A coached Microsoft sign-in finished on a lookalike domain while the real helpdesk never placed the call. 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 create urgency around passkey, MFA, or SSO updates, then walk workforce Entra users through adversary-in-the-middle pages or device-code approvals. Victims complete standard push or OTP. Attackers leave with credentials, replayable cloud sessions, and later their own enrolled MFA methods. Public reporting does not name a single victim organization or exact record counts. Prevention still has a clear job: remove transferable factors at login and at security-info change so the kit never mints the first useful token.
Why live helpdesk coaching still completed Entra MFA
Microsoft describes callers contacting employees on personal phones, framing the work as passkey rollout, MFA refresh, or SSO repair, and staying on the line while the victim opens a link or completes an approval. Lookalike domains carried the theme, including patterns such as companyname.add-passkey.com, passkeyhelpdesk.com, and integratedsso.com. An adversary-in-the-middle attack is a reverse proxy between the user and the real identity provider that shows a convincing login while copying secrets and the authenticated session the real site returns.
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 same script also drove device-code style flows, where the employee approves access on a legitimate Microsoft auth page while an attacker-controlled client receives 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."
On those credential paths, authentication was still in the future. The helpdesk voice supplied trust. The employee typed a password and completed a transferable second factor on a path the attacker directed. That is the same industrial social-engineering class as other coached identity plays: a live coach walks a factor the attacker can spend. Origin did not stop relay of push or OTP. Device-code coaching finished a legitimate consent UX for someone else's client. Microsoft notes that authentication remains incomplete until token issuance. The employee finished the proof. The attacker received the session.
One documented sequence shows the shape 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 used against My Apps, My Sign-Ins, SharePoint, Outlook, and other apps. MFA finished. The session did not stay glued only to the victim's browser.
| Path | What was taken | Why transferable MFA lost |
|---|---|---|
| Helpdesk lure | Trust and coaching | Voice beat policy text |
| AiTM login | Password, live MFA, session | Push or OTP relay on wrong origin |
| Device-code | OAuth or device-code grant | User authorized attacker client |
| Persistence | New phone, app, or OTP methods | Security-info change from stolen session |
| Data access | Graph, mail, files | Replay of already-minted tokens |
Persistence was still a credential-lifecycle failure. With an authenticated session, actors enrolled phone numbers, authenticator apps, or 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. That is weak step-up on security-info changes after a phishable login succeeded.
Token replay and bulk Graph collection sit after authentication. No login product un-steals a cookie already copied off a proxy. 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 self-service portals that trust the same cloud identity. Classic SSO auto-login fails the never-trust, always-verify idea of zero trust when a single replayable federation cookie opens every integrated app. Public reporting does not establish a single-tenant blast radius or a ransom narrative. It does establish identity compromise, not a novel authorization bug, as the carrier of access. Personal-phone delivery often left little endpoint telemetry when devices were not onboarded to Microsoft Defender for Endpoint.
For the full attack-chain narrative, read the related post on legacymfa.sucks: how helpdesk vishing stole Entra and M365 sessions.
How phishing-proof MFA 2.0 closes the coached login
Phishing-proof, device-bound MFA 2.0 removes the transferable factors the coach was selling. There is no password, OTP, SMS code, email code, or push approval to read out, type on a lookalike, or approve under pressure for someone else's client. Signatures are origin-bound and the private key never leaves the enrolled hardware. There is no central password or credential database to steal, and same-device proof means a second phone or USB key is not required for the ceremony. A reverse proxy that is the wrong origin cannot complete a usable login. A device-code style nudge has no weak factor left to coach across the phone.
That is prevention at the credential phases, not detection after the fact. The prevention-focused architecture matters here because revoke, short lifetimes, and anomaly tools only start after a session already exists. Microsoft 365 session settings can last on the order of many days depending on configuration. Shortening lifetime does not stop the first harvest. It only forces the attacker to re-use or re-steal sooner. If the attacker registers their own authenticator during the window of access, lifetime limits stop mattering. They now hold a legitimate factor.
Protected enrollment is the second half of the same story. Adding a phone, app, or software OTP must require proof from an already-enrolled device, not a recoverable secret a helpdesk can recite or a stolen session can satisfy alone. Pending-method alerts and admin policy on security-info changes block the NO_DEVICE-style persistence Microsoft described. Without that lifecycle lock, even a strong login factor can be diluted after the first stolen session.
Honest residual boundary: once a legitimate session cookie or OAuth token already sits in attacker hands, no MFA product reverses that copy. Defense then shifts to token binding, continuous access evaluation, rapid revoke, and detection. Fooling a user into a proxied or coached login is easy relative to planting malware on a machine that already holds a good session. For this campaign the primary win is still upstream. Stop the kit from completing the login so the token is never issued to the proxy or the attacker client.
When cloud SSO is in play, prefer per-app, device-bound proof over one shared federation cookie. Secure Explicit Sign-On keeps the one-tap user experience while each application receives its own fresh, hardware-bound signature. No single replayable SSO token becomes a skeleton key across SharePoint, mail, and Graph. That architectural choice shrinks blast radius even when some residual endpoint compromise still occurs later.
| Control | Coached AiTM or device-code login | Attacker MFA enrollment | Post-auth token replay |
|---|---|---|---|
| Push or OTP Entra MFA | Completes under coaching | Often allows new methods | Does not bind session to victim client |
| Passkeys at login only | Strong if truly required | Gap if recovery is phishable | Does not un-steal cookies |
| Phishing-proof full lifecycle | No transferable factor to coach | Enrollment needs enrolled device | Residual; use binding and CAE |
| Classic SSO session | One proof, many apps | Persistence multiplies reach | Skeleton-key replay |
| Secure Explicit Sign-On | Fresh per-app signatures | Same device-bound bar | No shared cookie to replay |
Related industrial shape, different branding: the BigBear 2.0 AiTM wave also showed proxied Entra logins and cookie harvest after non-phishing-resistant MFA. Spring Ring's Teams helpdesk vishing pushed remote control without stealing login codes. This campaign stayed on the identity ceremony and took the cloud session directly.
Why login-only passkeys leave the NO_DEVICE gap
Passkeys and FIDO2 put a key pair on the user device. The private key stays in hardware. The IdP stores only a public key and checks an origin-bound signature at login. Industry language correctly calls that phishing-resistant for the authentication act: there is no reusable OTP to type into a proxy. On a generic enterprise IdP that demands those hardware-bound signatures for every interactive sign-in, a passkey-themed lookalike cannot complete the same relay that worked against push and OTP in this campaign. That hardens login. It is not yet full-lifecycle coverage by itself.
FIDO2 and passkeys are phishing-resistant at login only. If email OTP, SMS, push, or a stolen session can still enroll a new phone or software token, an attacker who holds that path registers a factor that later looks legitimate. Microsoft's disclosure shows exactly that pattern after the first authenticated session: new methods on the victim identity, then later PhoneAppOTP-style sign-ins. Phishing-proof coverage means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning. The enrolment model has to demand an already-enrolled device before security info changes, or the persistence phase in this campaign simply moves downstream of a stronger login.
Key Takeaways for Defenders
- Require phishing-resistant or phishing-proof authenticators for interactive Entra sign-ins so push and OTP cannot finish on AiTM or coached device-code paths.
- Treat helpdesk calls that demand live codes, approvals, or "passkey update" links as identity incidents, not routine IT tickets.
- Gate MFA method registration behind step-up from an already-enrolled device and alert on pending security-info changes.
- Prefer per-app device-bound sign-on over one long-lived SSO cookie across mail, files, and Graph.
- Keep CAE, token binding, and rapid revoke as hygiene for residual post-auth replay; do not confuse them with stopping the first harvest.
The forward-looking bar is simple. If a stranger on a personal phone can still walk an employee through a transferable factor or a weak enrollment change, the identity system is still coaching-complete. Hardware-bound proof with locked lifecycle stages ends that conversation before a token is ever issued.
FAQ
Would phishing-proof MFA have stopped this Microsoft helpdesk campaign at login?
Yes for the credential phases of the Microsoft passkey-themed social engineering campaign. Callers coached employees into AiTM pages or device-code approvals that collected passwords plus standard Entra push or OTP and then issued session or OAuth tokens. Device-bound, origin-bound authentication has no transferable factor to coach and will not complete on a wrong-origin proxy, so the kit never obtains that first cloud session. Token replay after a session already exists remains a separate residual problem.
What separates phishing-resistant passkeys from phishing-proof MFA on this vector?
Phishing-resistant passkeys harden the Microsoft Entra login act with origin-bound signatures and no reusable OTP to relay. Public reporting on this campaign does not show those passkeys failing on the successful paths; standard push and OTP did. Phishing-proof MFA 2.0 goes further across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor, which is what closes the attacker-enrolled MFA gap after the first stolen session.
How do you stop attacker-enrolled MFA methods like NO_DEVICE after a stolen session?
In the Microsoft-disclosed campaign, actors used authenticated sessions to register new phone, authenticator, or software OTP methods on victim identities. Stopping that persistence requires protected enrollment: security-info changes must demand proof from an already-enrolled device, with pending-method alerts and admin policy. Login-only passkeys without that lifecycle lock leave the enrollment gap open.
Why does MFA 2.0 avoid classic SSO for breaches like this?
Classic SSO issues one session that many Microsoft 365 apps trust, so a single stolen Entra cookie became a skeleton key across My Apps, SharePoint, Outlook, and Graph in this campaign. MFA 2.0 uses Secure Explicit Sign-On instead: the user still gets simple one-tap access, but each application receives its own fresh, device-bound signature with no shared replayable federation cookie to steal across the estate.
If tokens were already stolen, what still helps?
After MFA succeeded on proxied or device-code paths in this campaign, attackers replayed session and OAuth tokens from their infrastructure. No MFA product reverses that copy. Token binding, continuous access evaluation, short practical lifetimes as hygiene, rapid revoke, and anomaly detection matter then. Those controls do not replace closing the phishable login that minted the tokens in the first place.
