Active Directory lets administrators delegate fine-grained rights: who can reset whose password, edit which group, or modify which object’s permissions. Attackers abuse these ACLs (access control lists) by chaining rights like GenericAll, WriteDACL, and ForceChangePassword into a route to privilege. Kerberos delegation, a feature that lets a service act on a user’s behalf, has its own abuses (unconstrained, constrained, and resource-based delegation) that can let an attacker impersonate anyone, including a Domain Admin. None of it is a vulnerability in the classic sense. It is configuration, which is why it hides in plain sight.
ACL abuse: rights as rungs
Every object in Active Directory has an ACL describing who can do what to it. Delegated administration relies on this: the helpdesk can reset passwords, a team lead can manage their group. The problem is that these rights are often broader than intended and accumulate over years.
The rights attackers chain include:
- GenericAll: full control of an object, enough to reset its password or take it over.
- GenericWrite: write attributes, which enables tricks like adding an SPN to make an account kerberoastable (targeted Kerberoasting).
- WriteDACL: rewrite the object’s permissions and grant yourself anything.
- ForceChangePassword: reset a user’s password without the old one.
- AddMember: add yourself or a controlled account to a privileged group.
BloodHound exists precisely to find where these rights connect into a path.
A worked example: targeted Kerberoasting
Suppose your compromised user has GenericWrite over a service account. On its own that looks minor. But you can:
1. Write a fake SPN onto that account using your GenericWrite. 2. Now that it has an SPN, Kerberoast it: request its ticket and crack the password offline. 3. If the cracked account is privileged, you have escalated.
This is how a single, boring-looking permission becomes a full escalation. The lesson: in AD, the danger is in how rights combine, not in any one right alone.
Kerberos delegation abuse
Delegation lets a service act on behalf of a user, for example a web app reaching a database as the logged-in user. Three flavours, three abuses:
- Unconstrained delegation: a server with this can capture the TGT of any user who connects, then impersonate them anywhere. If you can coerce a Domain Admin or a Domain Controller to connect, you win.
- Constrained delegation: limited to specific services, but S4U tricks can still let an attacker who controls the account impersonate other users to those services.
- Resource-based constrained delegation (RBCD): configured on the target object via the
msDS-AllowedToActOnBehalfOfOtherIdentityattribute. If an attacker can write that attribute (often via GenericWrite or WriteDACL), they can grant a controlled machine the right to impersonate any user to the target, including a Domain Admin.
How to defend
Defence is about pruning and tiering:
- Audit ACLs regularly with BloodHound and remove rights that no longer serve a purpose, especially WriteDACL and GenericAll on sensitive objects.
- Avoid unconstrained delegation entirely on anything but Domain Controllers, and mark privileged accounts as "sensitive and cannot be delegated."
- Protect the RBCD attribute. Restrict who can write
msDS-AllowedToActOnBehalfOfOtherIdentityand watch for changes to it. - Tier administration so that control of a low-value object never chains up to a Tier 0 asset.
References
- [1]Microsoft: Best Practices for Securing Active Directory(Microsoft)
- [2]MITRE ATT&CK Enterprise Matrix(MITRE)
- [3]Microsoft: Active Directory Certificate Services(Microsoft)