Storm-1167 AiTM stole M365 sessions and MFA

Storm-1167 ran multi-stage adversary-in-the-middle phishing and business email compromise against banking and financial Microsoft 365 workforces. According to the Microsoft Security Blog on 8 June 2023, compromised trusted-vendor mail with unique seven-digit subjects and Canva “fax/OneDrive” lures steered staff onto Tencent-hosted fake Microsoft sign-in pages. An adversary-in-the-middle attack is a live phishing setup that sits between the user and the real identity provider so the attacker can capture credentials, MFA responses, and the session that follows. Storm-1167 used an indirect-proxy kit (not the reverse-proxy style Microsoft had previously associated with kits like EvilProxy), stole legitimate session cookies, later enrolled attacker phone OTP without a step-up challenge, set inbox rules, and sent more than 16,000 second-stage phishing emails from hijacked mailboxes. Public reporting does not name the victim banks, headcounts, or financial loss.

If you want the prevention angle, read the related article on mfa2point0.com.

FAQ

How did Storm-1167 get into Microsoft 365 accounts?

Storm-1167 got into Microsoft 365 accounts by phishing workforce users through compromised trusted-vendor mail that led to fake Microsoft sign-in pages, then harvesting passwords and live MFA responses so a legitimate session cookie landed with the attacker. According to Microsoft’s 8 June 2023 write-up, the lure used Canva-hosted “document” links and Tencent cloud hosting for the spoofed sign-in and fake MFA pages. Password plus transferable MFA was enough. The kit completed authentication for the attacker, so the session cookie was real, not forged.

Was Storm-1167 the same reverse-proxy AiTM as EvilProxy?

No. Microsoft stated Storm-1167 used an indirect-proxy AiTM method, not the reverse-proxy pattern associated with kits like EvilProxy and NakedPages. The attacker still presented attacker-controlled fake Microsoft sign-in and fake MFA pages, relayed what the user typed and approved, and obtained a usable session cookie. The architecture differed from classic reverse proxy, but the failure mode for legacy password-plus-OTP/push MFA was the same: transferable factors on the wrong origin.

Why didn’t a password reset alone stop Storm-1167 access?

A password reset alone did not stop Storm-1167 access because the attackers already held stolen session cookies and later generated a new access token for longer-lived cloud use without re-entering the password or MFA. Microsoft’s disclosure is explicit: affected organizations needed to revoke session cookies and roll back MFA modifications the threat actor made. Hours after the initial harvest, cookie replay from a different IP opened mail and cloud documents with no fresh login. Password change without session kill leaves the stolen cookie valid.

How did Storm-1167 add its own MFA method on the account?

Storm-1167 added its own MFA method by abusing MFA policies that allowed a new phone-based OTP factor (OneWaySMS, Iranian country code) without an MFA challenge or step-up re-authentication while the hijacked session was live. Microsoft called out policies “not configured using security best practices” for updating MFA methods without an MFA challenge. With that parallel OTP enrolled, the attacker also created an inbox rule that moved mail to Archive and marked it read, then used the mailbox for BEC-oriented activity. Enrollment without strong proof of presence is a credential-lifecycle hole, not a mystery “MFA bypass” after the fact.

What did the Storm-1167 BEC stage actually do?

The Storm-1167 BEC stage used already-held mailbox access to send more than 16,000 second-stage phishing emails to the compromised user’s contacts and distribution lists, monitor undeliverable and authenticity-question replies, delete those replies, and push further AiTM pages that compromised additional internal mailboxes. Microsoft framed the campaign as multi-stage AiTM phishing plus business email compromise aimed at financial fraud against anonymized banking and financial services organizations. That volume is post-authentication abuse of a trusted-looking internal sender. Closing the original phishable login and locking enrollment shrinks how often attackers reach this stage; revoke and mailbox hygiene clean up what they already hold. A fix that removes transferable login and enrollment factors exists; the prevention write-up is on the companion site.