Which logs show evidence of a Golden Certificate attack?

Which log sources matter most for Golden Certificate detection?

Golden Certificate activity is easiest to spot when you correlate certificate authority, domain controller, and PKI audit data, because the attack’s value comes from producing a certificate that behaves like a trusted enterprise identity. The AD CS Security Guide is the best internal starting point for the certificate-template and CA abuse paths that often precede the telltale log trail.

Certificate authority logs are the first place to look for unusual issuance patterns, template edits, renewed trust relationships, and administrative actions that should not line up with normal enrolment. Domain controller logs add the authentication side of the story, showing whether a certificate was actually used to request access in a way that resembles a legitimate domain principal.

PKI and directory audit records are especially useful when the attacker modifies a template, changes CA configuration, or abuses a trusted mapping path rather than stealing a single user certificate. In practice, the strongest signal is not one log entry on its own, but a certificate issuance event that lacks the expected approval, enrolment, or change-control trail and then appears in authentication activity soon after.

What patterns separate benign certificate use from Golden Certificate abuse?

Normal certificate operations usually leave a small but coherent trail: request, approval or automated enrolment, issuance, and later use within an expected account or system lifecycle. Golden Certificate abuse breaks that pattern by creating a trusted certificate path that should not exist for the identity being impersonated.

Watch for certificate templates that are modified shortly before suspicious issuance, especially when the change increases enrollee control over subject details or weakens the trust boundary around certificate mapping. A CISA cyber threat advisories page is a useful companion source when you need to compare local findings with broader abuse patterns and incident response priorities.

Investigators should also treat unexpected certificate use for authentication as a separate clue, because the attack may surface later than the issuance event itself. If the certificate appears to authenticate as a privileged or domain-linked identity without the usual enrolment history, the issue is not only issuance abuse, but trust abuse.

How should investigators confirm and contain the activity?

The practical test is to line up certificate issuance, CA configuration, revocation state, and account activity in the same time window. If the certificate was issued from a path that should not have produced it, or if it can still be used after trust changes, you likely have a real exposure rather than a harmless anomaly.

The CA/Browser Forum is relevant here because certificate issuance and revocation hygiene depend on a reliable trust and lifecycle process, even when the attack is internal rather than public-web facing. For deeper key-lifecycle framing, NIST SP 800-57 Key Management is the clearest external reference for why lifecycle control, cryptoperiod discipline, and revocation handling matter once a certificate can impersonate an identity.

Containment usually means revoking the suspicious certificate, checking whether the CA or template was altered, and reviewing whether the impersonated account or any linked administrative credential was also abused. If the certificate was issued through a compromised CA or template path, the response needs to widen from the single certificate to the trust fabric that produced it.

Practitioner Guidance

What to verify: Confirm whether the certificate has a normal enrolment trail, a valid issuer path, and a believable identity mapping. If those three do not line up, treat the certificate as an impersonation artifact first and a legitimate asset second.

Decision rule: If the certificate can authenticate as a domain identity without an expected request, approval, or lifecycle record, prioritise revocation, CA review, and account-impact assessment before spending time on low-value log noise. If you can tie the certificate to a template or CA change, that change becomes part of the incident scope.

Practitioner takeaway: Golden Certificate detection is a correlation problem, not a single-log problem, and the decisive evidence is usually the mismatch between issuance, trust configuration, and authentication use.

Related resources from NHI Mgmt Group

• Which logs show evidence of Golden gMSA and Golden dMSA Attacks?
• Which logs show evidence of Biometric Injection Attack?
• Which logs show evidence of Kerberos Key List Attack?
• Which logs show evidence of fast-flux DNS?