Phishing-proof MFA stops Storm-1167 AiTM login

Storm-1167’s multi-stage adversary-in-the-middle phishing against banking and financial Microsoft 365 workforces harvested passwords and live MFA responses on attacker-controlled fake sign-in pages, then replayed session cookies and enrolled attacker phone OTP. According to the Microsoft Security Blog on 8 June 2023, the kit used an indirect-proxy AiTM method rather than classic reverse-proxy tooling. Phishing-proof MFA 2.0 stops that path at login and at enrollment: origin-bound device keys never complete a ceremony on the wrong origin, and adding a factor requires an already-enrolled device. Cookie replay and BEC after a session already exists still need revoke and mailbox hygiene. The full attack chain is on legacymfa.sucks.

FAQ

Would MFA 2.0 have stopped Storm-1167’s AiTM Microsoft sign-in?

Yes. Phishing-proof MFA 2.0 would have stopped Storm-1167’s AiTM Microsoft sign-in harvest because there is no password, OTP, SMS code, or push approval for an indirect-proxy kit to relay on a spoofed page. Storm-1167 presented fake Microsoft sign-in and fake MFA pages, captured transferable factors live, and received a legitimate session cookie for the attacker. Device-bound, origin-bound signatures never leave the enrolled hardware and never validate on the attacker’s origin, so the kit never completes authentication. Closing that phishable login stops this path. An attacker who wants a session after that point needs malware on a signed-in device, which is a different and harder attack.

Does phishing-proof MFA undo Storm-1167 session cookie replay?

No. Phishing-proof MFA does not undo Storm-1167 session cookie replay once a legitimate cloud session already exists. Microsoft reported that hours after the harvest the attacker replayed the stolen cookie from a US IP, opened mail and cloud documents, and generated a new access token without re-entering password or MFA. No login-time control, including MFA 2.0, revokes a token already issued. The fix comes earlier: the AiTM page never obtains the session. Microsoft’s own remediation guidance still required cookie revoke and rollback of attacker MFA changes. Revoke remains hygiene, not a substitute for stopping the login.

How does MFA 2.0 block attacker MFA enrollment like Storm-1167’s OneWaySMS add?

MFA 2.0 blocks Storm-1167-style attacker MFA enrollment by treating factor add and recovery as privileged ceremonies that demand proof from an already-enrolled device, not a silent policy hole. Microsoft stated the actors leveraged MFA policies that allowed updating MFA methods without an MFA challenge, then enrolled phone-based OneWaySMS OTP on an Iranian-country-code number while the hijacked session was live. That is a credential-lifecycle failure, not a mystery after the fact. Protected enrolment removes transferable enrollment codes and forbids parallel OTP registration without strong step-up. Passkeys that only harden login still leave this gap if enrollment stays phishable.

Are passkeys alone enough against a Storm-1167-style campaign?

Passkeys alone are not enough against a Storm-1167-style campaign if enrollment and MFA-method changes still accept phishable proof. Passkeys are phishing-resistant at the login act: origin-bound signatures stop many AiTM relays at authentication. Storm-1167 also abused weak MFA-update policy after the session existed, adding attacker-controlled OTP without step-up. MFA 2.0 is phishing-proof across the identity lifecycle, registration through decommissioning, so both the fake sign-in harvest and the silent factor add fail. Resistant hardens login; proof closes enrollment and recovery too.

What should defenders still do after Storm-1167-style access?

Defenders still need to revoke session cookies, roll back attacker-added MFA methods, and scrub inbox rules after Storm-1167-style access, even when phishing-proof MFA is the long-term fix. Microsoft was explicit that password reset alone is insufficient when cookies and parallel OTP factors remain valid. Second-stage BEC, including more than 16,000 phishing emails from compromised mailboxes, is post-authentication abuse of already-held access. The prevention-first model shrinks how often attackers reach that stage. Containment cleans what they already hold.