The Proxy Pandemic: Why Modern Phishing Ignores Your MFA

Adversary-in-the-Middle (AiTM) attacks bypass Multi-Factor Authentication (MFA) by positioning a proxy server, such as Evilginx2, between the victim and the legitimate login service. Unlike traditional phishing that steals passwords, AiTM proxies capture the live session cookie issued after a successful MFA challenge. Since the attacker possesses the authenticated session token, they can impersonate the victim directly in a new browser session without needing to provide credentials. Defeating this threat requires applying the Verify Before You Click protocol using tools like phishpond.io to analyze URLs, combined with phishing-resistant hardware authentication like FIDO2.

A veteran systems administrator recently watched in real-time as an executive account was compromised, despite the user correctly entering a hardware-generated six-digit code. There were no failed login attempts in the logs. There were no alerts for a wrong password. To the identity provider, the login looked perfect.

This is the chilling efficiency of Adversary-in-the-Middle (AiTM) phishing. The security industry spent a decade telling users to “look for the green lock” and “enable MFA,” but the threat landscape has pivoted. Today, the green lock is a standard feature of the attack, and MFA is often just a minor speed bump for a well-configured reverse proxy.

The Deep Dive: Decoding the Proxy Engine

To understand why traditional defenses are failing, we have to look under the hood of the modern phishing kit. The current gold standard for these attacks is Evilginx2, a standalone pre-auth proxy written in Go. While it functions as its own web server, many advanced threat actors use Nginx as a sophisticated shield in front of it.

The Role of Nginx in Stealth Operations

In a high-authority attack scenario, Nginx acts as the primary entry point. Attackers configure Nginx as a reverse proxy to handle several critical tasks before a victim even sees a login page. First, Nginx handles SSL/TLS termination, often using legitimate certificates from providers like Let’s Encrypt to ensure the secure icon appears in the browser.

Second, Nginx is used for traffic scrubbing. By using Geo-IP blocking and header analysis, the attacker can ensure that only real users from specific regions can access the phishing page. If a security researcher or an automated bot from a cybersecurity firm tries to scan the URL, Nginx silently redirects them to a benign site like Google or Wikipedia. This makes the phishing infrastructure nearly invisible to traditional automated scanners, which is exactly why manually checking suspicious links through phishpond.io is so vital.

Pro Tip: Because Nginx can hide these servers from automated bots, manual verification is your strongest defense. Before clicking any login link from an email or text, paste the URL into the PhishPond Link Analyzer to detect hidden proxy signatures and domain age anomalies.

Understanding the Phishlet Logic

The true brain of the AiTM attack is the “phishlet.” These are YAML-based configuration files that act as a set of instructions for the proxy server. A phishlet tells the server which legitimate website to mirror, which specific URLs to rewrite on the fly, and most importantly, which cookies are the prize.

When a victim clicks a link, they are connected to the attacker’s proxy. The proxy fetches the real Microsoft 365 or Google login page and presents it to the user. Every keystroke is passed through the proxy to the real service. When the real service sends back an MFA challenge, the proxy passes that to the user too. The user completes the MFA on their phone, the proxy relays that success to the real service, and the real service issues a session cookie. The proxy captures this cookie, logs it to a database, and the attacker now has a fully authenticated session that bypasses the need for any future passwords or MFA prompts.

Data Visualization: The Hierarchy of MFA Vulnerability

Not all Multi-Factor Authentication is created equal. The table below categorizes common MFA methods by their susceptibility to proxy-based hijacking.

Actionable Advice for Identity Defense

Moving from vulnerable to resilient requires a shift in how we handle identity. If you are responsible for an organization’s security, or just trying to protect your own accounts, these steps are non-negotiable.

1. The “Verify Before You Click” Protocol

The absolute easiest way to defeat an AiTM proxy is to never load it in your browser. These attacks rely on you clicking a link that looks close to the real thing (e.g., login-microsoft-secure.com instead of login.microsoft.com). If you receive an urgent request to log in, copy the URL and paste it into phishpond.io. Our analysis will tell you if the domain was registered yesterday or if it is masking a proxy server.

2. Transition to Phishing-Resistant MFA

The only technical way to stop an AiTM proxy is to use authentication that is origin-bound. FIDO2 and WebAuthn standards involve a cryptographic handshake between the browser and the hardware. If the URL in the address bar does not perfectly match the legitimate login domain, the hardware key will detect the mismatch and refuse to sign the challenge. This stops the attack at the protocol level.

3. Implement Conditional Access with Device Compliance

You should never trust a login based on credentials alone. Use Conditional Access policies to require that a device is compliant or hybrid joined before it can access sensitive resources. Because an attacker’s proxy server is not a managed device in your environment, the login will be blocked even if the attacker has a valid, stolen session cookie.

4. Reduce Session Lifetimes and Use CAE

The value of a stolen cookie is determined by how long it stays active. Shorten your session time-to-live (TTL) for high-risk applications. Additionally, enable Continuous Access Evaluation (CAE). CAE allows services like Microsoft 365 to instantly revoke a session if the user’s IP address changes unexpectedly.

5. Hunt for Proxy Indicators in Logs

Threat hunters can look for specific anomalies in sign-in logs. Look for instances where a user’s User Agent string changes mid-session or where the source IP address belongs to a known hosting provider rather than a residential ISP. Modern AiTM kits often leave subtle footprints in the HTTP headers that can be surfaced through KQL queries in Microsoft Sentinel.

// Identify User Agent changes within a single SessionID
SigninLogs
| where TimeGenerated > ago(24h)
| summarize UA_Count = dcount(UserAgent), UA_List = make_set(UserAgent) by SessionId, UserPrincipalName
| where UA_Count > 1
| project TimeGenerated, UserPrincipalName, SessionId, UA_List

Technical Definitions

• Reverse Proxy: A server that sits between a client and a web server, forwarding client requests to the web server and returning the server’s responses to the client.
• Session Hijacking: The exploitation of a valid computer session to gain unauthorized access to information or services.
• Origin Binding: A security mechanism in FIDO2 that ensures a credential can only be used with the specific website domain it was originally created for.
• Bearer Token: A security token that gives access to the bearer. If an attacker steals a bearer token like a session cookie, they can use it without providing any other proof of identity.
• TLS Termination: The process of decrypting encrypted traffic before it is passed to a backend server, often performed by Nginx to inspect or redirect traffic.

The Next Frontier of Identity Defense

We have reached a point where the human element can no longer be the only defense against phishing. Expecting a distracted employee to notice a slightly malformed URL while they are toggling between twenty browser tabs is a recipe for failure. The technical sophistication of tools like Evilginx and the cloaking capabilities of Nginx have leveled the playing field for attackers. Our defense must move into the architecture itself. By adopting the Verify Before You Click mindset, enforcing strict device compliance, and utilizing tools like phishpond.io, we can ensure that even if an attempt is made, the attacker is left holding useless data.

Sources and Further Reading

• cisa guide on phishing-resistant mfa: implementing phishing-resistant mfa
• microsoft threat intelligence: detecting and mitigating aitm phishing
• fido alliance knowledge center: how fido standards stop phishing
• nginx reverse proxy guide: configuring an nginx reverse proxy
• phishpond.io: link analysis and safe browsing tools

← All posts · Home