A Fake Passport to Your Domain: How Certighost Turns a Basic Account Into a Domain Controller

CISO SUMMARY

CertiGhost allows a basic Active Directory account to become a full domain takeover by tricking a trusted certificate system into treating the attacker like a domain controller. Installing Microsoft’s July 14 patch is important, but security teams should also confirm the protection is actually active across their environment. CISOs and their security teams should restrict certificate servers so they can communicate only with approved systems and block unauthorized attempts to copy sensitive identity data from domain controllers. The larger lesson: patches fix individual flaws, while segmentation and tight access controls can stop entire categories of attack.

 

Microsoft fixed CertiGhost on July 14, 2026. Researchers H0j3n and Aniq Fakhrul published a working proof-of-concept ten days later. If your CAs and domain controllers took the July updates, you are probably in reasonable shape — but you should be aware of the patch-versus-enabled loophole attackers are betting on and go verify that the fix is actually enforcing on your CAs and DCs, not just sitting around installed but inactive. 
I want to share a note on what “patched” means in AD CS specifically. When Microsoft shipped the SID security extension in May 2022 to counter Certifried (CVE-2022-26923), the fix arrived in a compatibility mode that still permitted weak certificate mapping. Full enforcement did not become the default until February 2025, three years later, which means the fix was installed almost everywhere but enforced almost nowhere unless an administrator knew enough to go investigate it. That’s a wide open door for attackers to sneak through. 
The CertiGhost fix leaves a similar attack vector open to attackers – but it hides in plain sight. The new validation sits behind a Windows velocity feature gate — Feature_3185813818 in the patched certpdef.dll, guarding the branch that calls _ValidateChaseTargetIsDC. Velocity gates are ordinary servicing machinery, not evidence of an incomplete fix: they let Microsoft stage, wave, or roll back a change without shipping a new binary, and MSRC security fixes are one of the things they gate. Most security features ship as always-enabled, in which case the gate is a rollback lever nobody will ever pull. What this means to real security teams is that enforcement is a runtime state rather than a property of the build, and a runtime state is something you have to confirm on your own CAs rather than infer from a patch level.
The rest of this post is about the more uncomfortable question. CertiGhost is a low-privileged domain user turning into krbtgt in a single automated script. The chain is short, the prerequisites are close to default, and nothing in it exploits memory corruption or breaks cryptography. It is a missing validation in a trust decision.
Since Will Schroeder and Lee Christensen published Certified Pre-Owned in 2021, the community has kept a running catalogue of AD CS escalation paths: ESC1 through ESC8 in the original research, extended by later work to ESC17. It's not a Microsoft scheme and not a CVE series — it’s an informal numbering that grows whenever someone finds another way to turn certificate issuance into domain privilege. Most of the seventeen are misconfigured templates or weak ACLs on PKI objects. Two of them, ESC8 and ESC11, are relay attacks that work for no reason more sophisticated than an enrollment endpoint being reachable by something that should never have reached it. CertiGhost belongs to the same family: the CA made a trust decision on data an attacker supplied. There will be an eighteenth.
So: if you had not patched on July 14, what in your network would have stopped this?
For most environments the honest answer is nothing, because the attack looks like ordinary Windows traffic at every step. But two of the four network legs in the chain are gateable with controls that don’t know or care that CertiGhost exists. That is the point worth making. 

Key answers in this article

• What is CertiGhost (CVE-2026-54121) and why does patching alone not close the risk? CertiGhost is an Active Directory Certificate Services (AD CS) exploit chain that turns a low-privileged domain user into a domain controller by tricking a certificate authority into signing a DC-identity certificate, which converts into krbtgt compromise via PKINIT and DCSync. Microsoft patched it July 14, 2026, but the fix ships behind a Windows velocity feature gate, meaning enforcement is a runtime state on each CA rather than a guaranteed property of the patch — the same pattern that left the 2022 Certifried fix in compatibility mode for nearly three years.
• How does the CertiGhost attack chain actually work? The exploit abuses AD CS's "chase" fallback, where a CA follows attacker-supplied cdc and rmd enrollment attributes to a secondary lookup host without validating it's a real domain controller; an attacker stands up rogue SMB/LDAP/LSA services, creates a machine account via the default ms-DS-MachineAccountQuota, relays Netlogon authentication to a real DC, and receives a certificate carrying that DC's identity.
• What single network control neutralizes the most dangerous leg of the attack? Default-deny egress on the certificate authority — permitting outbound SMB and LDAP only to known domain controllers — collapses the attack before identity confusion occurs, because this control requires no knowledge of CertiGhost, no signatures, and no patch-level awareness; it simply enforces that a CA's legitimate outbound peer set is small, stable, and enumerable.
• Why does per-asset microsegmentation matter more than per-subnet or VLAN-based rules? A CA sitting in a broad server VLAN with permissive east-west traffic has effectively no egress policy at all; the defensive value comes specifically from scoping rules to the individual asset (or even the process, like certsrv.exe), since CAs have a narrower legitimate communication footprint than the network segment they sit in.
• What is the single highest-ROI rule for blocking this entire class of AD CS attacks? Denying DCSync (MS-DRSR / DRSGetNCChanges) from all non-domain-controller sources is a narrow, low-breakage rule that neuters CertiGhost, every AD CS ESC escalation path, Zerologon, and any other attack whose final move is replicating secrets out of the directory.
• What's the broader architectural lesson beyond this one CVE? CertiGhost will be patched and forgotten within months, like the ESC series before it — but every one of these bugs shares the same weakness: a trust decision made on attacker-influenced data. The defense that ages well isn't one that recognizes cdc specifically; it's one that constrains what a compromised or confused asset can reach, since a CA that can't open SMB to an arbitrary host is indifferent to which validation was missing this time.

