Qué es un ataque DCSync: detección y prevención

DCSync es un ataque que permite a un adversario simular el comportamiento de un controlador de dominio (DC) y recuperar datos de contraseñas a través de la replicación de dominio. El uso clásico de DCSync es como precursor de un ataque de Golden Ticket ya que puede utilizarse para recuperar el hash de KRBTGT.

Específicamente, DCSync es un comando en la herramienta de código abierto Mimikatz. Utiliza comandos en el Directory Replication Service Remote Protocol (MS-DRSR) para simular el comportamiento de un controlador de dominio y solicitar a otros controladores de dominio que repliquen información, aprovechando funciones válidas y necesarias de Active Directory que no pueden ser desactivadas o deshabilitadas.

El proceso de ataque

El ataque DCSYNC funciona de la siguiente manera:

1. El atacante descubre un controlador de dominio para solicitar replicación.
2. El atacante solicita la replicación de usuario utilizando el GetNCChanges
3. El DC devuelve los datos de replicación al solicitante, incluyendo los hashes de contraseñas.

Derechos Requeridos

Se requieren algunos derechos muy privilegiados para ejecutar un ataque DCSync. Dado que normalmente toma algo de tiempo para que un atacante obtenga estos permisos, este ataque se clasifica como un ataque de cadena de eliminación en etapa tardía.

Generalmente, los Administradores, Domain Admins y Enterprise Admins tienen los derechos necesarios para ejecutar un ataque DCSync. Específicamente, se requieren los siguientes derechos:

• Replicando cambios en el directorio
• Replicando cambios en todos los Directory Management

Replicando cambios en el conjunto filtrado de Directory Management

Cómo las soluciones de Netwrix pueden ayudarte a detectar y frustrar ataques DCSync

Detección

Netwrix Threat Manager monitorea todo el tráfico de replicación de dominios en busca de señales de DCSync. No depende de registros de eventos ni de captura de paquetes de red. Su principal método de detección es encontrar patrones de comportamiento que coincidan con DCSync, incluyendo la actividad de replicación entre un controlador de dominio y una máquina que no es un controlador de dominio.

La solución ofrece un resumen claro de la actividad sospechosa, así como una visualización que ilustra qué usuario perpetró el ataque, el dominio y el usuario objetivo, y pruebas de apoyo del ataque. Si el mismo usuario ejecuta múltiples ataques DCSync, esta información crítica también se incluirá.

Respuesta

Para ejecutar DCSync, un atacante necesita privilegios elevados, por lo que la clave para frustrar un ataque es bloquear inmediatamente la escalada de privilegios. La respuesta estándar del manual de procedimientos de deshabilitar la cuenta de usuario puede no ser suficiente, ya que para cuando detectes el ataque en progreso, es probable que el atacante ya tenga a su disposición una serie de otros recursos y opciones.

Netwrix Threat Prevention proporciona políticas de bloqueo que pueden prevenir que una cuenta o estación de trabajo ejecute replicación adicional, lo cual puede ralentizar un ataque y dar a los respondedores más tiempo para eliminar completamente la amenaza.

Netwrix Threat Manager apoya estos pasos de respuesta proporcionando detalles sobre el perpetrador del ataque DCSync, las fuentes, los objetivos y los objetos consultados.

¿Qué es un ataque DCSync?

Los atacantes acceden con más frecuencia a través de ese tipo de delegación residual que mediante una cuenta de administrador comprometida, ya que los derechos de replicación se asignan a cuentas de servicio durante migraciones e integraciones y luego nunca se revocan.

Sin embargo, DCSync en sí no tiene parche, ya que utiliza la misma interfaz de replicación que usan los controladores de dominio para mantenerse sincronizados, y bloquearlo rompería Active Directory. El tráfico resultante parece idéntico a la replicación ordinaria para cualquiera que revise los registros rápidamente.

Cómo funciona un ataque DCSync

Solo el 26 % de las organizaciones confía plenamente en que su Active Directory está libre de configuraciones erróneas que permiten la escalada de privilegios, según el Netwrix 2026 Data and Identity Security Report. Esa incertidumbre está bien fundamentada, ya que DCSync solo necesita un permiso delegado en una cuenta de servicio olvidada para entregar todos los hashes de contraseña del dominio.

La secuencia se completa en segundos y no requiere ejecución de código en el controlador de dominio.

1. El atacante apunta a cualquier controlador de dominio en el dominio

Un ataque DCSync es una técnica de intrusión en la que un adversario simula un controlador de dominio (DC) y recupera datos de contraseñas mediante la replicación de dominio. Normalmente precede a un ataque Golden Ticket.

3. El controlador de dominio objetivo devuelve hashes de contraseña

No se necesita un acceso previo en esa máquina específica, ya que la solicitud viaja por la red como cualquier otro tráfico de replicación. Cualquier controlador de dominio la responderá.

2. El atacante se hace pasar por un controlador de dominio para solicitar la replicación

DCSync también es el nombre de un comando en la herramienta open-source Mimikatz. El comando usa el Directory Replication Service Remote Protocol (MS-DRSR) para suplantar un controlador de dominio y pedir a los controladores reales que repliquen la información del directorio, abusando de la replicación de AD que funciona exactamente como está diseñada. MITRE la rastrea como T1003.006 bajo OS Credential Dumping, y no hay ninguna vulnerabilidad subyacente que corregir.

El atacante llama a IDL_DRSGetNCChanges en la interfaz de replicación MS-DRSR, también conocida como DRSUAPI, y solicita datos de replicación de usuarios mientras se hace pasar por un controlador de dominio. La llamada es un uso legítimo de la API de replicación, no una solicitud malformada o inusual, por lo que no activa defensas a nivel de protocolo.

El controlador de dominio responde con datos de replicación, incluidos los hashes de contraseña, porque la interfaz no puede distinguir un controlador de dominio legítimo de una cuenta con los permisos adecuados.

4. Las herramientas existentes ejecutan la solicitud

Qué permisos requiere un ataque DCSync

Los Administradores, Domain Admins y Enterprise Admins tienen los derechos necesarios por defecto. Debido a que estos privilegios tardan en obtenerse, DCSync suele aparecer tarde en la cadena de ataque. Los permisos específicos son:

• Replicación de cambios en Directory (DS-Replication-Get-ChangesExpand)

El módulo DSInternals de PowerShell lo expone a través de Get-ADReplAccountExpand. Extraer datos de contraseñas de usuario con Mimikatz DCSync cubre toda la secuencia de comandos.

El módulo lsadump::dcsync de Mimikatz sigue siendo la implementación más conocida, y otras herramientas realizan la misma solicitud de replicación. secretsdump.py de Impacket lo ejecuta a través de la red, y el módulo DSInternals de PowerShell lo expone mediante Get-ADReplAccountExpand.

• Replicando Directory Changes All (DS-Replication-Get-Changes-AllExpand)
• Replicación de cambios de Directory en conjunto filtrado (requerido solo en algunos entornos)

Dos permisos más abren la misma puerta y rara vez aparecen en una revisión de la membresía de grupos privilegiados. Una cuenta con GenericAll (control total) o AllExtendedRights a nivel de dominio puede ejecutar DCSync sin pertenecer a ningún grupo privilegiado.

Lo que hacen los atacantes con los hashes

Cualquier cuenta con estos derechos delegados en el contexto de nombres de dominio puede replicar. Las cuentas de servicio Entra Connect, normalmente nombradas con el prefijo MSOL_, poseen legítimamente estos derechos, al igual que las cuentas que los heredaron de una migración o una integración olvidada hace tiempo.

Los derechos de replicación que hacen posible DCSync son permisos; los hashes que devuelve no lo son. Un hash es material de credenciales, la representación criptográfica de una contraseña, y poseer uno permite a un atacante hacerse pasar por quien pertenece sin conocer la contraseña real de esa persona. Lo que haga el atacante a continuación depende de qué cuenta obtuvo el hash.

Hash KRBTGT: Forjar tickets para cualquier cuenta en el dominio

Enumerar quién tiene los derechos hoy es la comprobación de exposición más económica disponible, ya que la delegación reside en las listas de control de acceso (ACL) que una herramienta de evaluación de directorios lee directamente, y análisis de rutas de ataque muestra cómo se encadenan esos derechos.

Los atacantes obtienen estos derechos mediante privilege escalation, por lo que cualquier cuenta que los posea necesita la misma privileged account management disciplina que un Domain Admin, no un acceso permanente que nadie revisa.

Hashes de cuentas regulares: Muévete lateralmente sin descifrar nada

Una ejecución de DCSync que alcanza la cuenta KRBTGT convierte el robo de credenciales en una compromisión del dominio. El hash KRBTGT firma cada ticket Kerberos en el dominio. Un atacante que lo posea puede falsificar Ticket Granting Tickets (TGTs) para cualquier cuenta sin tocar las credenciales propias de esa cuenta, y ese acceso falsificado sobrevive a un restablecimiento normal de contraseña en la cuenta suplantada. Solo un restablecimiento de KRBTGT invalida los tickets falsificados.

Material de credenciales más débil: descifrar sin conexión una contraseña en texto plano

Cómo detectar un ataque DCSync

Los hashes NT LAN Manager (NTLM) para cuentas regulares y privilegiadas alimentan Pass-the-Hash directamente. Un atacante se autentica como esa cuenta reproduciendo el hash mismo, por lo que no es necesario descifrar nada antes de que la credencial pueda usarse en otro lugar del dominio.

Tres lugares pueden detectar una solicitud DCSync, y cada uno detecta algo diferente: el registro de eventos del controlador de dominio, la red en sí y el comportamiento de la identidad que realiza la solicitud.

Las claves Kerberos y el historial de contraseñas almacenadas recuperados en la misma respuesta de replicación se descifran offline cuando el tipo de hash es lo suficientemente débil como para hacerlo práctico. Las contraseñas en texto plano aparecen directamente solo para cuentas configuradas con cifrado reversible, una configuración que vale la pena auditar por esta razón.

Habilite la auditoría de Directory Service y las alertas sobre los GUID de replicación

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 para DS-Replication-Get-ChangesExpand
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 para DS-Replication-Get-Changes-AllExpand

Observe el tráfico para la replicación desde un host que no sea DC

Comportamiento básico de identidad para detectar lo que un solo evento no puede

Active primero la Política de Auditoría Avanzada para el Acceso al Servicio de Directorio, ya que Windows la desactiva por defecto y el Evento ID 4662 no se activará sin ella. Una vez activada, vigile específicamente estos GUIDs de propiedades de replicación, identificados por identificador único global (GUID) en lugar de por nombre amigable:

Alerta cuando esos GUID aparezcan en una cuenta que no sea un controlador de dominio ni una cuenta de servicio de replicación conocida, y filtra antes de alertar, ya que un volumen 4662 sin filtrar en un controlador de dominio ocupado genera ruido que nadie lee. Trata esta señal como un respaldo y no como el control principal, ya que un atacante que accede a un controlador de dominio también puede borrar o detener los registros de los que depende una estrategia solo 4662.

Cómo prevenir ataques DCSync

Controle los nuevos derechos de replicación en el aprovisionamiento, no solo en la siguiente revisión

No existen controles a nivel de protocolo que bloqueen DCSync, por lo que la prevención depende de controlar quién puede invocar la replicación y acortar las rutas que conducen a esos derechos.

Monitoree un enlace DRSUAPI que lleve IDL_DRSGetNCChanges desde cualquier host que no sea un controlador de dominio, ya que la replicación legítima solo se realiza entre controladores de dominio y no existe una versión benigna de ese tráfico para filtrar. Priorice esta señal sobre la detección en el registro de eventos, ya que la monitorización de red captura la solicitud independientemente de si el controlador de dominio la registró, lo que mantiene la señal disponible incluso después de que un atacante manipule el registro del endpoint.

Alimente eventos de replicación en una plataforma de Identity Threat Detection que crea una línea base del comportamiento normal de cada cuenta, ya que un evento 4662 o una vinculación DRSUAPI pueden parecer legítimos aisladamente pero anormales según el historial específico de esa cuenta. Un patrón que esta capa detecta es cuando una cuenta que nunca antes había hecho una solicitud de replicación la realiza por primera vez, algo que una lista blanca estática o una regla puntual pueden pasar por alto por completo.

Los derechos otorgados durante una migración o integración tienden a permanecer mucho después de que el proyecto termina, ya que eliminar accesos que nadie recuerda haber concedido es más difícil que otorgarlos inicialmente.

Revise y elimine los derechos de replicación que nadie pueda justificar

Restringir la replicación RPC a direcciones conocidas de controladores de dominio

Revise cada cuenta que tenga los tres permisos de replicación más GenericAll y AllExtendedRights en el contexto de nombres del dominio, y elimine lo que nadie pueda justificar. Repita la revisión según un calendario, ya que las nuevas integraciones reintroducen los derechos.

Cierre las rutas que usan los atacantes para alcanzar los derechos de replicación

Cuando la topología lo permita, permita la replicación de llamadas a procedimiento remoto (RPC) solo entre direcciones conocidas de controladores de dominio. Esto no detendrá a un atacante que ya tenga derechos válidos de replicación, pero bloquea las solicitudes de cualquier host sin una razón legítima para hacerlas.

Cómo responder a un ataque DCSync sospechoso

Delimite lo que el atacante realmente consultó

Enterprise Key Admins es el ejemplo recurrente, ya que adprep /domainprep en Windows Server 2016 otorgó a ese grupo control total sobre el Domain Naming Context y sus objetos secundarios. Microsoft lo calificó como un error en lugar de una vulnerabilidad y lo cerró para nuevas preparaciones de dominio a partir de la actualización 1709, pero los dominios preparados antes de esa corrección necesitan un script de remediación separado; las actualizaciones del esquema a nivel de dominio por sí solas no lo resolverán.

