Passkey & Identity Phishing Evolutions: Beyond the Pretext — AiTM, Device Code, and Helpdesk Social Engineering Defenses

Attackers aren't breaking passkeys. They're calling your employees, pretending to be the helpdesk, and talking them past the controls that were supposed to stop this.

What Microsoft found

On September 9, 2026, Microsoft Security Research published details of active cloud intrusions it has been tracking since May 2026, spanning multiple compromised Microsoft 365 accounts.[1] The pattern was consistent enough to name: an odd sign-in, followed by the attacker registering their own authentication method, followed by a burst of Microsoft Graph activity, followed by SharePoint, OneDrive, and Exchange access that looked a lot like systematic data collection.[1]

What made this cluster worth a dedicated report wasn't a new exploit. It was the pretext. Employees were getting calls or texts on their personal phones from someone claiming to be internal IT, telling them a passkey, MFA method, or SSO configuration needed to be updated right away.[1] CSO Online's reporting on the campaign quoted Jon Baker of AttackIQ putting it plainly: the passkey in this story is the lure, not the weakness.[2]

The pretext is the point, not the payload

Here's the part that trips people up. Microsoft's own researchers wrote that despite the constant passkey framing, enrolling a passkey is usually not what the attacker actually wants.[1] The passkey narrative is just a convincing reason to get someone to a fake sign-in page or to walk them through entering a code. Two very different technical mechanisms sit behind that same story.

In adversary-in-the-middle (AiTM) scenarios, the victim lands on a proxy site that mirrors the real Microsoft sign-in experience closely enough to capture both credentials and the resulting session token as it's issued.[1] In device code scenarios, there's no fake login page involved at all — the victim is told to visit Microsoft's actual authentication page and type in a code the attacker supplies, and that approval hands a valid token to a client the attacker controls.[1]

Domains built for this campaign followed a predictable naming pattern: the target organization's name folded into a subdomain of something like secure-passkey[.]com or oskeysync[.]com, registered and operational within hours.[1] That speed matters — it's part of why the initial contact is so often the only evidence an investigator gets, especially when the victim clicks the link on a personal phone that Microsoft Defender for Endpoint has never seen.[1]

How device code phishing actually works

Device code flow is a legitimate part of OAuth 2.0, built for devices that can't easily run a browser — think smart TVs, CLI tools, or conference-room hardware. The device requests a code from Entra ID, the user takes that code to a second device, enters it at Microsoft's real login page, and the original device gets a token.[7] There's nothing wrong with the protocol. The problem is that nothing in the flow forces the code to have come from a device the user actually owns.

In one sequence Microsoft investigated, the actor used exactly this gap: the passkey-themed pretext steered the victim into entering a device code, and that single approval bypassed MFA entirely and issued a working session token — no browser cookie theft required.[1] A separate, earlier Microsoft report from April 2026 on an AI-enabled device code campaign found automation that generated codes dynamically enough to get around the standard 15-minute expiration window, a step up from the earlier, more manual Storm-2372 campaign from February 2025.[5]

Device code phishing isn't limited to one actor or one kit anymore. Reporting from The Hacker News in July 2026 described a phishing-as-a-service operation called Forg365 that combines device code phishing with AiTM session theft against Microsoft 365, complete with traffic classification that serves decoy content to anything that looks like a VPN connection and real content to everyone else.[4] That's a commercial kit built specifically to blend into normal traffic analysis, not a one-off proof of concept.

What happens after the first click

The initial compromise is only step one. Microsoft's timeline of one investigated sequence shows the actor moving from a successful sign-in to enumerating assigned applications within two minutes, touching approval-management and account-control interfaces within three minutes, and reaching SharePoint and Outlook Web within eleven.[1] That's not a person poking around. It's a script working through a checklist.

The first real objective after access is persistence, and the method is almost boring in its simplicity: register a new MFA method — a phone number, an authenticator app, a software OTP — under the attacker's control.[1] BleepingComputer's coverage noted that in one case, the attacker's device-authentication session stayed active for about an hour while they listed sensitive files and internal applications — plenty of time, and short enough to look unremarkable.[3]

Reconnaissance that hides in plain sight

Once an actor-controlled MFA method is in place, the reconnaissance phase runs almost entirely through Microsoft Graph — enumerating users and groups, checking directory roles and registered authentication methods, mapping applications and OAuth consent grants, then walking SharePoint sites and mailboxes.[1] Individually, none of these calls looks suspicious; hitting /users or /sites is completely normal enterprise behavior. Microsoft's own write-up makes the point directly: the same identity systematically touching multiple resource categories in a short window is the actual signal, not any single request.[1]

What follows is deliberately unhurried. Microsoft observed the actors keeping data collection under roughly 1,000 files or emails per hour, sustained over hours to multiple days rather than a rapid smash-and-grab, which helps the activity blend with ordinary usage patterns.[1] Some sessions showed a python-httpx user agent tied to high-volume SharePoint and OneDrive access — worth watching for, though Microsoft is careful to note the user agent alone isn't proof of anything; it needs context from volume, source infrastructure, and prior signs of compromise.[1]

