ADPRIV-021: Huérfanos de AdminCount
- Plataforma
- Active Directory
- Categoría
- AD Privileged Account Security
- Severidad
- Medium
- Pilar de Zero Trust
- Identity (peso 3)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Cuando se eliminan objetos de los grupos protegidos, el atributo AdminCount permanece establecido en 1 y los permisos heredados siguen bloqueados. Estos 'huérfanos de AdminCount' tienen la herencia de permisos rota, lo que puede impedir que las políticas de seguridad se apliquen correctamente y puede enmascarar una escalada de privilegios
Por qué importa
AdminCount orphans are not a direct privilege escalation primitive, but they degrade the security posture of the directory in three concrete ways. First, the AdminSDHolder ACL that remains stamped on the object overrides any OU-level delegation: a help-desk team that should be able to reset passwords in their OU cannot touch the orphan, so emergency password rotations fall back to Domain Admins and operational pressure tends to weaken Tier-0 hygiene. Second, the broken inheritance hides the object from GPO-driven security baselines that rely on inherited ACEs (for example, fine-grained password policy delegations and LAPS read permissions), so the orphan silently drifts out of the configured security model. Third, and most important for defenders, an orphan is a strong indicator that the account was once privileged. Adversaries who have read access to the directory (every authenticated user by default) routinely filter on adminCount = 1 to find historical Tier-0 identities, which are frequently service accounts with weak or never-rotated passwords, or human accounts that were demoted on paper but never had their secrets rotated. AdminCount orphans are explicitly called out as a hunting heuristic in BloodHound and AD posture assessment tools, and as a hygiene defect in Microsofts protected accounts guidance.
Ruta de ataque
1. Reconnaissance: the attacker queries LDAP as any authenticated user with a filter such as (&(objectCategory=person)(adminCount=1)) or runs Get-ADUser -LDAPFilter "(adminCount=1)" -Properties memberOf. No special rights are needed. 2. Triage: the attacker cross-references each result against current membership of the protected groups. Anything with adminCount = 1 and no current protected membership is an orphan. 3. Target selection: orphans that are service accounts (servicePrincipalName populated) are prioritised because they are eligible for Kerberoasting and often have weak passwords. Orphans that have not changed their password in years are prioritised because their hash is likely to crack offline. 4. Kerberoast or AS-REP roast: the attacker requests a TGS for the orphan SPN (Rubeus kerberoast /user:<orphan>) or, if PreAuth is disabled, an AS-REP (Rubeus asreproast). The returned ticket is cracked offline with hashcat mode 13100 or 18200. 5. Credential reuse: with the cleartext credential, the attacker authenticates as the orphan. Even though it is no longer in a protected group, the broken inheritance and stale AdminSDHolder ACL mean the account often retains delegated rights granted while it was privileged (mailbox access, SQL roles, file-share ACEs, certificate template enrollment rights), which is the foundation for the next lateral move. 6. Persistence: if the orphan has rights on a Tier-0 object that were granted while it was privileged and never audited away, the attacker uses the orphan as a low-noise persistence identity that is not in any protected group and therefore is not on the Tier-0 watch list.
Cómo lo evalúa Guerrilla
Guerrilla executes Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,sAMAccountName,servicePrincipalName,pwdLastSet,nTSecurityDescriptor against a reachable domain controller and then resolves nested memberOf for each result using tokenGroups where available and a recursive memberOf walk otherwise. The current set of SDProp protected groups is computed at runtime from the well-known SIDs (S-1-5-32-544, the domain SID + RID 512 / 519 / 518 / 548 / 549 / 550 / 551 / 552, plus the krbtgt account and Domain Controllers / RODC groups), with a dsHeuristics read to honour any organisation that has cleared the AccountOperators flag (dsHeuristics character 16). For each orphan the check also reads nTSecurityDescriptor and reports AreAccessRulesProtected = true so the analyst can see at a glance which orphans still have inheritance disabled. Results are surfaced as a structured object suitable for SIEM ingestion (DN, sAMAccountName, objectClass, adminCount, memberOf, inheritanceBroken, pwdLastSet, hasSPN, daysSincePwdChange).
Valor recomendado
Ninguna cuenta con AdminCount=1 que no sea miembro de algún grupo protegido
Remediación
Identifique las cuentas huérfanas mediante Get-ADUser -Filter {AdminCount -eq 1} y contrástelas con la pertenencia actual a los grupos protegidos. Para los huérfanos, borre el atributo AdminCount y vuelva a habilitar la herencia en la ACL del objeto. Use PowerShell o ADSIEdit para corregir los permisos heredados
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 | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-6, AC-3
- CIS AD Benchmark
- 4.7.2
- MITRE ATT&CK
- T1078.002