🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Defensa y Bastionado de Active Directory
Módulo 7 de 13

Módulo 7: Ataques clásicos a Active Directory y cómo defenderse

Módulo 7: Ataques clásicos a Active Directory y cómo defenderse

Aviso ético y legal: este módulo describe técnicas de ataque contra Active Directory (Kerberoasting, AS-REP Roasting, Pass-the-Hash, Pass-the-Ticket, DCSync, DCShadow, Golden/Silver Ticket) con un propósito exclusivamente defensivo: entender su funcionamiento lo suficiente para detectarlas y prevenirlas. No es un tutorial ofensivo ni sustituye la formación reglada en pentesting. Las herramientas mencionadas (Mimikatz, Rubeus, Impacket, BloodHound) son de uso dual y su ejecución contra sistemas que no sean de tu propiedad o sin autorización expresa por escrito constituye delito de acceso ilícito a sistemas informáticos (art. 197 bis y ss. del Código Penal español), y en el ámbito de la UE puede incurrir en la Directiva NIS2 y la Convención de Budapest sobre Ciberdelincuencia. Practica únicamente en un dominio Active Directory desechable de laboratorio (un bosque en VMware/VirtualBox con Windows Server Evaluation y clientes Windows 10/11 unidos al dominio), nunca contra el AD de tu empresa sin una autorización de pentest firmada y con alcance definido.

Qué aprenderás

Este módulo recorre las técnicas de ataque a Active Directory más citadas en la literatura de seguridad (SANS FOR610/SEC560, el blog adsecurity.org de Sean Metcalf y los boletines de Microsoft) y, para cada una, profundiza en su detección y prevención. Al terminar serás capaz de:

  • Explicar a nivel conceptual cómo funcionan Kerberoasting, AS-REP Roasting, Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, DCSync, DCShadow y la falsificación de tickets Golden/Silver, sin necesidad de ejecutarlos.
  • Identificar los Event IDs de Windows Security y los campos concretos (Ticket Encryption Type, Failure Code, GUID de derecho replicado) que delatan cada técnica.
  • Escribir consultas reales con wevtutil y Get-WinEvent para cazar Kerberoasting y DCSync en los logs de un controlador de dominio.
  • Diseñar contramedidas estructurales: gMSA, contraseñas largas, cifrado AES, LAPS, Protected Users, Credential Guard, tiering de administración y rotación del hash de krbtgt.
  • Reconocer el papel defensivo de conocer herramientas ofensivas como Mimikatz, Rubeus, Impacket y BloodHound: qué ruido dejan y cómo se cazan.
  • Mapear cada técnica a su identificador real de MITRE ATT&CK para integrarla en un programa de detección basado en el framework.

1. Kerberoasting: SPN en cuentas de usuario y tickets crackeables offline

Cuando una cuenta tiene un Service Principal Name (SPN) registrado —típico de cuentas de servicio de SQL Server, IIS o aplicaciones legacy—, cualquier usuario autenticado del dominio puede solicitar al KDC un Ticket Granting Service (TGS) para ese SPN sin credenciales adicionales: es comportamiento normal de Kerberos. La parte del TGS que da acceso al servicio va cifrada con el hash de la contraseña de la cuenta de servicio. Si esa cuenta usa cifrado RC4 (heredado, habitual cuando no se ha forzado AES) y una contraseña débil, el atacante extrae el ticket y lo crackea offline, sin generar más tráfico contra el dominio, hasta recuperar la contraseña en claro.

El riesgo estructural es que cualquier usuario de dominio, sin privilegios especiales, puede solicitar TGS para todos los SPN existentes en un único barrido (Rubeus kerberoast o GetUserSPNs.py de Impacket automatizan la enumeración), lo que convierte Kerberoasting en una de las rutas de escalado más rentables para quien solo dispone de credenciales de un usuario estándar.

1.1 Detección

El evento clave es el 4769 (A Kerberos service ticket was requested), registrado en el controlador de dominio:

  • Ticket Encryption Type = 0x17 (RC4-HMAC) para un SPN de servicio, en un entorno donde el resto del tráfico usa AES (0x12 = AES128, 0x11 = AES256). Un salto puntual a RC4 es la firma más citada de Kerberoasting, porque las herramientas ofensivas fuerzan RC4 al pedir el TGS (más rápido de crackear).
  • Volumen anómalo de 4769: un único usuario solicitando TGS para decenas o cientos de SPN distintos en minutos, cuando su patrón habitual es acceder a uno o dos servicios.
  • Failure Code = 0x0 (éxito) con un Service Name que no es krbtgt y un Client Address ajeno al segmento habitual del usuario.
