How to Detect AiTM Adversary-in-the-Middle Phishing Attacks
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Traditional MFA defeat requires obtaining both the password and the one-time code simultaneously. AiTM phishing bypasses this entirely: the attacker's reverse proxy passes the victim's credentials and MFA response to the legitimate authentication server, receives the authenticated session cookie, and uses that cookie to access the account: without ever needing to crack MFA.
The victim sees a successful login to what appears to be a legitimate Microsoft page. The attacker simultaneously gains full access to the victim's account. The attack happens in seconds: phishing email → victim enters credentials and MFA on Evilginx2 proxy → attacker gets session cookie → account accessed from attacker's location within 30-120 seconds.
How AiTM Phishing Works
Evilginx2 attack flow:
1. Attacker sets up Evilginx2 on a VPS:
- Configures a phishlet for Microsoft 365 (login.microsoft-corp.net vs login.microsoftonline.com)
- Creates a convincing redirect URL: users.microsoft-corp.net/login
2. Phishing email sent to target:
Subject: "Action Required: Verify your Microsoft account"
Link: https://login.microsoft-corp.net/... (attacker's Evilginx2 server)
3. Victim clicks link and sees a real Microsoft login page:
- Evilginx2 proxies all traffic to login.microsoftonline.com in real-time
- Victim enters credentials → Evilginx2 forwards to Microsoft
- Microsoft prompts for MFA → Evilginx2 presents MFA prompt to victim
- Victim completes MFA → Microsoft issues session cookie
- Evilginx2 captures the session cookie
4. Attacker uses the captured cookie:
- Imports cookie into browser
- Accesses victim's Microsoft 365 account without any MFA prompt
- Session is valid until it expires (typically 1-24 hours)
- Immediately: sets up mail forwarding rule, exfiltrates data, creates persistence
What is captured:
Evilginx2 terminal output:
[09:17:22] [inf] [session] [user: john.smith@corp.com] [session_token: eyJ0eXAiOiJ...]
[09:17:22] [inf] [session] [auth_tokens]
- access_token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
- refresh_token: 0.ARoA...
- session_cookie: ESTSAUTHPERSISTENT=... ← This cookie lets attacker bypass MFA
Detection Signal 1: Impossible Travel
The most reliable AiTM detection signal: the user completes MFA from their real location (e.g., New York), but the stolen session is used milliseconds later from the attacker's location (e.g., Moscow). The time gap between the legitimate authentication and the attacker's first action is typically 30-120 seconds: physically impossible travel.
Entra ID built-in detection:
Microsoft Entra ID Identity Protection includes "Impossible travel" risk detection (available in P2 licenses): it flags when the same session is used from geographically impossible locations.
Microsoft Entra admin center > Protection > Identity Protection >
Risk Detections: "Impossible travel" and "Atypical travel"
For high-confidence AiTM:
Risk level: High
Detection type: Unfamiliar sign-in properties, Token issuer anomaly
Sentinel KQL: impossible travel for Microsoft 365 sign-ins:
// Detect: same user authenticating from two locations within 1 hour
// where distance implies physically impossible travel
let MaxTravelSpeed = 900; // km/h (faster than any commercial flight)
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0" // Successful sign-ins only
| extend IPCountry = tostring(LocationDetails.countryOrRegion)
| summarize
Locations = make_list(IPCountry),
IPs = make_list(IPAddress),
Times = make_list(TimeGenerated)
by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1
// Alert on sessions from different countries in the same hour
| where Locations[0] != Locations[1]
| project UserPrincipalName, Locations, IPs, Times
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detection Signal 2: Suspicious Post-Auth Behavior
Attackers typically take the same actions within seconds to minutes of gaining session access: before the victim realizes their account is compromised. These rapid post-authentication actions are highly detectable.
Detect inbox rule creation (mail exfiltration setup):
// Alert: inbox forwarding rule created within 30 minutes of sign-in from new location
let SuspiciousSignIns = SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| where RiskState != "none" or RiskLevelAggregated != "none"
| project UserPrincipalName, SignInTime = TimeGenerated, SignInIP = IPAddress;
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where Parameters has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo",
"DeleteMessage", "MarkAsRead")
| join kind=inner SuspiciousSignIns on $left.UserId == $right.UserPrincipalName
| where abs(datetime_diff('minute', TimeGenerated, SignInTime)) < 30
| project TimeGenerated, UserId, Operation, Parameters, SignInIP
Detect OAuth app consent grants (persistence establishment):
// Alert: new application consent granted after suspicious sign-in
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Consent to application"
| where Result == "success"
// Attacker grants consent to a rogue OAuth app for persistent access
// (survives password reset: token persists until app is removed)
| join kind=inner (
SigninLogs
| where RiskLevelAggregated in ("medium", "high")
| project UserPrincipalName, RiskTime = TimeGenerated
) on $left.InitiatedBy.user.userPrincipalName == $right.UserPrincipalName
| where abs(datetime_diff('minute', TimeGenerated, RiskTime)) < 60
| project TimeGenerated, InitiatedBy, TargetResources
Detect unfamiliar device access:
// Alert: sign-in from device not seen in last 30 days for this user
let KnownDevices = SigninLogs
| where TimeGenerated between (ago(30d) .. ago(1d))
| summarize KnownDeviceIds = make_set(DeviceDetail.deviceId) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| where DeviceDetail.deviceId != ""
| join kind=leftouter KnownDevices on UserPrincipalName
| where not (DeviceDetail.deviceId in (KnownDeviceIds))
// Unknown device for this user:
| project TimeGenerated, UserPrincipalName, DeviceDetail, IPAddress, Location
Prevention: Phishing-Resistant MFA
The only complete defense against AiTM: FIDO2/WebAuthn hardware keys
FIDO2 authentication is cryptographically bound to the relying party's domain: when the user authenticates via Evilginx2's proxy domain, the FIDO2 key refuses to authenticate because the domain does not match the registered origin. This makes AiTM impossible for FIDO2-enrolled users.
Microsoft Entra: Enforce FIDO2 for high-risk users
Authentication Methods > FIDO2 Security Keys: Enabled
Target: All users (or Tier 0 admins first)
Conditional Access policy: "Require phishing-resistant MFA"
Conditions: All users, All cloud apps
Grant: Require authentication strength = Phishing-resistant MFA
(Phishing-resistant = FIDO2 or Windows Hello for Business only)
Enforce Conditional Access token binding (additional mitigation):
Microsoft Entra > Conditional Access > Session Controls >
"Sign-in frequency": Every 1 hour (reduces stolen session lifetime)
"Persistent browser session": Never persistent (session expires on browser close)
For high-sensitivity workloads:
"Token protection" (preview): Bind token to the specific device
→ Stolen session cookie cannot be used from a different device
Block suspicious IP ranges and unfamiliar countries:
Conditional Access > Named Locations > Create country-based location
Policy: Block sign-in from countries your org never operates in
This forces attackers to use residential proxies in the victim's country,
which are more expensive and less available than VPS infrastructure
Enable Entra ID Identity Protection (P2):
Identity Protection > User risk policy:
Trigger: User risk = High
Action: Require password change
Identity Protection > Sign-in risk policy:
Trigger: Sign-in risk = Medium or above
Action: Require MFA (or block for high)
This automatically blocks access when AiTM signals are detected
The bottom line
AiTM phishing bypasses MFA by proxying the full authentication session and stealing the resulting cookie: the victim completes real MFA, the attacker gets the session. Detection focuses on post-authentication anomalies: impossible travel (session used from two geographically impossible locations in < 1 hour), inbox forwarding rule creation within 30 minutes of a risky sign-in, OAuth app consent grants from compromised sessions, and unfamiliar device sign-ins. The only complete prevention is phishing-resistant MFA: FIDO2 hardware keys or Windows Hello for Business: which cryptographically binds authentication to the legitimate domain and cannot be proxied.
Frequently asked questions
How does AiTM phishing bypass multi-factor authentication?
AiTM phishing uses a reverse proxy (Evilginx2, Modlishka) that sits between the victim and the real authentication server. The victim's credentials and MFA response are forwarded to the real server in real-time: so MFA succeeds legitimately. The proxy intercepts the resulting authenticated session cookie before returning the user to the real site. The attacker then uses this cookie to access the account without needing the password or MFA code. The cookie remains valid for hours or days.
What is the best defense against AiTM phishing attacks?
FIDO2 hardware security keys (YubiKey, Titan) or Windows Hello for Business are the only MFA types that defeat AiTM phishing: the authentication is cryptographically bound to the legitimate domain URL, so an Evilginx2 proxy on a different domain cannot complete the FIDO2 ceremony. In Microsoft Entra, enforce phishing-resistant MFA via Conditional Access authentication strength policies. Additionally, enable Identity Protection risk policies to block or challenge sessions flagged for impossible travel or token anomalies.
What is Evilginx2 and how does an AiTM phishing attack work technically?
Evilginx2 is an open-source adversary-in-the-middle framework that proxies the real authentication flow between the victim and the legitimate identity provider. The attack flow: the victim receives a phishing link to an Evilginx2 server configured with a phishlet for the target service (Microsoft 365, Google, Okta). The victim authenticates normally — including completing MFA — and the Evilginx2 proxy captures the session cookie from the server's response after successful authentication. The attacker then injects the captured cookie into their browser, bypassing all authentication. The victim sees the real login page and completes real MFA, so they suspect nothing. All TOTP codes, SMS codes, and push notification MFA types are defeated because MFA happens before the session cookie is issued.
How do I detect an AiTM phishing attack in Microsoft 365 audit logs?
Detection signals in Entra ID sign-in logs and Microsoft 365 Defender: sign-in with a new IP immediately followed by activity from a different IP in the same session (the attacker used the stolen cookie from a different location than the victim authenticated from); session age anomaly — the session's first activity timestamp is seconds after a legitimate user sign-in event, with a different IP; UserAgent mismatch — victim authenticated from Chrome on Windows, but first session activity shows a different user agent string; and Microsoft Defender for Cloud Apps alerts for 'Impossible travel' and 'Session from anonymous IP'. The most reliable detection: compare the sign-in IP (from the authentication event) against the IP of the first audit log action in that session — if they differ, the session was hijacked.
What is Continuous Access Evaluation (CAE) and does it prevent AiTM attacks?
Continuous Access Evaluation (CAE) is a Microsoft feature that allows Azure AD to revoke access tokens in near-real-time when security conditions change: the user is disabled, password is changed, risk is detected, or network location changes. CAE-capable applications (modern Microsoft 365 clients) receive long-lived tokens (up to 28 hours) but can have them revoked within minutes if a risk event occurs. CAE partially mitigates AiTM: if Identity Protection detects the stolen session token's unusual location and marks the user as high-risk, CAE-enabled apps will force re-authentication within minutes. However, legacy apps and non-CAE apps retain sessions until the original token expires. Combine CAE with phishing-resistant MFA, risk-based Conditional Access, and session anomaly detection for comprehensive coverage.
What should the first 30 minutes of incident response look like when you detect an AiTM-compromised account in Microsoft 365?
AiTM response is time-critical because attackers establish mail forwarding rules and create OAuth app consents within minutes of gaining session access. First 30 minutes: (1) Immediately disable the Entra ID account using Disable-MgUser -- a password reset alone is insufficient because the attacker's stolen refresh token may survive a password reset if CAE is not active on the client; (2) Explicitly revoke all active sessions with Revoke-MgUserSignInSession to invalidate all outstanding tokens; (3) Query the Unified Audit Log for all actions taken during the compromised session window, specifically checking for New-InboxRule, Set-Mailbox -DeliverToMailboxAndForward, and consent-to-application operations; (4) Remove any inbox forwarding rules created during the window via Remove-InboxRule; (5) Review and remove OAuth app consents granted during the compromised session in the Entra admin center under Enterprise Applications. After remediation, re-enable the account only after the user completes MFA re-enrollment with a phishing-resistant method, and review the affected mailbox for any data exfiltrated during the window.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.