TL;DR
- what: Researchers H0j3n and Aniq Fakhrul published a working exploit, dubbed Certighost, abusing an AD CS enrollment fallback (CVE-2026-54121) that lets a low-privileged user get a certificate impersonating a Domain Controller.
- impact: The forged DC credential carries directory replication rights, so the attacker runs DCSync and pulls the krbtgt secret, giving full domain compromise from a standard user account.
- fix: Install Microsoft's July 14 updates on all AD CS hosts; if patching must wait, lab-test clearing the chase flag with certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC and restart CertSvc.
- who: Any Windows Server 2012-2025 forest (and Windows 10 1607/1809) running an Enterprise CA with the default Machine template and default machine-account quota.
On July 24, researchers H0j3n and Aniq Fakhrul published a working proof-of-concept that turns any ordinary domain account into a Domain Controller. The flaw, codenamed Certighost, lets a low-privileged Active Directory user enroll a certificate that impersonates a DC, authenticate as that machine, and then use its replication rights to run DCSync and extract the krbtgt secret. That is full domain compromise starting from a standard Domain Users account, with no admin rights and no user interaction.
Microsoft patched the underlying Active Directory Certificate Services (AD CS) bug ten days earlier as CVE-2026-54121, classing it as improper authorization with a CVSS score of 8.8. Exploitation needs only network access and a domain account. As of July 24, no primary source reviewed by The Hacker News reported in-the-wild abuse, and the flaw was not in CISA's KEV catalog, but the full PoC is public. Absence of reporting is not evidence of safety.
The bug: a CA that trusts the requester
The weakness sits in an AD CS enrollment fallback called a chase. When a certification authority cannot resolve an end entity's information, the Windows enrollment protocol lets the request supply two attributes: cdc, the Active Directory server to contact, and rmd, the machine object to resolve. The researchers found the CA followed the requester-supplied cdc host over SMB and LDAP without first proving it was a real Domain Controller.
That trust is the whole game. An attacker stands up rogue LSA and LDAP services on the cdc host, relays the CA's authentication challenge to a real Domain Controller over Netlogon, and returns the target DC's objectSid and dNSHostName. A machine account the attacker controls supplies the valid domain identity the CA needs to continue. The CA authenticates that account, then signs the target Domain Controller's identity into the issued certificate.
The chain, automated
The public exploit automates every step. In the researchers' test, a normal Domain Users account created a computer account under the default ms-DS-MachineAccountQuota of 10, or reused one it already controlled via --computer-name. The tool starts listeners on ports 445 (SMB) and 389 (LDAP), relays the CA's challenge to a live DC over Netlogon, submits the cdc and rmd attributes, and writes out a PFX file and a Kerberos credential cache.
- Create or reuse a controlled computer account for a valid domain identity
- Start rogue SMB (445) and LDAP (389) listeners as the fake cdc
- Relay the CA's authentication challenge to a real DC over Netlogon
- Return the target DC's objectSid and dNSHostName to the CA
- Receive a DC certificate, then use PKINIT to authenticate as that DC
- Run DCSync with the DC's replication rights to pull krbtgt and other secrets
⚠️ Preconditions that make you exploitable — The PoC was validated against a Windows Server 2016-or-later forest running an Enterprise CA that follows the vulnerable chase path, using the default Machine certificate template, with the default machine-account quota of 10, and network reachability from the CA to the attacker's SMB and LDAP listeners. The NVD record lists Windows Server 2012 through 2025 (including Server Core) and Windows 10 1607/1809 as affected.
What the patch actually changes
The researchers' binary analysis found Microsoft's July update adds a new check, CRequestInstance::_ValidateChaseTargetIsDC, to certpdef.dll before the CA follows a chase. The validation rejects IP literals, overlong names, and LDAP metacharacters. It requires exactly one matching Active Directory computer object whose DNS name matches the target and whose userAccountControl carries SERVER_TRUST_ACCOUNT (8192), the flag that marks a real Domain Controller. A later SID comparison blocks object substitution. In short, the CA now proves the chase target is genuinely a DC before trusting it.
What to do now
If you run an Enterprise CA, install Microsoft's July 14 updates on every AD CS host. Treat this as urgent: the exploit is public, the entry cost is a single domain account, and the payoff is krbtgt, which underwrites persistent domain-wide access. Patched CAs neutralize the chain regardless of template or quota configuration.
If you cannot patch immediately — Administrators can clear the chase flag and restart Certificate Services: certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC followed by Restart-Service CertSvc -Force. The researchers tested this only in a controlled lab and warn it can break legitimate enrollment flows. Stage it first, and treat the July update as the permanent fix, not the workaround.
The bigger picture
Certighost is another AD CS misplaced-trust bug in the lineage of the ESC certificate-abuse research. The recurring lesson: certificate services sit at the center of domain identity, and a CA that trusts attacker-supplied inputs hands out identities it was never asked to verify. Audit which templates allow machine enrollment, tighten ms-DS-MachineAccountQuota toward zero where users have no need to join machines, and monitor for certificate requests that resolve to Domain Controller identities. Those controls raise the bar even when the next chase-style fallback surfaces.
Originally published on RedEye Threat Intelligence.
