Cetro: Two Doors to Domain Admin (Zerologon and EternalBlue)

There's a Windows Server in front of you. Not just any server: a Domain Controller, the brain of an Active Directory domain.

And you won't find one way in. You'll find two, completely different, and neither one needs you to know a single password.

That's the lesson of Cetro, one of the medium-difficulty tasks in the CPPJ. We won't dictate copy-paste commands. We'll teach you to read the machine, to understand why each door exists, and what's happening under the hood when you open it. By the end, Cetro stops being a challenge and becomes a pattern you'll recognize on any real network.

A Domain Controller isn't a machine: it's the domain

Before you touch anything, understand what you're facing. A Domain Controller (DC) is the central authority of an Active Directory domain. In a file called NTDS.dit it stores the identity of everyone: users, groups, computers and their credentials.

Compromising any server gives you that server. Compromising the DC gives you every identity in the organization at once. That's why, on an engagement, the DC isn't a target: it's the target.

And that's why Cetro is built around one.

X-ray of a DC

The first move isn't to attack: it's to identify. And a DC gives itself away, because it speaks a set of protocols no other machine gathers together. A service scan paints it for you:

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

Don't memorize ports: learn to read the constellation. Port 88 (Kerberos) and 464 (kpasswd) only live where there's a key distribution center — a DC. 389/636 (LDAP/LDAPS) is the directory, and 3268/3269 is the Global Catalog, the index that spans the whole forest: only a DC publishes that. 9389 is AD Web Services. And 5985 (WinRM) is your future remote access door.

That signature —DNS + Kerberos + LDAP + Global Catalog + kpasswd— isn't a server. It's the authority of the domain.

There's a bonus gift. The ldap-rootdse script queries LDAP's root object, the one thing a DC answers without authentication, and hands you its topology:

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

That DC=corp,DC=local is the domain's base DN: you'll need it for any later LDAP query. And functional level 6 confirms it's a 2012 R2 — a detail that, in a minute, you'll see matters a lot.

Three words that define the attack

There's a tool that summarizes an SMB host's attack surface in a single line: netexec (formerly CrackMapExec). Its banner is one of the most information-dense things you'll ever read:

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)

Three flags at the end of that line decide much of your strategy. Learn to read them:

• `signing:True` — SMB signing is mandatory. Translation: forget SMB relay against this host. An entire technique ruled out at a glance.
• `SMBv1:True` — the machine has SMBv1 enabled, a protocol that should have been dead since 2017. That fires a huge alarm: it's the surface for EternalBlue (MS17-010). Hold that thought: it's your Door 2.
• `Null Auth:True` — it accepts a null session (anonymous login). Sounds like the jackpot… but, as you'll see, it isn't.

In one line you already know what you won't try (relay), what you will try (a platform bug), and that there's an anonymous door to explore.

When the order flips: exploit to enumerate

The classic playbook says: enumerate first, exploit later. With that null session you should be able to list users, groups, shares… You try:

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

Nothing. The DC is hardened with restrictanonymous: it accepts the anonymous connection, but won't let you enumerate anything useful with it. The anonymous door opens onto a wall.

And here's the lesson that separates an operator from someone following a checklist:

When anonymous enumeration is closed but the platform is old and vulnerable, the path flips: it's not enumerate-to-exploit, it's exploit-to-enumerate.

You won't pull credentials from the directory to get in. You'll get in by breaking the platform, and from inside you'll enumerate with full privileges. With an unpatched 2012 R2 DC and SMBv1 on, your candidates aren't weak passwords anymore: they're platform vulnerabilities. Two of them, in fact.

Confirming them is free and non-destructive — the detectors only check, they don't exploit:

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

Two open doors. Let's take each one, understanding why it works.

Door 1 — Zerologon: when the crypto betrays you

Zerologon (CVE-2020-1472) is one of the most elegant Active Directory vulnerabilities of the last decade. Tom Tervoort (Secura) found it in 2020, and it scored a perfect 10.0 severity.

To understand it you need to know what Netlogon is: the protocol domain machines use to authenticate to the DC with the password of their machine account — that hidden account, ending in $, that every Windows box holds (here, DC01$). Netlogon opens a "secure channel" through a cryptographic handshake.

And there's the flaw. That handshake encrypts with AES in CFB8 mode, but using an initialization vector (IV) of 16 zero bytes. An IV must never be fixed or predictable; that's its only purpose. Here it was.

The consequence is pure math. In CFB8, if the IV and the plaintext are all zeros, there's a 1-in-256 chance the ciphertext comes out all zeros too — regardless of the key.

Take it to the attack: you send the DC an 8-byte challenge of zeros and a computed 8-byte credential of zeros, claiming to be the DC's own machine account. In 1 of every 256 attempts, the DC accepts you without you knowing the password. Since you only retry the handshake, roughly 256 attempts (seconds) is all it takes.

Authenticating would already be bad. But there's a second act. Once inside the channel, you invoke the NetrServerPasswordSet2 function, meant to let a machine rotate its own password. The message travels, again, padded with zeros — so you set the DC's machine account password to empty.

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.

Let that land:

You just gave the most privileged identity on the network a blank password, without knowing a single credential.

One critical detail almost nobody explains: you just broke something. The machine account's real password is still stored in the DC's local registry, but in Active Directory it's now empty. That desync breaks the DC's secure channel — and on a real domain it can take down entire services. On a professional engagement, restoring that password after dumping isn't optional: it's part of the job.

The loot: replicating the soul of the domain

With the machine account holding an empty password, you ask to authenticate as it and something brutal becomes possible. A DC's machine account has a birthright privilege: it can replicate the directory database, the way DCs sync with each other.

Abusing that is called DCSync, and secretsdump does it for you via DRSUAPI: it politely asks the DC for every secret in NTDS.dit as if it were another DC.

impacket-secretsdump -no-pass 'corp.local/DC01$@10.10.10.100'

Administrator:500:aad3b435b51404eeaad3b435b51404ee:[NT_HASH_ADMIN]:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:[NT_HASH_KRBTGT]:::
support:2106:aad3b435b51404eeaad3b435b51404ee:[NT_HASH]:::
DC01$:1001:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

That dump is a treasure map. Read it in parts:

• `Administrator:500:...` — 500 is the RID of the built-in domain Administrator. That fourth field is its NT hash: your immediate prize.
• `krbtgt:502:...` — the account that signs every Kerberos ticket in the domain. With its hash you can forge a Golden Ticket: total persistence, authenticating as anyone whenever you want. It's the jewel a serious attacker takes even after already owning the Administrator.
• `DC01$:1001:...:31d6cfe0d16ae931b73c59d7e0c089c0` — that hash, 31d6..., is a famous public constant: the NT hash of the empty string. The DC's machine account holding it is the forensic proof that Zerologon worked. (You'll see it on Guest too, whose password is empty by default.)

And what is an NT hash? Not a reversibly encrypted password: it's MD4 applied to the password in UTF-16LE. You can't "decrypt" it. But — and this is the key — you don't need to.

The NTLM protocol doesn't use your cleartext password: it uses its NT hash as the secret in a challenge-response. A conclusion that breaks a lot of mental models:

If you have the NT hash, you have the credential. You don't need to know or crack the password.

That's Pass-the-Hash. You hand the Administrator's hash to evil-winrm, which injects it into NTLM over WinRM (port 5985 from recon), and you're in as the domain Administrator:

evil-winrm -i 10.10.10.100 -u Administrator -H '[NT_HASH_ADMIN]'

Zero known passwords, zero brute force. From a misplaced IV to Domain Admin.

Door 2 — EternalBlue: the other way in

Zerologon is fine and surgical. The second door is the opposite, and that's exactly why it's so good to learn from: it shows you a completely different class of vulnerability that leads to the same place.

Remember the SMBv1:True from the banner. EternalBlue (MS17-010) is a flaw in that old SMBv1 implementation — the same one the WannaCry ransomware rode in 2017. It's not a crypto problem or an authentication-logic problem: it's a memory-corruption bug. The SMBv1 code miscalculates the size of certain packets and lets you write data where you shouldn't, until you achieve code execution in the kernel.

Where Zerologon abuses broken math, EternalBlue abuses mismanaged memory. Two different worlds, same destination: SYSTEM, the most privileged user on Windows, with no credentials.

Here's a piece of technical honesty worth gold. "Vulnerable to MS17-010" does not mean any exploit works on the first try. The most famous kernel exploit (ms17_010_eternalblue) is unstable on 2012 R2: manipulating kernel memory is fragile and often fails with a timeout. The robust path is its cousin ms17_010_psexec, which uses the same authentication bug but to write into a named pipe and launch a service as SYSTEM — far more reliable:

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)

Notice a detail that isn't cosmetic: the payload is `bind_tcp`, not reverse_tcp. The difference is the direction of the connection. A reverse shell forces the victim to connect back to you — and if a firewall or a network rule blocks that server from initiating outbound connections, your shell never arrives. A bind_tcp does the opposite: the victim listens and you connect to it. When "you to victim" is allowed but "victim to you" isn't, bind_tcp is the right call. Thinking about the direction of traffic is a skill that will save you over and over.

Two doors, one lesson

Stop for a second on what just happened. The same machine fell through two paths that have nothing to do with each other: a cryptographic design flaw in Netlogon and a memory bug in SMBv1. Different decades, different bug families, same outcome.

That's not a lab coincidence: it's how real targets are.

The defender has to close every door. The attacker only needs one.

That's why pentesting isn't about knowing one exploit, but about reading a machine and enumerating its paths. Cetro forces you to see both, and to understand that if you patch Zerologon but leave SMBv1 on, the DC falls anyway.

The other side: closing both doors

At Spartan-Cybersecurity we think like attackers, but a good attacker understands defense better than the defender does. Both doors are loud, and both can be closed.

Zerologon. The exploit fires hundreds of Netlogon authentication attempts with a zero challenge in seconds: an unnatural pattern. And the password change leaves a trail:

• Event ID 4742 — a computer account was modified (the DC machine account reset).
• Event ID 5829 — a vulnerable Netlogon connection was allowed (shows up if you're not yet in enforcement mode).

The mitigation: apply the Zerologon patch (August 2020) and confirm enforcement mode (February 2021), which rejects the vulnerable handshake. A DC whose own machine account password changes without a scheduled rotation is a red flag any SOC should hunt.

EternalBlue. It's detected by the use of SMBv1 and by the named-pipe write patterns these exploits leave. The mitigation is even simpler, and explains why a 2012 R2 in 2026 is unforgivable:

• Apply MS17-010 — the patch has existed since March 2017.
• Disable SMBv1. There's no reason to have it on today. Its mere presence (that SMBv1:True) is an audit finding in itself.

The underlying defense is the same for both: patch and reduce surface. Every old protocol you turn off is a door the attacker can no longer even try.

What you take away from Cetro

Cetro doesn't reward memorizing commands. It rewards understanding why a zero IV collapses an entire domain, why a DC's machine account is so dangerous, why a hash is as good as a password, and why a protocol that should have died in 2017 still hands out SYSTEM.

Above all, it rewards learning to read a machine and see all of its paths, not just the first one.

That's the kind of understanding that separates someone who passed a course from someone you hire for a red team. And it's exactly what we build, task by task, in the CPPJ.