Microsoft attributes the initial-access activity in this cluster to a range of actors including Storm-3121, which feeds into ShinyHunters and Falcon extortion operations, and Storm-3032, a group that split from BlackFile and now operates under the Helix extortion brand.[1] The report is careful to note this is initial-access tradecraft shared across an ecosystem, not a single group's signature.

Why phishing-resistant MFA alone doesn't close this gap

This is the uncomfortable part. CISA has called FIDO2/WebAuthn-based authentication the gold standard for phishing-resistant MFA, and that assessment holds up technically — a real passkey ceremony is cryptographically bound to the origin it was issued for, so a proxy site simply can't relay it the way it can relay a password and OTP.[6] But device code phishing doesn't attack the passkey. It routes around the entire authentication ceremony by getting a human to approve a code on the genuine Microsoft page. The user really is authenticating to Microsoft — they just don't know which device is on the other end of that approval.

That's why Microsoft's guidance treats phishing-resistant MFA as necessary but not sufficient on its own, and pairs it explicitly with blocking or restricting the device code and authentication-transfer flows themselves.[1]

Layered defenses that actually address this pattern

1. Phishing-resistant MFA as the baseline, not the whole plan

Enforce FIDO2 security keys, passkeys, or Windows Hello for Business through Conditional Access, and require phishing-resistant authentication specifically for security-info registration — the moment where a new MFA method gets added to an account.[1]

2. Block device code flow by default

Microsoft Learn's guidance is direct: organizations should get as close as possible to a unilateral block on device code flow, building a Conditional Access policy that targets the Authentication Flows condition, starting in report-only mode, and excluding only well-documented, audited use cases like legacy tooling that genuinely can't be updated.[7] The same policy type should cover authentication transfer.

3. Require a managed, compliant device for sensitive workloads

Conditional Access policies that require a compliant device for Exchange, SharePoint, and Graph-privileged applications remove a lot of the room an unmanaged phishing session has to operate in.[1]

4. Lock down security-info registration specifically

Set sign-in frequency to always require fresh interactive authentication for security-info registration, require a managed device or named location, mandate phishing-resistant authentication strength, and block registration outright when sign-in risk is high.[1]

5. Fix the helpdesk process, not just the technology

A rigorous identity-verification step before any helpdesk-initiated credential or MFA reset — and an alert every time that reset happens — closes the exact door this campaign walks through.[1] Give employees a verified channel to report an unsolicited authentication request instead of just hanging up and wondering.

6. Restrict consent and watch high-privilege Graph permissions

Require admin approval for user consent to applications and regularly review service principals holding permissions like Mail.Read, Files.Read.All, and Directory.Read.All.[1]

7. Hunt for the pattern, not the indicator

Domains and IPs rotate quickly, but the sequence — unusual sign-in, new auth method, Graph reconnaissance across multiple categories, then SharePoint/OneDrive/Exchange access — is durable.[1] Microsoft's report includes Advanced Hunting queries for exactly this correlation, built around identities that touch three or more reconnaissance categories from the same IP within a 30-minute window.[1]

Security takeaway

The technology in this campaign isn't new — device code flow has existed for years, and AiTM proxies have been a known problem since at least Storm-2372's disclosure in early 2025.[5] What's changed is the packaging. A helpdesk phone call framed around passkeys is a better pretext than a generic phishing email, because it borrows the credibility of a security upgrade to get someone to lower their guard. Passkeys themselves remain sound; the failure mode here is entirely social and procedural — a human being talked through an authorization they didn't understand, on infrastructure that looked completely legitimate because, technically, it was.

Defending against this means treating identity events as a connected sequence rather than isolated alerts, closing the device code and authentication-transfer flows that don't need to be open, and putting a real verification gate in front of every helpdesk-initiated MFA reset. None of that requires new technology most Microsoft 365 tenants don't already have access to. It requires actually turning it on.

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] Shweta Sharma, CSO Online — Attackers use passkey-themed scams to hijack Microsoft 365 accounts — September 11, 2026 — CSO Online coverage
• [3] BleepingComputer — Passkey-themed phishing attacks lead to Microsoft 365 data theft — BleepingComputer report
• [4] Ravie Lakshmanan, The Hacker News — Forg365 PhaaS Targets Microsoft 365 with Device Code and AitM Session Theft — July 13, 2026 — The Hacker News article
• [5] Microsoft Security Blog — Inside an AI-enabled device code phishing campaign — April 6, 2026 — Microsoft Security Blog post
• [6] CISA — Implementing Phishing-Resistant MFA (fact sheet) — October 2022 — CISA fact sheet (PDF)
• [7] Microsoft Learn — Block authentication flows with Conditional Access policy — Microsoft Learn documentation

Disclaimer: This article summarizes vendor and press reporting current as of publication. Attribution and technique details reflect Microsoft's assessment as published and may be revised as investigations continue.