Active Directory Security: Kerberoasting, DCSync y Defensa en 2026

Active Directory es el sistema de identidad más extendido en entornos empresariales, y también el más atacado. Los ataques a AD no requieren exploits de día cero — aprovechan el diseño del protocolo Kerberos y malas prácticas de configuración que persisten desde 2014. En 2026, el Kerberoasting sigue siendo la técnica más fiable para pasar de domain user a domain admin en organizaciones que llevan más de cinco años usando AD.

1. Kerberoasting — El Ataque Más Común a AD

Cómo funciona

Kerberos emite tickets de servicio (TGS) cifrados con el hash de la contraseña de la cuenta de servicio destino. Cualquier usuario del dominio puede solicitar un TGS para cualquier servicio del dominio — eso es parte del diseño del protocolo. Un atacante con una cuenta de bajo privilegio:

Enumera cuentas con Service Principal Names (SPN) mediante consultas LDAP
Solicita tickets TGS para cada SPN
Extrae el blob cifrado del ticket
Lo crackea offline a velocidades de gigahash por segundo

Si la contraseña de la cuenta de servicio es débil, el atacante obtiene la credencial en texto claro en minutos. Si esa cuenta tiene privilegios elevados (y a menudo las tienen, porque la práctica histórica ponía cuentas de servicio en Domain Admins), el atacante controla el dominio.

Detección en Event ID 4769

Windows registra cada solicitud de ticket de servicio en el Event ID 4769 (Kerberos Service Ticket Operations). Para detectar Kerberoasting:

# Habilitar auditoría de Kerberos
# Advanced Audit Policy → Account Logon → Audit Kerberos Service Ticket Operations (Success)

Señales de alta fidelidad:

RC4 downgrade: Si un SPN configurado para usar AES128/AES256 recibe una solicitud con tipo de cifrado 0x17 (RC4-HMAC), es altamente sospechoso. Microsoft documenta RC4 como inseguro y recomienda auditoría de su uso.
Fan-out anómalo: Un usuario normal solicita 0-5 SPNs por día. Una herramienta de Kerberoasting solicita docenas en segundos desde la misma cuenta origen. Una regla SIEM basada en el volumen de SPNs distintos por cuenta origen en una ventana de 60 segundos detecta esto independientemente del tipo de cifrado.
Honeypot SPN: Crear una cuenta de servicio señuelo (svc_backup_deprecated) con un SPN registrado pero sin ningún servicio real detrás. Cualquier solicitud TGS para este SPN es un atacante enumerando. Esta es la detección de mayor fidelidad disponible para Kerberoasting.

// Regla SIEM para detección de Kerberoasting por fan-out
EventID: 4769
| where TicketEncryptionType == 0x17
| where ServiceName !in ("krbtgt", "host", "rpcss", "http")
| summarize SPNCount = dcount(ServiceName) by SourceAccount, bin(Timestamp, 1m)
| where SPNCount > 5

Mitigación de Kerberoasting

Control	Efectividad	Esfuerzo
Migrar cuentas de servicio a gMSA (Group Managed Service Accounts)	Elimina completamente el riesgo	Medio
Contraseñas de 25+ caracteres aleatorias en un vault	Hace el cracking computacionalmente inviable	Bajo
Forzar cifrado AES256 (eliminar RC4)	7x más costoso de crackear que RC4	Bajo
Protected Users Group	Previene NTLM, RC4, DES y delegación	Medio
Honeypot SPN + alerta	Detección de alta fidelidad	Bajo
Auditoría trimestral de SPNs y propietarios	Reduce la superficie de ataque	Medio

Dato real: Según RingSafe 2026, no se ha encontrado ninguna organización con todos estos controles implementados que haya fallado un test de Kerberoasting en un engagement de red team. Tampoco se ha encontrado ninguna organización que faltara más de tres de estos controles que lograra bloquearlo.

gMSA — La mitigación definitiva

Group Managed Service Accounts (gMSA) son cuentas de AD donde Windows gestiona automáticamente una contraseña de 120 caracteres aleatorios que rota cada 30 días. Como ningún humano conoce la contraseña, no hay contraseña débil que crackear, y la longitud hace que el cracking offline sea computacionalmente inviable con cualquier hardware actual o previsible.

# Crear un gMSA
New-ADServiceAccount -Name "gmsa-sql-prod" -DNSHostName "sql01.dominio.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQL Servers"

# Instalar en un servidor
Install-ADServiceAccount -Identity "gmsa-sql-prod"

2. AS-REP Roasting — Sin Credenciales Necesarias

El AS-REP Roasting es el primo más peligroso del Kerberoasting. Las cuentas con el flag Do not require Kerberos preauthentication habilitado permiten a un atacante sin credenciales solicitar un AS-REP (Autenticación inicial de Kerberos) y recibir material cifrable.

# Enumerar cuentas vulnerables a AS-REP Roasting
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

Mitigación: Revisar y deshabilitar este flag en todas las cuentas. Las únicas excepciones justificadas son cuentas de servicio para tecnologías específicas que lo requieran (raras en entornos modernos).

3. DCSync — El Punto de No Retorno

DCSync es la técnica más asociada con el punto de no retorno en una compromiso de AD. Un atacante con el privilegio Replicating Directory Changes All (obtenido mediante Kerberoasting de una cuenta de servicio privilegiada o pass-the-hash contra un administrador) puede:

