Passkey Phishing Hits Microsoft Cloud: The Identity Layer Cracks

Any platform lead who signed off on a passkey rollout in the last twelve months needs to reopen that decision memo this week. Microsoft has now documented two active campaigns that treat the passkey enrollment flow itself as the attack surface, and the economics of the defense stack just shifted. The vendor pitch that passkeys eliminate phishing risk was always half true; the other half is now visible in the incident data.

What Happened

Between August 3 and 5, 2026, threat actors pushed over a million scam emails through third-party delivery infrastructure, impersonating CEOs at target companies and pressuring accounts payable teams to wire ACH payments for a fake ServiceNow annual subscription. As The Hacker News reported, the operators used generative AI to draft tailored email templates, registered impersonation domains including service-nowinc[.]com and domainlify[.]net, and populated signature blocks with real names of CEOs, CFOs, and presidents lifted from public sources. The primary target was U.S. enterprises in IT services, consumer goods, real estate, and discrete manufacturing.

The second campaign, running since May 2026, is the more architecturally interesting one. Attackers call or SMS a user's personal phone number, claim to be from internal IT help desk, and instruct them to update their passkey, MFA, or SSO configuration. Victims get redirected to counterfeit Microsoft sign-in pages and either surrender credentials through an adversary-in-the-middle proxy or approve a device-code authentication flow that grants the attacker a token without ever exposing a password.

Once inside, the pattern is consistent: suspicious sign-in, then the attacker enrolls their own authentication method (a new phone number, an authenticator app, or a software OTP), then high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and mailbox collection via REST APIs. Microsoft describes this as automated collection from compromised cloud identities using proxy-associated infrastructure. The activity overlaps with a cybercrime cluster tracked variously as Cordial Spider, O-UNC-045, PREY-0058, and UNC6671, with Microsoft attributing initial access to Storm-3121 and Storm-3032. Storm-3121 feeds into ShinyHunters and Falcon extortion; Storm-3032 (UNC6671) split from the BlackFile group and now operates under the Helix extortion brand.

Technical Anatomy

The core deception exploits a gap between how identity vendors describe passkeys and how end users experience them. A passkey is phishing-resistant at the cryptographic layer: the private key never leaves the device, and the browser binds the assertion to the origin. That property is real. What is not phishing-resistant is the enrollment ceremony, the recovery flow, and the user's mental model of what "updating a passkey" even means. Attackers have identified that gap and are driving trucks through it.

The registered domain list tells you how deliberate this is: passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, syncmykey[.]com, portalsetuphub[.]com. The pattern is company-specific subdomains grafted onto generic passkey-themed roots, so a target sees acme.passkeyhelpdesk[.]com and pattern-matches on the brand rather than the domain. Google-owned Mandiant flagged the same technique last month for UNC6671.

Two attack flows carry the load. In the AitM path, the fake portal proxies the real Microsoft sign-in and captures both credentials and the session cookie post-MFA. In the device-code path, the attacker initiates a device authorization request against Microsoft's own endpoints, then socially engineers the victim into entering the attacker's code on a legitimate Microsoft page. That second flow is the one CISOs need to grasp: the victim never visits a phishing site, never enters credentials into anything suspicious, and MFA completes normally. Microsoft's own infrastructure issues a valid token to the attacker's device. This maps cleanly to techniques catalogued under MITRE ATT&CK for phishing and valid account abuse, but the device-code variant sidesteps most conditional access policies that assume the login page itself is the trust boundary.

Persistence is the second-stage story. Microsoft observed the actor enrolling a new MFA method under their control immediately after initial access, converting a session-length compromise into indefinite tenancy. In one documented incident, attackers used credentials from a prior event to register a phone-based method and bypass MFA entirely on subsequent logins. In another, an anomalous sign-in from an unmanaged device to Microsoft Office Home was followed by Graph API expansion into SharePoint Online and OneDrive.

Who Gets Burned

Start with the finance function. The ACH campaign specifically targeted accounts payable staff at U.S. enterprises across IT services, consumer goods, real estate, and discrete manufacturing. These are teams where the average tenure of the AP clerk is shorter than the average vendor relationship, and where a ServiceNow renewal invoice from someone matching the CEO's name and email domain hits an entirely plausible pattern. Any CFO whose vendor onboarding process still relies on email-based approvals is now underwriting a loss that will not be covered by the crime rider on their cyber policy in most jurisdictions.

Second, identity teams at any organization that recently deployed passkeys as a "phishing-resistant" control. The board deck said passkeys solve phishing. The incident data says passkeys solve one narrow variant of credential theft while opening two new social engineering vectors: enrollment manipulation and recovery abuse. The VP Eng who owns the identity roadmap needs to explain to the audit committee why the control that was sold as terminal is now the thing being spoofed on registered lookalike domains.

Third, and this is the underappreciated one, Microsoft 365 tenants that treat Graph API activity as ambient noise. The observed pattern is high-volume Graph calls, SharePoint and OneDrive bulk downloads, and mailbox enumeration through REST endpoints. If your SIEM is not baselining per-identity Graph call rates and does not fire on new MFA method registration from an unmanaged device, you have no detection surface for this campaign. The Head of Platform whose logging bill has been trimmed twice in the last four quarters is about to find out what was cut.

Every CFO and General Counsel pair should be asking their CISO this week: what is our documented process when an employee reports a suspicious call from someone claiming to be IT, and does that process include automatic invalidation of any authentication method registered in the preceding twenty-four hours? If the answer is a shrug or a policy PDF nobody has read since onboarding, the incident response retainer is already burning.

Playbook for Security Teams

Kill user-initiated MFA enrollment from unmanaged devices. If a passkey, phone number, or authenticator app can be added to a corporate identity from a personal device outside your MDM, you have already lost the persistence fight. Route enrollment through a managed device or an in-person help desk verification, and accept the friction.

Alert on new authentication method registration as a first-class detection, not a compliance checkbox. The signal here is loud: a phone number added from a residential IP within minutes of a sign-in from a new geography is not a false positive. Tie it to automatic session revocation and force reauthentication through a channel the attacker does not control.

Disable device-code authentication flows for user accounts unless there is a documented business need. Most enterprises enabled it once for a CLI tool and never revisited the policy. Conditional access can scope it to specific applications and trusted networks. Do that this week.

On the ACH side, mandate out-of-band verification for any vendor payment change or new invoice above a threshold your CFO sets. Voice callback to a number on file, not a number in the email. This is a 1990s control that solves a 2026 attack because the attack is a 1990s attack with generative AI polish.

Finally, hunt for the domain pattern. Block outbound DNS to the passkey-themed roots Microsoft published, and add a proxy rule for any subdomain matching your own company name on a domain registered in the last ninety days. That single rule would have stopped a meaningful percentage of the observed intrusions.

Key Takeaways

• Passkeys are cryptographically phishing-resistant, but enrollment and recovery flows remain fully social-engineerable, and attackers have industrialized that gap.
• Device-code phishing bypasses MFA without stealing credentials or cookies, and most conditional access policies do not catch it by default.
• The ACH campaign hit over a million inboxes in three days using generative AI for template drafting and public sources for executive impersonation.
• Persistence comes from attacker-registered MFA methods added immediately after initial access; detecting new-method enrollment is now a tier-one control.
• The threat cluster spans Storm-3121, Storm-3032, UNC6671, Cordial Spider, and connects to ShinyHunters, Falcon, and Helix extortion brands, meaning initial access here funds ransomware downstream.

Teams evaluating passkey deployments in the next 90 days should now be asking themselves a different question. Not "does this eliminate phishing," but "who owns the enrollment ceremony, and what does it cost us to make that ceremony hostile to attackers?" The answer will show up in headcount, in help desk process redesign, and in a vendor conversation about conditional access licensing that nobody budgeted for.