Sep 15, 2026 · 7 min read
Passkey Phishing Lures Now Loot Microsoft 365 Inboxes
Since May 2026, callers posing as corporate IT have told employees their passkey needs an urgent update. No passkey is ever enrolled. What the victim hands over is a Microsoft 365 session, and Microsoft has traced the technique to Storm-3121, Storm-3032, and a Google tracked cluster called UNC6671.
The pitch works because we taught people it would. Passkeys are the strongest authentication shipping today, and the industry has spent years saying so loudly. Attackers listened, then borrowed the vocabulary. When a voice on the phone says "passkey," the word arrives pre loaded with trust that every security awareness deck built for it. Microsoft published the research on September 9, 2026.
Key Takeaways
- Microsoft has tracked passkey themed social engineering against Microsoft 365 tenants since May 2026, attributing initial access to Storm-3121, whose activity leads to ShinyHunters and Falcon extortion, and Storm-3032, made up of former BlackFile members now operating as Helix.
- No passkey is enrolled: the word is only a pretext routing victims to adversary in the middle sign in pages or to a device code approval that hands a token to an attacker controlled client.
- Phishing domains included passkeyhelpdesk[.]com, secure-passkey[.]com and oktasession[.]com, each with the target company name inserted as a subdomain.
- Once inside, operators stayed below 1,000 files or emails per hour to evade volume based detection, pulling SharePoint, OneDrive and Exchange Online data via the python-httpx user agent. Source: BleepingComputer
Why Is "Passkey" the Perfect Phishing Pretext?
"Passkey" works as a pretext precisely because users have been trained that passkeys are unphishable, so the word functions as a credential for the caller rather than a warning. The defense's marketing became the attacker's opening line.
The irony is buried in the standards. NIST defines phishing resistance in SP 800-63B as the protocol's ability to prevent disclosure of authentication secrets to an impostor verifier "without relying on the vigilance of the claimant." That property holds only while the protocol is running. A phone call about a passkey is not a passkey ceremony, so none of the cryptography applies. The attack lives in the gap between the brand and the protocol.
Microsoft's recommended fix is FIDO2 passkeys, so the thing being impersonated is also the thing that would have stopped the attack. Of the 39 documented attack methods against passkey authentication, almost none break the signature scheme. They go around it.
Who Is Running These Attacks?
Storm-3121 and Storm-3032 hand their access to extortion crews rather than monetizing mailboxes themselves. Google Threat Intelligence tracks the overlapping activity as UNC6671, linking it to BlackFile, Helix, Falcon, Pink and Redact.
Five extortion brands drawing on one intrusion technique means the pretext circulates as tradecraft rather than a single group's signature, so brand level takedowns will not retire it. The same pattern showed up in the Storm-2755 payroll pirate campaign against Microsoft 365, where adversary in the middle access was the commodity and the payload varied by buyer.
Targeting starts on social and professional networks, so the caller already knows who you report to, and the phishing domains carry your company name as a subdomain so the URL reads as a tenant portal.
How Does Device Code Phishing Bypass MFA?
Device code phishing bypasses MFA by never fighting it: the victim types a code into the genuine Microsoft authentication page, and that approval issues a token to an attacker controlled client. Every certificate is valid. Every domain is real. The user completes MFA correctly and the token lands somewhere else.
This is why it resists training: the standard advice is to check the URL, and the URL is microsoft.com. The campaign's other path is an adversary in the middle proxy relaying the session live, which we examined in NovaCookies harvesting Microsoft 365 sessions through fake DocuSign notifications. Both endpoints are the same: a live session, no second MFA prompt.
Microsoft's guidance here is unusually blunt. Its Conditional Access documentation tells organizations to "get as close as possible to a unilateral block on device code flow," allowing it only for documented legacy tooling. The flow exists for devices without keyboards. If nobody in your tenant uses one, it is pure attack surface.
What Happens After the Attacker Is Inside?
The first sign in from an unmanaged device surfaces in Entra logs as "OfficeHome," the shared Office 365 portal application, preceded by error 50074 for secondary authentication and error 50140 for the keep me signed in interruption. That sequence is the cleanest early detection opportunity available.
What follows is methodical. The operators query Microsoft Graph across /users, /groups, /directoryroles, /applications, /sites, /drives, /messages and /mailfolders, mapping privileged accounts, OAuth permissions and service principals before touching a file. Then they register their own phone number, authenticator app or software one time password token, so the next MFA prompt answers itself.
Collection is deliberately patient. Microsoft observed sessions lasting from hours to multiple days while staying under 1,000 files or emails in any one hour window, the python-httpx user agent visible during automated pulls. Run the arithmetic: at 999 items an hour, a three day session moves roughly 71,000 files and messages without tripping a volume alert. Throttling is not caution. It is a detection budget being spent carefully. That user agent is worth hunting, since Microsoft Graph activity logs record a UserAgent column against every API request in the tenant.
What This Means for Your Inbox
Exchange Online is not a side effect of this intrusion. It is an objective. Microsoft documented mail folders, messages and attachments among the enumerated Graph endpoints, with mailbox contents read through the REST API. Your sent folder is a map of who trusts you.
A read mailbox is also a staging area. Anyone who sees your threads can reply inside them, from your real address, with the right history and tone, which is why Microsoft's incident response guidance specifically calls for removing attacker created mailbox rules after a compromise. Those rules exist to hide the replies from you.
Nothing here depends on a Microsoft only weakness. Help desk impersonation and token theft after a valid MFA ceremony apply equally to Google Workspace and Okta protected tenants, and the campaign's domain list already includes oktasession[.]com. Assume the pretext is being rehearsed against every identity provider you run.
How Do You Shut This Down?
Most of Microsoft's guidance is configuration you can change this week.
- Enforce phishing resistant MFA. FIDO2 passkeys and Windows Hello for Business break the relay outright, because the credential is bound to the origin.
- Block device code and authentication transfer flows. Use the Authentication Flows condition in Conditional Access, starting in report only mode to find legitimate usage.
- Restrict sensitive resources to managed devices. An unmanaged device appearing as OfficeHome should not reach SharePoint at all.
- Alert on the sequence, not the events. An unusual sign in, then a new MFA registration, then Graph enumeration is a chain no legitimate user produces. Enable Graph activity logs and mailbox auditing so it is visible.
- On compromise, reset completely. Revoke sessions and refresh tokens, reset credentials, and remove attacker added authentication methods and mailbox rules. Microsoft notes the persistence dies with a full reset, but a partial one leaves the attacker's authenticator in place.
Add the one control no documentation gives you: your help desk should never initiate an authentication change by phone, and every employee should know it. Make the callback the rule.
The Uncomfortable Lesson
Passkeys are not weakened by this campaign. They are the countermeasure to it. But the industry sold them as the thing you no longer have to think about, and NIST's framing reinforced it: security that does not rely on the vigilance of the user. Storm-3121 read that as an opportunity. Market a technology as removing the need for suspicion and you produce users who are not suspicious when someone says its name. Expect the next pretext to borrow whatever the industry promotes hardest in 2027.