Detección de ataques a AD: Sigma, MDI y honeytokens

Aviso ético: este módulo enseña a detectar ataques contra Active Directory, no a ejecutarlos. Las técnicas ofensivas (Kerberoasting, DCSync, Golden Ticket) se nombran únicamente como referencia para poder construir la lógica de detección correspondiente, y ya se trataron en profundidad en el módulo de ataques del itinerario. Las reglas Sigma, las consultas KQL y los procedimientos de creación de honey accounts deben desplegarse solo en dominios propios, en tu laboratorio de prácticas, o en entornos de producción para los que tengas autorización explícita por escrito y dentro de tu rol como defensor. Crear cuentas señuelo o desplegar sensores de Microsoft Defender for Identity en un dominio ajeno sin autorización puede constituir, además de una mala práctica, un ilícito. La responsabilidad de cualquier cambio de configuración recae por completo en quien lo ejecuta.

Qué aprenderás

A pasar de «tener logs habilitados» (módulo anterior) a detectar ataques concretos: qué señal exacta busca cada regla y por qué esa señal es difícil de evitar para el atacante.
Reglas de detección específicas para Kerberoasting, DCSync, Golden Ticket y enumeración masiva (BloodHound/LDAP), con el Event ID, el campo y el umbral concretos de cada una.
A escribir y leer reglas Sigma en formato YAML, campo a campo, y a entender cómo se traducen a un backend de SIEM real (Splunk SPL, Microsoft Sentinel KQL).
Qué aporta Microsoft Defender for Identity (MDI) frente a la detección basada solo en Event IDs, y cómo se despliega su sensor en los controladores de dominio.
El concepto de deception aplicado a AD: honey accounts, honeytokens y honeypots, y cómo montar una honey account con SPN paso a paso, incluida su alerta.
Las herramientas estándar de evaluación de postura del dominio (PingCastle, Purple Knight, BloodHound en modo azul, ORADAD, Microsoft Secure Score) y cómo convertirlas en un proceso periódico con métricas de madurez.

Desarrollo

1. De la auditoría a la detección: por qué no basta con tener el log

El módulo anterior dejó los controladores de dominio generando los eventos correctos: 4769 con el tipo de cifrado del ticket, 4662 con el GUID del derecho de control accedido, 4768 con el resultado de la petición de TGT. Tener esos eventos disponibles no es lo mismo que detectar un ataque: la diferencia la marca la regla de detección, una lógica explícita que dice «si ocurre esta combinación de campos, en este volumen, en esta ventana de tiempo, genera una alerta accionable». Sin esa lógica, un analista de SOC se enfrenta a miles de 4769 legítimos por hora en un dominio mediano —cada acceso a un recurso, cada impresora, cada aplicación con SPN genera TGS-REQ constantemente— y ninguna revisión manual es sostenible. El trabajo de este módulo es convertir ese ruido en un puñado de alertas de alta confianza. Tres ingredientes hacen que una regla sea buena:

Especificidad del campo: no basta con «hubo un 4769», hace falta el campo que distingue tráfico normal de ataque (por ejemplo, el tipo de cifrado del ticket).
Volumen o correlación: muchos ataques no se distinguen por un evento aislado sino por su repetición anómala en poco tiempo desde una única cuenta.
Baseline de lo normal: sin saber qué es «normal» en tu dominio (cuántas cuentas de servicio tienen SPN, qué cuentas hacen replicación legítima) cualquier umbral es una conjetura. Se retoma en la sección de errores comunes.

2. Tabla de referencia: ataque, señal de detección y herramienta

Esta tabla resume, para los ataques ya introducidos conceptualmente en el módulo de ataques, la señal exacta que los delata y con qué herramienta se detecta en la práctica. Es el mapa que desarrollan el resto de secciones.

