4.9 · Defensa de Active Directory: detección, hardening y respuesta

Panorama#

Los ocho capítulos anteriores de esta Parte recorrieron Active Directory desde la óptica del atacante: el reconocimiento del grafo (4.1), el abuso de Kerberos (4.2) y de NTLM (4.3), la escalada por certificados (4.4), el volcado de credenciales (4.5), la delegación y los trusts (4.6), el abuso de ACLs y la persistencia (4.7) y el movimiento lateral (4.8). Cada uno terminó con una subsección de defensa que apuntaba aquí. Este capítulo recoge esas promesas y las convierte en un sistema: no una lista de reglas sueltas, sino la postura defensiva completa de un dominio.

La tesis que ordena el capítulo es la de la fuente que lo cimenta: un ataque a Active Directory casi nunca es un evento, es una historia. El SOC que caza a un adversario en el dominio rara vez lo hace por una alerta aislada —un solo Event ID 4769 con RC4 es indistinguible del ruido—, sino porque correlaciona una secuencia de comportamientos que, encadenados, solo tienen una explicación: un punto de apoyo interno, seguido de reconocimiento del dominio, seguido de descubrimiento de SPN, seguido de una ráfaga de peticiones de ticket, seguido de un uso anómalo de la cuenta descifrada. Ninguna etapa por separado dispara una alerta crítica; la suma sí. Defender AD es, por tanto, un problema de telemetría (registrar lo correcto), de correlación (leer la historia en los eventos) y de postura (quitarle al atacante las técnicas antes de que las use).

El capítulo sigue ese orden. Primero, la telemetría que hay que tener antes de que un ataque ocurra —porque no se detecta lo que no se registra—. Después, el diccionario consolidado de Event IDs de AD, organizado por fase de la cadena de ataque, que reúne en un solo lugar las firmas que 4.2–4.8 fueron citando. Luego, la correlación: cómo esas firmas se leen juntas como una historia. A continuación, el hardening que elimina cada familia de técnica de raíz. Y por último, el playbook de respuesta cuando la detección dispara —incluido el caso especial del doble reset de krbtgt que erradica un Golden Ticket—.

flowchart LR
  subgraph T["1 · Telemetría (antes)"]
    AUD["Advanced Audit Policy\n+ SACL en objetos Tier 0"]
    SYS["Sysmon + Script Block\nLogging (4104)"]
    WEF["Reenvío de logs\n(WEF/SIEM) fuera del DC"]
  end
  subgraph D["2 · Detección + correlación"]
    DICT["Diccionario de\nEvent IDs por fase"]
    STORY["Correlación →\nhistoria de ataque"]
  end
  subgraph H["3 · Hardening (raíz)"]
    POST["Credential Guard · LAPS ·\ntiering · Protected Users ·\nAES · MAQ=0"]
  end
  subgraph R["4 · Respuesta"]
    IR["Scoping → contención →\nerradicación (krbtgt ×2) →\nlecciones aprendidas"]
  end
  T --> D
  D -->|"la alerta dispara"| R
  H -.->|"reduce la superficie\nque D debe vigilar"| D
  R -.->|"lecciones aprendidas\nmejoran la postura"| H

La telemetría que hay que tener antes#

Todo lo que sigue depende de un hecho incómodo: por defecto, Windows no registra la mayoría de lo que se necesita para cazar a un atacante en AD. Los Event IDs que 4.2–4.8 citaron no aparecen mágicamente; muchos exigen habilitar categorías de la Advanced Audit Policy, configurar SACLs (System Access Control Lists) en los objetos sensibles, o desplegar telemetría de terceros como Sysmon. Un dominio sin esta configuración previa es ciego a casi todo el catálogo defensivo de esta Parte. La telemetría no es la última pieza del sistema; es la primera, y sin ella el resto es teoría.

Cuatro capas de recolección sostienen la detección en AD:

