What happens when an attacker keeps valid access long enough to establish persistence?

How durable access changes the intrusion model

Persistence turns a one-time compromise into an ongoing access problem. The attacker is no longer limited by the original password, token, or session, because they have added a second path back into the environment. That can be a new account, a fresh factor, a forged ticket, a long-lived API key, or an OAuth grant that keeps working after the first entry point is removed.

Once that foothold exists, the practical question shifts from “was the original credential exposed?” to “what other trust relationships now exist?” Durable access often survives routine password resets because it lives in account state, token state, or delegated authorization rather than in the single secret that was first stolen.

That is why persistence is so dangerous: it changes the intrusion from transient compromise to configuration-level abuse, where the attacker operates through mechanisms the business may still view as legitimate.

What an attacker usually does to stay in place

Attackers tend to use persistence methods that blend into normal administration. They may create hidden or secondary accounts, add additional MFA methods, mint new long-lived sessions, or place secrets in automation paths that are rarely reviewed. In identity-heavy environments, the most effective persistence often looks like ordinary access management unless someone is checking the surrounding changes.

The same pattern appears in both human and non-human access. A stolen login can be converted into standing API keys, service credentials, or OAuth consent that outlives the original compromise window. NHIMG’s Identity Threat Detection and Response (ITDR) Guide is useful here because it focuses on the detections that matter when valid accounts are being reused for abuse and persistence.

Persistence also gives the attacker time to reduce risk to themselves. They can test access paths slowly, wait for off-hours, and build redundancy so that one cleanup action does not evict them completely. That is why durable access is often paired with privilege escalation, credential planting, and lateral movement rather than a single noisy action.

How to know the account was not really removed

The key test is whether the attacker can still authenticate or act after the initial secret is changed. If resets, token revocation, or password changes do not stop activity, then the compromise has moved beyond the original credential. The likely issue is another trust edge, such as delegated authorization, a new authentication factor, an unmanaged ticket, or a second account created during the intrusion.

Watch for signs that account state changed without a matching business request. New roles, new recovery methods, unexpected OAuth consents, unusual ticket issuance, and API keys that persist across maintenance windows are all indicators that the environment has been modified to preserve access. NHIMG’s Persistence Techniques Guide is a practical reference for the kinds of persistence mechanisms and evasion patterns that commonly create this problem.

Log evidence matters because persistence is often discovered indirectly. If activity continues after a cleanup action, you need records that show when the durable access path was created, which identity controls changed, and whether the attacker touched adjacent systems while establishing the foothold. NHIMG’s Log Management and Retention Guide supports that investigation because retention and integrity determine whether the timeline can still be reconstructed.

Risk and Threat Considerations

Persistent access is risky because it makes compromise survivable. Even after the first secret is rotated, the attacker may retain an alternate route through standing privileges, forged sessions, or delegated access that was quietly added during the intrusion. That can extend dwell time, increase blast radius, and make remediation look complete when it is not.

Failure mechanism: The intrusion becomes durable when the attacker modifies identity state or authorization state instead of relying only on the original stolen credential. That can leave behind surviving accounts, tokens, grants, or sessions that are not removed by normal password hygiene.

Impact: The organisation may believe the incident is contained while the attacker still has legitimate-looking access. That creates re-entry risk, follow-on lateral movement, and a higher chance that cleanup misses the real persistence mechanism.

Practitioner Guidance

What to verify: Confirm whether revoking the original password or token actually breaks all access paths, including secondary factors, delegated grants, service credentials, and long-lived sessions. If any path still works, treat the account as compromised even if the primary secret was rotated.

Decision rule: If the attacker had enough time to alter account state, prioritise identity review and access-path inventory over narrow secret replacement. The cleanup target is not one credential, it is every durable mechanism that can reconstitute access.

Practitioner takeaway: Persistence changes incident response from “replace the secret” to “remove every surviving path back in,” because a valid-looking identity that was modified during compromise can remain dangerous long after the first credential is gone.

Related resources from NHI Mgmt Group

• What happens when an attacker uses Tomcat to establish persistence on both Windows and Linux systems?
• What happens when a threat actor gains access to cloud infrastructure and keeps using valid credentials?
• What happens when an attacker gets valid access to a private repository account?
• What happens when a Windows kernel vulnerability is exploited after an attacker already has valid access?