Document Type: Detection Use Case Related CVE: CVE-2026-54121 (Certighost) Author: Youssef Benchater

Detection Use Case: Certighost (CVE-2026-54121)

This document describes the Splunk detection built for CVE-2026-54121. It follows the standard detection use case format so it can sit in a detection catalog the same way a real detection engineering team would maintain it.

Table of Contents

Overview

• Detection ID / Name
• Purpose
• MITRE ATT&CK Mapping

Detection Build

• Required Log Sources
• Detection Logic
• Findings & Design Notes
• Trigger Conditions
• Severity

Response & Validation

• Response / Triage Steps
• Testing Evidence
• Associated Dashboards

Roadmap

• Planned Detection Chain
• Future Improvements

Metadata

• Owner
• Last Reviewed / Version
• References

Detection ID / Name

Alert : Certighost ( CVE-2026-54121 )

Purpose

Detects abuse of the AD CS certificate enrollment chase mechanism described in CVE-2026-54121. The rule flags certificate lifecycle events on the CA where the requester supplied chase target (the cdc attribute) does not resolve to the legitimate Domain Controller, which is the exact mechanism Certighost uses to make the CA issue a certificate containing Domain Controller identity data to a low privileged requester resulting to full domain compromise and take over.

The detection is anchored on the cdc chase target rather than machine account creation because Microsoft's advisory for CVE-2026-54121 lists the account precondition as either a default ms-DS-MachineAccountQuota value or an account the attacker already controls. A rule keyed on account creation would miss the second path entirely, and would also depend on account creation and exploitation happening within the same time window. The cdc check covers both paths and has no such dependency.

MITRE ATT&CK Mapping

This rule covers the certificate request and issuance stage of the attack chain.

Required Log Sources

• Index: wineventlog-lab
• Source Type: WinEventLog
• Logs Source: WinEventLog:Security
• Host: DC01
• Windows Event Codes queried directly by this rule's search:
  • 4886 (Certificate request received)
  • 4887 (Certificate issued)
  • 4888 (Certificate request denied)

Detection Logic

index=wineventlog-lab sourcetype=WinEventLog source="WinEventLog:Security"
  (EventCode=4886 OR EventCode=4887 OR EventCode=4888) cdc
  
| fields _time EventCode Request_ID Requester Attributes Subject host Message
| rex field=Message "(?m)^cdc:(?<chase_cdc>\S+)"
| where isnotnull(chase_cdc) AND lower(chase_cdc)!="dc01.atlasvec.lab"
| stats min(_time) as _time
        values(Requester)  as requester
        values(Attributes) as template
        values(chase_cdc)  as chase_target
        values(Subject)    as cert_subject
        values(EventCode)  as codes
        values(host)       as ca_host
  by Request_ID
  
| eval status   = case(mvfind(codes,"4887")>=0,"ISSUED",
                       mvfind(codes,"4888")>=0,"DENIED",
                       true(),"PENDING")

| eval severity = "critical"
| sort - _time
| rename ca_host as "CA Host", Request_ID as "Request ID",
         requester as "User Requester", template as "Certificate Template",
         chase_target as "Chase Target (cdc)", cert_subject as "Issued Subject",
         status as "Outcome", severity as "Severity",
         _time as "Timestamp"
| table "Timestamp" "CA Host" "Request ID" "User Requester" "Certificate Template" "Chase Target (cdc)" "Issued Subject" "Outcome" "Severity"

Findings & Design Notes

• Events are grouped by Request ID so the full lifecycle of one malicious request (received, then issued or denied) shows as a single row.

• The initial iteration of this detection included Event ID 4741 (computer account created) as a precondition, based on the public proof of concept demonstrating account creation as part of the attack chain. However, Microsoft's advisory for CVE-2026-54121 lists the machine account precondition as either a default ms-DS-MachineAccountQuota value or a machine account already controlled by the attacker.

  An attacker taking the second path uses a machine account they already control and generates no 4741 event. The rule was updated to anchor solely on the cdc chase target, covering both exploitation paths by design.

  This also removes any dependency on the account creation and the certificate abuse happening within the same time window. An attacker could create the machine account days before or after the exploitation attempt and the rule still fires.

Trigger Conditions

The base search scopes to AD CS Security auditing events on DC01 (4886, 4887, 4888) and pre-filters to events that contain the literal string "cdc", since only chase abuse attempts carry that attribute in the Message field.

For each matching event, the search extracts the chase destination from the cdc: line in the Message field. Events where that value is absent or matches the legitimate DC FQDN (dc01.atlasvec.lab) are excluded.

Events where the cdc value points to any other target are flagged, as that is the exact condition where the CA was instructed to chase outside of legitimate DC infrastructure, which is the core exploitation of this CVE.

Severity

Critical - fixed value set directly in the search logic. Not calculated on a scale, every match this rule produces is treated as critical because the condition it detects (CA following a requester-controlled chase to a non-DC target) is the exploitation primitive itself.

Response / Triage Steps

1. Confirm the requester account in the alert output. Check whether it is a standard domain user, a machine account, or a service account, and whether that account has any legitimate reason to be requesting a certificate at all.
2. Run the DC01 - Suspicious Accounts Activities correlation search against the same time window to check for related account or process activity on DC01 around the same timestamps.
3. Run the DCSync / replication rights check to determine whether the requester or any related account has performed or attempted DS-Replication-Get-Changes / DS-Replication-Get-Changes-All activity, which would indicate the attacker moved past cert issuance into credential extraction.
4. If Outcome is ISSUED, treat the issued certificate as compromised. It contains forged Domain Controller identity data and can be used to authenticate as the DC.
5. Escalate for containment: revoke the issued certificate, disable or reset the requester account, and confirm ms-DS-MachineAccountQuota and the certificate template ACLs, since both are preconditions for this attack.

Testing Evidence

Validated against real request lifecycle data captured in this lab on 2026-08-02:

The PoC run above confirms the full attack chain end to end, from rogue server setup through certificate request to credential extraction. The Splunk evidence below shows the same request lifecycle caught on the CA side.

• Request ID 11 (requester ATLASVEC\Administrator) shows chase target DC01.atlasvec.lab, the legitimate DC, and correctly did not trigger the rule.

Full test methodology, preconditions checked, and additional screenshots are recorded separately in Document 2: Detection Validation Report.

Associated Dashboards

A companion monitoring dashboard was built alongside this detection. It covers the Certighost attack chain across two views: a DC Monitoring tab tracking AD CS certificate events, DCSync indicators, and machine account activity, and a SOC overview tab surfacing all fired alerts by severity.

Pre-Attack Baseline

DC Monitoring tab before exploitation. All four KPIs at zero: no DC-relevant alerts fired, no chase certificate events, no DCSync replication, no machine accounts created.

Post-Attack State

SOC Alerts & KPI Center after exploitation: 1 Critical, 3 High, 14 Medium alerts. The Certighost rule appears in the Top Triggering Rules list and surfaces as a Critical entry in the Latest Critical & High Alerts table at 08/03 12:15:01.

DC Monitoring tab post-attack. Chase Cert Events: 2, DC-Relevant Alerts Fired: 1, Machine Accounts Created: 1, DCSync Replication: 0. Triggered Alerts row shows Alert - Certighost (CVE-2026-54121) at Critical, 08/03 12:15:01. DC01 Threat Event Trend shows the AD CS Certificate spike at 12:13.

Planned Detection Chain

The MITRE mapping above covers the full Certighost attack chain from initial discovery through persistence via forged Kerberos tickets. Only the certificate request and issuance stage has a built detection rule today. The table below tracks build status for the remaining stages, so the chain can eventually correlate risk across the full attack path instead of relying on a single point detection.

The detection rules planned below align with the attack chain demonstrated in the public PoC and covered in Microsoft's detection guidance.

Future Improvements

The current detection operates entirely on Windows Security event logs from the CA host. It has no visibility into how the rogue chase target stands itself up at the network layer, the LDAP and SMB listeners the attacker's own host opens locally to answer the CA's chase lookup. A network-based signal would close that gap and give an earlier, independent trigger point, before the certificate request even reaches the CA.

Network detection (Suricata). A signature watching for outbound SMB (445) and LDAP (389) connections initiated by the CA or DC host toward a destination address outside the known domain controller allow-list would catch the chase lookup itself, at the moment the CA validates the forged target, rather than after the certificate has already been issued. This depends on a network tap or span port positioned to see CA-to-attacker traffic, and requires maintaining an allow-list of legitimate DC IPs to avoid false positives on normal DC-to-DC replication. Not built or tested in this lab, listed here as the next logical layer to add.

Alert chaining. The rules listed in Planned Detection Chain currently fire independently, each a separate critical alert with no relationship to the others. Chaining them, correlating multiple stage alerts against the same entity (requester account or target DC identity) and escalating severity as more stages fire, would widen behavioral coverage beyond any single detection. An attacker who evades one stage, for example using a pre-existing machine account to skip the 4741 signal, would still surface if a later stage in the chain fires for the same identity. This is a natural fit for Splunk's risk-based alerting model, accumulating a risk score per entity across contributing searches rather than treating each rule as a standalone alert.

Owner

Youssef Benchater

Last Reviewed / Version

2026-08-03, v1.2.1

References

• Microsoft Tech Community, "Detecting CVE-2026-54121 (Certighost) with Microsoft Defender": https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/detecting-cve-2026-54121-certighost-with-microsoft-defender/4542861

• Proof of concept repository, H0j3n and aniqfakhrul: https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26