A normal domain user —the kind who can only print and read email— could, with any account and no admin rights, impersonate a Domain Controller and walk away with the keys to the entire domain. It's called Certighost, it's CVE-2026-54121, and it wasn't a kernel bug or an exotic 0-day: it was the part of Windows that issues trust —certificates— trusting the wrong party.
Microsoft fixed it in the July 14, 2026 Patch Tuesday. The researchers who found it —H0j3n and Aniq Fakhrul— published a fully working PoC on July 24. In other words: the patch has been available for ten days and now there's public code that exploits it. If your Active Directory has an integrated CA (and many do without realizing it), this post is your plan for today.
Certighost in one sentence (and why it hurts this much)
Active Directory Certificate Services (AD CS) is the certification authority many companies stand up inside their Windows domain. When issuing a certificate, if the CA can't obtain all of the end-entity information, the enrollment protocol allows a fallback known as a chase: the requester can supply attributes —cdc (which directory server to query) and rmd (which machine object to resolve)— so the CA goes and fetches the missing data.
The flaw: the CA followed the host the requester supplied without first verifying it was a real Domain Controller. The attacker stood up fake LDAP and SMB services, answered with a real DC's identity (its SID and hostname), and the CA signed that identity into the certificate. With a certificate that says "I am a Domain Controller", the rest is textbook: a Kerberos credential with replication rights, a DCSync to pull the krbtgt account hash and, with that, full domain control. Microsoft classed it as improper authorization with a CVSS of 8.8.
The detail that makes it so accessible: the attacker needed a machine account to provide valid identity, and that's where another piece comes in. By default, any domain user can create up to 10 machine accounts (the ms-DS-MachineAccountQuota attribute is set to 10). You don't need to be an administrator of anything. Just a user, on the network.
This isn't a one-off bug: AD CS has been the favorite shortcut for years
If Certighost rings a bell, it's because it isn't the first. Since SpecterOps published the first family of AD CS escalation techniques in 2021 —now extended up to ESC1–ESC16—, the certification authority has become one of the cleanest paths from "normal user" to "domain admin". The underlying reason: the CA is the machine that manufactures identity. Whoever gets it to issue a certificate in their name —or a DC's— doesn't need to steal a password: the trust infrastructure signs it for them.
And here's the uncomfortable part: AD CS is usually set up once, "so certificate WiFi and the VPN work", and then nobody looks at it again. It doesn't show up in the application inventory, it has no clear owner, and its certificate templates —where most of the misconfigurations live— were last touched by someone three years ago. The Certighost patch plugs this hole; it doesn't tell you whether the template that lets a user set their own subject name (the classic ESC1) has been sitting open since 2019.
The plan for today: what to do, in this order
It's not a 20-item list. It's five decisions, ordered by what actually reduces risk:
- 1Patch. The July 2026 update is the definitive fix: it adds a validation (
_ValidateChaseTargetIsDC) that checks the target is a real DC —it rejects literal IPs, names with LDAP injection characters and requires the account to carry theSERVER_TRUST_ACCOUNTflag—. There's a temporary mitigation for those who can't patch yet (disable the chase withcertutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDCand restartCertSvc), but the researchers themselves only tested it in a lab: it's a tourniquet, not the cure. - 2Find out whether you have AD CS —and how many CAs—. It sounds absurd, but it's the step most people skip. Many domains inherit a CA some consultant stood up years ago for a one-off project and that's still alive, issuing, with no owner. If it's not in your inventory, you're neither patching nor watching it.
- 3Set
ms-DS-MachineAccountQuotato 0. Preventing a normal user from creating machine accounts cuts the primitive that Certighost and half a dozen other attacks need (NTLM relay, RBCD…). Only administrators or delegated accounts should join computers to the domain. It's a one-value change, free, and it removes a lever from a whole set of techniques at once. - 4Audit the CA's templates and permissions. This is where the chronic risk lives. Tools like
Certipy(in find mode),LocksmithorPSPKIAuditreview the ESC1–ESC16 family and tell you which template lets someone request a certificate with an arbitrary subject name, who can enroll, and where manager approval is missing. What an attacker uses to find the hole, you use to close it first. - 5Reduce exposure and watch the right logs. The CA server and its web enrollment don't need to be reachable from the entire flat network; segment them. And keep an eye on certificate issuance and directory replication events (DCSync): an odd certificate request or a DCSync from something that isn't a DC is exactly the signal you want to catch in time.
What we would NOT do
- ✗Ripping out AD CS in a panic. Half the network depends on those certificates (WiFi, VPN, machine authentication). Tearing it out at once breaks more than it fixes. You patch it, audit it and tidy it up; you don't amputate blindly.
- ✗Considering it closed once you've patched. The patch kills Certighost, not the misconfigured templates that have been there for years. Applying the update and not auditing the CA is changing the front-door lock while leaving the window open.
- ✗Assuming "it's Microsoft's, so it must be fine". AD CS is a component you install and configure yourself; its security depends on how you left the templates and permissions, not on a vendor checkbox. Configuration responsibility is yours.
The bottom line: the plane that issues trust is worth more than any server
Certighost is one more case of a pattern we see again and again: what really needs protecting isn't "a server", it's the system that manufactures identity and trust —the CA, the domain controller, the identity provider—. An attacker who bends that plane doesn't need to steal anything from you: they issue themselves the permission. That's why least privilege (a normal user unable to create machine accounts), assume-breach (watching as if they're already inside) and auditing configuration instead of trusting the default state aren't Zero Trust slogans: they're the job.
Not all our clients run AD CS, but those with an Active Directory and an integrated CA have almost never looked at it since it was set up. And that "almost never" is exactly the gap these things slip through.
Sources (verified): mechanism, cdc/rmd attributes, _ValidateChaseTargetIsDC patch, mitigation and timeline (reported May 14, patched Jul 14, PoC Jul 24, 2026) — cybersecuritynews.com and The Hacker News; original PoC by H0j3n and Aniq Fakhrul — H0j3n's gist; ESC1–ESC16 family and auditing with Certipy/Locksmith/PSPKIAudit — public AD CS research. CVSS 8.8 and no confirmed exploitation in CISA KEV as of Jul 24, 2026.
Do you know what's inside your Active Directory —and who can manufacture identity in it?
At everyWAN we audit identity and security configurations without selling anyone's licenses: we tell you what's misconfigured and what moves the needle. We review your cybersecurity posture and work with you through consulting to tidy it up, before it becomes an incident.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN