When Your CA Is Compromised: Containment, Revocation, and Recovery
CA compromise is one of the most severe Active Directory security incidents — a compromised CA can issue fraudulent certificates that are trusted by every system in the domain. This playbook covers the immediate response actions, forensic steps, and recovery decisions required when a CA compromise is suspected or confirmed.
Immediate Containment
When CA compromise is suspected, take these actions immediately — before investigation:
- Isolate the CA server from the network. Do not shut it down — preserve volatile memory and running processes for forensics.
- Revoke the CA's own certificate if it is an Issuing CA — this invalidates all certificates it has issued. This is a drastic action; confirm compromise before proceeding.
- Disable the CertSvc service on the CA to stop new certificate issuance without full network isolation.
- Preserve CA audit logs: copy the Security event log and the CA database from %SystemRoot%\System32\CertLog.
Rogue Certificate Identification
Export the full CA database and review all issued certificates for anomalies. Look for certificates issued to unexpected principals, certificates with unusual EKUs (Any Purpose, Smart Card Logon for non-user accounts), and certificates issued outside business hours or from unexpected enrollment hosts.
# Export CA database to CSV for analysis certutil -view -out "RequestID,RequesterName,NotBefore,NotAfter,CertificateTemplate,SubjectKeyIdentifier" csv > ca_issued_certs.csv
Recovery Decision: Rebuild vs. Restore
The decision to rebuild the CA from scratch versus restore from backup depends on the scope of compromise. If the CA private key has been exfiltrated, the CA must be rebuilt — a restored CA with a compromised private key is still compromised. If the compromise was limited to the OS layer (malware, unauthorized access) without evidence of key extraction, a restore from a known-good backup may be viable.
In either case, all certificates issued by the CA after the earliest possible compromise date should be treated as potentially fraudulent and revoked.
CA compromise is a force multiplier for attackers — fraudulent certificates can be used for authentication, code signing, and TLS interception across the entire domain. The response window is narrow: every hour the CA remains operational after compromise is an hour the attacker can issue additional fraudulent certificates.
- 1Develop and test a CA compromise response playbook before an incident occurs.
- 2Maintain offline, encrypted CA backups that include the CA database, private key (HSM backup), and configuration.
- 3Enable CA audit logging now — you cannot reconstruct what happened without logs.
- 4Define your CA rebuild procedure in advance — know where your Root CA offline media is stored.
- 5Conduct a tabletop exercise simulating CA compromise with your security and PKI teams.
Most organizations do not have a CA compromise playbook. They have a general IR playbook that does not account for the PKI-specific response actions required. By the time you are figuring out how to export the CA database during an active incident, you have already lost significant response time. Build the playbook now.
InsecurePlanet provides original technical analysis based on the sources listed below. This article does not claim facts beyond the cited source material.