Certighost the vulnerability of AD CS that could convert a domain user into the Domain Controller

On July 24, a concept test was published that explores a vulnerability in Active Directory Certificate Services (AD CS) - baptized by its discoverers as Certighost- which allows a domain user with few privileges to obtain a certificate identifying a Domain Controller and authenticating itself as that machine. Gravity is not symbolic: by authenticating as a DC the doors are opened to request account secrets through DCSync, including krbtgt, which can lead to a total control of the domain through forged tickets and long-term persistence.

Microsoft described the problem as an authorisation failure and assigned it as CVE-2026-54121 with a CVSS score of 8.8; the patch for AD CS was published on July 14. Unlike many vulnerabilities that require high privileges or user interaction, this vector requires only network access and a standard domain account. In the public tests the researchers used an account of the Domain Users group and relied on default behaviors such as the mms-DS-MachineAccountQuota (10) quota to create or reuse equipment accounts.

The technical core lies in the "chose" logic of the AD CS encoding: when an CA cannot solve the subject's information, the protocol allows the request to indicate a cdc (the Active Directory server to contact) and rmd (the machine object to solve). The attackers can deceive the CA to communicate with false SMB / LDAP services, relay authentication to the real DC via Netlogon and return attributes such as objectSid and dNSHostName of the target, thus validating identity and causing the CA to sign a DC identity certificate. The concept test automates this channeling, lifts up listening in ports 445 / 389 and produces a PFX and a PKINIT Kerberos credentials cache capable of authenticating itself as the Domain Controller.

The existence of a public PoC makes the risk imminent: even if no holdings in nature have been verified to date according to primary reports, the availability of the explosion means that response teams can see active attacks quickly. In addition, the vector exploits very common configurations: Enterprise CA, default Machine template and CA accessibility to the attacker's SMB / LDAP services.

Microsoft corrected the failure by adding validations before following a chuse; the update introduces verifications that reject IP literal, too long names and LDAP metacaracterms, requires exactly a computer object whose name DNS matches and which has the SERVER _ TRUST _ ACCOINT flag, and makes SID comparisons to avoid object replacements. This verification is included in the CA binary and is the correct and definitive mitigation, so organisations with Enterprise CA should install Microsoft patches in AD CS hosts immediately. For general reference on AD CS and its architecture see the official Microsoft documentation at https: / / learn.microsoft.com / en-us / windows-server / identity / ad-cs / ad-cs-overview.

When applying patches is not immediately possible, the authors documented a temporary mitigation that disables the chute flag in CA policy: run certutile to modify EditFlags and restart the CertSvc service. This change can interrupt legitimate enrollment flows, so researchers and Microsoft recommend testing it in a controlled environment before deploying it in production. The certutile utility and its parameters are documented by Microsoft in https: / / learn.microsoft.com / en-us / windows-server / administration / windows-commands / certutil.

In terms of detection and response, there are specific actions that need to be prioritized: to audit the recent creation of equipment accounts and changes in the ms-DS-MachineAccountQuota, to review the CA records for binding requests using cdc / rmd attributes, to monitor unusual PKINIT activity and DCSync operations or abnormal LDAP requests. If there is evidence of commitment, the response should include krbtgt rotation (ideally twice for security) and forensic investigation of access to the CA and the affected DC.

In addition to patching and monitoring, it is appropriate to take hardening measures: to restrict which hosts can communicate with CA in SMB / LDAP ports, to limit registration rights in certificate templates, to review delegations to create equipment accounts and to segment CA so that they are not directly accessible from low-privileged workstations. The in-depth defense reduces the likelihood that a user with minimum permissions can reach the full operating chain.

The community should follow developments in technical reference sources; the official vulnerability register in the national vulnerability database can be consulted at https: / / nvd.nist.gov / vuln / detail / CVE-2026-54121. It is also important to remain alert to additional updates and guides from Microsoft or CERT to provide specific commitment indicators and mediation procedures.

For IT and safety equipment the recommendation is clear: prioritize patch installation on all AD CS servers, carefully test any temporary mitigation such as chute deactivation, and run an anomaly hunt focused on unusual machine certificates, creation of equipment accounts and DCSync use signals. The combination of patch, monitoring and hardening of CA significantly reduces the risk that a vulnerability such as Certighost will result in a full domain commitment.