Tim Beasley Senior Incident Response Consultant

Welcome back to our exploration of risky Active Directory groups that don’t “look” risky. As I explained in our first installment, attackers don’t need Domain Admin to do real damage, and they aren’t always looking for groups with that kind of obvious high privilege.

Account Operators is an AD group that many people underestimate because it doesn’t contain the word “admins.” That’s exactly why it is so often overlooked.

A common misconception is that Account Operators isn’t a serious risk because members aren’t supposed to modify protected groups such as Domain Admins.

That assumption is incomplete at best—and dangerous at worst.
It’s also false in certain circumstances.

The main issue isn’t that Account Operators is a direct “top tier” administrative group (although we do treat it as such). The real problem is that it gives broad control over identities across the domain—and in Active Directory, identities are privilege.


What can Account Operators actually do?

By default, members of the Account Operators group can create, modify, and delete user, group, and computer objects across much of the domain. In many environments, that includes abilities to:

  • Reset passwords
  • Enable or disable accounts
  • Edit service principal names (SPNs)
  • Manage non-protected group membership
  • Create new computer accounts

Account Operators are intentionally restricted from directly modifying protected groups and accounts controlled by AdminSDHolder, including Domain Admins, Enterprise Admins, Schema Admins, and the built-in Administrators group on domain controllers.

But those restrictions do not eliminate the attack paths that a skilled threat actor can use after compromising an Account Operators member.

That’s the key point that defenders need to internalize: Account Operators is not a harmless delegated admin role.
It is a privilege amplifier sitting directly on top of the identity plane.


Why does the Account Operators group become dangerous so quickly?

If an attacker compromises an Account Operators credential, they don’t need to add themselves to Domain Admins to start winning.

I’ve seen them create attacker-controlled users, reset passwords for non-protected privileged accounts, manipulate group membership indirectly, add SPNs for Kerberoasting setup, and abuse computer object creation for delegation attacks such as resource-based constrained delegation.

This matters because many of the most realistic enterprise attack paths don’t require touching the obvious “crown-jewel” groups first. They need the right identities, the right delegated groups, and the right authentication paths just long enough to pivot.

In other words, Account Operators gives an attacker distributed write access across the identity fabric. That is often more than enough to move from “not quite privileged” to “I own you.”


Realistic abuse paths after Account Operators compromise

One obvious path is backdoor account creation. An attacker can create a new user and then place it into privileged or semi-privileged groups they can control, including groups with hidden escalation paths that are often monitored far less aggressively than Domain Admins. In addition, this approach gives them the ability to figure out group nesting within privileged groups, allowing for further escalation and persistence.

Another common path is targeted or bulk password reset activity. Account Operators can reset passwords for most users in the domain, including service accounts, application identities, and non-protected administrative users. In the hands of a threat actor, that is immediate operational access and potential business disruption.

A third path is SPN abuse and Kerberoasting. If an attacker can edit account attributes and add SPNs, they can create fresh Kerberoastable targets or make existing accounts exploitable without the “attack” looking obvious.

A fourth path is abusing non-protected but still valuable accounts. Many organizations still have delegated admins, legacy service accounts, and nested groups that aren’t protected by AdminSDHolder. Resetting passwords or changing attributes on those objects can be enough to escalate up.

And then there is computer account abuse. Because Account Operators can often create computer objects and control what they create, they can enable attacks involving MachineAccountQuota and resource-based constrained delegation. That creates a path to impersonation and privilege escalation without ever touching the Domain Admins group directly.

Are we having fun yet?


The AdminSDHolder nuance defenders should not ignore

This is where the conversation gets even more uncomfortable.

In theory, Account Operators should not be able to modify protected groups like Domain Admins or Enterprise Admins.

In practice, that protection is not enforced continuously. It is enforced by the Security Descriptor Propagator process, commonly called SDProp, which stamps the AdminSDHolder ACL onto protected objects on a periodic cycle. By default, that cycle runs about every 60 minutes.

The default 60-minute SDProp interval matters. Between processing runs, “protected objects” can temporarily change from the intended security descriptor. If permissions have drifted, if inherited or delegated rights were not fully corrected yet, or if a newly created or newly modified object has not been restamped, an attacker may get a short-lived opportunity to abuse that gap before SDProp re-applies the protected ACL.

That means an attacker may not need persistent membership in a protected group. They may only need enough time inside that default 60-minute window to add a controlled principal, start a privileged session, dump secrets, create backdoor accounts, or establish persistence elsewhere before SDProp removes the obvious evidence at the ACL or membership level. They may even have time to reset a newly created admin account.

60 minutes is a long time for a well-versed threat actor.

That is a terrible detection problem for defenders because it creates the possibility of very short-lived privileged membership, followed by privileged activity from an account that may no longer appear to be privileged when investigators look later.

The key takeaway is that AdminSDHolder protection is eventually consistent, not real-time, and the default 60-minute SDProp schedule is the gap an attacker tries to exploit.


What should defenders monitor to detect Account Operators abuse?

If you want to detect abuse of Account Operators, start with identity lifecycle activity. New account creation, account enablement, password reset activity, and account changes are all core signals when performed by a member of this group. Relevant events include 4720, 4722, 4723 or 4724, and 4738.

Next, watch group membership changes closely, especially additions to unusual delegated groups, nested groups, or rarely used privilege-bearing groups. Events such as 4728, 4732, and 4756 matter here, and in the short-window scenario you also need to correlate rapid add-and-remove patterns with 4729, 4733, and 4757.

You should also monitor for SPN changes and other directory attribute modifications. Event 5136 is important for unexpected servicePrincipalName edits, delegation-related attribute changes such as msDS-AllowedToActOnBehalfOfOtherIdentity, and other suspicious changes on newly created or newly modified objects.

Finally, build a behavioral baseline.

  • How many users does an Account Operators member normally create in a day?
  • How many password resets do they normally perform?
  • Who are the normal targets?

Deviation from that baseline is where high-confidence detections begin.


What to do about it

The preferred answer is simple: empty the group.

If there is no valid operational reason to use Account Operators (which is almost ALWAYS the case), remove the membership and keep it empty. If you still need delegated administration, use tailored delegation on the specific OUs and objects that actually require management.

If the group membership cannot be eliminated immediately, treat it as far more sensitive than most organizations currently do.

  • Enforce administrative tiering
  • Prevent interactive logon to domain controllers and critical servers
  • Deny local logon where possible

You should also reduce the opportunities for computer object abuse by tightening MachineAccountQuota (preferably to zero) where appropriate and restricting who can create new computer accounts.

In addition, explicitly monitor the surfaces that make short-window or indirect escalation possible: privileged group changes, delegation changes, SPN modifications, and ACL changes on AdminSDHolder and protected groups.


Rethink the risks of Account Operators

The Account Operators group is dangerous because it gives broad control over the objects that define access, trust, and authentication across Active Directory.

A compromised Account Operators identity can create new principals, reset passwords, manipulate groups, set up Kerberoasting, abuse delegation, establish persistence, and in the right conditions exploit the delay built into AdminSDHolder protection.

That is why mature defenders should stop thinking of Account Operators as a legacy support role and start treating it for what it really is: pre-privileged access with multiple paths to escalation…aka Tier 0.

Identity is the perimeter…protect it.

Until next time…Follow the conversation about Account Operators on LinkedIn.

And if you want expert help finding and closing gaps in your AD security gaps, reach out for an Active Directory Security Assessment. We’re here for you.


Further reading