Identity-persistence sweep

About 13 min read

On this page

A password reset is the move everyone reaches for when an account looks taken, and it ends less than it seems to. An attacker who held an identity for ten minutes had time to plant anchors that outlive the new password: an authenticator app of their own, a registered device, a consented application, a rule that hides the replies. This page is the identity-persistence sweep Identity-Persistence SweepASSURED term In ASSURED, the read-only checklist run on any identity an attacker held or may have held: sessions and refresh tokens, MFA methods, registered devices, OAuth grants, mailbox rules and forwarding, delegated access, federation trust and new service principals. Finding an anchor is triage; removing it is containment. See Identity-persistence sweep. : the checklist for finding them, where each one is logged in Microsoft Entra ID, Okta and Google Workspace, and the order that removes them without destroying the evidence.

The sweep is a read-only inventory. Finding an anchor is triage; removing it is containment, under the pre-authorized actions list. The worked thread is Case C, the replayed session on the mail tenant, in the Alert, Scope and Uncover examples.

When to run it

Run it on every identity that was, or may have been, in attacker hands:

• Session theft or replay, confirmed or suspected: adversary-in-the-middle phishing AiTM Phishing Adversary-in-the-middle phishing: a kit proxies the real login page, so the victim completes their own password and MFA prompts while the proxy captures the resulting session cookie. , a replayed cookie, a device-code sign-in the user did not start (see identity attacks at protocol depth).
• Credential exposure at a phishing kit: the rule in the callout below.
• An infostealer on a host: infostealers Infostealers Software that harvests sensitive data from victims: passwords, session cookies, browser history, autofill, crypto wallets. The resulting logs are sold in bulk and are a leading source of the valid credentials and session tokens used for initial access. read the whole browser cookie store, so every session in that profile is presumed stolen. Case A treats both finance users as credential-exposed Credential-ExposedASSURED term In ASSURED, the status of any user who reached the credential step of a phishing kit. They stay credential-exposed until the password is reset, sessions are revoked and MFA methods are reviewed; stopping at the MFA prompt rules out session theft, not credential theft. See Identity-persistence sweep. Full entry: ASSURED terms. for this reason.
• An MFA reset or new method the user did not ask for: especially after a help-desk call, the signature move of Scattered Spider Scattered Spider Native-English-speaking group behind the 2023 MGM and Caesars intrusions and the defining identity-attack playbook: help-desk social engineering, SIM swapping, MFA fatigue, AiTM phishing kits, then abuse of the victim's own identity provider (IdP) and cloud tooling. It overlaps with the loose "The Com" ecosystem and later partnered with RaaS operations for encryption. In April 2025 it hit UK retail (M&S, Co-op, Harrods); at M&S, DragonForce's encryptor was deployed on VMware ESXi hosts. UK arrests followed in July 2025. U.S. prosecutors charged Thalha Jubair over at least 120 intrusions and $115M in ransoms, and in July 2026 Jubair and Owen Flowers were sentenced in the UK for the 2024 Transport for London hack. The NCA says the action effectively halted the group, but its playbook (help-desk resets, MFA re-registration, hypervisor encryption) is widely copied. The actor profile most relevant to single sign-on (SSO) era triage. .
• A follow-on artifact found first: a consent to an unverified app, a hiding inbox rule Inbox Rule A mailbox rule that moves, deletes, marks read or forwards messages. Attackers add rules that hide replies and security notices (ATT&CK T1564.008, Email Hiding Rules) or forward mail outside (T1114.003, Email Forwarding Rule). See Identity-persistence sweep. , external forwarding. A session acted, so sweep the identity behind it.

A privileged identity changes the depth, not the checklist. It always fails the Level 0 eligibility gate Eligibility GateASSURED term In ASSURED, the three checks a case's subject must pass before a Level 0 close, each proven from its source system: not a crown-jewel asset; not a privileged identity, and not automation with deploy, signing, secrets or repository-write capability; no regulated data in reach. Unknown fails the gate. A failed item moves the case up the ladder, and a crown-jewel subject or privileged identity goes straight to Level 2. See the fast path. Full entry: ASSURED terms. and routes to Level 2 (see the depth ladder), and the sweep must cover the tenant-level objects it could change: federation, roles, application credentials. If the sweep confirms an escalation criterion, the escalation tripwire Escalation TripwireASSURED term ASSURED's rule that a confirmed escalation criterion escalates immediately, from any phase, and makes the case P1 whatever its matrix cell. Confirmed means supported at High confidence on the shared confidence rubric; suspicion refines Scope and re-runs the loop instead. Always written with "escalation", because Tripwire is also a file-integrity product. Formerly called the break-glass rule. See Escalation criteria. Full entry: ASSURED terms. fires from whatever phase you are in, and the rest of the sweep runs as IR-assigned scoping support.

