ADACL-008: Análisis de delegación de OU
- Plataforma
- Active Directory
- Categoría
- AD ACL & Delegation
- Severidad
- Medium
- Pilar de Zero Trust
- Identity (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
La delegación a nivel de unidad organizativa es el método recomendado para conceder permisos administrativos en Active Directory, pero las delegaciones de OU mal configuradas pueden crear vías de acceso no deseadas. Esta comprobación analiza todas las delegaciones de permisos a nivel de OU para identificar concesiones demasiado permisivas, permisos heredados que eluden el ámbito previsto y delegaciones que pueden haber quedado obsoletas
Por qué importa
OU delegation determines who can read, modify, create, and delete the user, computer, group, and gMSA objects beneath it. A single excessive ACE on an OU containing Tier 0 or Tier 1 assets converts a helpdesk-level breach into a domain compromise. Concrete blast radius for a low-privilege attacker who controls a principal with abusive rights on an OU: GenericAll or WriteDACL on the OU grants the right to write a new ACE on any child object, including resetting passwords of users in the OU, taking ownership of computer objects, or writing msDS-KeyCredentialLink to perform Shadow Credentials (UnPAC-the-Hash). WriteProperty on servicePrincipalName on child users enables targeted Kerberoasting of accounts the attacker selects. WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity on a child computer enables Resource-Based Constrained Delegation (RBCD) takeover of that host. CreateChild for user objects lets an attacker plant a new account inside a sensitive OU that may inherit GPO-applied privilege, bypassing joiner workflow controls. Beyond the technical reach, undocumented delegations are an audit and recertification failure: SOX, PCI DSS, ISO 27001 A.9.2.5, and NIST SP 800-53 AC-6(7) all require periodic review of access, and stale OU ACEs are routinely missed because Active Directory Users and Computers (ADUC) does not surface them in the default view.
Ruta de ataque
1. Initial recon: from any domain-joined host with a low-privilege account, run BloodHound / SharpHound with the ACL collection method, or use PowerView Get-DomainObjectAcl -ResolveGUIDs against each OU. The collector reads nTSecurityDescriptor over LDAP and maps every ACE to a graph edge. 2. Path selection: in BloodHound, the attacker queries for outbound rights from owned principals to OU nodes (GenericAll, WriteDACL, WriteOwner, AddSelf, AllExtendedRights), then expands to child users and computers via the OwnsOU / GenericAll edges. The shortest path query frequently terminates at a Tier 0 group or a privileged user object. 3. Abuse, user objects: with WriteDACL on the OU, write a new ACE granting GenericAll to the controlled principal on a chosen child user, then reset the password (Set-DomainUserPassword) or write a Shadow Credential to msDS-KeyCredentialLink using Whisker or Certipy shadow-credentials. 4. Abuse, computer objects: with GenericAll on a computer object via OU inheritance, write msDS-AllowedToActOnBehalfOfOtherIdentity to point at an attacker-controlled computer account (RBCD), then request a service ticket as any user via S4U2Self + S4U2Proxy with Rubeus. 5. Abuse, group objects: with WriteProperty on the member attribute via the OU ACE, add the controlled user to a privileged group housed in the OU. 6. Persistence: write a deny-inherit ACE or rewrite the OU security descriptor to hide the abused ACE from default ADUC views, while retaining the access path.
Cómo lo evalúa Guerrilla
Guerrilla reads the OU tree via System.DirectoryServices.Protocols, binds the nTSecurityDescriptor of each OU, and parses it with System.DirectoryServices.ActiveDirectorySecurity. Each non-inherited ACE is evaluated against an allowlist of built-in trustees (Domain Admins, Enterprise Admins, SYSTEM, Account Operators, Pre-Windows 2000 Compatible Access where applicable). For non-allowlisted trustees the check resolves the SID to a current AD object via the SID resolver cache; orphaned SIDs (no matching object) are reported as stale delegations. ObjectType and InheritedObjectType GUIDs are resolved against the schema via the well-known rights GUID table (msDS-KeyCredentialLink = 5b47d60f-6090-40b2-9f37-2a4de88f3063, User-Force-Change-Password = 00299570-246d-11d0-a768-00aa006e0529, etc.). Inheritance flags are walked top-down so that ACEs applied at the domain root and inherited into every OU are reported once with their scope, not per-OU. Output includes OU distinguishedName, trustee SamAccountName or stale-SID marker, ActiveDirectoryRights, ObjectType resolved name, InheritanceType, and a risk classification (Critical / High / Medium) based on the rights mask and whether the trustee is privileged.
Valor recomendado
Todas las delegaciones de OU documentadas, delimitadas a tipos de objeto específicos y con permisos de mínimo privilegio
Remediación
Revise todas las ACE no predeterminadas de cada OU con dsacls.exe o PowerShell. Verifique que las delegaciones utilicen InheritedObjectType para delimitar los permisos a clases de objeto específicas. Elimine las delegaciones que ya no sean necesarias. Documente todas las delegaciones intencionales en una matriz de autorización.
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-6, AC-6(3), CM-5
- MITRE ATT&CK
- T1222.001