Certighost: how one domain account turns AD CS into a Domain Controller (CVE-2026-54121)

Microsoft's July 2026 Patch Tuesday quietly fixed one of the nastier Active Directory bugs in recent memory: CVE-2026-54121, nicknamed Certighost. With nothing more than an ordinary domain account -- no admin rights, no phishing, no user interaction -- an attacker can make your Certificate Authority hand them a certificate that is a Domain Controller, then walk that into full domain compromise.

What Certighost actually is

Certighost is an improper-authorization flaw in Active Directory Certificate Services (AD CS) -- specifically in the Certificate Authority's own enrollment code, not in how you configured your templates. That distinction matters. The well-known AD CS attacks (the ESC1-ESC16 family from SpecterOps' "Certified Pre-Owned" research) are misconfigurations -- someone left a template too open. This one is a bug in Microsoft's code that hits default deployments.

The root cause is a directory-lookup fallback the CA code calls a chase. When issuing a certificate, the CA honoured two attributes supplied by the requester: cdc (the host the CA should contact to resolve directory data) and rmd (the principal to look up). The vulnerable CA dutifully connected to the attacker-named cdc host over SMB and LDAP and trusted the identity it got back -- the object's SID and dNSHostName -- without ever checking that the host was a real Domain Controller. Point cdc at a rogue service you control, name a real DC in rmd, and the CA signs a certificate carrying that DC's identity. It is the logical successor to 2022's Certifried (CVE-2022-26923), which abused a machine's own dNSHostName; here the DC identity is smuggled in through the chase lookup instead.

The exploitation chain

The published proof-of-concept (certighost.py, from the researchers who disclosed the bug) runs the whole path in one shot. It needs one standard domain user's credentials and network reach to the CA. Here is what happens end to end, and where a defender can break it:

1. Create a machine account. The default ms-DS-MachineAccountQuota of 10 lets any user add a computer account -- the identity the exploit rides in on.
2. Stand up rogue LDAP/LSA services. These impersonate the target DC to answer the CA's chase.
3. Submit a crafted enrollment. Against the default Machine template, with cdc pointed at the rogue host and the victim DC named in rmd.
4. The CA issues a DC-identity certificate. It trusts the forged SID and dNSHostName -- this is the flaw, and the step the patch blocks.
5. PKINIT. The attacker uses the certificate to get a Kerberos ticket as the Domain Controller.
6. DCSync. With the DC's replication rights, they pull krbtgt and other secrets -- Golden Ticket and total domain takeover.

How bad is it, really?

Read the three risk signals separately, because they disagree and that is the interesting part. Impact (CVSS) is high: 8.8 (AV:N/AC:L/PR:L/UI:N) -- network-reachable, low complexity, low privilege, no interaction, with high confidentiality/integrity/availability loss. Near-term probability (EPSS) is low: roughly 0.8-1.1%. And observed in-the-wild exploitation (CISA KEV) is: none -- it was not in the KEV catalog as of 2026-07-27.

Disclosure timeline

Am I affected?

You are exposed if you run an AD CS Enterprise issuing CA. If you have no CA, this specific bug does not apply -- but double-check that no forgotten CA role is sitting on a member server. The reported affected surface and the preconditions the exploit relies on:

Detecting it

First, turn on logging -- AD CS and DC auditing are off by default, so most environments are blind to this. On each issuing CA, enable full CA auditing (certutil -setreg CA\AuditFilter 127, then restart CertSvc); on Domain Controllers, enable Audit Directory Service Access for the DCSync signal. Then deploy detections at the three chokepoints in the chain. These Sigma rules are authored by us from documented Windows event semantics -- treat them as experimental starting points and tune the allow-lists to your environment. There is no public Sigma or Nuclei rule for this CVE yet, and Nuclei does not apply to an internal post-auth attack.

