1. Introducción
La Seguridad en Active Directory es el reto central de la ciberseguridad corporativa, y no es casualidad: Active Directory concentra credenciales, políticas y control de acceso de toda la organización. Cuando un Red Team compromete un dominio, obtiene de facto el control de la compañía. Por eso este artículo aborda la Seguridad en Active Directory desde cero, con un enfoque hands-on: reconocer el terreno con BloodHound, robar credenciales con Kerberoasting y AS-REP Roasting, escalar con Pass-the-Hash y DCSync, y desplegar los controles que hacen defendible y auditable esa Seguridad en Active Directory. Al final tendrás un playbook completo de ataque y defensa.
Toda estrategia de Seguridad en Active Directory debe empezar por entender por qué este servicio es, con diferencia, el objetivo número uno del atacante. Cada inicio de sesión, cada ticket Kerberos y cada replicación deja un rastro en los logs del controlador de dominio, y la Seguridad en Active Directory se juega en saber leer esos rastros antes que el adversario. Mantener ese equilibrio entre visibilidad y usabilidad es el oficio del administrador.
2. Por qué la Seguridad en Active Directory es el objetivo prioritario
Más del 90% de las grandes empresas usan Active Directory como repositorio central de identidades, y los informes de incidentes muestran que la mayoría de los ataques en entornos Windows terminan comprometiendo un dominio. La Seguridad en Active Directory se juega en muchas capas, pero todas convergen en una verdad incómoda: si el atacante domina el AD, domina la empresa. Los grupos de operaciones del MITRE ATT&CK clasifican estos abusos en las técnicas T1558 (robo y falsificación de tickets Kerberos) y T1069 (descubrimiento de grupos y permisos), y todos ellos forman parte del arsenal habitual contra la Seguridad en Active Directory.
Además, el modelo híbrido complica el perímetro: el atacante con credenciales de dominio puede alcanzar Office 365, Azure, VPN y SaaS corporativos con el mismo token. Cualquier hardening debe asumir que la Seguridad en Active Directory incluye el ecosistema híbrido y las cuentas de servicio privilegiadas que conectan ambos mundos.
El tercer motivo es económico: el coste medio de un incidente que compromete el dominio se cuenta en meses de forense, restauración y reputación. Invertir en Seguridad en Active Directory es una de las decisiones con mejor retorno para la dirección de TI.
3. Reconocimiento y enumeración: BloodHound y las rutas de ataque
El primer paso de cualquier aproximación rigurosa a la Seguridad en Active Directory es la exhaustiva enumeración del dominio. No se puede proteger lo que no se conoce, y tampoco atacar lo que no se ha mapeado. BloodHound convierte la estructura de AD en un grafo dirigido donde cada nodo es un usuario, equipo, grupo o recurso, y cada arista es un abuso potencial: pertenencias a grupos, GPO vinculadas y permisos DACL abusables.
3.1. Colección de datos: el mapa que necesita la Seguridad en Active Directory
La recolección se hace con SharpHound, el recolector oficial que consulta el LDAP y los sistemas remotos para construir el grafo:
# Colección completa con SharpHound (modo stealth para evadir logs)
SharpHound.exe -c All --ldapuser svc-monitoring --ldappass 'S3cr3t!' --domain corp.local
# Alternativa desde PowerShell en el propio segmento
Import-Module .\BloodHound.ps1
Invoke-BloodHound -CollectionMethod All -Domain corp.local -ZipFileName ad-graph.zipFig. 1 – Recolección del grafo de Active Directory con SharpHound para su análisis con BloodHound.
Con el grafo cargado, BloodHound responde preguntas que definen el estado real de la Seguridad en Active Directory: qué usuarios pueden volcarse tickets Kerberos, qué máquinas administran cuentas comprometidas, o qué rutas de pocos saltos llevan de un usuario sin privilegios a Domain Admins. Cada camino marcado en rojo es una vulnerabilidad concreta que el atacante explotará y que el defensor debe romper.
3.2. De la enumeración a la acción
En nuestro laboratorio, la enumeración reveló un patrón clásico: svc-monitoring era Administrador de las máquinas del clúster de aplicaciones, y esas máquinas tenían permisos de escritura sobre una GPO de dominio. Ese encadenamiento convierte una cuenta sin aparente interés en un vector directo al dominio y demuestra que la Seguridad en Active Directory no se resuelve solo con políticas de contraseñas, sino cortando rutas de abuso. Herramientas como ACLight o los queries de BloodHound permiten auditar esos permisos periódicamente.
4. Ataques de credenciales: Kerberoasting y AS-REP Roasting
El siguiente paso en toda prueba de Seguridad en Active Directory es atacar la capa de autenticación Kerberos. Estos ataques se aprovechan de cuentas de servicio con SPN: roban los tickets y los rompen offline, sin generar apenas tráfico sospechoso.
4.1. Kerberoasting y robo de tickets: la gran amenaza para la Seguridad en Active Directory
Cuando un usuario pide un ticket TGS para un servicio, el controlador de dominio lo cifra con la contraseña de la cuenta que tiene ese SPN. Kerberoasting consiste en pedir tickets de forma masiva y llevarlos a casa para romperlos con diccionario. El mismo equipo del laboratorio lo extrajo con Rubeus e Impacket:
# Extraer todos los tickets TGS posibles con Rubeus
.\Rubeus.exe kerberoast /outfile:tickets_kerberoast.txt
# Desde Linux con Impacket (requiere credenciales válidas de dominio)
python3 GetUserSPNs.py corp.local/adm.carlos:'C0ntra2026!' -dc-ip 192.168.1.10 -request
# Crackeo offline del hash de Kerberos 5 etype 23 con hashcat
hashcat -m 13100 tickets_kerberoast.txt rockyou.txt --showFig. 2 – Kerberoasting completo: extracción de tickets TGS y crackeo offline con hashcat.
En el laboratorio, la cuenta svc-metrics, con contraseña de 11 caracteres, se rompió en menos de una hora en una GPU doméstica. La lección es doble: ninguna cuenta de servicio debe tener contraseñas humanamente recordables, y el cifrado de tickets debe ser AES256, nunca RC4, porque el modo de cifrado del ticket delata el material criptográfico disponible al atacante.
4.2. AS-REP Roasting y protección defensiva
Variante aún más silenciosa: si una cuenta tiene desactivada la preautenticación Kerberos, cualquiera puede pedir un TGT cifrado con su contraseña sin interactuar siquiera con ella. La detección de cuentas con el flag Do not require Kerberos preauth debe formar parte de cualquier auditoría de Seguridad en Active Directory. Como contramedidas: usar cuentas gMSA gestionadas por el propio AD (rotan su contraseña cada 30 días), prohibir el cifrado RC4 por GPO, auditar SPN en cuentas de usuario y exigir contraseñas de 25 caracteres en las cuentas con SPN.
5. Escalada y dominio: Pass-the-Hash, DCSync y delegaciones
Cuando el adversario ya dispone de credenciales válidas, la Seguridad en Active Directory se enfrenta a su fase más difícil: la escalada silenciosa. El Pass-the-Hash permite autenticarse en cualquier servidor con solo el hash NTLM robado con mimikatz:
# Volcado de hashes de la sesión local con mimikatz
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"
# Autenticación remota directa con el hash robado
mimikatz.exe "privilege::debug" "sekurlsa::pth /user:adm.carlos /domain:corp.local /ntlm:8846f7eaee8fb117ad06bdd830b7586c /run:powershell"
# Replicación del directorio como ataque DCSync
mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt" "exit"Fig. 3 – Volcado de hashes, Pass-the-Hash y DCSync con mimikatz en el laboratorio.
El DCSync no explota una vulnerabilidad: abusa de permisos legítimos de replicación de directorio (GetChanges/GetChangesAll) para volcar los hashes de cualquier cuenta, incluida la cuenta krbtgt. Con el hash de krbtgt se fabrica un Golden Ticket válido durante años, incluso si cambiamos las contraseñas de los usuarios. La defensa pasa por revisar quién tiene permisos de replicación, desactivar el cifrado RC4, implantar Credential Guard en los hosts administrativos y monitorizar los eventos 4662 y 5136.
Las delegaciones Kerberos (sin restricciones o basadas en recursos) añaden otra capa de riesgo: permiten al servicio delegado volcarse tickets de otros usuarios, por lo que deben enumerarse y sustituirse por gMSA con delegación restringida y cifrado AES.
6. Mitigación, detección y monitorización
Una Seguridad en Active Directory madura se demuestra en lo que el SIEM ve. La tabla recoge las señales de detección de los ataques vistos, con los Event ID de Windows que debes correlacionar:
| Ataque | Señal de detección (Event ID) | Mitigación clave |
|---|---|---|
| Kerberoasting | 4769 con cifrado RC4 del ticket de servicio | Prohibir RC4, usar gMSA y contraseñas de 25 caracteres |
| AS-REP Roasting | 4768 sobre cuentas sin preautenticación Kerberos | Reactivar preautenticación y auditar el flag anualmente |
| Pass-the-Hash | 4624 con el mismo hash NTLM en varios hosts | Credential Guard, LAPS y administrador local único |
| DCSync | 4662 con control 0x100 (Ds-Replication-Get-Changes) | Restringir GetChanges/GetChangesAll y alertar replicaciones fuera de horario |
| Golden Ticket | 4768/4769 con propiedades anómalas y vida superior a 10 horas | Rotar dos veces el hash de krbtgt acompañado del reset de sesiones |
| Delegación Kerberos | 4769 con código de opción 0x08000000 | Eliminar delegación sin restricciones y usar gMSA con AES |
Como ejemplo práctico, el siguiente script PowerShell detecta solicitudes de tickets de servicio cifrados con RC4, señal inequívoca de Kerberoasting en curso:
# Detección de Kerberoasting: tickets de servicio (4769) cifrados con RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
Where-Object { $_.Properties[3].Value -eq 17 } |
Group-Object @{e={$_.Properties[0].Value}} |
Where-Object Count -gt 10 |
Select-Object Count, Name | Out-GridViewFig. 4 – Consulta PowerShell para detectar ráfagas de tickets TGS con cifrado RC4 en el visor de eventos de Windows.
Además de la telemetría, conviene implantar un ciclo mensual de revisión: volcar el grafo con BloodHound, contrastar las rutas de ataque con el inventario de cuentas privilegiadas y re-ejecutar el playbook de detección. La Seguridad en Active Directory no es un proyecto con fecha de fin, sino un proceso continuo sujeto a auditorías internas y externas y enmarcado en las líneas base de seguridad de Windows.
7. Conclusión
La Seguridad en Active Directory es un campo de batalla con reglas definidas: el adversario enumerará, robará credenciales, escalará y buscará persistir, y el defensor solo gana si conoce cada una de esas fases y ha construido telemetría para verlas. Hemos recorrido el ciclo completo: reconocimiento con BloodHound, Kerberoasting y AS-REP Roasting, escalada con Pass-the-Hash y DCSync, y las mitigaciones que los neutralizan, desde gMSA y AES256 hasta Credential Guard y la rotación de krbtgt.
Lo esencial es la constancia: auditar el grafo, revisar permisos de replicación, reducir la superficie de cuentas de servicio y mantener el SIEM afilado. Si un solo control falta, el atacante probablemente lo encuentre. La Seguridad en Active Directory bien ejecutada encarece el ataque hasta que el adversario desiste.
Artículos relacionados: aplicar el ciclo PDCA a la auditoría de la Seguridad en Active Directory y cómo programar las auditorías de gobierno TIC que sostienen tu plan de seguridad.
¿Necesitas ayuda con Seguridad en Active Directory?
En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.
Contacta con nosotros para una evaluación gratuita de tu infraestructura.