TL;DR
AitM phishing kits proxy the real login page, relay the MFA prompt, and capture the session cookie and tokens the identity provider issues once the victim finishes. The attacker replays them and is signed in with MFA already satisfied. A stolen refresh token can keep working for months and survive a password reset, so response needs explicit session and refresh token revocation through the identity provider.
Multi-factor authentication (MFA) stops the attacker who only has a password. It does much less against an attacker who sits between the user and the login page, which is exactly where adversary-in-the-middle (AitM) phishing kits operate.
This post covers how an AitM kit captures a session, what SpyCloud’s recaptured phishing data shows about the kits behind these attacks, and what a response needs to include for session and token theft. For a step-by-step reference, see SpyCloud’s phishing-as-a-service (PhaaS) guide.
The reverse proxy behind an AitM attack
An AitM phishing kit works as a reverse proxy between the victim and the real login service. Everything the victim types goes to the attacker’s server, which forwards it to the real service and returns the real responses. The victim sees a genuine sign-in experience because, functionally, it is one.
The attack runs in five steps:
- The victim clicks a phishing link and lands on a proxy page that mirrors the real sign-in, such as a Microsoft 365 login.
- The kit forwards the victim’s credentials to the real identity provider.
- The identity provider prompts for a second factor, the kit relays the prompt, and the victim completes it.
- The identity provider issues a session cookie or token to what it believes is the user’s browser, and the kit receives and stores it.
- The attacker loads that session into their own browser and is logged in as the victim, with MFA already satisfied.
MFA works as designed in this attack, but it only verifies the login, and the session it produces is the thing the attacker takes.
Step 4 hands the kit more than one item. SpyCloud’s phishing research separates what it captures into three artifacts. Session cookies give hours of access and close when the session expires or is revoked. Session tokens represent the authenticated state inside the identity provider and open any SSO-connected application. Refresh tokens are the one to watch, because they silently generate new session cookies for months with no login, MFA prompt, or behavioral signal, and in most enterprises they survive a password reset.
The credential itself may never be taken. Teams that check only for exposed credentials after a successful phish can close the incident while the attacker still has working access.
What attackers do with the session
With the stolen session loaded into an anti-detect browser, the service sees a connection that matches the user’s original session and has no reason to ask for a login or an MFA challenge again. In a typical Microsoft 365 environment that opens the inbox and sends mail, SharePoint and shared drivers, Teams, and any app connected through SSO. Attackers now use AI to draft business email compromise replies in the victim’s writing style within minutes of token theft. The session hijacking use case covers how this plays out in more detail.
Where phishing-resistant MFA stops and token theft continues
FIDO2 keys and passkeys largely close the classic AitM relay. Origin binding prevents the key from signing a request on the attacker’s proxy domain, so the identity provider never issues a token for the attacker to keep.
It doesn’t cover everything, though. Origin binding protects a user only when no fallback to a perishable factor such as a push, one-time code, or password exists, and that fallback is the usual real-world defeat. Device code phishing reaches the same result without a proxy, because the victim enters an attacker-generated code on a real Microsoft domain and the identity provider issues tokens to the attacker’s device. Infostealer malware lifts tokens from the device after a legitimate login, so the key performs correctly and the theft happens anyway. SpyCloud researchers have observed a marked rise in device code phishing as of 2026.
Where AitM kits are aimed
SpyCloud’s victimology analysis of Tycoon 2FA, an AitM kit and the target of a 2026 takedown effort, found that about 80% of its victims were enterprise users. Across phishing-as-a-service (PhaaS) platforms, about half of phishing-sourced records are tied to enterprises, compared with roughly 11% of infostealer records, which makes phishing about five times more targeted toward enterprises than malware.
What a response needs after a token is stolen
A survey of enterprise security teams found that 58% of organizations struggle to identify which credentials or session tokens were exposed after a phish. Speed varies too. Only 28% finish remediation in under four hours, and 68% take four hours or longer, leaving stolen tokens usable for that entire stretch.
A response built for AitM and device code phishing resets passwords on confirmed-exposed identities, re-issues MFA to step up authentication, revokes active sessions and refresh tokens through the identity provider, and monitors phishing target lists so exposed users are watched before an attacker acts. The third step is the one most incident responses playbooks don’t yet account for, and a password reset does not cover it.
Closing the window on stolen sessions
Every successful phish deserves to be treated as a potential credential, session, and token compromise. SpyCloud recaptures session cookies, refresh tokens, and credentials from successful phishing attacks and infostealer logs, and identifies the affected employee. In Okta environments, Okta Workforce Guardian can then revoke active sign-in sessions and refresh tokens automatically, while the Entra ID and Active Directory Guardians force a password reset for the user. That shortens the time between theft and response, which is the window AitM kits depend on.
To see how SpyCloud finds exposed sessions and tokens tied to your workforce, request a demo.
Your organization's data may already be exposed.
Billions of assets from this year’s identity events are circulating right now.
FAQs
An adversary-in-the-middle (AiTM) phishing attack uses a reverse proxy to sit between a victim and a real login page. The victim signs in to what looks like their normal service while the kit relays everything to the real site and records the session the service issues. The attacker then uses that session to access the account.
The kit lets MFA run normally. It relays the second factor prompt to the victim, who completes it on the real service. Once the login succeeds, the identity provider issues a session cookie or token to what it believes is the user’s browser, and the kit captures it. The attacker replays that session from their own browser, so no further MFA challenge appears.
They capture the artifacts the identity provider issues after authentication: session cookies, session tokens, and refresh tokens. Session cookies give hours of access, session tokens open SSO-connected applications, and refresh tokens can generate new sessions for months. The victim’s password may never be taken at all.
Not on its own. In most enterprises, a stolen refresh token keeps generating new session cookies after a password reset, so the attacker keeps access. Ending it takes explicit revocation of active sessions and refresh tokens through the identity provider, alongside the reset.
They largely close the classic reverse-proxy relay, because origin binding prevents the key from signing a request on the attacker’s proxy domain. Gaps remain when a phishable fallback such as a push, one-time code, or password is still allowed, when attackers use device code phishing, and when infostealer malware takes tokens from the device after a legitimate login.
Device code phishing reaches a similar result without a proxy. The victim enters an attacker-generated code on a real Microsoft domain, and the identity provider issues tokens to the attacker’s device. Because authentication happens on legitimate infrastructure, origin binding does not stop it.
Keep reading