title: AD CS - DC/Machine Identity Certificate Issued to Unexpected Requester (Certighost)
status: experimental
logsource:
  product: windows
  service: security
detection:
  issued:
    EventID: 4887
  selection_dc_identity:
    - SubjectAltName|contains: '$'
    - Subject|contains: 'CN=DC'
  filter_expected:
    RequesterName|endswith: '$'   # legitimate machine auto-enroll
  condition: issued and selection_dc_identity and not filter_expected
fields: [RequesterName, Subject, SubjectAltName, RequestId, Attributes]
level: high
# Tuning: alert when the Requester is a USER, or a computer account created in the
# last N hours (join to a recent 4741). Inspect request Attributes for cdc/rmd.

title: Kerberos PKINIT TGT for DC Account After AD CS Issuance (Certighost)
status: experimental
logsource:
  product: windows
  service: security
detection:
  pkinit:
    EventID: 4768
    PreAuthType: 16
  dc_target:
    TargetUserName|endswith: '$'
  condition: pkinit and dc_target
fields: [TargetUserName, IpAddress, CertIssuerName, CertSerialNumber]
level: high
# Key off PreAuthType=16 + identity anomaly, not ticket flags. Correlate to a
# preceding suspicious 4887 within ~10 min; enrich with 4624/4672.

title: DCSync from Non-DC Account (post-Certighost domain takeover)
status: experimental
logsource:
  product: windows
  service: security
detection:
  access:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes-All
  filter_legit_dcs:
    SubjectUserName|endswith: '$'   # then ALLOW-LIST only your real DC accounts
  condition: access and not filter_legit_dcs
fields: [SubjectUserName, SubjectDomainName, ObjectName, Properties]
level: critical
# Tune with an explicit allow-list of your DC computer accounts, not any '$'.
# Also flag a DC$ name originating from an unexpected source IP.

Fixing it

1. Patch every issuing CA and Domain Controller with the July 2026 (2026-07-14) or later cumulative update. This is the only complete fix -- it adds a server-side check that the chase target is a genuine DC (verifying the SERVER_TRUST_ACCOUNT flag and matching the SID) before trusting it. Pull the exact KB for your build from the MSRC advisory.
2. If you cannot patch immediately, the researchers describe a temporary CA workaround that disables the chase fallback (certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC, then restart CertSvc). It was lab-tested only and can break legitimate enrollment -- a stopgap, never a substitute for the patch.
3. Turn on CA + DC audit logging (above) and deploy the detections before you consider this closed.

Hardening beyond the patch

The patch closes this specific hole, but the AD defaults that made it a one-click domain takeover are still there -- and they enable the next AD CS bug too. Fix the class:

• Set the domain ms-DS-MachineAccountQuota to 0 so standard users cannot create the machine account the exploit rides in on.
• Scope template enrollment: find every template granting Enroll/AutoEnroll to Authenticated Users or Domain Users, restrict it to a defined group, and require CA-manager approval on sensitive templates.
• Disable AD CS web-enrollment / interfaces you do not use, and enforce EPA / RPC signing to blunt relay.
• Enforce strong certificate mapping (per Microsoft KB5014754, StrongCertificateBindingEnforcement = 2) so a certificate cannot silently impersonate an account -- after remediating weak mappings.
• Remember certificates are long-lived credentials: if you suspect abuse, revoke and reissue -- a forged cert survives password and krbtgt resets.

Sources

• Microsoft MSRC advisory - CVE-2026-54121
• H0j3n - Certighost technical write-up (GitHub gist)
• The Hacker News - New exploit lets low-privileged users impersonate a Domain Controller
• Dataminr - Certighost (CVE-2026-54121) intel brief
• it-connect - Certighost: a standard AD account is enough to impersonate a DC
• Field Effect - Public exploit enables Domain Controller impersonation
• SentinelOne - CVE-2026-54121 vulnerability record
• Palo Alto Unit 42 - Active Directory Certificate Services exploitation