• Advanced Audit Policy. Las categorías granulares que activan las familias de eventos clave: Account Logon y Logon/Logoff (4624/4625/4768/4769/4771/4776), Account Management (4720–4767), DS Access (4662, 4928 —la auditoría del directorio, imprescindible para ver DCSync—), Directory Service Changes (5136, el antes/después de la modificación de un objeto) y Process Creation (4688, con la línea de comandos incluida, que es una opción aparte que hay que activar explícitamente).
• SACLs en los objetos Tier 0. Varios de los eventos más valiosos solo se emiten si el objeto auditado tiene una SACL que lo pida. El caso canónico es el objeto del dominio y el AdminSDHolder: sin una SACL que audite las lecturas de replicación y las escrituras de DACL, el 4662 que delata un DCSync (4.5) y el 5136 que delata un backdoor en AdminSDHolder (4.7) sencillamente no se generan.
• Sysmon y Script Block Logging. Los registros nativos tienen puntos ciegos que la telemetría de Sysmon cubre: el acceso al proceso de LSASS (Sysmon Event ID 10, la firma del volcado de credenciales), la suscripción de eventos WMI (Sysmon 19/20/21), la creación de valores de registro (Sysmon 12/13) y la relación padre-hijo de procesos (Sysmon 1). En paralelo, el PowerShell Script Block Logging (Event ID 4104) reconstruye el código real que ejecutó un powershell.exe ofuscado o codificado en Base64 —la única vía de ver qué hizo de verdad una carga fileless—.
• Reenvío de logs fuera del host. Esta capa es la que un atacante no puede borrar. El Event ID 1102 (registro de auditoría borrado) es, en sí mismo, uno de los primeros indicadores de compromiso: un adversario que limpia el log de seguridad de un DC para tapar su rastro. La contramedida no es solo alertar sobre 1102, sino no depender del log local: el reenvío mediante Windows Event Forwarding o un agente de SIEM asegura que, cuando el atacante borre el registro de la máquina, la copia ya esté fuera de su alcance. El log del DC comprometido deja de ser confiable en el momento del compromiso; el del SIEM, no.

Bajo el capó: el subsistema de auditoría, el SACL y por qué la telemetría se puede cegar#

La sección anterior prescribió qué habilitar. Debajo de esa receta operativa hay una maquinaria del núcleo que conviene entender, porque explica tres cosas que la lista de GPO da por sentadas: por qué la auditoría requiere dos piezas y no una, por qué los Event IDs de AD del diccionario que sigue son casos particulares de una familia más general, y —el giro incómodo— por qué la propia telemetría es un objeto que un atacante con el privilegio adecuado puede silenciar en su origen, no solo borrar después.

El primer hecho es que la auditoría no es un subsistema aparte, es una rama del access-check. Cuando el Security Reference Monitor evalúa un acceso con el algoritmo de tres fases que describe 4.7, en la misma pasada comprueba si el objeto lleva una SACL (System Access Control List) cuyas entradas coincidan con el sujeto y la máscara de acceso solicitada; si coinciden, emite un evento. La DACL responde a la pregunta «¿se concede?»; la SACL, en la misma evaluación, responde a «¿se registra?». Por eso el substrato del descriptor de seguridad de 4.7 y el de la auditoría de 4.9 son gemelos: dos ramas de una sola decisión del SRM.

El segundo hecho es el mecanismo detrás de los «dos componentes interdependientes» que la sección de telemetría mencionó. La Advanced Audit Policy es el interruptor maestro global: sin la subcategoría correspondiente —Object Access → Kernel Object, DS Access, etc.— activada, el núcleo ignora silenciosamente cualquier regla de SACL declarada en los objetos. Es deliberado: evita ahogar el log con eventos de la operación nominal. La SACL del objeto concreto es la regla atómica: qué SID, qué máscara de permisos, y si se registra el éxito, el fracaso o ambos. Las dos piezas tienen que estar —la política global habilita la categoría, la SACL define la regla—, y esa dependencia es exactamente la razón por la que un Event ID «no aparece mágicamente» aunque el ataque haya ocurrido: faltaba una de las dos mitades. Configurar o leer una SACL exige además el privilegio SeSecurityPrivilege, de modo que solo cuentas administrativas alteran la visibilidad del defensor —un detalle que se vuelve central en un momento—.

El tercer hecho es que los Event IDs específicos de AD del diccionario son especializaciones de una familia genérica de acceso a objeto. Todo handle abierto contra un objeto auditado emite el 4656 (con la máscara concedida en el propio evento), su cierre el 4658, un borrado el 4660 y un intento fallido o de lectura el 4663. El 4662 que delata un DCSync (4.5) es un evento de esta clase sobre un objeto del directorio cuya máscara coincide con el control-access-right de replicación; el 5136 es la variante de modificación. Entender la capa genérica es lo que permite a un defensor escribir sus propias SACLs sobre objetos Tier 0 arbitrarios —no depender solo de las preconfiguradas por Microsoft— y saber qué Event ID esperar.

El caso canónico de una SACL preconfigurada lo ilustra: por defecto Windows equipa al proceso LSASS con una SACL que dispara únicamente cuando un actor solicita el permiso VmRead (Virtual Memory Read) —el permiso exacto del volcado de credenciales de 4.5—. Microsoft focalizó la telemetría para que una consulta inofensiva (QueryLimitedInformation) no genere ruido, pero una lectura de la memoria del proceso sí. Es el primo nativo del Sysmon Event ID 10 que la sección de telemetría ya citaba: la misma detección del acceso a LSASS, emitida por el propio núcleo, sin agente de terceros. Un defensor puede enumerar qué procesos conservan esa SACL —con Get-NtProcess filtrando por entradas de auditoría en el módulo NtObjectManager— y verificar que LSASS no la haya perdido.

Y aquí está el talón de Aquiles simétrico. Si SeSecurityPrivilege permite escribir SACLs, entonces un atacante que lo posea puede quitarle la SACL a LSASS o a un objeto Tier 0 y operar sin telemetría en la fuente —más silencioso que borrar el log entero—. Sostener ese privilegio es un vector del abuso de tokens de 3.9, y SeAuditPrivilege, su pareja, permite fabricar eventos falsos para ahogar la señal en ruido. Donde borrar el registro completo emite el ruidoso 1102 que la sección de telemetría ya trata, manipular la configuración de auditoría emite sus primos quirúrgicos: el 4719 (política de auditoría del sistema modificada) y el 4907 (configuración de auditoría de un objeto modificada). La lección refuerza exactamente la de la telemetría: la configuración de auditoría local, igual que el log local, queda bajo control del atacante en cuanto este toma el privilegio, así que la defensa es la misma —reenviar fuera del host, tratar 4719/4907 como IOC de primera clase (¿quién cambió la política o vació una SACL, y por qué?) y verificar periódicamente la integridad de las SACLs de los objetos Tier 0, LSASS incluido—.

El diccionario de Event IDs de Active Directory#

Con la telemetría en su sitio, este es el catálogo consolidado —las firmas que 4.2–4.8 citaron una por una, reunidas por fase de la cadena de ataque—. No es una lista para memorizar, sino un mapa: para cada técnica de los capítulos ofensivos, el evento (o la correlación de eventos) que la delata.

Autenticación y acceso#

El Event ID 4624 (logon exitoso) es el eje, y su valor está en el campo Logon Type, que revela cómo entró la identidad: tipo 2 (teclado local), tipo 3 (red / SMB, el del movimiento lateral), tipo 10 (RDP), tipo 11 (credenciales cacheadas). Un 4624 seguido inmediatamente de un 4672 (privilegios especiales asignados) señala una sesión administrativa. Su contraparte, el 4625 (logon fallido), se lee por sus códigos Status / Sub Status: 0xC0000064 (usuario inexistente) frente a 0xC000006A (contraseña incorrecta) distingue una adivinación ciega de identidades de un password spraying sobre usuarios válidos. La duración exacta de una sesión se reconstruye vinculando el Logon ID del 4624 con el 4634/4647 (cierre de sesión).

La validación de credenciales se registra en el sistema que autentica, no en el que recibe el logon: los fallos NTLM generan el 4776, y los de pre-autenticación Kerberos el 4771 (con su propio Failure Code: 0x18 = contraseña incorrecta, 0x6 = usuario inexistente). El 4740 (bloqueo de cuenta) cierra el cuadro de la fuerza bruta.

Acceso a credenciales#

Aquí viven las firmas de oro de la Parte. El Kerberoasting de 4.2 se ve como una ráfaga de Event ID 4769 (petición de TGS) con tipo de cifrado RC4 (0x17) en un dominio que negocia AES por defecto: un pico volumétrico de peticiones de ticket de servicio pidiendo explícitamente el cifrado débil es el ataque casi en texto claro. El Overpass-the-Hash de 4.8 deja la misma firma RC4 pero en el 4768 (emisión de TGT): un TGT pedido con el NT hash en vez de la clave AES.

