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. Malware after a legitimate login is a harder, separate problem.

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. Prevention value is upstream: 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.