Not every intrusion needs a zero-day. Some of the most effective attacks we run during red team engagements start with nothing more than a convincing email and a login page that behaves exactly the way the real one does. This field note describes an anonymised, enterprise-style engagement where a single phishing message let us walk straight past multi-factor authentication, capture a live session and reach systems the organisation assumed were well protected. Every identifying detail has been removed. What remains is the attack path, because the pattern matters far more than the target.
The lesson is uncomfortable but simple. Phishing that bypasses MFA is not a theoretical risk. It is a routine technique, it works against the second-factor methods most organisations rely on, and the fix is well understood even if it is not yet widely adopted.
The Setup
The client was a large, well-resourced organisation with a mature security program on paper. Multi-factor authentication was enforced across the workforce, staff completed regular awareness training, and email filtering was in place. Leadership believed, reasonably, that MFA had closed the door on credential-based attacks. The objective agreed for the engagement was to test that belief: could an external adversary gain a foothold through the workforce and reach sensitive internal systems.
Reconnaissance was quiet and entirely passive. Using public sources, professional networking sites and previously exposed corporate email formats, our operators built a picture of the organisation's structure and identified a shortlist of staff in roles that would plausibly receive the message we intended to send. There was no need to guess passwords or scan for exposed services. The workforce itself was the attack surface.
The critical detail from a defensive point of view is that the MFA in use was app-based codes and push approvals. Those are a genuine improvement over passwords alone. They are also exactly the methods that the technique we were about to use is designed to defeat.
The Attack
We deployed an adversary-in-the-middle phishing campaign. Rather than a crude fake login page that only harvests a username and password, this approach uses a reverse proxy that sits transparently between the victim and the real identity provider. Every request the target makes is relayed to the genuine service, and every response comes back through our infrastructure. From the user's perspective, they are logging in to the real system, because in a technical sense they are.
The pretext was mundane and believable, the kind of routine notification staff see and action without a second thought. A small number of recipients clicked through to a lookalike domain. There, they were presented with the authentic login flow, proxied in real time. They entered their credentials. They were prompted for their second factor, and they provided it, because the request was real. The identity provider validated everything and issued a session token.
That token was the prize. Our proxy captured the authenticated session cookie as it passed through. At no point did we need to defeat the second factor directly. The user completed it for us, and we simply stole the result. This is the heart of why phishing that bypasses MFA succeeds against app codes and push notifications: the attacker is not trying to fake the second factor, they are stealing the session that exists after it.
With the captured token imported into a browser on our own system, we were treated as the authenticated user. No further prompt, no password, no code.
What We Reached
Holding a valid session, we moved with the access the compromised account carried. We reached the organisation's email and collaboration platform and read the sorts of internal communications an attacker would use to plan a wider campaign. From there we mapped internal applications the account could reach and identified where sensitive information was stored and who held elevated access.
We want to be precise here and avoid overstating the result. We did not need to demonstrate destruction or data theft to prove the point. The significant finding was qualitative: a single phished session gave an external actor an authenticated presence inside an environment that was assumed to be gated by MFA. From that presence, the paths to escalate, to phish colleagues from a trusted internal mailbox, and to hunt for higher-value access were all open. The door everyone believed was locked was standing open.
Impact
The business implications are best understood in plain terms. An attacker with a foothold like this can read confidential correspondence, impersonate a trusted employee to defraud the organisation or its partners, and quietly expand access until they reach something worth monetising. Because the initial login was legitimate in every technical sense, standard alerting did not flag it as malicious. The intrusion did not look like an attack. It looked like a member of staff going about their day.
For a security team, that is the hard part. The controls were not misconfigured and the staff were not careless. The organisation had done what most guidance told it to do. The gap was in the type of MFA deployed and in the absence of controls that could tell a genuine session from a stolen one.
How to Prevent This
The good news is that this attack path has a direct and proven remedy.
Move to phishing-resistant MFA. FIDO2 security keys and passkeys are cryptographically bound to the legitimate domain. When a user authenticates, their device signs a challenge tied to the real service, so an adversary-in-the-middle proxy cannot complete the handshake or capture anything reusable. This single change neutralises the technique described here for the accounts that adopt it. Prioritise administrators, executives and anyone with access to sensitive systems first.
Enforce strong conditional access. Require that sign-ins come from managed or compliant devices, so a token replayed from an attacker's machine is rejected even if it is valid. Combine this with continuous access evaluation and shorter session lifetimes to shrink the window an attacker has after a theft.
Build detection for stolen sessions. A legitimate login is not the end of the story. Alert on a session used from a new device or unexpected network soon after authentication, on sign-ins that resolve to hosting or proxy infrastructure, and on impossible-travel patterns. Make token revocation fast and rehearsed so a suspected theft can be shut down in minutes.
Test the human and identity layers together. Awareness training helps, but it will not stop a well-crafted proxy campaign on its own, because the user does nothing obviously wrong. The reliable way to know whether your controls hold is to have expert operators safely run the same attack against your environment and show you exactly where it lands.
If your organisation relies on app codes or push approvals and assumes MFA has solved credential attacks, this is the test worth commissioning before someone runs it for real. Our team can safely reproduce this attack path and help you close it. Start a conversation through red team testing, targeted adversary simulation of identity attacks, or get in touch to talk it through. If you suspect a session has already been stolen, our incident response team can help.
Frequently asked questions
How does phishing bypass multi-factor authentication?
Modern phishing that bypasses MFA usually relies on an adversary-in-the-middle proxy rather than a simple fake login page. The attacker sends the target to a domain that transparently relays traffic to and from the real identity provider. The victim genuinely authenticates, including entering a one-time code or approving a push, and the proxy sits in the middle and captures the authenticated session cookie. With that token the attacker replays the session and is treated as logged in, so the second factor never has to be defeated directly. This is why app-generated codes and push approvals, while far better than a password alone, do not stop a determined phishing operator.
What is an adversary-in-the-middle phishing attack?
An adversary-in-the-middle attack places a malicious reverse proxy between the victim and the legitimate service. Every keystroke, code and cookie passes through the attacker's infrastructure in real time. Because the victim is interacting with the real login flow, the experience looks normal and the credentials and second factor are valid. The prize is the session token issued after successful authentication. Once stolen, that token lets the attacker resume the session from their own device without needing the password or the second factor again until the session expires.
Does MFA still matter if attackers can bypass it?
Yes. MFA remains one of the most valuable controls an organisation can deploy, and it stops the overwhelming majority of credential attacks such as password spraying and reuse. The point of this field note is not that MFA is worthless, but that not all MFA is equal. App codes and push notifications are vulnerable to real-time phishing, while phishing-resistant methods such as FIDO2 security keys and passkeys are bound to the legitimate domain and cannot be relayed through a proxy. The goal is to upgrade MFA quality, not to abandon it.
What is phishing-resistant MFA?
Phishing-resistant MFA uses cryptographic authentication that is tied to the real service and the user's device, so it cannot be captured and replayed by a proxy. The main examples are FIDO2 or WebAuthn security keys and passkeys. When a user authenticates, their device signs a challenge that is cryptographically bound to the genuine domain, so an adversary-in-the-middle site simply cannot complete the handshake. Certificate-based authentication offers similar protection. These methods are the practical defence against the session-token theft described in this field note.
How can we detect session token theft?
Session token theft leaves detectable traces even though the login itself looks legitimate. Watch for a session being used from a new device, location or network shortly after authentication, sign-ins that resolve to hosting or proxy infrastructure rather than expected user networks, and impossible-travel patterns. Conditional access policies can require compliant or managed devices, which breaks a stolen token used from an attacker's machine. Shorter session lifetimes, continuous access evaluation and prompt token revocation all reduce the window an attacker has to act.