El DCSync de 4.5 es el caso que justifica la SACL del objeto de dominio: se detecta por un Event ID 4662 con el GUID de la extensión de control DS-Replication-Get-Changes (o -All) originado desde un principal que no es un controlador de dominio. Un DC replica con otro DC de forma rutinaria; una cuenta de usuario o de estación pidiendo replicación es, por definición, un DCSync. El volcado de LSASS que alimenta todo lo anterior se ve en Sysmon Event ID 10 (acceso al proceso de lsass.exe).

Persistencia y escalada#

La gestión de identidades delata la persistencia. La creación de una cuenta clandestina genera 4720 (creación) y 4722 (habilitación), pero el evento de creación no dice qué privilegios recibió: hay que cruzarlo con los eventos de modificación de grupos —4728 (grupo global), 4732 (grupo local de dominio), 4756 (grupo universal)— para ver si la cuenta apócrifa fue insertada en Domain Admins. Esta correlación creación→elevación es la firma directa de la persistencia por cuenta.

Las demás formas de persistencia de 4.7 tienen cada una su evento: las tareas programadas se registran con 4698 (creación, con el XML de la carga en el propio evento), 4699/4700/4702 (borrado/habilitación/actualización); los servicios maliciosos con 7045 (canal System) y 4697 (canal Security); la suscripción de eventos WMI fileless con 5861 (canal WMI-Activity) o, con más fidelidad, los Sysmon 19/20/21 (registro del filtro, del consumidor y su vinculación). Y la modificación de cualquier objeto sensible del directorio —el backdoor en AdminSDHolder, la escritura del atributo RBCD de 4.6, el cambio de DACL que habilita un auto-DCSync— se ve en el 5136 (modificación de un objeto del servicio de directorio), que registra el antes y el después del atributo tocado.

Movimiento lateral#

El Pass-the-Hash de 4.8 se caza en un 4624 de tipo 3 con paquete de autenticación NTLM donde se esperaría Kerberos, y en particular en el logon de una cuenta local por red. El abuso de recursos administrativos compartidos (ADMIN$, C$) que precede a PsExec genera 5140 (acceso al recurso de red) y 5145 (acceso detallado al fichero), correlacionados con la instalación del servicio PSEXESVC (7045/4697). El RDP deja 4778/4779 (reconexión/desconexión del canal TerminalServices) además del 4624 tipo 10. Y el PowerShell Remoting vía WinRM instancia wsmprovhost.exe en el destino, cuya carga real se reconstruye con el 4104. La firma transversal de las vías de ejecución sin servicio (WMI, DCOM) es la relación padre-hijo anómala: WmiPrvSE.exe, mmc.exe o un proceso de Office que engendra cmd.exe/powershell.exe (4688 con línea de comandos, Sysmon 1).

Correlación: de la alerta aislada a la historia de ataque#

El diccionario anterior es necesario pero no suficiente. El problema real del defensor es que cada uno de esos eventos, por separado, es ambiguo: un 4769 con RC4 puede ser una aplicación heredada legítima; un 4624 tipo 3 es el pan de cada día de una red; un 4728 es un administrador haciendo su trabajo. La señal no está en el evento, está en la secuencia. La disciplina que convierte el diccionario en detección es la correlación: leer varios comportamientos ambiguos como capítulos de una sola historia que solo tiene una explicación maliciosa.

El playbook de abuso de Kerberos de la fuente lo ilustra con una cadena de diez etapas que el SOC detiene no en la primera, sino cuando las etapas se ensamblan en un relato coherente. Cada etapa mapea a una técnica MITRE ATT&CK y a un conjunto de eventos; ninguna dispara sola una alerta crítica, pero su encadenamiento sí:

