Microsoft says a threat actor is calling employees on their personal phones, posing as IT helpdesk staff, and using a fake "update your passkey" request to walk them into handing over a Microsoft cloud account.
The pitch is almost boring by design. Someone calls your personal cell, says they're from the helpdesk, and tells you your passkey or single sign-on setup needs to be updated right now or you'll lose access. There's a link, usually sent by text. The page it opens looks like a normal Microsoft sign-in screen. Nothing about it screams "attack."
That's the point. Microsoft Security Research has been tracking this activity since May 2026, and in a research post published September 9, it laid out how a passkey-themed pretext has been turned into a reliable way to get inside Microsoft 365 tenants.[1] The company describes the pattern as consistent with automated collection from compromised cloud identities using proxy-associated infrastructure.[1]
What Microsoft actually disclosed
Two separate write-ups came out of Microsoft's security team within 24 hours of each other, and it's worth keeping them apart because they're different attacks with different mechanics. The first, covered by The Hacker News on September 13, is a business email compromise campaign — over a million scam emails sent between August 3 and 5, 2026, impersonating CEOs to trick accounts payable teams into wiring money for a fake ServiceNow invoice.[3] Microsoft's own account of that campaign says the operation targeted accounts payable departments with a near-$50,000 ACH transfer request, layering executive impersonation, a fabricated ServiceNow invoice, and a forged forwarded email thread into one narrative.[2] It's a well-built scam, but it's fundamentally an email problem — no account takeover involved.
The second campaign is the more consequential one, and it's the focus of this article: cloud account compromise driven by passkey-themed vishing (voice phishing). This is where an attacker doesn't just ask for money — they get inside the tenant.
How the attack actually works
Microsoft breaks the intrusion into a repeatable sequence, and the shape of it explains why it's been hard to catch early. It starts with a call or text to a personal phone number from someone claiming to be IT helpdesk, creating urgency around a passkey, MFA, or SSO update.[1] The victim gets redirected to a lookalike Microsoft sign-in page, often via SMS, and the interaction happens on a personal device that may not be enrolled in the organization's endpoint protection — which means there's frequently no telemetry from that first step at all.
Here's the twist Microsoft calls out specifically: the passkey story is a pretext, not the actual goal. The real objective is to get the victim through an adversary-in-the-middle phishing flow, where the attacker captures credentials and session tokens in real time, or a device-code authentication flow, where the victim unknowingly authorizes an attacker-controlled client without ever giving up a password. Either way, standard MFA doesn't save you, because the victim completes it themselves — device-code phishing in particular is designed to look like nothing more than typing a code into a legitimate Microsoft page.
Getting in once is easy to lose. So the actor's first move after gaining access isn't to start grabbing files — it's to make the access permanent. Microsoft found that the actor registers a new phone number, authenticator app, or software OTP token under their own control as an additional MFA method on the compromised identity.[1] That single step matters more than it sounds. A password reset alone won't kick the attacker out anymore, because they now hold a valid second factor. Only removing the rogue authentication method — on top of resetting credentials and revoking sessions — actually closes the door.
Interestingly, Microsoft documented three slightly different paths into that same persistence step across its investigations: one where a sign-in from an unmanaged device led to MFA completion and then broader application access; one where a passkey lure led straight into device-code phishing; and one where previously compromised credentials, combined with an authenticator app the attacker had quietly registered days earlier, were reused to sign in cleanly. Different entry points, same endpoint.
What gets taken, and how
Once the actor-controlled MFA method is in place, the next phase is reconnaissance through the Microsoft Graph API — and this is the part Microsoft's writeup spends the most time on, because on its own, none of it looks unusual. Requests to endpoints like /users, /groups, or /sites happen constantly in any enterprise tenant. What made this activity stand out, according to Microsoft, was the same identity systematically traversing multiple resource categories — directory structure, privilege assignments, application consent grants, SharePoint sites, mailbox folders — before moving into actual content retrieval.[1] That progression, not any single API call, is what Microsoft says separates this from normal usage.
From there the actor moves into collection. Microsoft observed high-volume access to SharePoint Online and OneDrive for Business, and in some intrusions, mailbox content pulled through Exchange Online's REST APIs. A detail worth noting for defenders: in several cases the activity carried a python-httpx user agent, which is consistent with automated, script-driven access rather than someone clicking through a browser — though Microsoft is careful to say the user agent alone isn't proof of anything; it only matters combined with volume, source infrastructure, and prior signs of compromise.
What's notable is the pacing. This isn't smash-and-grab. Microsoft says exfiltration typically spans several hours to multiple days, with fewer than 1,000 files or emails accessed in any single hour.[1] Slow and steady blends into normal enterprise traffic far better than a burst would — and it buys the attacker time before anyone notices.
Who's behind it
Microsoft Threat Intelligence attributes the initial access activity to a range of actors including Storm-3121 and Storm-3032, both of which feed into extortion operations rather than working in isolation.[1] Storm-3121 leads into ShinyHunters and Falcon extortion activity; Storm-3032 is Microsoft's designation for a set of actors that splintered off from a group tracked as BlackFile and now operate under a brand called Helix. It's worth being precise here, since exploitation terminology gets sloppy fast in coverage of stories like this: this is attributed initial-access activity feeding known extortion brands, not a confirmed single group running the entire operation start to finish. Microsoft's own wording keeps those two things separate, and this article does too.
The domain infrastructure fits a pattern the security community has seen before under different names — Cordial Spider, PREY-0058, UNC6671 — loosely affiliated actors who appear to share phishing panels and vishing infrastructure without necessarily being the same organization. Microsoft is careful to note that the exact nature of those connections is unclear, and this article treats that framing as unresolved rather than settled.
What defenders should do
The single clearest structural fix Microsoft recommends is moving away from MFA methods that can be phished at all. Enforcing phishing-resistant MFA — FIDO2 security keys or Windows Hello for Business — through Conditional Access removes the AiTM path entirely, because there's no session token or one-time code for a fake page to intercept.[1] That's a real fix, not a mitigation that just raises the attacker's cost.
Beyond that, Microsoft's guidance leans heavily on treating this as a connected sequence rather than isolated alerts:
- Restrict the device-code flow. Block device code and authentication transfer flows via Conditional Access unless there's a genuine business need for them — this closes off one of the two phishing paths Microsoft documented.
- Lock down MFA registration. Require managed devices, named locations, and phishing-resistant authentication strength specifically for security info registration, and set sign-in frequency to require fresh interactive authentication for that action.
- Watch for new authentication methods on existing accounts. A newly registered phone or authenticator app on an account with a recent risky sign-in is one of the highest-signal indicators in this whole chain.
- Correlate Graph activity across categories, not endpoints. A single request to
/usersmeans nothing. The same identity touching directory, privilege, application, and repository endpoints within a short window is what should trigger review. - Restrict unmanaged devices to web-only, no-download sessions for SharePoint and OneDrive, and disable anonymous sharing links.
- Train staff to distrust unsolicited "update your passkey" calls to personal phones, and give them a verified channel to report and confirm helpdesk-initiated resets before acting on them.
None of this is exotic. What makes the campaign effective isn't novel technique — device-code phishing and AiTM are both known quantities — it's that the entry point (a phone call to a personal device) sits almost entirely outside the visibility most security teams have built their detection around.
Security takeaway
The uncomfortable pattern here is that MFA, treated as a checkbox, doesn't stop this attack. It's not that MFA failed technically — it's that the attacker got the victim to complete it for them, and then quietly added their own second factor so they wouldn't need the victim again. That's the actual lesson: MFA method type matters as much as MFA presence, and a password reset alone is not remediation if a rogue authentication method is still sitting on the account. If your organization hasn't looked at how many identities still allow phishable MFA methods, or whether device-code flows are actually restricted, this campaign is a reasonable prompt to check both this week.
Sources & References
- [1] Microsoft Security Research — Passkey-themed social engineering leads to identity and cloud compromise — September 9, 2026 — Official Microsoft Security Blog post
- [2] Microsoft Security Research — Protecting organizations from AI-assisted executive impersonation and invoice fraud — September 10, 2026 — Official Microsoft Security Blog post
- [3] Ravie Lakshmanan, The Hacker News — Attackers Use Passkey Phishing to Hijack Microsoft Cloud Accounts and Exfiltrate Data — September 13, 2026 — View source
- [4] MITRE ATT&CK — T1556.006, Modify Authentication Process: Multi-Factor Authentication — MITRE ATT&CK technique reference
- [5] MITRE ATT&CK — T1078.004, Valid Accounts: Cloud Accounts — MITRE ATT&CK technique reference
Disclaimer: This article summarizes threat intelligence published by Microsoft Security Research as of September 9–13, 2026. Attribution to specific threat actor clusters reflects Microsoft's stated assessment and may be revised as investigations continue.
Technical Discussion & Feedback (0)
Leave a Comment (Authenticated Users)