Auditoría de Active Directory y Event IDs

Aviso ético: el contenido de este módulo se proporciona con fines exclusivamente educativos, dentro de un itinerario de formación en monitorización y defensa (blue team / SOC) de entornos Active Directory. Todos los comandos de auditpol, PowerShell y configuración de Windows Event Forwarding (WEF) deben ejecutarse únicamente en laboratorios propios o en entornos de producción para los que dispongas de autorización explícita por escrito. Habilitar auditoría avanzada sin dimensionar el almacenamiento de logs, sin capacidad de análisis y sin un SIEM que los centralice puede saturar discos, degradar el rendimiento de un controlador de dominio (DC) o generar una falsa sensación de seguridad («lo audito pero nadie lo mira»). La responsabilidad legal y operativa de cualquier cambio de configuración de auditoría en sistemas de terceros recae por completo en quien lo ejecuta.

Qué aprenderás

Por qué la auditoría «por defecto» de Windows es insuficiente y qué diferencia hay entre la política de auditoría clásica (9 categorías) y la auditoría avanzada (53 subcategorías), incluyendo el flag SCENoApplyLegacyAuditPolicy.
Qué subcategorías de auditoría avanzada hay que habilitar en los controladores de dominio para tener visibilidad real: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Logon/Logoff, Account Management, Directory Service Access/Changes y Process Creation con línea de comandos.
El significado operativo de los Event IDs críticos de AD: 4624/4625/4634/4648 (logons), 4672 (privilegios especiales), 4768/4769/4771 (Kerberos AS-REQ/TGS-REQ/preauth fallida), 4776 (validación NTLM), 4720/4722/4725/4726 (ciclo de vida de cuentas), 4728/4732/4756 (adición a grupos privilegiados), 4738 (cambio de cuenta), 5136/5137/5141 (cambios en objetos del directorio), 4662 (acceso a objeto — clave para detectar DCSync), 4713/4739 (cambios de política Kerberos/dominio), 1102 (borrado del log de seguridad) y 4674.
Cómo auditar cambios en objetos sensibles de AD mediante SACL en OUs (Tier 0, Domain Admins, GPOs críticas).
Por qué centralizar con Windows Event Forwarding (WEF) hacia un colector y, desde ahí, hacia un SIEM, en lugar de confiar en los logs locales del DC.
Cómo montar un laboratorio mínimo para habilitar la auditoría avanzada y confirmar que se generan eventos 4769 y 4662 reales.

Desarrollo

1. El problema de partida: auditoría insuficiente por defecto

Un Windows Server 2003 recién instalado prácticamente no auditaba nada relevante para seguridad: la política de auditoría clásica (Local Security Policy → Local Policies → Audit Policy) tenía 9 categorías muy amplias — «Audit account logon events», «Audit logon events», «Audit account management», etc. — y en la mayoría de despliegues se dejaban en «No Auditing» o, como mucho, se activaba «Success» sin «Failure». El resultado era que, ante un incidente, el equipo forense se encontraba con un log de seguridad vacío o con ruido genérico sin capacidad de diferenciar, por ejemplo, un logon interactivo normal de un logon de red con un ticket Kerberos forjado.

Windows Server 2008 introdujo la auditoría de directivas de seguridad avanzada (Advanced Audit Policy Configuration), que descompone esas 9 categorías clásicas en 53 subcategorías mucho más granulares, distribuidas en 10 categorías: Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use, System y Global Object Access Auditing. Esto permite, por ejemplo, auditar específicamente «Kerberos Service Ticket Operations» sin generar el volumen de ruido que produciría auditar todo «Account Logon» en bloque.

El problema es que ambos sistemas — clásico y avanzado — pueden convivir y entrar en conflicto. Si configuras subcategorías avanzadas por GPO pero el sistema sigue aplicando también la política clásica, Windows puede sobrescribir tu configuración avanzada con la clásica en el próximo refresco de directiva. Para evitarlo existe el flag de registro:

SCENoApplyLegacyAuditPolicy

Se encuentra en HKLMSYSTEMCurrentControlSetControlLsa como valor DWORD. Cuando está a 1, fuerza a que solo se aplique la política de auditoría avanzada y se ignore la clásica, evitando el conflicto. Microsoft recomienda habilitarlo siempre que se despliegue auditoría avanzada por GPO. La propia consola de gestión de directivas de grupo (GPMC) muestra un aviso al respecto en Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration: «Note: Security policy setting and advanced security policy settings are incompatible and cannot be applied together». Por GPO, esa opción corresponde a:

Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options >
"Audit: Force audit policy subcategory settings (Windows Vista or later)
 to override audit policy category settings" = Enabled

