Secure Bulletin Navigating the cyber sea with knowledge
Home > Articolo > Certighost Flaw Let Ordinary Users Impersonate Domain Controllers and Seize Active Directory
Certighost Flaw Let Ordinary Users Impersonate Domain Controllers and Seize Active Directory
Read Time:3 Minute, 50 Second

Microsoft’s July 2026 security updates quietly closed one of the more elegant Active Directory attack paths disclosed this year: a flaw researchers have named Certighost, tracked as CVE-2026-54121. On paper, it required nothing more than an ordinary, low-privileged domain account. In practice, it could hand an attacker the keys to an entire Windows domain.

How Certificate Services Became the Weak Link

Active Directory Certificate Services (AD CS) is the public key infrastructure that underpins much of a Windows domain’s trust model, issuing the X.509 certificates used for signing, encryption, and authentication. One increasingly common use of that infrastructure is certificate-based Kerberos authentication, known as PKINIT, where a client presents a certificate to the Key Distribution Center in exchange for a ticket. The KDC’s job is to map the identity embedded in that certificate back to a real Active Directory account, and it is precisely this mapping step that Certighost quietly broke.

During certain enrollment flows, the certificate authority performs what researchers describe as a secondary lookup, or “chase,” governed by two attacker-influenceable request fields: one specifying which host the CA should contact, and another specifying which identity to resolve. According to the advisory, the vulnerable CA code trusted whatever host was supplied without ever confirming it was an actual Domain Controller.

From Rogue Server to Domain Takeover

That trust gap opened the door to a surprisingly practical attack chain. A malicious actor could spin up their own SMB, LDAP, and LSA services, point the CA at that rogue infrastructure, and feed back fabricated identity data, including a legitimate Domain Controller’s SID and DNS hostname. Combined with Active Directory’s default machine account quota, which allows any ordinary user to register up to ten machine accounts, an attacker’s own server could pass the CA’s checks as a plausible domain principal despite not being a Domain Controller at all.

Once the certificate authority issued a certificate carrying that impersonated Domain Controller’s identity, the attacker could authenticate as if they were that machine. Because Domain Controllers hold directory replication rights, that access is enough to run a DCSync-style extraction, pulling sensitive secrets such as the krbtgt account hash, which effectively unlocks the ability to forge tickets for any user in the domain.

  • A single low-privileged account is the only prerequisite.
  • Rogue SMB, LDAP, and LSA services simulate a trusted Domain Controller.
  • Default machine account quotas provide the extra identity needed to pass validation.
  • Successful exploitation leads directly to a full domain compromise via DCSync.

What Microsoft’s Patch Actually Changes

The July fix introduces a new validation routine, gated behind a servicing feature flag, that runs before the CA is allowed to follow a chase target. It now rejects empty, oversized, or IP-literal hostnames, blocks characters associated with LDAP injection, queries Active Directory to confirm the target genuinely carries the server-trust-account flag, and performs a follow-up SID comparison to prevent attackers from substituting one object for another. Only once all four checks pass does certificate issuance proceed.

Mitigating Without an Immediate Patch

Organizations that cannot deploy the July update right away have a temporary lever: disabling the vulnerable chase fallback via the EDITF_ENABLECHASECLIENTDC registry flag and restarting the certificate services process. Microsoft and researchers are both clear that this is a stopgap rather than a fix. If the flag is ever re-enabled, whether through group policy drift, a reimaged server, or a well-meaning administrator restoring a legacy workflow, the certificate authority becomes exploitable again. Any organization relying on this mitigation should test it in staging first, since legitimate workflows that depend on the chase fallback will break.

A working proof-of-concept for Certighost is already circulating publicly, which raises the urgency for defenders considerably. Security teams running AD CS should treat this as a priority patch rather than a routine one, and should specifically audit every Enterprise CA in their environment for the EDITF_ENABLECHASECLIENTDC setting, since a single misconfigured certificate authority can undermine the trust model of an otherwise well-secured domain.

Why This Matters Beyond One CVE

Certighost is a reminder that identity infrastructure often carries implicit trust assumptions that age poorly. AD CS was built in an era when the population of machines that could talk to a CA was small and largely trusted; two decades later, in sprawling enterprise domains with self-service machine account creation, those same assumptions become an escalation path. Teams should treat certificate services with the same scrutiny normally reserved for domain controllers themselves, since, as Certighost shows, the two are sometimes only a forged identity apart.

Share: Twitter  |  Facebook  |  LinkedIn
Join the discussion

This is a blog in the Fediverse: you can find this article everywhere with @blog@securebulletin.com and every comment/answer will appear here.

If you want to comment on Certighost Flaw Let Ordinary Users Impersonate Domain Controllers and Seize Active Directory, use the discussion on Forum.

>> forum community

Comments

Leave a Reply