CertiGhost after patching: hunt the certificate-to-DCSync chain

Microsoft's July 2026 update closes CVE-2026-54121, known as CertiGhost, but installing it answers only the first question. It stops a vulnerable Active Directory Certificate Services (AD CS) certification authority from following an untrusted directory chase in the same way. It does not show whether the CA previously issued a certificate carrying a Domain Controller's identity, whether that certificate was used for PKINIT, or whether the resulting DC context requested directory secrets.

The public research demonstrates a path from a low-privileged domain account to a CA-signed DC certificate and DCSync in the tested configuration. That makes retrospective investigation more important than a conventional patch-and-close response. The investigation must join evidence from the CA, network, Kerberos and directory-replication layers. Looking at any one layer in isolation leaves an easy route to a false negative.

Contribution

This article turns the published exploit chain into a staged hunt and identifies a dangerous blind spot in user-focused DCSync analytics. Elastic's published rule excludes computer accounts because legitimate replication is performed by Domain Controllers. CertiGhost deliberately authenticates as a DC computer account. That filter can therefore discard the final stage of the exploit.

The defensible analytic is not 'DCSync by a user account'. It is 'replication by a DC identity from an address that does not belong to that DC', correlated backwards to certificate-backed Kerberos authentication and an unusual CA chase. That distinction preserves ordinary replication while keeping the forged machine identity visible.

What the vulnerability actually permits

Microsoft describes CVE-2026-54121 as CWE-285 Improper Authorization in AD CS, with CVSS 3.1 metrics of Attack Vector: Network, Privileges Required: Low and User Interaction: None. The operational detail comes from the researchers who disclosed CertiGhost.

AD CS has a directory-object resolution fallback called a chase. Request attributes named cdc, for client DC, and rmd, for remote domain, influence where the CA performs a secondary lookup. Before the July update, the requester could supply a chase target without the CA first proving that the target was the Domain Controller it claimed to be.

The public proof of concept creates or reuses a machine account, starts rogue SMB/LSA and LDAP listeners, and submits a certificate request whose cdc value points to the controlled host. The CA connects to that host over TCP 445 and 389. The rogue services authenticate using the controlled machine account but return identity data belonging to the chosen DC, including its SID and DNS name. In the tested configuration, the CA then issues a certificate whose identity maps to that DC.

The certificate is usable as alternate authentication material because Active Directory, the domain's identity provider, trusts certificates its own certification authority signed. The proof of concept performs PKINIT to obtain Kerberos credentials for the target DC. A Domain Controller account holds directory replication rights, so the chain can continue to DCSync and retrieve secrets including krbtgt.

This is not a claim that every unpatched AD CS deployment is exploitable. The demonstrated route depends on the vulnerable chase path being enabled and reached, suitable Machine-template enrolment, access to the CA enrolment interface, and network reachability from the CA to attacker-controlled SMB and LDAP listeners. The default machine-account quota makes it easier for an ordinary domain user to obtain the required principal, but the proof of concept can reuse an existing controlled machine account. Exposure decisions should be based on the actual CA configuration and network path, not on the presence of AD CS alone.

The July update changes the trust boundary. The researchers' binary analysis shows the patched CA validating that cdc resolves to a unique computer object with the SERVER_TRUST_ACCOUNT flag before continuing, followed by a SID comparison. Microsoft remains the authority for which supported Windows builds and security updates apply. The researchers' temporary mitigation disables the chase fallback, but it was validated in a lab and can disrupt legitimate cross-DC enrolment. Test it against a representative CA before use; patching is the preferred remediation.

Start with the CA database, not the endpoint

The CA is the first durable record of successful issuance. Preserve its database, Security log and relevant backups before changing retention, clearing logs or rebuilding systems. If audit data has rolled over, the certificate database may still retain request attributes and issuance details.

Where 'Audit Certification Services' was enabled, Events 4886 and 4887 are the most useful starting pair. Microsoft documents 4886 as a received certificate request containing the request ID, requester and attributes. Event 4887 records approval and issuance with the same request ID, plus disposition, subject and certificate information. Join them on request ID rather than timestamp alone.

Search request attributes for cdc: and rmd:. A useful first pass also looks for the Machine template and requesters that were newly created or seldom used computer accounts. Do not reduce the hunt to the proof of concept's default GHOST[A-Z]{8}$ naming pattern. The machine name is configurable, and an existing principal can be reused.

For every suspicious issued request, retain the certificate serial number, thumbprint where available, requester, template, subject, validity interval and the exact cdc and rmd values. Validate any certutil -view query against the deployed Windows Server version before operational use. Column names and output formatting can differ, and an untested copy-and-paste command is a poor foundation for a compromise decision.

Absence of 4886 or 4887 is not exculpatory if the audit subcategory was disabled, retention was short or an attacker tampered with audit settings. Events 4885 and 4896 are also worth reviewing because Microsoft assigns high potential criticality to CA audit-filter changes and certificate-database row deletion.

Follow the CA's outbound connections

CertiGhost reverses the network direction defenders may expect. The attacker does not simply connect to the CA and wait. During the chase, the CA initiates SMB and LDAP connections to the host named by the requester.

Use firewall, network detection and response, flow, or endpoint network telemetry to identify the CA opening TCP 445 and 389 to systems that were not Domain Controllers during the exposure window. The strongest candidate is the same destination receiving both protocols close to a suspicious certificate request. Resolve historical addresses against historical asset data, not today's DNS. A reused DHCP address can make an old attacker workstation look like a current server.

If Windows Filtering Platform connection auditing was enabled on the CA, Event 5156 can supplement network records. EDR process-network telemetry may also tie the connection to certsrv.exe. These are supporting signals rather than prerequisites. A CA database record with malicious chase attributes should not be dismissed because network retention expired first.

The converse matters too. An outbound connection to an unusual host does not prove certificate forgery. CAs can contact remote systems for legitimate enrolment and directory operations. Confidence comes from the join: unusual cdc and rmd attributes, issuance on the Machine template, then CA callbacks to the named host.

Find the forged identity at the KDC

The next stage is certificate-backed Kerberos authentication. Domain Controller Security Event 4768 records a request for a ticket-granting ticket and includes the target account and client address. For certificate authentication, supported event versions can also populate certificate issuer, serial number and thumbprint fields.

Hunt for successful 4768 events where the target is a Domain Controller computer account, certificate fields are present, and the client address is not assigned to that DC. Normal DC activity creates plenty of machine-account Kerberos traffic, so the source address is load-bearing context. Build a historical table of DC names, machine SIDs, addresses and address-validity intervals before declaring anomalies.

Do not make the analytic depend on one pre-authentication value across every server version. Microsoft's event documentation notes an updated Event 4768 after January 2025 cumulative updates, and field availability varies with event version and patch state. In a lab that matches production, capture a known-good smartcard or certificate-backed logon and a controlled machine-certificate authentication. Record the resulting event version, pre-authentication type and certificate fields, then write the query against observed schema.

Where the CA record includes a certificate serial number or thumbprint, correlate it directly to 4768. Where it does not, use the target DC identity, request time, certificate validity and client address as a weaker composite join. A suspicious certificate being issued is serious; seeing it used from the attacker's address moves the case from attempted abuse to successful identity impersonation.

Repair the DCSync blind spot

DCSync is the payoff. Event 4662 can expose directory replication when Directory Service Access auditing and suitable SACLs are in place. The relevant control-access mask is 0x100, combined with the replication rights DS-Replication-Get-Changes, DS-Replication-Get-Changes-All and DS-Replication-Get-Changes-In-Filtered-Set, or their schema GUID equivalents.

Elastic's published DCSync analytic excludes subjects ending in $, along with Microsoft Entra Connect MSOL_ accounts. That is reasonable for detecting user accounts unexpectedly starting replication, but it does not cover CertiGhost's forged DC identity. The attack has shaped itself like the traffic the rule removes.

Keep the existing user-focused rule, then add a second SIEM correlation for machine identities. For a 4662 replication event whose subject is a DC account, join Event 4624 network logons by logon ID and recover the source address. Event 4662 holds no client address of its own, so this join is the only route to it: the correlation depends on a network logon that was actually audited, and a path crossing a relay or RPC over HTTP can record an intervening hop rather than the attacker. Alert when that source is not an address assigned to the named DC. Raise confidence further when the same source previously made a certificate-backed 4768 request for that DC, or appears as the cdc destination in a suspicious CA request.

The complete high-confidence sequence is:

1. The CA receives and issues a Machine-template request containing attacker-selected cdc and rmd values.
2. The CA opens SMB and LDAP connections to the cdc host.
3. A DC computer account obtains a TGT through certificate-backed authentication from that host's address.
4. The same identity and source perform directory replication.

Each stage can be noisy or absent on its own. Together they describe the exploit rather than a generic AD CS anomaly. The source-address test catches CertiGhost's shape, where replication arrives from a host outside the DC's own inventory. It does not catch an attacker who runs the replication from a Domain Controller itself, or from another address already trusted as a DC, so a clean address comparison argues against this exploit path rather than against DCSync in general. Missing 4662 records do not prove DCSync did not occur, because generation depends on audit policy and SACL coverage. Network monitoring for DRS replication from non-DC addresses and identity-security product alerts are useful independent checks.

Decide whether this is a CA incident or a domain incident

A suspicious request that was denied is not the same case as an issued certificate. An issued certificate is not yet proof it was used. A certificate-backed 4768 from a non-DC address shows successful impersonation. Replication activity or evidence that directory secrets were retrieved crosses the boundary into domain compromise.

For an issued certificate, revoke it where appropriate, publish updated revocation information, preserve its private-key exposure context and hunt for every use across its validity period. Patching the CA does not invalidate a certificate already in the attacker's possession. Do not assume that a password reset removes certificate-backed access.

If DCSync may have exposed krbtgt, activate the organisation's domain-compromise recovery plan. Scope which directory objects and secrets were replicated, rotate affected service and privileged credentials, and inspect trusts, federation, synchronisation services and cloud-connected administration paths. Microsoft forest-recovery guidance calls for resetting krbtgt twice, with a wait longer than the configured ticket lifetimes between resets. That operation needs replication-aware planning; Microsoft warns that the two resets must be separated by more than the configured ticket lifetimes, rather than performed back to back.

Hybrid estates need one more review. A DC identity or replicated privileged credentials can unlock synchronisation servers, federation services, management tooling and accounts that administer cloud resources. The CertiGhost exploit begins on premises, but the incident boundary follows the credentials and trust relationships, not the server rack.

What to do now

Patch every affected Enterprise CA using Microsoft's July 2026 guidance, and verify the installed build rather than trusting deployment status alone. If patching cannot be completed immediately, evaluate the published chase-disable mitigation in a representative staging environment and restrict CA egress to approved Domain Controllers where operationally possible.

Then run the retrospective hunt in order: CA issuance, CA callbacks, certificate-backed 4768 activity and replication. Preserve the joins between request ID, certificate serial or thumbprint, target DC, client address and logon ID. If retention is incomplete, state the blind period explicitly. 'No evidence found' is only as strong as the telemetry that survived.

Finally, inspect every DCSync detection for blanket machine-account exclusions. CertiGhost's most important defensive lesson is not that computer accounts should always alert. It is that identity alone cannot establish legitimacy. A Domain Controller name performing replication from the wrong host is not routine DC traffic. It is a forged uniform, and the source address is where the stitching shows.

References

1. Microsoft Security Response Center, CVE-2026-54121 Security Update Guide.
2. H0j3n and Aniq Fakhru'l, CertiGhost technical analysis and patched-flow comparison.
3. Aniq Fakhru'l, public CertiGhost proof of concept.
4. NIST National Vulnerability Database, CVE-2026-54121.
5. Microsoft, Securing PKI: Appendix A: Events to Monitor.
6. Microsoft, Event 4768: A Kerberos authentication ticket was requested.
7. Elastic, Potential Credential Access via DCSync.
8. Microsoft, Active Directory Forest Recovery: Reset the krbtgt password.
9. MITRE ATT&CK T1649, Steal or Forge Authentication Certificates.
10. MITRE ATT&CK T1550, Use Alternate Authentication Material.
11. MITRE ATT&CK T1003.006, DCSync.