The Step After the Click: Five Persistence Primitives That Survive Your Response

Why the Persistence Step Is Underweighted

The standard post-compromise response is well rehearsed. Reset the password. Revoke the active sessions. Re-enroll MFA. Sign the user out across devices. Close the ticket when the next login looks clean. That sequence works against the threat it was designed for, which is a stolen password used by a stranger who needs to log in again to do anything.

Modern intrusion chains assume that response. They are built so the visible compromise — the AiTM session, the device-code redemption, the help-desk callback that ends in a remote-support window — is the moment the attacker establishes one or more persistence primitives whose continued operation does not require another login. The password reset succeeds. The next login looks clean. The persistence primitives keep working anyway.

This is the sixth handoff from [our earlier walkthrough of the durable shape of an intrusion](/articles/procedure-outlives-tooling-intrusion-shape) — the one defenders consistently underweight. It is underweighted because, by design, it does not generate the signals that trigger the response. The fast-use stage is loud. The persistence stage is quiet, and the artifacts it leaves are usually structured to look like normal configuration. The deep-dive below walks through the five primitive families that account for nearly all of the persistence we see in 2026 phishing-led intrusions, with examples drawn from our recent coverage and the practical question each primitive demands of a defender's audit lane.

1. Mailbox Rules and Message-Suppression Artifacts

The oldest persistence primitive on the list is still the most common because it is the cheapest. A mailbox rule that forwards finance-related mail to an external address, deletes replies from a vendor, or moves messages containing "wire" or "DocuSign" into RSS feeds gives an attacker continued visibility and continued ability to suppress the conversations that would expose them. It costs nothing, requires no software, and survives every credential-centric response in the standard playbook.

The 2026 wave we covered in [the hybrid M365 mailbox-rule abuse piece](/articles/mailbox-rule-abuse-hybrid-m365) is the canonical example. Investigators found forwarding and deletion rules created within minutes of the suspicious sign-in, then left untouched for weeks because the rules themselves did not generate the kinds of telemetry the IR team was watching. The compromised account's next login looked normal. The rule kept routing the finance team's reply traffic to the operator's inbox until a downstream business-process owner noticed a missing approval.

What makes mailbox-rule persistence durable is the gap between identity telemetry and mail-flow telemetry. Identity tells you the account is fine. Mail flow tells you a rule is silently rewriting the conversation. Few SOCs run a rule-diff against a known-good baseline as part of post-compromise cleanup; almost all of them run a session revoke. The persistence primitive is chosen accordingly.

The audit-lane question is simple: for every account involved in a credible compromise, what mailbox rules exist today that did not exist before the incident window? Anything new is a finding, regardless of how innocuous it looks. The corollary control is to alert on rule creation in real time, especially rules that forward externally, delete by keyword, or move messages out of the inbox.

2. OAuth Grants and Offline Refresh Tokens

OAuth changed the shape of persistence because it decoupled "the user is signed in" from "the app has access." A consent granted once, with offline-access scope, produces a refresh token that the third-party application can use to obtain new access tokens indefinitely — without prompting the user, without an MFA challenge, and without triggering the sign-in telemetry that anchors most identity programs.

[Our 2026 OAuth back-door piece](/articles/unmanaged-oauth-grants-saas-backdoor) covered this directly: a user authenticates normally, approves an app — often one the attacker controls, sometimes one the attacker has compromised — and leaves behind a delegated access path that continues to function without another password prompt. Microsoft has confirmed that existing grants remain in place until they are explicitly reviewed and revoked, which means tightening future consent policy does nothing about the grants already issued. The [follow-on detection brief](/articles/detecting-oauth-app-behavior-after-consent) and the [enterprise consent-governance walkthrough](/articles/oauth-consent-governance-microsoft-google) both make the same point from different angles.

The reason OAuth persistence is so effective is that it is structurally invisible to the login-centric instincts of most security programs. A refresh-token redemption does not look like a sign-in. It looks like an application going about its work. Even teams that audit consent at provisioning time often have no review cadence after that, and the [OAuth consent-debt research note](/articles/oauth-consent-debt-research-note) showed how quickly the inventory drifts from anyone's mental model of what is actually delegated.

