A caller posing as help desk staff talked an employee into sharing the SMS code for Microsoft Entra self-service password reset. After taking over that one account, the intruder downloaded approximately 100,000 SharePoint files and exported a ServiceNow user table with approximately 2,500 records, according to Sophos X-Ops’ October 19 incident investigation. Organizations that use Entra to sign users into Microsoft 365 and other SaaS apps have the same kind of recovery-to-federation path to examine.
The intruder also opened the organization’s email warning staff about the scam calls, then deleted that message from the compromised mailbox. Sophos describes one compromised account at one organization. The reset, new device and federated sign-ins give defenders a single user-and-session timeline to investigate.
A phone call unlocks recovery
Several employees had reported suspicious calls, and the organization had sent a warning. The affected employee later told investigators that the caller claimed to be help desk staff and asked for the SMS verification code. Sophos traced a successful Entra self-service password reset, or SSPR, to a different IP from an earlier geographically anomalous SSPR initiation. The earlier attempt’s relationship to the confirmed intrusion remains uncertain; prioritize the completed reset and subsequent device event when investigating a comparable sequence.
Microsoft’s SSPR documentation explains that tenant policy chooses the permitted verification methods and whether users provide one or two methods. SMS is among the supported methods. That makes the recovery configuration a real exposure decision: a strong sign-in method alone leaves this phone-assisted reset path if a user can complete recovery with a shared code.
Registered device carries access
Minutes after the reset, Sophos observed a new Windows device registered to the compromised Entra identity, successful use of a Primary Refresh Token, or PRT, and Edge authentication in that device context. Microsoft explains that the token broker uses a PRT for single sign-on and to request tokens for cloud applications. Later ServiceNow sign-in records showed SAML 2.0 with a PRT and MFA marked “Previously satisfied.” That record ties the downstream login to an already authenticated cloud session.
The account moved through My Apps, Graph and Salesforce, then into ServiceNow. Sophos found Graph queries for directory roles, users, service principals and tenant details in GraphApiAuditEvents. The identity opened more than 100 unique mail items across its own and shared mailboxes, and SharePoint logs showed downloads of approximately 100,000 unique files. SearchQueryInitiatedSharePoint recorded searches for password, cred, aws, vpn and ssh, among other terms. Correlate those searches with the user’s reset, new-device registration and sign-ins before escalating.
ServiceNow logs show the export
ServiceNow records show a federated login, repeated visits to the sys_user list, export activity, and a read of the generated sys_user.csv attachment. Export metadata put the CSV at approximately 2,500 records. The table can hold names, email addresses, phone numbers, roles, departments and managers, depending on the organization’s configuration. The same session browsed the cmdb_ci_computer list; investigate that access as browsing, while the sys_user CSV is the confirmed export.
Salesforce telemetry also showed a successful federated login. Its SuspiciousActivity event was followed by FreezeUser and SendEmail, indicating automated containment and administrator notification. Investigate CRM exports on their own terms; the documented mass download was from SharePoint. In Exchange, the actor deleted two messages, including the vishing warning. Sophos writes that the actor “read and confirmed the organization was aware of the campaign before suppressing it from the compromised user’s view.” Those ordinary account actions are useful investigation pivots when a mailbox-rule hunt comes up empty.
Follow the session across applications
Start with the affected identity’s SSPR completion, nearby device registration and Entra sign-ins. Join the user, device and session timeline to GraphApiAuditEvents, MailItemsAccessed, SearchQueryInitiatedSharePoint, SharePoint downloads, and SAML sign-ins to Salesforce and ServiceNow. In ServiceNow, inspect sys_user export events, generated attachment reads and their record counts. Compare the sequence with the user’s known devices and approved application access before deciding its reach.
Change the recovery and registration controls that let this sequence work. Move users away from SMS and voice recovery where feasible; where they remain, restrict eligible accounts and review the number of required recovery methods. Microsoft’s Conditional Access documentation names Register or join devices and Register security information as targetable user actions. Apply an appropriate MFA or authentication-strength requirement to device registration and test it against an authorized enrollment. Microsoft warns that this user-action policy requires the tenant-wide device-registration MFA setting to be set to No for proper policy enforcement. Alert on a new device registered soon after SSPR. For a compromised identity, revoke its active Entra sessions and refresh tokens and terminate sessions in the federated SaaS apps it accessed, then verify that the suspect device is removed and its sessions no longer authenticate.
An investigation also needs to account for passive Teams reading: Sophos notes that opening an existing chat or channel message leaves no audit event for what was viewed. Sophos labels its device-registration correlation a research rule; configure your own production alert for that sequence. Verify the containment with a fresh sign-in and device-enrollment test under the intended policy, followed by a review of new sign-ins and exports for the affected identity. The phone call crossed into file downloads and an actual user-table export because a recovered account could enroll a device and carry its session into federated apps. Recovery policy, device admission and SaaS session revocation belong in the same response.
