Passkey helpdesk vishing stole Entra M365 sessions

A helpdesk voice on a personal phone and a passkey-update story were enough to walk workforce Entra users through a full Microsoft sign-in the attackers never owned. According to the Microsoft Security Blog on 9 September 2026, Microsoft Security Research has tracked a multi-tenant campaign since May 2026 in which callers posing as IT helpdesk create urgency around passkey, MFA, or SSO updates, then coach employees onto adversary-in-the-middle phishing pages or device-code flows. Victims complete standard Entra MFA. Attackers leave with credentials, replayable session or OAuth tokens, and later their own enrolled MFA methods on the victim identity.

Public reporting does not name a single victim organization, a threat-actor brand, or exact record counts. The pattern is still clear: workforce Microsoft Entra and Microsoft 365 identities, not consumer apps, and a live coach who never needed to crack cryptography.

How a personal-phone helpdesk call steered the login

The opening move was voice trust, not a clever zero-day. Callers contacted employees on personal phones and framed the conversation as routine IT work: passkey rollout, MFA refresh, SSO repair. Urgency did the rest. The employee was told to open a link or follow a short approval path while the caller stayed on the line.

Lookalike domains carried the theme. Microsoft cites examples in the style of companyname.add-passkey.com, passkeyhelpdesk.com, and integratedsso.com. An adversary-in-the-middle attack is a reverse proxy that sits between the user and the real identity provider, showing a convincing login while copying whatever the user types and whatever the real site returns. On those paths, the proxy harvested the password and the live MFA completion in the same ceremony.

Microsoft is explicit about the lure: "Despite the frequent use of passkey-themed lures, passkey enrollment is often not the actor's true objective." Successful paths typically used standard Entra methods such as push or OTP, not phishing-resistant passkeys. The passkey story was cover. The transferable factor was the real prize.

The same helpdesk script also drove device-code style flows. In that pattern the user is coached to enter a code or approve access on a legitimate Microsoft authentication page while an attacker-controlled client waits for the grant. Microsoft states the split cleanly: "In AiTM scenarios, the actor captures credentials and session tokens; in device code attacks, the victim unknowingly authorizes access on the actor's behalf." Either way, authentication is incomplete until a token is issued. The employee finishes the proof. The attacker receives the session.

Delivery on a personal phone mattered for defenders too. Microsoft notes that if the victim opens the phishing link on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, related activity may be absent from endpoint telemetry. The identity plane still lights up. The laptop may not.

This is the same industrial social-engineering class as other helpdesk recovery plays: a live coach walks a transferable factor across a path the attacker controls. It is not a separate MFA universe from a spoofed login page. Spring Ring's Teams helpdesk vishing pushed RMM and malware without stealing codes at login. This campaign stayed on the identity ceremony itself and took the cloud session directly.

What AiTM proxies and device-code approvals actually captured

Once MFA succeeded on the proxied path, the kit held full post-MFA session cookies and tokens. Device-code paths issued OAuth or device-code tokens straight to the attacker client. Those tokens were replayed from proxy infrastructure against My Apps, SharePoint, Outlook, and related Microsoft 365 surfaces.

One documented sequence shows the mechanics without romance. An OfficeHome sign-in from an unmanaged device hit error 50074 (MFA required). MFA completed through the AiTM path. The resulting session was then used against My Apps, My Sign-Ins, SharePoint, Outlook, and other apps. MFA finished. The session did not stay glued to the victim's browser.

That is not "MFA failing after the fact" in a mystical sense. It is a credential-phase win for the attacker followed by ordinary token replay. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem. Here the remote kit never needed malware on a corporate PC to mint the first useful cloud session.

SSO multiplies the damage. One Entra-backed session is a skeleton key across mail, files, chat, and admin-adjacent self-service portals that trust the same cloud identity. Public reporting does not establish a single-tenant blast radius or a ransom narrative. It does establish high-volume Microsoft Graph reconnaissance and bulk access to SharePoint, OneDrive, and email once the session existed. Authorization failures were not the primary theme. Access rode stolen cloud identity sessions with the victim's effective permissions.

Compare that to the BigBear 2.0 Evilginx2 PhaaS wave: different branding, same industrial shape of proxied Microsoft logins and replayable cookies after non-phishing-resistant MFA completes.

Attacker-enrolled MFA and what the session unlocked next

With an authenticated session, actors registered new MFA methods on the victim identity: a phone number, an authenticator app, or a software OTP labeled in patterns such as NO_DEVICE. Later sign-ins could use a previously attacker-registered PhoneAppOTP-style method with credentials the campaign already held. Persistence stopped being "hope the stolen cookie still works" and became "we are a legitimate factor on this account."

From there the work looked like ordinary cloud abuse at scale. Compromised sessions drove Microsoft Graph enumeration of users, groups, apps, and sites, plus bulk collection from SharePoint, OneDrive, and email. Public reporting does not establish how many mailboxes or files left each tenant. It does establish that identity compromise, not a novel authorization bug, carried the access.

Infrastructure rotated. Domains and IPs moved quickly. Microsoft describes the victim scope as ongoing and incomplete in public material. Defenders chasing a fixed IOC list will lag the voice call that starts the next chain.

The honest split for anyone reading sign-in logs tonight is simple. Credential and enrollment phases are where transferable MFA and weak step-up on security-info changes lose. Token replay and Graph collection after a good session are post-authentication problems. No login product un-steals a cookie already copied off a proxy. Prevention still matters most upstream, because the kit only held that cookie after a phishable ceremony succeeded.

If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how phishing-proof MFA and protected enrollment blunt passkey-themed helpdesk AiTM and device-code paths.

FAQ

Did this campaign defeat passkeys on Microsoft Entra?

No. Public reporting on the Microsoft passkey-themed social engineering campaign does not show phishing-resistant passkeys failing on the successful paths. According to Microsoft Security Research, passkey-themed lures were often a pretext, and successful paths typically used standard Entra MFA such as push or OTP rather than passkeys.

How did helpdesk vishing and AiTM work together in this campaign?

In the Microsoft-disclosed campaign, callers posing as IT helpdesk contacted employees on personal phones, created urgency around passkey, MFA, or SSO updates, and directed victims to lookalike domains that reverse-proxied Microsoft login or steered device-code approval. The voice call supplied trust and coaching. The AiTM page or device-code client collected the credential ceremony and the resulting token.

Once MFA succeeded, why did attackers still get into SharePoint and mail?

After MFA succeeded on the proxied or device-code path in this campaign, attackers held post-authentication session cookies or OAuth tokens and replayed them from their infrastructure. Microsoft describes token replay enabling enumeration and further progression. MFA completion does not bind that session exclusively to the victim's device, so cloud apps that trust the Entra session accepted the replay.

How did attackers stay in accounts after the first stolen session?

According to Microsoft's disclosure of this campaign, actors used the authenticated session to register new MFA methods on the victim identity, including phone numbers, authenticator apps, or software OTP methods such as NO_DEVICE. Later access could use those attacker-enrolled factors with previously compromised credentials, which is persistence on the identity, not only cookie lifetime.

Why might endpoint tools have missed the initial lure?

Microsoft states that if the victim opened the phishing link on a personal mobile device not onboarded to Microsoft Defender for Endpoint, related activity may be absent from endpoint telemetry. The Microsoft passkey-themed campaign often started on personal phones, so identity and cloud signals matter more than waiting for a managed-PC alert that never fires.