Passkey-Themed Phishing Is Breaching Microsoft 365 — Not Passkeys Themselves

Microsoft has disclosed two concurrent but unrelated attack campaigns against its cloud customers: a social-engineering wave that uses passkey setup as bait to break into Microsoft 365 accounts, and a separate, high-volume invoice-fraud blast targeting accounts-payable teams. Neither involves a technical flaw in Microsoft's products — both are process and human-verification failures, which is exactly why they're working.

The "passkey" angle is a lure, not a break

The more notable of the two, active since May 2026, is built around passkey-themed pretexts. Per Microsoft's writeup, attackers call employees pretending to be IT help desk staff and direct them by SMS to counterfeit login pages on domains like passkeyhelpdesk[.]com, secure-passkey[.]com, and setupmypasskey[.]com. Passkeys themselves remain phishing-resistant — Microsoft is explicit that passkey enrollment is usually not the attacker's real goal. The narrative is a convincing cover story to walk a victim through an adversary-in-the-middle (AiTM) proxy or a device-code authentication flow, or, where credentials were already stolen in an earlier breach, to get a victim to approve an attacker-controlled phone-based MFA method.

Why this bypasses MFA without breaking it

Device-code phishing abuses a legitimate Microsoft sign-in flow meant for input-constrained devices: the victim is talked into entering a real, valid code on the genuine Microsoft login page, which hands the attacker a working session token. No password is phished and no MFA prompt is technically defeated — the victim authenticates the attacker's session for them. It's the same technique flagged in Microsoft's 2025 Storm-2372 disclosure, now repackaged with a passkey theme.

What happens after access

Once in, the intrusions follow a consistent pattern: high-volume Microsoft Graph API calls to enumerate tenant resources, bulk SharePoint and OneDrive downloads, and mailbox collection via REST APIs, with exfiltration windows running from a few hours to several days. Microsoft attributes the activity to Storm-3121, which feeds into ShinyHunters/Falcon extortion operations, and Storm-3032, a splinter of the BlackFile group now running the Helix extortion brand — both financially motivated, not nation-state.

A second, unrelated wave: a million-email invoice scam

Separately, Microsoft says attackers sent over a million scam emails between August 3 and 5, 2026, impersonating chief executives and routing messages through trusted third-party email infrastructure and domains such as service-nowinc[.]com and domainlify[.]net. The lure was a fabricated ServiceNow subscription invoice, aimed at accounts-payable staff at U.S. firms in IT services, consumer goods, real estate, and discrete manufacturing, with the goal of triggering an ACH transfer to attacker-controlled accounts.

What defenders should actually do

• Restrict or disable the OAuth device-code flow via Conditional Access unless a specific business case needs it — it's the mechanism both AiTM and device-code phishing rides on.
• Alert on new MFA/authentication-method registrations, especially phone-based methods added shortly after a help-desk contact or password reset.
• Treat inbound calls or texts about "setting up" or "verifying" a passkey as suspicious by default — legitimate IT workflows shouldn't require it, and help desks should authenticate the caller, not the other way around.
• For AP teams, require callback verification on a known number — not one in the email — before changing payment details or approving a new vendor invoice, regardless of who it appears to come from.

Neither campaign needs a novel exploit to succeed; both rely on someone under time pressure trusting an unverified call, text, or email. That's the gap worth testing before an attacker finds it for you.