Ataque DCShadow: Controlador de Dominio Rebelde

La técnica de ataque DCShadow controlador de dominio rebelde (registro de un controlador de dominio rebelde) — revelada públicamente por Benjamin Delpy y Vincent Le Toux (creadores de Mimikatz) en BlueHat IL en enero de 2018 — permite a un atacante con privilegios suficientes registrar temporalmente una máquina comprometida como controlador de dominio y enviar cambios de objetos de Active Directory al resto del dominio a través del protocolo de replicación normal, en lugar de a través de una API de escritura estándar. MITRE ATT&CK la cataloga como T1207 — Rogue Domain Controller.

Este artículo cubre el mecanismo, por qué evade el registro de logs que normalmente detecta los cambios privilegiados en AD, y pasos concretos de detección y remediación. Para la técnica de abuso de replicación más común — leer secretos en lugar de escribir cambios — consulta Abuso de ACL y DCSync: Los Caminos Silenciosos hacia Domain Admin y Supervisión de Seguridad AD: Event IDs que Importan para la base de auditoría de replicación más amplia que esta técnica está diseñada para eludir.

El Ataque DCShadow Controlador de Dominio Rebelde Explicado

Todo controlador de dominio de Active Directory está representado en el propio directorio: un objeto server y un objeto nTDSDSA hijo bajo el contexto de nomenclatura Configuration (CN=Sites), la misma clase de objetos que se crea cada vez que se promueve un DC real. DCShadow abusa del hecho de que cualquier principal que posea los permisos de replicación adecuados puede crear ese mismo par de objetos en una máquina que en realidad no es un controlador de dominio — y luego usar el protocolo RPC legítimo Directory Replication Service (DRS) para que el resto del dominio extraiga "cambios" desde esa máquina como si fuera un par de confianza.

⚠️

⚠️ Advertencia: como el cambio llega mediante replicación en lugar de escrituras LDAP o el registro Security local de un DC, DCShadow no genera los eventos en los que los equipos de seguridad normalmente confían para detectar una manipulación privilegiada de AD — no hay 4738 (cuenta de usuario modificada), ni 5136 (objeto del servicio de directorio modificado) vinculado al cambio en sí.

DCShadow es distinto de DCSync. DCSync (DS-Replication-Get-Changes) abusa de los derechos de replicación para leer secretos — casi siempre para volcar hashes de contraseñas desde la perspectiva de un DC legítimo. DCShadow abusa de un conjunto distinto, aunque adyacente, de derechos de replicación para escribir — fabrica una fuente de replicación rebelde e inyecta cambios en el directorio. Ambas técnicas se confunden con frecuencia porque comparten la misma familia de protocolo subyacente (MS-DRSR) y la misma pregunta de auditoría de "quién tiene derechos cercanos a DCSync", pero son primitivas de ataque distintas con superficies de detección distintas.

Cómo Funciona

Paso 1 — Adquirir los Derechos

Según una investigación independiente sobre permisos mínimos publicada por Lab of a Penetration Tester en abril de 2018, DCShadow no exige estrictamente pertenecer a Domain Admin o Enterprise Admin — ese es el camino habitual, pero la técnica también puede funcionar con un conjunto más reducido de permisos concedidos directamente sobre el objeto de dominio: los derechos extendidos DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, según la referencia ADSchema de Microsoft), DS-Replication-Manage-Topology, y DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, según la referencia ADSchema de Microsoft) — más suficiente WriteProperty sobre el propio objeto de equipo de la máquina atacante (ver Superficie de ataque de los objetos de equipo en Active Directory para la clase de riesgo más amplia) para establecer sus Service Principal Names. Por eso el catálogo de EtcSec rastrea quién posee los derechos de Server Trust Account como un hallazgo distinto y crítico: es la precondición que hace posible registrar un DC rebelde en primer lugar, independientemente de si esa cuenta también es Domain Admin.

Paso 2 — Registrar el DC Rebelde

Mediante el módulo lsadump::dcshadow, Mimikatz (ejecutándose con privilegios SYSTEM en la máquina atacante) establece dos Service Principal Names en la cuenta de equipo comprometida, y luego crea los objetos server y nTDSDSA en la partición Configuration. Según la estrategia de detección DET0276 de MITRE, los SPN usados son el SPN de Global Catalog (GC/<hostname>/<domain>) y el SPN de la interfaz Directory Replication Service (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) — las mismas clases de SPN que porta un DC legítimo, que es precisamente lo que permite a la máquina hacerse pasar por uno a efectos de replicación.

Paso 3 — Enviar el Cambio

Con el DC rebelde registrado y los SPN configurados, un segundo comando lsadump::dcshadow /push dispara un evento de replicación saliente: el cambio fabricado de objeto o atributo (una reescritura de ACL, una membresía de grupo, un msDS-KeyCredentialLink, un atributo de esquema — DCShadow puede apuntar a prácticamente cualquier dato de AD con permiso de escritura) se replica desde la máquina del atacante a un DC real mediante IDL_DRSReplicaAdd/GetNCChanges, exactamente como si viniera de un DC par.

Paso 4 — Darse de Baja y Desaparecer

El atacante elimina los objetos server y nTDSDSA rebeldes, restaura los SPN originales, y la máquina vuelve a parecer un equipo unido al dominio ordinario. El cambio malicioso, sin embargo, ya se ha replicado a todos los DC reales del dominio y persiste en el directorio.

Detección

Los pasos de registro y baja son la ventana detectable — el cambio enviado en sí, una vez replicado, se ve como cualquier otro atributo del directorio.

