Certighost: A Low-Privileged AD User Can Forge a Domain Controller (CVE-2026-54121)

Researchers H0j3n and Aniq Fakhrul have disclosed Certighost, tracked as CVE-2026-54121 (CVSS 8.8), a flaw in Active Directory Certificate Services (AD CS) that turns any ordinary domain account into a path to full domain takeover. Microsoft shipped the patch on July 14, 2026; the researchers published their writeup and a working proof-of-concept on July 24. This is not a phishing story or a misconfiguration story. It is a design flaw in how the Certificate Authority decides who it is talking to.

The short version: the CA can be tricked into issuing a certificate that carries a domain controller's identity to an attacker who is not a domain controller. Once you hold a certificate for the DC, Active Directory treats you as that DC. Everything downstream, up to and including the krbtgt hash, follows.

What the "chase" fallback actually does

AD CS enrollment has a fallback path internally called a "chase." When the CA needs to resolve details about the client requesting a certificate, it will follow a requester-supplied host over SMB and LDAP. The bug, per the researchers, is that the CA does this without first proving that host is a real domain controller. It trusts the name it was handed. That single missing check is the whole vulnerability, and it is why the fix is a new validation routine, CRequestInstance::_ValidateChaseTargetIsDC, added to certpdef.dll.

An attacker chains a handful of well-known Active Directory primitives on top of that trust gap. The stacked panel above walks the full sequence; the key links are these:

• A machine account, for free. The default ms-DS-MachineAccountQuota of 10 lets any authenticated user create computer accounts. The attacker uses one as the identity the CA will "chase."
• Rogue LSA and LDAP services. The attacker runs their own services on ports 445 and 389, so when the CA reaches out over SMB and LDAP it talks to attacker-controlled infrastructure and relays the CA's Netlogon authentication challenge to the real domain controller.
• A certificate for the DC's identity. Through that relay the attacker obtains the target DC's objectSid and dNSHostName, and the CA signs a certificate bound to that identity.
• Authenticate as the DC. Using PKINIT with that certificate, the attacker authenticates as the domain controller, then performs a DCSync to replicate secrets, including the krbtgt account hash.

Why this belongs in the crown-jewel tier

Most privilege-escalation bugs get you from low to high on one machine. Certighost gets you from a single unprivileged domain user to the krbtgt hash, which is the root of trust for Kerberos across the entire domain. With krbtgt an attacker can forge golden tickets for any user, including domain admins, and reassert access long after you think you have evicted them. Recovering from a krbtgt compromise is one of the most painful operations in AD incident response: a double password rotation, careful timing, and a stretch where things break. This is precisely the outcome AD CS escalation research has been circling for years, and Certighost is a clean, low-precondition route to it.

Affected versions

The flaw affects AD CS on Windows Server 2012 through 2025, including Server Core installations, plus Windows 10 versions 1607 and 1809. In other words, essentially every supported Windows environment running a Certificate Authority. If you run AD CS anywhere, assume you are in scope until you have confirmed the July 14 update is deployed on the CA.

Exploitation status

As of July 24, no primary source has reported exploitation in the wild. That is the good news, and it is thin. The full proof-of-concept is publicly available on GitHub, the mechanism is well understood, and the building blocks, machine-account creation plus SMB and LDAP relay, are already in every red-team and ransomware-affiliate toolkit. The gap between "PoC published" and "used in intrusions" for AD CS escalations has historically been short. Treat the disclosure date as the start of the clock, not a grace period.

What to do now

• Patch the CA. Deploy Microsoft's July 14, 2026 update to every AD CS server. This is the only complete fix; it adds the missing "is this actually a DC" validation.
• If you cannot patch immediately, disable the chase fallback: certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC then Restart-Service CertSvc -Force. Test in a maintenance window; this changes enrollment behavior.
• Set ms-DS-MachineAccountQuota to 0 and grant machine-account creation only to a controlled provisioning group. This removes the attacker's starting building block and hardens you against a whole family of relay attacks.
• Enforce SMB signing and LDAP channel binding and signing. The attack depends on relaying authentication; these controls break the relay leg independent of the AD CS patch.
• Tier your CA. The Certificate Authority is Tier 0. It should not be reachable from, or share administration with, general workstations and servers.

Detection guidance

Hunt on the Certificate Authority and domain controllers, not the endpoint. Watch for:

• Certificate issuance events (4886 / 4887) where the requester and the subject identity do not line up, especially certificates whose subject maps to a domain controller account but were requested by a machine account created minutes earlier.
• Machine-account creation (4741) from unexpected users, immediately followed by certificate enrollment.
• Certificate-based Kerberos authentication (4768 with certificate information) for a DC identity originating from an unusual host.
• Replication / DCSync activity (4662 with the replication GUIDs) from any principal that is not a known domain controller. This is the loud, high-value signal and should already be an alert.