Initializing

Volver al blog
CPPJ

18 de julio de 2026

Cetro: dos puertas a Domain Admin (Zerologon y EternalBlue)

Gerardo Eliasib

Gerardo Eliasib

CEO of Spartan-Cybersecurity

Cetro: dos puertas a Domain Admin (Zerologon y EternalBlue)

Tienes delante un Windows Server. No uno cualquiera: un Domain Controller, el cerebro de un dominio de Active Directory.

Y no vas a encontrar una forma de entrar. Vas a encontrar dos, completamente distintas, y ninguna necesita que conozcas una sola contraseña.

Esa es la lección de Cetro, una de las tasks de dificultad media del CPPJ. No te vamos a dictar comandos para copiar y pegar. Te vamos a enseñar a leer la máquina, a entender por qué cada puerta existe, y qué está pasando por dentro cuando la abres. Cuando termines, Cetro deja de ser un reto y se vuelve un patrón que reconocerás en cualquier red real.

Un Domain Controller no es una máquina: es el dominio

Antes de tocar nada, entiende qué tienes enfrente. Un Domain Controller (DC) es la autoridad central de un dominio de Active Directory. Guarda, en un archivo llamado NTDS.dit, la identidad de todos: usuarios, grupos, equipos y sus credenciales.

Comprometer un servidor cualquiera te da ese servidor. Comprometer el DC te da todas las identidades de la organización a la vez. Por eso, en un pentest, el DC no es un objetivo: es el objetivo.

Y por eso Cetro está diseñada alrededor de uno.

Radiografía de un DC

Lo primero no es atacar: es identificar. Y un DC se delata solo, porque habla un conjunto de protocolos que ninguna otra máquina reúne. Un escaneo de servicios te lo pinta:

bash
nmap -Pn -n -sV \
  -p 53,88,135,139,389,445,464,593,636,3268,3269,5985,9389,3389 \
  --script "smb-os-discovery,smb2-security-mode,ldap-rootdse,smb-vuln-ms17-010" \
  10.10.10.100
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: corp.local)
445/tcp  open  microsoft-ds  Windows Server 2012 R2 Standard 9600 microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Global Catalog)
3269/tcp open  tcpwrapped
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp open  mc-nmf        .NET Message Framing

No memorices puertos: aprende a leer la constelación. El 88 (Kerberos) y el 464 (kpasswd) solo viven donde hay un centro de distribución de claves — un DC. El 389/636 (LDAP/LDAPS) es el directorio, y el 3268/3269 es el Global Catalog, el índice que abarca todo el bosque: eso solo lo publica un DC. El 9389 son los AD Web Services. Y el 5985 (WinRM), tu futura puerta de acceso remoto.

Esa firma —DNS + Kerberos + LDAP + Global Catalog + kpasswd— no es un servidor. Es la autoridad del dominio.

Hay un regalo extra. El script ldap-rootdse consulta el objeto raíz de LDAP, lo único que un DC responde sin autenticación, y te entrega su topología:

namingContexts: DC=corp,DC=local
dnsHostName: DC01.corp.local
domainFunctionality: 6          <- Windows Server 2012 R2
forestFunctionality: 6
isGlobalCatalogReady: TRUE

Ese DC=corp,DC=local es el DN base del dominio: lo necesitarás para cualquier consulta LDAP posterior. Y el nivel funcional 6 te confirma que es un 2012 R2 — un dato que, en un minuto, vas a ver que importa mucho.

Tres palabras que definen el ataque

Hay una herramienta que resume la superficie de ataque de un host SMB en una sola línea: netexec (antes CrackMapExec). Su banner es de las cosas más densas en información que verás:

bash
nxc smb 10.10.10.100
SMB  10.10.10.100  445  DC01  [*] Windows Server 2012 R2 Standard 9600 x64
     (name:DC01) (domain:corp.local) (signing:True) (SMBv1:True) (Null Auth:True)

Tres banderas al final de esa línea deciden buena parte de tu estrategia. Apréndete a leerlas:

  • `signing:True` — el firmado SMB es obligatorio. Traducción: olvídate del SMB relay contra este host. Una técnica entera queda descartada de un vistazo.
  • `SMBv1:True` — la máquina tiene habilitado SMBv1, un protocolo que debería estar muerto desde 2017. Eso enciende una alarma enorme: es la superficie de EternalBlue (MS17-010). Retén esto: es tu Puerta 2.
  • `Null Auth:True` — acepta sesión nula (login anónimo). Suena a jackpot… pero, como verás enseguida, no lo es.

En una línea ya sabes qué NO vas a intentar (relay), qué SÍ vas a intentar (un bug de plataforma), y que hay una puerta anónima por explorar.

Cuando el orden se invierte: explotar para enumerar

El manual clásico dice: primero enumera, luego explota. Con esa sesión nula deberías poder listar usuarios, grupos, shares… Lo intentas:

bash
nxc smb  10.10.10.100 -u '' -p '' --shares      # -> STATUS_ACCESS_DENIED
nxc smb  10.10.10.100 -u '' -p '' --rid-brute   # -> STATUS_ACCESS_DENIED
rpcclient -U '' -N 10.10.10.100 -c 'enumdomusers'  # -> NT_STATUS_ACCESS_DENIED

Nada. El DC está endurecido con restrictanonymous: acepta la conexión anónima, pero no te deja enumerar nada útil con ella. La puerta anónima abre a un muro.

Y aquí está la lección que separa a un operador de alguien que sigue un checklist:

Cuando la enumeración anónima está cerrada pero la plataforma es vieja y vulnerable, el camino se invierte: no es enumerar-para-explotar, es explotar-para-enumerar.

No vas a sacar credenciales del directorio para entrar. Vas a entrar rompiendo la plataforma, y desde dentro enumerarás con todos los privilegios. Con un DC 2012 R2 sin parchear y SMBv1 encendido, tus candidatos ya no son contraseñas débiles: son vulnerabilidades de plataforma. Dos, de hecho.

Confirmarlas es gratis y no destructivo — los detectores solo comprueban, no explotan:

bash
nxc smb 10.10.10.100 -u '' -p '' -M ms17-010     # -> VULNERABLE
nxc smb 10.10.10.100 -u '' -p '' -M zerologon    # -> VULNERABLE

Dos puertas abiertas. Vamos por cada una entendiendo por qué funciona.

Puerta 1 — Zerologon: cuando el cifrado te traiciona

Zerologon (CVE-2020-1472) es una de las vulnerabilidades más elegantes de la historia reciente de Active Directory. La descubrió Tom Tervoort (Secura) en 2020 y su gravedad es un 10.0 sobre 10.

Para entenderla necesitas saber qué es Netlogon: el protocolo que usan los equipos de un dominio para autenticarse contra el DC con la contraseña de su cuenta de máquina — esa cuenta oculta, terminada en $, que cada equipo Windows tiene (aquí, DC01$). Netlogon abre un "canal seguro" mediante un handshake criptográfico.

Y ahí está el fallo. Ese handshake cifra con AES en modo CFB8, pero usando un vector de inicialización (IV) de 16 bytes en cero. Un IV jamás debe ser fijo ni predecible; ese es su único propósito. Aquí lo era.

La consecuencia es pura matemática. En CFB8, si el IV y el texto en claro son todo ceros, hay una probabilidad de 1 entre 256 de que el texto cifrado también salga todo ceros — sin importar la clave.

Llévalo al ataque: le mandas al DC un desafío de 8 bytes en cero y una credencial calculada de 8 bytes en cero, afirmando ser la cuenta de máquina del propio DC. En 1 de cada 256 intentos, el DC te acepta sin que sepas la contraseña. Como solo hay que reintentar el handshake, en promedio 256 intentos (segundos) bastan.

Autenticarte ya sería grave. Pero hay un segundo acto. Una vez dentro del canal, invocas la función NetrServerPasswordSet2, pensada para que un equipo rote su propia contraseña. El mensaje viaja, otra vez, relleno de ceros — así que pones la contraseña de la cuenta de máquina del DC a un valor vacío.

bash
python3 cve-2020-1472-exploit.py -n DC01 -t 10.10.10.100
Performing authentication attempts...
.............................................
[+] Success: Target is vulnerable!
[+] Success: Zerologon Exploit completed! DC's account password has been set to an empty string.

Deja que eso cale:

Le acabas de poner contraseña vacía a la identidad más privilegiada de la red, sin conocer una sola credencial.

Un detalle crítico que casi nadie explica: acabas de romper algo. La contraseña real de la cuenta de máquina sigue guardada en el registro local del DC, pero en Active Directory ahora está vacía. Esa desincronización rompe el canal seguro del DC — y en un dominio real puede tumbar servicios enteros. En un engagement profesional, restaurar esa contraseña después de dumpear no es opcional: es parte del trabajo.

El botín: replicar el alma del dominio

Con la cuenta de máquina en contraseña vacía, pides autenticarte como ella y algo brutal se vuelve posible. La cuenta de máquina de un DC tiene un privilegio de nacimiento: puede replicar la base de datos del directorio, como hacen los DC entre sí para sincronizarse.

Abusar de eso se llama DCSync, y secretsdump lo hace por ti vía DRSUAPI: le pide al DC, con toda educación, todos los secretos de la NTDS.dit como si fuera otro DC.

bash
impacket-secretsdump -no-pass 'corp.local/DC01$@10.10.10.100'
Administrador:500:aad3b435b51404eeaad3b435b51404ee:[HASH_NT_ADMIN]:::
Invitado:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:[HASH_NT_KRBTGT]:::
soporte:2106:aad3b435b51404eeaad3b435b51404ee:[HASH_NT]:::
DC01$:1001:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Ese volcado es un mapa del tesoro. Léelo por partes:

  • `Administrador:500:...` — el 500 es el RID del Administrador integrado del dominio. Ese cuarto campo es su hash NT: tu premio inmediato.
  • `krbtgt:502:...` — la cuenta que firma todos los tickets Kerberos del dominio. Con su hash puedes forjar un Golden Ticket: persistencia total, autenticarte como cualquiera cuando quieras. Es la joya que un atacante serio se lleva incluso si ya tiene al Administrador.
  • `DC01$:1001:...:31d6cfe0d16ae931b73c59d7e0c089c0` — ese hash, 31d6..., es una constante pública famosa: el hash NT del string vacío. Que la cuenta de máquina del DC lo tenga es la prueba forense de que Zerologon funcionó. (Lo verás también en Invitado, cuya contraseña está vacía por defecto.)

¿Y qué es un hash NT? No es una contraseña cifrada de forma reversible: es MD4 aplicado a la contraseña en UTF-16LE. No se puede "descifrar". Pero — y aquí está la clave — no hace falta.

El protocolo NTLM no usa tu contraseña en claro: usa su hash NT como secreto en un desafío-respuesta. Conclusión que rompe muchos esquemas mentales:

Si tienes el hash NT, tienes la credencial. No necesitas conocer ni crackear la contraseña.

Eso es Pass-the-Hash. Le pasas el hash del Administrador a evil-winrm, que lo inyecta en el NTLM sobre WinRM (el puerto 5985 del recon), y estás dentro como Administrador del dominio:

bash
evil-winrm -i 10.10.10.100 -u Administrador -H '[HASH_NT_ADMIN]'

Cero contraseñas conocidas, cero fuerza bruta. De un IV mal puesto a Domain Admin.

Puerta 2 — EternalBlue: la otra forma de entrar

Zerologon es fina y quirúrgica. La segunda puerta es todo lo contrario, y por eso es tan buena para aprender: te muestra una clase de vulnerabilidad completamente distinta que lleva al mismo sitio.

Recuerda el SMBv1:True del banner. EternalBlue (MS17-010) es un fallo en esa vieja implementación de SMBv1 — el mismo que usó el ransomware WannaCry en 2017. No es un problema de criptografía ni de lógica de autenticación: es un error de corrupción de memoria. El código de SMBv1 calcula mal el tamaño de ciertos paquetes y permite escribir datos donde no debería, hasta lograr ejecución de código en el kernel.

Donde Zerologon abusa de matemática rota, EternalBlue abusa de memoria mal gestionada. Dos mundos distintos, mismo destino: SYSTEM, el usuario más privilegiado de Windows, sin credenciales.