flowchart TD
  E1["1 · Foothold interno\n4624 · VPN anómala\nT1078"] --> E2["2 · Domain discovery\nconsultas LDAP masivas\nT1087/T1069"]
  E2 --> E3["3 · SPN discovery\nbúsqueda de cuentas con SPN\nT1558.003"]
  E3 --> E4["4 · Kerberoasting\nráfaga de 4769 con RC4 0x17\nT1558.003"]
  E4 --> E5["5 · Cracking offline\n(sin telemetría — fuera de línea)\nT1110"]
  E5 --> E6["6 · Uso de la cuenta de servicio\n4624 desde host irregular\nT1078.002"]
  E6 --> E7["7 · Acceso a servidores\n5140/5145 (SMB)\nT1021.002"]
  E7 --> E8["8 · Privilege discovery\nenumeración de grupos admin\nT1069"]
  E8 --> E9["9 · Lateral movement\n7045 · C$/ADMIN$\nT1021.002/T1569.002"]
  E9 --> E10["10 · Domain escalation\n4728/4732/4756\nT1098/T1484"]
  E10 --> DET["PUNTO DE DETECCIÓN FINAL\nel SOC correlaciona la historia\ny contiene"]
  style DET fill:#7c3f58,color:#fff
  style E4 fill:#3f5a7c,color:#fff
  style E10 fill:#3f5a7c,color:#fff

La lógica de la regla de SIEM que atrapa esto no evalúa un evento, evalúa el patrón: «SI se observa un foothold interno Y el comportamiento posterior encaja con reconocimiento de dominio y descubrimiento de SPN Y una actividad ulterior alcanza el descubrimiento de privilegios o el movimiento lateral Y hay impacto posible sobre datos o negocio, ENTONCES dispara una alerta de severidad crítica». Es una máquina de estados sobre la historia, no un umbral sobre una métrica. La pregunta que el analista se hace en cada etapa es la misma que estructura cualquier investigación: ¿es esperable esta actividad, qué evidencia la confirma, tuvo éxito, qué se accedió o cambió, y qué hay que contener antes de la siguiente etapa?

Hardening: quitar la técnica de raíz#

La detección atrapa al atacante después de que actúe; el hardening le quita la técnica antes. Es la capa que reduce la superficie que la detección debe vigilar, y la única que escala: una regla de SIEM se evalúa contra todo el tráfico para siempre, mientras que una contramedida de postura elimina la clase de ataque de una vez. Las recomendaciones que 4.2–4.8 fueron dejando caer se consolidan aquí en una sola tabla, ordenada por la familia de técnica que neutralizan.

Tres piezas de esta tabla merecen énfasis por su alcance transversal. El grupo Protected Users neutraliza de un golpe varias técnicas: fuerza a sus miembros a autenticarse solo con Kerberos y AES, sin NTLM ni caché de credenciales, lo que anula el Pass-the-Hash, el Overpass-the-Hash con RC4 y el robo de credenciales cacheadas —a cambio de que esas cuentas no puedan usar delegación ni logon offline, por lo que se reserva para las identidades de Tier 0—. El tiering (segmentación por niveles administrativos) es la contramedida estructural más importante y la más difícil: impide que una credencial de Tier 0 (administradores de dominio) se exponga jamás en la memoria de una máquina de Tier 2 (estaciones de usuario), que es exactamente donde el atacante la roba; sin tiering, un solo host comprometido puede escalar hasta el dominio. Y LAPS cierra el combustible del Pass-the-Hash a escala —la contraseña de administrador local reutilizada en toda la flota— asignando a cada equipo una distinta y rotada.

Respuesta: del scoping a la erradicación#

Cuando la detección dispara, empieza la respuesta —y su primera regla es contraintuitiva: acotar antes de actuar. Buena parte de los incidentes reportados como brechas resultan ser fallos operativos convencionales; despachar analistas forenses y capacidad de contención sobre una falla de hardware quema recursos que un incidente real necesitaría. El scoping (triaje inicial) determina si de verdad hay evidencia de un adversario antes de escalar. Su contracara es igual de importante: recolectar cantidades masivas de datos sin una hipótesis no acelera la investigación, la ahoga —«más datos» no es «mejor investigación» si nadie los correlaciona—. El analista se enfoca en los artefactos que reconstruyen la línea temporal: los Event IDs críticos (un 1102 que confirma que el adversario borró los logs, un 4688 que muestra la ejecución de mimikatz.exe o PSExec.exe), no en un volcado indiscriminado.