Indicador	Event ID	Fuente	Descripción
Contexto de nomenclatura de origen de réplica establecido	4928	DC — subcategoría "Audit Detailed Directory Service Replication"	Según la referencia de eventos de Microsoft, se dispara cuando un DC comienza a tratar una fuente como socio de replicación. En un DC legítimo esto se corresponde con promociones conocidas; un Source DRA inesperado es la señal a vigilar.
Contexto de nomenclatura de origen de réplica eliminado	4929	DC — misma subcategoría	Según la referencia de eventos de Microsoft, se dispara al darse de baja — el paso de limpieza de DCShadow. Un par 4928/4929 muy próximo en el tiempo, desde un host que no es un DC conocido, es una señal fuerte.
Cuenta de equipo modificada	4742	DC — "Audit Computer Account Management"	Según la referencia de eventos de Microsoft, se dispara cuando se establecen los SPN de la máquina atacante. Cruza el Subject (la cuenta que realiza el cambio) con tu lista conocida de titulares de Domain Admin / Server Trust Account.
Creación de objeto nTDSDSA / server en el NC Configuration	—	Directory Service Changes (5137), requiere una SACL en `CN=Sites,CN=Configuration`	Active Directory no audita la partición Configuration por defecto. Se necesita una SACL en el contenedor Sites antes de que exista esta señal — esto corresponde directamente a correlacionar "objetos nTDSDSA/server inesperados" según la guía DET0276 de MITRE.
Uso inesperado de SPN de DRS	—	Correlación de autenticación Kerberos / SIEM	Según MITRE DET0276, autenticación Kerberos usando las clases de SPN `GC/` o `E3514235-4B06-11D1-AB04-00C04FC2DCD2` desde un host fuera de la lista de DC conocidos.

💡

💡 Consejo: ninguna de las señales de la partición Configuration anteriores se captura por defecto. Si tu única visibilidad sobre la replicación es la política de auditoría por defecto del NC de dominio, no verás un registro de DC rebelde DCShadow. Esa es exactamente la brecha que la técnica está diseñada para explotar — el análisis externo (análisis de SentinelOne) recomienda tratar el par 4928/4929 y las SACL del NC Configuration como la base, no como un añadido opcional.

Remediación

1. Auditar Quién Tiene los Derechos de Server Trust Account y Replicación-Escritura

La precondición de un ataque DCShadow es un principal con DS-Install-Replica, DS-Replication-Manage-Topology, y DS-Replication-Synchronize sobre el objeto de dominio — o permisos más amplios para establecer los SPN de una cuenta de equipo. Enuméralo de la misma manera en que auditarías las cuentas capaces de DCSync, pero para los derechos extendidos del lado de escritura:

# Enumerar principals no estándar con derechos extendidos de replicación sobre el objeto de dominio
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Cruza cada resultado con tu membresía esperada de Domain Admin / Enterprise Admin — cualquier otra cosa es un permiso no documentado que hay que investigar.

2. Habilitar la Auditoría de la Partición Configuration

Los cambios del NC Configuration no se auditan por defecto. Aplica una SACL a CN=Sites,CN=Configuration,DC=<domain> (e idealmente a la raíz del NC Configuration) para que la creación/eliminación de objetos nTDSDSA y server genere eventos Directory Service Changes (5136/5137), y habilita la subcategoría "Audit Detailed Directory Service Replication" en todo el dominio para que se capturen 4928/4929.

3. Minimizar y Segmentar los Accesos Privilegiados

💡

💡 Quick Win: trata "quién puede registrarse como DC" como una cuestión de Tier 0, no solo como "quién es Domain Admin".

Sigue un modelo de administración por niveles — ver Endurecimiento de Active Directory: Prioridades — para que las cuentas capaces de tener derechos de replicación-escritura sean el mismo conjunto pequeño y supervisado que ya tratas como Tier 0, sin membresía permanente más allá de lo que se necesita activamente. Es la misma disciplina que evita la deriva de acceso privilegiado de forma más amplia.

4. Alertar sobre el Par 4928/4929 Correlacionado con DC Conocidos

Construye una regla de detección que marque cualquier 4928 (y su 4929 asociado) cuyo Source DRA no coincida con tu inventario mantenido de controladores de dominio legítimos. Como una ventana de registro DCShadow suele ser breve, el reenvío de logs casi en tiempo real importa aquí más que en la mayoría de las detecciones de AD — una revisión diaria por lotes normalmente se ejecutará después de que el DC rebelde ya se haya dado de baja.

Cómo Detecta Esto EtcSec

El catálogo de vulnerabilidades de AD de EtcSec señala esta exposición mediante dos comprobaciones: DCSHADOW_EVIDENCE, que busca evidencia directa de que ha ocurrido un registro de DC rebelde DCShadow, y SERVER_TRUST_ACCOUNT_RIGHT, que marca las cuentas y grupos que poseen los derechos para establecer una server trust account — la precondición que hace viable la técnica, sea o no esa cuenta también Domain Admin. Los entornos que ya han revisado sus cuentas capaces de DCSync deberían tratar esto como la auditoría complementaria: los derechos de replicación de lectura y escritura suelen concederse por los mismos errores de delegación, pero rara vez se revisan juntos.

ℹ️

ℹ️ Nota: EtcSec comprueba automáticamente la evidencia de DCShadow y los derechos de Server Trust Account en cada auditoría de AD. Ejecuta una auditoría gratuita para verificar si tu entorno tiene esta exposición.

Ataque DCShadow Controlador de Dominio Rebelde: Cómo Elude la Auditoría de Cambios en AD