Microsoft 365 Token-Replay Attacks: Defending Against AitM Session Hijacking and Credential Theft

In early October 2026, security researchers at Huntress disclosed a widespread campaign targeting Microsoft 365 environments. Between July 14 and September 22, 2026, threat actors leveraged adversary-in-the-middle (AitM) relay infrastructure to intercept authentication sessions, capture session tokens, and replay them to gain unauthorized access to corporate email accounts. The campaign resulted in 497 successful sign-in events, compromising 97 accounts across 79 distinct organizations.

This is not a vulnerability in the traditional sense—there is no CVE to patch. Instead, this campaign exploits the fundamental trust model of token-based authentication. By positioning themselves between the user and the legitimate Microsoft login portal, attackers bypass multi-factor authentication (MFA) entirely. They do not steal passwords; they steal the cryptographic proof of a successful authentication. For SOC analysts and CISOs, this represents a clear and present danger to identity infrastructure. If your organization relies on Microsoft 365 without phishing-resistant MFA or robust session anomaly detection, you are a target. This post provides the technical depth required to understand the attack chain, hunt for indicators of compromise, and harden your environment against token-replay attacks.

Technical Analysis

Affected Products and Platforms

This campaign specifically targets cloud identity and productivity ecosystems:

• Microsoft 365 (Office 365): Exchange Online, SharePoint Online, and Teams are primary targets once access is established.
• Microsoft Entra ID (formerly Azure Active Directory): The identity provider issuing the tokens being stolen.
• Authentication Endpoints: Legacy authentication protocols (IMAP, POP3, SMTP) and modern OAuth 2.0 flows are both viable vectors if not properly secured.

Attack Chain: Anatomy of an AitM Token Replay

Unlike credential stuffing or password spraying, AitM attacks are sophisticated, interactive operations. Understanding the attack chain is critical for effective defense.

1. The Lure: The victim receives a phishing email, often containing a QR code or a link, directing them to a convincing replica of the Microsoft 365 login page. The domain is typically a lookalike (e.g., login.microsoftonline.com.evil-corp.com).
2. The Relay: When the victim enters their credentials and MFA code on the phishing site, the attacker’s server acts as a proxy. It forwards the credentials to the legitimate Microsoft login page in real-time.
3. Token Capture: Upon successful authentication, Microsoft returns a session token (a JSON Web Token or JWT, often stored as a cookie like ESTSAUTH or ESTSAUTHPERSISTENT). Because the attacker is proxying the traffic, they capture this token.
4. The Replay: The attacker now injects the stolen session token into their own browser session. Microsoft Entra ID validates the token, sees it as legitimate, and grants the attacker access to the victim’s mailbox and data. MFA is effectively bypassed because the token represents a post-authentication state.
5. Persistence and Exfiltration: Once inside, attackers establish persistence by creating inbox rules to hide security alerts, adding MFA methods to their own devices, or registering malicious OAuth applications. They then proceed to exfiltrate sensitive data or launch Business Email Compromise (BEC) campaigns.

Exploitation Status

This is confirmed active exploitation. Huntress observed 497 successful sign-in events during the campaign window. This is not theoretical; it is an ongoing threat to organizations globally. There is no CVE associated with this technique, as it abuses the intended functionality of token-based authentication rather than exploiting a software flaw. However, it maps directly to MITRE ATT&CK techniques T1557 (Adversary-in-the-Middle) and T1550.004 (Use Alternate Authentication Material: Web Session Cookie).

Detection & Response

Detecting AitM token-replay attacks requires shifting focus from endpoint malware to identity telemetry. We must hunt for anomalies in session behavior, impossible travel, and post-compromise configuration changes.

SIGMA Rules

The following Sigma rules are designed to detect the post-compromise behaviors commonly associated with AitM token theft. They focus on mailbox manipulation and persistence mechanisms, which are high-fidelity indicators of account takeover.

---
title: Microsoft 365 Suspicious Inbox Rule Creation
id: 8a3f1c92-0f72-4e3a-a8c5-1d2f3b4c5d6e
status: experimental
description: Detects the creation of inbox rules that forward or delete emails, a common tactic for hiding malicious activity or exfiltrating data after token replay.
references:
  - https://attack.mitre.org/techniques/T1098/002/
author: Security Arsenal
date: 2026/10/27
tags:
  - attack.persistence
  - attack.t1098.002
logsource:
  product: office365
  service: exchange
detection:
  selection:
    Operation: 'New-InboxRule'
  condition: selection
falsepositives:
  - Legitimate user-created rules for organization
level: medium
---
title: Microsoft 365 Impossible Travel Sign-in
id: 7b2e4d81-9e4b-4d67-bc12-3e5a8f901234
status: experimental
description: Detects sign-in attempts from geographically distant locations within a short timeframe, indicative of token replay from an attacker's infrastructure.
references:
  - https://attack.mitre.org/techniques/T1550/004/
author: Security Arsenal
date: 2026/10/27
tags:
  - attack.initial_access
  - attack.t1550.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    Status: 'Success'
  filter:
    Location|contains: 'Expected Corporate Locations'
  condition: selection and not filter
falsepositives:
  - VPN usage
  - Legitimate travel
level: high
---
title: Microsoft 365 Legacy Authentication Protocol Usage
id: 9c1d5e72-8f5c-5e78-cd23-4f6b9a012345
status: experimental
description: Detects sign-ins using legacy authentication protocols (IMAP, POP3, SMTP) which do not support MFA and are often abused by attackers using stolen tokens or basic credentials.
references:
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/10/27
tags:
  - attack.initial_access
  - attack.t1078
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ClientAppUsed:
      - 'IMAP4'
      - 'POP3'
      - 'Authenticated SMTP'
  condition: selection
