Introduction#

Cybersecurity defenses have significantly evolved over the past decade, with multi-factor authentication (MFA) becoming a widely adopted method to reduce the risk of credential theft. However, as defenses improve, so do the tactics of attackers. One such tactic that has rapidly gained traction is the Adversary-in-the-Middle (AiTM) attack. Unlike traditional phishing attacks that simply collect usernames and passwords, AiTM attacks go further by intercepting session cookies and tokens — effectively bypassing MFA and allowing full account takeover.

In this article, we’ll break down exactly what AiTM is, how it works, and what organizations can do to detect and defend against it.

Learn how Adversary-in-the-Middle (AiTM) attacks bypass MFA by hijacking session tokens. This guide includes real-world examples, detection strategies, and KQL queries.

1. Phishing Site Setup#

Attackers use phishing kits such as Evilginx2 or Modlishka to spin up a fake login page that looks identical to a legitimate service (e.g., Microsoft 365). These tools function as reverse proxies, forwarding requests and responses between the user and the real authentication provider in real time. SSL certificates are also commonly deployed on these proxy sites to lend credibility, using Let’s Encrypt to generate seemingly valid HTTPS connections.

2. Victim Interaction#

The attacker crafts a phishing lure—usually an email or SMS—containing a link to the spoofed site. The content may claim the user’s session has expired or that they need to log in to verify activity. Upon clicking the link, the user is routed to the reverse proxy, which mirrors the legitimate login page, complete with branding, form fields, and even security indicators like lock icons in the browser.

3. Credential and MFA Harvesting#

Once the user enters their username and password, the reverse proxy forwards these credentials in real time to the actual login portal. This triggers the real MFA challenge (e.g., push notification, SMS, or TOTP). The user completes this step believing it’s legitimate, while the attacker proxies the MFA response through the backend, allowing full authentication to succeed. This gives the attacker access without ever needing the user’s MFA device again.

An important note here: AiTM attacks are not breaking MFA—they’re bypassing it by capturing the session after authentication is completed.

4. Session Hijacking#

Once MFA is successfully completed, the legitimate service returns a session token to the browser — which the attacker intercepts. With this token, the attacker can now impersonate the user and access their account without needing to reauthenticate.

This is where AiTM stands out. By stealing session tokens, attackers bypass MFA entirely and gain full access until the session expires or is revoked.

Key Indicators of AiTM Activity#

• Token Replay Detection: If the same authentication token is used across different geolocations or devices, it suggests token theft and reuse — a hallmark of AiTM.

• MFA Satisfied by Token Only: Sign-ins where MFA requirements are marked as “Previously satisfied” but have no associated interactive authentication could indicate a stolen session token.

• Impossible Travel: Analyze sign-ins where the time difference and geographic distance between events make it impossible for a real user to travel that fast. This is often indicative of token theft and use from a different region.

• Long-Lived Session Tokens: Session tokens should expire within a standard time window. If a token remains valid far longer than typical, it could mean an attacker is maintaining persistence.

• Browser or Device Mismatch: Sudden changes in user-agent strings or device fingerprints during active sessions may indicate an AiTM proxy in play.

• Unusual or Obsolete User Agents: Logins using outdated or uncommon user-agent strings (e.g., Internet Explorer, old Android WebViews, or scripted browsers) may indicate proxy-based access from phishing kits or automation tools used by attackers.

Advanced Techniques for AiTM Detection#

• Session Token Anomaly Modeling: Use machine learning or KQL-based baselines to track normal session durations, IP ranges, and device profiles for each user.

• Correlate Authentication and Authorization Logs: Look for disjointed authentication logs (e.g., login from one IP) and resource access logs (e.g., SharePoint access from another IP), which may reveal session hijacking.

• Real-Time Proxy Behavior Analysis: Proxy-based AiTM attacks often introduce subtle latency, TLS certificate mismatches, or header anomalies. Analyzing network logs for these fingerprints may surface malicious middleboxes.

• Cloud App Sign-in Review: Platforms like Microsoft 365 and Google Workspace log detailed session and sign-in metadata. Look for discrepancies in device ID, session IDs, and IP correlations.

Organizations should enable detailed auditing and centralize log collection via a SIEM like Microsoft Sentinel to correlate authentication events with resource access and endpoint behavior. Using these techniques, security teams can more reliably identify and investigate AiTM attacks before data loss or lateral movement occurs.

1. Detect Non-Interactive Sign-ins (Token Reuse)#

SigninLogs
| where ResultType == 0
| where AuthenticationRequirement == "SingleFactor" and AuthenticationDetails has "Previously satisfied"
| where ConditionalAccessStatus == "success"
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, AuthenticationDetails

2. Impossible Travel Detection#

let threshold = 5000; // in kilometers
SigninLogs
| where ResultType == 0
| project UserPrincipalName, IPAddress, Location, TimeGenerated
| join kind=inner (
    SigninLogs
    | where ResultType == 0
    | project UserPrincipalName, IPAddress, Location, TimeGenerated
) on UserPrincipalName
| where abs(datetime_diff("minute", TimeGenerated1, TimeGenerated2)) < 60
| extend Distance = geo_distance_2points(Location1, Location2)
| where Distance > threshold

3. Long-Lived Session Tokens#

AADTokenLogs
| where TimeGenerated > ago(7d)
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by TokenIdentifier, UserPrincipalName
| extend DurationHours = datetime_diff("hour", LastSeen, FirstSeen)
| where DurationHours > 12

These queries can be modified to fit your specific log schema and alert thresholds. The goal is to surface suspicious behavior that mimics what AiTM campaigns typically produce.

1. Enable Conditional Access with Sign-In Risk Evaluation#

Microsoft Entra (formerly Azure AD) allows for granular access policies that consider user risk, location, device compliance, and token age. Blocking access based on sign-in risk can stop attackers even after token theft.

2. Implement Continuous Access Evaluation (CAE)#

CAE is a Microsoft feature that automatically revokes tokens based on conditions such as user logout, password change, or token misuse. It dramatically reduces the window of exploitation for stolen tokens.

3. Use Device-Bound Access Tokens#

Binding session tokens to a specific device ensures they cannot be reused elsewhere. This feature is rolling out across Microsoft 365 tenants and should be enabled wherever possible.

4. Leverage Defender for Cloud Apps#

MCAS provides real-time session control and app governance, allowing security teams to block risky behavior mid-session. This includes alerting on token theft patterns and automatic session termination.

5. Educate Users on AiTM Phishing#

Even the most technical controls benefit from user awareness. Train employees to recognize phishing tactics, especially those that mimic login portals with push MFA prompts.