Adversary-in-the-Middle (AiTM) phishing kits (EvilginX2, Modlishka, Muraena) act as a reverse proxy between the victim and the real Microsoft sign-in page. The user completes MFA normally — the kit intercepts the post-authentication session cookie in real time. The attacker replays that cookie from a different IP. No password stolen. No MFA code stolen. Just a valid session token.
Microsoft Entra ID fires tokenIssuerAnomaly, unfamiliarFeatures, and impossibleTravel risk events when it detects session replay signatures. Because MFA genuinely completed, standard Conditional Access policies do not block the replay. Containment requires session revocation — not just password reset.
◈ Table of Contents
01
Background
CONTEXTB1AiTM Attack Phases & MITRE Mapping
| Phase | MITRE | Attacker Goal | Key Indicator |
|---|---|---|---|
| Phishing kit delivery | T1566.002 | Lure victim to AiTM proxy URL | Spear-phishing link to adversary subdomain mimicking login.microsoftonline.com |
| Credential relay + MFA bypass | T1539, T1557 | Capture session cookie after real MFA completes | User finishes MFA — kit forwards credentials live and steals the resulting cookie |
| Session cookie replay | T1550.004 | Access tenant as authenticated user from attacker IP | Sign-in from different country/ASN within minutes of MFA success — Entra fires tokenIssuerAnomaly |
| Follow-on: BEC / inbox rules | T1114.003 | Suppress detection, commit fraud | New inbox rule to delete/forward security alerts; fraudulent payment emails sent |
| Follow-on: OAuth persistence | T1528 | Maintain access after password reset | App consent to Mail.Read or offline_access — survives credential change |
B2Log Sources & Prerequisites
| Source | Sentinel Table | Key Fields | Required Setting |
|---|---|---|---|
| Entra ID Sign-in Logs | SigninLogs | RiskEventTypes_V2, ResultType, IPAddress, LocationDetails, NetworkLocationDetails | Entra ID P1/P2; diagnostic settings → Log Analytics workspace |
| Entra ID Protection | AADUserRiskEvents | RiskEventType, RiskLevel, IPAddress, AdditionalInfo | Entra ID P2 (Identity Protection) |
| M365 Unified Audit | OfficeActivity | Operation, ClientIP, UserId — inbox rules, consent grants, email activity | Unified Audit Log enabled in Microsoft Purview |
| Defender for Office 365 | EmailEvents, EmailUrlInfo | RecipientEmailAddress, Url, UrlClickCount, NetworkMessageId | Microsoft Defender for Office 365 Plan 1+ |
02
Identification
DETECT & INVESTIGATE◈ AiTM MFA Bypass — Investigation Workflow
I1Detect AiTM Session Replay via Entra ID Risk EventsMANUAL + KQL
WHY
AiTM kits steal the session cookie after real MFA completes. The attacker replays it from a different IP/ASN, which triggers tokenIssuerAnomaly in Entra. A ResultType=0 (success) combined with this risk event is near-certain confirmation of session hijack — NOT a false positive despite MFA succeeding.
◈ Where to Check
Entra ID→Protection→Identity Protection→Risk detections
- 1Navigate to Entra ID → Protection → Identity Protection → Risk detections. Filter by User = [UPN from alert], date range = last 7 days.
- 2Look in the Risk event type column for
tokenIssuerAnomaly,unfamiliarFeatures, orimpossibleTravel. Any of these on a successful sign-in = investigate immediately. - 3Open the risk detection event. Note the IP address and Location fields. Then navigate to Entra ID → Users → [UPN] → Sign-in logs and find the MFA-success event 2–10 minutes earlier. Compare IP and country — if they differ, this is cookie replay.
- 4Open the second sign-in (different IP). Click the Authentication Details tab. If it shows "Previously satisfied" or no MFA step while the first showed MFA completed — confirms session token replay.
- 5Check the User risk level in the user's profile (Entra ID → Users → [UPN] → overview). If High and risk state is atRisk, Entra has already flagged this user for remediation.
Key Indicators — Entra ID Risk Events & Sign-in Fields
| Code / Field Value | Meaning | Analyst Action |
|---|---|---|
| tokenIssuerAnomaly | Session token issued by entity different from the authenticating IdP — the AiTM kit's classic signature | Treat as confirmed AiTM. Check IP delta vs MFA completion. Proceed to C1 immediately. |
| unfamiliarFeatures | Sign-in properties (IP, device, ASN) atypical for this user's sign-in history | Correlate with phishing click in EmailUrlInfo. Click + unfamiliarFeatures within 30 min = high-confidence AiTM. |
| impossibleTravel | Two successful sign-ins from geographically separated locations within physically impossible travel time | Compare timestamps and country fields. Gap <60 min across continents = session stolen, not the user travelling. |
| ResultType = 0 | Sign-in SUCCEEDED — MFA was completed by the real user, cookie was intercepted by the AiTM kit | Critical when paired with any risk event for same user. Do NOT dismiss as clean because MFA succeeded — that is the attack. |
| RiskLevelDuringSignIn = high | Entra ID classified this sign-in as high risk in real-time via ML evaluation | Block sign-in and revoke sessions immediately. Do not wait for more evidence. |
DETECTS: Successful sign-ins (ResultType=0) for a target user with concurrent high/medium risk events — surfaces the AiTM replay sequence where MFA completed at one IP and the session was used from another.
KQL — Microsoft Sentinel: AiTM token replay per user
let user = "[email protected]";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ user
| where ResultType == 0
| extend RiskEvents = tostring(RiskEventTypes_V2)
| extend Country = tostring(LocationDetails.countryOrRegion)
| extend ASN = tostring(NetworkLocationDetails[0].networkNames[0])
| extend AuthMethod = tostring(AuthenticationDetails[0].authenticationMethod)
| project TimeGenerated, IPAddress, Country, ASN, AuthMethod,
RiskLevel = RiskLevelDuringSignIn, RiskEvents, AppDisplayName
| order by TimeGenerated asc
DETECTS: All tokenIssuerAnomaly, unfamiliarFeatures, and impossibleTravel events org-wide in the last 24h — use once one victim is found to identify other compromised accounts in the same campaign.
KQL — Org-wide AiTM campaign detection (last 24h)
AADUserRiskEvents
| where TimeGenerated > ago(24h)
| where RiskEventType in ("tokenIssuerAnomaly","unfamiliarFeatures","impossibleTravel")
| where RiskLevel in ("high","medium")
| project TimeGenerated, UserPrincipalName, RiskEventType, RiskLevel,
IPAddress, Location, AdditionalInfo
| order by RiskLevel asc, TimeGenerated desc
DETECTS: High/medium risk successful sign-ins in Splunk — equivalent to the KQL above for environments ingesting Entra logs via the Azure Monitor connector.
SPL — Splunk
index=azure sourcetype=azure:aad:signin ResultType=0
RiskLevelDuringSignIn IN ("high","medium")
| eval risk_events=mvjoin(RiskEventTypes_V2, ", ")
| where risk_events LIKE "%tokenIssuerAnomaly%" OR risk_events LIKE "%impossibleTravel%"
| table _time, UserPrincipalName, IPAddress, Location, risk_events, AppDisplayName
| sort -_time
ResultType=0 with tokenIssuerAnomaly is near-certain AiTM. The user completed real MFA — the attacker replays the resulting token from a different IP. Do NOT dismiss as a false positive because MFA succeeded. The success IS the attack signal.
I2Correlate Phishing Click with Sign-in AnomalyMANUAL + KQL
WHY
Linking an email URL click to the subsequent risky sign-in proves the full kill chain — phishing delivery → AiTM intercept → session replay. This distinguishes AiTM from legitimate impossible travel, confirms the initial access vector, and identifies the full scope of affected users who clicked the same URL.
◈ Where to Check
Microsoft Defender Portal→Email & Collaboration→Explorer→All email
- 1Navigate to Microsoft Defender Portal → Email & Collaboration → Explorer → All email. Filter Recipient = [UPN], date range = last 7 days.
- 2Find emails received within 1 hour before the risky sign-in. Check the URL column for lookalike Microsoft domains — AiTM kits use visually similar domains (e.g. login-microsoftonIine.com, microsoft-365-login.net).
- 3Click into the suspicious email → URL clicks tab. Verify the user clicked the link. Note the exact click timestamp — it should be <5 minutes before the first Entra sign-in event.
- 4Take the AiTM proxy domain and search EmailUrlInfo for all other recipients — this identifies whether this is a targeted single-user attack or an org-wide campaign requiring broader containment.
- 5Check the domain against Sentinel → ThreatIntelligenceIndicator table — existing IOC matches confirm known AiTM infrastructure and may link to a tracked threat actor campaign.
DETECTS: Users who clicked a non-Microsoft URL followed by a risky sign-in within 1 hour — proves the AiTM kill chain from phishing delivery to session compromise for any user in the organisation.
KQL — Phishing click correlated with risky sign-in (org-wide)
let risky = AADUserRiskEvents
| where TimeGenerated > ago(7d)
| where RiskEventType in ("tokenIssuerAnomaly","unfamiliarFeatures","impossibleTravel")
| project UserPrincipalName, RiskTime=TimeGenerated;
EmailUrlInfo
| where TimeGenerated > ago(7d)
| where UrlClickCount > 0
| where Url !has "yourdomain.com" and Url !has "microsoft.com"
| join kind=inner risky on $left.RecipientEmailAddress == $right.UserPrincipalName
| where TimeGenerated < RiskTime and RiskTime < TimeGenerated + 1h
| project ClickTime=TimeGenerated, RecipientEmailAddress, Url, NetworkMessageId, RiskTime
| order by ClickTime desc
DETECTS: Splunk equivalent — correlates URL click events with Entra ID risk events within a 1-hour window for the same user.
SPL — Splunk: Phishing click + risky sign-in
index=azure sourcetype=azure:aad:signin
| eval is_risky=if(RiskLevelDuringSignIn IN ("high","medium") AND ResultType="0","yes","no")
| where is_risky="yes"
| eval signin_time=_time
| join UserPrincipalName [
search index=o365 sourcetype=ms:o365:management Operation=SafeLinksUrlClick
| eval click_time=_time
| fields UserPrincipalName, click_time, Url
]
| where click_time < signin_time AND signin_time < click_time+3600
| table click_time, signin_time, UserPrincipalName, Url
| sort -click_time
AiTM domains frequently use lookalike characters (uppercase I vs lowercase l, zero vs O) or Unicode homoglyphs. Check the domain registration date — AiTM infrastructure is typically registered within 24–48h of the campaign launch.
03
Containment
STOP ITBased on Identification Findings:
Confirmed
tokenIssuerAnomaly or impossibleTravel + ResultType=0 present, OR two successful sign-ins from different countries within 30 min, OR user confirmed click on AiTM URL before anomalous sign-in → Execute C1 immediately, notify L2.
Uncertain
unfamiliarFeatures present but no impossible travel and no confirmed URL click found → Complete I1 and I2 fully. If user has admin access or handles sensitive data, block sign-in as precaution while investigating.
False Pos.
User confirms legitimate travel or VPN use, known device, no new inbox rules, no OAuth grants, no phishing click in email logs → Document explanation, close ticket, note IP/ASN for tuning.
C1Session Revocation & Sign-in BlockImmediate
- 1Revoke all sessions (kills stolen cookie): Entra ID → Users → [UPN] → Revoke sessions. The attacker's browser session dies within seconds. This is the single most important containment action.
- 2Block sign-in: Entra ID → Users → [UPN] → Account enabled → toggle OFF. Prevents re-authentication until remediation is complete.
- 3Revoke all OAuth grants: Entra ID → Enterprise applications → filter by user → Permissions → Revoke. AiTM operators commonly consent a rogue app immediately for persistence that survives password reset.
- 4Remove malicious inbox rules: Exchange admin center → Mailboxes → [user] → Mailbox → Manage mailbox policies → Inbox rules. Delete any rules created during the compromise window. If BEC emails were sent, cross-reference SOP-10.
- 5Block AiTM domain org-wide: Microsoft Defender Portal → Email & Collaboration → Policies & rules → Threat policies → Tenant Allow/Block Lists → URLs → Add block. Enter the AiTM proxy domain.
Password reset alone does NOT revoke existing session tokens. An attacker holding a stolen cookie remains logged in even after the victim changes their password. Always revoke sessions via Entra ID FIRST.
04
Eradication
CLEAN UPE1Full Identity Remediation
- 1Issue a Temporary Access Pass (TAP) for MFA re-registration: Entra ID → Users → [UPN] → Authentication methods → Add method → Temporary Access Pass. Set validity to 1 hour. User must register a new authenticator app using this TAP.
- 2Delete all existing MFA methods before issuing TAP: Entra ID → Users → [UPN] → Authentication methods → delete all existing entries. AiTM kits can harvest TOTP seeds during the attack window — do not trust existing registrations.
- 3Confirm no persistent OAuth apps remain: Entra ID → Users → [UPN] → Applications → review all entries. Remove any third-party app consented during the compromise window.
- 4Review 7-day activity log: Pull OfficeActivity for the compromised UPN from click time through containment. Document every resource accessed (SharePoint files, Teams, Exchange, Azure portal) for breach scope assessment.
- 5Enable Continuous Access Evaluation (CAE): Entra ID → Protection → Continuous access evaluation. CAE reduces the token replay window from hours to seconds by enforcing near-real-time revocation signalling to supported apps.
Eradication Complete When
- All sessions revoked; sign-in re-enabled only after TAP MFA re-registration confirmed
- All OAuth grants audited; non-approved grants removed
- AiTM phishing domain blocked in Defender for Office 365 Tenant Allow/Block list
- No further risky sign-in events for user in last 1 hour
- 7-day session activity reviewed and all accessed resources documented
- CAE enabled for user and supported apps
05
Escalation
TIERSESCEscalation Decision Table
| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Single user AiTM confirmed, sessions revoked, no follow-on activity (no inbox rules, no OAuth grants, no sensitive data accessed) | L2 SOC Analyst | Hand off: affected UPN, phishing domain, risk event timestamps, OAuth apps found, session revocation timestamp |
| L2 → IR + CISO | Multiple victims of same campaign OR BEC fraud email sent from account OR sensitive/PII/financial data accessed during compromise window | IR Team + CISO | Treat as potential data breach. Legal notification assessment required (GDPR 72h, PCI 24h). Engage CISO immediately. |
| L2 → Security Engineering | CA policy did not block the session replay — CAE not enforced, token binding not in place, Entra ID Protection not licensed correctly | Security Architecture | Prioritise CAE rollout and phishing-resistant MFA (FIDO2/passkeys) via CA policy for all users |
Authorized security research & penetration testing only. Unauthorized use is illegal. Built by Rudra Verma | Senior Cyber Security Architect & Researcher | CyberHawk Threat Intel
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, SOC playbooks, and hands-on detection engineering content.
"They can't exploit you if you are the Exploit."