falsepositives:
  - Legacy applications or service accounts that have not been migrated
level: medium

KQL (Microsoft Sentinel / Defender)

This KQL query is designed for Microsoft Sentinel or the Microsoft 365 Defender advanced hunting portal. It hunts for the impossible travel scenario—a strong indicator that a session token has been replayed from a different geographic location.

let lookback = 24h;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| summarize FirstSeen=min(TimeGenerated), Locations=make_set(Location) by UserPrincipalName, IPAddress
| where array_length(Locations) > 1
| extend Distance = geo_distance_2points(todouble(Locations[0].latitude), todouble(Locations[0].longitude), todouble(Locations[1].latitude), todouble(Locations[1].longitude))
| where Distance > 500 // Threshold in kilometers
| project UserPrincipalName, IPAddress, FirstSeen, Locations, Distance

Velociraptor VQL

While AitM attacks are primarily cloud-based, endpoint forensics can reveal if a user was phished via a malicious link or if credentials were harvested locally before the token theft. This VQL hunts for suspicious browser history entries related to known phishing domains or login pages.

-- Hunt for browser history containing suspicious login patterns or phishing domains
SELECT * FROM Artifact.Windows.Forensics.BrowserHistory(
  URLRegex='login\.microsoftonline\.com\.|office\.com\.|.*-auth\..*'
)

Remediation Script (PowerShell)

This PowerShell script helps you audit your environment for vulnerable configurations and enforces a key hardening measure: disabling legacy authentication. Run this with appropriate administrative privileges.

# Connect to Exchange Online and Azure AD
Connect-ExchangeOnline
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Directory.Read.All"

# 1. Audit: Check for users with legacy authentication enabled
Write-Host "Auditing for legacy authentication protocols..." -ForegroundColor Cyan
$LegacyProtocols = Get-CasMailbox -ResultSize Unlimited | Where-Object {$_.PopEnabled -eq $true -or $_.ImapEnabled -eq $true}
if ($LegacyProtocols) {
    Write-Host "Found mailboxes with POP/IMAP enabled:" -ForegroundColor Yellow
    $LegacyProtocols | Select-Object Name, PopEnabled, ImapEnabled
} else {
    Write-Host "No mailboxes found with POP/IMAP enabled." -ForegroundColor Green
}

# 2. Remediate: Disable legacy authentication for all mailboxes
Write-Host "Disabling legacy authentication (POP/IMAP) for all mailboxes..." -ForegroundColor Cyan
Get-CasMailbox -ResultSize Unlimited | Set-CasMailbox -PopEnabled $false -ImapEnabled $false
Write-Host "Legacy authentication disabled." -ForegroundColor Green

# 3. Hardening: Create a Conditional Access Policy to block legacy auth (requires Azure AD P1)
Write-Host "Creating Conditional Access Policy to block legacy authentication..." -ForegroundColor Cyan
$Conditions = @{
    Users = @{
        Include = "All"
    }
    ClientAppTypes = @{
        Include = "exchangeActiveSync", "other"
    }
}
$GrantControls = @{
    Operator = "OR"
    BuiltInControls = "block"
}
# Note: This is a simplified example. In production, use the Microsoft Graph SDK or Portal for complex CA policies.
Write-Host "Please configure a Conditional Access policy in the Entra portal to block legacy authentication." -ForegroundColor Yellow

# 4. Audit: Check for suspicious inbox rules
Write-Host "Checking for suspicious inbox rules..." -ForegroundColor Cyan
$Mailboxes = Get-ExoMailbox -ResultSize Unlimited
foreach ($Mailbox in $Mailboxes) {
    $Rules = Get-InboxRule -Mailbox $Mailbox.Identity
    foreach ($Rule in $Rules) {
        if ($Rule.ForwardTo -ne $null -or $Rule.RedirectTo -ne $null) {
            Write-Host "Suspicious rule found on $($Mailbox.Identity): $($Rule.Name)" -ForegroundColor Red
        }
    }
}

Remediation

Defending against AitM token-replay attacks requires a defense-in-depth strategy focused on identity. There is no patch to deploy; instead, you must raise the cost of attack for the adversary.

1. Implement Phishing-Resistant MFA: This is the single most effective control. Move away from SMS, voice, or push-based MFA. Enforce FIDO2 security keys or Windows Hello for Business. These methods bind the authentication to the legitimate domain, making AitM relays ineffective.
2. Enforce Conditional Access Policies: Use Microsoft Entra ID Conditional Access to:
   • Block Legacy Authentication: Legacy protocols (IMAP, POP3, SMTP) cannot enforce MFA and are a primary entry point.
   • Require Compliant Devices: Only allow access from devices that are managed and compliant with your security policies.
   • Implement Location-Based Policies: Block or require additional verification for sign-ins from unexpected geographic locations or anonymizing VPNs.
3. Reduce Token Lifetime: Shorten the lifetime of session tokens. While this may increase authentication prompts, it limits the window of opportunity for an attacker to replay a stolen token.
4. Monitor for Impossible Travel: Actively hunt for and alert on sign-ins that violate the laws of physics (e.g., a login from New York and London within an hour). This is a high-fidelity indicator of token replay.
5. User Awareness Training: Educate users to scrutinize login URLs, hover over links before clicking, and never approve MFA requests they did not initiate. Teach them to recognize the subtle signs of a phishing page.
6. Incident Response Playbook: If you detect a token-replay attack, immediately:
   • Revoke all active sessions for the affected user (Revoke-AzureADUserAllRefreshToken).
   • Reset the user’s password.
   • Review and remove any malicious inbox rules or OAuth application consents.
   • Investigate the full scope of data access.

For further guidance, refer to Microsoft’s official documentation on Configure phishing-resistant MFA and Block legacy authentication.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub