> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session Token Theft Response

> An account shows malicious activity even though MFA passed and the password looks fine — a stolen session cookie or token is in play, so revoke sessions and tokens, not just the password.

<Info>
  **Category:** Security · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/security/session-token-theft-response/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response, Risk & Compliance

**When to use:** Malicious or anomalous activity on an account where sign-in logs show MFA succeeded and no password change explains it; a user's session appears active from an unfamiliar IP/device while the user is elsewhere; or post-phishing where the lure harvested a session (adversary-in-the-middle / token-replay), not just credentials.

**Run it:** on one ticket (a suspected stolen-session case).

## Prompt

```
The tell is a paradox: confirmed malicious activity on an account whose MFA was satisfied
and whose password nobody reset recently. That is a stolen session token or cookie — an
attacker replaying the user's already-authenticated session, sailing past MFA because the
session already cleared it. The fix a password reset alone will not deliver: kill the
sessions. You drive and document; the client's admin performs the tenant-side revocation.
Work it in order:

1. Recognize the pattern before acting: MFA-satisfied sign-in + malicious activity + no
   plausible password compromise = session/token theft until proven otherwise. Capture the
   anomalous session's IP, device, and timestamps.
2. Revoke first, and revoke the right thing: invalidate all active sessions AND refresh
   tokens for the account — this is what evicts the attacker. A password reset alone does
   NOT kill an already-issued session; the stolen cookie stays valid until the session is
   explicitly revoked.
3. Then rotate the password too — the harvest that produced the token may have taken the
   credential as well — and re-verify MFA (remove any attacker-registered method).
4. Look for persistence the attacker planted during the live session: inbox rules and
   forwarding (inbox-rule-alert-runbook for the full sweep), OAuth app consents
   (oauth-consent-grant-abuse), delegates/send-as. Token theft buys a window; attackers use
   it to plant durable access.
5. Trace the source: if this came from a phishing message, run email-header-analysis and
   treat other recipients as potentially hit by the same token-stealing lure. If fraud was
   sent from the account, branch to business-email-compromise-recovery.
6. Assess blast radius and run the account-takeover-runbook sweep for anything the session
   touched.
7. Document the decision, not just the action: the MFA-passed-yet-malicious evidence, exactly
   what was revoked (sessions + tokens) and when, what persistence was found, and the
   root-cause hypothesis. Classify per soc-classification-tree.

Guardrails — always:
- The core rule: revoke sessions and tokens, not just the password. If your remediation is
  only a password reset, the attacker is still in.
- Session/token revocation is a tenant-side action owned by the client's admin — recommend,
  drive, and document; never hold credentials or flip the setting yourself.
- MFA passing does NOT clear the account — replayed sessions are pre-authenticated. Do not
  treat "MFA succeeded" as evidence of legitimacy here.
- Always check for planted persistence — a revoked session with a live forwarding rule or
  OAuth grant is not remediated.
- Defensive writing: "an unauthorized session was detected and revoked," not "you were
  hacked"; do not assert data was accessed without log evidence. Plain text only. When in
  doubt, revoke and re-verify.
```


## Related topics

- [Lost or Stolen Device Response](/skill-library/security/lost-stolen-device-response.md)
- [Business Email Compromise Recovery](/skill-library/security/business-email-compromise-recovery.md)
- [WatchGuard Firewall Alerts](/skill-library/vendor-runbooks/watchguard-firewall-alerts.md)