SeManageVolumePrivilege and DLL hijacking

SeManageVolumePrivilege is a Windows privilege meant for "volume maintenance tasks" (defragmenting, extending volumes, etc.). It sounds harmless, but it grants low-level disk access and, in practice, lets you rewrite the access control lists (ACLs) of system files, including those under C:\Windows. Whoever holds it can grant themselves write access to protected directories that normally only SYSTEM touches.

Who has it. It's uncommon, but some service accounts carry it through misconfiguration. The first step is always to confirm it:

whoami /priv

If SeManageVolumePrivilege shows up (even as Disabled, the exploit enables it), the vector is available.

From privilege to SYSTEM (DLL hijacking). The classic abuse uses the public binary SeManageVolumeExploit.exe, which leverages the privilege to give BUILTIN\Users write access to the files under C:\Windows:

.\SeManageVolumeExploit.exe       :: "Entries changed: NNN / DONE"

From there you can hijack a DLL that a privileged process loads. A convenient target is C:\Windows\System32\wbem\tzres.dll: the WMI service loads it whenever someone runs systeminfo, and that service runs as a privileged account. You drop a malicious tzres.dll (for example, a reverse shell built with msfvenom -f dll) and trigger the load:

move tzres.dll C:\Windows\System32\wbem\
systeminfo        :: WMI loads the DLL and runs the payload

The resulting shell inherits the context of the process that loaded the DLL (often NT AUTHORITY\NETWORK SERVICE or SYSTEM, depending on the triggered process), enough to read the proof or, if needed, chain a Potato attack.

Why it matters. It's another case of "legitimate privilege turned into escalation": no kernel exploit needed, just abusing misassigned permissions. Conceptually it's a cousin of PATH hijacking and SeImpersonate abuse.

How to detect it. The signature has two parts. First, the mass ACL change on C:\Windows that SeManageVolumeExploit.exe performs: a flood of 4670 events ("permissions on an object were changed") and the binary itself in 4688/Sysmon 1. Second, the DLL hijack: Sysmon Event ID 7 (Image Load) of an unsigned tzres.dll loaded from System32\wbem by wmiprvse.exe, and the privileged child process that follows. A freshly written tzres.dll in System32\wbem (FIM) is the on-disk indicator.

Defence. Don't grant SeManageVolumePrivilege to service accounts that don't need it, watch for mass ACL changes on C:\Windows, and apply known-DLL lists / binary signing so a foreign DLL can't be loaded from a writable directory.