Ataque	Señal de detección concreta	Herramienta / mecanismo que lo detecta
Kerberoasting	Evento 4769 con `TicketEncryptionType = 0x17` (RC4) y alto volumen de SPN distintos desde la misma cuenta en ventana corta (p. ej. >15 servicios en 5 min), sin acceso previo a esos recursos.	Regla Sigma/SIEM sobre el log del DC; MDI («Suspected AD Kerberoasting attack»); honey account con SPN atractivo.
AS-REP Roasting	Evento 4768 con `Pre-Authentication Type = 0` para cuentas `DONT_REQUIRE_PREAUTH`, combinado con `TicketEncryptionType = 0x17`.	Regla Sigma sobre 4768; inventario previo del flag (auditoría de postura); MDI.
DCSync	Evento 4662 con los GUID `1131f6aa-9c07-11d1-f79f-00c04fc2dcd2` (DS-Replication-Get-Changes) y/o `1131f6ad-9c07-11d1-f79f-00c04fc2dcd2` (-Get-Changes-All) desde un principal que no es un DC ni cuenta de replicación autorizada (Entra Connect, backup con delegación legítima).	Regla Sigma/SIEM sobre 4662 con lista blanca de DCs; MDI («Suspected DCSync attack»); honey account nunca usada para replicación.
Golden Ticket	Evento 4769 sin 4768 previo correlacionable (misma cuenta, hora, Logon ID); vida útil del TGT anómala (>10h de política estándar); cuenta ya inexistente en AD con ticket aún válido.	Correlación 4768↔4769 en SIEM; MDI («Suspected Golden Ticket usage»); rotación de `krbtgt` como contención.
Silver Ticket	Evento 4624 (logon tipo 3) con TGS válido pero sin el 4769 correspondiente en el DC (ticket forjado offline, nunca pasó por el KDC).	MDI (correlación logons↔actividad del KDC); logs del servicio objetivo cruzados con ausencia de 4769.
Enumeración masiva (BloodHound/LDAP)	Volumen anómalo de consultas LDAP (usuarios, grupos, ACL, anidamiento) desde una única cuenta/IP en poco tiempo.	MDI («Reconnaissance» — SAMR, DNS); Sysmon/ETW sobre `Directory Service Access`.
Password spraying	Múltiples 4625 con `Sub Status = 0xC000006A` repartidos entre muchas cuentas desde el mismo origen (vs. fuerza bruta clásica sobre una sola cuenta).	Regla Sigma/SIEM agrupando por IP origen y cuentas distintas; MDI.

3. Reglas de detección campo a campo

La tabla anterior resume la señal; aquí se detalla el porqué de cada una para los tres ataques con evidencia más directa en el log de seguridad:

Kerberoasting (4769 + RC4 + volumen). La firma no es «hubo un 4769» —ocurre constantemente en tráfico legítimo— sino la combinación de: (1) cifrado RC4 (0x17), sospechoso en un dominio migrado a AES salvo que la cuenta objetivo siga forzando RC4 por su msDS-SupportedEncryptionTypes; (2) la misma cuenta origen solicitando múltiples SPN distintos en poco tiempo, algo que ningún usuario o servicio legítimo hace (se accede a un puñado de recursos conocidos, no a decenas en minutos); (3) ausencia de logon interactivo previo que justifique el acceso. Cualquier herramienta de Kerberoasting (Rubeus, Impacket GetUserSPNs.py) solicita TGS para todas las cuentas con SPN de una vez, disparando el volumen de forma inequívoca.

DCSync (4662 + GUID de replicación + origen no-DC). DCSync abusa de los derechos extendidos de replicación (DS-Replication-Get-Changes y DS-Replication-Get-Changes-All) para que un DC legítimo envíe los hashes de cualquier cuenta, sin tocar ntds.dit directamente. El evento 4662 registra ese acceso con el GUID del derecho en su campo Properties. La regla es una lista blanca invertida: cualquier 4662 con esos GUID cuyo SubjectUserName no sea un DC ni una cuenta de replicación autorizada y documentada (Entra Connect, backup con delegación legítima) es sospechoso por definición. No hace falta volumen: un solo evento desde origen no autorizado ya es alerta crítica.

Golden Ticket (TGT anómalo, 4769 sin 4768 previo). Un Golden Ticket se forja offline con el hash de krbtgt y nunca pasa por la fase AS-REQ/AS-REP real del KDC (evento 4768). Esto rompe la cadena causal normal (4768 de la sesión → uno o varios 4769 posteriores): el 4769 aparece sin un 4768 correlacionable para esa cuenta, hora y Logon ID. Señales complementarias: vida útil del ticket distinta a la política de dominio (10h por defecto; Mimikatz suele fijar valores muy superiores si el atacante no los ajusta) y tickets válidos para cuentas ya eliminadas de AD.

