the_open_door
café
ESEN
← Volver al índice

ACL Abuse (DACL)

ATT&CKT1098
Arsenal completo de comandos en la cheatsheet

En Active Directory cada objeto (usuarios, grupos, equipos, GPOs, el propio objeto de dominio) lleva un descriptor de seguridad, y dentro de él una DACL (Discretionary Access Control List): la lista de ACEs (Access Control Entries) que define quién puede hacer qué sobre ese objeto. Cuando esos permisos se conceden de más (a un usuario ordinario, a un grupo demasiado amplio, por herencia), dejan de ser configuración y se convierten en una ruta de escalada que no depende de ningún exploit: solo de usar el permiso que sobra.

El modelo, en concreto. La DACL vive en el atributo nTSecurityDescriptor del objeto y es legible por LDAP con una simple cuenta de dominio. Cada ACE ata un principal (quién) a un derecho (qué) sobre el objeto (dónde). Eso es exactamente lo que recolecta y pinta BloodHound: convierte miles de ACEs en un grafo y responde a la pregunta clave, cuál es la ruta más corta desde donde estoy hasta Domain Admin encadenando permisos mal puestos.

Los abusos, cada uno con su página. Según el derecho concreto que dibuje BloodHound, el abuso cambia:

Cómo se trabaja en la práctica. El flujo es siempre el mismo: enumerar las ACEs escribibles, abusar de la que interese y verificar el nuevo estado en vez de darlo por hecho.

# enumerar qué permisos tiene un principal que controlamos (PowerView)
Get-DomainObjectAcl -Identity <target> -ResolveGUIDs |
  ? { $_.SecurityIdentifier -eq (Get-DomainUser <yo>).objectsid }
# escribir/leer ACEs desde Linux (Impacket): propietario y DACL
owneredit.py -action write -new-owner <yo> -target <target> <domain>/<yo>:<pass>
dacledit.py  -action write -rights <derecho> -principal <yo> -target-dn <DN> <domain>/<yo>:<pass>

bloodyAD y net rpc cubren las mismas primitivas con otra sintaxis. La regla de rigor: tras cada abuso que cambia estado, una comprobación corta (un login, Get-ADUser, net rpc group members, una consulta LDAP de la DACL) es la prueba de que el permiso se aplicó.

Matiz. Que BloodHound marque una arista no garantiza que sea explotable aquí y ahora: puede depender de la contraseña del objetivo, de que la cuenta esté habilitada, de heredar permisos que un GPO revierta o de condiciones de la delegación. La arista es el indicio; el abuso verificado es la prueba.

Cómo detectarlo. El abuso de ACLs no se detecta en la lectura (enumerar la DACL por LDAP es indistinguible de una consulta legítima), sino en la escritura y en el uso posterior. Cambiar una DACL o un propietario genera Event ID 5136 (se modificó un objeto del servicio de directorio) y 4670 (se cambiaron permisos de un objeto); el efecto concreto añade su propio evento según el derecho abusado: reset de contraseña 4724, alta en grupo 4728/4732/4756, replicación 4662. Todo ello exige activar Audit Directory Service Changes con SACLs en los objetos Tier-0. La estrategia que funciona es correlacionar por actor: un usuario de bajo privilegio que en minutos modifica una DACL y ejecuta el derecho recién concedido es la firma de la cadena. En modo proactivo, correr BloodHound en modo defensivo encuentra las rutas antes que el atacante.

Defensa. Mínimo privilegio sobre las ACEs, con lupa en el objeto de dominio y la cuenta del DC (donde una WriteDACL equivale a DCSync). Revisar grupos sospechosos por diseño (Account Operators, Exchange Windows Permissions) y podar las ACEs heredadas o concedidas de más antes de que se conviertan en ruta.

HerramientasbloodyADBloodHoundPowerViewowneredit.pydacledit.pySharpHoundbloodhound-pythonPingCastleBloodHound CLI

Máquinas donde se aplica