Under 1,000 an Hour: The Passkey Rollout Became the Best Phishing Pretext of 2026

On September 1, 2026, Microsoft flipped a switch identity teams had wanted for years. Every Entra ID user still enrolled in SMS or voice MFA was auto-enabled for passkeys, and at their next multifactor prompt they got pushed toward registering one. Microsoft-provided SMS and voice delivery goes dark completely on February 1, 2027, per Microsoft's own retirement documentation. This is the right call. Phishing-resistant authentication is the highest-value identity control most organizations can turn on this decade.

Attackers started working the rollout four months before it shipped.

On September 9, Microsoft Threat Intelligence published a teardown of a campaign it has tracked since May 2026. The pattern: operators call or text an employee on their personal phone, say they are the internal IT help desk, and explain that a passkey, MFA or SSO configuration has to be updated immediately to avoid losing access. Microsoft's words for the caller's technique are "creates a sense of urgency." Mine would be "reads the change log out loud."

Microsoft attributes the initial access to a set of clusters including Storm-3121 and Storm-3032. Google's Threat Intelligence Group tracks overlapping activity as UNC6671, which CrowdStrike calls Cordial Spider and Unit 42 tracks as CL-CRI-1116. GTIG counted more than $10.6 million in Bitcoin paid to the group between January and May 2026, with opening demands as high as $3 million typically settling near $750,000. Same crew, same phone script, now rebranded across the REDACT, Pink, Helix and Falcon extortion labels after retiring BlackFile in May. Their recent victim list, per BleepingComputer's reporting, runs through hedge funds and private equity: Point72, Millennium Management, Two Sigma, Citadel.

The pretext was in the release notes

Here is what makes this campaign different from the generic "your password expires today" call. The pretext is true.

Your users really are being told by Microsoft to register a passkey. That prompt really did start appearing on September 1. Your help desk really is fielding confused tickets about it. Somewhere in your organization there is a genuine email with a genuine deadline explaining that SMS codes are going away. When an attacker calls and says "we need to move you to a passkey before you lose access," they are not inventing a story the victim has to be talked into. They are echoing an internal comms campaign the victim already half-remembers.

Security awareness training is built on the assumption that the lure contains something false the user can catch. Here the only false thing is the caller's identity, and the caller is phoning a personal mobile number where no corporate banner, no external-sender warning and no mail filter exists. We saw the same structural problem in the McKesson breach that started with a phone call, where one Okta SSO session was enough to reach 284 million records in four days.

The infrastructure is cheap and disposable. Microsoft documented domains registered through Nicenic and operational within hours, following a companyname[.]maliciousdomain[.]com pattern. Published examples include passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, syncmykey[.]com, integratedsso[.]com and oktasession[.]com. If your brand protection vendor is not watching for newly registered domains containing "passkey" alongside your company name, this quarter is a good one to start.

Nobody fought the passkey

Read the attack chain closely and you notice something the headlines mostly missed: in the sequences Microsoft describes, the passkey itself is never defeated. It is the topic of conversation, not the target.

Microsoft documents three paths into the identity. The first is ordinary adversary-in-the-middle phishing, capturing credentials and a session token from a lookalike sign-in page, then a first sign-in to OfficeHome from an unmanaged device with MFA completed. The second is device code flow, where the user is walked through entering a code on the real microsoft.com authentication page. Nothing about that page is fake. The user is signing in legitimately, and the token that comes out goes to a client the attacker controls, with no browser cookie stolen at any point. The third is plain token replay, and this one is the most instructive: Microsoft observed MFA approved through a PhoneAppOTP method that suggests the attacker had registered an authenticator app days before the campaign against that victim started.

Device code flow is not a bug. It exists so you can sign a smart TV or a headless build agent into a tenant. It also produces a fully valid token for an attacker who never has to render a convincing login page, which is why phishing kits have been migrating toward it. Compare that with the approach in the BigBear 2.0 kit that hunts and deletes canary tokens: the AiTM operators are spending engineering effort to strip detection artifacts out of hijacked sessions, while the device code operators just sidestep the session entirely.

If your conditional access policies do not block device code and authentication transfer flows, you have a supported, documented, fully logged path around a passkey rollout you are in the middle of paying for. Microsoft's own mitigation list puts blocking those flows near the top. Almost nobody does it, because somewhere in the estate there is one conference room display that needs it.

The second factor they added was theirs

Persistence in this campaign is not malware. It is a self-service portal.

After getting in, the actors registered additional authentication methods under their own control: phone numbers for SMS or voice, authenticator apps tagged SoftwareTokenActivated, and software OTP tokens. Microsoft published the artifact detail from one registration, and it is worth staring at: device name NO_DEVICE, device token NO_DEVICE_TOKEN, AuthenticationType: 2, HashFunction: hmacsha1.