The chain, briefly

Certificate enrollment in AD CS has a fallback path the researchers call a chase. When the CA can’t resolve the requester’s directory object locally — a real scenario in multi-domain forests with replication lag — the enrollment request may carry two attributes that steer a secondary lookup: cdc, naming the host the CA should contact, and rmd, naming the principal to resolve.
Before the July patch, the CA followed the cdc value without confirming that the host was actually a domain controller. In certpdef.dll, CRequestInstance::_LoadPrincipalObject read the attribute straight out of the request and passed it into _GetDSObject with chase enabled. The July build wraps that call in _ValidateChaseTargetIsDC, which rejects IP literals, LDAP metacharacters, and oversized hostnames, then queries AD for exactly one computer object whose dNSHostName matches and whose userAccountControl carries SERVER_TRUST_ACCOUNT (8192).
The exploit stands up rogue SMB, LDAP, and LSA services on an attacker-controlled host, creates a machine account through the default ms-DS-MachineAccountQuota of 10 so it holds a genuine domain identity, and points cdc at itself. When the CA connects, the rogue services relay the authentication challenge to the real DC over Netlogon — satisfying the CA’s authentication checks — while returning the target DC’s objectSid and dNSHostName as directory data. The CA signs a certificate carrying a domain controller’s identity. PKINIT converts that into Kerberos credentials for the DC, and DCSync converts those into krbtgt.
Four network legs matter:

Leg	Traffic	Direction
1	Enrollment request carrying cdc / rmd	Attacker → CA
2	The chase: SMB and LDAP to the cdc target	CA → Attacker
3	Netlogon relay of the CA's challenge	Attacker → DC
4	DCSync via directory replication	Attacker → DC

 

 

 

 

 

 

Leg 2 is the one to sit with. Every other leg is an attacker reaching into your infrastructure, which is the situation security tooling is built for. Leg 2 is your certificate authority — one of the most trusted machines in the domain — opening an SMB and an LDAP session outbound to an attacker’s Linux box, because a string in an untrusted request told it to.

Leg 2: the CA’s outbound peer set is small, and this isn’t in it

A certificate authority is not a general-purpose client. Its legitimate outbound connections are few, stable, and enumerable: domain controllers, its database, possibly an HSM, and wherever it publishes CRLs. That list changes on the order of once a year.
Which means the exploit’s critical leg is not merely suspicious — it is outside the CA’s entire behavioral envelope. Default-deny egress on the CA, permitting SMB and LDAP only to known domain controllers, collapses the attack before the identity confusion ever happens. The rogue LSA service never gets a connection. No directory data comes back. No certificate is issued.
The bar this sets is high rather than infinite. An attacker who has already compromised a host the CA is permitted to reach can stand the rogue services up there instead, and the chase succeeds. But that moves the prerequisite from “create a machine account, which the default quota lets any user do” to “own something on the CA’s short list of permitted peers” — a materially different class of problem, and one you are far more likely to have instrumented.
The thing worth dwelling on is that this control requires knowing nothing about CertiGhost. It doesn’t parse cdc. It doesn’t inspect enrollment attributes. It doesn’t need a signature, a patch level, or a threat intel feed. It enforces a statement that was true before the CVE existed and remains true after: this CA talks to these hosts on these ports, and nothing else.
Two things make this practical rather than aspirational. The first is automated policy generation — you cannot hand-write egress policy for every server in an estate, but you can observe what each asset actually connects to and propose a least-privilege ruleset from that — then run it in monitor mode and see what it would have blocked before it blocks anything. The organizations that get burned by least-privilege network policy are the ones that wrote it from an architecture diagram instead of from observed traffic. The second is that policy has to be per-asset rather than per-subnet. A CA in a broad “server VLAN” with permissive east-west rules has effectively no egress policy at all; the whole value is in the CA’s ruleset being narrow specifically because CAs have narrow needs.
If you want to go further, per-process egress narrows it again: certsrv.exe has a smaller legitimate peer set than the host as a whole, and the chase originates from exactly that process.

