Sophos: Vishing and SSPR Reset Enable Entra PRT Session Hijack and SharePoint Data Theft

The case involved no exploit, malware or malicious OAuth app. The details also show where many Microsoft 365 tenants have blind spots.

What Sophos reports happened​

The victim organization had already warned staff by email about suspicious calls. One employee had been compromised before that warning went out. The employee later said the caller posed as help desk staff and talked them into reading out the SMS verification code the SSPR flow required.

• Possible probing: Telemetry showed an SSPR initiation from a geographically anomalous IP address the day before. Sophos says it can't tell whether that attempt was related.
• The takeover: The confirmed reset came from a different attacker-controlled IP. The attacker completed SMS verification and reset the password.
• Device registration: Within minutes, the actor registered a new Windows device in Entra ID. The actor then used a Primary Refresh Token (PRT), and Microsoft Edge authenticated in that device context.
• Federated sign-ins: Later ServiceNow sign-ins were logged as SAML 2.0 using a PRT, with MFA shown as "Previously satisfied." Sophos reads this as reuse of an existing cloud session, not fresh interactive logins at each app.

The point is that the user took part in a legitimate recovery workflow. Nothing had to be phished on a fake page.

Graph reconnaissance​

Sophos reviewed the Defender GraphApiAuditEvents table and found queries consistent with structured enumeration. The query patterns it documented cover these areas:

• User licensing, via /me/licenseDetails
• Organization metadata, via /organization
• Tenant relationships, via the beta tenantRelationships/getResourceTenants endpoint
• Directory role assignments, via a transitiveRoleAssignments query
• Owned service principals, with $top=999
• Verified domains, via /domains
• SharePoint sites, via /sites
• Individual users and user counts

These queries show what the actor looked for. They don't prove each one returned data the account couldn't already see. Sophos also did not identify which client issued the Graph calls.

Impact: SharePoint, mail, Teams, Salesforce, ServiceNow​

Sophos puts the main impact on email and SharePoint data. Unified Audit Log analysis found:

• Over 100 unique mail items accessed, across the user's mailbox and shared mailboxes they could reach.
• Approximately 100,000 unique SharePoint files downloaded.

SharePoint search logs showed terms such as "Password," "Cred," "VPN," "SSH," "AWS," "SSN" and "Jira." Four searches, including misspellings, named the organization's identity verification vendor. Sophos says that suggests the actor either already knew the MFA platform or was hunting for bypass documentation. Sophos does not say which.

On cleanup, the actor created no inbox rules, forwarding rules or apps. The only observed Exchange cleanup was deleting two messages. One was the organization's own vishing warning, which the actor had read first.

Salesforce: Federated access was confirmed, but Sophos saw no large-scale CRM extraction. Salesforce logged a SuspiciousActivity event followed by FreezeUser and SendEmail. Sophos attributes these to automated anomaly containment that froze the account and notified the administrator.

ServiceNow: This was the largest non-Microsoft impact. The same user context logged in, browsed dashboards, repeatedly opened the sys_user list and exported it. It then read the resulting sys_user.csv, which export metadata put at about 2,500 records.

• Depending on configuration, sys_user can hold names, emails, phone numbers, roles, departments and managers.
• The session also viewed the cmdb_ci_computer list, which can hold hardware names and operating systems. Sophos found no evidence it was exported.
• The organization kept receiving phishing and vishing attempts. Sophos says the stolen data may have been used in them, but it does not establish that.

Teams: Purview logged a TeamsSessionStarted event. Sophos notes that Microsoft doesn't audit passive viewing of existing chat and channel messages. So the log shows Teams was opened, but not what was read.

Interpreting the mailbox numbers​

Microsoft's documentation on MailItemsAccessed explains a caveat when you size a mailbox compromise. Per Microsoft Learn, bind operations record individual messages, while sync operations record the folder, and all items in a synced folder are assumed compromised. Sync records only appear for desktop Outlook clients on Windows or Mac. A count of "over 100 items" is therefore a floor for bind activity. It is not a full measure of exposure, so check for sync events from the same IP and session.

Defender takeaways​

Sophos builds its advice on the observed chain. Here are the practical points, with notes where this article adds context.

1. Harden recovery, not just sign-in. Favor FIDO2 keys, passkeys, Windows Hello for Business or certificate-based authentication. Where SMS stays, keep admins out of it and require explicit registration instead of directory-sourced phone numbers. Treat SSPR from unexpected locations as a signal.
2. Treat device registration as privileged. Alert on a new device shortly after a password reset or MFA change. Require MFA on registration itself. Consider automated session revocation until someone verifies the device.
3. Contain across the whole estate. Resetting the password isn't enough. Sophos says to revoke sessions and refresh tokens in the identity provider and in every federated SaaS platform the identity could reach.
4. Hunt after sign-in. Look for Graph enumeration from one session and SharePoint searches for credential terms. Also watch for mail access followed by deletion of security notices, SAML sign-ins to new apps with MFA satisfied by an existing claim, and bulk exports from identity, CMDB or CRM tables.

The Entra revocation step​

Microsoft Learn documents the emergency procedure for an individual user. In the Entra admin center, you can block new sign-ins and revoke refresh tokens. The documented flow includes these steps:

• Disable the account.
• Select Revoke sessions on the user's Overview page.
• Disable the user's registered devices.

In PowerShell, the documented cmdlet is Revoke-MgUserSignInSession. A separate documented example uses Get-MgUserRegisteredDevice and Update-MgDevice to disable devices. The device step matters here, because the attacker's foothold was a registered device.

Revocation has limits. A Microsoft Q&A answer notes that it stops future token refreshes but doesn't instantly kill already-issued access tokens. Those expire naturally. Community write-ups put the default access token lifetime at about one hour, which Microsoft's page also states. Browser and app sessions, and app-owned session cookies in downstream SaaS, may need separate handling. Check each platform's own session controls.

Vendor claims​

Sophos also describes its own products, and that part is self-assessment. By its own account:

• Its research rule correlating device registration with an unseen login property closely matches this sequence, but it is a research rule and does not alert.
• It cannot say its Azure CLI or PowerShell alert would have fired, because the Graph client wasn't identified.
• It lacks direct coverage for general Graph directory, role or service-principal enumeration from a single session.
• Its XDR alert correlating an anomalous login with mass SharePoint downloads from the same IP within an hour would have applied.

The victim was not a Sophos customer, so the "would have been protected" framing is hypothetical. The account is also based on one case. It reflects the investigators' reading of logs, and Sophos says indicators of compromise will be published on its GitHub.

Why it matters​

Sophos' own conclusion is that no single step was novel. Each action used a workflow built to be frictionless. The assembly was the novelty. Sophos also cites Mandiant reporting on GOLD CRYSTAL (ShinyHunters)-linked SaaS extortion activity as the same pattern, without tying this incident to that group. For Windows and Microsoft 365 admins, the practical lesson is that SSPR methods, device registration policy and cross-SaaS session revocation deserve as much scrutiny as the sign-in page.