Esta GPO, al habilitarse, escribe precisamente ese valor SCENoApplyLegacyAuditPolicy = 1 en el registro de cada equipo afectado.

2. auditpol: la herramienta para consultar y configurar auditoría avanzada

auditpol.exe es el binario nativo de Windows para leer y modificar la política de auditoría avanzada tanto local como, combinado con GPO, a nivel de dominio. Para ver el estado actual de todas las subcategorías:

auditpol /get /category:*

Para ver una categoría concreta:

auditpol /get /category:"Account Logon"
auditpol /get /category:"DS Access"

Y para habilitar una subcategoría específica con éxito y fallo:

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

Aunque auditpol permite configuración local inmediata (útil para pruebas en laboratorio), en producción la configuración de auditoría avanzada se despliega siempre por GPO vinculada a la OU de Domain Controllers, para que sea consistente, se reaplique en cada refresco y quede documentada como configuración de dominio, no como ajuste manual en una máquina.

3. Subcategorías clave a habilitar en los DCs

No conviene activar las 53 subcategorías indiscriminadamente: algunas (como «File System» dentro de Object Access sin SACLs específicas) generan volumen sin valor si no se combinan con auditoría de objetos concretos. Para monitorización de AD, el conjunto mínimo recomendado —alineado con las guías de Microsoft («Audit Policy Recommendations») y con la práctica de ADSecurity/SANS— es el siguiente, aplicado mediante GPO a la OU de Domain Controllers:

# Account Logon
auditpol /set /subcategory:"Credential Validation" /success:enable /failure: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:"Other Account Logon Events" /success:enable /failure:enable

# Logon/Logoff
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable

# Account Management
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Distribution Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Other Account Management Events" /success:enable /failure:enable

# DS Access (fundamental en un DC)
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

# Detailed Tracking (línea de comandos en creación de procesos)
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

# Policy Change (Kerberos, políticas de auditoría, política de dominio)
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable

# Privilege Use
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable

# System
auditpol /set /subcategory:"Security State Change" /success:enable /failure:enable
auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable

La subcategoría Process Creation por sí sola solo registra la creación del proceso (evento 4688); para obtener la línea de comandos completa (imprescindible para ver qué se ejecutó, no solo qué binario) hace falta además habilitar la GPO complementaria:

Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation >
"Include command line in process creation events" = Enabled

Esto añade el campo Process Command Line al evento 4688, algo crítico para detectar, por ejemplo, uso de ntdsutil, vssadmin, reg save sobre el registro de un DC (extracción de hashes) o ejecución de herramientas de post-explotación tipo Mimikatz o Rubeus con sus parámetros.

Las subcategorías Directory Service Access (evento 4662) y Directory Service Changes (eventos 5136/5137/5139/5141) solo producen eventos si, además, se configuran SACLs (System Access Control Lists) sobre los objetos concretos que se quieren auditar — ver sección 6. Habilitar la subcategoría sin SACL no genera ningún evento.

4. Event IDs críticos de AD: tabla de referencia

Event ID	Qué significa	Por qué vigilarlo en AD
4624	Inicio de sesión (logon) correcto. Incluye tipo de logon (2 interactivo, 3 red, 10 RDP, etc.), cuenta, IP origen y proceso de autenticación (NTLM o Kerberos).	Base de toda detección de movimiento lateral y uso de credenciales. Un 4624 tipo 3 (red) desde una IP inusual hacia un DC, o un tipo 10 (RDP) fuera de horario a una cuenta privilegiada, es señal de alerta.
4625	Fallo de inicio de sesión. Incluye el motivo (contraseña incorrecta, cuenta bloqueada, cuenta deshabilitada, fuera de horario permitido…).	Ráfagas de 4625 contra múltiples cuentas desde el mismo origen son la firma clásica de password spraying; ráfagas contra una sola cuenta, de fuerza bruta/credential stuffing.
4634	Cierre de sesión (logoff).	Permite correlacionar duración real de la sesión con el 4624 asociado (mismo Logon ID) y detectar sesiones anómalamente largas o logoffs que nunca llegan (posible persistencia).
4648	Intento de logon con credenciales explícitas (distintas a las de la sesión actual). Típico de `runas`, tareas programadas con credenciales guardadas o herramientas de movimiento lateral tipo PsExec/WMI con credenciales alternativas.	Muy usado para detectar «pass the credential» y uso de cuentas de servicio o admin desde estaciones que no deberían tenerlas. Es uno de los eventos más citados en cadenas de detección de movimiento lateral.
4672	Se han asignado privilegios especiales a un nuevo logon (p. ej. `SeDebugPrivilege`, `SeBackupPrivilege`, pertenencia a Domain Admins).	Indica que la cuenta que ha iniciado sesión tiene privilegios elevados. Correlacionado con el 4624 del mismo Logon ID, permite ver exactamente cuándo y desde dónde se autentica un admin de dominio.
4768	Se ha solicitado un Ticket Granting Ticket (TGT) Kerberos — AS-REQ/AS-REP.	Primer evento de toda autenticación Kerberos. Un pico de 4768 con Result Code `0x6` (usuario no existe) o `0x12` (cuenta deshabilitada/bloqueada) contra muchas cuentas es enumeración de usuarios vía Kerberos (p. ej. Kerbrute).
4769	Se ha solicitado un ticket de servicio Kerberos (TGS-REQ), es decir, acceso a un SPN concreto.	Clave para detectar Kerberoasting: solicitudes masivas de TGS con tipo de cifrado RC4 (`0x17`) hacia múltiples SPN de cuentas de servicio en un intervalo corto son la firma característica del ataque.
4771	Fallo de preautenticación Kerberos (Kerberos pre-authentication failed).	Equivalente a un 4625 pero en el mundo Kerberos. Ráfagas contra distintas cuentas indican password spraying vía Kerberos; combinado con Result Code `0x18` (contraseña incorrecta) es fuerza bruta directa.
4776	El controlador de dominio ha intentado validar credenciales de una cuenta (validación NTLM).	Aparece cuando se usa NTLM en lugar de Kerberos. Volumen alto e inesperado de 4776 en un entorno que debería ser «Kerberos-only» indica posible downgrade a NTLM (relevante para ataques de relay) o aplicaciones legacy mal configuradas.
4720	Se ha creado una cuenta de usuario.	Creación de cuentas fuera del proceso habitual de altas (fuera de horario, por un operador que normalmente no gestiona usuarios, con nombres sospechosos) es indicador de persistencia.
4722	Se ha habilitado una cuenta de usuario.	La reactivación de una cuenta deshabilitada (ex-empleado, cuenta de servicio obsoleta) sin ticket de cambio asociado es una técnica de persistencia habitual.
4725	Se ha deshabilitado una cuenta de usuario.	Útil para detectar sabotaje (deshabilitar cuentas de administradores legítimos) o para confirmar que el proceso de baja de empleados se ejecuta correctamente.
4726	Se ha eliminado una cuenta de usuario.	Borrado de cuentas puede usarse para cubrir huellas tras crear y usar una cuenta temporal. Correlacionar 4720 + uso + 4726 en ventana corta es un patrón de «cuenta usar y tirar».
4728	Se ha añadido un miembro a un grupo global con seguridad habilitada.	Si el grupo es sensible (p. ej. un grupo global de administración delegada), la adición inesperada de un miembro es escalado de privilegios.
4732	Se ha añadido un miembro a un grupo local con seguridad habilitada.	Especialmente crítico cuando el grupo local es Administrators en un DC o servidor sensible: es prácticamente sinónimo de compromiso si no está en el cambio previsto.
4756	Se ha añadido un miembro a un grupo universal con seguridad habilitada.	Los grupos privilegiados de AD (Domain Admins, Enterprise Admins, Schema Admins) suelen ser universales o globales; una adición a estos grupos fuera de proceso de cambio es de las alertas de mayor severidad posible en un SOC de AD.
4738	Se ha modificado una cuenta de usuario (cambios en atributos: SPN añadido, «Password never expires», «Smart card required» retirado, cambio de `userAccountControl`, etc.).	Un cambio de `userAccountControl` que retira «Kerberos preauthentication required» habilita el objetivo para AS-REP Roasting. Añadir un SPN a una cuenta de usuario normal es requisito previo a un ataque de Kerberoasting dirigido.
5136	Se ha modificado un objeto del directorio (Directory Service Changes) — muestra el atributo cambiado, valor anterior y nuevo.	Es el evento de mayor detalle para auditar cambios de atributos en objetos de AD: cambios en `ntSecurityDescriptor` de OUs, atributos de GPOs vinculadas, adminSDHolder, etc.
5137	Se ha creado un objeto del directorio.	Creación de objetos en OUs con SACL activa (por ejemplo, una OU de Tier 0) permite detectar la aparición de cuentas, GPOs u objetos equipo no autorizados.
5141	Se ha eliminado un objeto del directorio.	Borrado de objetos críticos (cuentas de servicio, GPOs, grupos) que puede indicar sabotaje o limpieza de artefactos tras un ataque (p. ej. tras crear y usar una cuenta de «backdoor»).
4662	Se ha realizado una operación sobre un objeto del Active Directory (requiere SACL en el objeto + subcategoría Directory Service Access habilitada). Incluye el GUID de la propiedad accedida.	Clave para detectar DCSync: cuando una cuenta no autorizada (que no sea un DC ni una cuenta de servicio de replicación legítima como Azure AD Connect) genera un 4662 con los GUID de `DS-Replication-Get-Changes`, `DS-Replication-Get-Changes-All` y/o `DS-Replication-Get-Changes-In-Filtered-Set` sobre el objeto de dominio (naming context), es la firma directa de un ataque DCSync (p. ej. `mimikatz lsadump::dcsync`).
4713	Se ha modificado la política Kerberos del dominio (p. ej. tiempo de vida máximo del ticket, tolerancia de reloj).	Debilitar la política Kerberos (alargar la vida de los tickets, reducir requisitos) puede ser preparación para persistencia con Golden/Silver Tickets de mayor duración.
4739	Se ha modificado la política de dominio (p. ej. política de contraseñas, política de bloqueo de cuentas).	Relajar la política de complejidad de contraseñas o el umbral de bloqueo de cuentas facilita ataques de fuerza bruta/spraying posteriores; es un paso de preparación habitual.
1102	Se ha borrado el registro de auditoría (log de seguridad). Se genera en el log Security justo después del borrado, indicando la cuenta que lo ejecutó.	Uno de los eventos anti-forenses más relevantes: un atacante que ha completado su objetivo suele intentar borrar el log de seguridad del DC para eliminar evidencia. Un 1102 inesperado en un DC es de severidad crítica per se, incluso sin más contexto.
4674	Se ha intentado una operación sobre un objeto privilegiado (uso de un privilegio sensible sobre un objeto, p. ej. `SeBackupPrivilege` para leer el registro/SAM, o manipulación de un proceso con `SeDebugPrivilege`).	Complementa al 4672: mientras 4672 dice «esta sesión tiene privilegios especiales», 4674 dice «se ha usado uno de esos privilegios sobre este objeto», lo cual es mucho más accionable para detectar abuso real, no solo posesión del privilegio.