Impersonar un controlador de dominio
Solicitar la replicación de la base de datos NTDS
Extraer todos los hashes NTLM del dominio, incluyendo KRBTGT

Detección de DCSync

El Event ID 4662 (se realizó una operación en un objeto) combinado con el GUID de control de acceso 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All) desde una cuenta que no sea un controlador de dominio es una señal casi inequívoca de DCSync.

// Detección de DCSync
EventID: 4662
| where ObjectType == "domainDNS"
| where AccessMask contains "0x100"  // DS-Replication-Get-Changes-All
| where Account !endswith "$"  // excluir cuentas de computadora DC

Mitigación: Identificar todas las cuentas con DACLs capaces de DCSync y confirmar que están limitadas a controladores de dominio y sistemas de backup/monitorización aprobados. El privilegio Replicating Directory Changes All no debería existir en ninguna cuenta que no sea un controlador de dominio.

4. Golden Ticket y Silver Ticket

Con el hash KRBTGT en mano, un atacante puede forjar TGTs (Golden Ticket) con cualquier SID, nivel de privilegio y tiempo de vida. Un Golden Ticket bien craftedo:

Autentica contra cualquier servicio del dominio
Bypassa cambios de contraseña (hasta que KRBTGT se rota dos veces)
Puede persistir durante años si KRBTGT no se rota post-incidente

# Detección de Golden Ticket en Event ID 4769
- ticket_lifetime > 600 minutos (10 horas, el máximo legítimo)
- ticket_options.renewable_ok = TRUE
- source_workstation no coincide con el origen esperado

Rotación de KRBTGT

La rotación de la cuenta KRBTGT es el único procedimiento que invalida todos los Golden Tickets. Pero requiere hacerse dos veces (con un intervalo de 24 horas) porque Windows almacena en caché dos hashes de KRBTGT para permitir la transición:

# Paso 1: Rotar KRBTGT (primera vez)
Reset-ADAccountPassword -Identity krbtgt

# Esperar 24 horas para que todos los DCs repliquen

# Paso 2: Rotar KRBTGT (segunda vez)
Reset-ADAccountPassword -Identity krbtgt

Dato real: El Microsoft Digital Defense Report 2025 documentó que el tiempo medio entre el compromiso inicial y la detección de un ataque con Golden Ticket en entornos sin monitorización específica es de 143 días.

5. Pass-the-Hash y Pass-the-Ticket

Estas técnicas permiten a un atacante moverse lateralmente sin conocer la contraseña en texto claro:

Pass-the-Hash (PtH): usa el hash NTLM directamente para autenticarse en sistemas que aceptan NTLM.
Pass-the-Ticket (PtT): inyecta un ticket Kerberos robado en la sesión actual para autenticarse sin credenciales.

Mitigaciones:

Deshabilitar NTLM donde sea posible (objetivo: autenticación solo Kerberos)
Usar Protected Users Group para cuentas privilegiadas
Implementar Credential Guard en Windows 10/11 y Windows Server
Habilitar Windows Defender Remote Credential Guard para conexiones RDP

6. Modelo de Administración por Capas (Tiering Model)

Microsoft recomienda un modelo de administración con tres capas (Tier 0, Tier 1, Tier 2) para prevenir el movimiento lateral desde sistemas comprometidos:

Tier	Recursos	Cuentas
Tier 0	Controladores de dominio, AD, CA, ADFS	Domain Admins, Enterprise Admins, administradores de DC
Tier 1	Servidores de aplicación, bases de datos, servidores de archivos	Administradores de servidores
Tier 2	Estaciones de trabajo de usuario	Administradores locales de estaciones de trabajo

Regla fundamental: una cuenta de Tier 0 nunca debe autenticarse en un sistema de Tier 1 o Tier 2. Si un administrador de dominio inicia sesión en una estación de trabajo comprometida, el atacante captura sus credenciales y asciende a Tier 0.

7. BloodHound y Análisis de Rutas de Ataque

BloodHound (junto con SharpHound y AzureHound) mapea gráficamente las relaciones de confianza, permisos y pertenencia a grupos en AD. Permite identificar rutas de ataque imposibles de ver manualmente — como un usuario sin privilegios que resulta ser miembro de un grupo que tiene permisos de escritura en un GPO que se aplica a un DC.

# Recolección de datos con SharpHound
SharpHound.exe --CollectionMethods All --Domain dominio.local

# Consulta en BloodHound GUI:
# "Find Shortest Paths to Domain Admins"
# "Find all Kerberoastable Accounts"
# "Find computers where Domain Users can RDP"

Defensa con BloodHound: Ejecutar BloodHound periódicamente (como atacante, desde la perspectiva de un usuario estándar) para identificar y eliminar rutas de ataque antes de que un adversario real las explote.

Checklist de Seguridad en Active Directory

Conclusión

La seguridad en Active Directory no depende de parches de Microsoft — los ataques más efectivos (Kerberoasting, AS-REP Roasting, DCSync) llevan documentados desde 2014 y siguen funcionando porque la higiene de cuentas de servicio y la segmentación administrativa no han mejorado. La prioridad debe ser: primero reducir la superficie de ataque (gMSA, contraseñas fuertes, eliminación de RC4), luego detectar lo que no se pudo corregir (honeypot SPN, reglas SIEM de fan-out). Una organización con estos controles implementados reduce drásticamente la probabilidad de que un atacante con una cuenta de usuario estándar pueda comprometer el dominio entero.