Passkey-themed phishing drains corporate Microsoft 365 accounts
Microsoft documents attacks in which ShinyHunters and Helix-linked gangs impersonate the help desk to steer employees toward passkey-themed phishing pages, then exfiltrate Microsoft 365 data. The defense rests less on the passkey itself than on phishing-resistant authentication and session revocation.
September 11, 2026. Microsoft is detailing a campaign in which groups tied to ShinyHunters, Helix, and other extortion gangs use passkey-themed social engineering to compromise corporate accounts and drain data from Microsoft 365. The activity dates back to May 2026, and the trick is brutally simple: pose as the internal help desk, then claim a passkey or SSO configuration needs an urgent update. The attack is especially cruel because it weaponizes the very tool meant to protect us from phishing.
The passkey is not attacked, it is the bait
The detail that changes everything: the attackers are not trying to enroll a passkey. Microsoft is explicit on this point. The words “passkey,” “MFA,” and “SSO” are only a lure to get the target to click.
The real mechanics rely on two known techniques. The first is adversary-in-the-middle (AiTM), where a phishing site relays the victim’s session to the real Microsoft portal in real time, capturing credentials and session tokens along the way. The second is device code phishing: the victim, guided by phone, enters a code supplied by the attacker on Microsoft’s legitimate authentication page, which hands an OAuth token to an attacker-controlled application.
Microsoft notes the attackers invest heavily in pre-attack research: employee profiles, org charts, professional platforms. Phishing domains combine the company name with terms like passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, or oktasession[.]com, often with the victim’s company in a subdomain (company.secure-passkey[.]com). The lure arrives by phone call or SMS to the personal device.
Who is behind it, and how the tracks connect
Microsoft ties the activity to several actors in a single extortion ecosystem: Storm-3121, associated with ShinyHunters and Falcon extortion, and Storm-3032, linked to former BlackFile members now operating as Helix.
The overlap with Google Threat Intelligence is telling. Google had already documented the UNC6671 cluster, which combines phone-based social engineering and passkey-themed phishing infrastructure before breaking into enterprise cloud environments. Google links UNC6671 to the same gangs: BlackFile, Helix, Falcon, Pink, and Redact. Two intelligence teams converge on the same actors, with the same technical signature.
What happens once the session is stolen
The most instructive part of the report is the post-compromise sequence. In one case, Microsoft saw a suspicious sign-in from an unmanaged device to a Microsoft 365 service identified in Entra logs as OfficeHome. After a valid MFA, the attacker established a legitimate session and, within minutes, began inventorying reachable resources: My Apps, My Profile, the approval-management and sign-in interfaces.
That was followed by access to SharePoint Online, Outlook Web, the collaboration and search services, and an internal line-of-business application. The session stayed active for about an hour while the attacker listed sensitive files and internal apps.
Persistence is equally methodical. Attackers add an MFA method they control: new phone numbers, authenticator apps, software TOTP tokens. That lets them satisfy future MFA challenges without the victim — though Microsoft notes it does not survive a full credential and session reset.
Then comes Microsoft Graph enumeration: organizations, licenses, users, groups, directory roles, registered authentication methods, applications, service principals, OAuth permissions, SharePoint sites, OneDrive documents, mail folders and attachments. Requests like /users, /groups, or /sites are common in enterprises and raise no alarm. The suspicious signal appears when the same account moves rapidly across resources, checks privileges, and then starts pulling email and documents.
The final step is exfiltration: high-volume access and download from SharePoint Online and OneDrive for Business, with some intrusions reaching Exchange Online through REST API access to mailbox content.
Where the passkey holds, and where it breaks
Be precise about what this campaign says — and does not say — about the passkey. A FIDO2 assertion is origin-bound: an AiTM relay can capture the session token, but cannot replay the assertion on another domain. That property is what makes the passkey structurally superior to TOTP or SMS against phishing. None of these attacks “break” the passkey.
What breaks is the enrollment and recovery path, where the human is the weak link. The attacker does not bypass the passkey: they convince the employee to authenticate through another channel — a device code, a relayed session — while waving the word “passkey” as an urgency alibi. The lesson inverts intuition: the louder an organization talks about passkeys, the harder it must lock down the weak authentication flows around them.
In practice, three controls matter more than the rest. First, restrict the device code flow to tenants and applications with a legitimate use, since it is this campaign’s favorite channel. Second, gate MFA method enrollment behind managed devices and a strong re-authentication, to block the “attacker’s phone number” addition. Third, treat any new MFA method as a security event to correlate, not a directory triviality.
Verdict
The foothold in this campaign is not a passkey flaw but the friction between humans and authentication. The passkey remains technically phishing-resistant — a true AiTM cannot replay a FIDO2 assertion bound to an origin. The problem is that an employee who thinks they are “re-enrolling a passkey” ends up entering a device code or signing into a relay, and no cryptography saves them at that point.
If you run Microsoft 365, enforce phishing-resistant authentication (FIDO2 passkeys, security keys, certificate-based authentication) and block the weak flows: disable the device code flow for tenants that do not need it, restrict MFA enrollment to managed devices, and treat new MFA methods as a first-class alert signal.
If you are a busy CISO, circulate one rule: the help desk will never ask anyone to re-register a passkey through a link sent by SMS. And rehearse session revocation as a reflex — because in this campaign, it is the only barrier persistence cannot cross.