Supervision Seguridad AD: Event IDs y SIEM

¿Qué es la supervisión de Active Directory?

La supervisión de Active Directory es la combinación de política de auditoría, recopilación de eventos, correlación y análisis de líneas base necesaria para detectar ataques de identidad contra los controladores de dominio y las cuentas privilegiadas. Muchos entornos AD generan eventos de Windows Security, pero muchos menos generan los eventos correctos y los enrutan hacia detecciones que un analista pueda realmente utilizar.

La supervisión en AD no es solo retención de logs. Es la disciplina de elegir las subcategorías que importan, demostrar que los eventos están presentes en los controladores de dominio y construir detecciones en torno al comportamiento del atacante en lugar del volumen bruto.

Un programa útil de supervisión de AD comienza con las rutas de ataque que los defensores realmente necesitan ver: abuso de tickets Kerberos, DCSync, cambios en grupos privilegiados, escrituras en objetos del directorio, autenticación NTLM, emisión de certificados y movimiento lateral hacia servidores sensibles.

Cómo funciona la supervisión de Active Directory

La auditoría de seguridad de Windows se controla mediante la Política de Auditoría Avanzada y solo produce datos útiles si se habilitan las subcategorías correctas.

Un pipeline de supervisión práctico se ve así:

1. La Política de Auditoría Avanzada habilita los eventos que necesita
2. El registro de eventos de Windows almacena localmente los eventos de Security
3. WEF o un agente reenvía los eventos a una plataforma central
4. La correlación del SIEM convierte esos eventos en detecciones e investigaciones

El fallo más común sigue siendo el primer paso: el colector y el SIEM existen, pero las subcategorías AD clave nunca se habilitaron en los controladores de dominio que importan.

La documentación de Microsoft Defender for Identity refuerza este punto al listar los eventos de Windows requeridos para los sensores y la infraestructura relacionada. La lista incluye eventos de identidad esenciales como 4662, 4728, 4732, 4756 y 4776. Si sus controladores de dominio no generan y reenvían esos eventos, la lógica de detección posterior no puede recuperar la evidencia faltante.

La cadena de ataque sin supervisión

DCSync - Sin auditoría de acceso al servicio de directorio

Sin Audit Directory Service Access, el evento 4662 no ofrece a los defensores la visibilidad esperada frente al abuso de derechos de replicación. El evento 4662 se genera cuando se realiza una operación sobre un objeto de Active Directory, pero la auditoría de objetos y la configuración de la SACL siguen siendo determinantes para una cobertura útil.

Kerberoasting - Sin visibilidad de tickets Kerberos

Sin la recopilación y revisión de 4769, las solicitudes inusuales de tickets de servicio se mezclan con el tráfico normal y las solicitudes con cifrado RC4 son fáciles de pasar por alto. Microsoft documenta el evento 4769 como un evento de solicitud TGS generado en los controladores de dominio. Las actualizaciones más recientes de Windows exponen campos Kerberos adicionales, lo que puede mejorar la investigación cuando están disponibles.

Abuso de grupo privilegiado - Sin alertas de cambios de membresía

Sin cobertura para 4728, 4732 y 4756, un atacante puede añadir una cuenta backdoor a un grupo privilegiado y confiar en que los administradores solo lo notarán después de los hechos. Estos eventos corresponden a cambios de membresía en grupos de seguridad globales, locales y universales.

Abuso de delegación o GPO - Sin visibilidad de cambios

Sin 5136 y la auditoría de cambios relacionada, las modificaciones de directorio de alto impacto pueden ocurrir con muy poco contexto para la investigación. El evento 5136 se genera cuando se modifica un objeto del servicio de directorio, y resulta más útil cuando se combina con el atributo modificado y el contexto del objeto.

Detección

Configuración esencial de la política de auditoría

Implementar mediante GPO: Configuración del Equipo > Configuración de Windows > Configuración de Seguridad > Configuración de la Política de Auditoría Avanzada

Referencia de Event ID críticos

Consultas de detección SIEM (Elastic KQL)

Detección de DCSync:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")

Detección de Kerberoasting:

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

Cambio de grupo privilegiado:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")

Consejo: empiece con un conjunto reducido de detecciones de alta confianza que el equipo realmente vaya a investigar. DCSync, los cambios de grupos privilegiados y el abuso de tickets de servicio suelen aportar mucho más valor que un conjunto amplio de reglas sin mantenimiento.

Mapeo de campos y validación del parser

Antes de escribir lógica de detección compleja, valide el mapeo de campos de su SIEM. El mismo evento de Windows puede llegar con nombres de campo distintos según el conector, el agente o la capa de normalización. Para cada detección crítica, confirme que:

• el Event ID se analiza de forma consistente
• los campos de cuenta separan las cuentas de usuario, dominio y equipo
• se conservan los campos de estación de origen y dirección del cliente
• los campos de cifrado de ticket están presentes para las detecciones Kerberos
• se conservan los campos de objeto y atributo de directorio para 4662 y 5136
• se conservan los campos de solicitud y plantilla de certificado para los eventos de AD CS

Una regla que funciona en laboratorio pero pierde el campo crítico en producción no es cobertura real.

Remediación

Acción rápida: habilite Directory Service Access, Directory Service Changes y las subcategorías de Kerberos en todos los controladores de dominio antes de ajustar cualquier otra cosa.

1. Implementar la política de auditoría avanzada mediante GPO

auditpol /get /category:*

auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

2. Aumentar la capacidad del registro Security

El tamaño predeterminado del registro Security suele ser insuficiente para controladores de dominio con mucha actividad.

wevtutil sl Security /ms:1073741824 /rt:false /ab:true

La capacidad del registro debe dimensionarse según el volumen real de eventos. Los dominios con mucha actividad Kerberos y los DC muy cargados pueden sobrescribir la evidencia rápidamente si los registros Security se quedan en los valores predeterminados, demasiado pequeños.

3. Reenviar centralmente los eventos de los controladores de dominio

winrm quickconfig
wecutil cs subscription.xml
gpupdate /force

El reenvío debe preservar el XML del evento o los campos normalizados necesarios para la detección. Si su colector descarta Properties, ObjectDN, TicketEncryptionType o los campos de estación de origen, las reglas de alto valor se degradan a alertas genéricas.

4. Establecer líneas base antes de ajustar umbrales

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
    Group-Object {$_.TimeCreated.Hour} |
    Select-Object Name, Count |
    Sort-Object Name

Use esas líneas base para entender el volumen normal de tráfico Kerberos y de inicio de sesión antes de introducir umbrales de anomalías.

5. Vincular las detecciones a las rutas de ataque

No supervise los Event ID de forma aislada. Vincule cada detección con la ruta de ataque que respalda:

• DCSync necesita los eventos de derechos de replicación y los cambios de directorio privilegiados
• Kerberoasting necesita visibilidad de tickets de servicio, contexto de cifrado e inventario de cuentas de servicio
• el abuso de delegación necesita visibilidad de cambios de atributos y autenticación inusual de cuentas de equipo
• el relay NTLM necesita validación NTLM, inicios de sesión objetivo y acciones posteriores específicas del servicio
• el abuso de AD CS necesita contexto de solicitud, emisión y plantilla de certificado

Este mapeo evita que el programa de supervisión se convierta en una lista de eventos desconectados.

Cómo lo detecta EtcSec

EtcSec verifica la cobertura de política de auditoría que los defensores necesitan para investigar las principales rutas de ataque de AD reveladas en otras partes del informe.

Los hallazgos relacionados con la supervisión destacan subcategorías de auditoría faltantes, retención insuficiente y otras brechas que dejarían invisible o difícil de reconstruir un abuso de identidad de alto valor.

Detecciones a implementar primero

Si el equipo de supervisión solo puede desplegar unas pocas reglas de alto valor inicialmente, empiece por los ataques que son a la vez comunes y operativamente revisables:

• abuso de derechos de replicación e intentos de DCSync
• cambios de membresía en grupos privilegiados
• solicitudes sospechosas de tickets de servicio asociadas con Kerberoasting
• cambios de objetos de directorio de alto impacto, como escrituras de GPO o delegación
• actividad de emisión de certificados para entornos con ADCS habilitado
• patrones de validación NTLM e inicio de sesión de red para investigaciones de relay o movimiento lateral

Estas detecciones crean una base útil sin inundar a los analistas con alertas de baja calidad.

Revisión de retención y cobertura

La supervisión de Active Directory también debe incluir una revisión de retención. Un controlador de dominio puede producir grandes volúmenes de eventos de Kerberos, inicio de sesión y gestión de cuentas, y un registro Security local pequeño puede sobrescribir exactamente la evidencia necesaria durante la respuesta a incidentes. Revise juntos el tamaño máximo del registro Security, la latencia de reenvío, los fallos de ingesta del SIEM y la retención en almacenamiento activo. Si el SIEM conserva 90 días de datos consultables, pero el colector descarta silenciosamente Event ID de alto volumen durante los periodos de mucha actividad, la política de retención aparente no es la cobertura de investigación real.

Para la evidencia Tier-0, defina qué eventos deben permanecer consultables durante toda la ventana de respuesta. Los cambios de grupos privilegiados, las modificaciones de objetos de directorio, la emisión de certificados, el acceso a objetos relevante para DCSync y los eventos Kerberos de alto valor no deben tratarse como telemetría de depuración descartable. Son la evidencia que permite a los defensores reconstruir qué cambió, quién lo cambió, y si la misma ruta se reutilizó después de la remediación.

Validación después de los cambios de política de auditoría

Después de cambiar la política de auditoría, confirme que la cadena de supervisión funciona de extremo a extremo:

• verifique que los eventos esperados aparecen en los controladores de dominio dentro del alcance
• confirme que esos mismos eventos llegan a su colector o SIEM sin retrasos excesivos ni pérdidas silenciosas
• pruebe al menos una acción administrativa controlada y una acción Kerberos benigna para validar el análisis y el mapeo de campos
• revise la retención para asegurarse de que la evidencia crítica sigue presente cuando los investigadores la necesiten
• confirme que 4662 y 5136 incluyen el contexto de objeto y atributo necesario para las investigaciones de directorio
• confirme que 4769 incluye la información de cifrado y servicio necesaria para las investigaciones Kerberos
• confirme que los eventos de AD CS están presentes si existen servicios de certificación en el entorno

Controles relacionados

Este artículo se complementa de forma natural con Seguridad de Contraseñas AD: Malas Configuraciones que Siguen Abriendo el Dominio, Ataques NTLM Relay: Detección y Prevención, Malas Configuraciones GPO como Vector de Ataque, Cuentas Obsoletas y Sobreprivilegiadas: El Riesgo Oculto en Active Directory, y Delegación Kerberos: No Restringida, Restringida y RBCD. Una buena supervisión es lo que permite a los equipos demostrar que esos problemas se corrigieron y detectar si reaparecen.

Referencias principales

• Descripción general de la recopilación de eventos de Defender for Identity
• Configurar la auditoría de eventos de Windows para Defender for Identity
• 4662: se realizó una operación sobre un objeto
• 4769: se solicitó un ticket de servicio Kerberos
• 5136: se modificó un objeto del servicio de directorio
• Auditoría de la administración de grupos de seguridad