Brechas de configuración de la política de auditoría de Active Directory: las categorías que nadie activa antes de necesitar los registros

Qué son las brechas de configuración de la política de auditoría de Active Directory

La mayoría de los equipos de Active Directory asumen que si el registro de eventos Security se está llenando, el entorno está "auditado". No lo está — no de la forma que importa para detectar un ataque. Las brechas de configuración de la política de auditoría de Active Directory son las subcategorías que Windows entrega desactivadas, a medio configurar o silenciosamente sobrescritas, de modo que los eventos que un investigador necesitaría más tarde nunca se generaron. Windows organiza lo que se registra en una Configuración Avanzada de la Política de Auditoría compuesta por 10 categorías subdivididas en decenas de subcategorías — que pasaron de las 9 categorías básicas originales a 53 subcategorías granulares a partir de Windows Vista y Windows Server 2008 (el número ha seguido creciendo desde entonces, ya que versiones posteriores de Windows añadieron subcategorías como Group Membership y PNP Activity), según describe el propio historial de Microsoft sobre las políticas de auditoría avanzada de Windows Server. Cada subcategoría es un interruptor independiente. Deja una desactivada, y cada evento que habría generado simplemente nunca existe — no hay registro que revisar después, ninguna brecha que notar en una revisión de incidente, nada.

En la práctica, cuatro puntos ciegos aparecen una y otra vez en entornos AD cuya política de auditoría nunca ha sido revisada deliberadamente, y que corresponden directamente a lo que buscan nuestras verificaciones de auditoría de seguridad de Active Directory:

• Account Management dejado en los valores predeterminados de Windows en lugar de estar completamente habilitado (éxito y fallo), de modo que los cambios de usuarios, equipos y grupos quedan parcial o totalmente sin registrar.
• Account Logon (la categoría que realmente cubre la autenticación Kerberos en los controladores de dominio) desactivada por completo — esta viene desactivada por defecto incluso en servidores.
• Policy Change que no cubre las subcategorías que importan más allá de la que Windows ya registra por usted.
• Ningún honeypot o cuenta señuelo en ninguna parte del directorio, por lo que no existe un disparador de casi cero falsos positivos para la enumeración o el abuso de credenciales.

Cada uno es pequeño por sí solo. Juntos significan que las categorías que detectarían la creación de privilegios, el abuso de credenciales y a un atacante cubriendo sus huellas son precisamente las que menos probabilidades tienen de registrar algo. Estas brechas se suman a las otras prioridades de hardening cubiertas en Hardening de Active Directory: Qué Bloquear Primero — la política de auditoría rara vez recibe la misma atención que las ACL o el aislamiento del Tier 0, precisamente porque un registro faltante no se anuncia por sí mismo. A diferencia de una ACL peligrosa o un grupo sobreprivilegiado, una subcategoría de auditoría desactivada no produce ningún artefacto con el que tropezar durante una revisión rutinaria — la única forma de detectarla es ir a verificar directamente la política efectiva, en el controlador de dominio, en lugar de asumir que el editor de GPO cuenta toda la historia.

Cómo Funciona Realmente la Política de Auditoría de Windows — Y Dónde Falla Silenciosamente

Microsoft publica una tabla de recomendaciones de referencia precisamente por esta razón: la política predeterminada de Windows Server deja varias subcategorías relevantes para la identidad desactivadas, y solo un subconjunto de las subcategorías de Account Management registra fallos de fábrica. Dos valores predeterminados destacan específicamente para AD:

• Audit Credential Validation (la subcategoría bajo Account Logon que gobierna la validación de contraseñas NTLM y Kerberos) se entrega como No | No — completamente desactivada — tanto en Windows Client como en Windows Server. La recomendación de referencia de Microsoft la eleva a Yes | Yes en servidores (los controladores de dominio de los que trata este artículo) y a Yes | No en clientes, y las otras tres subcategorías de Account Logon (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) no tienen ningún valor predeterminado.
• Audit Policy Change (bajo Policy Change) viene por defecto como Yes | No — solo éxito. La referencia de Microsoft recomienda Yes | Yes.

Este segundo punto importa por un detalle que Microsoft documenta directamente en el propio evento: el Event ID 4719 ("System audit policy was changed") "siempre se registra sin importar la configuración de la subcategoría Audit Policy Change". Eso es tranquilizador para ese evento que los administradores suelen conocer — pero Authentication Policy Change y Authorization Policy Change son subcategorías separadas, activadas de forma independiente, dentro de la misma categoría Policy Change, y ninguna de las dos recibe ese mismo pase gratuito. Si no están explícitamente habilitadas, un atacante que relaja discretamente la configuración de delegación Kerberos o una asignación de privilegios no deja nada atrás.

La Trampa del Reemplazo Legacy-vs-Avanzado

Existe una segunda trampa, más operativa, y es la misma categoría de problema que las malas configuraciones de GPO que convierten Group Policy en un vector de ataque: incluso cuando una GPO habilita correctamente una subcategoría avanzada, esa configuración puede ser silenciosamente sobrescrita por la Política de Seguridad Local heredada de 9 categorías, a menos que el dominio también habilite "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" — el valor de registro SCENoApplyLegacyAuditPolicy bajo HKLM\SYSTEM\CurrentControlSet\Control\Lsa, según la documentación de Microsoft para esa política. Sáltatelo, y la GPMC puede mostrar cada subcategoría correctamente configurada mientras el controlador de dominio sigue aplicando silenciosamente la antigua política a nivel de categoría en su lugar.