4. Regla Sigma de ejemplo: Kerberoasting

Sigma es el formato estándar de facto para escribir reglas de detección independientes del SIEM: se define una vez en YAML y un conversor (sigma-cli con el backend correspondiente) la traduce a Splunk SPL, KQL de Sentinel, EQL de Elastic, etc. La regla siguiente detecta Kerberoasting sobre el log de seguridad de Windows:

title: Posible Kerberoasting por solicitud de TGS con cifrado RC4
id: 8ac9e0f1-4d3a-4b71-9e0c-7d5f1a2b3c4d
status: stable
description: |
  Detecta solicitudes de ticket de servicio (TGS) con tipo de cifrado
  RC4 (0x17), excluyendo cuentas de máquina, como indicador de un
  posible ataque de Kerberoasting (extracción de hashes de cuentas
  de servicio con SPN para crackeo offline).
references:
  - https://attack.mitre.org/techniques/T1558/003/
  - https://adsecurity.org/?p=3458
author: Equipo Blue Team - Modulo 11 AD
date: 2026/07/02
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  filter_maquinas:
    ServiceName|endswith: '$'
  filter_krbtgt:
    ServiceName: 'krbtgt'
  condition: selection and not (filter_maquinas or filter_krbtgt)
falsepositives:
  - Cuentas de servicio legítimas que aún no han migrado a AES y se
    acceden con frecuencia normal (baja el volumen esperado con una
    baseline previa antes de poner esta regla a nivel "high").
  - Escaneos de vulnerabilidades o herramientas de inventario que
    autentican contra muchos servicios en poco tiempo.
level: medium
tags:
  - attack.credential_access
  - attack.t1558.003

Explicación campo a campo:

title / id / status: identifican la regla de forma única (el id es un UUID v4) y su estado de madurez (stable, frente a experimental o test).
logsource: product windows, service security: le dice al conversor que esta regla opera sobre el log de seguridad de Windows, lo que en la mayoría de backends mapea directamente al índice/sourcetype donde llegan los eventos del DC vía WEF o el forwarder del SIEM.
detection.selection: la condición positiva — EventID: 4769 con TicketEncryptionType: '0x17' (el valor va entre comillas porque Sigma lo trata como cadena, no como número hexadecimal).
detection.filter_maquinas y filter_krbtgt: excluyen falsos positivos conocidos — las cuentas de equipo (que terminan en $ en el campo ServiceName) generan TGS con RC4 de forma rutinaria en muchos entornos legacy sin ser un ataque, y las peticiones hacia el propio krbtgt no son Kerberoasting.
condition: selection and not (filter_maquinas or filter_krbtgt): la sintaxis booleana de Sigma — cumple la selección pero no cae en ninguno de los dos filtros de exclusión.
falsepositives: documentación obligatoria de buenas prácticas Sigma; ayuda al analista a triar la alerta sin tener que redescubrir por qué salta en su entorno.
level: severidad relativa (informational, low, medium, high, critical); se deja en medium hasta afinar la regla con volumen/ventana temporal específicos de correlación (ver nota siguiente), momento en el que puede subirse a high.
tags: mapeo a MITRE ATT&CK — attack.t1558.003 es la sub-técnica exacta de Kerberoasting dentro de «Steal or Forge Kerberos Tickets» (T1558).

Esta regla base detecta el uso de RC4, pero no el volumen. En un SIEM real se complementa con una regla de correlación adicional (agregación) que cuenta SPN distintos por TargetUserName en una ventana de, por ejemplo, 5 minutos, y solo alerta por encima de un umbral definido tras observar la baseline del dominio — Sigma soporta esto mediante el bloque detection con timeframe y funciones de agregación (count() by) en las versiones más recientes del estándar, o se implementa directamente como regla de correlación nativa en el SIEM de destino.

5. De Sigma al SIEM: conversión y ejemplo en KQL

