Performing Adversary In The Middle Phishing Detection

Performing Adversary-in-the-Middle Phishing Detection

Overview

Adversary-in-the-Middle (AiTM) phishing attacks use reverse-proxy infrastructure to sit between the victim and the legitimate authentication service, intercepting both credentials and session cookies in real time. This allows attackers to bypass multi-factor authentication (MFA). The most prevalent PhaaS kits in 2025 include Tycoon 2FA, Sneaky 2FA, EvilProxy, and Evilginx. Over 1 million PhaaS attacks were detected in January-February 2025 alone. These attacks have evolved from QR codes to HTML attachments and SVG files for link distribution.

When to Use

• When conducting security assessments that involve performing adversary in the middle phishing detection
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Detection Gaps & Validation

• MFA "success" is not safety: AiTM kits (Evilginx, EvilProxy, Tycoon 2FA, Sneaky 2FA) relay the real login, so the sign-in shows MFA satisfied while the attacker steals the session cookie - a successful MFA event does NOT mean the session is the legitimate user.
• Push/OTP/SMS are all bypassable: only origin-bound FIDO2/WebAuthn (or Windows Hello, CBA) resists AiTM because authentication is bound to the real domain - SMS/voice/push MFA are intercepted by the proxy.
• The signal is the cookie, not the password: alert on a session used from a different IP/ASN/device than the authentication within minutes, on token replay, and on impossible travel between auth and session use.
• Post-compromise tells: inbox-rule creation, new MFA-method registration, and OAuth app consent immediately after sign-in are high-fidelity AiTM follow-ups - monitor all three.
• Infrastructure evasion: kits use Cloudflare Turnstile, CAPTCHA, random URLs, and IP rotation to dodge crawlers and serve a real Microsoft/Okta-looking page - judge on domain/cert and reverse-proxy behavior, not the login screenshot.
• Validate + FP tuning: simulate an AiTM sign-in and confirm Conditional Access/CAE revokes or blocks session replay, FIDO2 blocks capture, and SIEM fires on cookie-reuse-from-new-IP. Baseline VPN/CGNAT and roaming users to avoid flagging legitimate IP changes.

Prerequisites

• Azure AD / Entra ID Conditional Access policies
• SIEM with authentication log ingestion (Azure AD sign-in logs)
• Web proxy with SSL inspection and URL categorization
• Endpoint Detection and Response (EDR) solution
• FIDO2/phishing-resistant MFA capability

Key Concepts

How AiTM Works

1. Victim receives phishing email with link to attacker-controlled domain
2. Attacker domain runs reverse proxy that mirrors legitimate login page
3. Victim enters credentials on proxied page; credentials captured in transit
4. Reverse proxy forwards credentials to real authentication service
5. MFA challenge sent to victim; victim completes MFA on proxied page
6. Attacker captures session cookie returned by legitimate service
7. Attacker replays session cookie to access victim's account without MFA

Major AiTM Kits (2025)

Detection Indicators

• Authentication from unusual IP not matching user profile
• Session cookie reuse from different IP/device than authentication
• Login page served from non-Microsoft/non-Google infrastructure
• CDN requests to legitimate auth providers from phishing domains
• Impossible travel between authentication and session usage

Workflow

Step 1: Deploy Phishing-Resistant MFA

• Implement FIDO2 security keys or Windows Hello for Business for high-value accounts
• Configure Conditional Access to require phishing-resistant MFA for admins
• Enable certificate-based authentication where possible
• Disable SMS and voice MFA for privileged accounts
• AiTM cannot intercept FIDO2 because authentication is bound to origin domain

Step 2: Configure Conditional Access Policies

• Require compliant/managed device for sensitive application access
• Block authentication from anonymous proxies and Tor exit nodes
• Enforce token binding to limit session cookie replay
• Configure continuous access evaluation (CAE) for real-time token revocation
• Implement sign-in risk policies that require re-authentication for risky sign-ins

Step 3: Build AiTM Detection Rules

• Alert on sign-in followed by session from different IP within 10 minutes
• Detect authentication where proxy IP does not match user's expected location
• Monitor for impossible travel patterns in session usage
• Alert on inbox rules created immediately after authentication (common post-compromise)
• Detect new MFA method registration from suspicious sign-in

Step 4: Monitor Web Proxy for AiTM Infrastructure

• Log and analyze DNS queries to newly registered domains
• Detect connections to known PhaaS infrastructure IPs
• Alert on authentication page backgrounds loaded from legitimate CDNs through proxy domains
• Monitor for SSL certificates issued to domains mimicking corporate login pages
• Block access to known EvilProxy/Evilginx infrastructure via threat intelligence

Step 5: Implement Post-Compromise Detection

• Alert on mailbox forwarding rules created after suspicious authentication
• Detect OAuth app consent after AiTM sign-in
• Monitor for email sending patterns indicating BEC follow-up
• Alert on SharePoint/OneDrive mass download after session hijack
• Track lateral movement from compromised account

Tools & Resources

• Microsoft Entra ID Protection: Risk-based Conditional Access
• Azure AD Sign-in Logs: Authentication event analysis
• Okta ThreatInsight: AiTM proxy detection at IdP level
• Sekoia TDR: AiTM campaign tracking and intelligence
• Evilginx (defensive): Understanding attack mechanics for detection

Validation

• Phishing-resistant MFA blocks AiTM session capture in test scenario
• Conditional Access denies session replay from different device/IP
• SIEM alerts fire on simulated AiTM sign-in patterns
• Web proxy blocks connections to known PhaaS infrastructure
• Post-compromise rules detect inbox rule creation after suspicious auth