A worked example: the [SaaS integration token blast-radius analysis](/articles/saas-integration-token-blast-radius-drift-lessons) traced an incident in which a token issued for a sales automation app retained access to a CRM tenant long after the human accounts associated with the original provisioning had been deprovisioned. The user lifecycle moved on. The grant did not.

The audit-lane question is: what grants exist in Entra and Google Workspace today that were not present in the last clean snapshot, and which of them carry offline-access, mail.read, files.read.all, or comparable broad scopes? Revoke first, justify later, especially where the publisher is unverified or the requesting app is unfamiliar to the account owner.

3. Session Reuse and Replayed Device Trust

The capture stage of a modern phishing chain rarely ends with a password. It ends with a session cookie, a refresh token, or a device-bound credential that the attacker can replay against the identity provider from their own infrastructure. Those primitives keep working until they are explicitly invalidated, and "explicitly invalidated" is a stronger claim than most response playbooks can make.

[The credential-kits / device-bound session-replay piece](/articles/credential-kits-device-bound-session-replay) covered the shift from password theft to token capture in detail. The [AiTM reverse-proxy detection brief](/articles/detecting-aitm-reverse-proxies-tls-cookie-page-tells) and the [Chrome device-bound session credentials brief](/articles/chrome-device-bound-session-credentials-defender-brief) are companion pieces; together they describe a 2024-to-2026 trajectory in which the attacker's expected output from a successful AiTM is a session artifact replayable for hours and a device-trust signal replayable longer.

Persistence here is partly a property of the protocol — a refresh token's lifetime — and partly a property of the response. Sign-out-everywhere invalidates the session, but only if the response actually runs it and only if the IdP enforces it on the refresh path. We have seen incident timelines in which a password reset was logged, the user was instructed to "sign out and back in," and the captured refresh token continued producing valid access tokens for the rest of the day because the explicit token-revocation step was missed.

The downstream form of this primitive is device-trust replay. If the attacker registered a device during the compromise window — many AiTM kits do this automatically as part of the conditional-access bypass — that device may continue to satisfy device-compliance policies until it is removed. The persistence primitive is not the session; it is the device record.

The audit-lane question is: for every compromised account, was every active session explicitly revoked, every refresh token explicitly invalidated, and every device registered during the incident window explicitly removed? Three separate verbs, three separate API calls, three separate audit findings if any one of them is skipped.

4. Remote-Management Agents as Signed Persistence

A particularly clean form of persistence skips the identity layer entirely. If the attacker can convince a user to install a legitimate remote-management agent during the workflow-transfer step — SimpleHelp, ScreenConnect, AnyDesk, Atera, Splashtop, MeshAgent, Quick Assist as the stepping stone, an unmanaged remote-support binary as the residue — the attacker no longer needs an account to come back. The agent calls home.

[The VENOMOUS#HELPER analysis](/articles/rmm-phishing-persistence-simplehelp-screenconnect) documented this directly: a phishing chain that delivers signed RMM software gives the attacker interactive access, file transfer, and hands-on-keyboard capability under software whose presence often resembles normal IT administration. The [Storm-1811 Quick Assist chain](/articles/storm-1811-teams-quick-assist-phishing-chain) and the [Silent Ransom Group help-desk piece](/articles/silent-ransom-group-in-person-helpdesk-law-firms) both end at the same primitive: a remote-control channel installed under a believable IT pretext.

A variant worth naming is management-plane abuse, where the persistence primitive is not a new agent but an existing one that has been pivoted. The [FortiClient EMS / EKZ infostealer piece](/articles/forticlient-ems-ekz-infostealer-management-plane-abuse) covered a case in which the management plane of a legitimate endpoint product became the deployment channel for attacker-controlled software. The persistence is the management relationship, not the binary.

What makes RMM persistence durable is that the response playbook for "user clicked a phishing link" usually does not include a software-inventory diff. The user's account gets reset; the agent on the workstation, which never needed the account, continues to operate.

The audit-lane question is: what remote-management software is installed on the user's workstation today that was not present in the last managed inventory snapshot, and for each instance, what management server is it connecting to? Application control on unapproved RMM products turns this from a hunt into a block.

5. Downstream Account Changes

The fifth family is the broadest and, increasingly, the most dangerous. Once an attacker has interactive access to an identity, they can modify the recovery and trust attributes of that identity so that the next response cycle does not actually remove them. The primitive is not session-bound or device-bound. It is policy-bound.

A non-exhaustive list of what this looks like in 2026 incidents:

- **MFA recovery methods.** A new phone number, a new authenticator, a new backup code set. The [phishing-resistant MFA recovery workflows research](/articles/phishing-resistant-mfa-recovery-workflows-research) covered why recovery flows are the soft underbelly of an otherwise hardened MFA program. After the reset, the user re-enrolls a clean factor. The attacker's recovery method, added during the original window, still works. - **Device registrations.** A new Entra-joined device, a new MDM enrollment, a new passkey on the IdP. The device is the persistence; the password no longer matters. - **Backup and recovery secrets.** The [Signal recovery-key phishing piece](/articles/signal-backup-recovery-key-phishing-support-impersonation) is the consumer example, but the enterprise version is the same: a recovery key, a tenant root-of-trust seed, a BitLocker recovery escrow, a cloud-IAM root account recovery email. The secret being captured is the one that overrides the response. - **SSO and IdP admin promotions.** [The Octo Tempest / Scattered Spider profile](/articles/octo-tempest-scattered-spider-phishing-actor-profile) and the [kali365 Okta / AWS multi-platform analysis](/articles/kali365-multi-platform-okta-aws-russian-cluster-expansion) both document operators who, given even brief privileged access, add a new federated admin, a new IdP, or a new trust to the tenant. The user account they originally compromised becomes irrelevant; the trust they planted survives every reset of every individual identity.

The reason this family is hardest to detect is that each change, on its own, looks like legitimate administrative activity. A new admin in Entra, in isolation, is a normal Tuesday. A new device on a user, in isolation, is what happens when someone gets a new laptop. The signal lives in correlation: the change happened during or shortly after a credible compromise window, on an account or tenant whose other artifacts say the operator was not the legitimate user.

The audit-lane question is the longest of the five: for every account and tenant involved in the incident, what recovery methods, registered devices, backup secrets, federated trusts, IdP admins, and conditional-access exemptions were created or modified during the incident window, and have all of them been reverted to the pre-incident state? In practice this requires a baseline that most organizations do not maintain. Building that baseline is the single highest-leverage change a program can make after this read.

A Unified Detection Lens

The five primitives look unrelated until you notice what they share. None of them depends on the attacker logging in again. All of them are configured during the operation and operate on their own afterwards. All of them are structured to look like normal configuration once they exist. And every one of them survives the response a defender is most likely to run.

The unified lens is to instrument for new standing access paths rather than for new session activity. The questions that detect persistence are diffs: what rules exist now that did not exist before, what grants exist now that did not exist before, what sessions and devices are trusted now that were not trusted before, what software is installed now that was not installed before, what recovery and admin and trust state exists now that did not exist before. A response playbook that does not run those five diffs is a playbook that defines "closed" as "the original symptom stopped."

The procedural lens from the [parent piece](/articles/procedure-outlives-tooling-intrusion-shape) applies cleanly here. The capture primitive will keep rotating — passwords, session cookies, refresh tokens, recovery keys, device codes. The persistence primitive will keep rotating — new mailbox-rule syntax, new OAuth scopes, new IdP federation surfaces, new RMM products. The five families above are the layer that has held steady for several years, and the audit lanes that catch them today are the audit lanes that will still catch them after the toolkit rotates next quarter.

Build the audit lanes. Close the ticket on the diff, not on the reset.