La regla anterior se convierte con sigma-cli al backend correspondiente. Para Microsoft Sentinel (KQL):

# Instalación del conversor y el backend de Microsoft Sentinel
pip install sigma-cli
sigma plugin install sentinel

# Conversión de la regla Sigma a KQL
sigma convert -t sentinel -p sysmon kerberoasting-rc4.yml

El resultado equivalente en KQL, ejecutable directamente sobre la tabla SecurityEvent (o WindowsEvent si se ingiere vía AMA) de un workspace de Log Analytics/Sentinel:

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where not(ServiceName endswith "$")
| where ServiceName != "krbtgt"
| summarize SPNsDistintos = dcount(ServiceName), Servicios = make_set(ServiceName)
    by TargetUserName, bin(TimeGenerated, 5m)
| where SPNsDistintos >= 15
| order by SPNsDistintos desc

Esta versión KQL ya incorpora la capa de volumen que la regla Sigma base deja para una segunda etapa: agrupa por cuenta origen y ventanas de 5 minutos, cuenta SPN distintos con dcount(), y solo emite fila al superar el umbral (15, ajustable tras baseline). Es el patrón recomendado: una regla Sigma simple y portable para la señal atómica, más una capa de correlación específica de cada SIEM para el volumen, ya que la sintaxis de agregación varía entre backends y conviene afinarla con datos reales del entorno.

6. Microsoft Defender for Identity (MDI)

Microsoft Defender for Identity (antes Azure Advanced Threat Protection, Azure ATP) es la solución de Microsoft específica para detección de ataques a identidad on-premises e híbrida. A diferencia de una regla Sigma sobre el log de seguridad, MDI no depende únicamente de Event IDs: despliega un sensor en cada Domain Controller (y opcionalmente en AD FS/AD CS) que analiza en tiempo real el tráfico de red del DC —Kerberos, NTLM, LDAP, DNS— además de los propios logs, viendo así patrones que nunca llegan a generar un Event ID individual reconocible (ciertas técnicas de enumeración SAMR, reconocimiento de red previo al ataque).

MDI organiza su detección en las fases del ciclo de vida de un ataque, alineadas con la Cyber Kill Chain: Reconnaissance (enumeración de cuentas/grupos, reconocimiento de red y DNS — el patrón típico de BloodHound/SharpHound), Compromised credentials (fuerza bruta, password spraying, Kerberoasting, AS-REP Roasting), Lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, delegación anómala) y Domain dominance (DCSync, Golden Ticket, abuso de AdminSDHolder, AD CS, Skeleton Key).

La ventaja frente a reglas Sigma hechas a mano es doble: Microsoft mantiene los modelos de detección actualizados conforme evolucionan las técnicas, y MDI correlaciona automáticamente actividad de varios DC en una línea de tiempo por entidad (usuario, equipo) en Microsoft Defender XDR, reduciendo el triado manual. El coste es la licencia (Microsoft 365 E5 / Defender for Identity standalone) y el despliegue del sensor en cada DC, que en hardware legacy muy limitado exige planificación de capacidad.

7. Deception: honey accounts, honeytokens y honeypots

La detección basada en logs y en MDI parte de reconocer patrones de ataque conocidos. El deception (decepción) invierte la lógica: en vez de intentar distinguir tráfico malicioso de tráfico legítimo dentro de un volumen enorme de actividad real, se coloca un objeto que nunca debería recibir tráfico legítimo en absoluto. Cualquier interacción con ese objeto es, por definición, sospechosa —no hace falta ningún umbral de volumen ni baseline compleja, porque el valor esperado de actividad legítima es exactamente cero.

7.1 Honey account (cuenta señuelo) para detectar Kerberoasting

Una honey account aplicada a Kerberoasting es una cuenta de AD que se crea deliberadamente con un SPN atractivo (un nombre de servicio que sugiera privilegios o valor, por ejemplo algo que parezca una cuenta de backup, de SQL Server o de un servicio de gestión) y una contraseña larga y aleatoria que en la práctica es imposible de crackear offline en un tiempo razonable. La cuenta no se usa para ningún servicio real: ningún proceso legítimo la autentica jamás. Por tanto, cualquier solicitud de TGS (evento 4769) contra el SPN de esa cuenta es, con certeza casi absoluta, obra de una herramienta de enumeración de SPN (Rubeus, GetUserSPNs.py) ejecutada por alguien que está listando y solicitando tickets para todas las cuentas con SPN del dominio — el propio comportamiento que define el ataque.

