Auditoría y detección en AD: directiva e ID de evento

El hardening de la configuración reduce la superficie de ataque, pero no hace imposibles los ataques contra Active Directory: los hace más difíciles y más ruidosos. Que sean más ruidosos solo sirve si alguien, o algo, está escuchando. La mayoría de los compromisos de AD que llegan al control total del dominio no tienen éxito porque la detección fuera técnicamente imposible, sino porque nunca se activaron la directiva de auditoría, las SACL y la canalización de registros necesarias para verlos. Este artículo cubre la configuración concreta de la directiva de auditoría avanzada, los ID de evento que importan, las SACL en los objetos sensibles y la canalización de recopilación (WEF, Defender for Identity, honeytokens) para pasar de «tenemos registros» a «nos daríamos cuenta».

Configurar la directiva de auditoría avanzada mediante GPO

La directiva de auditoría heredada (las nueve categorías básicas) es demasiado general. Use Advanced Audit Policy Configuration (configuración de directiva de auditoría avanzada), aplicada mediante una GPO vinculada a la OU Domain Controllers:

Ruta de directiva de grupo: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Habilite estas subcategorías (Success y Failure, salvo que se indique lo contrario):

Aplique y verifique:

# Aplique la GPO y confirme después la configuración efectiva en un DC
auditpol /get /category:*

# Comprobar una subcategoría concreta
auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Si auditpol muestra «No Auditing» tras una actualización de la GPO, confirme que la configuración de auditoría de Local Policies del Editor de objetos de directiva de grupo local no está invalidando la directiva de auditoría avanzada: mezclar la directiva de auditoría heredada y la avanzada en el mismo equipo provoca exactamente esto. Establezca Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings en Enabled.

Los ID de evento que más importan

La detección de DCSync merece especial atención: no aparece como un evento «DCSync» específico. Aparece como el evento 4662 con los dos GUID de replicación anteriores, emitido por una entidad de seguridad que no es una cuenta de equipo de un controlador de dominio ni una cuenta de servicio de replicación designada. Que cualquier otra entidad de seguridad invoque esos derechos extendidos es un indicio sólido de que se están usando credenciales robadas para suplantar a un controlador de dominio.

SACL en los objetos sensibles

Los eventos 4662 y 5136 solo se generan donde hay una lista de control de acceso del sistema (SACL) configurada en el objeto. Aplique SACL, y no solo la directiva de auditoría, a:

• El propio objeto de dominio (DC=domain,DC=com): imprescindible para detectar DCSync, ya que los derechos de replicación se evalúan en la raíz del dominio.
• AdminSDHolder (CN=AdminSDHolder,CN=System,DC=domain,DC=com).
• Los grupos privilegiados: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators.
• La cuenta krbtgt.
• Las GPO vinculadas a la OU Domain Controllers y a cualquier OU de Tier 0.

Configúrelas desde Configuración de seguridad avanzada > Auditoría en el objeto, o con PowerShell:

$path = "AD:\DC=domain,DC=com"
$acl = Get-Acl $path
$sacl = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0",   # Everyone: filtre después en su SIEM
    "WriteProperty,ExtendedRight",
    "Success",
    [guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"                # DS-Replication-Get-Changes
)
$acl.AddAuditRule($sacl)
Set-Acl -Path $path -AclObject $acl

Verifique que las SACL están presentes:

(Get-Acl "AD:\DC=domain,DC=com").Audit | Format-Table IdentityReference, ActiveDirectoryRights, AuditFlags

Windows Event Forwarding hacia un recopilador

Los registros de eventos locales de un controlador de dominio no son una evidencia duradera: un atacante con DA puede borrarlos, y los registros de un solo DC dan una imagen incompleta. Reenvíelos a un recopilador central:

1. En el recopilador: wecutil qc para configurar el servicio Windows Event Collector.
2. Cree una suscripción (la iniciada por el origen es la más sencilla a escala) dirigida a las subcategorías de auditoría anteriores; distribúyala mediante el valor de registro SubscriptionManager enviado por GPO, que dirige los DC hacia el recopilador.
3. En los DC, asegúrese de que el servicio Windows Remote Management (WS-Management) está en ejecución y de que la cuenta Network Service (que utiliza el servicio de reenvío) puede leer el registro Security: agregue NT AUTHORITY\NETWORK SERVICE al grupo integrado Event Log Readers (de ámbito de dominio en los DC), o amplíe el SDDL de acceso del canal Security mediante directiva de grupo.
4. Verifique la entrega:

Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 20 -ComputerName <collector>
wecutil gr <SubscriptionName>

Conserve los registros reenviados en un lugar del que no puedan borrarlos los administradores del dominio auditado: un nivel separado de gestión de registros o de SIEM, idealmente en un límite de confianza o administrativo distinto del de los DC supervisados.

Microsoft Defender for Identity y honeytokens

Microsoft Defender for Identity despliega sensores en los DC y en los servidores AD FS y correlaciona la telemetría de red y de eventos para detectar reconocimiento, uso de golden ticket, DCSync y patrones de movimiento lateral sin que tenga que construir a mano cada regla de detección. Es un complemento sólido, no un sustituto, de la directiva de auditoría y las SACL anteriores, porque el propio Defender for Identity consume la telemetría ETW y de auditoría local del DC.

Cuentas honeytoken: cree cuentas señuelo sin ningún uso legítimo para el negocio, idealmente con un nombre o un SPN atractivo, sin actividad de inicio de sesión jamás y con una contraseña de apariencia plausible (pero sin usar), y genere una alerta ante cualquier intento de autenticación contra ellas. Defender for Identity permite marcar cuentas como honeytokens de forma nativa; sin él, genere alertas directamente sobre los eventos 4768/4769/4624 cuya entidad de seguridad de destino sea la cuenta honeytoken. Una sola coincidencia es una señal de alta confianza, ya que ningún proceso legítimo debería tocarla nunca.

Qué se rompe

Nada funcional: la auditoría es pasiva. El coste real es el volumen de registros: habilitar la auditoría de Directory Service Access (4662) de forma amplia, en lugar de limitar las SACL a los objetos realmente sensibles, puede generar un volumen enorme de eventos en los DC con mucha actividad y saturar tanto la retención de registros local como su recopilador WEF. Planifique el almacenamiento del recopilador y la capacidad de ingesta del SIEM a partir de un piloto con un subconjunto de DC antes de desplegar la directiva de auditoría en todo el bosque, y prefiera SACL específicas a «auditarlo todo».

Una vez implantada la detección, combínela con el hardening de controladores de dominio para reducir lo que los atacantes pueden hacer antes de que usted los vea, y con la seguridad de objetos y ACL para reducir el conjunto de objetos cuyo compromiso es lo bastante importante como para necesitar una SACL.