How Phishing Kits Bypass MFA and What Email Headers Reveal

An alert fires. A user's Microsoft 365 account just sent a dozen internal phishing emails. You check the sign-in logs and see a successful, MFA-satisfied login from an unfamiliar IP and ASN. The user swears they're not traveling and that they approved the push notification because the login page looked perfect. So what happened? The lock wasn't picked; the attacker simply walked in with a valid key.

This is the reality of Adversary-in-the-Middle (AiTM) phishing. For years, we've told users that MFA is the answer. It is, but not all MFA is created equal. Attackers using reverse-proxy toolkits like Evilginx, Tycoon, or the newly surfaced W3llStore are no longer just after static credentials. They're stealing the entire authenticated session.

The good news? These proxies aren't ghosts. They leave smudges on the glass. By dissecting email headers and correlating them with identity provider logs, we can develop a high-fidelity signal for effective AiTM phishing detection.

It’s Not a Web Page, It's a Live Mirror

Forget the classic phishing page of old. Those were static HTML forms that scraped a username and password, then maybe a TOTP code. They were brittle and often easy to spot. An AiTM setup is fundamentally different. It's a reverse proxy that sits between your user and the legitimate service, like Microsoft 365 or Google Workspace.

When a user clicks the phishing link, they aren't loading a fake page hosted by the attacker. They're loading the *real* login page, but it's being served to them through the attacker's proxy. Every button they click, every character they type, is passed through the proxy to the real service. The service's response is then passed back to the user. The proxy is a man-in-the-middle for the whole conversation.

The Session Token Heist

The true goal here isn’t the user's password. It's the session cookie that the legitimate service issues *after* a successful login. Once the user enters their credentials and satisfies the MFA challenge (which the proxy dutifully passes along), the service returns a session token. This token tells the service, 'This browser is authenticated for the next X hours.' The proxy captures this cookie.

Now the attacker has everything. They can inject that session cookie into their own browser and access the user's account without ever needing the password or the MFA device. From the service's perspective, it's a legitimate, already-authenticated session. The MFA-protected front door was used correctly; the attacker just stole the keycard that was issued afterwards.

Anatomy of a Proxied Email Header

You can't trust what's in the email body, but you can often find truth in the headers. Email headers are the metadata stamped onto a message by every mail transfer agent (MTA) that handles it. In an AiTM attack, the initial phish still has to get to the user's inbox, and the proxy infrastructure often leaves tracks.

Investigating Received and Authentication-Results

The chain of `Received` headers tells the story of an email's journey. You're looking for anomalies. Was the mail injected into your environment from an unexpected source? Does the HELO/EHLO hostname announced by the sending server mismatch its reverse DNS lookup? These are classic signs of a hastily configured sending infrastructure, common with phishing campaigns.

The `Authentication-Results` header is your Rosetta Stone for email authentication. It provides a summary of SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) verdicts in one place. An attacker using a lookalike domain for their phishing link might have perfect email authentication for their sending domain (`notifications@secure-microsft.com`), which can lull automated defenses into a false sense of security. The failure isn't in the email delivery; it's in the payload.

The IP Mismatch Anomaly

Some phishing kits get sloppy. They might inject headers that directly betray the proxy or the victim's true IP address. An `X-Originating-IP` header, for instance, might show the victim’s home IP address, while the `Received` header shows the mail originated from a virtual private server in a different country. That's a massive red flag.

Authentication-Results: mta.example.com; dkim=pass (2048-bit key) header.d=attacker.com; spf=pass smtp.mailfrom=attacker.com; dmarc=pass (p=REJECT) header.from=attacker.com

Look at that DMARC result. A `pass` verdict means the email is authentic... for `attacker.com`. The security problem is that the user associates the email's content—the convincing brand livery and the urgent request—with the legitimate service being impersonated, not the domain in the `From:` field. The user doesn't read the `dmarc=pass`.

When Conditional Access Policies Fire Too Late

Most modern identity providers (IdPs), like Microsoft Entra ID or Okta, offer Conditional Access (CA) policies. These are if-then rules for access control: IF a user signs in from an unmanaged device OR from a risky country, THEN require compliant MFA OR block access. This seems like a perfect defense.

The problem is that AiTM kits are evolving to mimic the victim's environment. They pass the user's `User-Agent` string through the proxy, so from the IdP's perspective, the sign-in might appear to come from the correct browser and OS. The primary signal that remains is the IP address. The login comes from the attacker's proxy server, not the user's expected location.

This can trigger an 'impossible travel' or 'unfamiliar sign-in properties' alert. But these are often detective, not preventative. The alert fires *after* the session token has been issued and stolen. The SOC gets an alert at the same time the attacker gains access. It's a race against time, and you're starting from a disadvantage.

Worse, if the attacker is using a residential proxy service or a compromised machine in the same geographic area as the victim, even the IP-based signals get muddied. The login might look perfectly legitimate to an automated system, avoiding an alert altogether.

Breaking the Proxy: The Power of Phishing-Resistant MFA

So if SMS, TOTP codes, and simple push notifications can be proxied, what's left? The answer lies in methods that cryptographically bind the authentication ceremony to the origin—the domain name of the site you're trying to log into.

This is the domain of FIDO2 and WebAuthn. When a user enrolls a security key (like a YubiKey) or a platform authenticator (like Windows Hello or Face ID), their browser generates a unique public-private key pair for that specific service. The public key is sent to the service, while the private key never leaves the authenticator.

During login, the service sends a challenge. The user's browser tells the authenticator, 'Hey, `login.microsoft.com` is asking you to sign this challenge.' The authenticator checks that the origin it's being asked to sign for matches the origin it registered with. If there's a match, it uses the private key to sign the challenge and sends the response back. The service verifies the signature with the public key, and the user is in.

This is where the AiTM proxy fails. The proxy's domain is `secure-login-portal.net`, not `login.microsoft.com`. When the browser forwards the service's challenge to the authenticator, it presents it as coming from the proxy's origin. The authenticator sees the mismatch and refuses to sign. The attack dead-ends right there. No signature, no login, no session token.

This isn't a policy or a detection; it's a mathematical certainty. The entire model of proxying the login flow is defeated because the authentication is tied directly to the true, legitimate domain name, a detail the proxy cannot fake.

The takeaway

Adversary-in-the-Middle isn't science fiction. It's the new standard for sophisticated phishing campaigns targeting high-value accounts. Relying solely on push-based or code-based MFA gives a false sense of security. The attackers aren't breaking your MFA; they're just making the user complete it for them.

Your defense has to operate on two fronts. First, in the short term, you must get better at hunting for the artifacts of these proxies. That means rigorous email header analysis and correlating suspicious sign-ins with the initial email vectors. Tools that automatically surface these header anomalies, like MailSleuth.AI, can be a crucial part of your detection workflow. Second, the long-term strategic play is to lobby for and deploy phishing-resistant authenticators like FIDO2. Stop playing defense and start making the attack itself impossible.