You validated MFA.
Your account is compromised.
AiTM phishing places an invisible proxy between you and the real site. You do everything right, but the attacker steals your session cookie the moment it's issued. MFA has already been consumed.
Monday meeting 2pm — agenda
Scheduled update tonight
March payslip available
The victim is working normally
No warning sign. The mailbox is open. The account is a target — the trap hasn't been triggered yet.
An AiTM proxy already deployed
Behind the scenes, the attacker configured a reverse proxy (EvilGinx2) on a convincing domain. Every request will be relayed in real time to the real Microsoft 365, making the page indistinguishable from the original.
Key figures
> 0
Organizations targeted in one day
by AiTM campaigns (Microsoft, June 2022)
< 0 s
To steal a valid session cookie
after the victim validates MFA
0
Visible signal for the victim
the login succeeds normally, no alert
Advanced technical demo
Full simulation + comparison + countermeasures
Three tabs: classic phishing vs AiTM comparison, victim-side and attacker-side simulation, and concrete FIDO2 and conditional access countermeasures.
Interactive demonstration
Bypassing MFA by stealing a session
Classic phishing
Password theft
The victim receives an email with a link to a fake static site
They enter their credentials — the password is captured
The attacker tries to log in with that password
Microsoft prompts for MFA → the attacker cannot approve it
MFA blocks access.
AiTM Phishing
Session cookie theft
The victim clicks a link to a real-time proxy (invisible)
They enter their credentials — relayed to the real Microsoft via the proxy
A real MFA notification arrives on their phone — they approve it
The proxy intercepts the session cookie issued by Microsoft
The attacker injects the cookie: full access, no MFA, no password
MFA is bypassed.
The fundamental difference
Classic phishing steals:
→ The password (a static secret). MFA then verifies you really are you → attack blocked.
AiTM steals:
→ The session cookie: proof that you've already authenticated with MFA. The attacker inherits your active session.
Key takeaway: the attacker never had your password or access to your phone. They just hold the proof that you logged in — which is enough to impersonate you.
AiTM proxy (reverse proxy)
An intermediary server relaying requests in real time between the victim and the real site. Common tools: EvilGinx2, Modlishka, Evilginx3. The served page is identical to the original.
Session cookie
A token issued by the server after successful MFA authentication. Valid 1 to 30 days. Stealing it short-circuits any need to re-authenticate — MFA has already been consumed.
MFA bypassed
TOTP, SMS, and push notifications don't protect against AiTM: the cookie is stolen AFTER MFA validation, during the active session. Only FIDO2 (bound to the domain) resists.
Real-world example
0ktapus Campaign — August 2022
130 companies. Same technique.
In August 2022, Group-IB researchers documented the "0ktapus" campaign: attackers targeted more than 130 companies (Twilio, DoorDash, Signal…) via fake Okta pages with an AiTM proxy. Victims received a text message: "Your session has expired, sign in again." Everything looked legitimate.
The Twilio / Cloudflare contrast
Twilio — compromised
Push-notification authentication. 163 employees affected, 9,931 customer accounts exposed.
Cloudflare — blocked
FIDO2 keys mandatory for all employees. The keys refused to activate on the proxy domain — attack automatically neutralized.
0ktapus campaign figures
Companies targeted
130+
Twilio employees affected
163
Twilio customers exposed
9,931
Signal contacts compromised
1,900
Cloudflare (mandatory FIDO2)
0 compromised
The Cloudflare lesson
Cloudflare received the same rigged text messages. Some employees even clicked. But the FIDO2 keys automatically refused to activate on the fake domain, with no decision required from the employee.