BIPI
BIPI

ACL Abuse in Active Directory: GenericAll, WriteDACL, and Owner Takeovers

Cybersecurity

Misconfigured AD object ACLs are the silent privilege escalation channel in nearly every enterprise. A practical tour of GenericAll, WriteDACL, WriteOwner, and the takeover primitives.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 2, 2024 · 10 min read

#active-directory#acl#privilege-escalation#red-team

Every object in Active Directory has a security descriptor. Most enterprises have inherited a decade of helpdesk delegations, vendor installations, and ad-hoc grants that nobody audits. ACL abuse is the privilege escalation channel that lives in the cracks between those grants.

The primitives

  • GenericAll: full control. Reset passwords, set SPNs, add yourself to groups, write attributes.
  • GenericWrite: write most attributes, including servicePrincipalName and scriptPath.
  • WriteDACL: rewrite the ACL itself, so grant yourself GenericAll then proceed.
  • WriteOwner: take ownership, then grant yourself WriteDACL, then GenericAll.
  • ForceChangePassword: change the password without knowing the old one.
  • AddSelf: add yourself to the target group, useful when AddMember is restricted.

Common takeover chains

  1. User with GenericAll on a privileged user: set an SPN, Kerberoast the target, crack offline, or simply ForceChangePassword.
  2. User with WriteOwner on a group: take ownership, grant AddMember to self, add self to group.
  3. User with GenericWrite on a computer: write msDS-AllowedToActOnBehalfOfOtherIdentity for RBCD, request a service ticket as anyone.
  4. User with GenericAll on an OU: pre-create a computer account in the OU, then exploit downstream.
  5. User with WriteDACL on the domain root: grant DCSync (DS-Replication-Get-Changes plus All), dump krbtgt.

Resource-Based Constrained Delegation takeover

RBCD is the most useful primitive when you control GenericWrite on a target computer. Add a controlled machine account (any low-priv user can create up to ten via MachineAccountQuota) to msDS-AllowedToActOnBehalfOfOtherIdentity on the target, then use S4U2Self and S4U2Proxy to impersonate any user against the target. Local admin on the box, no password reset required, very quiet.

Standard chain: impacket addcomputer.py, then rbcd.py to set the attribute, then getST.py with -impersonate administrator, then psexec.py with the resulting ticket.

MachineAccountQuota defaults to 10. Setting it to 0 closes one of the easiest privilege escalation primitives in modern AD.

Shadow Credentials (msDS-KeyCredentialLink)

GenericWrite or GenericAll on a user or computer also enables Shadow Credentials. Write a key credential, then PKINIT-authenticate as the target without ever changing the password. Tooling: Whisker, pyWhisker, Certipy shadow auto.

Finding the paths

  • BloodHound: Owned user, Shortest Paths to High Value Targets, filter to ACL edges only.
  • PowerView: Find-InterestingDomainAcl to surface non-default ACL grants.
  • Adalanche: alternative graph engine with deeper ACL detail and faster ingest for large forests.

Detection

  • Event 5136 changes on user, group, and computer objects, especially msDS-AllowedToActOnBehalfOfOtherIdentity, msDS-KeyCredentialLink, servicePrincipalName, scriptPath.
  • Event 4742 computer account changes from unexpected source workstations.
  • Event 4732 and 4728 group membership additions outside the change window.

Remediation

  1. Run a quarterly ACL audit. Anything granting non-admin principals write rights on Tier 0 objects is a finding.
  2. Set MachineAccountQuota to 0 unless there is a documented need.
  3. Restrict who can write msDS-KeyCredentialLink via a delegation review.
  4. Tier the directory. Tier 0 objects must only have Tier 0 ACL grants.
  5. Deploy Microsoft LAPS for local admin and Authentication Silos for privileged users to limit blast radius.

ACL abuse is invisible until someone draws the graph. Once you have, the fix is mechanical. The work is doing it.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.