Detecting Token Theft and Adversary-in-the-Middle Hijack

Adversary-in-the-middle kits proxy the real sign-in page, relay the user’s password and MFA response, and capture the resulting session cookie. The attacker then replays that cookie from their own infrastructure and inherits an already authenticated session. The sign-in succeeded legitimately, so detection depends on spotting where the session is used afterwards.

Signals at a Glance

Session Reuse Across Networks

A replayed cookie carries the original session identifier, so the same SessionId appears from the victim’s network and then from attacker infrastructure. Compare network origin per session across interactive and non-interactive sign-ins:

// Microsoft Sentinel (KQL) - one session ID seen from multiple ASNs and countries
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| summarize ASNs = dcount(AutonomousSystemNumber),
            Countries = dcount(Country),
            IPs = make_set(IPAddress, 10),
            Agents = dcount(UserAgent),
            First = min(TimeGenerated), Last = max(TimeGenerated)
          by UserPrincipalName, SessionId
| where ASNs >= 2 and Countries >= 2
| order by Last desc
// tune/validate: mobile carriers and VPN egress produce legitimate ASN changes; require Countries >= 2 or a risk event

• Join to RiskEventTypes_V2 on the same session; anomalousToken and tokenIssuerAnomaly are the Entra ID Protection detections designed for this case.
• Hunt for the lure: a sign-in page hosted on an unrelated domain that loads login.microsoftonline.com assets, visible in proxy or URL click telemetry.
• Token protection and compliant-device Conditional Access make replayed cookies fail outright; use detections to find the gaps, not as the only control.

What the Attacker Does Next

Post-compromise behaviour is more reliable than the replay itself. AiTM intrusions commonly create inbox rules to hide replies, then pivot to business email compromise. Alert when a rule is created close to a sign-in from a new network:

// KQL - inbox rule created within 30 minutes of a sign-in from an unfamiliar IP
let sus = SigninLogs
    | where TimeGenerated > ago(1d) and ResultType == 0
    | where RiskEventTypes_V2 has_any ("anomalousToken","tokenIssuerAnomaly","unfamiliarFeatures")
    | project SignTime = TimeGenerated, UserPrincipalName, IPAddress;
OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend UserPrincipalName = tolower(UserId)
| join kind=inner (sus | extend UserPrincipalName = tolower(UserPrincipalName)) on UserPrincipalName
| where TimeGenerated between (SignTime .. SignTime + 30m)
| project TimeGenerated, UserPrincipalName, Operation, IPAddress, Parameters
// tune/validate: drop the risk filter to widen coverage, then rank by rule parameters (DeleteMessage, MoveToFolder RSS/Archive)

• Contain by revoking all refresh tokens and sessions for the user, not only resetting the password.
• Review OAuth app grants and registered MFA methods for the account, since attackers often add their own authenticator.