Researchers released a proof-of-concept (PoC) exploit for a now-patched flaw in Microsoft’s Active Directory Certificate Services (AD CS) that can allow a low-privileged domain user to impersonate a domain controller and fully compromise an AD environment. The flaw was present due to a defective trust boundary within the certificate-based client authentication aspect of Microsoft AD Services.
In its July raft of a record 622 Patch Tuesday updates, Microsoft patched a flaw tracked as CVE-2026-54121, which the researchers who discovered and exploited it — Aniq Fakhrul (@aniqfakhrul) and Muhammad Ali (@h0j3n) — called “Certighost,” according to a post by the researchers on GitHub.
As the researchers described, the vulnerability affects the enterprise certificate authority’s (CA) handling of an AD CS enrollment fallback mechanism known as a “chase,” which is a second directory lookup performed in some cross-domain controller enrollment scenarios.
Because of the flaw, Fakhrul and Ali found that during the issuance of certificates — which bind a subject to a public key — the CA could be tricked into querying an attacker-controlled host for AD identity information by manipulating the cdc (Client DC) and rmd (Remote Domain) request attributes, they explained.
“The vulnerable path is an AD CS enrollment fallback known as a chase during directory-object resolution,” the researchers wrote in the post. “By supplying request attributes such as cdc, an attacker could cause the Certificate Authority [CA] to ask an attacker-controlled host for identity data belonging to a Domain Controller. The CA then used that data while issuing a certificate.”
This resulted in the CA accepting the requester-supplied chase target without first proving that it was the domain controller it claimed to be. “That made it possible for an attacker to run LDAP and LSA services on a host they controlled, direct the CA to that host, and return directory data for a chosen target principal,” they wrote.
Certighost Abuses a Trust Boundary
The vulnerability stemmed from a broken trust boundary within the AD CS certificate enrollment process, which the researchers abused in their PoC attack.
“Active Directory treats its own directory as the source of truth about who is who, and the certificate service will vouch for whatever the directory says,” Jason Soroko, senior fellow at certificate authority giant Sectigo, explains to Dark Reading. “So anyone who can add an entry to the directory can shape what a certificate claims.”
Unfortunately, it’s a risk scenario that often is repeated in other standard protocols for such exchanges, he says. “A low-trust party hands a high-trust component a pointer, and the component follows it without asking whether the target is who the pointer claims,” Soroko says. “Directory referrals, DNS delegation, and OAuth redirects have all produced the same shape of bug.”
Active Directory Certificate Services act as Microsoft’s public key infrastructure (PKI) implementation that integrates with Active Directory and issues X.509 certificates for purposes such as encryption, signing, secure communications, and authentication, the researchers explained.
While the private key stays with the requester, the certificate contains the public key and identity information signed by a CA. Certificates are often used to sign Web domains to validate HTTPS connections as well as the domains’ ownership information.
“Certificate templates control the enrollment process,” the researchers wrote. “A template decides who may request a certificate, what it can be used for, what identity information must be present, and whether the CA may accept information supplied in the request.”
The flaw and PoC involve certificate-based client authentication, in which a client requests a certificate from an enterprise CA and later presents it to the Key Distribution Center (KDC) to obtain Kerberos credentials, they said.
How the Certighost Exploit Works
The researchers exploited the flaw in a standard enterprise lab environment featuring an Enterprise CA, Windows Server Active Directory, the default machine certificate template, and a low-privilege domain user account. The PoC itself is a self-contained Python script that requires tools such as Impacket, pyasn1, asn1crypto, and dnspython, the researchers said.
The attack chain starts with the script connecting through LDAP (Lightweight Directory Access Protocol) with the supplied low-privileged account and discovering the CA, DC, domain SID, and domain GUID. It then creates a machine account through ms-DS-MachineAccountQuota and registers the required service principal names.
The next step in the attack is to start local LSA and LDAP services, which relay the CA’s authentication challenge to the real domain controller so the chase endpoint is accepted as a valid domain principal, the researchers explained. The script then submits a certificate request containing the cdc and rmd attributes.
Once it receives a certificate carrying identity material for the target DC, including SID and DNS-name data used by the authentication flow, the script then uses the certificate to authenticate as the target domain controller and write the resulting credential cache, they said.
Patching and Mitigation
The researchers reported the flaw to the Microsoft Security Response Center on May 14, and by May 22 the company had investigated and confirmed the vulnerability. The patch was issued in the July Patch Tuesday updates earlier this month, and Microsoft acknowledged and thanked the researchers for their responsible disclosure in a report on the flaw.
The company did not immediately respond to Dark Reading’s request for comment today.
The update changes two things, according to the researchers. One is the target authenticity, ensuring that the chase target must be an AD-registered domain controller, not an arbitrary requester-controlled host. The other is the object authenticity, ensuring that the object resolved through the chase must match the expected identity, preventing substitution even if the lookup path is unusual.
While the fix is valid for this particular flaw, it’s just “the latest in a run of similar fixes” that leaves the basic trust system intact, which may not be a long-term solution, Soroko observes. Instead, security teams should begin in earnest to consider certificate enrollment as a “security boundary rather than plumbing,” even as they continue to move toward post-quantum encryption schemes, he adds.
“The trust in a certificate has always lived in the vetting behind it,” Soroko says.
And while the best way to mitigate the flaw is to apply the patch, there is a temporary workaround for organizations unable to deploy the update immediately. System administrators can disable the vulnerable chase behavior by clearing the EDITF_ENABLECHASECLIENTDC policy flag, the researchers noted. However, this mitigation should not be treated as an absolute fix, the researchers added, and should be tested before deployment, as it may affect legitimate certificate enrollment workflows.
