Certighost: How to Determine Whether Your Enterprise CA Was Exploited

Microsoft’s patch closes the Certighost vulnerability — but it cannot tell you whether an attacker previously used it. Here is how to assess your exposure and hunt for evidence with PKI Spotlight^®.

Certighost is the kind of vulnerability that keeps PKI teams awake at night.

Tracked as CVE-2026-54121, it affects Active Directory Certificate Services and can allow a low-privileged domain user to obtain a certificate representing a domain controller. That certificate can then be used for Kerberos authentication and, ultimately, domain compromise.

Microsoft addressed the vulnerability in its July 2026 security updates. But installing the update answers only one question: Is the CA still vulnerable?

It does not answer the more urgent one:

Was the vulnerability exploited before the CA was patched?

That distinction matters because patching a certification authority does not automatically identify or revoke certificates issued before the update. Organizations therefore need both a remediation plan and a retrospective hunt.

This article explains the attack at a practical level and outlines how PKI Spotlight can help you determine whether your environment was exposed, identify suspicious certificate activity, and preserve the evidence needed for a broader investigation.

What is Certighost?

Certighost exploits a legacy behavior in the Microsoft Enterprise CA policy module commonly referred to as “chasing” the client domain controller.

During certificate enrollment, a requester can supply request attributes including cdc and rmd. In affected configurations, the CA may use the requester-supplied cdc value to locate a domain controller and obtain identity information needed to process the request.

The vulnerability arises because the CA did not adequately verify that the system identified by cdc was a genuine domain controller.

An attacker could therefore direct the CA to an attacker-controlled system masquerading as the client’s domain controller. That system could provide identity information belonging to a real domain controller, causing the enterprise CA to issue a valid certificate representing that domain controller.

The attack is particularly serious because the resulting certificate is not forged. It is issued and signed by the organization’s trusted CA.

Microsoft’s update changes the validation behavior so that the CA verifies that the supplied host belongs to a legitimate domain-controller computer account. Additional technical details are available in the Microsoft Security Update Guide and the researcher’s technical disclosure.

Why the attack is so consequential

Certighost combines several characteristics that make certificate attacks difficult to detect:

• The initial actor may need only an ordinary domain account.
• The malicious certificate is signed by a trusted enterprise CA.
• Authentication with the certificate can resemble legitimate Kerberos activity.
• Conventional vulnerability scanners may identify an unpatched CA but cannot establish whether it issued a malicious certificate.
• Installing the patch does not invalidate certificates issued before remediation.

If an attacker obtains a certificate representing a domain controller, the attacker may be able to use PKINIT to obtain Kerberos credentials for that identity. From there, replication privileges associated with the domain controller can enable a DCSync attack and exposure of domain credential material.

In practical terms, a successful Certighost attack should be treated as a potential domain-compromise event — not merely as a vulnerable-server finding.

Start by establishing whether the attack path existed

Before searching for an individual certificate, establish whether the affected CA behavior was enabled.

In PKI Spotlight:

1. Open Agents.
2. Select the certification authority.
3. Open Configuration.
4. Review Policy Module Configurations.
5. Look for Enable chase client DC, corresponding to EDITF_ENABLECHASECLIENTDC.

If this option was enabled, the affected processing path was available on that CA. Its presence is evidence of exposure, not proof that exploitation occurred.

If it was not enabled, the demonstrated Certighost attack path is substantially reduced. You should still confirm the CA’s patch and restart status, however, rather than treating the configuration setting as a substitute for remediation.

For each enterprise CA, document:

• CA name and operating-system version
• Whether chase-client-DC processing was enabled
• Date and time the security update was installed
• Date and time the CA service or server was restarted
• Available certificate-services audit history
• Earliest PKI Spotlight event and certificate record available

This produces the timeline against which subsequent evidence should be evaluated.

Identify templates capable of producing an authentication credential

Not every certificate template is useful to an attacker. Focus first on templates that could issue a certificate suitable for client or Kerberos authentication.

In PKI Spotlight’s Certificate Template Status view, review templates containing authentication-related enhanced key usages, including:

• Client Authentication – 1.3.6.1.5.5.7.3.2
• Smart Card Logon – 1.3.6.1.4.1.311.20.2.2
• PKINIT Client Authentication – 1.3.6.1.5.2.3.4
• Any Purpose – 2.5.29.37.0
• Templates with no EKU restriction

Begin with the built-in Computer and Machine templates, but do not stop there. Many organizations duplicate Microsoft templates and assign locally meaningful display names. Follow the template’s OID, assigned CAs, enrollment permissions, identity construction, and issuance requirements rather than relying solely on its name.

The highest-priority combination is generally:

• Chase-client-DC processing was enabled.
• The CA was not confirmed as patched and restarted.
• An authentication-capable computer template was published.
• The template derived DNS or computer identity from Active Directory.
• Ordinary or broadly delegated accounts could submit enrollment requests.
• Manager approval or authorized signatures were not required.

