Phishing doesn't need malware anymore — it just needs your session token
Adversary-in-the-middle kits relay real logins in real time and steal the session token directly, skipping malware — what it means for OAuth and session handling.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
The mental model most developers still carry for phishing is: attacker sends email, victim clicks link, link drops malware, malware does the damage. Recent reporting on adversary-in-the-middle (AiTM) phishing kits describes a version of the attack that skips the malware step entirely. The kit sits as a reverse proxy between the victim and the real login page. The victim types a real password and a real MFA code into what looks like the real site, because functionally it is a relay of the real site. The kit forwards everything through, the login succeeds, and the kit keeps a copy of the session token that comes back. No payload ever touches the victim’s machine — there’s nothing for endpoint security to catch, because nothing was installed.
Microsoft’s own incident writeup of a multi-stage AiTM campaign published in May 2026 walks through exactly this pattern against Entra ID sign-ins. And the scale matters: Microsoft’s 2025 Digital Defense Report attributes roughly 80% of MFA-bypass breaches to stolen session tokens, not to a defeated password or a compromised second factor. MFA did its job in these cases — the attacker just walked around it by grabbing what MFA hands back after it succeeds.
Why “we have MFA” stopped being the whole answer
MFA was designed to defend the login moment: prove you have the password and the second factor, get a session. AiTM phishing doesn’t attack the login moment at all — it sits inside it, watches a real, successful authentication happen, and steals the artifact that authentication produces. The session token is, by design, what lets a user skip re-authenticating on every request. That convenience is precisely what makes it valuable to steal: once an attacker has it, they don’t need the password again, they don’t need the MFA code again, they just need the token to still be valid.
What this means for OAuth and session handling in your own stack
If you’re building or integrating an auth flow — your own app’s login, an OAuth client against a third-party API, an agent that holds a token on a user’s behalf — the AiTM pattern is a useful stress test for a few defaults worth checking:
| Design choice | Why it matters against session theft |
|---|---|
| Long-lived access tokens with no expiry check | A stolen token is valid for as long as the attacker wants it to be |
| Short-lived access tokens + refresh flow | Narrows the window a stolen token is useful, even if the refresh token also leaks |
| No re-auth for sensitive actions | A hijacked session can do everything a legitimate one could, silently |
| Step-up re-auth before high-risk actions | Forces a second proof of identity at the moment it matters most, not just at login |
| Tokens not bound to a device/context signal | A token works identically from the attacker's infrastructure as from the real user's browser |
None of this is exotic advice — short-lived tokens, refresh rotation, and step-up re-authentication for sensitive actions are standard OAuth hygiene. What’s changed is the cost-benefit of skipping them. When credential theft required malware with persistence on the endpoint, a long-lived token was one layer in a chain an attacker still had to maintain access through. When theft happens in real time during a normal login, the token itself is the entire prize, and its lifetime is the entire window of exposure.
Why phishing-resistant MFA is a different claim than “MFA”
Not every second factor is equally exposed to this. A one-time code typed into a form is just another value the relay can capture and forward, no different from the password it sits next to. Factors built on public-key cryptography that’s bound to the specific origin being authenticated — the FIDO2/WebAuthn model behind most passkeys and hardware security keys — don’t have this problem, because the cryptographic challenge is tied to the real site’s origin and can’t be relayed through a lookalike domain the way a typed code can. That distinction is why “phishing-resistant MFA” became its own phrase instead of just meaning “MFA”: the AiTM pattern is precisely the case it was built to close, and it’s worth knowing which of your own factors actually qualify rather than assuming any second factor is interchangeable with any other.
The practical checklist
- Default to short-lived access tokens. If your API or client issues tokens that are valid for days or weeks with no re-check, that’s the exact shape of exposure an AiTM-stolen token benefits from most.
- Scope re-authentication to the actions that matter, not just to session start — changing a password, adding a payment method, or exporting data are reasonable places to ask for a fresh proof of identity even mid-session.
- Treat “MFA is enabled” as necessary, not sufficient. MFA stops credential-only attacks; it does not stop an attacker who relays a live session through your MFA prompt and keeps what comes out the other end.
- Log and alert on session anomalies — a token used from a wildly different network or client fingerprint than where it was issued is a cheap, useful signal, independent of how the theft happened.
None of this requires knowing the internals of any particular vendor’s auth stack — it’s the same discipline that applies to scoping any API credential to least privilege or rotating server-to-server keys: assume a credential can leak, and design so that leak has a short, narrow blast radius rather than a long, wide one.
Where Norbelys draws that same line
Norbelys keeps the two credential shapes deliberately separate for exactly this reason. A human in the dashboard authenticates with a short-lived browser session — nothing long-lived for an AiTM relay to walk off with beyond the usual session window. A backend service or CI job instead uses an org-scoped API key, which doesn’t expire on its own and is designed to be rotated on a schedule and immediately on any suspected leak rather than trusted to stay good forever. The same principle applies one level down, to credentials Norbelys stores on your behalf: mailbox passwords and OAuth refresh tokens for connected senders are encrypted at rest and never returned over the API once saved — even a fully authenticated request can’t read them back out, which is the same “the stored secret itself is a smaller target” logic AiTM-resistant session design is built on.