Confirmado el incidente, la secuencia de respuesta en AD sigue el arco estándar —contención, erradicación, recuperación, lecciones aprendidas— con particularidades propias del dominio:

• Contención. Aislar los endpoints comprometidos de la red y revocar las sesiones Kerberos activas de las cuentas implicadas. Como el DC comprometido ya no es una fuente confiable de logs (pudo emitir un 1102), la investigación se apoya en la copia reenviada al SIEM.
• Erradicación. Rotar las contraseñas de las cuentas de servicio afectadas (invalida los TGS crackeados), revertir las modificaciones anómalas de grupos privilegiados (4728/4732/4756) y de objetos del directorio (5136 sobre AdminSDHolder, RBCD, DACLs), y revocar los certificados si hubo compromiso de AD CS. El caso especial es el Golden Ticket: como se forja con el hash de krbtgt, la única erradicación real es resetear la contraseña de krbtgt dos veces seguidas (la cuenta mantiene la clave actual y la anterior; un solo reset dejaría válidos los tickets forjados con la clave previa). El doble reset —espaciado para no romper la replicación— invalida todo TGT forjado.
• Recuperación y lecciones aprendidas. Aplicar las políticas que impidan la repetición (prohibir RC4 en el dominio, cerrar las aristas que BloodHound revele) y documentar el incidente. La contención técnica no es el final: el informe post-incidente —qué falló en la postura, qué evento no estaba auditado, qué regla no correlacionó a tiempo— es lo que realimenta el hardening de la sección anterior y sube la línea base. Es el bucle que cierra el diagrama del panorama: la respuesta a un incidente es la mejor fuente de requisitos para la telemetría y la postura del siguiente.

Con esto, la Parte 4 queda cerrada como un ciclo púrpura completo: los capítulos 4.1–4.8 describen lo que el atacante hace en Active Directory, y 4.9 describe cómo se registra, se correlaciona, se previene y se responde —cada firma defensiva conectada a la técnica ofensiva que la produce—. La detección profunda de estos mismos artefactos a escala de SIEM, y el análisis forense de los Event Logs de Windows como disciplina, continúan en la Parte 5 (Blue / DFIR).

Referencias#

• blue-dfir/effective-threat-investigation/cap-04 — Rastreo de autenticación y gestión de cuentas: Logon Type, códigos Status/Sub Status, 4624/4625/4634/4647/4672/4771/4776, y los eventos de gestión de identidades (4720/4722/4728/4732/4740) como firma de persistencia.
• blue-dfir/effective-threat-investigation/cap-07 — Investigación de persistencia y movimiento lateral con Event Logs: tareas (4698–4702), servicios (7045/4697), suscripción WMI (5861, Sysmon 19/20/21), recursos compartidos (5140/5145), RDP (4778/4779), Script Block Logging (4104) y la firma del Pass-the-Hash.
• blue-dfir/incident-playbook/cap-09 — Playbook de abuso de Kerberos: la cadena de diez etapas, el mapeo MITRE ATT&CK, la detección por RC4 (0x17) en 4769 y la lógica de correlación «historia de ataque, no alerta aislada».
• blue-dfir/attack-defense/cap-13 — Investigación de incidentes: scoping/triaje, priorización de artefactos (1102, 4688), forense en vivo vs post-mortem y el ciclo de lecciones aprendidas.
• red-infra/windows-security-internals/cap-09 (Forshaw, Security Auditing) — el substrato del subsistema de auditoría: la auditoría como rama del access-check, la dependencia Advanced Audit Policy + SACL, la familia genérica de eventos de acceso a objeto (4656/4658/4660/4663) bajo los específicos de AD, la SACL de LSASS sobre VmRead, y los privilegios SeSecurityPrivilege/SeAuditPrivilege que permiten cegar o falsear la telemetría en la fuente (con inspección vía NtObjectManager).
• MITRE ATT&CK — T1558 Steal or Forge Kerberos Tickets, T1550 Use Alternate Authentication Material y la táctica TA0006 Credential Access.
• Microsoft — Advanced Security Audit Policy, Credential Guard, Protected Users, LAPS, el modelo de tiering (Enterprise Access Model) y el procedimiento de doble reset de krbtgt.