The window. Start at the earliest possible exposure (lure delivery, the first attacker sign-in, the infostealer’s first run) and look back 14 to 30 days on the affected identities, because these artifacts can predate the alert (see time boundaries). Keep the forward window open until containment is verified. Sweep two ways: per identity, for every exposed account, and tenant-wide, by the attacker’s fingerprints (source IPs and ASN, the application ID, the rule’s shape), as Case C’s Scope did.

The checklist

Eight places an attacker leaves a way back in. For each: what survives a password reset, the shape an attacker leaves, and the ATT&CK technique.

1. 1. Sessions and refresh tokens

   What survives: it depends on the identity provider and on how the reset is done. On Microsoft Entra ID, a refresh token is valid until it is revoked or goes unused for 90 days; already-issued access tokens stay valid until they expire unless continuous access evaluation is enforced for that app; sessions that a SaaS application issues itself are outside the identity provider’s reach; and app passwords App Password A legacy per-application password for clients that cannot do modern authentication or MFA. On Microsoft Entra ID a password reset does not revoke it, so the sweep lists and removes app passwords explicitly. See Identity-persistence sweep. are not revoked by a password reset at all. Okta’s session revocation does not clear sessions created for web or native apps either.

   Attacker shape: one session ID seen from more than one network; non-interactive sign-ins from an ASN the user never used; tokens issued to apps the user never opens.

   ATT&CK: T1539 Steal Web Session Cookie and T1550.004 Web Session Cookie for the theft and replay; T1528 Steal Application Access Token.

2. 2. MFA methods

   What survives: all of it. A method the attacker registered satisfies the next MFA prompt and, where self-service password reset is enabled, can reset the new password too.

   Attacker shape: an authenticator app, phone number or passkey registered within hours of a risky sign-in, from the attacker’s IP, or minutes after a help-desk call; a changed default method; a method an admin registered with no ticket behind it.

   ATT&CK: T1098.005 Device Registration Device Registration Registering an attacker-controlled device to a compromised account so access survives a password change: as a new MFA method (an authenticator app or phone number), or as a registered or joined device in the identity provider or MDM, which can satisfy device-based Conditional Access and, in Microsoft Entra ID, obtain a Primary Refresh Token. Storm-2372 and Scattered Spider have both used it. An ATT&CK Persistence technique. , which covers enrolling a device in an MFA system.

3. 3. Registered and joined devices

   What survives: the device. In Entra ID a registered device can hold a Primary Refresh Token Primary Refresh Token (PRT) A long-lived token Microsoft Entra ID issues to a registered device at sign-in, used to get access tokens for apps without prompting again. A stolen PRT, or a session cookie derived from one, lets an attacker sign in as the user and can satisfy device-based Conditional Access. Revoking sessions, not only resetting the password, is what invalidates it. and can satisfy device-based Conditional Access, which is why Microsoft’s emergency guidance disables the user’s devices as well as the account.

   Attacker shape: a device registered from attacker infrastructure, or a device-code sign-in through the Microsoft Authentication Broker followed by a registration; in Okta, an Okta Verify enrollment on a new device.

   ATT&CK: T1098.005 Device Registration.

4. 4. OAuth grants and app consents

   What survives: the grant. A password reset never removes a consent grant OAuth Consent Grant (Illicit Consent) A user's or admin's approval that lets a third-party application act on their data with the permissions (scopes) it requested, such as Mail.Read and offline_access. Attackers abuse it by luring users into consenting to a malicious app (consent phishing), which gives API access that survives a password reset and MFA. Triage: check the publisher's verification, the scopes, and the consent event in the audit log. Revoking the grant is a non-reversible step that needs IR or owner approval unless the protocol pre-authorizes it. ATT&CK T1528. . Removing it means deleting the delegated grants and any app-role assignments, or disabling the app’s service principal Service Principal In Microsoft Entra ID, the tenant-local identity of an application. It signs in with a client secret, a certificate or a federated credential and holds delegated or application permissions; disabling it blocks the app's sign-in. See Non-human identities and cloud roles. , then blocking re-consent. In Google Workspace, removing an app’s access is temporary: the user can grant it again unless the app or its scopes are blocked.

   Attacker shape: an unverified publisher, a multi-tenant or newly registered app, scopes such as Mail.Read with offline_access, and a consent made from the replayed session.

   ATT&CK: T1528 Steal Application Access Token; T1671 Cloud Application Integration when the consent is persistence.

5. 5. Mailbox rules and forwarding

   What survives: every rule and every forwarding setting. They belong to the mailbox, not to the sign-in.

   Attacker shape: a one-character rule name; conditions on “invoice”, “payment” or “bank”; actions that move messages to RSS Subscriptions, Archive or Deleted Items and mark them as read; forwarding to an external address. Rules can be hidden from Outlook and most admin views, so list them with the hidden ones included.

   ATT&CK: T1564.008 Email Hiding Rules; T1114.003 Email Forwarding Rule.

6. 6. Delegated access

   What survives: permissions granted to another account. The attacker keeps reading through the delegate after the victim’s account is locked down.

   Attacker shape: full-access, send-as or folder permissions granted to another compromised account, or to an account created in the window.

   ATT&CK: T1098.002 Additional Email Delegate Permissions.

7. 7. Federation and tenant trust changes

   What survives: the trust itself, for every user in the tenant. An attacker with admin rights who adds a federated domain or a new identity provider can mint sign-ins without touching any password (see federation and tenant trust abuse).

   Attacker shape: a new or changed domain authentication setting, a new token-signing certificate, a new identity provider or routing rule, a new cross-tenant partner.

   ATT&CK: T1484.002 Trust Modification; T1606.002 SAML Tokens for the forging that follows ( Golden SAML Golden SAML Forging SAML tokens with a stolen federation token-signing key, such as an AD FS token-signing certificate. The attacker can then sign in to any service that trusts the key, as any user and with any claims, without a password or MFA, and resetting user passwords does not stop it. CyberArk named the technique in 2017; APT29 used it in the SolarWinds campaign. ).

8. 8. New service principals, app credentials and roles

   What survives: a non-human identity the attacker controls. A secret added to an existing application signs in as that application, with its permissions, regardless of what happens to the user.

   Attacker shape: a new service principal or OAuth client, a secret or certificate added to an existing app, an owner added to an app, a role assigned, an API token minted.

   ATT&CK: T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles; T1136.003 Cloud Account.

Where to look: Entra ID, Okta and Google Workspace

The names below are the audit activity and event-type strings each platform logs. Read the current state as well as the history: the audit log shows that a method or a grant was created, and the object shows what it looks like now.

Retention decides whether the sweep can answer at all: if the window reaches past the console’s retention, run it against the SIEM copy and say so (see typical default retention). Lag matters too. A Google OAuth event can take hours to appear, so a “none” five minutes after the incident is a result with a timestamp, not a final answer.

A starting query in Microsoft Sentinel: every persistence-shaped change made by, or to, one account in the last 30 days.

let target = "rvega@corp.example";
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("User registered security info", "Admin registered security info",
    "User changed default security info", "Register device", "Add registered owner to device",
    "Consent to application", "Add delegated permission grant",
    "Add app role assignment to service principal", "Add service principal",
    "Add service principal credentials", "Add owner to application", "Add member to role",
    "Set domain authentication", "Set federation settings on domain")
    or OperationName has "Certificates and secrets management"
| extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
         ActorIP = tostring(InitiatedBy.user.ipAddress),
         Target = tostring(TargetResources[0].userPrincipalName)
| where Actor =~ target or Target =~ target
| project TimeGenerated, OperationName, Actor, ActorIP, Target, Result, CorrelationId
| order by TimeGenerated asc

Run it a second time without the last where on the account and with ActorIP filtered to the attacker’s addresses: that is the tenant-wide half of the sweep. The mailbox half runs in the unified audit log on the operations in the table above.

Order of operations

The sweep and the containment it feeds run in a fixed order: the order Case C ran, and the one preserve before you contain sets for every action.

