Adversary-in-the-Middle Phishing Proxies: How Modern Frameworks Hijack MFA Sessions

Interview with Dr. Aris Thorne: Analyzing Adversarial AiTM Proxies

Adversary-in-the-Middle (AiTM) phishing frameworks have evolved from experimental tools into automated platforms targeting enterprise identity infrastructure. Recent campaign analysis shows frameworks like Mirage2FA hijacking authenticated Microsoft 365 sessions at scale. I spoke with Dr. Aris Thorne, Principal Security Researcher at VaultSec Labs, about how these proxies bypass authentication controls and what engineering teams must do to neutralize them.

Q: How do modern adversary-in-the-middle phishing frameworks bypass standard multi-factor authentication controls?

Answer: Traditional phishing static pages clone login portals to steal passwords. AiTM frameworks work as transparent reverse proxies sitting between the target user and the legitimate identity provider. When a user clicks a malicious link, the proxy fetches the actual login page from the identity service in real time, serving it to the victim while relaying user input back to the backend service.

When the identity provider prompts for a push notification or time-based one-time password (TOTP), the proxy forwards the prompt directly to the victim. Once the user completes the authentication prompt, the identity provider returns session cookies to the browser. The proxy intercepts these cookies, stores them in an attacker-controlled database, and completes the session establishment. Because the identity provider sees a valid multi-factor response, access is granted without raising immediate alerts.

Q: What technical indicators in network logs reveal an active AiTM session interception?

Answer: Detection relies on spotting discrepancies between authentication transport parameters and subsequent API telemetry. An AiTM proxy routes traffic through intermediate server IP addresses, creating an immediate network anomaly. The initial authentication log records the IP address of the proxy server, while the client browser might initiate background telemetry requests from its real residential IP address.

Security teams can detect these anomalies by inspecting sign-in logs for rapid IP address switches, unexpected User-Agent header drift within a single session, and mismatched TLS cipher fingerprints. You can extract suspicious log records from identity provider export files using command-line utilities:

jq -r '.records[] | select(.resultType == 0) | [.createdDateTime, .userPrincipalName, .ipAddress, .location.city, .clientAppUsed] | @tsv' signin_audit.json | sort -k2,2 -k1,1

Analyzing these record dumps exposes instances where a single user principal registers successful authentications from disparate geographic regions or unknown cloud provider Autonomous System Numbers within seconds.

Interview Insights: Architectural Mitigations for IAM Hardening

Q: Why do conventional authentication methods fail here, and what architectural changes stop proxy interception?

Answer: Password-plus-TOTP setups fail because authentication artifacts are decoupled from the underlying TLS connection domain. The user verifies their identity to the proxy, thinking it is the real portal, and TOTP codes are valid regardless of which domain origin receives them.

To eliminate this vector, identity architecture must move to FIDO2 WebAuthn authentication protocols. WebAuthn enforces cryptographic domain binding inside the browser browser engine. During the FIDO2 ceremony, the browser signs a challenge containing the actual origin hostname in the address bar. If the user is on a fake domain hosted by an AiTM proxy, the signature validation fails at the identity provider because the origin domain does not match the registered relying party identifier. Device Bound Session Credentials (DBSC) extend this binding to post-authentication cookies, preventing token theft from compromising downstream sessions.

Session cookies remain prime targets for network adversaries. If your identity provider does not enforce strict origin binding at the browser layer, an adversary proxy converts every valid MFA prompt into a stolen credential.

Q: What response actions should security engineers take when a stolen session token is confirmed?

Answer: Speed is critical when invalidating compromised sessions. Password resets alone do not terminate active HTTP session cookies issued prior to the reset. Infrastructure engineers must revoke active OAuth refresh tokens and invalidate existing session caches across the tenant.

Enforce Continuous Access Evaluation (CAE) to force real-time policy re-evaluation whenever IP address changes occur. Combine CAE with strict Conditional Access policies that restrict portal access to compliant, managed devices carrying hardware-backed certificates. Forcing device compliance checks blocks session tokens reused on unauthorized attacker hardware, stopping session replay attacks even if the raw cookie string leaks.