Aquí hay una lección de honestidad técnica que vale oro. "Vulnerable a MS17-010" no significa que cualquier exploit funcione al primer intento. El exploit de kernel más famoso (ms17_010_eternalblue) es inestable en 2012 R2: manipular la memoria del kernel es frágil y a menudo falla con un timeout. El camino robusto es su primo ms17_010_psexec, que usa el mismo bug de autenticación pero para escribir en un named pipe y lanzar un servicio como SYSTEM — mucho más fiable:

bash
msfconsole -q -x "use exploit/windows/smb/ms17_010_psexec; \
  set RHOSTS 10.10.10.100; \
  set PAYLOAD windows/x64/meterpreter/bind_tcp; run"
[+] 10.10.10.100:445 - Overwrite complete... SYSTEM session obtained!
[*] Meterpreter session 1 opened

Server username: NT AUTHORITY\SYSTEM
Computer     : DC01
OS           : Windows Server 2012 R2 (6.3 Build 9600)

Fíjate en un detalle que no es cosmético: el payload es `bind_tcp`, no reverse_tcp. La diferencia es la dirección de la conexión. Un reverse shell obliga a la víctima a conectarse de vuelta hacia ti — y si un firewall o una regla de red bloquea que ese servidor inicie conexiones salientes, tu shell nunca llega. Un bind_tcp hace lo contrario: la víctima escucha y tú te conectas hacia ella. Cuando "de ti hacia la víctima" está permitido pero "de la víctima hacia ti" no, bind_tcp es la elección correcta. Pensar en la dirección del tráfico es una habilidad que te va a salvar una y otra vez.

Dos puertas, una lección

Detente un segundo en lo que acaba de pasar. La misma máquina cayó por dos vías que no tienen nada que ver entre sí: un fallo de diseño criptográfico en Netlogon y un error de memoria en SMBv1. Distintas décadas, distintas familias de bug, mismo resultado.

Eso no es casualidad de laboratorio: es cómo son los objetivos reales.

El defensor tiene que cerrar todas las puertas. El atacante solo necesita una.

Por eso el pentest no va de conocer un exploit, sino de leer una máquina y enumerar sus caminos. Cetro te obliga a ver los dos, y a entender que si tapas Zerologon pero dejas SMBv1 encendido, el DC sigue cayendo igual.

El otro lado: cerrar las dos puertas

En Spartan-Cybersecurity pensamos como atacantes, pero un buen atacante entiende la defensa mejor que el defensor. Ambas puertas son ruidosas y ambas se cierran.

Zerologon. El exploit dispara cientos de intentos de autenticación Netlogon con desafío en cero en segundos: un patrón antinatural. Y el cambio de contraseña deja huella:

  • Event ID 4742 — se modificó una cuenta de equipo (el reset de la cuenta de máquina del DC).
  • Event ID 5829 — conexión Netlogon vulnerable permitida (aparece si aún no estás en modo enforcement).

La mitigación: aplicar el parche de Zerologon (agosto 2020) y confirmar el enforcement mode (febrero 2021), que rechaza el handshake vulnerable. Un DC cuya propia cuenta de máquina cambia de contraseña sin una rotación programada es una bandera roja que cualquier SOC debería cazar.

EternalBlue. Se detecta por el uso de SMBv1 y por los patrones de escritura en named pipes que usan estos exploits. La mitigación es todavía más simple, y explica por qué un 2012 R2 en 2026 es imperdonable:

  • Aplica MS17-010 — el parche existe desde marzo de 2017.
  • Deshabilita SMBv1. No hay razón para tenerlo encendido hoy. Su sola presencia (ese SMBv1:True) es un hallazgo de auditoría por sí mismo.

La defensa de fondo es la misma para las dos: parchea y reduce superficie. Cada protocolo viejo que apagas es una puerta que el atacante ya no puede ni intentar.

Lo que te llevas de Cetro

Cetro no premia que memorices comandos. Premia que entiendas por qué un IV en cero colapsa un dominio entero, por qué la cuenta de máquina de un DC es tan peligrosa, por qué un hash es tan bueno como una contraseña, y por qué un protocolo que debió morir en 2017 sigue entregando SYSTEM.

Sobre todo, premia que aprendas a leer una máquina y ver todos sus caminos, no solo el primero.

Ese es el tipo de comprensión que separa a alguien que aprobó un curso de alguien a quien contratas para un red team. Y es exactamente lo que construimos, task a task, en el CPPJ.