1. Check the tripwire first. If an escalation criterion is confirmed (supported at High confidence on the confidence rubric), page IR now, on a channel the attacker cannot read (see out-of-band communication).
2. Preserve. Export the sign-in records (interactive and non-interactive, with session IDs) and the audit log for the window, and snapshot what later steps will remove: MFA methods and devices, grants and the app’s service principal, rules and forwarding, delegates. Hash the exports and write the custody record. Minutes, not an hour.
3. Run the reversible, pre-authorized actions. Disable the account, then revoke all sessions and refresh tokens, which is Microsoft’s emergency order. In Okta, clear the user’s sessions with the option that also revokes OAuth tokens. In Google Workspace, reset the sign-in cookies, after ending the session at any third-party identity provider, which could sign the user straight back in. Disable the app’s sign-in; disable (not delete) the rules.
4. Verify, do not assume. The check is the attacker’s next presentation, refused, with its time. Already-issued Entra ID access tokens live 60 to 90 minutes by default; continuous access evaluation, where the app supports it, enforces revocation in near real time, with up to 15 minutes of propagation. Sessions a SaaS app issued itself need that app’s own revocation.
5. Take the non-reversible steps with IR’s or the owner’s approval. Unless the protocol pre-authorizes them for the scenario, these wait: reset the password (on a hybrid account, in Active Directory, where Microsoft advises resetting twice); remove the attacker’s MFA methods and devices; delete the grants and app-role assignments, keeping the service principal disabled; remove added delegates, roles and app credentials; delete app passwords, which a reset does not revoke.
6. Re-enroll through a verified channel. The account stays disabled until IR clears it, and the user re-registers MFA after verification out of band (a call-back Call-Back Verification Confirming a caller or an instruction by calling a number you looked up from a trusted source, never the number supplied in the contact. See Talking to people during triage. to a number from the directory), never on a request that arrives through the compromised mailbox or chat.
7. Re-sweep once any access token issued before revocation has expired and the slowest logs have caught up. Anything new is a failed containment, and it goes to IR at once.

What to record

Record every checklist item, each line with its source, window, query time and result. A recorded negative (“MFA methods: one, the user’s own; none registered in the window; AuditLogs, 30 days, queried 10:14 UTC”) is a finding. An item not checked is a gap, and unknown is not low: it goes in the open questions, not down as “clean”. In the handoff packet, the preservation steps and removals go in section 6, the hashed exports in section 7, and anything unswept in section 8.

Case C, recorded this way

Uncover ran Case C’s tenant sweep once, over 14 days and all users, as Scope bounded it. Found: one consent grant to the “Mail Backup Sync” app ID and one hiding inbox rule, both on rvega’s mailbox, both made from the replayed session. None: forwarding rules, added delegates, MFA methods or devices registered from either attacker IP. One more exposed identity: the second click-through user, sessions revoked at 09:41, password reset and MFA methods reviewed at 09:44 with IR’s approval. rvega’s own review at 09:40 found only her own method. Those recorded negatives make “one account taken, one more exposed and reset, nothing else” a defensible claim instead of a hope. The full timeline is in the Escalation decision example.

Check yourself

At 02:10 UTC the help desk resets a sales manager’s MFA after a caller passes the identity questions. At 02:14 a new authenticator app is registered on the account from a residential proxy. At 02:20 the account signs in from a new device and consents to a file-sync app. The callback number on the ticket is not the manager’s. What do you sweep, in what order, and what is a password reset worth here?

One way to answer

The registration and the consent are follow-on activity from attacker infrastructure on an account the attacker reset into, and nothing contained it: that is a confirmed criterion, so the escalation tripwire fires and IR is paged out of band. The help-desk ticket is evidence (who called, from what number, how the caller was verified). Preserve first: sign-in and audit records from the reset onward, the MFA methods, the new device, the app’s grant and service principal. Then disable the account, revoke all sessions and refresh tokens, disable the app’s sign-in, and verify that the next attempt from the proxy is refused. With IR’s approval, remove the attacker’s authenticator and device, delete the grant, and reset the password. Sweep all eight items, not only the two you can see, and go tenant-wide by the proxy’s IP and the app ID: a caller who got through the help desk once may have called about other users. On its own, the reset is worth little: the attacker’s authenticator satisfies the next MFA prompt, and the grant keeps reading files.

Sources

• Microsoft Learn, Revoke user access in an emergency in Microsoft Entra ID (updated June 2026): disable the account, revoke refresh tokens, disable the user’s devices; Entra ID cannot revoke session tokens an application issued itself. Configurable token lifetimes (updated June 2026): access tokens default to a random 60 to 90 minutes; refresh tokens last until revoked, with a 90-day inactivity limit.
• Microsoft Learn, Respond to a compromised email account in Microsoft 365 (updated August 2026): app passwords survive a password reset; review MFA methods and devices, consented apps, roles and forwarding; list hidden inbox rules.
• Microsoft Learn, Continuous access evaluation (updated September 2026), Microsoft Entra audit log activity reference (updated June 2026), and Audit log activities (updated October 2026).
• Okta, Event types and User Sessions API (both checked October 2026).
• Google, Data retention and lag times and Manage a user’s security settings (both updated October 2026); Admin SDK Reports API, Login and OAuth Token activity events (checked October 2026).
• MITRE ATT&CK, T1098.005 Device Registration, T1671 Cloud Application Integration and T1114.003 Email Forwarding Rule (ATT&CK v19, checked October 2026).