DCSync a menudo se considera una de las técnicas más peligrosas en ataques contra Active Directory. No requiere volcar memoria del controlador de dominio ni se parece al típico “extracción de contraseñas de LSASS”. En lugar de eso, el atacante se hace pasar por otro controlador de dominio y “pide” al controlador legítimo que entregue los datos de replicación. Como resultado, se pueden obtener hashes NTLM, claves de Kerberos y otros secretos que abren la vía a la compromisión de todo el dominio.
La astucia de DCSync es que se trata de un abuso de un mecanismo legítimo. La replicación en Active Directory es esencial; sin ella, varios controladores de dominio no podrían sincronizar cuentas, grupos y políticas. La técnica DCSync simplemente usa el mismo protocolo que emplean los controladores entre sí y, con los permisos adecuados, solicita la “replicación de secretos” desde una máquina remota.
En MITRE ATT&CK DCSync se describe como una subtécnica de volcado de credenciales del sistema operativo (OS Credential Dumping) y tiene el identificador T1003.006. Es un punto de partida útil para entender el lugar de DCSync en las cadenas de ataque y los escenarios típicos de uso. Conviene tener a mano la ficha de la técnica en el sitio MITRE ATT&CK.
A continuación se analiza por qué los atacantes usan DCSync, cómo funciona a nivel de permisos y protocolos y qué conviene hacer para protegerse y detectar su uso.
Por qué existe DCSync y por qué es tan peligroso
Active Directory normalmente no se despliega en un solo servidor. En un dominio suele haber varios controladores de dominio y todos los cambios deben propagarse rápidamente por la infraestructura. Para ello existe la replicación mediante el Directory Replication Service Remote Protocol, conocido también como MS-DRSR o DRSUAPI. Sobre el mecanismo y la mención de MS-DRSR en el contexto de DCSync escriben muchos proveedores e investigadores, por ejemplo NCC Group.
El peligro surge cuando la replicación incluye no solo atributos “normales”, sino datos sensibles. En AD hay secretos que no deben divulgarse a cualquiera, pero los controladores de dominio los necesitan. Por eso los permisos de replicación están estrictamente limitados y, por defecto, solo los sujetos privilegiados del dominio los tienen.
DCSync convierte esos permisos en un “aspirador” universal de credenciales del dominio. Con hashes y claves en su poder, el atacante puede pasar a técnicas como pass-the-hash, golden ticket o afianzarse silenciosamente mediante el cambio de contraseñas y la creación de puertas traseras “permanentes” en AD. Especialmente grave es el robo de la cuenta krbtgt, ya que sustenta la confianza de Kerberos en el dominio.
Otro problema es que DCSync a menudo se ejecuta después de que el atacante consigue una delegación de permisos que no resulta obvia pero sí suficiente. No siempre se trata de un “Domain Admin”. A veces es una cuenta de servicio a la que en su momento se le concedieron permisos para sincronización, migración o integración, y ese “temporal” resultó ser permanente.
Cómo funciona el ataque DCSync a nivel de protocolo y permisos
Técnicamente, DCSync imita el comportamiento de un controlador de dominio e inicia solicitudes de replicación al DC legítimo. En la práctica suelen mencionarse las llamadas de la familia GetNCChanges, porque a través de ellas es posible pedir datos de las particiones del directorio que interesan. Una explicación clara de que DCSync “se hace pasar por un DC y solicita replicación” está, por ejemplo, en ADSecurity.
Para que la solicitud de replicación tenga éxito, el sujeto debe tener los permisos extendidos correspondientes en el dominio. Las principales autorizaciones suelen enumerarse así: Replicating Directory Changes y Replicating Directory Changes All. En los nombres del esquema de AD esto corresponde a DS-Replication-Get-Changes y DS-Replication-Get-Changes-All. La descripción de estos permisos puede consultarse en la documentación de Microsoft sobre objetos del esquema, por ejemplo para DS-Replication-Get-Changes y DS-Replication-Get-Changes-All.
Dicho de forma sencilla, es un permiso de lectura sobre los cambios de replicación. Para extraer secretos y material de hashes normalmente se requiere un conjunto de permisos de mayor nivel, por lo que en investigaciones reales es importante verificar delegaciones no solo en los grupos de administradores, sino también a nivel de ACL del dominio.
En lo instrumental, DCSync suele asociarse con Mimikatz, mediante el comando lsadump::dcsync. Ese comando envía solicitudes de replicación y recibe datos sin necesidad de ejecutar código en el controlador de dominio. Descripciones prácticas de cómo se ve esto desde la perspectiva del atacante están en diversas fuentes, por ejemplo en The Hacker Recipes y en el análisis de Netwrix.
La conclusión principal es simple. DCSync no es “magia”, sino la comprobación de permisos más el uso de un protocolo legítimo. Por eso la protección no debe comenzar por “prohibir el protocolo”, sino por controlar a quién se permite replicar datos sensibles.
Cómo se usa DCSync en los ataques, dónde aparece en la cadena y qué señales deja
DCSync rara vez es el primer paso. Normalmente, antes de su uso el atacante ya ha obtenido acceso a una cuenta de dominio y ha escalado privilegios. A partir de ahí DCSync sirve para acelerar la intrusión: en lugar de buscar contraseñas largo tiempo, se pueden obtener de un golpe los hashes de cuentas clave y pasar a técnicas de autenticación por hashes o tickets de Kerberos.
Un escenario típico es el siguiente. Primero se compromete un puesto de trabajo o servidor. Luego el atacante extrae credenciales, se mueve lateralmente y localiza una cuenta que tiene permisos de replicación. A veces esos permisos pertenecen a servicios de sincronización o a grupos “técnicos” creados para migraciones. A continuación se ejecuta DCSync contra uno de los DC y se solicitan los secretos de los usuarios deseados. Objetivos frecuentes son krbtgt, Administrator y cuentas de servicio privilegiadas.
En los registros esto puede aparecer como solicitudes de replicación inusuales procedentes de un equipo que no es un controlador de dominio. Esta es una idea importante para la detección. La replicación en AD es normal, pero es normal entre DC; cuando un servidor normal empieza a “replicar”, es motivo de alarma. Plataformas como Microsoft Defender for Identity pueden destacar estos sucesos. Microsoft publica materiales de formación que muestran un escenario de sospecha de DCSync y su investigación. Un ejemplo de laboratorio está disponible aquí Microsoft Defender for Identity lab.
Otro aspecto que suele pasarse por alto es que DCSync puede usarse de forma selectiva. Al atacante no le hace falta “volcar todo el dominio”; puede solicitar solo el objeto o los objetos necesarios para reducir el ruido y la probabilidad de detección. Por eso una detección que solo reacciona a extracciones masivas puede fallar ante un ataque cuidadoso.
Finalmente, DCSync es útil para afianzarse. Con las claves apropiadas el atacante puede construir un acceso persistente que sobreviva al cambio de contraseña de usuarios comunes. Por eso la respuesta a un evento DCSync debe tratarse como un incidente a nivel de dominio, no como “otra actividad extraña”.
Cómo protegerse de DCSync y cómo detectarlo
La protección más eficaz es minimizar los permisos de replicación. Es necesario saber quién en el dominio tiene Replicating Directory Changes y Replicating Directory Changes All, y por qué. A partir de ahí hay que aplicar una lógica estricta: si los permisos no son necesarios, se eliminan; si son necesarios, se aíslan y controlan. Microsoft explica cómo conceder Replicating Directory Changes para escenarios concretos, y ese material sirve como guía sobre qué configuraciones afectan. Un ejemplo está en Microsoft Learn.
Un checklist práctico de protección suele incluir varias capas. La primera capa es la auditoría de ACL a nivel de dominio y de los contenedores de configuración. Hace falta revisar regularmente las delegaciones de permisos, incluidas las pertenencias a grupos anidados, porque la concesión “indirecta” de permisos es más frecuente de lo deseable. También conviene limitar qué cuentas de servicio pueden iniciar sesión de forma interactiva y desde qué hosts.
La segunda capa es la arquitectura de privilegios: separación de cuentas administrativas, principio de mínimos privilegios, estaciones administrativas dedicadas, prohibición del uso cotidiano de cuentas privilegiadas. Puede sonar tedioso, pero es exactamente lo que reduce la probabilidad de que los permisos de replicación acaben en manos del atacante “por el camino”.
La tercera capa es detección y respuesta. Hacen falta reglas de monitorización para replicación anómala, especialmente desde hosts que no son DC, y correlación de eventos con actividad de red hacia controladores de dominio por RPC. Es importante contar con un plan de respuesta. Si se confirma una sospecha de DCSync, suele ser necesario considerar el reinicio de secretos del dominio, incluido el cambio de contraseña de krbtgt según la procedura, la revisión de todos los privilegios y la comprobación de la posible compromisión de los controladores de dominio.
La cuarta capa es resistencia frente al “legado”. En dominios reales conviven servicios, conectores y sincronizaciones antiguos, y cada uno tiene su justificación sobre por qué “necesita” replicar. Una buena práctica es inventariar esas dependencias y sustituirlas gradualmente por enfoques más seguros. También es útil preguntarse periódicamente: ¿qué fallaría si ahora mismo quitáramos esos permisos?
Conclusión
DCSync resulta inquietante no por su exotismo, sino por su sencillez. Con los permisos adecuados un atacante puede extraer de Active Directory la información más valiosa sin tocar físicamente el controlador de dominio en el sentido tradicional. Por eso la defensa contra DCSync comienza con disciplina de privilegios y transparencia en los permisos de replicación, y continúa con un monitoreo eficaz de anomalías de replicación y un plan de respuesta listo.
Si un dominio lleva mucho tiempo funcionando, el primer paso más útil es revisar quién tiene DS-Replication-Get-Changes y DS-Replication-Get-Changes-All y por qué. El segundo paso es establecer rutas limpias para administración y tareas de servicio, de modo que los privilegios no se propaguen por la infraestructura. Y el tercer paso es contar con detección capaz de identificar replicación donde no debería existir. En el caso de DCSync conviene pecar de precavido una vez, antes que luego explicar por qué de repente “el dominio ya no es totalmente vuestro”.
