A newly disclosed Active Directory Certificate Services vulnerability shows how a relatively ordinary domain account could potentially be transformed into one of the most powerful identities inside a Windows network.
Security researchers H0j3n and Aniq Fakhrul published a working proof of concept for the flaw, which they named Certighost, on July 24. The attack could allow a low-privileged Active Directory user to obtain a certificate representing a Domain Controller and then authenticate to the domain as that machine.
Microsoft had patched the underlying issue ten days earlier as CVE-2026-54121, classifying it as an improper-authorisation vulnerability with a CVSS score of 8.8.
The weakness is particularly serious because a Domain Controller certificate is not merely another credential. Once an attacker can authenticate as a Domain Controller, they may be able to abuse directory-replication privileges and retrieve highly sensitive account secrets.
Why Impersonating a Domain Controller Is So Dangerous
Domain Controllers sit at the centre of an Active Directory environment.
They authenticate users, apply security policies, store directory information and replicate account data between servers. Their machine accounts therefore receive privileges that ordinary workstations and users do not have.
Certighost allows an attacker to obtain a certificate containing the identity of a legitimate Domain Controller.
The attacker can then use Public Key Cryptography for Initial Authentication in Kerberos, commonly known as PKINIT, to request a Kerberos credential as that server.
With the resulting identity, the attacker may be able to perform a DCSync operation.
DCSync is a legitimate replication function used by Domain Controllers to exchange directory information. When abused by an attacker, it can retrieve password-related data and other secrets from Active Directory.
The most sensitive target is often the krbtgt account, which is used by the Kerberos authentication system.
Access to the krbtgt secret can allow an attacker to create forged Kerberos tickets and maintain broad, long-term control over the domain.
No Administrator Rights Are Required
One of the most concerning aspects of the vulnerability is the low level of access needed to begin the attack.
The researchers demonstrated the chain using a standard Domain Users account. The attacker did not require Domain Administrator permissions and did not need to convince another user to click a link or approve a prompt.
Exploitation still requires several conditions:
In many Active Directory environments, ordinary users can create computer accounts because the default value of ms-DS-MachineAccountQuota allows each authenticated user to add up to ten machines to the domain.
The researchers used this capability to create a controlled computer object or reuse one already under the attacker's control.
This computer account provided the valid domain identity needed to keep the certificate-enrolment process moving.
The Weakness Was Hidden Inside an AD CS Fallback Process
The flaw exists in an Active Directory Certificate Services enrolment fallback mechanism known as a chase.
During certificate enrolment, a Certification Authority may need to retrieve information about the user or computer requesting the certificate.
When the CA cannot obtain the required identity information directly, the enrolment protocol can allow the request to specify:
cdc — the Active Directory server the CA should contact rmd — the machine object the CA should resolveThe researchers found that the CA trusted the requester-supplied chase destination without first proving that the supplied host was a genuine Domain Controller.
This created an opportunity for an attacker to redirect the CA toward services under their control.
Instead of communicating only with a legitimate Domain Controller, the CA could be persuaded to connect to rogue SMB and LDAP listeners operated by the attacker.
How the Certificate Identity Became Substituted
The attack chain combined several legitimate Windows authentication mechanisms in an unintended way.
The attacker presented a controlled computer account to satisfy the domain-authentication portion of the enrolment flow.
At the same time, the rogue services relayed the CA's authentication challenge to the real Domain Controller through Netlogon.
The malicious LDAP service then returned directory attributes associated with the target Domain Controller, including its:
objectSid dNSHostNameThe CA authenticated the attacker-controlled computer account but accepted identity information belonging to the real Domain Controller.
As a result, the issued certificate contained the Domain Controller's identity rather than the identity of the machine account the attacker actually controlled.
That certificate could then be used for Kerberos authentication.
The problem was therefore not that the attacker could simply request any certificate they wanted. It was that the CA failed to verify properly that the chase destination and returned directory object genuinely matched a trusted Domain Controller.
The Public Exploit Automates Most of the Chain
The proof-of-concept tool released by the researchers automates the major stages of the attack.
It can create a computer account or reuse one already controlled by the operator. It then starts the required SMB and LDAP listeners, interacts with the Certification Authority and relays authentication toward the legitimate Domain Controller.
After successful exploitation, the tool can produce:
The release of a working exploit significantly increases the urgency of patching.
Even when no confirmed real-world exploitation has been publicly reported, a complete proof of concept lowers the technical barrier for other attackers to study, modify and deploy the technique.
As of July 24, the source reporting reviewed for the disclosure had not identified confirmed exploitation in the wild. That should not be interpreted as evidence that no attacks occurred.
Many certificate-abuse incidents are difficult to detect, and public confirmation frequently arrives after an initial disclosure.
Microsoft Patched the Issue on July 14
Microsoft released the security update for CVE-2026-54121 on July 14, following the researchers' responsible disclosure.
The flaw was initially reported to Microsoft on May 14. Microsoft confirmed the issue on May 22 before delivering the final update in July.
The researchers published their full technical analysis and exploit ten days after the patch became available.
Organisations operating an Enterprise Certification Authority should prioritise the July security updates on all affected AD CS servers.
Patching the Domain Controllers alone is not sufficient. The vulnerable behaviour occurs within the Certification Authority's certificate-enrolment processing, so the AD CS hosts must receive the update.
How Microsoft Strengthened the Chase Validation
Binary analysis performed by the researchers found that Microsoft added a new validation routine to certpdef.dll.
The new function, identified as CRequestInstance::_ValidateChaseTargetIsDC, runs before the Certification Authority follows a requester-supplied chase target.
The updated logic performs several checks.
It rejects:
The CA now requires exactly one matching Active Directory computer object.
The object's DNS name must correspond to the supplied chase target, and its userAccountControl value must include SERVER_TRUST_ACCOUNT, represented by the value 8192.
That flag is normally associated with Domain Controller computer accounts.
Microsoft also added a later Security Identifier comparison, helping prevent an attacker from substituting one directory object for another after the initial validation.
Together, these checks ensure that the CA confirms the target is a genuine Domain Controller before trusting the returned identity information.
Which Windows Systems Are Affected
The researchers tested the public exploit in an Active Directory forest running Windows Server 2016 or later with:
The National Vulnerability Database separately listed affected Windows Server versions ranging from Windows Server 2012 through Windows Server 2025, including specified Server Core installations.
It also listed certain Windows 10 versions, including 1607 and 1809.
Administrators should rely on Microsoft's official security-update guidance to determine the exact products and components requiring patches in their own environment.
The flaw was not listed in CISA's Known Exploited Vulnerabilities catalogue on July 24, but catalogue status can change and does not measure whether an exploit is technically practical.
Temporary Mitigation Is Available but Carries Risk
For organisations unable to apply the July updates immediately, the researchers documented a way to disable the chase functionality used by the attack.
The mitigation clears the relevant Certificate Services policy flag and restarts the Certification Authority service:
Restart-Service CertSvc -Force
This workaround was tested only in a controlled laboratory.
Disabling chase behaviour may interrupt legitimate certificate-enrolment workflows that depend on the fallback process. Organisations should therefore test the change in a staging environment and confirm how it affects existing enrolment scenarios before applying it broadly.
The mitigation should be treated as a temporary risk-reduction measure, not a replacement for Microsoft's security update.
Machine Account Creation Should Be Reviewed
Certighost also highlights the security implications of leaving the default machine-account quota unchanged.
Many organisations do not expect ordinary users to create computer accounts, yet the default configuration may permit them to add up to ten.
Reducing ms-DS-MachineAccountQuota to zero can limit one path used by low-privileged attackers.
However, changing the quota must be planned carefully.
Some legitimate processes may depend on users or automated systems joining workstations to the domain. Organisations should identify those workflows and delegate machine-account creation only to approved administrators, deployment systems or service accounts.
The quota change would not fix the AD CS vulnerability itself, but it can remove one of the convenient prerequisites used in the published attack chain.
Network Segmentation Can Limit Exploitation
The exploit requires the Certification Authority to reach attacker-controlled SMB and LDAP listeners.
That requirement provides another defensive opportunity.
Enterprise CAs should not have unrestricted network access to every workstation or user-controlled device.
Firewall rules can limit outbound connections from Certification Authorities to approved Domain Controllers and required infrastructure.
In particular, organisations should review whether AD CS servers genuinely need to initiate SMB and LDAP connections to arbitrary systems.
Restricting those paths reduces the attacker's ability to make the CA communicate with rogue services.
Certificate Authorities are highly sensitive systems and should be placed in protected network segments with tightly controlled administrative and communication paths.
Certificate-Enrolment Activity Should Be Monitored
Security teams should review certificate logs and Active Directory changes for behaviour associated with this attack.
Useful areas of investigation include:
A suspicious certificate request may not be enough on its own to confirm exploitation.
Investigators should correlate certificate events with computer-account creation, CA network activity, Kerberos authentication and directory-replication behaviour.
DCSync Monitoring Is Particularly Important
Because the end goal may include retrieving the krbtgt secret, organisations should monitor directory replication closely.
DCSync activity is legitimate when performed by Domain Controllers and certain authorised identity-management systems.
It becomes suspicious when replication permissions are exercised from unexpected devices or accounts.
Detection systems should alert when directory-replication operations originate from:
Security teams should also review whether any non-Domain Controller accounts have unnecessary replication permissions.
Reducing the number of identities capable of performing DCSync makes anomalous activity easier to identify.
AD CS Should Be Treated as Tier-Zero Infrastructure
Certificate Authorities are sometimes managed as ordinary application servers.
That is a dangerous assumption.
An Enterprise CA can issue credentials trusted throughout the domain. If compromised or misconfigured, it may allow attackers to impersonate users, computers, administrators or Domain Controllers.
AD CS servers should therefore receive protections comparable to Domain Controllers.
These protections include:
Administrators should also review previously documented AD CS abuse paths, including insecure templates and weak enrolment permissions.
Fixing Certighost does not automatically remove other certificate-related attack opportunities.
Why Certificate Abuse Can Be Hard to Detect
Traditional credential theft often involves passwords, hashes or authentication tokens.
Certificate-based attacks can be quieter.
A malicious certificate may remain valid for months or years and can sometimes be used without repeatedly triggering password-based controls.
Changing the user's password may not invalidate an already issued certificate.
This makes certificate inventory and revocation essential parts of incident response.
If Certighost exploitation is suspected, organisations should not limit their response to resetting the compromised domain account.
They may also need to:
Because krbtgt rotation can affect authentication throughout the domain, it should be planned and performed according to Microsoft guidance.
Final Thoughts
Certighost demonstrates how a low-privileged Active Directory account can become dangerous when combined with a flaw in certificate-enrolment trust.
The attacker does not begin with administrator access. Instead, the chain abuses a controlled computer account, a Certification Authority fallback mechanism and Windows authentication protocols to obtain a certificate representing a Domain Controller.
From there, the attack can move into Kerberos authentication and potentially DCSync, placing the domain's most sensitive secrets at risk.
Microsoft's July 14 update addresses the underlying validation failure and should be treated as the permanent fix.
Organisations should also use the disclosure as an opportunity to review broader Active Directory Certificate Services security: machine-account creation, certificate templates, CA network access, replication privileges and certificate-monitoring capabilities.
In Active Directory, certificates can be as powerful as passwords—sometimes more powerful. Protecting the systems that issue them must therefore be considered a core part of protecting the domain itself.
Comments