5. Consultar estos eventos con PowerShell

Para consultas puntuales o para alimentar scripts de correlación previos a la llegada al SIEM, Get-WinEvent con -FilterHashtable es más eficiente que Get-EventLog (deprecado) porque filtra en el propio proveedor ETW antes de traer los datos a PowerShell:

# Todos los TGS-REQ (4769) de las últimas 24 horas
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddHours(-24)}

# Buscar posibles Kerberoasting: 4769 con tipo de cifrado RC4 (0x17)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
  Where-Object { $_.Message -match 'Ticket Encryption Type:s+0x17' } |
  Select-Object TimeCreated, @{n='Cuenta';e={($_.Properties[0]).Value}}, @{n='SPN';e={($_.Properties[2]).Value}}

# Accesos a objetos de AD (4662) que incluyan los GUID de replicación (posible DCSync)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} |
  Where-Object {
    $_.Message -match '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or   # DS-Replication-Get-Changes
    $_.Message -match '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'      # DS-Replication-Get-Changes-All
  }

# Correlacionar creación de cuenta (4720) con adición a grupo privilegiado (4728/4732/4756)
# en una ventana de 10 minutos, indicativo de "crear cuenta + escalar" rápido
$altas = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720; StartTime=(Get-Date).AddDays(-1)}
foreach ($alta in $altas) {
    $cuenta = ($alta.Properties[0]).Value
    $ventana = $alta.TimeCreated
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4728,4732,4756; StartTime=$ventana; EndTime=$ventana.AddMinutes(10)} |
      Where-Object { $_.Message -match [regex]::Escape($cuenta) }
}

# Confirmar borrado de log de seguridad (1102) — debería ser prácticamente inexistente
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}

