Successful sign-ins from unusual browsers or locations
Watch for sessions that do not match the user, device, or expected working pattern.
Identity security guide
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.
The explanation
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.
Warning signs
Signals to watch for
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.
Reduce risk
First controls to put in place
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.
What we look at during a review
When we assess identity security, these are the specific areas we check against your actual Microsoft 365 tenant.
Session and token response process
We confirm administrators know how to revoke sessions, reset MFA methods, and verify recovery details.
Conditional Access session posture
We review persistent sessions, unmanaged device access, sign-in frequency, and risk-based controls.
Endpoint and identity correlation
We compare endpoint alerts with Microsoft 365 sign-ins so device compromise is not investigated in isolation.
Sensitive account hardening
We check admin, finance, and owner accounts for stronger session controls and reduced exposure.
Continue learning
More identity attack guides
Need this mapped to your own tenant?
We can review your Microsoft 365 sign-in posture, MFA coverage, Conditional Access policies, legacy auth exposure, admin roles, and mailbox permissions — practical and scoped to a small team.
no obligation~30 minutesGTA-based engineers
FAQ
Identity attack questions answered
4 results
CoverageAre identity attacks mostly a Microsoft 365 problem?
Microsoft 365 is a common target because email, files, Teams, and identity all meet there. The same principles apply to Google Workspace, accounting portals, CRM systems, and remote access tools.
SecurityCan MFA be bypassed?
MFA greatly reduces risk, but active session theft, phishing proxies, OAuth consent abuse, and compromised devices can still create access. That is why Conditional Access, endpoint protection, and logging matter.
SecurityWhat should we check first after a suspected mailbox compromise?
Revoke sessions, reset the password and MFA methods, review inbox and forwarding rules, check sign-in logs, inspect sent mail, and preserve audit logs before cleanup.
CoverageDo small businesses need separate admin accounts?
Yes. Admin accounts should be separate from daily email accounts, protected with strong MFA, and used only for administration.