One typed code on a lookalike sign-in page is enough to hand an attacker a live workforce session. The employee sees a normal MFA prompt. The identity provider sees a valid login. The session it issues lands on the attacker’s side of the relay.
That is the industrial AiTM pattern. An adversary-in-the-middle attack puts attacker infrastructure between the employee and the real identity provider, relaying the password and one-time factor as they are entered so the attacker completes the sign-in and receives the session. Phishing-proof MFA 2.0 stops it at that step, because a device-bound, origin-bound signature cannot be relayed from a lookalike page. Microsoft’s Storm-1167 write-up and Barracuda’s Whisper2FA kit show the relay itself. Reddit’s 2023 employee phishing incident and Cloudflare’s 2022 near miss show what happens on either side of it.
This rolling hub covers the login-ceremony class. Deep 2026 incident posts (TrendAI MDR PTO AiTM, BigBear, Mirage2FA, and similar) remain full articles. Add them here as one-sentence Updates when they illustrate the same failure. For the attack-side walkthrough, see the companion on legacymfa.sucks: how AiTM phishing steals MFA login sessions.
Why push and OTP finish the login for the wrong party
Push approvals and one-time codes are transferable proofs. They do not bind to the legitimate origin or to a hardware-held private key. They bind to whatever channel can display a code or tap Approve. The employee proves identity to the page the proxy presents. The proxy forwards a completed authentication to the real IdP. The IdP does what it is designed to do. It validates the factors and mints a session. That session lands where the kit can copy it.
| Phase | What was abused | Why transferable MFA failed |
|---|---|---|
| Initial access | Password + OTP / push via AiTM proxy | Factor is transferable and origin-unbound |
| Cloud access | Stolen unbound session cookie | Authentication had already finished |
| Persistence / BEC | Same session, mailbox rules, or attacker MFA enroll | Post-auth abuse of an already-good session |
Some kits also spoof the MFA page itself to harvest SMS OTPs without a full reverse proxy. Proofpoint’s 2021 university Duo-themed campaigns are that flavor. Cloudflare’s July 2022 SMS phishing attack, which Cloudflare says had very similar characteristics to the attack on Twilio, shows the contrast: three employees entered passwords into a fake Okta page designed for real-time credential and TOTP relay, and FIDO2 hardware keys blocked authentication. Real-time OTP paste still loses. Origin-bound hardware signatures do not.
Dropbox’s 2022 CircleCI-themed phishing campaign captured a one-time password from a hardware authentication key typed into a malicious page. A code that can leave the device is still a transferable secret, even if the key that generated it was “hardware.”
After the cookie exists on the attacker side, the problem changes character. No login product un-steals an already-issued unbound session. Shortening lifetime only shrinks how long the stolen cookie remains useful unless the operator re-steals or plants lasting mailbox control. If they register their own authenticator while the session is live, lifetime limits stop mattering.
Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
How phishing-proof MFA 2.0 keeps the session from issuing
Stop the kit at the login it tried to complete. Device-bound credentials use public-key cryptography on enrolled hardware. The private key never leaves the device, never crosses the network, and never appears in a proxy transcript. Each authentication produces a fresh signature origin-bound to the real enterprise identity provider. A lookalike page cannot obtain a valid signature for the legitimate origin. There is no OTP to relay and no push prompt to approve for the wrong client.
Against AiTM-class harvests, that means the ceremony dies before a workforce cloud session is minted for the attacker. No transferable factor. No replayable cookie from that path.
Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. That hardens the ceremony these kits abuse. Phishing-proof MFA 2.0 goes further across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. Several AiTM campaigns enroll attacker MFA methods after the first stolen session. Login-only passkeys with soft enrollment still leave that second door open.
Classic SSO multiplies damage when the first proof is stolen. One session many apps trust becomes mail, files, and admin portals without another proof. Prefer per-app, device-bound proof over one shared federation cookie. Secure Explicit Sign-On keeps one-tap UX while each application receives its own fresh, hardware-bound signature.
| Control | Against AiTM login relay | Against later unbound cookie replay |
|---|---|---|
| Password + push / OTP | Completes inside proxy | N/A after issue |
| Passkeys at login only | Stops origin-mismatched relay | Does not bind cloud cookies alone |
| Phishing-proof MFA 2.0 | Kit cannot finish login | Session never issued to attacker |
| Device-bound token protection | Not the login ceremony | Limits replay off the enrolled device |
| Secure Explicit Sign-On | Fresh proof per app | No shared SSO skeleton key |
The industry keeps buying better detection for sessions that should never have been issued to a proxy. Stop minting those sessions. Start at prevention, not detection.
Key takeaways for defenders
- Treat reverse-proxy AiTM and MFA-page OTP harvest kits as credential-phase failures that end in stolen sessions, not as “MFA bypass magic.”
- Require origin-bound, device-bound signatures for interactive workforce sign-ins so push and OTP cannot finish on a hostile origin.
- Ban soft-factor fallback and lock enrollment so a stolen session cannot quietly register attacker MFA methods.
- Prefer per-app device-bound sign-on over one long-lived SSO cookie across mail and files.
- Keep token binding, CAE, and revoke as hygiene for leftover post-auth replay; do not confuse them with stopping the first harvest.
FAQ
Would phishing-proof MFA 2.0 have stopped AiTM session theft at login?
Yes, at initial access for the proxied login class these kits use. Private keys never leave enrolled hardware and signatures are origin-bound, so a reverse-proxy lookalike cannot complete authentication or receive a replayable workforce session. Cookie replay after a session is already stolen by malware is a separate residual problem.
Would MFA 2.0 undo a cookie the kit already copied?
No. Once authentication has succeeded and an unbound session token sits in attacker hands, no MFA product reverses that copy. Device-bound token protection and session revocation address residual replay. They are not the same control as stopping the AiTM ceremony.
Are passkeys enough to call the identity program phishing-proof?
No. Passkeys and FIDO2 are phishing-resistant at the login act when signatures are origin-bound and the private key stays on device. MFA 2.0 is phishing-proof across the identity lifecycle only when registration, device onboarding, recovery, and decommissioning also forbid phishable factors. Several AiTM campaigns abuse enrollment after the first stolen session.
How is AiTM different from helpdesk MFA-reset vishing?
AiTM finishes a login ceremony on a hostile or proxied origin and often copies the issued session. Helpdesk MFA-reset vishing abuses recovery and issuance through IT. Both are credential-phase social engineering of transferable factors. See the workforce vishing hub for the helpdesk path.
What should change first after an AiTM cookie harvest pattern?
Eliminate phishable workforce login factors on the paths employees actually use: passwords plus OTP, SMS, email codes, or fatigueable push. Require origin-bound signatures. Lock enrollment. Then harden leftover sessions with binding and revoke. Do not treat shorter TTL alone as prevention.
Updates
2025-10-15: Kit disclosure
Barracuda documented Whisper2FA, a phishing kit that intercepts Microsoft 365 credentials and MFA OTP or tokens in real time via live relay against login flows.
Source: Barracuda Blog, Whisper2FA threat spotlight
2023-06-08: Vendor campaign write-up
Microsoft’s Security Blog detailed a multi-stage AiTM phishing and BEC campaign (Storm-1167) that used fake Microsoft sign-ins to capture credentials and MFA or session tokens, then attacker MFA enrollment and follow-on BEC.
Source: Microsoft Security Blog, Storm-1167 AiTM phishing and BEC
2023-02-05: Named victim disclosure
Reddit disclosed that a sophisticated phishing campaign targeting employees obtained one employee’s credentials, which the attacker used to reach some internal documents, limited code, and limited contact and advertiser information, with production systems not impacted.
Source: Reddit, Sharing our findings around a data security incident
2022-07-20: Named victim contrast
Cloudflare documented a mass SMS phishing wave to a fake Okta login designed for real-time credential and TOTP relay; three employees entered passwords, and FIDO2 hardware keys blocked authentication.