Este artículo trata deliberadamente sobre si estas categorías están siquiera activadas. Qué hacer una vez que lo están — qué event IDs concretos vigilar y cómo construir la lógica de detección — se cubre en Supervisión de Active Directory: Los Event IDs de Seguridad que Importan.

Detección: Verificar lo que Está Realmente Activado, No lo que Dice la GPO

Verificar la Política Efectiva con auditpol

No confíe solo en la Consola de Administración de Directivas de Grupo. Ejecute auditpol directamente en un controlador de dominio para ver la política efectiva:

# Política de auditoría efectiva completa en este DC
auditpol /get /category:*

# Solo las categorías que cubre este artículo
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Confirmar que la configuración de reemplazo legacy de la GPO realmente se aplicó
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

Si alguna subcategoría muestra "No Auditing", los eventos de la siguiente tabla no se están generando en esa máquina — punto final, nada que investigar después:

Por Qué una Cuenta Honeypot Cierra el Círculo

Un honey user es una cuenta AD señuelo sin privilegio real, colocada para que las herramientas de enumeración (BloodHound, password sprayers, scripts de Kerberoasting) la encuentren y la prueben como cualquier otro objetivo. Como un usuario o servicio legítimo nunca la toca, cualquier 4768/4769/4624 contra esa cuenta es una señal con casi 100% de confianza — lo opuesto al problema de fatiga por alertas ruidosas que las otras tres categorías pueden generar una vez activadas. Los señuelos efectivos necesitan metadatos y ubicación realistas, no un nombre obvio como honeypot-admin-01, según la orientación sobre tecnología de decepción en este ámbito. El mismo principio sustenta la detección del abuso de ACL y las rutas DCSync: una solicitud de replicación proveniente de una cuenta que no tiene motivo para replicar es exactamente el tipo de señal de bajo ruido y alta confianza que estas categorías de auditoría existen para revelar.

También conviene verificar: los atacantes que logran desactivar el registro están ejecutando MITRE ATT&CK T1562.002 — Impair Defenses: Disable Windows Event Logging, una técnica de evasión de defensas que apunta específicamente a la política de auditoría que cubre este artículo. Un entorno que nunca activó estas categorías en primer lugar le regala a esta técnica una victoria gratuita que de otro modo no tendría.

Remediación: Cerrando las Cuatro Brechas

Corregir Primero Account Logon y Account Management

1. Habilite Account Logon por completo, éxito y fallo, vía Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Eleve Account Management al nivel de referencia de Microsoft (éxito y fallo) para User Account Management, Security Group Management, Computer Account Management y Other Account Management Events — no solo el valor predeterminado de solo éxito.

Completar Policy Change y Asegurar el Reemplazo de la GPO

3. Complete Policy Change: habilite Authentication Policy Change y Authorization Policy Change junto con la subcategoría Audit Policy Change ya parcialmente activada, de modo que la manipulación de la política Kerberos y las asignaciones de privilegios realmente generen eventos.
4. Configure el reemplazo legacy de la GPO ("Audit: Force audit policy subcategory settings...") a nivel de dominio, y luego vuelva a ejecutar la verificación auditpol /get anterior en un DC tras un gpupdate /force — verifique la política efectiva, no confíe solo en el editor de GPO.

Desplegar una Cuenta Señuelo y Alertar sobre 4719

5. Despliegue al menos una cuenta honeypot por dominio, con atributos y ubicación de grupo realistas, y alerte ante cualquier evento de autenticación contra ella.
6. Reenvíe todo lo anterior a un SIEM y alerte sin condiciones sobre el Event ID 4719 — la propia guía de Microsoft es tratar cualquier cambio no planificado en la política de auditoría como un disparador de investigación de alta prioridad, ya que los atacantes desactivan la auditoría específicamente para operar sin dejar evidencia.

Trate esto como una verificación recurrente, no como un proyecto puntual: la reconstrucción de un controlador de dominio, una nueva GPO que reinicia la configuración de reemplazo legacy, o una migración a un bosque nuevo pueden reintroducir silenciosamente cualquiera de estas cuatro brechas, y ninguna de ellas aparecerá como una alerta — simplemente aparecerán como una ausencia, meses después, en un incidente donde los registros que necesitaba nunca se escribieron. Incorporar esta verificación en un flujo de auditoría AD recurrente es la única forma fiable de detectar la deriva antes de que importe.

Cómo Detecta Esto EtcSec

EtcSec verifica los objetos de Group Policy de Active Directory en cada auditoría en busca de exactamente estas brechas: AUDIT_POLICY_WEAK señala subcategorías por debajo de la referencia de Microsoft, DC_AUDIT_POLICY_INCOMPLETE señala controladores de dominio donde la política efectiva no coincide con lo que dice la GPO, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED verifica el cumplimiento de la recomendación ANSSI R38 para la cobertura de la política de auditoría avanzada, y NO_HONEYPOT_ACCOUNTS señala directorios sin ninguna cuenta señuelo en todo su alcance.