That combination is a software OTP seed bound to no device at all, and it matters for anyone writing detections. Microsoft's first recommended hunting query looks for newly registered authentication devices with a populated device token, comparing OldValue and NewValue counts in StrongAuthenticationPhoneAppDetail. The string NO_DEVICE_TOKEN is populated. It is also, semantically, the absence of a device. A naive "is this field non-empty" check passes it straight through. If you built your MFA-enrollment rule that way, go look at it today.

There is a bleaker point underneath. A rogue MFA method survives a password reset, and it survives the passkey registration you eventually walk that user through. The credential you rotate and the factor the attacker owns are different objects. That is the same eviction gap I wrote about when Gyazo reset 23.6 million passwords without touching the session IDs.

Graph has a schema, and they read it

Once inside, reconnaissance runs through Microsoft Graph, and the enumeration is methodical enough to look like a compliance scanner. Microsoft groups it into categories: tenant profile via /organization and /subscribedSkus, directory walking via /users, /groups, /transitiveMembers, privilege discovery via /directoryRoles, /roleManagement and /authentication/methods, application discovery via /servicePrincipals and /oauth2PermissionGrants, then repository and mailbox mapping via /sites, /drives, /messages and /attachments. Result sets get paged with $top, $skip, $skiptoken, /delta and /search.

In one AiTM sequence, the actor enumerated My Sign-Ins, My Apps and Microsoft Approval Management within 50 minutes of the first sign-in. That is an operator who knows exactly which three pages tell them what the victim can reach and what approvals they can forge their way through.

None of this requires an exploit. It is the directory answering questions it is designed to answer, which is precisely what made the TheHatman Entra directory dumps so hard to distinguish from normal administration.

The thresholds are the tradecraft

Now the part that genuinely bothers me, and the reason I think this writeup deserves more attention from detection engineers than it has gotten.

Microsoft shipped ten hunting queries with the report. They are good queries. They are also, nearly all of them, volume thresholds. Broad Graph recon fires at three or more categories with ten or more requests across six or more distinct paths in 30 minutes. Exchange REST exfiltration fires at 500 or more events per hour. Anonymous proxy collection fires at 5GB transferred or 1,000 or more events in a two-hour window.

Then read the collection behavior in the same document. Microsoft notes the actors accessed "fewer than 1,000 files or emails within any one-hour period" specifically to blend with normal usage, with collection stretched across several hours to multiple days.

The pacing and the alarm line are the same number. Whether that is coincidence or the result of an operator reading published guidance, the operational effect is identical: the volume-based detections are calibrated to a rate the adversary has already decided to stay under.

The one query that does catch this activity on volume is the SharePoint and OneDrive rule that fires at 100 or more file access events in two hours from the python-httpx user agent. So the query that works is keyed on a request header. That header is one line of configuration. The day an operator sets headers={"User-Agent": "Microsoft Office/16.0"} on their httpx client, the volume-based safety net goes back to a 1,000-event floor they are already pacing below.

I am not arguing Microsoft published a bad detection. I am arguing that a detection whose sensitivity depends on the attacker not editing a string is a detection with a shelf life, and you should know which of yours are in that category. Go count them. Most SOCs will find the number uncomfortable.

What a decoy does that a threshold cannot

Thresholds ask "is this too much?" That question has a wrong answer available to the attacker. A decoy asks "why did you touch this at all?" That question does not.

A honeytoken credential in a SharePoint document, a fake API key in a OneDrive folder, a decoy user object in the directory with a plausible name and a registered passkey: none of these have a legitimate consumer. Zero employees open them, zero scripts read them, zero backup jobs care. When one is read, there is no volume to evaluate and no baseline to argue about. The signal is binary, which is why our deception-based detection approach produces no false positives to tune away. One file read, one alert, one answer.

Against this specific chain, the placement writes itself. The actors enumerate /sites, /drives and /messages before they collect, and they page through results systematically. An automated enumerator that walks every result set will hit a decoy document early, usually before the thousandth real file. The one behavior this campaign cannot pace itself out of is completeness: they need broad discovery to find what is worth stealing, and broad discovery is exactly what trips a planted object. A mailbox seeded with a decoy credential in a message body catches the REST API collection stage regardless of how slowly it runs.

Three things I would do this week, in order. Block device code and authentication transfer flows in conditional access, with a named exception list you are willing to defend in writing. Alert on every single MFA method registration in the tenant, treating it as an event that requires a human to confirm, and fix any rule that tests a device token for non-emptiness rather than for meaning. Then give your help desk a verified callback procedure for passkey and MFA resets, because for the next sixteen months every attacker on earth has a true story to tell your users about why their authentication needs to change.

The passkey migration is worth finishing. Just do not assume the attackers are waiting for it to finish before they use it. If you want to see what a decoy identity looks like when it catches an enumeration pass through your tenant, book a walkthrough with our team and bring your own Graph logs.