Entra ID AiTM Token Replay, Impossible Travel Detection, and MFA Push Fatigue

Entra ID AiTM Token Replay, Impossible Travel Detection: Why It Matters Now

Multifactor authentication stops password-only attacks. It does not stop an attacker who proxies the entire sign-in flow and walks away with a valid session cookie after the user completes MFA. That is what adversary-in-the-middle (AiTM) phishing kits do, and it is exactly the gap that Entra ID AiTM token replay, impossible travel detection, and MFA push-fatigue signals are built to close. Microsoft has been explicit that this class of attack is a growing share of identity compromise: Microsoft's security blog on evolving identity attack techniques and multiple incident write-ups describe AiTM kits such as Evilginx deploying a reverse proxy between the victim and the real Microsoft 365 sign-in page, serving the legitimate content while capturing username, password, and — critically — the session/refresh token issued after MFA succeeds. Deepwatch documents the same kit being used by threat actors ranging from the prolific phishing operator Storm-0485 to the Russian espionage actor Star Blizzard to silently intercept Microsoft 365 sessions.

Microsoft Entra ID Protection turns this kind of activity into risk signals, but the signals are scattered across several distinct detections, log tables, and licensing tiers. This article is a field guide to reading five of them together:

• AiTM token replay — a stolen session or refresh token gets reused from infrastructure the real user never touched
• Impossible / atypical travel — two sign-ins for the same identity, too far apart geographically to both be legitimate
• MFA push-approval abuse — an attacker with a valid password tries to talk or wear a user into approving a push notification they did not request
• Service principal sign-in spikes — a workload identity suddenly authenticates far more, or far more broadly, than its baseline
• Unusual geography for admin accounts — a privileged identity signs in from a location or device it has never used

How Each Signal Shows Up in Entra ID's Telemetry

AiTM proxies and token replay

MITRE tracks session-cookie theft as T1539 (Steal Web Session Cookie). An AiTM kit sits between the user and Microsoft's real login endpoint, relays every step of the authentication — including the MFA challenge — and then captures the resulting session artifact. Because the victim genuinely completed MFA, the stolen token carries that claim forward. The attacker replays it from their own infrastructure, not the victim's device or network.

Microsoft Entra ID Protection has several detections that catch pieces of this:

• Anomalous token (riskEventType: anomalousToken) — fires on abnormal token characteristics: an unusual lifetime, or a token used from a location, application, IP address, or user agent that does not match the user's history. Microsoft's own documentation names this as a direct indicator of potential token replay. It is real-time or offline, and requires Entra ID P2.
• Attacker in the Middle (attackerinTheMiddle, a user risk detection) — a high-precision detection triggered when a sign-in session is linked to a known malicious reverse proxy, sourced from Microsoft Defender for Cloud Apps telemetry. It raises the user directly to High risk and requires Microsoft 365 E5 with Enterprise Mobility + Security E5 — unlike most other Defender for Cloud Apps-sourced detections, Microsoft does not list a standalone Entra ID P2 + Defender for Cloud Apps license path for this one.
• Unfamiliar sign-in properties (unfamiliarFeatures) — compares a sign-in against the user's learned history (IP, ASN, location, device, browser, tenant subnet). Microsoft's guidance specifically flags this: when it fires on a non-interactive sign-in, it deserves extra scrutiny, because that pattern is consistent with a replayed refresh token being used silently in the background rather than through an interactive logon.
• Token issuer anomaly (tokenIssuerAnomaly) — for SAML tokens, flags issuer claims that are unusual or match known attacker patterns.

Microsoft's token theft playbook lists the concrete triggers a SOC should alert on for token theft investigations: anomalous token, unfamiliar sign-in properties, non-interactive sign-ins from unfamiliar sources, attempted Primary Refresh Token (PRT) access (via Defender for Endpoint), and suspicious URLs consistent with an AiTM landing page.

Impossible travel and atypical travel

Entra ID Protection actually ships two related but distinct detections here, and mixing them up leads to wrong licensing and tooling assumptions:

• Impossible travel (mcasImpossibleTravel) — identifies activity from geographically distant locations within a time window shorter than physically possible travel between them. It is sourced from Microsoft Defender for Cloud Apps, calculated offline, and requires Entra ID P2 plus a standalone Defender for Cloud Apps license (or Microsoft 365 E5).
• Atypical travel (unlikelyTravel) — a native Entra ID Protection detection (no Defender for Cloud Apps dependency) that flags two sign-ins from distant locations where at least one is also atypical for that specific user's history. It accounts for travel time between locations and deliberately suppresses common false positives such as VPN egress points and IPs shared across the org. New users go through a learning period of the earlier of 14 days or 10 sign-ins before the detection activates.

Both require Entra ID P2. If your tenant only has P1 or Free, these fire as the generic Additional risk detected detection with no detail.

MFA push-approval abuse, briefly

Two Entra-native signals matter here: Suspicious MFA authentication approval (authenticatorPhishing) is a real-time, P2-only detection that correlates ASN, browser, device, and GPS mismatches between the device requesting the sign-in and the device approving it via Microsoft Authenticator, and flags the pairing directly as High risk. User reported suspicious activity (userReportedSuspiciousActivity) fires when a user denies an MFA prompt they did not initiate and explicitly reports it — Microsoft treats this as high-confidence, user-confirmed evidence and sets the account to High user risk immediately. Only the latter depends on the Report suspicious activity feature being turned on; authenticatorPhishing fires automatically from sign-in telemetry and needs no separate opt-in. For the full attack chain and hardening sequence (number matching, phishing-resistant MFA for admins, response workflow), see the dedicated article linked above.

Service principal sign-in spikes

Workload identities do not show up in the same SigninLogs table as users — they log to AADServicePrincipalSignInLogs (also referred to as ServicePrincipalSignInLogs depending on workspace/table naming). Thomas Naunheim's auditing guidance for managed identities and service principals recommends grouping by ServicePrincipalName and IPAddress, then aggregating failure counts (ResultType != "0") and the diversity of resources accessed (dcount(ResourceDisplayName)) — a spike in either dimension, especially from an IP or ASN the service principal has never used, is the signal to chase. Microsoft Entra ID Protection also has a dedicated workload identity risk detection surface for exactly this scenario, separate from user risk.

Unusual geography for admin accounts

Microsoft's own security operations guide for privileged accounts is explicit that admin sign-ins deserve stricter, separate monitoring than standard users — new device or location, sign-ins outside expected working hours, and any Entra ID Protection risk detection (at any risk level) on a privileged identity should all generate a high-priority alert. The same guide recommends treating any Unfamiliar sign-in or TOR-sourced activity against a privileged role as worth immediate review, rather than waiting for it to escalate to high risk.

Detection: What to Pull From the Logs

The Microsoft Entra token theft playbook gives concrete starting queries for SigninLogs, AADUserRiskEvents, and AuditLogs. Adapted here for the AiTM/travel/admin-geo signal set:

Find risk detections tagged unfamiliar or anomalous from a specific IP (starting point once you have a suspect IP from a phishing report or EDR alert):

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Pull every sign-in from the same source IP to scope the blast radius:

SigninLogs
| where IPAddress == "<suspect-ip>"

Baseline a specific identity's sign-in geography and devices — this is the query the playbook recommends before deciding whether a flagged sign-in is genuinely anomalous for that user:

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

The playbook notes explicitly that not every Entra risk alert has a matching SigninLogs row — anomalous token detections in particular are sometimes only visible via AADUserRiskEvents or the ID Protection risk-detections API, not the raw sign-in stream.

Service principal spike, adapted from cloud-architekt.net's auditing guidance:

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

For privileged-account geography and MFA-denial monitoring, Microsoft ships ready-made Sentinel content rather than a single query to hand-copy — the security operations guide for privileged accounts points to named templates including SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml, and AADPrivilegedAccountsFailedMFA.yaml in the Azure-Sentinel GitHub repository, which is a better source of truth than reconstructing the exact filter logic here.

Remediation

For AiTM / token replay:

1. Move privileged and high-value accounts to phishing-resistant MFA (FIDO2 security keys or certificate-based authentication) — a proxied session cookie is far less useful to an attacker if the original authentication ceremony can't be relayed. See Azure Identity Security: Why MFA Alone Is Not Enough for why standard push MFA is not sufficient on its own.
2. Enable Continuous Access Evaluation and Conditional Access token protection where supported, so a token bound to one device cannot simply be replayed from attacker infrastructure. EtcSec's catalogue tracks this gap directly as CA_TOKEN_PROTECTION_DISABLED — see Entra ID Conditional Access Gaps for the broader policy review.
3. Turn on the Attacker in the Middle and Anomalous token detections (requires P2, and Defender for Cloud Apps for the former) and route them into a sign-in risk Conditional Access policy rather than leaving them as dashboard-only visibility.
4. Treat a confirmed AiTM hit as a token-theft incident, not a password reset: follow Microsoft's token theft playbook containment steps — revoke sessions, block the attacker IP, and check for newly registered MFA methods or mailbox rules left behind after the session was used.

For impossible / atypical travel:

1. Confirm licensing — atypical travel is native to ID Protection P2, but impossible travel additionally needs Defender for Cloud Apps connected. Missing that connection silently drops the mcasImpossibleTravel signal.
2. Let the 14-day/10-login learning window complete for new or recently-migrated accounts before tuning thresholds off noisy early data.
3. Feed sign-in risk into a Conditional Access policy that requires MFA or blocks at medium/high risk, rather than only reviewing the risky sign-ins report reactively.

For MFA push-approval abuse: enable number matching and the Report suspicious activity feature, and require phishing-resistant MFA for administrators — see the dedicated MFA fatigue article for the full sequence.

For service principal spikes:

1. Review AADServicePrincipalSignInLogs for baseline vs. spike behavior on a recurring cadence, not only during incident response.
2. Avoid standing high-privilege roles on service principals; rotate client secrets/certificates on a defined schedule and prefer managed identities where possible.
3. Enable Entra ID Protection's workload identity risk detections if licensed for it — user-risk policies do not cover service principals.

For unusual admin geography:

1. Enroll all privileged roles in Privileged Identity Management (PIM) with time-bound activation, and require re-authentication at activation.
2. Alert on any ID Protection risk detection against a privileged identity, regardless of the risk level Microsoft assigns — Microsoft's own privileged-account guidance recommends this stricter bar for admins versus standard users.
3. Restrict admin elevation to approved devices (PAW/SAW) where feasible, and alert when elevation happens outside that population.

How EtcSec Detects This

EtcSec's Risk Protection and Conditional Access categories check whether a tenant has the policy and licensing scaffolding these detections depend on, not just whether Entra ID Protection is turned on. Relevant catalogue checks include MFA_SUSPICIOUS_ACTIVITY (suspicious MFA / sign-in activity pattern) and MFA_UNUSUAL_LOCATION (MFA sign-in from an unusual geolocation) at the signal level, plus RISK_NO_SIGNIN_RISK_POLICY (no sign-in risk policy enforcing a response), RISK_SIGNINS_NOT_INVESTIGATED (risky sign-ins accumulating without review), and CA_TOKEN_PROTECTION_DISABLED (no token binding to blunt replay) at the response level.

A tenant that shows risky sign-ins in the portal but has no policy acting on them, and no token protection in front of session cookies, is exactly the gap these checks are built to surface.

Related Controls

Read this alongside Azure Identity Protection: Blocking Leaked Credentials for sign-in and user risk policy configuration, MFA Fatigue: Detection and Prevention for Microsoft Entra ID for the push-approval attack chain, Azure Privileged Access: Too Many Global Admins and How to Audit Microsoft Entra ID Security for the PIM and admin-hardening side, and OAuth Consent Phishing and Malicious Apps and Device Code Phishing in Entra ID for adjacent identity-phishing techniques that feed the same risk signals.

Primary References

• Microsoft Learn: What are risk detections? (Entra ID Protection)
• Microsoft Learn: Token theft playbook
• Microsoft Learn: Security operations for privileged accounts
• Microsoft Learn: Securing workload identities with Entra ID Protection
• Microsoft Learn: How number matching works in MFA push notifications
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• nicolonsky/ITDR: AiTM phishing detection in Entra ID
• cloud-architekt.net: Sign-in logs and auditing of managed identities and service principals
• Microsoft Security Blog: Defending against evolving identity attack techniques
• Elastic Security Labs: Microsoft Entra ID OAuth phishing and detections