# A Rogue Machine Account Is All It Takes: Inside the Certighost Domain Takeover
The attack chain is disarmingly short. A low-privileged domain user — the kind you'd find in any Windows environment, the intern's account, a service principal with minimal rights — creates a machine account, stands up a few rogue services on their own box, and tricks the certification authority into handing them a certificate that says they're a domain controller. From there, it's DCSync, krbtgt, game over. The domain belongs to them.
That's Certighost. And as of last week, there's a working PoC on GitHub.
## The Fallback Nobody Was Watching
Certighost, tracked as CVE-2026-54121 and patched in Microsoft's July 2026 Patch Tuesday, lives in Active Directory Certificate Services — specifically in a fallback mechanism the researchers call a "chase." When a certificate enrollment request includes two particular attributes, cdc (Client DC, pointing to which server the CA should contact) and rmd (Remote Domain, specifying the account to look up), the CA dutifully connects to wherever cdc points and retrieves identity information from whatever it finds there.
The problem is the word "wherever." Before this fix, AD CS did not verify that the server specified in cdc was an actual, legitimate domain controller. It just... trusted it.
Researchers H0j3n and Aniq Fakhrul, who reported the vulnerability to Microsoft on May 14, realized what that meant: if you control the server the CA calls, you control the identity information it gets back. You can tell the CA that the machine account you're looking up is a domain controller. The CA believes you. It issues a certificate accordingly.
The next steps are mechanical. The PoC tool, certighost.py, uses the fraudulent certificate to authenticate via PKINIT as the targeted domain controller, saves the resulting Kerberos ticket to a .ccache file, extracts the account's NT hash, and then uses Impacket's secretsdump to perform a DCSync and pull the krbtgt credentials. Once you have krbtgt, you can forge tickets for anyone. You own the domain.
## One Default Setting, One Open Door
The attack requires one precondition worth dwelling on: machine account creation. By default, Windows domains allow any authenticated user to create up to ten machine accounts — controlled by the ms-DS-MachineAccountQuota attribute, which ships set to 10. The researchers lean on this explicitly. The machine account the attacker creates is a valid domain principal, which satisfies the authentication checks the CA performs before connecting to the rogue service endpoint.
This is the kind of default configuration that security teams know they should change and almost never do. An ms-DS-MachineAccountQuota of zero breaks this attack cold — but it also breaks a lot of legitimate workflows, which is why the setting persists across enterprises. It's the same tradeoff that kept SMB signing disabled by default for years: the secure option exists, the insecure default ships, and environments run that way until someone makes it the attacker's on-ramp.
## AD CS Has Been a Gift That Keeps Giving
This vulnerability does not arrive in a vacuum. Active Directory Certificate Services has been one of the most fertile attack surfaces in Windows enterprise security since SpecterOps published "Certified Pre-Owned" in 2021 — the landmark research by Will Schroeder and Lee Christensen that catalogued a series of AD CS escalation paths, labeled ESC1 through ESC8, which let attackers abuse certificate templates, enrollment permissions, and CA misconfigurations to climb from low-privileged user to domain admin.
That research opened a floodgate. The years since have seen ESC9 through ESC16, multiple Kerberos certificate abuse chains, and now Certighost — an attack against the certificate issuance mechanism itself rather than template misconfiguration. Each new variant shows that the same fundamental architecture (a PKI deeply trusted by Kerberos, with numerous implicit assumptions baked in) keeps producing attack surface that wasn't anticipated when these features were designed.
The pattern is consistent: Microsoft fixes a specific instance, the research community finds another instance, the cycle continues. If your organization runs AD CS — and most Windows shops do — this is not a space where you patch once and stop worrying.
## What a Defender Needs to Do Right Now
Patch first. CVE-2026-54121 was addressed in July 2026 Patch Tuesday. If you haven't deployed those updates, this PoC reduces the exploitation barrier to anyone who can read Python.
Check your MachineAccountQuota. Run this against your domain:
Get-ADObject -Identity ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuotaIf the value is anything above zero and you don't have a documented need for it, reduce it. Zero is the right answer for most environments. If legitimate processes need machine account creation, provision a dedicated service account with delegated rights and remove the broad default.
Audit who can request certificates from which templates. Certighost attacks the enrollment mechanism, not a misconfigured template — but if attackers are probing your AD CS environment, they're probably looking at both. Use the Certipy tool to enumerate your templates and flag any that allow low-privileged enrollment for authentication-capable certificates.
Enable Extended Protection for Authentication on your CA. This doesn't directly close the Certighost vector post-patch, but it hardens the channel against related relay and authentication coercion attacks that frequently accompany AD CS exploitation chains.
Monitor for anomalous certificate requests. Certighost-style exploitation will generate CA event logs — look for certificate requests that include unusual cdc and rmd attributes, or that result in certificates for machine accounts shortly followed by PKINIT authentication from unexpected hosts.
## HackWire Analysis
The PoC release is the headline, but the more important signal is structural. Certighost represents a third distinct category of AD CS attack: first came template misconfiguration (ESC1–ESC8), then relay and coercion attacks against the enrollment process (ESC11, ESC8), and now a logic flaw in how the CA resolves identity during the chase fallback. Three different attack families, all exploiting the same core trust model — that AD CS is deeply, implicitly trusted by Kerberos and Active Directory, and that the CA will do what it's told.
The fact that a low-privileged user gets there through the ms-DS-MachineAccountQuota default is a reminder that security theater around "minimum privilege" doesn't help much when a default setting lets anyone in the domain create machine accounts on demand. Organizations that have hardened their AD CS templates but left MachineAccountQuota at 10 just traded one attack surface for another.
What's missing from most coverage of this is the detection angle. Organizations often respond to AD CS research by patching and moving on, but the audit capabilities in AD CS are genuinely good — the CA event log is verbose, and request anomalies like unusual cdc or rmd values are observable. The problem is that almost nobody is collecting or alerting on those logs. Building detection for certificate request anomalies — not just post-breach forensics — is the unglamorous work that makes the difference between catching this early and finding out about it during a DCSync in your logs.
The patch closed the door. The detective work of figuring out whether someone used it before July is where most organizations aren't looking.
— HackWire Editorial
---
## Related Coverage