Evento 4662: la pista que delata un ataque DCSync

El evento 4662 de Windows Server queda en el centro de un caso práctico (eso sí, ficticio) que circula desde el 28 de octubre de 2026: un atacante pide a un controlador de dominio que replique el directorio completo sin ser él mismo un DC, y la huella queda grabada en un solo evento de seguridad. El escenario, documentado en un libro japonés de defensa de servidores, muestra cómo se ve un DCSync en los logs antes de que se pierdan todas las contraseñas del dominio.

El evento 4662 es un registro de seguridad de Windows Server que se genera cuando una cuenta accede a un objeto de Active Directory protegido por una SACL, con un AccessMask de 0x100 (Control Access). Cuando ese objeto es el dominio raíz y el GUID de la operación corresponde a una de las extended rights de replicación, el 4662 es la evidencia central de un ataque DCSync, la técnica T1003.006 del framework MITRE ATT&CK.

¿Qué es el evento 4662 y por qué aparece en una réplica de Active Directory?

El 4662 aparece porque Windows registra cada acceso a un objeto con auditoría habilitada, y el dominio raíz puede tener esa auditoría activada sobre permisos específicos. Por defecto, esto está apagado: hace falta prender Audit Directory Services Access dentro de la categoría DS Access y cargar las SACLs correspondientes en el dominio y todos sus objetos descendientes, según detalla la documentación de Splunk Research.

Tres GUIDs son los que importan acá. 1131f6aa corresponde a Replicating Directory Changes, 1131f6ad a Replicating Directory Changes All y 89e95b76 aparece también asociado a permisos de replicación extendida. Ninguno de los tres debería activarse desde una estación de trabajo normal. Si lo hace, alguien está pidiendo los hashes de todo el dominio.

La fuente de Splunk suma otros dos identificadores a la lista de vigilancia: 9923a32a-3607-11d2-b9be-0000f87a36b2 y 1131f6ac-9c07-11d1-f79f-00c04fc2dcd2. El detalle técnico que filtra ruido es el AccessMask: tiene que ser exactamente 0x100, porque ese valor marca Control Access, el tipo de permiso que usa DCSync para replicar.

¿Cómo se ve un ataque DCSync en los logs, paso a paso?

Se ve como una cadena de eventos en hosts distintos que termina en un 4662 sobre el controlador de dominio. El relato del capítulo 23 y el Escenario B del libro arman una línea de tiempo ficticia, pero útil como plantilla de lo que hay que correlacionar en un SIEM real.

Ponele que un atacante ya tiene acceso a una estación de trabajo. Desde ahí toca lsass, salta con pass-the-hash a un file server usando credenciales de Administrator (que normalmente solo loguea vía bastión, no desde una workstation), monta ADMIN$, y poco más de un minuto después el controlador de dominio recibe una conexión SMB seguida del 4662 con el GUID de replicación. Esa secuencia completa, de principio a fin, es la que separa un falso positivo de un incidente real.

Hora	Host	Evento
09:12:40	WS01	Acceso a lsass
09:14:05	FS01	4624 Tipo 3 NTLM, cuenta Administrator, origen WS01
09:14:30	FS01	5140, acceso a ADMIN$
09:15:50	DC01	SMB entrante desde FS01
09:16:20	DC01	4662 con GUID de replicación
09:18:00	WS01	Se corta la ingestión de logs

El corte de ingestión a las 09:18 en WS01 no es un detalle menor. Es la parte que un analista distraído pasa por alto, y es justo la que confirma que no fue un error de sincronización sino alguien tapando huellas.

¿Qué comando de PowerShell detecta el patrón y qué falsos positivos genera?

El filtro que propone el libro busca el 4662 con alguno de los tres GUIDs y excluye a las cuentas de máquina de los propios DCs. El comando, tal como aparece en la fuente, es:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} |
Where-Object { $_.Message -match '1131f6aa|1131f6ad|89e95b76' -and $_.Message -notmatch 'DC0\d\$' }

Ese patrón DC0\d\$ está pensado para nombres tipo DC01$, DC02$. Hay que adaptarlo a la convención real de cada dominio y, antes de usarlo en producción, probarlo en un laboratorio. El propio autor lo aclara: esto no fue testeado en vivo, es documentación con fines de detección.

• Replicación legítima DC a DC: dos controladores de dominio sincronizando entre sí también generan 4662 con estos GUIDs. Hay que excluir las cuentas de máquina de los DCs del filtro.
• Herramientas de sincronización como Azure AD Connect: necesitan permisos de replicación para funcionar. La solución es poner la cuenta de servicio en una lista de excepciones y fijar su IP de origen, no sacar el GUID del monitoreo.
• Promoción genuina de un nuevo DC: la detección de Splunk documenta este mismo falso positivo en su ficha técnica, porque el proceso de dcpromo también dispara 4662 de replicación.

Ejemplo hipotético: adaptar el filtro a un dominio con nomenclatura distinta

Lo que sigue es un ejemplo hipotético, construido para esta nota, y no corresponde a ningún incidente real ni al escenario del libro citado. Supongamos un dominio donde los controladores no se llaman DC01$ o DC02$ sino que siguen una convención tipo SRVAD-NY$ y SRVAD-BA$ (una sede en Nueva York y otra en Buenos Aires). Copiar el filtro -notmatch 'DC0\d\$' tal cual, sin adaptarlo, no excluiría a esas cuentas de máquina: el patrón nunca las va a matchear porque el nombre real no tiene el prefijo “DC”. El resultado sería una alerta falsa positiva en cada ciclo de replicación normal entre esas dos sedes, y el equipo de SOC terminaría silenciando la regla entera por “ruido” — exactamente lo que no hay que hacer. La corrección sería cambiar el patrón a algo como -notmatch 'SRVAD-\w+\$', construido a partir del inventario real de cuentas de máquina de DCs, no de un ejemplo genérico.

Criterios para decidir si un 4662 sospechoso amerita escalar el incidente

No todo 4662 con un GUID de replicación es un ataque, y no conviene escalar cada uno como si lo fuera. A partir de lo que documentan ambas fuentes, estos son los puntos que conviene chequear antes de decidir si se trata de una alerta real:

• ¿El solicitante es una cuenta de máquina de un DC? Si sí, probablemente sea replicación normal. Si es una cuenta de usuario o una cuenta de servicio que no está en la lista blanca de sincronización, subí la prioridad.
• ¿El AccessMask es exactamente 0x100? Si el evento no trae ese valor, no es la operación de Control Access que usa DCSync; puede ser ruido de otro tipo de acceso al objeto.
• ¿Hay un 4624 reciente con el mismo Logon ID desde un origen inusual? La ficha de Splunk correlaciona justamente esto (TargetLogonId) para saber de dónde vino la sesión que terminó pidiendo la replicación.
• ¿La IP de origen está categorizada como domain_controller en tu CMDB o asset inventory? Si no lo está, ese es el filtro final que usa la detección de Splunk antes de generar un finding.
• ¿Hubo un dcpromo legítimo programado en esa ventana? Si el change management no registra ninguno, la promoción “genuina” como excusa queda descartada.

Si las cinco respuestas apuntan a “no hay explicación operativa”, ahí sí corresponde tratarlo como incidente y arrancar la contención, no antes.

¿Por qué hay que resetear el krbtgt dos veces después de un DCSync?

Porque un solo reset no invalida los tickets Kerberos que ya circulan. La cuenta krbtgt firma todos los Ticket Granting Tickets del dominio, y si un atacante logró un DCSync completo, hay que asumir que tiene ese hash y puede forjar Golden Tickets sin límite de tiempo.

El procedimiento que marca la fuente es resetear la contraseña de krbtgt, esperar un tiempo entre ambos cambios y resetearla una segunda vez. En criollo: la primera pasada empieza a invalidar los tickets viejos, pero si no dejás pasar un margen antes del segundo reset, podés dejar una ventana donde un ticket forjado con el hash anterior todavía sirve. Conviene tener este procedimiento escrito y ensayado antes de necesitarlo, porque improvisarlo durante un incidente real, con el reloj corriendo, es donde más se rompen cosas.

¿Qué límites tiene esta detección basada solo en el evento 4662?

El límite principal es que el escenario completo es ficticio. El autor lo aclara en el propio artículo: corre sobre el rango 10.0.0.0/8, los eventos y los comandos de PowerShell salen del libro, no de una prueba en vivo, y el objetivo es solo detección, no un caso real documentado.

