TL;DR
- Six paths in, no MFA "broken": Session hijacking, AiTM phishing, OAuth token abuse, prompt bombing, SIM swapping, and NHI/API token abuse all sidestep MFA rather than defeat it.
- Passkeys don't cover everything: They stop AiTM phishing and prompt bombing, but not session hijacking or OAuth token abuse.
- Session theft is already at scale: 8.6 billion cookies stolen in 2025 – 40% from devices already running EDR or antivirus.
- Device code phishing is spiking: Huntress tracked a 1,380% jump between mid-2025 and early 2026.
- Remediation is the real gap: Nearly 60% of orgs can't pinpoint which credentials or tokens were exposed after an attack.
Multi-factor authentication (MFA) blocks the majority of automated login attempts – about 99% of them. Every method covered here works because it never tries to beat that check head-on, whether by replaying a session that already passed MFA, defeating a specific factor like SMS or push notification, or reaching identities that don’t go through a login screen at all. They also share a common aftermath: confusion and action paralysis. Nearly 60% of organizations can’t reliably identify which credentials, cookies, or tokens were exposed once one of these techniques succeeds.
At a glance
| Technique | How it works | Defeats phishing-resistant MFA (FIDO2/passkeys)? | Primary defense |
|---|---|---|---|
| Session hijacking | Malware steals a session cookie or token after login; attacker replays it to skip authentication entirely | Session monitoring, fast token invalidation | |
| AiTM phishing | Reverse-proxy relays a real login in real time and captures the resulting session token | Enforced WebAuthn with no phishable fallback | |
| OAuth token abuse | Victim authorizes a token grant directly on the real site; no fake domain | Token monitoring, explicit revocation | |
| MFA fatigue / prompt bombing | Repeated push prompts sent until one is approved out of habit | Number matching, rate limiting | |
| SIM swapping | Attacker ports a victim’s number to intercept SMS codes | Move away from SMS-based MFA | |
| NHI / API token abuse | Stolen API keys and tokens authenticate directly with no human prompt | N/A | NHI governance and monitoring |
Session hijacking via stolen cookies and tokens
The simplest way to replay a session that’s already passed an MFA check is to just take it, and that’s what infostealer malware makes easy to do at scale. Nearly half of corporate users have fallen victim to infostealer malware at some point, and once a device is compromised, the malware pulls session cookies and refresh tokens straight out of browser storage.
A session cookie is what tells a site a user is already authenticated, so presenting a valid one skips the login screen and the MFA prompt behind it entirely, regardless of whether the original login used a password, a push notification, or a passkey. An attacker drops the stolen cookie into an anti-detect browser and picks up the session exactly where the victim left off.
Malware infections exfiltrated 8.6 billion session cookies in 2025, and 40% of those infections happened with endpoint detection and response (EDR) or antivirus tools already running.
Endpoint tools are built to catch the infection, not to flag a cookie that’s already made it out the door. And the damage rarely stops at one login. A cookie tied to a single sign-on (SSO) session can open every application behind it, and it keeps getting resold and reused for as long as it stays valid.
Adversary-in-the-middle (AitM) phishing
Where a stolen cookie is one way to get a session that already exists, AitM phishing skips the waiting and snags one as it’s created. A reverse-proxy kit sits between a victim and the real login page, relaying everything in both directions in real time:
- The victim enters their real password on a page that mirrors the real site.
- The proxy relays it to the real site, which sends back its real MFA prompt.
- The victim approves the prompt, believing they’re logging into the actual service.
- The real site issues a session token at the end of the exchange, and the proxy copies it before it reaches the victim.
The login was completely real, but now, the session it produced has two owners.
FIDO2 keys and passkeys stop this specific version of the attack, since they’re bound to the real site’s domain and won’t sign in on a proxy’s copycat page. But protection only holds where physical authentication is enforced with no fallback to phishable actions like a push notification when the hardware key isn’t available.
SpyCloud’s victimology analysis of the Tycoon 2FA phishing-as-a-service platform, which runs on this exact technique, found that roughly 80% of its victims were enterprise users.
OAuth token abuse via device code and consent phishing
Device code phishing never touches a login screen at all, it goes straight for the authorization step that normally follows.
- The attacker generates a real device code, typically used to sign into devices like smart TVs, through a legitimate authentication portal, a genuine Microsoft sign-in page, and sends it to the victim disguised as something routine, like a Teams meeting invite.
- The victim enters the code on the real portal, where an already-active Microsoft 365 session satisfies the trust check, so no new MFA challenge fires.
- The real server issues valid access and refresh tokens once the victim completes the process, and those tokens land on the attacker's device instead of the victim’s.
- The tokens keep working for months and survive a password reset. Only revoking them directly through the identity provider shuts the door.
Huntress tracked a 1,380% spike in device code phishing attacks between July – December 2025 and January – April 2026.
A passkey only refuses to sign in on a fake copycat domain, and every step of this attack happens on the real site, so phishing-resistant MFA has nothing to flag.
Consent phishing reaches the same place through a different door. A victim grants a malicious app OAuth permissions directly, through a legitimate-looking permissions screen, and the attacker walks away with the same standing access, without a password. In the 2025 Salesloft Drift breach, attackers used stolen OAuth tokens tied to a third-party integration to pull contact records, support case data, and embedded credentials out of more than 700 organizations’ Salesforce environments over about 10 days.
MFA fatigue and prompt bombing
Prompt bombing doesn’t try to fool a system at all; it wears down a person instead. An attacker who already has a valid password triggers push notification after push notification on a victim’s device. Technically, nothing about the second factor gets broken. The person being overwhelmed with approval prompts just gets frustrated and eventually hits confirm to make the notifications stop.
One solution for this muscle memory is number matching. Instead of tapping one button, a person is required to type a code shown on the login screen, making the act of verification more deliberate. Another option is a hardware key or passkey, which removes the decision from the person altogether.
SIM swapping
SIM swapping targets an individual’s phone number. An attacker poses as the victim and convinces a mobile carrier to port the victim’s number onto a SIM they control, so any text-based code, like a bank’s wire transfer confirmation, lands on the attacker’s phone instead.
SMS-based MFA assumes a phone number reliably identifies its owner, and this breaks that assumption before the code is ever sent, so the second factor arrives exactly as designed and simply goes to a bad actor.
41% of people still trust SMS-based authentication despite its documented vulnerability to SIM swapping.
Non-human identity and API token abuse
An API key or service account doesn’t have a human behind it to prompt for a second factor. These non-human identities (NHI) authenticate automatically, every time, which is exactly why MFA wasn’t built to cover them. The same infostealer malware behind session hijacking pulls these credentials, lifting them straight out of config files and developer tools on an infected device. Once an attacker has one, there’s no login screen or approval prompt standing between them and whatever that credential can reach.
Compromised NHIs were the primary route into the enterprise for 31% of organizations, nearly twice the rate of phishing and social engineering.
A stolen package repository token can do more damage than most. Instead of reaching just one system, it lets an attacker slip malicious code into a software supply chain that gets distributed to everyone downstream. SpyCloud recaptured 18.1 million exposed API keys and tokens last year, spanning payment platforms, cloud infrastructure, developer tools, and AI platforms.
Your org’s data may already be exposed
Billions of records from this year’s confirmed breaches are circulating right now.
FAQs
Infostealer malware pulls them directly out of browser storage on infected devices. AiTM phishing kits capture them too, relaying a real login page in real time and copying the resulting session token.
No. Passkeys stop credential phishing, but a session cookie or token can still be stolen from an infected device after a passkey login completes, and presenting that stolen session skips authentication entirely.
AitM phishing uses a reverse-proxy kit to relay a real login page in real time, capturing the credential, the MFA approval, and the resulting session token.
Often within minutes. Attackers can analyze a compromised inbox and draft convincing replies in the victim’s writing style almost immediately after theft, which is why automated detection matters more than manual review.
Not reliably. EDR is built to catch device compromise, and 40% of malware infections that harvest session cookies occur on endpoints already running EDR or antivirus tools.
Keep reading
