A single spoken SMS code during Microsoft 365 self-service password reset handed an unnamed enterprise to an attacker who never needed a fake login page or malware. According to Sophos X-Ops on 19 October 2026, a threat actor impersonating help desk convinced an employee to provide the SMS-based MFA verification code during SSPR, completed the password reset from an attacker-controlled IP, registered a new Windows device in Entra ID within minutes, obtained a Primary Refresh Token, and used that session for Graph reconnaissance, mailbox access, about 100,000 SharePoint file downloads, Salesforce sign-in, and export of roughly 2,500 ServiceNow sys_user records. Closing SSPR SMS helpdesk vishing means removing verbally transferable recovery codes before the reset can finish.
What Sophos documented in the SSPR takeover
According to Sophos X-Ops, the affected user later reported that the caller posed as help desk personnel and convinced them to provide the SMS-based MFA verification code needed to complete the reset flow. Sophos stresses that this initial access method did not require a phishing page, malware, or an OAuth consent prompt. The password reset finished from an attacker-controlled IP. Within minutes a new Windows device appeared in Entra ID, a Primary Refresh Token was obtained, and Microsoft Edge authentication ran in a token-backed device context.
From that device-backed session the actor used My Apps, Microsoft Graph reconnaissance, user and shared mailboxes, Teams, and bulk SharePoint collection. Investigators counted approximately 100,000 unique SharePoint files downloaded. SharePoint searches used terms tied to passwords, credentials, VPN, SSH, AWS, SSN, and the organization's identity verification vendor, including misspellings. Over 100 unique mail items were accessed. Federated SAML sign-ins reached Salesforce and ServiceNow on the same PRT-backed Entra session. In the sign-in records reviewed, later ServiceNow access was recorded as SAML 2.0 authentication using a primary refresh token, with MFA listed as "Previously satisfied." ServiceNow produced an export of approximately 2,500 sys_user records. Salesforce access was confirmed; containment included SuspiciousActivity, FreezeUser, and SendEmail. Large-scale Salesforce CRM extraction is not shown in the reviewed evidence. The victim organization is not named.
Sophos also notes an anomalous, geographically unusual SSPR initiation from a different IP the day before the confirmed compromise. Whether that attempt was the same actor is not established. The organization later sent a company-wide vishing warning after other employees reported suspicious calls; the targeted user was already compromised. The actor reviewed that awareness message and deleted it, with cleanup limited to two messages. No inbox rules and no new apps appear in the evidence Sophos reviewed.
Sophos frames the case against a broader SaaS extortion pattern associated with GOLD CRYSTAL (ShinyHunters) style campaigns: vishing and credential work to obtain SSO access, then fan-out into cloud apps. That is adjacent operational context, not named attribution for this intrusion.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how SSPR SMS vishing minted a PRT-backed M365 session.
Why SMS recovery cannot survive a live helpdesk call
The failure started in recovery, not at an ordinary daily login form. Microsoft 365 SSPR accepted an SMS verification code as proof that the caller was entitled to set a new password. SMS OTP is a short string a human can read into a phone. A convincing helpdesk script is enough to move that factor to the attacker in real time while the attacker drives the legitimate reset UI from another network.
That is the same social-engineering class as coaching someone onto a fake login page. In both paths a live coach harvests a transferable factor. Here the prize was the SSPR SMS code rather than a password typed into a proxy. Once the code left the handset, the password became attacker-owned. No reverse-proxy kit and no malware implant were required for that step.
Minutes later the identity plane treated the takeover as ordinary device onboarding. A new Windows device registered in Entra ID. A Primary Refresh Token anchored a persistent device-backed session. Later federated access to ServiceNow and Salesforce did not demand a fresh interactive MFA ceremony. Sign-in records listed MFA as previously satisfied because the upstream Entra session already carried that claim. Classic SSO and SAML federation then amplified one reset into Graph, mail, SharePoint, Salesforce, and ServiceNow without repeating full proof at each app boundary.
| Surface | What failed | Result |
|---|---|---|
| SSPR SMS OTP | Code spoken on vishing call | Password reset completed |
| Post-reset enrollment | New Windows device + PRT | Persistent Entra session |
| Federated SAML apps | MFA previously satisfied | SaaS access without step-up |
| SharePoint / mail / Graph | Session treated as legitimate | Bulk file and mailbox use |
Revoking tokens, freezing SaaS users, and hunting mailbox cleanup are necessary after the fact. They do not rewrite the moment a transferable recovery code was valid over a voice channel. Shortening session lifetime also does not prevent the first successful reset. If the attacker already holds the password and can register a device, lifetime limits only force them to move faster inside a window they already own.
Helpdesk-themed recovery abuse keeps recurring for a structural reason. Whether IT is coached into a reset or the employee is coached into reading a code, the transferable secret is the product. In this Sophos case the secret was the SSPR SMS verification code, and the payout was a device-backed cloud session that federation reused.
What phishing-proof recovery changes for Entra SSPR
Prevention for this path is upstream of the PRT. If recovery never accepts a factor a human can speak, type into a coached channel, or forward from SMS, the helpdesk-impersonation call cannot finish the reset. Device-bound, origin-bound credentials leave no OTP, push, email code, or recovery string for IT or the user to read out. Adding or replacing a device requires proof from an already-enrolled device, not a phishable enrollment code delivered by voice or text.
Under that model the attacker still can call and still can sound like help desk. They cannot complete SSPR by harvesting a spoken SMS code, because that code does not exist in the flow. Without the reset, they do not set the password, do not register the rogue Windows device under the victim identity, and do not receive the Primary Refresh Token that later sign-ins treated as already authenticated. Graph reconnaissance, the ~100,000 SharePoint downloads, the ServiceNow sys_user export, and the Salesforce sign-in in this case all rode that post-reset session. Stop the recovery handoff and those token-stage actions never start from this vector.
That is prevention, not detection: the identity system refuses transferable recovery secrets instead of hoping analysts notice anomalous SSPR geography after the password has already changed. Detection, revoke, Conditional Access evaluation, and SaaS freezes remain essential when malware steals a cookie from a machine that already held a legitimate session. This intrusion never needed that higher bar. Sophos documents voice social engineering of an SMS code on the real SSPR path.
SSO design still matters after any successful authentication. One shared federation cookie or assertion that every integrated app trusts turns a single Entra proof into a skeleton key across mail, files, CRM, and ITSM. Secure Explicit Sign-On keeps the one-tap user experience while authenticating each application with its own fresh, device-bound signature so no shared replayable SSO token exists to fan out the way this PRT-backed SAML path did. For workforce Microsoft 365 and Entra estates that still rely on classic SSO, shrinking that blast radius is architectural, not a matter of training staff to spot fake helpdesk callers.
Passkeys harden the daily login ceremony when deployed carefully. They do not automatically rewrite SSPR, break-glass, or helpdesk re-enrollment if those paths still issue SMS or email codes. Full-lifecycle coverage is what separates phishing-resistant login from phishing-proof identity.
Passkeys and FIDO2 when recovery is the target
Passkeys and FIDO2 use a device-held key pair. The private key stays in hardware and signs an origin-bound challenge; the server stores only a public key. Industry language correctly calls that phishing-resistant at the authentication ceremony: a coached fake origin cannot complete a usable signature for the real enterprise IdP. Illustrate it on a generic enterprise identity provider that issues only hardware-bound signatures, not on a consumer login host. Against this Sophos path the daily login ceremony was not the first failure. The spoken SSPR SMS code was. Phishing-resistant login alone leaves recovery free to reintroduce a transferable factor unless enrollment policy forbids it.
The enrollment gap after SSPR succeeds
FIDO2 and passkeys are phishing-resistant at login. Enrollment, device onboarding, and recovery can still accept SMS, email OTP, or helpdesk-issued secrets unless the deployment bans them. In the Sophos X-Ops case the attacker did not need to break a passkey ceremony. They completed SSPR with a spoken SMS code, then registered a new Windows device and obtained a PRT under the reset identity. If recovery and enrolment still allow verbally transferable proofs, an attacker who wins that call enrolls hardware that later looks legitimate. Phishing-proof MFA 2.0 keeps phishable factors out of registration, device onboarding, authorisation, authentication, and decommissioning, so helpdesk theater cannot mint a new trusted device from a phone code.
Key takeaways for defenders
- Remove SMS, email OTP, and other verbally transferable factors from Microsoft 365 SSPR and helpdesk recovery.
- Require an already-enrolled device for any new device registration after reset; block solo attacker-driven Entra device join on workforce accounts.
- Treat PRT issuance and federated SAML "MFA previously satisfied" paths as high-value audit signals immediately after any password reset.
- Prefer per-app device-bound proof over one replayable SSO session across SharePoint, Salesforce, ServiceNow, and mail.
- Keep revoke and SaaS freeze runbooks ready for residual malware-grade session theft; do not confuse that residual path with SSPR SMS vishing.
Workforce identity fails in public when recovery still ships a code a person can speak. Close that channel and the helpdesk call stops being a remote password-reset API.
FAQ
Would phishing-proof recovery have stopped the Sophos X-Ops SSPR vishing intrusion?
Yes. Phishing-proof recovery would have stopped the Sophos X-Ops SSPR vishing intrusion at the password-reset step because no SMS or other verbally transferable verification code would exist for the employee to read to a fake helpdesk caller. Without that code the attacker could not complete SSPR from an attacker-controlled IP, register a new Windows device, or obtain the Primary Refresh Token used for Graph, SharePoint, Salesforce, and ServiceNow access.
Why did federated Salesforce and ServiceNow access show MFA as previously satisfied?
Federated Salesforce and ServiceNow access showed MFA as previously satisfied in the Sophos X-Ops case because those SAML sign-ins rode an already-issued PRT-backed Entra session after the SSPR takeover. According to Sophos X-Ops, later ServiceNow access was recorded as SAML 2.0 authentication using a primary refresh token, so apps did not demand a fresh interactive MFA challenge at the SaaS boundary.
Are passkeys enough to stop helpdesk SSPR SMS abuse on Microsoft 365?
Passkeys alone are not enough to stop helpdesk SSPR SMS abuse on Microsoft 365 if self-service reset and device onboarding still accept SMS or similar transferable factors. Passkeys are phishing-resistant at the login ceremony; the Sophos X-Ops intrusion abused recovery, then enrolled a new device. Phishing-proof coverage across enrollment and recovery is required so a spoken code cannot mint a trusted factor.
What is Secure Explicit Sign-On and why does it matter after a PRT is issued?
Secure Explicit Sign-On matters after a PRT is issued because classic SSO lets one Entra session unlock every integrated app without a new proof, which is how this intrusion reached SharePoint, Salesforce, and ServiceNow from a single device-backed token. SES keeps one-tap UX while each application receives its own fresh device-bound signature, so there is no shared replayable federation cookie to fan out across SaaS.
Does MFA 2.0 stop malware that steals tokens after a legitimate sign-in?
MFA 2.0 does not stop malware that steals tokens from a machine that already holds a legitimate sign-in; that residual path is endpoint compromise and session revoke work. The Sophos X-Ops SSPR case did not use malware for initial access. Removing the spoken SMS recovery factor prevents this vishing path from minting the session in the first place.
