What does AD CS Account Persistence look like in a real intrusion?

What AD CS account persistence looks like in an intrusion

In a real intrusion, AD CS persistence usually shows up as an attacker preserving usable trust rather than simply preserving a password. They may keep a certificate that still authenticates, alter a template so new certificates can be issued later, or change enrolment paths so access survives account resets and some clean-up actions. The visible clue is often continued authentication after the obvious compromise has been remediated.

The important practical point is that AD CS turns certificate trust into an access path. If an attacker can issue, renew, map, or reuse certificates, they may retain entry even after the original account password changes. That makes the persistence look less like a single stolen secret and more like a durable trust relationship that needs to be reviewed, revoked, and re-secured.

Persistent abuse often leaves configuration evidence, not just login evidence. Watch for certificate enrolment that does not fit the normal user, service, or workstation pattern, changes to certificate templates, new or modified enrolment permissions, and unexpected use of certificate-based authentication from systems that should no longer be trusted. The same pattern can also appear when an attacker pivots from one compromised account to a broader certificate authority path.

Why AD CS persistence survives ordinary remediation

Resetting a password only removes one way in. It does not automatically invalidate certificates already issued, undo template abuse, or repair a compromised enrolment workflow. If the attacker has changed the trust path, the environment may continue to accept certificate-based authentication even though the initial foothold looks closed.

This is why AD CS persistence is especially dangerous in environments that treat certificates as low-visibility infrastructure. The attacker is not necessarily trying to stay hidden forever in the same account. They are trying to keep a valid authentication artifact or a repeatable issuance path that can be used again later, sometimes through a different account or machine entirely.

In practice, the persistence often sits at the boundary between identity governance and certificate authority hygiene. NHI Management Group’s AD CS Security Guide covers the template abuse and mapping issues that make this persistence durable, and the underlying issue is usually a trust path problem, not just a credential problem. For defenders, that means the question is not only “which password was reset?” but also “which certificate paths still authenticate?”

How to confirm, contain, and clean up certificate-based persistence

Start by confirming whether certificate authentication is still succeeding from accounts, hosts, or templates that should have been neutralised. Then trace which certificates were issued, which templates were changed, and whether any enrolment or mapping settings were altered during the intrusion. If authentication continues after the reset, treat that as evidence of an unresolved trust path, not a benign anomaly.

Containment usually means revoking affected certificates, removing or repairing rogue template changes, and restoring the intended enrolment path. If the environment depends on certificate mapping or auto-enrolment, validate that those mechanisms are back to a known-good state before assuming the intrusion is over. In many cases, you also need to review whether the attacker obtained the authority to issue new certificates through a compromised CA-adjacent account or an over-permissive template.

For correlation, compare the pattern against broader identity abuse tradecraft. NHI Management Group’s Identity Threat Detection and Response (ITDR) Guide is useful here because persistence often appears as valid account activity, token or certificate reuse, and repeated authentication after an assumed recovery point. If you see the same actor maintaining access through multiple identity artifacts, the incident is no longer a single-account problem.

What a defender should look for first

The fastest triage path is to look for three things together: unexplained enrolment activity, template or CA configuration drift, and successful authentication that should have stopped. That combination is stronger evidence than any one signal by itself, because AD CS persistence is often built to blend into normal certificate operations.

It also helps to compare the case with known identity persistence patterns. The attack may resemble ordinary credential abuse at first, but the durable piece is the certificate lifecycle, not the login event. NHI Management Group’s Salt Typhoon telecom intrusions 2025 illustrates the broader point that attackers often keep access by combining stolen access material with additional trust artifacts, then using those artifacts to stay operational after the obvious compromise has been handled.

Risk and Threat Considerations

AD CS persistence is risky because certificate trust can outlive the compromise that created it. If the attacker can keep a valid certificate, alter issuance controls, or preserve a certificate mapping path, they may continue authenticating after password resets, account disables, or partial incident response.

Failure mechanism: The defender removes the visible account compromise but leaves issued certificates, template abuse, or enrolment changes intact, so certificate-based authentication remains trusted.

Impact: The attacker retains a durable, low-noise access path that can support re-entry, lateral movement, and repeated compromise even after remediation appears complete.

Practitioner Guidance

What to verify: Confirm whether the certificate authority, template, and enrolment path are clean before you declare recovery. If authentication is still succeeding through certificates, treat the trust path as active compromise and not just residual noise.

Decision rule: If a certificate can still authenticate to a sensitive system, revoke and revalidate that trust path before spending time on password resets alone. If the certificate path cannot be fully explained, assume persistence until proven otherwise.

Practitioner takeaway: With AD CS, the real recovery question is whether you have removed the attacker’s issuance and trust options, not whether you have changed the password of the account they first used.

Related resources from NHI Mgmt Group

• What does Account Enumeration look like in a real intrusion?
• What does macOS auto-start persistence look like in a real intrusion?
• What does Fast-Flux DNS look like in a real intrusion?
• What does HTTP Desync Attack look like in a real intrusion?