Un 4662 aislado no confirma exfiltración. Confirma que alguien pidió un permiso de replicación. Por eso la correlación importa: el 4624 tipo 3 con NTLM, el 5140 sobre ADMIN$, el acceso previo a lsass y el corte de ingestión de logs son las piezas que, juntas, convierten un evento administrativo en evidencia de ataque.

Qué está confirmado y qué no

• Confirmado: el evento 4662 con AccessMask 0x100 y los GUIDs de replicación es la base documentada de la detección de DCSync, según la ficha técnica de Splunk firmada por Dean Luxton.
• Confirmado: la técnica corresponde a T1003.006 de MITRE ATT&CK y Splunk la asocia a actores como Earth Lusca, LAPSUS$, Mustang Panda, Scattered Spider y Storm-0501.
• No confirmado / ficticio: la línea de tiempo con WS01, FS01 y DC01 es un ejercicio narrativo del libro, no un incidente real reportado.
• No confirmado: el comando de PowerShell no fue validado en un entorno de producción por el autor, solo documentado para fines educativos.

Errores comunes al implementar esta detección

• No habilitar la auditoría antes de necesitarla: muchos equipos descubren que “Audit Directory Services Access” estaba apagada justo cuando ya pasó el incidente. Hay que activarla y cargar las SACLs con anticipación, no después.
• Filtrar solo por GUID sin revisar el AccessMask: si el filtro no exige 0x100, el volumen de ruido hace inútil la alerta en cualquier dominio con tráfico normal.
• Dejar el patrón de exclusión de DCs hardcodeado: copiar DC0\d\$ tal cual de un ejemplo y no adaptarlo a la convención de nombres real genera falsos negativos silenciosos (el ejemplo hipotético de más arriba es justamente este error).
• Resetear krbtgt una sola vez: pensar que un reset alcanza deja tickets viejos vigentes y la sensación de haber resuelto algo que en realidad sigue abierto.

Preguntas Frecuentes

¿Qué es el evento 4662 en Windows Server?

Es un registro de seguridad que se genera cuando una cuenta accede a un objeto de Active Directory con auditoría SACL habilitada, usando un AccessMask específico. Cuando el objeto es el dominio y el GUID corresponde a permisos de replicación, el 4662 es la señal clave de un posible DCSync.

¿Cómo detecto un ataque DCSync en los logs de seguridad?

Buscando el evento 4662 con los GUIDs 1131f6aa, 1131f6ad o 89e95b76 y AccessMask 0x100, solicitado por una cuenta que no sea un controlador de dominio. La detección publicada por Splunk Research filtra además por categoría de activo distinta a “domain_controller”.

¿Por qué el evento 4662 aparece cuando no es un controlador de dominio el que pide la replicación?

Porque DCSync no necesita ser ejecutado desde un DC: solo hace falta una cuenta con los permisos de replicación suficientes, algo que un atacante puede conseguir escalando privilegios. Esa es justamente la condición que convierte un 4662 normal en una alerta de ataque.

¿Cuántas veces hay que resetear el krbtgt después de un DCSync?

Dos veces, con una espera entre ambos resets. Un solo cambio no invalida los tickets Kerberos que ya fueron emitidos o forjados con el hash expuesto.

¿Qué falsos positivos genera la detección de DCSync por evento 4662?

Los tres más documentados son la replicación legítima entre controladores de dominio, herramientas de sincronización como Azure AD Connect y la promoción genuina de un nuevo DC. Los tres se resuelven con listas de exclusión bien mantenidas, no apagando la detección.

Conclusión

El valor real de este caso, aunque sea ficticio, está en la plantilla de correlación: un 4662 solo no alcanza, pero cruzado con un 4624 NTLM sospechoso, un 5140 sobre ADMIN$ y un corte de logs, sí cuenta una historia completa. Si todavía no tenés habilitada la auditoría de Directory Services Access en tu dominio, ese es el primer paso antes de copiar cualquier query. Lo segundo es tener el plan de reset de krbtgt escrito y probado, porque improvisarlo en medio de un incidente real sale caro.

Fuentes