# Buscar peticiones de TGS con cifrado RC4 (0x17) en las últimas 24 horas
wevtutil qe Security /q:"*[System[(EventID=4769)] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" /f:text /c:100

# Excluyendo al propio krbtgt y a cuentas de máquina (terminadas en $)
wevtutil qe Security /q:"*[System[(EventID=4769)] and EventData[Data[@Name='TicketEncryptionType']='0x17' and Data[@Name='ServiceName']!='krbtgt']]" /f:text /c:100

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
  Where-Object { $_.Properties[8].Value -eq '0x17' -and $_.Properties[3].Value -notlike '*$' } |
  Select-Object TimeCreated, @{n='Cuenta';e={$_.Properties[0].Value}}, @{n='SPN';e={$_.Properties[3].Value}}, @{n='ClientAddress';e={$_.Properties[6].Value}} |
  Group-Object Cuenta | Sort-Object Count -Descending | Select-Object Count, Name -First 20

Umbral razonable para el SIEM: más de 5-10 SPN distintos solicitados por la misma cuenta en menos de 5 minutos, o cualquier 4769 con RC4 para un SPN de alto valor.

1.2 Prevención

  • gMSA (group Managed Service Accounts): contraseñas de 240 caracteres generadas y rotadas automáticamente cada 30 días, que hacen inviable el crackeo offline. Migrar cuentas de servicio legacy a gMSA es la contramedida estructural más efectiva.
  • Contraseñas de 25+ caracteres aleatorios donde no sea viable gMSA, para que el crackeo offline sea computacionalmente inviable incluso con RC4.
  • Forzar AES: configurar msDS-SupportedEncryptionTypes para excluir RC4 y exigir AES128/256, y desactivar RC4 a nivel de dominio con la GPO Network security: Configure encryption types allowed for Kerberos. No impide la petición del TGS, pero encarece enormemente el crackeo.
  • Auditoría periódica de SPN con setspn -Q */* o Get-ADUser -Filter {ServicePrincipalName -ne "$null"}, priorizando la migración de cuentas privilegiadas con SPN.
  • Mínimo privilegio: ninguna cuenta con SPN debería pertenecer a Domain Admins; si el ticket se crackea, el impacto queda contenido.

2. AS-REP Roasting: cuentas sin preautenticación Kerberos

Kerberos normal exige preautenticación: antes de emitir un TGT, el KDC comprueba que el cliente puede cifrar una marca de tiempo con el hash de su contraseña. Si una cuenta tiene el flag DONT_REQ_PREAUTH («No requiere autenticación previa de Kerberos» en ADUC), el KDC responde a cualquier petición de TGT sin comprobar nada, y el AS-REP incluye una porción cifrada con el hash de la contraseña. Como en Kerberoasting, esa porción se crackea offline, con la diferencia de que ni siquiera hacen falta credenciales válidas de dominio: basta conocer el nombre de una cuenta vulnerable (GetNPUsers.py de Impacket o Rubeus asreproast automatizan la enumeración).

2.1 Detección

Evento clave: 4768 (A Kerberos authentication ticket (TGT) was requested).

  • Pre-Authentication Type = 0 en un 4768 exitoso: no hubo preautenticación. En un dominio bien configurado debería ser rareza, no norma.
  • Ticket Encryption Type = 0x17 (RC4) combinado con Pre-Authentication Type 0: la respuesta cifrada con el hash de la cuenta facilita el crackeo.
  • Múltiples 4768 con Pre-Authentication Type 0 para cuentas distintas desde el mismo origen: enumeración activa de cuentas vulnerables, no uso legítimo puntual.
# Buscar TGT emitidos sin preautenticación (Pre-Authentication Type 0)
wevtutil qe Security /q:"*[System[(EventID=4768)] and EventData[Data[@Name='PreAuthType']='0']]" /f:text /c:100

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768} |
  Where-Object { $_.Properties[13].Value -eq 0 } |
  Select-Object TimeCreated, @{n='Cuenta';e={$_.Properties[0].Value}}, @{n='IP';e={$_.Properties[9].Value}}

2.2 Prevención

  • Auditar y eliminar DONT_REQ_PREAUTH de toda cuenta que no lo requiera explícitamente (algunos clientes MIT Kerberos legacy sí lo necesitan). Consulta: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth.
  • Contraseñas robustas y MFA donde el flag deba mantenerse por requisito técnico.
  • Preautenticación activada por defecto en las plantillas de creación de cuentas, revisada en cada auditoría de AD.
  • Monitorización continua: el flag puede reactivarse por un script de aprovisionamiento mal configurado o de forma deliberada como persistencia.

3. Pass-the-Hash y Pass-the-Ticket

Pass-the-Hash (PtH) aprovecha que en NTLM nunca se transmite la contraseña en claro: el desafío-respuesta usa directamente el hash NTLM. Si un atacante lo extrae de LSASS (Mimikatz sekurlsa::logonpasswords) puede autenticarse como esa cuenta en cualquier sistema donde el hash sea válido, sin conocer la contraseña real. Pass-the-Ticket (PtT) es el equivalente Kerberos: se extrae un ticket (TGT o TGS) de la memoria de una sesión (Mimikatz sekurlsa::tickets, Rubeus dump) y se inyecta en otra sesión o máquina para reutilizarlo sin volver a autenticar.

3.1 Detección

  • Pass-the-Hash: 4624 Type 3 con Authentication Package = NTLM y Key Length = 0, en un entorno donde Kerberos debería dominar. La ausencia del 4768/4769 esperado en el DC para esa cuenta es señal adicional.
  • Pass-the-Ticket: el mismo ticket/Logon ID apareciendo en hosts distintos en una ventana incompatible con el desplazamiento de un usuario humano; o un 4624 Kerberos válido sin el 4769 previo coherente en el DC.
  • 4648 (logon con credenciales explícitas) en el host origen justo antes de un 4624 remoto, si ese host no usa habitualmente runas.
  • Sysmon Event ID 10 (ProcessAccess) con TargetImage = lsass.exe y GrantedAccess de lectura de memoria (p. ej. 0x1010/0x1438) desde un proceso que no es EDR/AV legítimo: indicador directo de volcado de credenciales previo al PtH.
# Detectar accesos a LSASS típicos de Mimikatz vía Sysmon
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=10} |
  Where-Object { $_.Properties[7].Value -like '*lsass.exe*' -and $_.Properties[7].Value -notlike '*MsMpEng*' } |
  Select-Object TimeCreated, @{n='SourceImage';e={$_.Properties[4].Value}}, @{n='GrantedAccess';e={$_.Properties[10].Value}}

3.2 Prevención

  • LAPS (Windows LAPS): contraseña de administrador local única por equipo y rotada automáticamente; un hash robado en una máquina no sirve para moverse a otra.
  • Protected Users: sus miembros no pueden autenticarse con NTLM y fuerzan TGT de vida corta sin delegación, reduciendo la superficie de PtH/PtT en cuentas privilegiadas.
  • Credential Guard: aísla LSASS en un contenedor VBS para que ni SYSTEM pueda volcar hashes NTLM ni tickets con las técnicas clásicas de Mimikatz.
  • Tiering (Tier 0/1/2): separar qué cuentas administran DC, servidores y estaciones de trabajo, de forma que un hash robado en una estación de trabajo nunca corresponda a una cuenta con privilegios sobre el DC (modelo ESAE / Privileged Access Workstations de Microsoft).
  • Restringir NTLM vía GPO (Network security: Restrict NTLM), forzando Kerberos como mecanismo único en redes internas modernas.

4. Overpass-the-Hash (Pass-the-Key)

Variante híbrida: en lugar de reutilizar el hash NTLM contra NTLM, el atacante lo usa para solicitar un TGT legítimo de Kerberos (Mimikatz sekurlsa::pth, Rubeus asktgt con el hash como clave). Obtiene así un ticket Kerberos válido sin conocer la contraseña en claro, moviéndose con Kerberos «limpio» en lugar de NTLM y evadiendo controles centrados solo en tráfico NTLM anómalo.

4.1 Detección y prevención

  • Indicador principal: un 4768 con Pre-Authentication Type 2 sin sesión interactiva o de red previa coherente para esa cuenta desde ese origen — el TGT se pide «de la nada».
  • La correlación entre Sysmon ID 10 sobre LSASS y un 4768 inmediatamente posterior desde el mismo host es la cadena de evidencia más sólida.
  • Contramedidas idénticas a Pass-the-Hash: Credential Guard impide el volcado inicial, Protected Users/tiering limitan el impacto si ocurre igualmente.

5. DCSync: abuso de derechos de replicación

DCSync no explota una vulnerabilidad de software: abusa de un derecho legítimo. Los controladores de dominio se sincronizan vía MS-DRSR (Directory Replication Service Remote Protocol), y cualquier cuenta con los derechos extendidos DS-Replication-Get-Changes y DS-Replication-Get-Changes-All sobre el objeto de dominio puede pedir a un DC real que le «replique» datos, incluidos los hashes de cualquier cuenta —típicamente krbtgt o un Domain Admin—, sin ejecutar código en el propio DC. Por defecto solo Domain Admins, Enterprise Admins y los DC tienen estos derechos, pero delegaciones mal configuradas (una cuenta de backup, un conector de sincronización con Entra ID mal alcanzado) crean rutas de abuso silenciosas.

5.1 Detección

Evento clave: 4662 (An operation was performed on an object) en el DC, que requiere Audit Directory Service Access más una SACL configurada sobre el objeto de dominio. El campo decisivo es el GUID del derecho extendido:

  • 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 — DS-Replication-Get-Changes
  • 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 — DS-Replication-Get-Changes-All
  • 89e95b76-444d-4c62-991a-0facbeda640c — DS-Replication-Get-Changes-In-Filtered-Set (relevante con RODC)

La detección cruza: un 4662 con alguno de estos GUID en Properties, cuyo Subject no es un controlador de dominio conocido (los DC legítimos generan este tráfico constantemente entre sí; el problema es un origen que no es DC).

# Buscar 4662 con el GUID de DS-Replication-Get-Changes-All (indicador de DCSync)
wevtutil qe Security /q:"*[System[(EventID=4662)] and EventData[Data[@Name='Properties']='*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*']]" /f:text /c:50

# Filtrando por el GUID y excluyendo cuentas de equipo de DC conocidas
$dcs = (Get-ADDomainController -Filter *).Name
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} |
  Where-Object { $_.Message -match '1131f6a(a|d)-9c07-11d1-f79f-00c04fc2dcd2' } |
  Select-Object TimeCreated, @{n='Subject';e={$_.Properties[1].Value}}, @{n='ObjectName';e={$_.Properties[6].Value}} |
  Where-Object { $dcs -notcontains ($_.Subject -replace '$$','') }

Complementariamente, Impacket secretsdump.py en modo DCSync genera tráfico DRSUAPI (RPC/135) hacia el DC desde un host que normalmente no es DC; un IDS/NDR o Zeek con analizador DCE-RPC puede correlacionar ese origen anómalo como segunda señal independiente del log.

5.2 Prevención

  • Auditar quién tiene DS-Replication-Get-Changes[-All] con BloodHound o dsacls/PowerShell, revocando cualquier delegación que no sea Domain Admins, Enterprise Admins, DC o una cuenta de sincronización explícitamente auditada (p. ej. Entra Connect).
  • Habilitar la SACL de auditoría sobre el objeto de dominio raíz: sin ella el 4662 no se genera aunque la categoría esté activa.
  • Tiering: cualquier cuenta con derechos de replicación equivale a Domain Admin y debe protegerse igual (MFA, PAW, sin uso interactivo en estaciones estándar).
  • Alertar en tiempo real ante cualquier 4662 con estos GUID desde origen no-DC: uno de los eventos con menor tasa de falsos positivos de todo AD.

6. DCShadow: registrar un controlador de dominio falso

DCShadow va un paso más allá de DCSync: en lugar de solo leer vía replicación, el atacante (ya con privilegios de Domain Admin) registra temporalmente un equipo bajo su control como controlador de dominio legítimo (creando los objetos nTDSDSA en la partición de configuración) e inyecta cambios arbitrarios que se replican al resto de DC reales como si fueran legítimos. Permite, por ejemplo, modificar SID History o ACL sin pasar por los mecanismos de auditoría estándar de un DC real, porque el cambio se origina en un «DC» que existe solo el tiempo necesario para inyectarlo y desregistrarse.

6.1 Detección y prevención

  • Es técnica post-explotación que ya requiere privilegios elevados, así que la primera defensa es la misma que para cualquier abuso de Tier 0: impedir llegar a ese nivel de privilegio.
  • Monitorizar creación/eliminación de objetos nTDSDSA en la partición de configuración (Event ID 5137), sobre todo si el objeto aparece y desaparece en minutos.
  • Auditar metadatos de replicación (repadmin /showobjmeta) para detectar atributos cuya última modificación se originó en un «DC» inexistente.
  • Restringir estrictamente quién puede escribir en CN=Configuration: solo Domain/Enterprise Admins de confianza.

7. Golden Ticket y Silver Ticket

Ambas forjan tickets Kerberos válidos sin pasar por el KDC, usando un hash robado previamente:

  • Golden Ticket: se forja un TGT completo con el hash de krbtgt (la cuenta que firma todos los TGT del dominio). Permite crear un TGT para cualquier usuario —incluso inexistente—, con cualquier grupo de pertenencia y la vida útil que se quiera, sin que el DC lo haya emitido realmente. Es la persistencia más potente en un dominio comprometido: sobrevive a cambios de contraseña individuales y solo se neutraliza rotando el hash de krbtgt.
  • Silver Ticket: se forja directamente un TGS con el hash de una cuenta de servicio o de equipo, dando acceso solo al servicio asociado, sin involucrar al KDC. Más sigiloso que el Golden Ticket porque nunca genera tráfico contra el DC, pero limitado al servicio cuyo hash se robó.

7.1 Detección

  • Golden Ticket: al forjarse offline, el 4768 original no existe en el DC, pero sí aparecen 4769 usando el TGT falsificado. Anomalías típicas: Ticket Lifetime fuera de la GPO estándar (10 horas por defecto); un RID que no corresponde a ningún objeto real (herramientas antiguas usaban RID 500 por defecto); y, sobre todo, actividad de una cuenta con contraseña cambiada o deshabilitada que sigue autenticándose con éxito, porque el Golden Ticket no depende de la contraseña actual, solo del hash de krbtgt.
  • Silver Ticket: 4624 Type 3 con Kerberos aparentemente válido en el destino, sin el 4769 correspondiente en el DC — el ticket nunca pasó por el KDC.
  • Anomalías de vida útil de TGT: Microsoft Defender for Identity y reglas Sigma específicas («Golden Ticket») comparan MaxTicketAge configurado contra la vida real observada, alertando cuando difiere.
# Correlacionar 4769 sin 4768 previo coherente para la misma cuenta en la ventana de vida del ticket
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 500 |
  ForEach-Object {
    $cuenta = $_.Properties[0].Value
    $previo = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768; StartTime=$_.TimeCreated.AddHours(-10)} -MaxEvents 50 |
      Where-Object { $_.Properties[0].Value -eq $cuenta }
    if (-not $previo) { [PSCustomObject]@{Time=$_.TimeCreated; Cuenta=$cuenta; Servicio=$_.Properties[3].Value} }
  }

7.2 Prevención

  • Rotar el hash de krbtgt dos veces consecutivas: AD conserva el hash anterior como válido durante una generación, así que hay que rotarlo dos veces (con al menos la vida máxima del ticket entre medias) para invalidar cualquier Golden Ticket forjado con el hash antiguo. Microsoft proporciona New-KrbtgtKeys.ps1 para automatizarlo.
  • Rotación periódica programada, no solo reactiva tras incidente, junto con la rotación de contraseñas de cuentas de servicio con SPN.
  • Minimizar la exposición del hash de krbtgt: solo se roba vía DCSync o acceso directo a NTDS.dit, así que toda la protección de Tier 0 lo reduce indirectamente.
  • Para Silver Ticket: las mismas medidas de protección de hash de cuenta de servicio (gMSA, contraseñas largas, AES), más la monitorización activa de la discrepancia 4624/4769.

8. Enumeración con BloodHound: mapeo de rutas de ataque

BloodHound no es un exploit: es una herramienta de análisis de grafos que recolecta datos de AD (LDAP, y con SharpHound también sesiones SMB/WinRM y membresías de grupos locales) y los modela como un grafo de relaciones (usuario → miembro de grupo → tiene GenericAll sobre → objeto → es Domain Admin), visualizando automáticamente rutas de escalado de privilegios difíciles de detectar manualmente en un dominio con miles de objetos y ACL heredadas. Es tan útil para atacantes como para equipos defensivos que la usan para auditar su propio entorno (BloodHound Community Edition y Enterprise se usan ampliamente en programas de higiene de AD).

8.1 Detección

  • Volumen anómalo de consultas LDAP desde un único origen: SharpHound genera un patrón de enumeración masiva muy característico, detectable con Microsoft Defender for Identity (que tiene detecciones nativas para «reconnaissance» BloodHound) o reglas Sigma sobre logs de Directory Service.
  • NetSessionEnum masivo contra múltiples equipos desde un mismo host, correspondiente a la recolección de sesiones activas que hace SharpHound.
  • Artefactos en disco en la variante local: ficheros ZIP con patrón YYYYMMDDHHMMSS_BloodHound.zip, detectables por Sysmon Event ID 11.

8.2 Prevención

  • Reducir las rutas de ataque, no solo detectar la herramienta: el valor de correr BloodHound defensivamente es identificar y eliminar ACL peligrosas (GenericAll, GenericWrite, WriteDACL, ForceChangePassword mal delegadas) antes de que un atacante las use.
  • Revisión periódica de ACL delegadas sobre objetos de alto valor, buscando delegaciones heredadas de migraciones antiguas o de personal que ya no trabaja en la organización.
  • Limitar la enumeración de sesiones donde sea viable (mitigación de Microsoft para NetSessionEnum), sabiendo que bloquear la lectura LDAP básica sin romper funcionalidad legítima es difícil.
  • Tiering: aunque BloodHound mapee todas las rutas posibles, si las cuentas Tier 0 nunca inician sesión en máquinas Tier 2, la mayoría resultan inviables en la práctica.

9. Herramientas ofensivas a conocer con fines defensivos

  • Mimikatz: referencia histórica para extracción de credenciales de LSASS (sekurlsa::logonpasswords), tickets (sekurlsa::tickets) y forja de Golden/Silver Tickets (kerberos::golden). Deja huella de acceso a LSASS (Sysmon ID 10); las variantes modernas evaden firmas estáticas, así que la detección basada en comportamiento es más robusta que la basada en firma.
  • Rubeus: centrada en Kerberos puro (kerberoasting, asreproasting, manipulación de tickets, ataques S4U). Su tráfico se refleja íntegramente en los Event IDs Kerberos ya descritos (4768, 4769, 4771); no siempre requiere volcar LSASS, lo que la hace más sigilosa frente a EDR centrados solo en accesos a memoria.
  • Impacket (secretsdump.py, GetUserSPNs.py, GetNPUsers.py, wmiexec.py, psexec.py): al operar remotamente desde Linux/Python, su tráfico NTLM/SMB suele mostrar patrones ligeramente distintos de las herramientas nativas de Windows, útiles como señal adicional en NDR.
  • BloodHound/SharpHound: huella en volumen LDAP y enumeración de sesiones SMB; usada defensivamente, es la que más reduce el riesgo estructural del resto de técnicas de este módulo.

10. Tabla maestra: ataque, MITRE ATT&CK, detección y contramedida

Ataque Técnica MITRE ATT&CK Event ID / señal de detección Contramedida principal
Kerberoasting T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting) 4769 con Ticket Encryption Type 0x17 (RC4) y volumen anómalo de SPN por usuario gMSA, contraseñas de servicio de 25+ caracteres, forzar AES
AS-REP Roasting T1558.004 (Steal or Forge Kerberos Tickets: AS-REP Roasting) 4768 con Pre-Authentication Type 0 Eliminar el flag DONT_REQ_PREAUTH de las cuentas
Pass-the-Hash T1550.002 (Use Alternate Authentication Material: Pass the Hash) 4624 Type 3, Authentication Package NTLM, Key Length 0; Sysmon ID 10 sobre lsass.exe LAPS, Credential Guard, Protected Users, tiering
Pass-the-Ticket T1550.003 (Use Alternate Authentication Material: Pass the Ticket) Mismo ticket/Logon ID en hosts distintos en ventana incompatible; 4624 Kerberos sin 4769 previo coherente Protected Users (TGT de vida corta), tiering, Credential Guard
Overpass-the-Hash T1550.002 / T1558 (material NTLM usado para obtener tickets Kerberos) 4768 con Pre-Auth Type 2 sin logon previo coherente; Sysmon ID 10 sobre lsass.exe inmediatamente antes Credential Guard, Protected Users, tiering
DCSync T1003.006 (OS Credential Dumping: DCSync) 4662 con GUID DS-Replication-Get-Changes[-All] desde un origen no-DC Auditar y limitar delegación de derechos de replicación; SACL de auditoría en el objeto de dominio
DCShadow T1207 (Rogue Domain Controller) 5137 sobre objetos nTDSDSA efímeros en la partición de configuración; metadatos de replicación inconsistentes Restringir escritura en CN=Configuration; proteger cuentas Tier 0
Golden Ticket T1558.001 (Steal or Forge Kerberos Tickets: Golden Ticket) Actividad Kerberos válida de cuentas deshabilitadas/con contraseña cambiada; vida de ticket fuera de GPO; ausencia de 4768 previo Rotación del hash de krbtgt (x2 consecutivas), protección de Tier 0
Silver Ticket T1558.002 (Steal or Forge Kerberos Tickets: Silver Ticket) 4624 Type 3 con Kerberos válido sin el 4769 correspondiente en el DC gMSA/contraseñas largas en cuentas de servicio, monitorizar discrepancia 4624/4769
Enumeración con BloodHound T1087 (Account Discovery) / T1482 (Domain Trust Discovery) / T1069 (Permission Groups Discovery) Volumen anómalo de consultas LDAP; NetSessionEnum masivo; ficheros *_BloodHound.zip Reducir ACL peligrosas, limitar enumeración de sesiones, tiering

11. Laboratorio: detectar Kerberoasting simulado en los logs de un DC de laboratorio

Objetivo: en tu controlador de dominio de laboratorio (con una cuenta de servicio de prueba con SPN registrado y contraseña deliberadamente débil, por ejemplo svc-sql con SPN MSSQLSvc/labsql01.lab.local:1433), generarás tráfico de Kerberoasting simulado desde una VM cliente con un usuario estándar, y lo detectarás exclusivamente a partir de los EVTX del DC.

  1. Preparación del DC: confirma que Audit Kerberos Service Ticket Operations está en Success (auditpol /get /subcategory:"Kerberos Service Ticket Operations"). Crea la cuenta de prueba con SPN y contraseña corta, exclusivamente en tu bosque desechable.
  2. Generación del tráfico simulado: desde la VM cliente, con un usuario estándar, solicita un TGS para el SPN de prueba con Add-Type -AssemblyName System.IdentityModel; New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/labsql01.lab.local:1433" — genera una petición de TGS legítima a nivel de protocolo, igual que una herramienta de kerberoasting, sin ejecutar ninguna herramienta ofensiva de terceros.
  3. Recolección: en el DC, wevtutil epl Security C:IRSecurity_dc.evtx.
  4. Triaje: busca el 4769 del SPN de prueba y verifica Ticket Encryption Type. Si el dominio permite RC4, debería aparecer 0x17; si fuerza AES, relaja temporalmente msDS-SupportedEncryptionTypes en la cuenta de prueba para observar el patrón RC4 (documenta la diferencia: es la prueba de que forzar AES es una contramedida real y medible).
  5. Umbral de alerta: repite la petición para 3-4 SPN adicionales en menos de un minuto y comprueba con la consulta de la sección 1.1 que el agrupamiento por cuenta detecta ese volumen como anómalo frente al resto de usuarios del dominio.
  6. Entregable: documenta la cadena completa —cuenta, SPN, Ticket Encryption Type, hora y conteo agrupado— que distingue el patrón de kerberoasting del tráfico Kerberos normal.

12. Errores comunes al defender Active Directory frente a estos ataques

  • No monitorizar 4769 ni 4662: el primero por volumen (se genera constantemente por uso legítimo), el segundo por desconocimiento (con el GUID de replicación casi nunca da falsos positivos). Ignorarlos «por ruido» sin aplicar los filtros correctos deja ciego al SOC frente a Kerberoasting y DCSync.
  • Registrar SPN en cuentas de usuario estándar con contraseñas débiles: la causa raíz más común de Kerberoasting exitoso en auditorías reales.
  • Rotar el hash de krbtgt una sola vez tras un incidente: un Golden Ticket forjado con el hash «antiguo» sigue siendo válido durante la ventana en la que AD todavía acepta la clave N-1.
  • Confiar solo en la detección y no en reducir la superficie: detectarlo después de que ocurra es tarde si el atacante ya extrajo el hash de krbtgt; la reducción estructural (tiering, gMSA, LAPS, Protected Users) limita el daño incluso cuando la detección falla.
  • Delegar derechos de replicación sin inventario: crear una vía de DCSync legítima-en-apariencia que nadie audita.
  • Tratar BloodHound solo como amenaza y no como herramienta de auditoría propia: desconocer las propias rutas de escalado hasta que un atacante o un pentest las descubre primero.

13. Ejercicio

Un SOC recibe la siguiente secuencia de eventos del controlador de dominio DC01 durante una ventana de 90 segundos:

  • 10:42:01 — 4769, Cuenta=jgarcia, Servicio=MSSQLSvc/sql01.lab.local:1433, TicketEncryptionType=0x17
  • 10:42:03 — 4769, Cuenta=jgarcia, Servicio=HTTP/web03.lab.local, TicketEncryptionType=0x17
  • 10:42:05 — 4769, Cuenta=jgarcia, Servicio=CIFS/fs02.lab.local, TicketEncryptionType=0x17
  • 10:42:08 — 4769, Cuenta=jgarcia, Servicio=MSSQLSvc/sql02.lab.local:1433, TicketEncryptionType=0x17
  • 10:42:11 — 4769, Cuenta=jgarcia, Servicio=LDAP/dc02.lab.local, TicketEncryptionType=0x12
  • 10:43:40 — 4662, Subject=svc-backup, ObjectType=Domain DNS, Properties contiene GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, Origen=10.10.20.15 (host que no figura en la lista de controladores de dominio)

Preguntas: (1) ¿Qué técnica indican los cuatro primeros eventos 4769 y qué campo concreto lo confirma? (2) ¿Por qué el quinto evento (LDAP/dc02.lab.local, tipo 0x12) probablemente no forma parte del mismo patrón de ataque? (3) Clasifica el evento 4662 según la tabla MITRE ATT&CK de este módulo y explica por qué el campo «Origen» es la clave para diferenciarlo de tráfico de replicación legítimo. (4) Si svc-backup es una cuenta de servicio de un producto de backup que nunca debería tener derechos de replicación, redacta las dos acciones inmediatas de contención y las dos acciones estructurales de prevención a medio plazo que aplicarías.

Preguntas frecuentes

¿Kerberoasting requiere privilegios de administrador para ejecutarse?

No. Cualquier cuenta autenticada en el dominio, sin ningún privilegio especial, puede solicitar un TGS para cualquier SPN registrado: es comportamiento normal de Kerberos, no una vulnerabilidad de permisos. Por eso es peligroso: convierte a cualquier usuario estándar comprometido en un vector potencial de escalado si existe al menos una cuenta de servicio con SPN y contraseña débil en RC4.

¿Basta con forzar AES256 en todas las cuentas de servicio para eliminar el riesgo de Kerberoasting?

Reduce drásticamente el riesgo práctico, pero no elimina la técnica en sí: el atacante sigue pudiendo solicitar y extraer el TGS, solo que crackearlo offline deja de ser viable con contraseñas robustas. Si la contraseña de la cuenta de servicio es débil (una palabra de diccionario), incluso con AES256 el crackeo puede tener éxito, aunque con mucho más coste computacional. La combinación AES + contraseña larga/aleatoria (o gMSA) es la que realmente cierra la puerta.

¿Por qué hay que rotar el hash de krbtgt dos veces y no basta con una sola rotación?

Active Directory mantiene la clave anterior de krbtgt (N-1) como válida durante un periodo, para no invalidar de golpe todos los tickets en circulación durante una rotación rutinaria. Si un atacante ya tiene el hash «antiguo», sigue siendo la clave N-1 válida justo después de tu única rotación, y un Golden Ticket forjado con él seguirá funcionando hasta una segunda rotación que finalmente la descarte. Por eso Microsoft y la literatura de respuesta a incidentes —incluyendo Sean Metcalf en adsecurity.org— recomiendan rotar dos veces.

¿DCSync deja rastro en el propio controlador de dominio que sufre la «réplica» maliciosa?

Sí: el DC que atiende la petición registra el 4662 con el GUID de derecho extendido correspondiente. El problema histórico no es la ausencia de log, sino que muchas organizaciones no tienen habilitada la SACL de auditoría sobre el objeto de dominio (sin ella el 4662 no se genera aunque la categoría esté activada) y, cuando sí la tienen, no filtran ni alertan sobre ese GUID concreto entre el enorme volumen de 4662 rutinarios de un dominio activo.

¿Es BloodHound en sí mismo una herramienta maliciosa que debería bloquearse en el antivirus/EDR?

No tiene sentido bloquearla como malware: es una herramienta legítima de auditoría de grafos de AD usada activamente por equipos de seguridad defensiva (incluida BloodHound Enterprise, orientada a gestión continua de exposición de identidad). El enfoque correcto es doble: detectar el patrón de recolección masiva (SharpHound) cuando lo ejecuta un actor no autorizado, y —más importante— usarla tú mismo proactivamente contra tu propio dominio para cerrar rutas de ataque antes que un adversario real.

«Kerberoasting is an effective method for extracting service account credentials from Active Directory as a regular user without sending any packets to the target system. […] This attack is effective since people tend to create poor passwords.» — Sean Metcalf, adsecurity.org, «Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain»