TLDR: skip to the summary at the bottom for quick wins with AiTM.
Adversary-in-the-Middle (AiTM) phishing targets the authenticated session token that exists after a user has already completed multi-factor authentication. Once captured, that token gives an attacker full access to M365 services — email, SharePoint, Teams, OneDrive — without ever knowing the user’s password, and without triggering another MFA prompt.
The March 2026 EvilTokens / Railway.com campaign, documented by Huntress across more than 340 organisations, introduced a variant that bypasses even network-based session controls: rather than routing a victim through a reverse proxy, it abuses the OAuth device code flow — a legitimate Microsoft authentication mechanism — to harvest tokens directly, then uses those tokens to register a device in Entra ID and obtain a Primary Refresh Token (PRT).
The Threat Landscape
Multi-factor authentication stops password replay. It does not stop token theft. Adversary-in-the-Middle attacks intercept the authenticated session token after MFA succeeds — then replay it from the attacker’s infrastructure. The user sees nothing unusual. No failed MFA prompt. No alert. A stolen access token gives full M365 access for hours; a stolen refresh token survives a password reset for days.
Every token theft attack follows the same four-phase progression. Understanding each phase is the starting point for mapping the right controls.
|
LURE
Phishing email + proxy redirect
|
→ |
INTERCEPT
Proxy relays MFA to Microsoft
|
→ |
TOKEN HARVEST
Session cookie + refresh token stolen
|
→ |
PERSISTENCE
Device reg + PRT survives pwd reset
|
→ |
IMPACT
BEC / Exfil / Lateral move
|
Attacker Arsenal
These are the active frameworks and phishing-as-a-service platforms observed in the wild. Knowing what attackers are using — and how each tool works — determines which controls are non-negotiable versus layered defences.
The Modern Attack Chain
Classic AiTM proxy attacks are increasingly blocked by Global Secure Access Strict Enforcement Mode — which validates the client IP against a Microsoft-managed Entra network presence. Attackers adapted: the EvilTokens / Railway.com campaign (March 2026) uses the OAuth device authorization flow instead of a reverse proxy. The user enters a code on a legitimate Microsoft page — no proxy involved. GSA network checks never fire. The stolen refresh token is then used to register a device under the attacker’s control, obtain a Primary Refresh Token (PRT), and achieve silent, persistent access to all M365 services — even after the user changes their password.
Attack Chain — Device Code Phishing & PRT Pivot
The kill chain below shows how an attacker converts a single phishing email into persistent, password-reset-proof access to all M365 services — without ever touching a reverse proxy.
|
1. PHISHING EMAIL
Attacker sends device code link
|
→ |
2. DEVICE CODE
User enters code at microsoft.com ✓
|
→ |
3. TOKEN ISSUED
Attacker receives refresh token
|
→ |
4. DEVICE REGISTER
Rogue device joins Entra ID
|
→ |
5. PERSISTENT
PRT = silent SSO to all M365 services
|
A Primary Refresh Token (PRT) is a long-lived credential that provides silent single-sign-on to every Microsoft 365 service. It is normally bound to a managed device. When an attacker registers a device using a stolen refresh token and obtains a PRT, they inherit that persistent SSO capability — with no MFA prompt, on their own hardware. A PRT survives a password reset because it is tied to the device registration, not the password. Revoking it requires removing the rogue device registration from Entra ID.
The Token Map: What an Attacker Sees First
An adversary who gains local administrator access to a managed Mac or Windows endpoint does not need to phish credentials. Every browser cookie database, every MSAL token cache, and — on Windows — LSASS memory itself contain active, replay-capable Microsoft 365 credentials. A tool like M365 Token Inspector (token_inspector.py) maps exactly what is present. The result on a corporate machine is reliably alarming.
Running streamlit run token_inspector.py on an active corporate Mac surfaces every Microsoft authentication token across Firefox, Chrome, and Edge simultaneously. Firefox cookies are stored in plaintext SQLite databases — no decryption required. Chrome and Edge cookies are AES-128-CBC encrypted with a key held in macOS Keychain. Retrieving that key requires one Keychain prompt — which an attacker with local admin can trigger silently via a background process. The output is a categorised inventory of every live credential: its expiry window, its host domain, and its classification. On a typical corporate Mac with an active M365 session, expect between 30 and 80 Microsoft cookies — several of them Critical.
| Token / Cookie | Storage | Lifetime | Risk | What an Attacker Does With It |
|---|---|---|---|---|
estsauthpersistent |
Browser cookie store (disk) | Up to 90 days | Critical | Replays the full Entra ID authenticated session from any remote host. Grants access to email, Teams, SharePoint, and OneDrive. No MFA prompt fires. No new sign-in event is logged for the replay — it appears as a continuation of the original session. |
sccauth / sccauthc1 |
Browser memory / cookie store | Session | Critical | Accesses the Microsoft Defender XDR portal (security.microsoft.com). Attacker can suppress active alerts, close incidents, add AV/EDR exclusions for their tools, and disable MDE sensor policies — blinding the security team while access continues undetected. |
fedauth / rtfa |
Browser cookie store (disk) | Session / persistent | Critical | Grants full SharePoint farm access — read, modify, exfiltrate, or delete documents and files across all SharePoint sites and OneDrive. Access patterns are indistinguishable from normal user activity in SharePoint audit logs. |
| MSAL Refresh Token | Disk (DPAPI / Keychain encrypted) | 90 days (sliding) | Critical | Survives a password reset. Exchangeable for new access tokens to any M365 service indefinitely within the 90-day window. On Windows, extractable via SharpDPAPI or Mimikatz DPAPI module with local admin. The user’s password change does not touch this token. |
| Primary Refresh Token (PRT) | Windows LSASS / macOS Keychain | 14 days (auto-renewed) | Critical | Silent SSO to every M365 service. On Windows, extracted from LSASS memory using ProcDump or Mimikatz, then used with AADInternals to generate access tokens for any M365 resource — no MFA, no password, from any attacker-controlled device. |
ohpauth / ohpauthc1 |
Browser cookie store | Session | Critical | Full Microsoft 365 portal access. Used to pivot to connected apps, access shared mailboxes, modify user settings, enumerate tenant resources, and exfiltrate data from any service the user can reach via the portal. |
estsauth (non-persistent) |
Browser memory | Browser session | High | Short-lived but immediately replayable while the browser is open. Usable for rapid exfiltration tasks — forwarding email rules, downloading OneDrive contents, accessing Teams messages — before the session closes. |
The estsauthpersistent cookie is created whenever a user selects “Keep me signed in” at the Entra login prompt — the default on most corporate Macs. An attacker who extracts this single cookie value from the browser’s SQLite database can inject it into any browser and access all M365 services for up to 90 days. There is no re-authentication prompt, no MFA challenge, and no new sign-in event generated in Entra ID logs. The session presents with the user’s original IP context from initial login, making anomaly detection unreliable unless the replay occurs from a geographically distant IP or unfamiliar ASN.
The sccauth cookie is the most underappreciated Critical token on the list. It grants access to the Microsoft Defender XDR portal. An attacker who captures it can suppress active detections, close open incidents, add their tools to MDE exclusion lists, and offboard endpoints from Defender monitoring — all from the same portal the security team uses to investigate them. This is how attackers go dark inside a defended environment: not by evading detection initially, but by accessing the security controls themselves and disabling them after they are already inside. A compromised sccauth session will not generate a suspicious sign-in alert, because it looks like an analyst using their own tools.
MSAL refresh tokens persist in an encrypted file on disk and survive a password reset by design — the token lifecycle is managed by Entra ID server-side policy, not the password. When incident response advises a user to change their password after a compromise, that action alone invalidates nothing an attacker has already captured from the MSAL cache. Revocation requires an explicit server-side action: Revoke-AzureADUserAllRefreshToken via PowerShell, or the “Sign out everywhere” option in myaccount.microsoft.com. Until that is executed, the attacker continues to generate valid access tokens from their captured refresh token.
Attack Chain 1 — Local Admin to Full M365 Compromise
|
1. LOCAL ADMIN
Endpoint access gained (any method)
|
→ |
2. TOKEN SCAN
Browser DBs · MSAL cache · LSASS (Win)
|
→ |
3. CRITICAL TOKENS
estsauthpersistent · sccauth · fedauth · PRT
|
→ |
4. REMOTE REPLAY
Cookies injected into attacker browser / C2
|
→ |
5. FULL M365
Email · Teams · SP · No MFA · 90-day window
|
Attack Chain 2 — Covering Tracks via the Defender Portal (sccauth)
|
1. sccauth CAPTURED
Defender portal session replayed
|
→ |
2. ALERT SUPPRESSION
Active incidents closed, alerts resolved / hidden
|
→ |
3. AV EXCLUSIONS
Attacker tools added to MDE exclusion list
|
→ |
4. SENSOR DISABLED
Endpoint offboarded from MDE policy
|
→ |
5. SOC IS BLIND
Zero telemetry. Attacker operates freely.
|
Attack Scenarios & E5 Controls
Each card maps a specific attack scenario to the Microsoft E5 controls that stop it — covering the problem, the solution, and the licensing required. Use these to drive the conversation with your customer around their current gaps.
Defense Architecture
|
PREVENT
Passkeys · Token Binding · Block Device Code
|
→ |
ENFORCE
GSA Strict Mode · CAE · Compliant Device CA
|
→ |
DETECT
ID Protection · XDR · Sentinel KQL
|
→ |
RESPOND
Auto-Disruption · Token Revocation
|
Token Protection: Proof-of-possession cryptographically binds the access token to the issuing device. Replay on any other device fails at validation.
Block Device Code: Conditional Access policy denies the device code grant type for all non-approved roles. Closes the EvilTokens attack path entirely.
Device Reg MFA: CA policy requires phishing-resistant MFA at device registration time. Stolen refresh tokens cannot be used to register rogue devices.
CAE: Continuous Access Evaluation pushes real-time policy signals to resource providers. IP change or risk elevation revokes access in under 15 minutes.
Compliant Device CA: Conditional Access requires Intune device compliance on all M365 sessions. Attacker-registered non-managed devices fail the compliance check.
Defender XDR: Correlates identity, endpoint, email, and cloud signals into a single incident. Auto-disruption suspends compromised accounts on high-confidence detection.
Defender for Cloud Apps: Inbox rule anomalies, OAuth app abuse, impossible travel across SaaS services — all correlated with Entra sign-in context.
Sentinel: Custom KQL analytics rules for device code grants, anomalous device registrations, and PaaS ASN sign-ins. Playbook automation for incident response.
Detection & Response
Prevention controls reduce exposure but will not catch every attack. The following Microsoft tools provide the detection and automated response capability needed to identify active token theft and contain it before data is exfiltrated.
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0 // successful only
| project TimeGenerated, UserPrincipalName, IPAddress,
AppDisplayName, DeviceDetail, Location
| order by TimeGenerated desc
let riskySignins = SigninLogs
| where RiskLevelDuringSignIn in ("high","medium")
| project UserPrincipalName, riskTime = TimeGenerated;
AuditLogs
| where OperationName == "Register device"
| extend UPN = tostring(InitiatedBy.user.userPrincipalName)
| join kind=inner riskySignins on $left.UPN == $right.UserPrincipalName
| where TimeGenerated between (riskTime .. riskTime + 4h)
| project TimeGenerated, UPN, DeviceName = tostring(TargetResources[0].displayName)
OfficeActivity
| where Operation in ("New-InboxRule","Set-InboxRule")
| where Parameters has "ForwardTo" or Parameters has "RedirectTo"
| extend RuleParams = parse_json(Parameters)
| where RuleParams has_any ("@gmail","@yahoo","@outlook.com")
or RuleParams !has "@yourdomain.com"
| project TimeGenerated, UserId, ClientIP, Parameters
MITRE ATT&CK Coverage
The table below maps each technique used across the token theft attack chain to its MITRE ATT&CK identifier and the corresponding E5 mitigations. This provides a common framework for discussing coverage with security-aware customers.
| Technique ID | Name | Phase | E5 Mitigations |
|---|---|---|---|
| T1566.002 | Phishing: Spear-phishing Link | Initial Access | Defender for Office 365 Safe Links; user awareness training |
| T1539 | Steal Web Session Cookie | Credential Access | GSA Strict Enforcement; Token Protection; CAE revocation |
| T1550.001 | Use Alternate Authentication Material: Application Access Token | Defense Evasion / Lateral Movement | Token Protection; CAE; Entra ID Protection Anomalous Token signal |
| T1528 | Steal Application Access Token (OAuth device code) | Credential Access | CA policy blocking device code grant; Defender XDR detection |
| T1098.005 | Account Manipulation: Device Registration | Persistence | MFA at device registration; Restrict BYOD registration; Anomalous device reg alert |
| T1556.006 | Modify Authentication Process: Multi-Factor Authentication | Defense Evasion | Privileged Identity Management; MFA method audit; Defender XDR MFA change detection |
| T1114.003 | Email Collection: Email Forwarding Rule | Collection | Defender for Cloud Apps inbox rule anomaly; Exchange audit logging KQL |
| T1078.004 | Valid Accounts: Cloud Accounts | Persistence / Privilege Escalation | Risk-based CA auto-block; Defender XDR auto-disruption; refresh token revocation |
| T1136.003 | Create Account: Cloud Account | Persistence | Entra Privileged Identity Management; admin account audit; creation anomaly alert |
All controls above are available within Microsoft 365 E5 or the Microsoft 365 E5 Security add-on, with one exception: Global Secure Access (GSA) is part of the Microsoft Entra Suite, which is a separate add-on (~$12 USD/user/month). GSA provides the strongest single control against token replay. All monitoring tools (Defender XDR, Defender for Cloud Apps, Defender for Identity, Sentinel, Entra ID Protection) are included in M365 E5.
Key Takeaways & Recommended Actions
The controls below represent the highest-impact actions for closing the token theft exposure window. Prioritise by threat coverage and implementation effort — the first three can be deployed with a single Conditional Access policy each.
Simple-Security 