7.2 Honey admin

Variante del mismo principio aplicada a cuentas administrativas: una cuenta con nombre plausible de administrador (por ejemplo, siguiendo la misma convención de nomenclatura que las cuentas de Domain Admin reales del dominio) que no pertenece a ningún grupo privilegiado real ni tiene permisos efectivos, pero que un atacante que enumera el dominio con BloodHound identificaría como objetivo atractivo por su nombre. Cualquier intento de autenticación, cualquier consulta LDAP dirigida específicamente a sus atributos, o cualquier intento de added-to-group sobre ella es una señal de alta confianza. Se puede reforzar añadiéndole atributos falsos que sugieran privilegios delegados (por ejemplo, en la descripción) para hacerla aún más atractiva en una recolección de BloodHound.

7.3 Honeypots de AD (más allá de la cuenta individual)

El concepto se extiende más allá de una sola cuenta: un honeypot de AD puede ser un equipo señuelo unido al dominio, sin función real, expuesto para que parezca un objetivo atractivo en un escaneo de red o en una recolección de BloodHound (por ejemplo, con nombre de servidor de gestión o de DC secundario). Cualquier tráfico de autenticación o movimiento lateral contra ese equipo es, igual que con la honey account, una señal de altísima confianza al no existir flujo de trabajo legítimo que lo justifique. Herramientas comerciales (Illusive Networks, Thinkst Canary) y las «honeytoken accounts» nativas de MDI automatizan el despliegue y la credibilidad de estos señuelos a mayor escala.

7.4 Creación paso a paso de la honey account

Crear la cuenta con un nombre plausible dentro de la convención de nomenclatura del dominio (ni demasiado genérico, ni obviamente falso):
```
New-ADUser -Name "svc-sql-backup" `
    -SamAccountName "svc-sql-backup" `
    -UserPrincipalName "svc-sql-backup@corp.local" `
    -AccountPassword (ConvertTo-SecureString `
        (-join ((48..57)+(65..90)+(97..122)+(33,35,36,37,38) | Get-Random -Count 32 | ForEach-Object {[char]$_})) `
        -AsPlainText -Force) `
    -Enabled $true `
    -PasswordNeverExpires $true `
    -Description "Cuenta de servicio - backup SQL nocturno"
```
La contraseña generada aleatoriamente de 32 caracteres con el rango de códigos ASCII anterior (dígitos, mayúsculas, minúsculas y símbolos comunes) hace que un crackeo offline del hash sea inviable en tiempos razonables incluso si el atacante llega a obtener el ticket. PasswordNeverExpires se activa a propósito: si la contraseña rota, hay que volver a comprobar que nadie la está usando realmente en ningún sitio (paso 2), y una honey account no debería generar tickets de renovación de contraseña que puedan confundirse con actividad real.

Asignarle un SPN atractivo, coherente con el nombre elegido:

setspn -A MSSQLSvc/sql-backup01.corp.local:1433 svc-sql-backup

# Verificación
setspn -L svc-sql-backup

Confirmar que la cuenta no tiene privilegios reales (miembro únicamente de «Domain Users», sin pertenencia a ningún grupo con delegación ni ACL especial), para que, si llega a comprometerse el hash pese a la longitud de la contraseña, el impacto sea nulo:
```
Get-ADUser -Identity svc-sql-backup -Properties MemberOf | Select-Object -ExpandProperty MemberOf
```

Configurar la SACL de auditoría sobre la propia cuenta para asegurar que cualquier acceso a sus propiedades queda registrado, además del 4769 estándar que ya se genera para cualquier TGS-REQ sin configuración adicional:

$acl = Get-Acl "AD:CN=svc-sql-backup,OU=ServiceAccounts,DC=corp,DC=local"
$sacl = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    (New-Object System.Security.Principal.NTAccount("Everyone")),
    "ReadProperty,GenericExecute",
    "Success"
)
$acl.AddAuditRule($sacl)
Set-Acl "AD:CN=svc-sql-backup,OU=ServiceAccounts,DC=corp,DC=local" $acl