Suponga que los hashes ya se han ido, porque los datos salieron del dominio antes de que se activara la alerta. Lo que haga a continuación decidirá cuánto tiempo ese acceso seguirá beneficiando al atacante.

Requiere una justificación documentada y un propietario nombrado antes de que cualquier nueva integración o migración reciba DS-Replication-Get-ChangesExpand, DS-Replication-Get-Changes-AllExpand, GenericAllExpand, o AllExtendedRightsExpand, en lugar de otorgar primero el derecho y revisarlo en el siguiente ciclo de auditoría.

Revise el ID de evento 4662, Directory Service y los registros de Sysmon para determinar qué objetos consultó el atacante antes de decidir hasta dónde deben llegar la contención y la remediación. Lo que se obtenga aquí determinará si la respuesta se detiene en una cuenta o se extiende a un restablecimiento de credenciales a nivel de dominio.

Verifique que Zerologon (CVE-2020-1472) esté corregido, ya que las vulnerabilidades que otorgan privilegios de dominio acortan directamente toda la cadena de ataque. Trate las rutas de obtención de credenciales como Kerberoasting como la forma en que los atacantes obtienen derechos de replicación desde el inicio, no como un problema separado para resolver después. Ambas correcciones forman parte de las mejores prácticas de seguridad de Active Directory que mantienen bajo control las otras rutas privilegiadas del dominio.

Restablezca KRBTGT dos veces si estaba entre los hashes

Contenga la fuente, no solo la cuenta implicada

Deshabilitar la cuenta implicada es el reflejo, pero por sí solo logra poco, porque el atacante ahora tiene credenciales que funcionan independientemente de esa cuenta. Revoca los derechos de replicación y las membresías en grupos privilegiados, y aísla el host de origen.

Cómo Netwrix te ayuda a detectar y bloquear ataques DCSync

Encuentra todas las cuentas que tienen derechos de replicación

La evaluación, detección y prevención se realizan mediante diferentes productos aquí, y trabajan juntos.

Si KRBTGT estaba entre ellos, restablezca la contraseña de KRBTGT dos veces, dejando un intervalo entre los dos restablecimientos que sea mayor que la vida máxima del ticket (10 horas por defecto) y un ciclo completo de replicación. Un solo restablecimiento deja la clave anterior válida, por lo que los tickets falsificados siguen funcionando. Cuando los registros no pueden establecer el alcance, opte por un restablecimiento de credenciales a nivel de dominio en lugar de adivinar.

Detectar una solicitud de replicación desde un host que no es DC

Bloquee la solicitud de replicación antes de que se complete

Netwrix PingCastle evalúa Active Directory según sus controles mapeados con MITRE ATT&CK, incluyendo cuentas con derechos de replicación fuera de los grupos predeterminados, convirtiendo la revisión de delegación anterior en un control repetible.

Sus alertas muestran la cuenta detrás de la solicitud, el dominio y la cuenta objetivo, y los objetos consultados, que son los detalles que un analista necesita para delimitar la ejecución en lugar de solo confirmar que ocurrió.

Su detección de DCSync proviene de una política de Netwrix Threat Prevention AD Replication Monitoring, por lo que ambos productos funcionan en conjunto.

Netwrix Threat Manager detecta técnicas de robo de credenciales contra Active Directory, incluyendo una solicitud de replicación emitida por una máquina que no es un controlador de dominio, y alerta sobre ello.

Netwrix Threat Prevention aplica políticas de bloqueo que impiden que una cuenta o estación de trabajo específica ejecute replicaciones adicionales. Ambos encajan en identity threat detection and response, con Threat Manager extendiendo la detección a Entra ID y Threat Prevention aplicando controles en la capa de Active Directory local.

Por dónde empezar con la exposición de DCSync

[MARCADOR DE IMAGEN: Producto, solicitar a PMM. Necesita una captura de pantalla del producto Netwrix Threat Manager (cualquier vista actual que muestre un evento DCSync detectado con host de origen, cuenta objetivo y objetos consultados)]

Los derechos de replicación soportan la mayor parte de la defensa aquí, y una lista de delegación que nadie ha revisado desde la última migración es la vía de ataque realista. Enumerarla cuesta una tarde.

Solicite una demostración para ver cómo Netwrix encuentra derechos de replicación, detecta un intento activo de DCSync y bloquea el siguiente en su propio entorno de Active Directory.

La alerta sobre la replicación desde hosts que no son controladores de dominio detecta el intento en sí, y esa señal se mantiene independientemente de si la auditoría de Directory Service estuvo activada o no. Un procedimiento documentado de reinicio de KRBTGT decide cuánto tiempo una ejecución exitosa sigue beneficiando al atacante.