Detecting and stopping token theft and session hijacking

Token theft means attackers steal the session or refresh token of an already authenticated user and use it to bypass MFA. The classic path is reverse-proxy phishing (adversary-in-the-middle), increasingly also endpoint info-stealers. A SOC detects this from token usage outside the user context, not from the login itself. Defence means phishing-resistant MFA, Continuous Access Evaluation, token binding and detection on refresh-token replay.

SOC as a ServiceAllDetecting and stopping token theft and session hijacking

How this compares to neighbouring topics

This page describes token theft as a technical attack vector: how session and refresh tokens are stolen and replayed, and how a SOC detects it. Business Email Compromise in M365 describes subsequent mailbox activity, including fraud and IBAN changes. ITDR explains its classification as a detection discipline; Glossary ITDR provides a short definition. SOC for Microsoft 365 and Sentinel covers the platform with Entra ID and Sentinel. The pillar page SOC as a Service Switzerland describes the full operational picture.

Rule of thumb on scope

Token theft describes the attack technique. ITDR covers this technique alongside password spray, consent abuse and AD attacks. BEC is a common consequence.

How token theft works

Path	Example	What is stolen
Adversary-in-the-middle phishing	Evilginx reverse proxy between user and real login page.	Session cookie after successful MFA prompt.
Endpoint info-stealer	RedLine, Raccoon, Lumma; often via malicious downloads or cracked software.	Browser cookies, stored refresh tokens, password manager database.
Device code phishing	Attacker initiates the OAuth device-code flow and gets the victim to enter the code.	Refresh token for the attacker's device, valid for weeks.
Primary refresh token theft	Access to an Entra ID joined device with local admin rights.	PRT plus session key, enabling silent SSO as the victim.

The common thread: the login looks clean because it happened. The signal is in how the token is used afterwards, not in how the user signed in.

Why classic MFA is no longer enough

SMS, push and TOTP MFA authenticate only the login event. Once an attacker holds the session or refresh token, they need no further MFA prompt to use it. Effective controls bind the token to the device (FIDO2 with token binding, Windows Hello for Business, certificate-based authentication). Continuous Access Evaluation continuously re-evaluates the token.

How a SOC detects token theft

Refresh-token replay from unusual IPs, ASNs or countries relative to the user baseline.
Non-interactive sign-ins without MFA claim right after an interactive login from the real user.
Impossible travel between session usage and last interactive login.
Client-app switch: a token issued for web is suddenly used from a script or CLI client.
Anomaly in Graph API or Exchange Web Services usage (mass reads, unusual endpoints).
Correlation with EDR signals for info-stealer families (cookie access, browser storage dumping).

Token theft response playbook

Revoke all sessions and refresh tokens for the user (revokeSignInSessions plus refresh-token reset).
Reset MFA methods, enrol a phishing-resistant method (FIDO2 or CBA).
Isolate the affected device and check for info-stealers; clean or recreate browser profiles.
For Entra ID joined devices: disable the device, invalidate the PRT, force re-registration.
Tighten Conditional Access: reduce sign-in frequency, enforce Continuous Access Evaluation, enable risk-based policies.
Investigate downstream activity: inbox rules, OAuth consents, outbound mail; see BEC in M365.

Placement in SOC operations

The pillar page SOC as a Service Switzerland explains how token detection fits into ongoing 24/7 operations.

Frequently asked questions

Is token theft the same as BEC?

Token theft and BEC describe different stages of an attack. Token theft is the technique attackers use to get into an account. BEC is a common follow-on crime in the mailbox. A SOC has to detect both layers: the token usage (this page) and the mailbox abuse (see [BEC in M365](/en/soc/business-email-compromise-m365)).

Does FIDO2 fully protect against token theft?

FIDO2 makes reverse-proxy phishing practically ineffective because it checks the origin. Info-stealers pulling cookies from the local browser still remain a risk while the endpoint is compromised. Defences also need token binding, Continuous Access Evaluation and EDR detection on the endpoint.

How often do tokens rotate by default?

Access tokens in Entra ID are typically valid for 60 to 90 minutes; refresh tokens can live for weeks or months without Continuous Access Evaluation. That is precisely why refresh-token replay is valuable for attackers and detection on it is valuable for defence.

Do we need ITDR in addition to a SOC?

A modern SOC covers ITDR as a detection discipline without requiring a separate purchase (details on [ITDR](/en/soc/itdr-identity-threat-detection)). The SOC needs to correlate identity signals (Entra ID, AD, Okta) alongside endpoint signals.

How fast should you respond to token theft?

Respond within minutes. As long as the session is alive, the attacker holds active rights in the tenant. Revoke sessions and reset MFA within the first hour. See [MTTD and MTTR in a SOC](/en/soc/soc-mttd-mttr) for targets.

Continue reading in this cluster

Detecting and stopping Business Email Compromise in Microsoft 365

Business Email Compromise (BEC) in Microsoft 365 rarely involves malware. The attack chain involves phishing, session or token theft, inbox rules and OAuth consent abuse. A SOC detects BEC by correlating signals from Entra ID, Exchange Online and Defender for Cloud Apps. The email body alone is insufficient for detection. Responders revoke sessions, remove inbox rules, withdraw OAuth consents and enforce MFA again. They document these actions in line with ISG and insurance requirements.

SOC for Microsoft 365 and Sentinel: what matters

A SOC for Microsoft 365 and Sentinel environments correlates signals from Entra ID, Defender XDR, Exchange Online and Azure in one detection layer. It responds 24/7. Analysts, playbooks and documented response provide the operational value beyond the licence.

Security awareness training: turning click risk into reporting behaviour

Security awareness training is a measurable behavioural process, beyond a mandatory e-learning module. The target is not a zero click rate but a reporting rate for suspicious mail in the 40 to 50 percent target band before the SOC escalates. ANOMAL combines short role-specific modules, realistic phishing simulations and a reporting interface in Microsoft 365 so awareness becomes a detection source. The 'Regular security awareness training with phishing simulations' requirement of most Swiss cyber insurers is documented in the process.

Incident response within 72 hours

The outcome of a serious cyber incident is decided in the first hours. ANOMAL provides a Swiss incident response team that works within the 72-hour notification window of cyber insurance. It covers first analysis, containment, evidence preservation and communication with insurer, regulator and executive leadership. A retainer is not mandatory but recommended so the clock does not start with the first phone call.

MTTD and MTTR: the two SOC KPIs that count

Mean Time to Detect (MTTD) measures how fast a SOC spots an attack. Mean Time to Respond or Contain (MTTR, MTTC) measures how fast it is stopped. Together they are the only credible evidence that a SOC is working, not just running.

Look up short definitions in the glossary