Nota práctica: en Get-WinEvent, filtrar por texto dentro de $_.Message es cómodo para laboratorio, pero es lento en producción sobre grandes volúmenes porque obliga a renderizar el mensaje completo de cada evento. En un SIEM, estos mismos campos (Ticket Encryption Type, Object GUID accedido, SPN) llegan como campos estructurados vía XML/EVTX y se filtran de forma indexada, sin ese coste.

6. Auditoría de cambios en objetos AD mediante SACL en OUs sensibles

Habilitar las subcategorías Directory Service Access y Directory Service Changes no genera, por sí sola, ningún evento 4662/5136/5137/5141: hace falta configurar explícitamente una SACL (System Access Control List, la parte de auditoría del descriptor de seguridad) sobre los objetos o contenedores concretos que se quieren vigilar. Auditar el naming context completo de dominio sin criterio genera un volumen inmanejable de eventos; la práctica recomendada es aplicar SACL de forma selectiva sobre:

OUs de Tier 0 (controladores de dominio, cuentas y grupos de administración de dominio).
Los grupos privilegiados en sí (Domain Admins, Enterprise Admins, Schema Admins, Administrators).
El contenedor AdminSDHolder, cuyo descriptor de seguridad se propaga periódicamente (cada 60 minutos por el proceso SDProp) a todos los objetos protegidos del dominio.
GPOs vinculadas a OUs sensibles.
El objeto de dominio raíz, para capturar los 4662 con los GUID de replicación relevantes para DCSync.

Configuración manual desde ADSI Edit o Active Directory Users and Computers con vistas avanzadas: clic derecho sobre la OU → Properties → pestaña Security → Advanced → pestaña Auditing → Add. Se selecciona el principal «Everyone» (para capturar tanto accesos legítimos como no autorizados), el tipo «All» o específicamente «Success/Fail» según el objeto, y se marcan como mínimo: Write all properties, Create/Delete all child objects, y para el caso concreto de DCSync, los derechos extendidos Replicating Directory Changes y Replicating Directory Changes All sobre el objeto de dominio.

Desde PowerShell, usando el módulo ActiveDirectory y el proveedor AD:, se puede automatizar la adición de una regla de auditoría sobre una OU:

$ouPath = "AD:OU=Tier0,DC=corp,DC=local"
$acl = Get-Acl -Path $ouPath

$auditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    (New-Object System.Security.Principal.NTAccount("Everyone")),
    [System.DirectoryServices.ActiveDirectoryRights]"WriteProperty,CreateChild,DeleteChild",
    [System.Security.AccessControl.AuditFlags]"Success,Failure"
)

$acl.AddAuditRule($auditRule)
Set-Acl -Path $ouPath -AclObject $acl

Para el caso específico de DCSync, la SACL debe aplicarse sobre el objeto de dominio (naming context DC=corp,DC=local) auditando los derechos extendidos correspondientes a los GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Replicating Directory Changes) y 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Replicating Directory Changes All). Con esa SACL en su sitio, cualquier cuenta que no sea un DC legítimo o una cuenta de servicio de sincronización autorizada (Azure AD Connect, por ejemplo) generará un 4662 al ejercer ese derecho — que es exactamente lo que hace mimikatz lsadump::dcsync o el módulo equivalente de Impacket (secretsdump.py) al solicitar la replicación.

7. Centralización con Windows Event Forwarding (WEF) y por qué no basta con dejarlos en el DC

Dejar los eventos solo en el log local del DC tiene tres problemas serios en un contexto de seguridad:

Rotación y tamaño limitado. El log de seguridad tiene un tamaño máximo configurado (por defecto, muchas veces insuficiente en un DC con auditoría avanzada activa) y, al llenarse, sobrescribe los eventos más antiguos. Con Kerberos Service Ticket Operations habilitado en un dominio grande, el volumen de 4769 puede rotar el log en horas, perdiendo evidencia de un incidente que se detecta días después.
Un atacante con privilegios en el DC puede borrar el log (evento 1102) o alterar los eventos antes de que nadie los revise, eliminando la evidencia en origen.
No hay correlación entre DCs ni con otras fuentes. Detectar Kerberoasting, DCSync o password spraying requiere ver el volumen agregado a través de todos los controladores de dominio (un atacante puede repartir las peticiones entre varios DCs precisamente para diluir el volumen por servidor) y cruzarlo con otras fuentes (firewall, EDR, proxy).

