Researchers H0j3n and Aniq Fakhrul published a working exploit on July 24 that lets a low-privileged Active Directory user obtain a certificate for a Domain Controller and authenticate as that machine.
They codenamed the flaw Certighost. Because Domain Controller accounts carry directory replication rights, the resulting Kerberos credential can retrieve the krbtgt
secret through DCSync
.
Microsoft patched the Active Directory Certificate Services (AD CS) issue ten days earlier as CVE-2026-54121
. Microsoft classed the flaw as improper authorization and assigned it a CVSS score of 8.8.
Exploitation requires network access and a domain account, but no administrator rights or user interaction. In the researchers' test, a normal Domain Users
account could create a computer account under the default ms-DS-MachineAccountQuota
value of 10
or reuse one it already controlled.
The chain also required an Enterprise CA that followed the vulnerable chain path, enrollment through the default Machine template, and network reachability from the CA to the attacker's SMB and LDAP listeners.
Organizations running an Enterprise CA should install Microsoft's July 14 updates on AD CS hosts. As of July 24, no primary source reviewed by The Hacker News reported exploitation in the wild, but the full proof-of-concept was public. That absence of reporting does not prove that exploitation has not occurred.
The researchers also documented a lab-tested way to disable the chase fallback when immediate patching is not possible, although it can break legitimate enrollment flows.
The bug sits in an AD CS enrollment fallback known as a chase. When a certification authority (CA) cannot obtain an end entity's information, the Windows enrollment protocol lets a request provide cdc
, the Active Directory server to contact, and rmd
, the machine object to resolve.
The researchers found that the CA followed the requester-supplied cdc
host over Server Message Block (SMB) and Lightweight Directory Access Protocol (LDAP) without first proving it was a real Domain Controller.
An attacker could run rogue Local Security Authority (LSA) and LDAP services, relay the CA's authentication challenge to the real Domain Controller over Netlogon
, and return the target Domain Controller's objectSid
and dNSHostName
. A controlled machine account supplied the valid domain identity needed for the CA to continue. The CA authenticated that account, then signed the target Domain Controller's identity into the certificate.
The public exploit automates the chain. It creates a computer account or reuses one specified with --computer-name
. The tool starts listeners on ports 445
and 389
and relays the CA's challenge to the real Domain Controller over Netlogon
. It then submits the cdc
and rmd
attributes and writes a PFX
file and Kerberos credential cache.
The exploit uses Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) to authenticate as the target Domain Controller. The resulting credential can request account secrets through DCSync
, including krbtgt
.
The researchers' binary analysis found that Microsoft's July update adds CRequestInstance::_ValidateChaseTargetIsDC
to certpdef.dll
before the CA follows a chase. The validation rejects IP literals, overlong names, and LDAP metacharacters. It also requires exactly one matching Active Directory computer object whose DNS name matches the target and whose userAccountControl
includes SERVER_TRUST_ACCOUNT
(8192
). A later SID
comparison blocks object substitution.
The public exploit was tested in a Windows Server 2016-or-later forest with an Enterprise CA, the default Machine certificate template, and the default machine-account quota. The NVD record separately lists Windows Server 2012 through Windows Server 2025, including listed Server Core editions, as affected. It also lists Windows 10 versions 1607 and 1809. The flaw was absent from CISA's Known Exploited Vulnerabilities catalog on July 24.
The researchers reported the flaw to Microsoft on May 14. Microsoft confirmed it on May 22 and patched it on July 14. The researchers publicly disclosed it on July 24. Administrators who cannot patch immediately can clear the chase flag and restart Certificate Services:
certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force
The researchers tested that mitigation only in a controlled lab. They recommend staging it first and treating the July update as the permanent fix.
Facts Only
* Researchers H0j3n and Aniq Fakhrul published an exploit on July 24.
* The flaw allows a low-privileged Active Directory user to obtain a certificate for a Domain Controller and authenticate as that machine.
* The vulnerability is codenamed Certighost.
* Domain Controller accounts possess directory replication rights, enabling retrieval of the krbtgt secret via DCSync.
* Microsoft patched the AD CS issue as CVE-2026-54121 on July 14.
* The flaw was classified as improper authorization with a CVSS score of 8.8.
* Exploitation requires network access and a domain account, but not administrator rights or user interaction.
* A normal Domain Users account could create a computer account under the default ms-DS-MachineAccountQuota value of 10 or reuse an existing one.
* The exploitation chain required an Enterprise CA following a vulnerable path, enrollment via the default Machine template, and network reachability to SMB/LDAP listeners.
* The exploit automates by creating a computer account or reusing one specified with --computer-name.
* The exploit uses PKINIT for initial Kerberos authentication to impersonate the target Domain Controller.
* Binary analysis indicated Microsoft's July update added CRequestInstance::ValidateChaseTargetIsDC to certpdef.dll, which validates targets against specific criteria, blocking IP literals and requiring a matching AD computer object with SERVERTRUSTACCOUNT (8192).
Executive Summary
Full Take
The core dynamic revealed here is the systemic risk introduced by trusting network protocols (SMB/LDAP) for critical identity validation within enterprise certificate infrastructure. The vulnerability exploits an architectural fallback—the 'chase' mechanism—where an implicit trust relationship is established based on the requester’s input, rather than rigorous, verifiable identity proof of the requested host. This design flaw moves from a localized error in protocol handling to a potential credential compromise that directly impacts the trust hierarchy of Kerberos and Active Directory through DCSync access to critical secrets.
The importance lies not just in the technical mechanism but in the failure to enforce least privilege at the infrastructure level, even for system processes like certificate enrollment. The fact that the exploit relies on relaying authentication challenges via LSA/LDAP interaction suggests a deeper structural weakness where network reachability is mistakenly conflated with authenticated identity, allowing an attacker controlling one entity to leverage the trust relationship of another within the domain structure.
The observation that mitigating controls, such as disabling the chase fallback, can break legitimate enrollment flows highlights a tension between security posture and operational continuity. This forces an organizational calculus: do they accept the risk of potential compromise from zero-day exploitation, or do they implement controls that introduce potential instability? The necessity of subsequent patches underscores the pattern where defensive measures are often reactive rather than preventative until the architectural assumption itself is revised to mandate explicit, cryptographically verified identity for every entity participating in an enrollment chain.
Bridge Questions: If trust must be explicitly proven at every step, what alternative mechanisms should replace reliance on implicit network presence for AD object resolution during certificate operations? How can organizations architect enterprise systems where disabling a known exploit mitigation introduces less risk than maintaining the exploited state under specific operational constraints? What is the long-term cost of managing an environment where operational flexibility inherently clashes with cryptographic integrity?