Legs 1 and 4: RPC-layer control

The remaining legs are RPC, which makes them addressable at a different layer.
Leg 1 is MS-WCCE enrollment. In the public PoC — impacket-based, no web enrollment endpoint involved — that means ICertPassage over DCERPC on the \pipe\cert named pipe: interface 91ae6020-9e3c-11cf-8d7c-00aa00c091be, opnum 0, CertServerRequest. The cdc and rmd attributes ride in that call’s attribute string. Note the transport: this is ncacn_np over port 445, not ncacn_ip_tcp over 135, so a port-based rule aimed at the RPC endpoint mapper never sees it. An RPC firewall that hooks the RPC runtime rather than filtering ports does.
Be precise about what this buys you. Filtering at the interface and opnum level tells you who may submit enrollment requests over RPC; it does not distinguish a malicious cdc from a benign one, because the discriminator is a string inside the parameters. So Leg 1 is an allow-list exercise: enrollment RPC to the CA should come from managed endpoints and enrollment proxies, not from an unmanaged host that appeared in the domain forty seconds ago. That shrinks the population who can attempt the attack. It does not identify the attempt.
It also only covers the RPC transport. If you run Certificate Enrollment Web Services, MS-WSTEP over HTTPS reaches the same policy module and the same chase logic, and RPC-layer filtering is blind to it. Leg 1 coverage is incomplete wherever web enrollment is deployed — which is another argument for Leg 2 carrying the weight, since egress policy on the CA is indifferent to how the request arrived.
That allow-list does have a second payoff worth naming. ESC11 is NTLM relay against precisely this interface — the RPC-based enrollment endpoint, as distinct from ESC8, which relays to the HTTP one. So restricting who may reach ICertPassage constrains CertiGhost’s submission leg and ESC11 with the same rule. That is the difference between an architectural control and a patch: the patch closes one bug, the rule closes a class of reachability.
Leg 4 is where RPC filtering earns its keep unambiguously. DCSync is MS-DRSR — interface e3514235-4b06-11d1-ab04-00c04fc2dcd2, DRSGetNCChanges at opnum 3. Only domain controllers have any business calling it. Denying it on your DCs from every non-DC source is a narrow, low-breakage rule, and it neuters the payoff of this attack, every AD CS ESC path, Zerologon and its derivatives, and any other chain whose final move is replicating secrets out of the directory. If you implement one rule from this post, implement that one.
Leg 3, the Netlogon relay, is MS-NRPC (12345678-1234-abcd-ef00-01234567cffb). It is RPC, but every domain-joined machine legitimately speaks it to DCs, so protocol-level blocking is disruptive. The tractable angle is source identity rather than protocol: an unmanaged Linux host making NRPC calls is the anomaly. Treat this as a detection opportunity, not a chokepoint.
Both rules want an audit pass before an enforcement pass. Logging calls to ICertPassage and DRSUAPI for a week gives you the real caller population, which is almost always narrower and stranger than the documentation implies, and occasionally includes a backup agent nobody remembers deploying.
One non-network control belongs on the same list, because it is cheaper than everything above it: set ms-DS-MachineAccountQuota to 0. The exploit needs a machine account to hold a valid domain identity, and the default lets any authenticated user create ten of them.

The generalization

CertiGhost will be patched everywhere within a few months and then largely forgotten, which is roughly what happened with the ESC series before it. The structural observation outlasts it.
Every one of these bugs is a trust decision made on data the attacker influenced, and the fix is always the same shape: add the validation that was missing. So the defense that ages well is not the one that knows about cdc. It is the one that constrains what a compromised or confused asset can reach — because a certificate authority that cannot open SMB to an arbitrary host, and a domain controller that will not replicate secrets to a non-DC, are indifferent to which validation was missing this time.
The cryptography was never the weak part. The reachability was.
If you want to see and control what your CAs and DCs can actually talk to right now — not what you assume they can talk to — request a demo.