Windows Event Forwarding (WEF) resuelve el primer y segundo problema reenviando los eventos, casi en tiempo real, desde cada DC («fuente») hacia un servidor colector centralizado. Desde ahí, el colector se integra con el SIEM (Splunk, Microsoft Sentinel, Elastic, QRadar…) para correlación, alertado y retención a largo plazo, separada del propio DC.

Configuración básica en modo «collector-initiated» (el colector inicia la suscripción, recomendado para entornos gestionados por GPO):

# 1. En el colector: habilitar el servicio Windows Event Collector
wecutil qc /q

# 2. En cada DC (fuente): habilitar el servicio WinRM, necesario para el reenvío
winrm quickconfig -q

# 3. Añadir el equipo colector al grupo local "Event Log Readers" en cada DC
#    (o gestionarlo vía GPO restringiendo membresía de ese grupo)
net localgroup "Event Log Readers" CORPWEF-Collector$ /add

# 4. Crear la suscripción en el colector a partir de un XML de definición
wecutil cs suscripcion-eventos-ad.xml

# 5. Verificar el estado de la suscripción y de las fuentes
wecutil gs "Suscripcion-Eventos-AD"
wecutil gr "Suscripcion-Eventos-AD"

Ejemplo simplificado de XML de suscripción centrado en los Event IDs críticos de este módulo, en modo collector-initiated:

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Suscripcion-Eventos-AD</SubscriptionId>
  <SubscriptionType>CollectorInitiated</SubscriptionType>
  <Description>Reenvio de eventos criticos de auditoria de AD</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxLatencyTime>30000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="60000"/>
    </PushSettings>
  </Delivery>
  <Query>
    <![CDATA[
      <QueryList>
        <Query Id="0" Path="Security">
          <Select Path="Security">
            *[System[(EventID=4624 or EventID=4625 or EventID=4634 or EventID=4648
                       or EventID=4672 or EventID=4768 or EventID=4769 or EventID=4771
                       or EventID=4776 or EventID=4720 or EventID=4722 or EventID=4725
                       or EventID=4726 or EventID=4728 or EventID=4732 or EventID=4756
                       or EventID=4738 or EventID=5136 or EventID=5137 or EventID=5141
                       or EventID=4662 or EventID=4713 or EventID=4739 or EventID=1102
                       or EventID=4674)]]
          </Select>
        </Query>
      </QueryList>
    ]]>
  </Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>HTTP</TransportName>
  <ContentFormat>RenderedText</ContentFormat>
  <Locale Language="es-ES"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers>
  <AllowedSourceDomainComputers>O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)</AllowedSourceDomainComputers>
  </Subscription>

Los eventos reenviados llegan al log ForwardedEvents del colector, desde donde el agente del SIEM (Splunk Universal Forwarder, Microsoft Monitoring Agent/AMA, Winlogbeat, etc.) los recoge para ingestión, indexado y correlación. Este diseño en dos saltos (DC → colector WEF → SIEM) desacopla el rendimiento del DC de la carga de recolección, y permite aplicar en el colector reglas de filtrado o normalización antes de que los eventos salgan de la red interna.

Una alternativa habitual en entornos con agente EDR/SIEM desplegado directamente en cada DC es que el propio agente lea el log de seguridad local y lo envíe al SIEM sin pasar por un colector WEF intermedio. Ambos enfoques son válidos; lo que no es aceptable en un diseño de monitorización serio es dejar los eventos solo en el log local del DC sin ningún mecanismo de reenvío.

Laboratorio

Objetivo: habilitar la auditoría avanzada en un controlador de dominio de laboratorio (Windows Server con rol AD DS) y confirmar que se generan eventos 4769 y 4662 reales al realizar acciones concretas.

Preparación. Levanta un DC de laboratorio (puede ser una VM aislada, sin conexión a producción) con al menos un usuario de prueba y una cuenta de servicio con SPN registrado. Confirma el estado inicial de auditoría:
```
auditpol /get /category:*
```
Habilitar el flag de auditoría avanzada exclusiva vía registro (o mejor, vía GPO «Audit: Force audit policy subcategory settings…» como se explicó en la sección 1):
```
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v SCENoApplyLegacyAuditPolicy /t REG_DWORD /d 1 /f
```

Habilitar las subcategorías necesarias para este laboratorio (como mínimo, Kerberos Service Ticket Operations y Directory Service Access):

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

