Token Theft Attacks
Token theft happens when an attacker steals the proof that a user has already signed in. After a successful Microsoft 365 sign-in, the user receives session tokens so they do not need to enter a password and MFA code for every click. If those tokens are stolen through phishing, malware, or a compromised device, the attacker may appear to be the already-authenticated user.
For small businesses, token theft is uncomfortable because it can bypass the simple mental model of MFA. MFA is still essential, but an active stolen session changes the problem: the question becomes whether the sign-in session should be trusted based on device health, location, risk, and ongoing behaviour.
What it means
A session token is like a temporary pass that says the user has already authenticated. Modern cloud apps rely on tokens because constantly re-prompting users would make normal work painful. Token theft abuses that convenience.
Attackers can steal tokens through phishing pages that sit between the user and Microsoft 365, malicious software on a device, unsafe browser extensions, or device compromise. Once a token is stolen, the attacker may not need the password again until the session expires or is revoked.
How it affects small businesses
A stolen token can let an attacker read email, access Teams chats, download files, or create mailbox rules while appearing to use a legitimate session. In a 5- to 50-person office, that can be difficult to spot because staff often move between office Wi-Fi, home networks, phones, and client locations.
For accountants, clinics, consultants, and law firms, the practical risk is unauthorized access to sensitive conversations and files. The attacker may quietly monitor messages, wait for a payment conversation, and then act at the right moment.
MFA fatigue is not the only issue
Even strong MFA can be sidestepped if a valid session token is captured after authentication.
Device trust becomes important
A compliant, managed device gives better assurance than an unknown browser on an unmanaged computer.
Session revocation matters
Changing a password may not immediately end every cloud session unless tokens are revoked.
How the attack usually starts
Token theft usually starts after a user interacts with a phishing page, malicious browser extension, compromised device, or phishing proxy. The user may complete a legitimate-looking Microsoft 365 sign-in and MFA prompt, but the attacker captures the active session token created after authentication.
The important point for a small business is that the attacker may not need to know the password again. They try to reuse the already-authenticated session until it expires, is revoked, or is blocked by device, risk, or session controls.
Phishing proxy
A fake sign-in flow relays authentication and captures the resulting session.
Compromised endpoint
Malware or suspicious tooling can target browser session data and saved credentials.
Unsafe browser extension
Extensions with broad permissions can create unexpected exposure around browser sessions.
What attackers are trying to achieve
Bypass repeated MFA prompts
A stolen session can let the attacker appear already authenticated.
Access email and files quietly
The attacker may read mail, download files, or create rules without triggering a new password prompt.
Maintain access long enough to act
The practical goal is often invoice fraud, internal phishing, or data review before the session is revoked.
What it looks like in a real small business
A 35-person consulting firm receives a fake Microsoft shared-document email. A project manager signs in and approves MFA. A few hours later, the same account shows activity from an unfamiliar browser session outside the normal device pattern.
The user insists they did not share their password, and that may be true. The useful response is to revoke sessions, reset credentials, check mailbox rules, review endpoint alerts, and tighten Conditional Access for unmanaged devices and persistent sessions.
Common warning signs
Successful sign-ins from unusual browsers or locations
Watch for sessions that do not match the user, device, or expected working pattern.
MFA completed but activity still looks wrong
A user may have completed MFA on a phishing proxy while the attacker captured the resulting session.
New inbox rules or file downloads after a suspicious login
Post-login actions often reveal more than the login event itself.
Endpoint alerts around browser credential storage
Malware or suspicious tools touching browser data should be treated as identity risk, not only endpoint risk.
Signals to check
Sign-in session details
Review device, browser, IP, country, user agent, and whether the session came from a managed or unmanaged device.
MFA timing
Compare the MFA approval time with the suspicious session and any phishing report from the user.
Mailbox and file activity
Check inbox rules, forwarding, downloads, SharePoint access, and unusual sent mail after the session began.
Endpoint telemetry
Look for browser credential access, suspicious extensions, info-stealer indicators, or unusual process activity.
What to do first
Revoke active sessions
Terminate refresh tokens for the suspected user so stolen sessions cannot continue silently.
Reset password and MFA methods
Change the password and review registered MFA devices, phone numbers, and recovery details.
Inspect the endpoint
Treat token theft as both an identity and endpoint issue until the device is verified clean.
Review access after the suspicious session
Identify mail, files, apps, and rules touched while the attacker may have had access.
How to reduce the risk
Use Conditional Access session controls
Require reauthentication for risky sessions, limit persistent browser sessions, and apply stricter rules to unmanaged devices.
Require compliant or trusted devices for sensitive access
For admin, finance, and client-data workflows, device compliance reduces the chance that unknown endpoints can carry valid sessions.
Monitor sign-in risk and user risk
Microsoft risk signals can help identify sessions that deserve step-up authentication or blocking.
Protect endpoints with EDR or MDR
Endpoint monitoring helps detect malware, suspicious browser activity, and credential theft behaviour.
Revoke sessions during account response
When an account is suspected compromised, revoke refresh tokens in addition to changing passwords and reviewing MFA methods.
Common mistakes
Assuming MFA means the session is safe
MFA is essential, but active session theft is a different problem than password guessing.
Only changing the password
Password resets may not immediately end every active session unless tokens are revoked.
Ignoring unmanaged devices
Unknown browsers and personal devices make session trust harder to assess.
Separating endpoint and identity alerts
Browser credential theft on a device can explain suspicious Microsoft 365 sessions.
CtrlShift IT review checklist
In a security risk review, we focus on the operational checks that show whether the control is actually working for a small business, not just whether a setting exists.
Session revocation readiness
We confirm administrators can revoke sessions, reset MFA methods, and preserve investigation data.
Conditional Access session controls
We review sign-in frequency, persistent sessions, unmanaged devices, and risk-based policies.
Endpoint protection coverage
We check whether EDR/MDR covers the user device and records browser or credential theft signals.
Mailbox and file audit review
We inspect rules, downloads, forwarding, SharePoint activity, and sensitive file access.
User reporting workflow
We verify users know how to report suspicious sign-ins, prompts, and document links quickly.
FAQ
Can token theft bypass MFA?
It can bypass the need for a new MFA prompt if the attacker successfully steals an already-authenticated session. MFA is still critical, but session controls, device trust, and token revocation are also needed.
Should I reset the password after token theft?
Yes, but do not stop there. Revoke sessions, review MFA methods, inspect mailbox rules, and check the endpoint that may have exposed the token.
How does Conditional Access help with token theft?
Conditional Access can restrict unmanaged devices, require compliant devices for sensitive access, control persistent sessions, and respond to risky sign-ins.
Can token theft happen on a clean Microsoft 365 tenant?
Yes. Token theft can start from phishing or endpoint compromise even when tenant settings are reasonable. The goal is to reduce likelihood and improve detection.