Some settings that are important in other AD CS attacks are less reassuring here. For example, “User Provides Subject Name: No” does not eliminate a Certighost path because the attack targets how the CA retrieves identity information — not simply whether the requester may type a subject name.

Hunt for request and issuance evidence

The most valuable Windows certificate-services events include:

• 4886 – Certificate Services received a certificate request.
• 4887 – Certificate Services approved a request and issued a certificate.
• 4888 – Certificate Services denied a certificate request.

In PKI Spotlight, open Events, select Windows, and filter by the affected CA, the exposure period, and these event IDs. Narrow the results using template name, requester, request ID, or certificate serial number where available.

Search request data for:

• cdc
• rmd
• Domain-controller fully qualified domain names
• Workstation and member-server names
• Unrecognized or external hostnames

The presence of cdc or rmd alone is not proof of exploitation. These attributes can appear in legitimate processing. The investigative value comes from correlation.

Escalate a request when one or more of the following are true:

• The cdc value identifies a workstation, member server, unknown system, or address that was not a domain controller at the time.
• The requesting account is unexpected for the template or certificate identity.
• The issued certificate represents a domain controller, but the request originated from a different user or computer.
• The certificate’s subject, SAN, SID extension, requester, and template do not form a coherent identity.
• Enrollment occurred at an unusual time or from a newly created or low-privileged account.
• The CA made SMB, LDAP, or related network connections to the system identified by cdc.
• Certificate issuance was followed by unusual PKINIT activity or directory-replication behavior.

A single log source is unlikely to prove the complete attack. The strongest cases combine CA request records, the issued certificate, CA network telemetry, domain-controller authentication logs, and directory-replication activity.

Look for configuration changes and attempts to weaken visibility

The investigation should also include certificate-service configuration events, particularly:

• 4873 and 4874 – Certificate request extensions or attributes changed
• 4880 and 4881 – Certificate Services started or stopped
• 4882 – CA security permissions changed
• 4885 – Certificate Services audit filter changed
• 4890 and 4891 – CA configuration changed
• 4896 – Rows deleted from the CA database
• 4898 through 4900 – Certificate template changes

These events can answer important questions:

• Was chase-client-DC processing enabled shortly before suspicious issuance?
• Was a template published or modified to make exploitation easier?
• Were enrollment permissions expanded?
• Was auditing reduced before or after the suspected request?
• Were CA database records removed?
• Was the service restarted in connection with an unexplained configuration change?

PKI Spotlight’s template history, CA configuration monitoring, agent-health information, and Is-Alive data can help reconstruct this sequence and identify monitoring gaps.

Correlate certificate issuance with downstream activity

A suspicious certificate request becomes substantially more serious when it is followed by activity consistent with use of the certificate.

For each candidate certificate, investigate:

1. Issuance: Who submitted the request, which template was used, and what identity was placed in the certificate?
2. CA communication: Did the CA contact the host supplied through cdc, and was that host a genuine domain controller?
3. Authentication: Was the certificate or represented identity used for PKINIT or other certificate-based authentication?
4. Privilege use: Did the identity subsequently perform directory replication or DCSync-like activity?
5. Persistence: Does the certificate remain valid, and could copies still exist outside the organization’s control?

This correlation can be performed in a SIEM by forwarding PKI Spotlight events through syslog or CEF and joining them with firewall, endpoint, Kerberos, and domain-controller telemetry.

What to do if you find a credible match

Do not begin by deleting evidence. Preserve the PKI Spotlight events, CA database entries, request attributes, issued certificate, certificate chain, relevant Windows logs, and CA network records.

Then:

• Confirm whether the cdc target was a legitimate domain controller at the time of issuance.
• Compare the requester with the certificate’s subject, SAN, SID extension, and template.
• Determine whether the certificate was used for authentication.
• Review the represented domain controller’s replication activity.
• Revoke the certificate and publish updated revocation information.
• Patch and restart every affected CA.
• Investigate the requesting account and attacker-controlled host.
• If domain-controller impersonation or DCSync occurred, initiate the organization’s domain-compromise response process.

Revocation is necessary, but it may not be sufficient. If the certificate enabled the attacker to obtain credential material, the investigation must address what the attacker accessed after authentication.

Patching closes the vulnerability. Hunting closes the incident.

Certighost demonstrates why AD CS must be treated as a core identity system. A certification authority can be fully patched today while certificates issued yesterday remain valid and dangerous.

The immediate objective is to determine whether the vulnerable processing path existed. The larger objective is to connect certificate issuance with the identity and network evidence needed to establish whether that path was actually abused.

PKI Spotlight provides the certificate-specific visibility needed for that investigation and supplies the context required to integrate CA activity with the rest of the security operations environment.

Get the full 29-page guide for the detailed PKI Spotlight investigation workflow, template-assessment methodology, Windows event reference, alert recommendations, Microsoft Sentinel and Splunk hunting queries, analytic logic, and incident-response checklist.