Breach · Identity Security

Attackers Use Passkey Phishing to Hijack Microsoft Cloud Accounts and Exfiltrate Data

September 14, 2026 · 6 min read

There is a bitter irony in this campaign: the attackers weaponized the language of security improvement. They called employees on their personal phones, told them to update their passkey or MFA settings right now, and pointed them to a convincing fake Microsoft login page. The credential or session token that landed in the attacker's hands was handed over by someone who thought they were doing the right thing. Microsoft's Security Research team published their analysis on September 9, 2026, and the activity they describe has been running since at least May 2026, carried out by threat actor clusters they track as Storm-3121 and Storm-3032.

What actually happened

The attack starts on a channel most corporate security teams cannot see: a phone call or text message to an employee's personal number. The caller claims to be from the IT help desk and creates urgency around updating a passkey, MFA configuration, or SSO setting. From there, the target is directed to an adversary-in-the-middle (AiTM) Microsoft sign-in page or walked through a device-code authentication flow that hands the attacker a valid session token. Microsoft's blog describes the resulting access as consistent with "automated collection from compromised cloud identities using proxy-associated infrastructure," which means the exfiltration is fast and scripted once that first token lands.

Persistence comes immediately. Before moving on to data collection, the attackers register their own MFA methods on the compromised account. That single step means a password reset by the victim does nothing to recover control of the account. The post-compromise playbook then runs through Microsoft Graph API queries against users, groups, roles, authentication methods, and connected applications, followed by bulk downloads from SharePoint Online and OneDrive, and mailbox collection through REST APIs. Compromised accounts also become a platform for sending further phishing lures through Microsoft Teams, which gives the campaign a self-propagating quality inside trusted organizational networks.

Microsoft attributes the initial access work to Storm-3121 and Storm-3032. Storm-3121's intrusions feed into ShinyHunters and Falcon (also tracked as CL-CRI-1182) extortion operations. Storm-3032 maps to UNC6671, a group that Google Threat Intelligence has also documented, which broke away from the BlackFile group (CL-CRI-1116) and now operates under the Helix extortion brand. The picture here is a tiered criminal ecosystem: one set of actors specializes in getting the initial foothold, and separate groups handle the monetization through extortion.

A parallel campaign documented in the same Microsoft report sent over one million scam emails between August 3 and 5, 2026, with attackers impersonating the CEOs of target companies and pressuring accounts payable teams to initiate ACH transfers for a supposed ServiceNow annual renewal. Those emails used AI-generated templates, forged invoices, and fake email threads to appear legitimate, and were sent through abused third-party email delivery infrastructure. The two campaigns share infrastructure and operator overlap but the identity-phishing campaign is the more structurally dangerous one, because it produces persistent cloud access rather than a one-time payment attempt.

Why this should matter to you even if you don’t run Microsoft 365

If your organization runs Microsoft 365, Entra ID, or any cloud productivity suite with a help-desk function, the attack surface described here applies to you directly. The specific lure was passkey and MFA enrollment language, which is effective precisely because organizations have been telling employees to expect communications about MFA updates. Attackers read the same security awareness memos your employees do.

The detail that initial contact happens on personal phones deserves attention from a monitoring standpoint. Corporate endpoint detection, email filtering, and even mobile device management policies generally do not cover an employee's personal cell number. That gap means the first indicator of compromise that appears in your corporate telemetry may be the AiTM login attempt or the Graph API enumeration, well after the social engineering succeeded. Help Net Security noted this specifically in their September 10, 2026 coverage: the personal device contact leaves little forensic trail in corporate systems.

The MFA persistence technique compounds the problem. Most incident response playbooks start with forcing a password reset on a compromised account. When an attacker has already registered their own authenticator app or hardware key against that account, a password reset alone does not terminate their access. Your response runbook needs to explicitly include auditing and removing all registered authentication methods, not just rotating credentials. If your team has not walked through that step in a tabletop exercise recently, this is a good time to schedule one.

The BEC thread running alongside this campaign is a reminder that the same criminal ecosystems are hitting organizations with multiple techniques simultaneously. Accounts payable receiving a CEO-impersonation email about an ACH transfer for a ServiceNow renewal, and an IT employee getting a call about updating their passkey, may be the same threat actor cluster probing your organization from two directions at once. Treating these as unrelated incidents in separate ticketing queues is exactly what the attackers are counting on.

The control that would have blunted it

The control category that directly addresses this campaign is phishing-resistant MFA, and it is worth being precise about what that phrase means in practice. Standard TOTP codes and push notifications are vulnerable to AiTM attacks because an attacker sitting between the user and the real login page can relay the code in real time. Phishing-resistant MFA, in the context cyber insurers and frameworks like CISA's guidance use, means FIDO2 passkeys or hardware security keys bound to the specific origin (the legitimate domain). A FIDO2 credential will refuse to authenticate against a spoofed login page because the origin check fails at the credential level, before any user action. That property is what makes it meaningfully different from a six-digit code.

The irony the attackers exploited here is that passkey language was used as the lure. That does not mean passkeys are the wrong answer. It means user education about enrollment processes needs to be explicit: IT help desks at most organizations do not call employees on personal phones to prompt immediate credential updates. Defining and communicating what a legitimate IT-initiated enrollment request looks like, and what it does not look like, is an operational complement to the technical control. The technical control fails if users can be socially engineered into enrolling attacker-controlled devices as their own.

Cyber insurers are increasingly asking for evidence of phishing-resistant MFA coverage specifically for cloud administrative accounts and privileged roles. Standard MFA on a global admin account is no longer sufficient to satisfy many underwriters' questionnaires. If you are in a renewal cycle, expect questions about FIDO2 or certificate-based authentication for your highest-privilege identities, conditional access policies that enforce authentication strength by role, and whether your MFA enrollment process itself requires verification through a separate trusted channel.

The attacker-added authentication method persistence technique points to a second, often overlooked control: monitoring and alerting on authentication method changes. Every time a new authenticator is registered to a cloud identity, that event should generate a near-real-time alert to a security team or at minimum to the account holder through a verified out-of-band channel. Microsoft Entra ID logs these events and Microsoft Defender has detection coverage for the known TTPs from Storm-3121 and Storm-3032, but the detections are only useful if someone is watching and response playbooks include the step of auditing registered auth methods as part of account containment. Logging without alerting and without a runbook that addresses this specific persistence mechanism leaves the control incomplete.

There is an honest operational tradeoff worth naming. Deploying FIDO2 hardware keys at scale across a large workforce involves hardware cost, logistics for key distribution and replacement, and user training. Passkeys backed by platform authenticators (Touch ID, Windows Hello) reduce the logistics burden but depend on device management maturity and consistent conditional access enforcement. Phased deployment that prioritizes privileged accounts, IT staff, and finance roles first is a reasonable starting point, both because those roles are the highest-value targets in this campaign and because a smaller initial rollout is easier to operate correctly.

Strondex's MFA assessment and implementation service helps organizations evaluate their current authentication coverage against insurer requirements and deploy phishing-resistant controls for the roles that matter most.