How can security teams detect AD CS Domain Persistence?

What AD CS Domain Persistence usually looks like in practice

AD CS persistence is rarely about one single backdoor. It usually shows up as a set of changes that preserve the attacker’s ability to mint trusted certificates even after passwords are reset or hosts are rebuilt. That makes certificate templates, enrollment permissions, CA configuration, and trust paths the key places to inspect. For defenders, the practical question is whether certificate issuance has been altered in a way that outlives normal account hygiene.

Look for template edits that broaden who can enroll, who can request on behalf of others, or which subject names can be supplied. Also watch for CA-level changes, because persistence often depends on keeping a certificate authority willing to issue certificates that map to privileged users or systems. The abuse path can remain quiet if the attacker can keep using certificate-based authentication instead of password-based access.

Administrative activity matters too. Sudden changes made through uncommon admin workstations, unexpected use of certificate management consoles, or certificate logons originating from unfamiliar systems are all worth treating as signals, not just noise. In environments with hybrid identity or delegated administration, those changes may be subtle, so baselines need to include not only normal issuance volume but also normal administrative pathways and timing.

Which changes should be baselined and compared first?

The highest-value baseline is the combination of template metadata, enrollment ACLs, and CA policy. Those three areas tell you whether someone has changed what can be issued, who can obtain it, and whether the CA will accept a request that should have been rejected. If any of those drift, the persistence technique may still be active even when endpoint evidence is thin.

Certificate-based logon patterns are equally important. A new or unusual certificate identity used for directory logon, especially when it appears from an account that does not normally authenticate that way, can indicate that a previously issued certificate remains valid for reuse. This is why review should include both the administrative change and the downstream authentication behaviour it enables.

To support that review, use AD CS Security Guide for the AD CS-specific abuse paths, template hardening points, and the certificate mapping issues that matter when persistence is the concern. For broader directory hardening context, Active Directory and Entra ID Hardening Guide helps place certificate services within the wider privileged access model.

When the change is not in AD CS itself, compare it to normal privileged identity behaviour. Top 10 Active Directory Security Risks is useful here because persistence often rides on the same misconfigurations that create broader directory exposure.

What evidence points to certificate-based persistence rather than ordinary administration?

Evidence usually comes from mismatches. A template change with no approved change record, enrollment permission expansion without a business reason, or a CA setting change that aligns with later suspicious logons all deserve review together. The goal is to connect the persistence mechanism to the resulting authentication behaviour, not to treat each artifact in isolation.

Unexpected admin action is especially important when it is followed by certificate issuance that survives credential resets. If a certificate remains usable after the original account is locked down, the attacker may still have durable access through trust already granted by the CA. That is why teams should correlate certificate events with directory privilege changes, administrative sessions, and any certificate mapping decisions that were recently altered.

For an identity-centric detection lens, Identity Threat Detection and Response (ITDR) Guide is the most direct companion resource because it focuses on the identity abuse patterns and response logic that persistence relies on. If the same activity also resembles broader identity compromise or lateral movement, Salt Typhoon telecom intrusions 2025 offers a useful example of how stolen credentials and durable access paths can support long-running intrusion activity.

Practitioner Guidance

What to prioritise: Start with the smallest set of objects that can preserve trust: template ACLs, CA policy, and any certificate mapping or enrollment changes. If you cannot explain a change as an approved administrative action, treat it as a potential persistence indicator until proven otherwise.

What to verify: Check whether the certificate in question still authenticates successfully after the original admin or user account has been remediated. If it does, the persistence problem is not theoretical, the trust relationship is still live.

Common mistake: Teams often focus on endpoint cleanup while leaving certificate issuance paths untouched. If the attacker can still obtain or reuse a trusted certificate, the environment may look clean while the persistence mechanism remains available.

Practitioner takeaway: In AD CS persistence investigations, the decisive question is not just who changed the directory, but whether that change created a durable trust path that can still issue usable certificates.

Related resources from NHI Mgmt Group

• How can security teams detect AD CS Domain Escalation?
• How should security teams use decoy certificate templates to detect AD CS abuse early?
• How should security teams detect a DCShadow attack before it becomes a domain-wide persistence path?
• Why are NHIs a critical concern for security teams?