A single coached Microsoft sign-in is enough to hand attackers a cloud session that Graph can drain for days. In the Microsoft 365 passkey-themed phishing campaign first observed in May 2026, operators posing as corporate IT steered employees from personal-phone vishing or SMS into adversary-in-the-middle reverse proxies or device-code flows. Victims finished real Microsoft authentication including MFA. Attackers left with replayable session cookies and OAuth tokens, enrolled their own authenticators, and slowly pulled SharePoint, OneDrive, and Exchange content. Closing those phishable login and enrollment surfaces stops this path. Malware after a legitimate login is a harder, separate problem.
What the passkey-themed M365 campaign actually did
According to BleepingComputer, Microsoft described operators who researched employees and org structure from public social and professional sources, then registered passkey- and SSO-themed domains. Contact hit personal phones. Voice and text claimed an urgent passkey, MFA, or SSO update. The lure did not enroll real passkeys. It funneled people into attacker-controlled authentication paths.
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. Device-code phishing nudges the victim to type an attacker-supplied code on a legitimate Microsoft page, finish ordinary MFA, and cause Microsoft to issue access and refresh tokens to an attacker-controlled OAuth client. No second challenge follows.
With sessions in hand, attackers registered their own phone numbers, authenticator apps, and software OTP methods. They used Microsoft Graph to enumerate users, groups, apps, and roles, reached My Apps and connected SSO applications, and paced exfiltration under roughly 1,000 files or emails per hour so the pull blended with normal traffic. In one observed intrusion the malicious session stayed active about an hour while listing sensitive files and internal applications. Public reporting does not name individual victim organizations or publish total record counts. Microsoft’s coverage ties the wave to extortion-linked clusters that include names associated with ShinyHunters-linked activity, Storm-3121, Helix, Storm-3032, BlackFile, Falcon, UNC6671, Pink, and Redact. Google Threat Intelligence had already documented UNC6671 passkey-themed corporate identity compromises with similar phone-based social engineering. Public reporting does not establish a single sole operator for every intrusion.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how passkey-themed helpdesk vishing stole Microsoft 365 cloud sessions.
Why push and OTP still finished the attacker login
Credential phase, helpdesk coaching. The transferable secret was whatever the employee typed or approved while a fake IT persona walked them through an “update.” Standard push, TOTP, and SMS-style MFA still succeeded because those factors prove someone can answer a prompt, not that the ceremony runs only on a trusted origin and an already-enrolled device the employee controls. The helpdesk call and the coached fake login are the same social-engineering class: live coaching of a transferable factor.
Credential phase, AiTM and device-code. On the reverse-proxy path, password plus live MFA completion became the attacker’s session cookie. On the device-code path, the victim’s legitimate MFA caused tokens to issue to the attacker’s OAuth client. Authentication succeeded for a party the defender never intended to authorize. That is still a login-path failure, not mysterious post-auth magic.
Persistence, attacker MFA enrollment. From the hijacked mailbox or tenant foothold, operators added phone numbers, authenticator apps, and software OTP methods they controlled. After that, cookie lifetime limits matter less. The directory treats the new factor as legitimate until humans remove it. Open enrollment from a stolen session is still a credential-lifecycle failure.
Token phase, Graph and file access. Stolen session cookies and OAuth tokens were replayed against Microsoft Graph and content APIs with no fresh MFA. No login control undoes a token already in attacker hands. Containment is revoke, credential reset, strip attacker methods, and hunt the quiet enumeration window.
| Phase | What was abused | Login MFA outcome |
|---|---|---|
| Helpdesk vishing / SMS | Coached live sign-in | Push/TOTP/SMS completed for attacker path |
| AiTM reverse proxy | Password + MFA relay | Session cookie captured post-MFA |
| Device-code flow | Code on real Microsoft page | OAuth tokens to attacker client |
| MFA method add | New phone / app / OTP | Persistence without phishing-proof step-up |
| Graph / SharePoint drain | Replay of issued tokens | No further MFA; revoke is hygiene |
SSO widened the blast radius. One Microsoft 365 cloud session and the My Apps surface open mail, files, and federated business apps without a fresh proof at each boundary. Classic SSO auto-sign-on fails never-trust, always-verify the moment one replayable token becomes a skeleton key.
Microsoft’s own guidance in the coverage points at phishing-resistant MFA, disabling unused device-code flow, managed-device Conditional Access, and on compromise revoking sessions and tokens, resetting credentials, and re-registering auth methods. That list already separates prevention at login from cleanup after theft.
What device-bound phishing-proof authentication changes
MFA 2.0 is phishing-proof across the identity lifecycle, not merely harder at one prompt. Device-bound credentials use public-key cryptography. The private key stays in hardware. The server stores only public keys. Each authentication is a fresh, origin-bound signature. There is no OTP to read aloud, no push to approve under coaching, and no SMS code to relay through a proxy.
Against the AiTM path, the private key never transits the network and the signature is bound to the real origin. A reverse-proxy page is the wrong origin. The kit cannot complete a usable login ceremony the way it completes password-plus-OTP. Against device-code style handoffs that depend on the user finishing a transferable MFA for an attacker client, removing relayable factors and disabling unused device-code issuance collapses the alternate token mint. Against helpdesk pretexts about “passkey updates,” there is no temporary secret for IT to dictate and no enrollment code the voice on the phone can harvest.
That is prevention. The attacker never obtains the session cookie or OAuth grant through those kits. Fooling a user into a proxied login is easy. Planting malware on a machine that already holds a legitimate session is not.
Honest residual boundary: once cookies or refresh tokens already sit with the attacker, no MFA design un-issues them. Revoke sessions and refresh tokens, reset credentials, remove attacker-enrolled methods, and review Graph and file-access logs. Shortening token lifetime alone does not stop the original coached login, and it does not help after the attacker has registered a lasting factor. Detection and revoke remain hygiene for that leftover state and for true endpoint malware after a clean sign-in.
When cloud SSO multiplies one stolen session across apps, prefer Secure Explicit Sign-On over bolting more alerts onto classic federation. SES keeps one-tap user experience but authenticates each application with its own fresh, device-bound signature. No shared, reusable federation cookie exists to replay as a skeleton key across mail, files, and connected business apps.
| Control | Against coached AiTM / device-code login | Against later token replay |
|---|---|---|
| Push / TOTP / SMS | Completes for attacker path | N/A once session exists |
| Passkeys at login only | Strong if origin-bound and enforced | Does not un-issue stolen tokens |
| Phishing-proof full lifecycle | No transferable factor to coach or relay | Still needs revoke if token already stolen |
| SES (no shared SSO cookie) | Limits multi-app replay design | Shrinks blast radius of any single proof |
Passkeys and FIDO2 for this vector
FIDO2 and passkeys put a key pair on the device. The private key never leaves hardware. The authenticator produces an origin-bound signature for the real relying party. Industry language correctly calls that phishing-resistant at the login act: a look-alike domain does not get a usable assertion the way a typed OTP does. On a generic enterprise IdP that issues only hardware-bound signatures, the employee taps an already-enrolled device and the IdP verifies a public-key challenge. No shared secret crosses the wire for a reverse proxy to steal. That hardens the ceremony these operators tried to coach. It is still the login stage only unless enrollment and recovery are locked the same way.
Why enrollment still decides whether a hijacked session sticks
Passkeys alone do not guarantee phishing-proof coverage if a phishable factor can still register a new device or method. In this campaign, persistence came from attackers adding phones, authenticator apps, and software OTP from a session born of coached login. If enrollment accepts a hijacked session plus a weak step-up, the attacker plants a factor the directory trusts. Full-lifecycle phishing-proof design requires already-enrolled hardware for new-device onboarding and governed recovery with no TAP-style secret, SMS code, or helpdesk-readable OTP. That is the gap between phishing-resistant login and phishing-proof identity. The enrolment model that refuses phishable recovery is what stops a stolen session from quietly becoming permanent control.
Key Takeaways for Defenders
- Enforce device-bound, origin-bound authentication on Microsoft 365 and workforce SSO so reverse-proxy kits cannot complete a relayable MFA ceremony.
- Disable unused device-code flow and require managed-device Conditional Access where policy allows, matching Microsoft’s published guidance for this wave.
- Lock MFA method registration: new phones, apps, and OTP seeds need phishing-proof step-up from an already-enrolled device, not a hijacked mailbox session.
- Treat helpdesk and personal-phone “passkey update” calls as the same class as coached fake login; remove any secret IT can dictate or the user can type for the wrong party.
- On suspected compromise, revoke sessions and refresh tokens, reset credentials, strip attacker-enrolled methods, and hunt slow Graph and SharePoint download patterns under about 1,000 objects per hour.
The operators sold urgency around passkeys while relying on factors passkeys were meant to retire. Build authentication so the coaching call has nothing transferable to collect, and the later Graph hose never starts.
FAQ
Would phishing-proof MFA have stopped the Microsoft 365 passkey-themed campaign?
Phishing-proof device-bound MFA would have blocked the credential-phase paths in the Microsoft 365 passkey-themed phishing campaign: AiTM reverse-proxy completion of live MFA, device-code token issuance to an attacker OAuth client, and helpdesk-coached transferable factors. It would also harden enrollment so a hijacked session cannot quietly plant attacker phones or OTP apps. It would not un-issue session cookies or OAuth tokens already stolen; those still need revoke and method cleanup.
Why is disabling device-code flow part of preventing this Microsoft 365 attack?
Disabling unused device-code flow is part of preventing this Microsoft 365 attack because victims who entered an attacker-supplied code on a legitimate Microsoft page caused access and refresh tokens to issue to an attacker-controlled OAuth client after ordinary MFA, with no further challenge. Removing that issuance path closes a token mint that does not require a reverse-proxy kit.
How is MFA 2.0 different from passkeys alone for this breach?
For this Microsoft 365 passkey-themed breach, passkeys and FIDO2 are phishing-resistant at login when origin-bound signatures are enforced, which already breaks classic AiTM OTP relay. MFA 2.0 is phishing-proof across registration, device onboarding, authentication, and decommissioning, so helpdesk-style recovery and post-access MFA method adds cannot reintroduce SMS, email codes, or other transferable enrollment secrets.
Why does MFA 2.0 avoid classic SSO for Microsoft 365-style estates?
MFA 2.0 avoids classic SSO for Microsoft 365-style estates because one stolen session or federation token unlocks mail, files, and connected apps without a fresh proof at each boundary, which is exactly how Graph and My Apps access expanded after these intrusions. Secure Explicit Sign-On keeps one-tap UX while each application gets its own fresh device-bound signature, so no shared replayable cookie acts as a skeleton key.
What should responders do if tokens were already stolen in a passkey-themed M365 intrusion?
If tokens were already stolen in a passkey-themed Microsoft 365 intrusion, responders should revoke sessions and refresh tokens, reset credentials, remove attacker-enrolled phone and authenticator methods, review Graph enumeration and FileAccessed or FileDownloaded spikes paced under roughly 1,000 objects per hour, and then eliminate the phishable login and open-enrollment paths that minted the session.
