Why “reset the password” isn’t enough for token theft
Token theft (AiTM phishing, session-cookie replay, refresh token abuse) breaks the mental model many SMBs still use for account compromise. If an attacker already has a valid session token, they can keep working in Microsoft 365 even after you change the password—until you explicitly evict sessions and remove any persistence they set up.
This drill is built for NYC SMBs that already run MFA and still worry about session hijacking. It’s time-boxed, role-based, and ends with proof you can hand to leadership, insurance, or a security questionnaire.
What this drill assumes (and what to do if you lack it)
You’ll move fastest if you have access to Microsoft Entra ID (Azure AD) admin roles and Microsoft 365 audit logs. If you don’t, your first decision point is whether you can safely contain within your current plan—or whether to escalate immediately.
Minimum tools and access
- An account with appropriate admin rights (at least to disable users, revoke sessions, review sign-in logs)
- Access to Microsoft 365 Defender / Entra sign-in logs (license-dependent)
- Ability to isolate or remove a device from access (Intune if you have it; otherwise local IT actions)
If you’re missing logs or admin rights
If you can’t view sign-in logs or revoke sessions, you can still reduce harm by disabling the user and resetting credentials, but you won’t be able to confidently prove eviction. In that case, treat this as a “stop the bleeding + escalate” event.
Roles: who does what in the first hour
The fastest containments aren’t “one admin doing everything.” Assign roles before you start, even if one person wears two hats.
Business owner / leadership (decision authority)
They decide whether to temporarily disable an executive’s account, approve user downtime, and trigger cyber insurance notification if required. They also own communications to clients/vendors if email was used to send messages.
IT admin (containment operator)
They execute the technical steps: revoke sessions, kill persistence, isolate devices, and capture evidence. They coordinate with the help desk and document timestamps.
Help desk / office manager (user coordination)
They handle the human logistics: getting the user off devices, collecting screenshots of suspicious prompts, and pausing outbound email activity. They can also guide the user through re-enrollment steps after containment.
The 60-minute clock: decisions and actions by time block
This section is designed to be run like a drill (or used live). Use the time blocks, but don’t let the clock override safety—if you see active exfiltration, move to the strongest containment immediately.
0–10 minutes: classify and freeze
In the first 10 minutes, your goal is to stop additional attacker actions and preserve evidence. Don’t start by “cleaning up everything” if you’ll lose visibility.
Triage questions (answer fast)
- Is the user reporting repeated MFA prompts, “unusual sign-in” alerts, or redirected login pages?
- Do sign-in logs show unfamiliar locations, impossible travel, unfamiliar device IDs, or multiple failures then success?
- Did someone approve an MFA prompt they didn’t initiate?
Immediate freeze actions
- Tell the user: stop using email, Teams, OneDrive, and Outlook on all devices.
- If you suspect the user’s workstation is compromised: disconnect it from the network (or isolate via Intune/Defender if available).
10–25 minutes: contain access (account + sessions)
This is where token theft differs from password theft. You’re separating “account reset” from “session eviction.”
Decision point: disable the user or not?
If you see active sending rules, suspicious OAuth apps, or ongoing sign-ins, disable the account temporarily. If it’s a high-impact mailbox (finance, exec, shared mailbox access), disabling buys you breathing room.
Perform session eviction
In Microsoft Entra admin center for the user:
- Revoke sign-in sessions (this targets active sessions)
- Revoke refresh tokens / require reauthentication (wording varies by portal)
In Microsoft 365 (where applicable):
- Sign out of all sessions for Microsoft 365 apps (if your portal offers it)
25–45 minutes: kill persistence (the things that let them come back)
Token theft incidents often include “persistence” so the attacker can regain control even after eviction. Your job is to remove those footholds.
Check and remove malicious inbox rules and forwarding
In Exchange admin / mailbox rules:
- Look for rules that auto-forward, delete, move to RSS/Archive, or mark as read
- Remove unexpected forwarding addresses (especially external)
- Check “Send As” / “Send on behalf” permissions changes
Check for suspicious OAuth app consents
In Entra ID:
- Review enterprise applications with recent consent for the user
- Remove user consent / revoke app permissions for unknown apps
- If you allow user consent broadly, consider temporarily restricting it during cleanup
Validate MFA methods and registration
In Entra ID user authentication methods:
- Remove unfamiliar phone numbers, authenticator registrations, or FIDO keys
- Force re-registration if there’s any doubt
Reset credentials the right way (after eviction)
Do password reset *after* session revocation when possible. Then enforce reauthentication and confirm the user re-enrolls in MFA from a known-clean device.
45–60 minutes: prove they’re out (and build your evidence pack)
Containment isn’t complete until you can validate re-entry attempts fail and you’ve captured defensible records. This is where many SMBs struggle when insurance or clients ask, “What exactly did you do?”
Validation steps (pick at least two)
- Confirm sign-in logs show revoked sessions followed by new interactive sign-ins only from expected locations/devices
- Confirm no new external forwarding is present and no new suspicious rules appear after cleanup
- Confirm the attacker’s suspicious IP/user agent stops appearing after session revocation
- Attempt a controlled login from the user on a clean device; confirm MFA prompts match expected behavior
- Timeline with timestamps (first alert, user frozen, account disabled, sessions revoked, password reset)
- Screenshot/export of sign-in log entries around the incident
- Screenshot/list of inbox rules removed and forwarding settings before/after
- List of OAuth apps reviewed/removed and consent changes
- MFA method changes (what was removed, what was re-registered)
- Device actions taken (isolated, wiped, password changed, reimaged)
Step 1: Evict sessions fast (your “token theft” lever)
This step is the heart of token theft containment. You’re invalidating the attacker’s ability to keep using what they already stole.
Keep notes on exactly which “revoke” actions you used, because different portals use slightly different language. What matters is: active sessions and refresh tokens are no longer valid.
Step 2: Remove persistence (mailbox, apps, MFA, and privilege)
Attackers who know what they’re doing won’t rely on a single session. They’ll add a forwarding address, approve an OAuth app, or manipulate MFA methods so they can re-enter.
Treat this like a checklist, not a hunch. If you only reset the password, you may stop the current login but keep the backdoor.
Step 3: Validate and document (so you can answer “are we safe now?”)
Validation is both technical and operational: you need confidence the attacker can’t re-enter, and you need artifacts you can share without digging through portals under pressure.
If you can’t validate due to missing logs or licensing, document that limitation explicitly and consider engaging outside incident support. “We revoked sessions” is stronger when paired with “and here’s what the sign-in logs showed afterward.”
NYC SMB specifics: common constraint-driven choices
NYC SMBs often have lean IT and mixed device fleets. Here are practical decision shortcuts that work when time and tooling are limited.
If the user is finance, payroll, or exec
Disable the account immediately, revoke sessions, and isolate the device. The business impact of downtime is usually lower than the impact of fraudulent payments or credential reuse.
If you don’t have Intune/managed devices
You can still contain by revoking sessions and resetting credentials, but treat the endpoint as suspect. Have IT check for browser credential theft, suspicious extensions, and malware; reimage if you can’t confidently clean it.
If email was used to message clients/vendors
Containment isn’t only technical. Leadership should prepare a short statement, preserve sent items and headers, and be ready to notify affected parties if requested by counsel/insurance.
Key Takeaways
- Token theft requires session eviction, not just a password reset.
- Run containment in parallel: freeze the user, revoke sessions, remove persistence, then validate.
- Persistence commonly hides in inbox rules/forwarding, OAuth app consents, and MFA methods.
- Finish the hour with an evidence pack: what was revoked, when, and what logs show afterward.
Frequently Asked Questions
Do I really need to disable the user account?
Not always, but it’s the fastest “circuit breaker” when you suspect active misuse. Many teams disable temporarily, revoke sessions, remove persistence, then re-enable with fresh credentials and MFA re-registration.
What’s the difference between changing a password and revoking sessions?
A password change affects future authentication attempts. Revoking sessions/refresh tokens invalidates existing tokens so an attacker can’t keep using a stolen session cookie or refresh token.
How do I know whether this was token theft or just a leaked password?
Repeated MFA prompts, suspicious “new device” logins, and successful sign-ins that don’t align with password reset timing can indicate token/session abuse. In practice, you contain the same way: revoke sessions, then clean persistence.
What should I capture for insurance or a client security questionnaire?
Capture a timeline, sign-in evidence (screenshots/exports), what you revoked (sessions/tokens), what you removed (rules/forwarding/apps/MFA methods), and your validation results showing the attacker stopped attempting or failing re-entry.
After containment, what’s the next best control to reduce recurrence?
Prioritize phishing-resistant authentication (FIDO2/security keys or certificate-based methods), tighten Conditional Access, and reduce user OAuth consent. But run this drill first—because even good controls don’t eliminate all token theft scenarios.
Take the Next Step
If you want, we can turn this drill into a one-page runbook tailored to your Microsoft 365 tenant: who clicks what, what to screenshot, and how to store the evidence pack so it’s ready under pressure. For NYC SMBs, we can also run a tabletop session with your leadership and IT team to test timing, permissions, and escalation paths before a real incident hits.