The Print Operators group is another highly privileged group within the Windows Security Groups
A principal who is member of this group has the following rights →
SeLoadDriverPrivilege assigned to its primary access token
“Load and unload device drivers” right
Create, share and delete printers connected to a DC
Log on locally to a DC
Shut down a DC
Enumeration
Listing the Groups to which the Current User belongs
whoami /groupsnet user <USER>
Members of Print Operators
net localgroup "Print Operators"
Code Execution as LOCAL SYSTEM
Workflow
As stated, a member of the Print Operators group usually has the seLoadDriverPrivilege assigned, which allows them to load and unload device drivers on the Windows Kernel
Device Drivers operate on Kernel Mode ( Ring 0 )
Therefore, if we compromise a principal belonging to this group, we can leverage this privilege to load a legitimate but vulnerable driver e.g. CAPCOM.sys, which exposes an interface to run arbitrary code in Kernel Mode
Then, we can run an exploit from Userland ( Ring 3 ) that interacts with the loaded driver in order to gain code execution as LOCAL SYSTEM
Since driver loading is a privileged action, the seLoadDriver privilege comes always disabled if the current process has a restricted primary token associated
If so, we will need to spawn a new process with a full primary access token in order to carry out the mentioned workflow
Requirements
The controlled user must be a member of the Print Operators group
The target must be vulnerable to CAPCOM.sys as Microsoft blocked the latter as of Windows 10 Version 1803
This is because it’s no longer possible to include references to registry keys under HKCU
UAC Bypass as the process from which the driver is loaded must have a high integrity level i.e. full primary access token
Abuse - Windows
Verifying Group Membership
So first, let’s verify that the current user belongs to the Print Operators group
whoami /groups | findstr /I print
Command Output
BUILTIN\Print Operators Alias S-1-5-32-550 Group used for deny only
Verifying Privileges
Next, we have to validate that the primary access token associated with the current process has the seLoadDriver privilege
whoami /priv | findstr /I "seload"
But it does not
UAC Bypass
Therefore, in order to have the given privilege assigned, we must spawn a new process with a high integrity level, that is, with a full primary access token assigned to it
To do so, we have to bypass the User Account Control ( UAC )
Interactive or RemoteInteractive Logon Session ( Type 2 or 10 )