Certighost (CVE-2026-54121): domain takeover via AD CS

On 24 July 2026, researchers H0j3n and Aniq Fakhrul published a working exploit for CVE-2026-54121, dubbed Certighost. The impact is about as bad as it gets in a Windows environment: an ordinary domain user — no admin rights, no victim interaction — can obtain a certificate authenticating them as a domain controller, then run DCSync and extract the krbtgt hash. That’s full domain compromise starting from an intern’s account.

Microsoft patched the bug on 14 July 2026, ten days before the exploit went public. If your domain controllers and CA servers took the July updates, you’re in good shape. If they didn’t, your grace period just ended. Below we stick to what Microsoft and the exploit authors confirmed; where something depends on configuration, we say so explicitly.

Context: why AD CS is such a rewarding target

Active Directory Certificate Services is internal PKI. In practice that means the certification authority (CA) is a machine that issues proof of identity on request, honoured across the entire domain. If you can persuade the CA to issue a certificate for someone else’s identity, you don’t need to crack a password — you simply receive credentials and log in as another principal (PKINIT → TGT → Kerberos).

Since 2021 we’ve known a whole family of such issues tracked as ESC1–ESC16 (template misconfigurations, excessive permissions, NTLM relay to enrolment endpoints). We covered them in our piece on AD CS certificate attacks. Certighost is more interesting because it is not an administrator’s misconfiguration — it’s a flaw in the CA’s own code, in a mechanism most teams didn’t know existed.

Anatomy: what “chase” is and where it broke

At the heart of the vulnerability is a little-known directory-object resolution mechanism on the CA side, referred to in code as chase. When the CA processes a certificate request, it must establish who the requesting principal is — which means querying the directory for their attributes. Certighost abuses the fallback path of that process.

The mechanics, in short:

1. The attacker controls who the CA asks. By supplying particular request attributes (notably cdc), the attacker makes the CA reach out for identity data to an attacker-controlled host instead of querying a trusted domain controller.
2. Rogue services on the attacker’s side. The attacker stands up their own substitute LSA and LDAP services. Those answer the CA’s identity questions.
3. Relaying authentication over Netlogon. To make the substitute service look legitimate, the CA’s authentication challenge is relayed to the real domain controller over the Netlogon channel. The attacker doesn’t know the secret — they simply pass the conversation through.
4. Returning the victim’s attributes. The rogue LDAP hands the CA the target domain controller’s attributes: objectSid and dNSHostName.
5. The CA signs someone else’s identity. Having never verified that the host it queried is actually a domain controller, the CA writes the received data into a certificate and signs it.

The entry requirement is possession of a machine account. And here’s the second piece of bad news: in a default AD configuration ms-DS-MachineAccountQuota is 10, meaning any authenticated user can create up to ten computer accounts themselves. So the attacker needs no privilege at all — membership in Domain Users suffices.

From certificate to krbtgt

The certificate alone isn’t the end, but the road onward is short and entirely “legitimate” from the protocols’ point of view:

1. The attacker uses the certificate for PKINIT authentication and receives a TGT as the domain controller account.
2. Domain controller accounts hold directory replication rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All).
3. With those rights the attacker performs DCSync — telling a real DC “I’m a domain controller, replicate the data to me” — and pulls hashes, including krbtgt.

A krbtgt leak is the worst-case scenario: it enables Golden Tickets, arbitrary Kerberos tickets for any user, valid until that account is rotated twice. Patching Certighost does not remove such access — the same lesson as in any serious breach: stealing a secret makes the attacker immune to the patch.

Note that Certighost combines techniques that are individually well known: spoofing directory services, authentication relay (as in NTLM relay to SMB/LDAP) and machine-identity abuse (as in Kerberos delegation and RBCD). The only novelty is the point at which the CA can be fooled.

What Microsoft did

The 14 July 2026 fix adds a validation routine for the chase target to the certpdef.dll library — identified in public analyses as CRequestInstance::_ValidateChaseTargetIsDC. In other words: the CA now checks whether the host it intends to “chase” for identity data really is a domain controller, instead of trusting what the requester supplied.

Microsoft classified the bug as improper authorization with a CVSS 8.8 rating. The vector requires network access and a domain account, but no administrator rights and no user interaction — so treat it as critical in practice, regardless of it not being a “ten”. This is a classic case where the CVSS score doesn’t reflect real risk: 8.8 describes a single step, not the end state, which is takeover of the entire AD forest.

Action plan — order matters

1. Patch CA servers and domain controllers. July 2026 updates or later. This is the only action that actually closes the hole. Priority: every server with the AD CS role, then domain controllers.

2. Check whether you’re already too late. With a public exploit, assume prior use is possible. Specific places to review:

• CA logs (CertUtil -view / certificate issuance events 4886/4887) — look for certificates issued with a domain controller identity that nobody requested, especially requested by freshly created computer accounts.
• Computer account creation — event 4741 (A computer account was created) initiated by a regular user is worth attention in any domain.
• PKINIT authentications — event 4768 (TGT) using a certificate for a domain controller account from an unusual address.
• DCSync from an unexpected source — event 4662 with DS-Replication-Get-Changes-All performed by a principal that is not a domain controller. This is one of the most valuable detection rules you can own.

3. If you see traces, treat it as full domain compromise. That means a double krbtgt rotation (with enough spacing for replication and ticket expiry), a review of privileged group memberships and of persistence mechanisms.

4. Harden what should have been hardened anyway. Regardless of this specific flaw:

• Set ms-DS-MachineAccountQuota to 0 and delegate computer-account creation to designated teams. That single setting removes the entry vector for a whole family of attacks, not just Certighost.
• Limit exposure of CA roles — enrolment/write interfaces shouldn’t be reachable from the entire user network.
• Enforce EPA/signing where possible, to frustrate classic relay scenarios.
• Monitor AD CS as a critical system — because it is. A CA server wields power comparable to a domain controller, yet is often treated as “that old certificate box”.

These points are the foundation of broader Active Directory security and part of a standing vulnerability management process, not a one-off reaction to a single CVE.

Frequently asked questions (FAQ)

We don’t run AD CS — are we safe? For Certighost, yes: the certification authority role is what’s vulnerable. But verify that with facts rather than memory — AD CS often gets deployed “along the way” (for Wi-Fi 802.1X, VPN or document signing) and runs for years without an owner. Check whether a forgotten server holds that role.

We have AD CS but don’t use certificate authentication. Does that protect us? Not in any obvious way. The problem lies in how the CA issues the certificate, and the resulting certificate is used for Kerberos authentication (PKINIT), which works in the domain regardless of whether you “use certificates” day to day.

Does ms-DS-MachineAccountQuota = 0 replace the patch? No. It raises the bar and removes the most convenient path (creating your own computer account), but an attacker who already controls any machine account still has what they need. Set the quota and patch.

We patched in July. Case closed? The vector is closed. What remains open is whether anyone used it beforehand — so review CA logs, computer-account creation and replication events retrospectively. If you find anything unusual, run it as an incident, not as trivia.

How do we test our resilience to this class of attack? An internal AD assessment from a regular user’s perspective shows the real path from an employee account to domain admin — including AD CS configuration, machine-account quota and relay opportunities. Get in touch if you want that verified in your environment.

Summary

Certighost (CVE-2026-54121) is a textbook case of a single missing validation turning an ordinary user account into administrator of an entire domain. The chain is short, fully automated and publicly available since 24 July 2026: computer account → fool the CA via chase → domain controller certificate → PKINIT → DCSync → krbtgt. Patching takes one maintenance window; rebuilding a domain after Golden Tickets takes weeks. If you want to know how far an attacker starting from a regular employee account would get in your network, let’s find out with a controlled test.

---

Sources and further reading: Microsoft MSRC — CVE-2026-54121, The Hacker News, H0j3n technical write-up, SpecterOps — Certified Pre-Owned.