Configurar una SACL de prueba sobre el objeto de dominio para poder generar un 4662, auditando el derecho extendido «Replicating Directory Changes» para el principal «Everyone» (solo en laboratorio; en producción se restringe a principales concretos). Puede hacerse desde ADSI Edit → objeto de dominio → Properties → Security → Advanced → Auditing → Add, o con el script de PowerShell de la sección 6 adaptado al objeto de dominio.
Generar tráfico Kerberos real desde un equipo unido al dominio con la cuenta de servicio con SPN:
```
# Desde un cliente del dominio, forzar solicitud de ticket de servicio
klist purge
Invoke-Command -ComputerName servidor-con-spn -ScriptBlock { hostname } -Credential (Get-Credential)
```
Esto debería generar un 4768 (TGT) seguido de un 4769 (TGS) para el SPN correspondiente.

Confirmar el 4769 en el DC:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddMinutes(-5)} |
  Select-Object TimeCreated, Id, Message | Format-List

Debe verse el nombre de cuenta, el SPN solicitado y el tipo de cifrado del ticket.

Simular (de forma controlada) una operación que dispare el 4662 con el derecho de replicación auditado, por ejemplo ejecutando Get-ADReplAccount del módulo DSInternals contra el DC de laboratorio desde una cuenta de prueba, o simplemente confirmando manualmente el acceso al derecho extendido desde una herramienta como dsacls. Verificar:
```
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddMinutes(-5)} |
  Where-Object { $_.Message -match '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' }
```
Documentar en una tabla propia: subcategoría habilitada → acción realizada → Event ID esperado → Event ID observado, confirmando que la cadena «configuración de auditoría → SACL → acción → evento» funciona de extremo a extremo antes de replicar la configuración en un entorno real.

Errores comunes

Logs de seguridad demasiado pequeños que rotan y pierden evidencia. Habilitar Kerberos Service Ticket Operations o Directory Service Access sin aumentar el tamaño máximo del log de seguridad (wevtutil sl Security /ms:<bytes>) provoca que, en un DC con actividad normal, el log rote en horas. Cuando llega el momento de investigar un incidente detectado días después, la evidencia ya no está.
No centralizar los eventos. Confiar únicamente en el log local del DC deja la evidencia al alcance de un atacante con privilegios suficientes para ejecutar wevtutil cl Security o generar el evento 1102, o simplemente para esperar a que rote.
Auditar sin tener capacidad de análisis. Activar todas las subcategorías y SACLs «por si acaso» sin que haya un SIEM, reglas de correlación o al menos un proceso manual de revisión periódica genera volumen sin valor: los eventos existen, pero nadie los mira hasta que ya es tarde. Auditoría sin análisis es una ilusión de seguridad.
Conflicto entre política clásica y avanzada por no habilitar SCENoApplyLegacyAuditPolicy, lo que provoca que la configuración avanzada aplicada por GPO se vea sobrescrita silenciosamente por la política clásica heredada de configuraciones antiguas.
Habilitar subcategorías de Object Access de forma genérica sin SACLs específicas, esperando ver eventos 4662/5136 que nunca llegan porque falta el paso de configurar la SACL sobre el objeto concreto.
No auditar los fallos (Failure), solo los éxitos (Success). Muchos de los eventos más valiosos para detección temprana (4625, 4771, intentos fallidos de acceso a objetos) son precisamente los de fallo; auditar solo éxito deja fuera buena parte de la señal de ataques en curso.

Ejercicio

Sobre tu laboratorio de AD (o uno nuevo si no dispones de uno activo), realiza lo siguiente y documenta los resultados:

Habilita las subcategorías de auditoría avanzada descritas en la sección 3 mediante GPO vinculada a la OU de Domain Controllers, incluyendo el flag SCENoApplyLegacyAuditPolicy.
Configura una SACL sobre una OU que simule tu Tier 0 (controladores de dominio, cuentas de administración) auditando creación, modificación y borrado de objetos.
Registra un SPN en una cuenta de usuario de prueba (setspn -A HTTP/servicio-prueba usuario-prueba) y, desde otro equipo, solicita un ticket de servicio contra ese SPN. Localiza el evento 4769 resultante e identifica el tipo de cifrado del ticket (campo Ticket Encryption Type). Si es 0x17 (RC4), documenta por qué ese tipo de cifrado es el que buscan las herramientas de Kerberoasting.
Crea una cuenta de usuario de prueba, añádela a un grupo con seguridad habilitada, y localiza en el log de seguridad la cadena completa de eventos 4720 (creación) → 4738 (si modificas algún atributo) → 4728/4732/4756 (adición al grupo, según el tipo de grupo).
Diseña (en papel o en un XML real de suscripción WEF) la lista de Event IDs que reenviarías desde tus DCs hacia un colector, justificando por qué incluyes o excluyes cada uno en función del volumen esperado y el valor de detección.
Redacta, en no más de 15 líneas, una política de retención razonada: cuánto tiempo mantendrías los eventos en el colector WEF frente al SIEM, y por qué esos dos periodos pueden ser distintos.

Preguntas frecuentes

¿Por qué no basta con auditar solo Logon/Logoff si ya cubre la mayoría de accesos?

Porque un atacante que ya tiene un punto de apoyo en la red rara vez se limita a iniciar sesiones «normales»: lo relevante para AD es ver también las operaciones sobre el propio directorio (Directory Service Access/Changes), el ciclo de vida de cuentas y grupos (Account Management) y la ejecución de comandos (Process Creation). Kerberoasting, DCSync o la manipulación de SACLs de AdminSDHolder no generan necesariamente eventos de logon anómalos, pero sí generan 4769, 4662 o 5136 que Logon/Logoff nunca vería.

¿Cuál es la diferencia real entre el 4768 y el 4769?

El 4768 corresponde a la fase AS-REQ/AS-REP del protocolo Kerberos: el usuario solicita el TGT (Ticket Granting Ticket) al KDC usando su contraseña o clave. El 4769 corresponde a la fase TGS-REQ/TGS-REP: con el TGT ya en mano, el usuario solicita un ticket de servicio (TGS) para acceder a un recurso concreto identificado por su SPN. El 4768 ocurre una vez por sesión de logon (o cuando expira el TGT); el 4769 ocurre cada vez que se accede a un servicio distinto, por lo que su volumen es mucho mayor y es el que hay que filtrar por tipo de cifrado para detectar Kerberoasting.

¿Es necesario habilitar Global Object Access Auditing además de las SACL individuales?

Global Object Access Auditing (auditoría global centralizada por GPO) permite aplicar una política de auditoría a todos los objetos de un tipo (por ejemplo, todo el sistema de archivos de un servidor) sin tener que configurar SACL objeto por objeto, y es muy útil en recursos compartidos de archivos. Para objetos de Active Directory en sí, sin embargo, la práctica estándar sigue siendo configurar SACLs específicas sobre OUs y objetos concretos (Tier 0, AdminSDHolder, objeto de dominio), porque una auditoría global sobre todo el directorio generaría un volumen de eventos inmanejable en cualquier dominio de tamaño medio o grande.

¿Qué pasa si el colector WEF se cae? ¿Se pierden los eventos generados mientras tanto?

No necesariamente. El propio DC sigue generando y almacenando los eventos en su log de seguridad local mientras dure la caída del colector; cuando la suscripción WEF se restablece, continúa el reenvío desde el último evento entregado (el estado de la suscripción se mantiene tanto en la fuente como en el colector). El riesgo real aparece si la caída del colector se prolonga más tiempo del que tarda el log local del DC en rotar por tamaño: por eso el dimensionamiento del log local (sección de errores comunes) sigue siendo relevante incluso con WEF desplegado, como colchón ante interrupciones del reenvío.

¿Por qué el evento 4662 no aparece aunque tengo habilitada la subcategoría Directory Service Access?

Es el error más común al implementar esta parte del módulo: la subcategoría habilita la capacidad de generar el evento, pero Windows solo lo genera para los objetos que tienen una SACL explícita configurada solicitando esa auditoría. Sin la SACL sobre el objeto de dominio (o el objeto concreto que se quiera vigilar), la subcategoría puede estar en «Success and Failure» y aun así no aparecer ni un solo 4662. Repasa la sección 6 y confirma con dsacls "DC=tudominio,DC=local" /S o desde ADSI Edit que la SACL de auditoría está realmente aplicada.

«Domain controllers generate events that reflect all account logon activity for the domain. […] Because domain controllers hold vital information for the enterprise, it is very important to closely monitor domain controller activity to identify signs of compromise as quickly as possible.» — Microsoft, «Audit Policy Recommendations», Microsoft Learn, Security guidance for Windows Server / Active Directory.

Módulo 10: Monitorización de AD I — auditoría avanzada y Event IDs críticos