This is an anonymized field note from a red team engagement. Details that would identify the client have been removed; the attack path is reported as it happened, because the same path is available against a large proportion of the organizations we assess.
The Setup
The client had done the things that are usually recommended. Multi-factor authentication was enforced across the workforce, security awareness training ran regularly, and the reported phishing rate in their internal simulations was respectable. Leadership considered credential phishing a solved problem, which is a common and understandable position.
The MFA method in use was app-based push approval. That detail is the whole story.
The Attack
Reconnaissance identified the organization's authentication portal and a set of employees whose roles suggested useful access. The pretext was mundane by design: a notification about a document requiring review, matching the naming and tone of the collaboration platform the organization actually used.
The link did not lead to a fake login page in the traditional sense. It led to a reverse proxy that relayed every request to the genuine authentication service and every response back. The victim saw the real login page, because it was the real login page. They entered their password, which the proxy passed through. The genuine MFA prompt arrived on their phone, from the genuine service, and they approved it, because they had genuinely just tried to log in.
At that moment the authentication service issued a session token, and the proxy captured it on its way past. The victim was redirected onward to a real document and noticed nothing.
The entire attack required no vulnerability. Every component behaved exactly as designed.
What We Reached
Replaying the token gave an authenticated session as that user, with MFA already satisfied. From there:
- Full mailbox access, including several years of correspondence and the credential reset messages an attacker uses to pivot into other services.
- The organization's directory, which is where reconnaissance stops being external and becomes precise.
- Cloud file storage, containing among other things a network documentation folder and a spreadsheet of service account credentials maintained by a departed administrator.
- Single sign-on access to a number of connected applications, because the compromised identity was the key to all of them.
Those service account credentials were the escalation. Within a further day, operators held privileged access to internal infrastructure, having started from one person clicking one plausible link.
Impact
The objective was reached inside a week. More instructive than the speed was the silence: the activity generated authentication events that looked entirely normal, because they were normal, and nothing in the environment distinguished a legitimate session from a replayed one.
The organization's detection was oriented toward malware and toward failed authentication. This attack produced neither.
How to Prevent This
The controls that would have stopped or contained this are specific, and the first one is decisive.
- Deploy phishing-resistant MFA. FIDO2 security keys and passkeys bind authentication to the legitimate domain cryptographically. The proxy sits on a different domain, so the exchange cannot complete. This single change defeats the technique outright, and it is worth prioritizing for administrators and high-value roles even if a full rollout takes longer.
- Shorten token lifetimes and bind sessions. Continuous access evaluation and token binding reduce how long a captured token remains useful and how easily it can be replayed from elsewhere.
- Alert on session anomalies. A session issued in one location and used minutes later from a different network is the signal here, and it is detectable if anyone is looking for it.
- Watch the follow-on actions. New mail forwarding rules, unusual OAuth consent grants and first-time access to sensitive file locations are all reliable indicators of a compromised identity.
- Remove credentials from documents. The service account spreadsheet turned an identity compromise into an infrastructure compromise. Secrets belong in a managed store.
The broader lesson is that "we have MFA" describes a range of protection wide enough to be almost meaningless. The method determines whether the control holds against the attacks that are actually being run in 2026. For more on the wider pattern, see identity attacks and why MFA is not enough.
To test whether this path works against your environment, get in touch.
Frequently asked questions
How does phishing bypass multi-factor authentication?
Modern phishing does not try to defeat the MFA challenge. It proxies it. The victim is directed to a page that relays every request to the genuine login service in real time, so the real MFA prompt appears on the victim's own device and they approve it legitimately. What the attacker captures is not the password or the code but the session token issued afterward, which represents an already-authenticated session and can be replayed.
What is an adversary-in-the-middle phishing attack?
An adversary-in-the-middle attack places a reverse proxy between the victim and the real service. The victim sees an authentic login flow, because it is the authentic login flow, simply relayed. Open-source toolkits make this straightforward to deploy, which is why it moved from advanced tradecraft to commodity crime within a couple of years.
Does MFA still matter if attackers can bypass it?
Very much so. MFA still stops the overwhelming majority of credential attacks, including password spraying, credential stuffing and the reuse of credentials from breach corpora. The point is not that MFA fails but that phishable MFA fails against this specific technique. The response is to strengthen the method, not to abandon the control.
What is phishing-resistant MFA?
Phishing-resistant methods, principally FIDO2 security keys and passkeys, cryptographically bind the authentication to the legitimate domain. A proxy on a different domain cannot complete the exchange, so the attack fails at the point it would otherwise succeed. Certificate-based authentication offers similar properties. These methods remove the shared secret an attacker can relay.
How can we detect session token theft?
Look for a session used from a location, device or network materially different from where it was issued, and for impossible travel between the authentication and subsequent use. Token binding and continuous access evaluation shorten the window in which a stolen token remains useful. Alerting on new mail forwarding rules and unusual OAuth application consent catches common follow-on activity.