Construir la alerta sobre el 4769 de esta cuenta específica — a diferencia de la regla general de Kerberoasting de la sección 4, aquí no hace falta volumen ni filtro de falsos positivos: cualquier 4769 para este SPN es una alerta crítica.
```
SecurityEvent
| where EventID == 4769
| where ServiceName == "svc-sql-backup"
| project TimeGenerated, TargetUserName, IpAddress, ServiceName, TicketEncryptionType
| extend AlertSeverity = "Critical", AlertType = "Honeytoken Kerberoasting Trigger"
```
En Sentinel, esta consulta se guarda como regla de análisis programada (cada 5 minutos, sin umbral de agregación) con severidad «High» o «Critical» y acción automática de notificación inmediata al SOC — es, junto con la detección nativa de honeytoken de MDI (que ofrece un mecanismo equivalente ya integrado, marcando una cuenta como «honeytoken» desde su consola), una de las alertas de mayor señal/ruido de todo el programa de detección, precisamente por no depender de ningún umbral.

8. Herramientas de evaluación de postura del dominio

Las reglas de detección y el deception cubren el «¿me están atacando ahora mismo?». Falta la pregunta complementaria: «¿cuánta superficie de ataque tiene mi dominio hoy?». Para responderla de forma sistemática y repetible existen varias herramientas especializadas en auditar la postura de seguridad de AD:

PingCastle: referencia en el mercado hispanohablante y europeo para auditoría rápida de AD. Ejecuta un healthcheck completo sin privilegios elevados (basta una cuenta de dominio estándar) y genera un informe con una puntuación de riesgo (0-100, cuanto más alto peor) en cuatro categorías: Stale Objects (objetos obsoletos), Privileged Accounts, Trusts y Anomalies. El informe HTML es fácil de compartir y comparar mes a mes.
Purple Knight (Semperis): gratuita, centrada en indicadores de exposición (IOE) por categoría de ataque (Kerberos, ACL, replicación, GPO, confianza), con severidad por hallazgo; complemento —no sustituto— de PingCastle, con motor y reglas independientes.
BloodHound en modo defensivo (azul): la misma herramienta que un atacante usa para hallar rutas hacia Domain Admin, ejecutada proactivamente por el equipo de seguridad para encontrar y cerrar esas rutas antes que el adversario (pertenencias a grupo innecesarias, ACL delegadas, Tier Model). Usarlo de forma recurrente es la validación definitiva de si el hardening de módulos anteriores surte efecto real.
ORADAD: herramienta francesa gratuita que audita la configuración del dominio de forma similar a PingCastle, con foco en cumplimiento de guías de hardening; útil como segunda opinión independiente sobre los mismos hallazgos.
Microsoft Secure Score (Microsoft 365 Defender / Entra ID): no es específica de AD on-prem, pero en entornos híbridos aporta una puntuación consolidada de identidad, dispositivos y aplicaciones, con recomendaciones ligadas a Defender for Identity y Entra ID (MFA, Conditional Access) que complementan la vista on-prem.

El valor real está en convertirlas en proceso periódico: ejecutar PingCastle o Purple Knight con cadencia mensual o trimestral, guardar el histórico de puntuaciones y tratar cualquier empeoramiento como un hallazgo que exige explicación, igual que una alerta de detección. Eso convierte una auditoría puntual en una métrica de madurez: un dominio maduro no es el que tuvo puntuación perfecta una vez, sino el que la mantiene estable o en mejora ejecución tras ejecución.

Laboratorio: honey account con SPN y alerta sobre su 4769

Objetivo: en tu dominio de laboratorio, crear una honey account completa con SPN, confirmar que genera el evento 4769 esperado al ser consultada, y construir la consulta de alerta que la vigila.

