A fake IT helpdesk call on a personal phone was enough to turn a normal Microsoft 365 login into an attacker-owned cloud session. In the Microsoft 365 passkey-themed phishing campaign first observed in May 2026, operators impersonating corporate IT used urgent passkey, MFA, or SSO update pretexts, then steered employees into adversary-in-the-middle reverse proxies or device-code flows. Victims completed real Microsoft authentication including MFA. The attackers walked away with replayable session cookies and OAuth tokens, enrolled their own MFA methods, and slowly pulled SharePoint, OneDrive, and Exchange data. According to BleepingComputer, Microsoft linked the activity to multiple extortion-linked clusters. Public reporting does not name individual victim organizations or publish total record counts.
How fake IT calls turned passkey urgency into live logins
Operators spent real effort before the first ring. According to Microsoft reporting carried by BleepingComputer, the actor invested heavily in pre-attack research, gathering employee and org-structure detail from public social and professional sources, then registered passkey- and SSO-themed domains that looked like configuration work, not theft.
Contact landed on personal phones. Voice calls and SMS messages claimed an urgent need to update a passkey, finish an MFA change, or complete an SSO fix. That framing mattered. Staff already hear about passkeys as the safer next step, so a helpdesk persona pushing a "required update" sounded like hygiene, not a break-in.
The lure did not enroll real passkeys. Public reporting is clear on that point: passkey language was bait. Victims were pointed at attacker-controlled Microsoft authentication paths instead. Two paths dominated.
An adversary-in-the-middle attack is a reverse-proxy login page that sits between the user and the real identity provider, relays every field and every MFA completion live, then keeps the authenticated session for the attacker. Device-code phishing is different in shape but not in outcome. The victim types an attacker-supplied code on a legitimate Microsoft sign-in page, finishes ordinary MFA, and Microsoft issues access and refresh tokens to an attacker-controlled OAuth client. No second challenge follows.
Either path is coached live authentication. The helpdesk voice on the personal phone and the fake update page are the same social-engineering class: someone talks a transferable factor through to completion for the wrong party. Standard push, TOTP, and SMS-style MFA still succeeded for the attacker-controlled path because those factors are designed to prove "someone who can answer this prompt," not "this exact origin and this exact device."
Google Threat Intelligence had already documented UNC6671 using phone-based social engineering and passkey-themed phishing against corporate identities. Microsoft's coverage ties overlapping activity into the same extortion ecosystem, with names that include ShinyHunters-linked clusters, Storm-3121, Helix, Storm-3032, BlackFile, Falcon, UNC6671, Pink, and Redact. Public reporting does not establish a single sole operator for every intrusion in the wave.
What the proxies and device-code flows actually handed over
Once the victim finished Microsoft sign-in, the useful prize was not the password alone. AiTM kits captured post-MFA session cookies and tokens. Device-code flows issued OAuth tokens straight to the attacker client after the victim's legitimate MFA. In both cases authentication had already succeeded for a session the defender never intended to share.
| Control in play | What happened here | Why it failed |
|---|---|---|
| Push / TOTP / SMS MFA | Victim completed live MFA | Factor was relayable or completed for attacker client |
| Passkey-themed helpdesk pretext | Personal-phone vishing or SMS | Urgency moved users onto attacker paths |
| Device-code flow (when enabled) | Code entered on real Microsoft page | Tokens issued to attacker OAuth client |
| Session / OAuth token acceptance | Cookies and tokens replayed | No fresh MFA on Graph and file access |
Microsoft observed that in one intrusion the malicious session stayed active about one hour while the operator listed sensitive files and internal applications. That is not a noisy smash-and-grab. It is quiet inventory under a session that already looked authenticated.
SSO made the blast radius worse. A single Microsoft 365 cloud session and the connected My Apps surface open mail, files, chat-adjacent workloads, and federated business apps without a fresh login at each boundary. Classic SSO auto-sign-on fails a never-trust, always-verify design the moment one replayable token becomes a skeleton key across the estate.
Persistence came next, still in the identity plane. With mailbox or tenant access in hand, attackers registered their own phone numbers, authenticator apps, and software OTP methods on the compromised accounts. After that, lifetime limits on the original stolen cookie matter less. The attacker holds a factor the directory treats as legitimate until someone removes it.
That enrollment step is still a credential-phase failure, not magic. The session that planted the new methods was born from a coached login. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Graph recon and the slow SharePoint drain
With tokens in hand, operators used Microsoft Graph to enumerate users, groups, applications, and roles, then moved into content. According to Microsoft via BleepingComputer, observers saw high-volume access and download activity against SharePoint Online and OneDrive for Business, with some intrusions extending into Exchange Online through REST API access to email. Across SharePoint and OneDrive the activity produced significant FileAccessed and FileDownloaded volumes, the signature of systematic cloud document retrieval rather than a single mailbox glance.
Exfiltration was paced on purpose. Public reporting describes automated theft held under roughly 1,000 files or emails per hour so the pull blended with ordinary traffic and ran for hours to days. Defenders hunting only for sudden multi-gigabyte spikes can miss a slow hose.
At this stage the stolen object is a token, not a typed secret. No MFA design undoes an already-issued session cookie or OAuth token sitting in attacker hands. Containment is revoke sessions and refresh tokens, reset credentials, strip attacker-enrolled auth methods, and review Graph and file-access logs for the quiet enumeration window. Shortening token lifetime alone does not prevent the original coached login, and it does not help once the attacker has registered a lasting factor.
The same industrial pattern showed up in adjacent coverage of UNC6671 passkey-themed corporate identity compromises and BlackFile-linked extortion reporting. Those are related actor-cluster stories, not proof that every Microsoft 365 victim in this wave is a named hedge-fund case. Public reporting does not establish victim counts, ransom figures, or a single published list of corporate names for this campaign.
What failed in plain terms is transferable MFA under live coaching, plus optional device-code issuance, plus open enrollment of new factors from a hijacked session. Push and OTP did their job for whoever completed the prompt. The directory then trusted the resulting session across SSO-connected apps until humans tore it down.
A fix for the coached-login and enrollment surfaces exists. It is not "train users harder" as the primary control. If you want to skip the rest of the attack detail and go straight to what can stop this class of helpdesk vishing, AiTM relay, and device-code token handoff, read the related article on mfa2point0.com: how phishing-proof MFA closes passkey-themed Microsoft 365 coaching paths.
FAQ
How did attackers get into Microsoft 365 in this passkey-themed campaign?
Attackers got into Microsoft 365 by impersonating corporate IT on personal phones with urgent passkey, MFA, or SSO update pretexts, then steering employees into AiTM reverse-proxy pages or device-code flows. Victims completed real Microsoft login including MFA, which handed the attackers session cookies or OAuth tokens. Public reporting does not name specific victim companies or total record counts.
Did passkeys actually get enrolled during these Microsoft 365 attacks?
No. In the Microsoft 365 passkey-themed phishing campaign, passkey language was a lure, not a successful enrollment step. According to Microsoft reporting via BleepingComputer, victims were funneled into AiTM phishing sites or device-code authentication instead of registering genuine passkeys for their accounts.
Why did MFA still succeed for the attackers after the helpdesk call?
MFA still succeeded for the attackers because victims completed push, TOTP, or SMS-style challenges on paths the attackers controlled: a reverse-proxy AiTM page that relayed the live response, or a legitimate Microsoft device-code page that issued tokens to an attacker OAuth client. The factor proved someone could answer the prompt, not that the session belonged only to the employee on a trusted device and origin.
What did the attackers do after they had Microsoft 365 sessions?
After they had Microsoft 365 sessions, attackers registered their own phone numbers, authenticator apps, and software OTP methods for persistence, used Microsoft Graph to enumerate users, groups, apps, and roles, accessed My Apps and connected SSO applications, and slowly exfiltrated SharePoint, OneDrive, and sometimes Exchange content at under about 1,000 files or emails per hour. In one observed case a malicious session stayed active about an hour while listing sensitive files and internal apps.
Does revoking tokens fix the root problem in this campaign?
Revoking tokens is required hygiene after compromise in the Microsoft 365 passkey-themed phishing campaign, along with credential resets and removal of attacker-enrolled MFA methods, but it does not fix the root problem. The root problem was coached live login and token issuance through AiTM and device-code paths. Closing those phishable login and enrollment surfaces stops the session from being minted for the attacker in the first place.
