· ·

CertiGhostbusters! – Notes about detecting CVE-2026-54121 AD CS exploitation

CVE-2026-54121 – CertiGhost

CVE-2026-54121, also known as “Certighost”, is a critical improper-authorization vulnerability in Microsoft Active Directory Certificate Services (AD CS) that allows a low-privileged domain user to achieve full domain takeover. It was patched on July 14, 2026 Patch Tuesday updates, and a Proof of Concept was released 10 days later on Github by the researchers who discovered the vulnerability.

I won’t dive too deep on the vulnerability details, since the authors (@h0j3n, @aniqfakhrul) already provided a phenomenal and extensive analysis on the vulnerability and its implications, which is definitely worth the read.

As a TLDR:

  • When processing certificate requests across domains, the Certificate Authority (CA) performs a second directory lookup called a “chase”. Adversaries may manipulate request attributes to force the CA to contact a rogue, attacker-controlled host over SMB/LDAP. This allows the attacker to forge a certificate impersonating a valid DC.
  • The CA blindly trusts identity data from the rogue host without verifying it is a legitimate Domain Controller (DC). This allows the attacker to forge a certificate impersonating a valid DC.
  • Requires network access and a standard domain user account; no administrator privileges or user interaction are needed. Adversaries must register service principal names (SPNs) on a valid domain principal (if machineAccountQuota > 0, they may register a new device and use it, otherwise they must control a machineAccount).

Exploitation & Telemetry

NOTE: The rules described in this section showcase possible detection approaches. They lack proper testing in KQL and can generate some level of noise. Use at your own discretion.

With that in mind, and to check the telemetry that the exploit generated, I spun up my lab environment. Note that this is a fully default environment, installed a couple of months ago for some other tests. I had not installed the July patches, which render the environment vulnerable.

From the attacking box, I executed the Proof-of-Concept code, with great success:

Now for the interesting part: what type of telemetry does this generate, and how can we leverage it to develop detection signatures?

Fist, the PoC implementation relies on the creation of Computer Accounts (while technically not necessary for the vulnerability to be exploited). This will produce an Event ID 4741 (A computer account was created) on the Active Directory. Looking at the event, we can see that the name in the exploit has a common prefix:

This is the default behavior, implemented in the exploit code – the GHOST prefix followed by 8 random capital ASCII characters:

A very lazy, yet somehow valid approach to detect this would be to look into Event IDs 4741, where the recently created computer account contained the keyword GHOST:

SecurityEvent
| where EventID == 4741
| extend RawData = tostring(EventData)
| where RawData contains "GHOST"

Another interesting event to have a look at is the certificate issuance event – Event ID 4887 – (Certificate Services approved a certificate request and issued a certificate). In this case, it contains the following properties:

  • a cdc (Cert Domain Controller / Client DC) field pointing to the attacker IP, whereas in typical events this would be the DNS name a Domain Controller.
  • a rmd (Request Machine DNS Name) field pointing to a Domain Controller, whereas in typical events this would be the UPN of the requester
let DC_Names = dynamic(["DC01", "DC02", "DC03"]);
SecurityEvent
| where EventID == 4887
| extend RawData = tostring(EventData)
| extend cdc_value = extract(@"cdc:\s*([^<&\s\r\n]+)", 1, RawData)
| extend rmd_value = extract(@"rmd:\s*([^<&\s\r\n]+)", 1, RawData)
// Condition A: cdc contains an IPv4 address
// Condition B: rmd contains a known DC name and cdc is not a DC name
| where cdc_value matches regex @"\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b"
     or rmd_value has_any (DC_Names) and !(cdc_value has_any(DC_Names))

Finally, since the exploit requires the Certificate Authority to connect to the fake LDAP server hosted in the attacker box, in order to perform the LDAP chase for the fake rmd, we can monitor for the certsrv.exe service, initiating outbound LDAP connections to non-Domain Controllers IP addresses:

DeviceNetworkEvents
| where InitiatingProcessFileName contains "certsrv"
| where RemotePort == 389
//EXCLUDE DC IPs

Microsoft has also already released built-in coverage in their security stack tools (likely Defender for Endpoint and Defender for Identity) in order to detect this kind of attacks, so if you happen to have any of these products, it is worth to keep an eye on alerts with these names:

  • Potential Certighost (CVE-2026-54121) AD CS abuse.
  • Active Directory Certificate Services attack tool activity.

As always, feel free to use the queries above to hunt through your environment, tune out the noise, and ensure your Enterprise CAs have the July 2026 patches successfully deployed.