Crea la cuenta señuelo con el comando de la sección 7.4 (paso 1), adaptando el nombre y la OU a tu laboratorio (por ejemplo OU=ServiceAccounts,DC=lab,DC=local).
Asígnale el SPN (paso 2) y verifica con setspn -L que quedó registrado correctamente y que no colisiona con ningún otro SPN existente en el dominio (setspn -X para comprobar duplicados).
Confirma que la cuenta no tiene privilegios (paso 3) y documenta su pertenencia a grupos.
Desde otro equipo del laboratorio, con una cuenta de usuario de prueba distinta (simulando al «atacante»), solicita explícitamente un ticket de servicio contra el SPN de la honey account, por ejemplo con Add-Type -AssemblyName System.IdentityModel y New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken apuntando al SPN, o simplemente accediendo a cualquier recurso que fuerce la resolución de ese SPN.

Verifica en el controlador de dominio que se generó el evento 4769 correspondiente, y anota el valor del campo TicketEncryptionType:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddMinutes(-10)} |
  Where-Object { $_.Message -match 'svc-sql-backup' } |
  Select-Object TimeCreated, Message

Construye la consulta de alerta de la sección 7.4 (paso 5) adaptada a tu SIEM de laboratorio (o, si no dispones de uno, documenta la lógica equivalente como una tarea programada de PowerShell que revise cada 5 minutos el log de seguridad filtrando por el SPN de la honey account y envíe una notificación —correo, webhook— si encuentra coincidencias).
Documenta en un informe breve: el nombre y SPN elegidos, por qué son plausibles dentro de la convención de tu dominio de laboratorio, la longitud y complejidad de la contraseña generada, y el resultado de la prueba de disparo (capturas del 4769 y de la alerta generada).

Errores comunes

Poner umbrales de volumen sin baseline previa. Fijar «más de 10 SPN en 5 minutos = alerta» sin haber medido antes cuántos SPN distintos solicita normalmente, por ejemplo, un servidor de aplicaciones legítimo con muchas integraciones, genera una alerta que o bien nunca deja de dispararse (ruido, el analista la acaba ignorando) o bien se sube tanto el umbral para silenciarla que deja de detectar ataques reales con volumen moderado. La baseline se construye ejecutando la consulta en modo «solo informe» durante al menos una o dos semanas antes de convertirla en alerta activa.
No ejecutar PingCastle (o equivalente) de forma periódica. Ejecutarlo una vez, arreglar los hallazgos «Critical» y no volver a correrlo nunca más es el patrón más habitual de degradación silenciosa: la configuración del dominio cambia constantemente (nuevas cuentas de servicio, nuevas delegaciones, nuevos grupos anidados) y la puntuación de riesgo sube gradualmente sin que nadie lo note hasta la siguiente auditoría externa o, peor, hasta el incidente.
Confundir «tener MDI desplegado» con «tener todas las detecciones activas y revisadas». MDI requiere que alguien revise sus alertas en Microsoft Defender XDR; un sensor desplegado cuyas alertas nadie mira aporta el mismo valor que no tenerlo.
Honey accounts con nombres o contraseñas obviamente falsos. Una cuenta llamada HONEYPOT_NO_USAR o con contraseña «Password123» no engaña a nadie que use herramientas automatizadas de reconocimiento (que no leen el nombre, simplemente listan todo lo que tiene SPN) pero sí puede ser identificada y evitada por un atacante manual experimentado. Conviene que se integre en la convención de nomenclatura real del dominio.
Excluir sistemáticamente las cuentas de máquina ($) de todas las reglas de Kerberoasting sin revisar por qué generan RC4. El filtro de la sección 4 es necesario para reducir ruido, pero si un número significativo de cuentas de equipo sigue usando RC4, es en sí mismo un hallazgo de hardening pendiente (ver el módulo de entornos legacy), no solo un falso positivo a ignorar.
Desplegar reglas Sigma genéricas descargadas de un repositorio sin adaptarlas al propio dominio. Los falsepositives documentados en una regla pública no cubren las particularidades de cada entorno (aplicaciones legacy, cuentas de servicio con nombres inusuales); toda regla importada debe pasar por un periodo de ajuste con los datos reales del SIEM de destino.

Ejercicio

Sobre tu laboratorio de AD con auditoría avanzada ya habilitada (módulo anterior):

