SURIQ
Active Directory Certificate Services was supposed to be the part of the domain you did not have to think about. Certificates get issued, machines authenticate, and the certification authority sits quietly in a corner. Certighost, disclosed publicly on July 24 by researchers H0j3n and Aniq Fakhrul as CVE-2026-54121, takes that quiet corner and turns it into the fastest path from a standard user account to total forest compromise. No admin rights. No phishing. No malware. Just a certificate request the CA trusts more than it should.
The mechanics are worth understanding, because the defensive lessons do not stop at "install the patch." AD CS carries an enrollment fallback the researchers call a "chase." When the CA cannot resolve the requester's identity locally, the enrollment protocol lets the request name which domain controller to ask (the cdc attribute) and which principal to resolve (rmd). The flaw is that the CA would reach out to that attacker-named host over SMB and LDAP and take its answers at face value, never confirming the host was actually a domain controller. Point cdc at a machine you control, answer the CA's lookups with a domain controller's SID and DNS name, and the CA signs that identity into a certificate it hands back to you.
From there the chain is textbook. The attacker uses the certificate for PKINIT authentication, receives a Kerberos ticket as the target domain controller, and, because DC accounts hold directory replication rights, runs DCSync to pull the krbtgt secret. Once you hold krbtgt, you can forge golden tickets for any principal in the domain, indefinitely. Microsoft rated it CVSS 8.8 and shipped the fix in the same July 14 update; the public proof of concept followed ten days later.
The bug is patched. The blind spot is not.
Here is the part no advisory says out loud: Certighost did not create a new weakness so much as weaponize one most organizations were already living with. Certificate enrollment is telemetry almost nobody watches. Domain controller logons get scrutiny, privileged group changes get scrutiny, but a certificate request is treated as plumbing. That is why this class of AD CS abuse, from the ESC families onward, keeps landing: the CA is a trusted issuer of identity that operates outside the visibility most teams build around their DCs. The patch closes one door. The room it opens into stays dark unless you put a light in it.
That reframes the response. Patching CVE-2026-54121 on every enterprise CA is step one and it is not optional. But treat it as the start of a project, not the whole of it, because two things the July update does not solve will still be true next week.
Machine account quota is the precondition you control
The exploit needs a domain principal it controls to host the rogue LDAP and LSA services that feed the CA. It gets one by creating a machine account, which any authenticated user can do up to the ms-DS-MachineAccountQuota default of 10. That default is the enabling condition for a long list of AD attacks, and it is a lever you own independent of any vendor. Setting ms-DS-MachineAccountQuota to 0 and delegating machine-join to a specific service account removes the attacker's ability to stand up that rogue principal in the first place. It is not a substitute for the patch, and a sufficiently privileged foothold can work around it, but on a fleet where you cannot patch every CA in an afternoon it raises the floor everywhere at once.
Watch the CA, not just the DC
The instinct after a domain-controller-impersonation bug is to add detection on the domain controllers. For Certighost, the sharpest signal is one hop upstream, on the CA itself. The whole trick depends on the certification authority reaching out over SMB and LDAP to a host the attacker named. A CA legitimately talks to a small, known set of domain controllers and almost nothing else. So a CA initiating an outbound SMB or LDAP connection to an arbitrary, non-DC host is close to always anomalous, and it is a signal you can build without deep Windows internals. Pair it with three more:
- Machine account creation by ordinary user accounts, especially clustered in time or preceding a certificate request.
- Certificate issuance from the default Machine template where the subject identity does not match the requesting account.
- Replication requests (directory
DS-Replication-Get-Changes) originating from a host that is not a known domain controller, the on-DC tail of a successful DCSync.
None of these requires the exploit itself to be understood. They describe the shape of the attack, which is what survives when the next variant lands.
One patched CA is not "done"
The last trap is treating this as a single-host fix. Forests routinely run more than one enterprise CA, and the attack works against any that follows the vulnerable chase path, so partial coverage is no coverage. The pre-patch workaround, disabling the chase with certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC and restarting CertSvc, carries its own tail risk: on an unpatched CA that setting can be flipped back on by group policy or a well-meaning administrator, silently restoring exploitability. That makes CA certificate configuration a thing worth watching for drift, not a checkbox you tick once. If you run Windows domains under managed detection, the useful questions this week are whether every enterprise CA carries the July update, whether machine account quota is still sitting at 10, and whether anything is watching the CA's own outbound connections. Certighost is patched. The habits that made it easy are not.