Escribe una regla Sigma completa (siguiendo el esquema de la sección 4) para detectar AS-REP Roasting: evento 4768 con Pre-Authentication Type igual a 0 y TicketEncryptionType 0x17, incluyendo title, id, logsource, detection, falsepositives, level y tags (la sub-técnica MITRE correspondiente es T1558.004).
Convierte esa regla a una consulta KQL equivalente, añadiendo la capa de correlación por volumen que corresponda (o, en este caso, justifica por qué un único evento con esas características ya es suficiente para alertar sin necesidad de umbral, comparándolo con el caso de Kerberoasting).
Crea una segunda honey account, esta vez configurada deliberadamente con DONT_REQUIRE_PREAUTH activado, y documenta el 4768 resultante que genera al ser consultada, siguiendo el mismo procedimiento que en el laboratorio de la sección anterior pero adaptado a AS-REP Roasting.
Ejecuta PingCastle (o Purple Knight) contra tu dominio de laboratorio, guarda la puntuación de riesgo obtenida, remedia al menos un hallazgo de severidad alta, y vuelve a ejecutar la herramienta para confirmar la mejora de puntuación. Documenta el antes/después.

Preguntas frecuentes

¿Por qué la regla Sigma de Kerberoasting no incluye directamente el umbral de volumen en el YAML?

Porque la portabilidad de Sigma entre backends es más limitada cuanto más compleja es la lógica de correlación: no todos implementan la agregación exactamente igual. La práctica de la comunidad SigmaHQ es mantener la regla centrada en la señal atómica más portable (el tipo de cifrado) y resolver el volumen con una regla de correlación nativa del SIEM de destino, como en la sección 5 con KQL, donde el umbral se ajusta con datos reales de cada entorno.

¿MDI sustituye a las reglas Sigma sobre el SIEM, o son complementarios?

Son complementarios. MDI aporta visibilidad de red y modelos mantenidos por Microsoft que van más allá de un Event ID individual, y correlaciona por entidad. Las reglas Sigma sobre el SIEM aportan flexibilidad total (señales a medida, incluidas las honey accounts) y centralizan la correlación con el resto de fuentes de seguridad (firewall, EDR, proxy) que MDI no cubre. Un programa maduro usa ambos.

¿Cuántas honey accounts son razonables en un dominio de tamaño medio?

No hay un número universal, pero la práctica habitual es empezar con dos o tres: una honey account con SPN orientada a Kerberoasting, una honey admin orientada a enumeración/BloodHound, y opcionalmente una cuenta con DONT_REQUIRE_PREAUTH orientada a AS-REP Roasting. Añadir decenas sin un proceso claro de mantenimiento añade complejidad operativa sin aumentar la señal proporcionalmente.

¿Con qué frecuencia hay que ejecutar PingCastle o Purple Knight para que aporten valor real?

Mensual como mínimo en dominios con cambios frecuentes; trimestral como mínimo absoluto en dominios muy estables. Lo determinante no es la cadencia exacta sino la consistencia: la misma periodicidad, histórico de puntuación y cada regresión tratada como hallazgo que requiere explicación, frente a una auditoría puntual que se olvida en un cajón.

¿Un Golden Ticket puede evadir por completo la detección basada en el par 4768/4769?

Puede evitar el 4768, pero no puede evitar que el 4769 generado al usar el TGT forjado quede registrado en el DC que atiende esa petición TGS, salvo que además borre el log de seguridad —lo que genera a su vez el evento 1102, alerta crítica en sí misma—. Por eso la correlación 4768↔4769 junto con la vigilancia del 1102 sigue siendo una de las técnicas de detección de Golden Ticket más citadas: cerrar una vía obliga al atacante a abrir otra igualmente ruidosa.

«Microsoft Defender for Identity monitors and analyzes user activities and information across your network, such as permissions and group membership, to identify suspicious activities and advanced attacks throughout the cyberattack kill chain. […] Defender for Identity’s design principles deliver these unique values: identify advanced attacks across the cyberattack kill chain, including reconnaissance, compromised credentials, lateral movements, and domain dominance.»

— Microsoft, «What is Microsoft Defender for Identity?», Microsoft Learn, Microsoft Defender for Identity documentation.

Módulo 11: Monitorización de AD II — detección de ataques, deception y herramientas