Beyond the mailbox: Graph reconnaissance and ServiceNow user enumeration in a modern identity intrusion

Traditional business email compromise (BEC) is often thought of as a mailbox problem: a stolen account, unauthorized access to email, forwarding rules, and (sometimes) outgoing mail impersonating the compromised user. But more recent incidents show how far beyond “email only” these intrusions can extend once an attacker gains control of a cloud identity.

In a recent case investigated by the Sophos X-Ops Incident Response team, a threat actor used voice phishing (vishing) and self-service password reset (SSPR) abuse to take over a Microsoft 365 account, establish a Primary Refresh Token (PRT)-backed device session, and pivot into multiple SaaS platforms. Rather than stopping at mailbox access, the actor treated the compromised identity as a springboard into the target’s broader SaaS estate.

Post-compromise activity was identified from a single compromised user account and included Microsoft Graph reconnaissance, access to email and SharePoint content including the download of nearly 100,000 documents, access to Salesforce, and a confirmed user-table export from ServiceNow of approximately 2,500 records. 

The Sophos X-Ops Incident Response team works with customers who have not previously purchased other Sophos offerings such as XDR. At the end of this writeup, we briefly cover the proactive, reactive, and behavioral protections available from Sophos via our other service offerings.

Initial access: SSPR abuse enabled by vishing

The compromise began with self-service password reset (SSPR) abuse. After several employees reported receiving suspicious phone calls from a suspected threat actor, the targeted organization sent a company-wide email warning users of the attack. However, one user had already unknowingly been compromised prior to the issuance of the emailed warning. The affected user later reported that the threat actor called by phone, impersonated help desk personnel, and convinced the user to provide the SMS-based MFA verification code needed to complete the reset flow.

Telemetry shows that an earlier SSPR initiation occurred from a geographically anomalous IP address the day before the confirmed vishing event. It is not clear whether that earlier attempt was directly related, but it may represent precursor probing or an unsuccessful attempt to validate the account. The confirmed compromise occurred when the actor initiated another SSPR flow from a different attacker-controlled IP, completed SMS verification, and successfully reset the user’s password.

This initial access method is important because it bypassed the need for a phishing page, malware, or an OAuth consent prompt. The user’s participation in a legitimate account recovery workflow was enough to hand over control of the identity.

From password reset to token-backed session

Within minutes of the successful password reset, the actor went beyond simple sign-in activity and established a device-backed cloud session.

The sequence included:

• Entra ID registration of a new Windows device
• successful use of a Primary Refresh Token
• subsequent Microsoft Edge authentication using that token-backed device context

The actor established a persistent authenticated session tied to a newly registered Entra ID device, which gave them a more durable foothold than a single password-based web login.

In the sign-in records reviewed during the investigation, later access to ServiceNow was recorded as SAML 2.0 authentication using a primary refresh token, with MFA listed as “Previously satisfied.” That combination strongly suggests the actor was leveraging an already-authenticated Microsoft cloud session to access federated downstream applications, rather than performing repeated fully interactive reauthentication for each platform.

Immediate post-compromise activity in Microsoft 365

After gaining access to the account, the actor signed in to My Apps, Microsoft Graph, and Salesforce. Logs indicate the threat actor accessed emails, downloaded SharePoint documents, and launched Microsoft Teams. Microsoft Graph was used for initial reconnaissance, and over the course of the next day the actor began to sign in to additional applications, including ServiceNow.

This is not extraordinary behavior for a modern attacker. Once a threat actor has a valid session in the identity provider, they can enumerate accessible resources and pivot into downstream services. Mandiant’s reporting on recent GOLD CRYSTAL (ShinyHunters) linked and adjacent SaaS extortion activity has described this exact operational shift, where vishing and credential harvesting are used to obtain SSO access and then fan out into cloud applications for reconnaissance and data theft.

Structured Graph API reconnaissance

Sophos’s analysis of logs from GraphApiAuditEvents from Microsoft Defender identified evidence the threat actor’s activity included Graph API-driven reconnaissance queries consistent with:

• Validating user context and licensing
• Retrieving organization metadata
• Enumerating tenant relationships
• Mapping directory roles and effective permissions
• Enumerating enterprise applications and service principals
• Identifying verified tenant domains
• Enumerating individual users and larger sets of directory objects

Examples of the query patterns documented during analysis included the following:

• hxxps[://]graph[.]microsoft[.]com/v1[.]0/me/licenseDetails
• hxxps[://]graph[.]microsoft[.]com/v1[.]0/organization
• hxxps[://]graph[.]microsoft[.]com/beta/tenantRelationships/getResourceTenants?$select=tenantId
• hxxps[://]graph[.]microsoft[.]com/beta/users/{id}/roleManagement/directory/transitiveRoleAssignments?$count=true
• hxxps[://]graph[.]microsoft[.]com/beta/users/{id}/ownedObjects/Microsoft[.]graph[.]ServicePrincipal?$top=999
• hxxps[://]graph[.]microsoft[.]com/v1[.]0/domains
• hxxps[://]graph[.]microsoft[.]com/v1[.]0/sites
• hxxps[://]graph[.]microsoft[.]com/v1[.]0/users/{UPN}?$select=userPrincipalName
• hxxps[://]graph[.]microsoft[.]com/v1[.]0/users/$count 

Impact

The primary impact of the incident involved access to email and SharePoint data.

Sophos’s analysis of Microsoft’s Unified Audit Logs identified:

• Over 100 unique mail items accessed across the compromised user’s mailbox and multiple shared mailboxes to which they had access
• Approximately 100,000 unique SharePoint files downloaded

Access to emails is commonly the primary focus of BEC incidents, but this case shows how valuable a target SharePoint can be.

The threat actor accessed a relatively small number of mail items compared to the SharePoint files downloaded. A review of the subject lines of the emails accessed by the threat actor revealed a search pattern for messages related to account or credential related messages, customer information, internal organizational/team structure, and workflow approval-style emails. One of the messages reviewed by the actor was the organization's own vishing-awareness notification; that same message was subsequently deleted from the mailbox, demonstrating that the actor read and confirmed the organization was aware of the campaign before suppressing it from the compromised user's view.

For SharePoint, logs for SearchQueryInitiatedSharePoint indicate the threat actor searched for key terms with an apparent intent of identifying credentials, Personally Identifiable Information (PII), and information about product development and customers. Notably, four of the recovered queries, including several misspelled variants, targeted the organization's identity verification vendor by name, suggesting the actor either had prior knowledge of which MFA platform was in use or was specifically searching for documentation that might support a bypass.

A sample of keywords searched by the threat actor in this attack includes:

• Salesforce
• IT
• Sales
• Aws
• NDA
• Contracts
• Login
• Cred
• Engineering
• Customers
• Jira
• SSN
• Contacts
• Password
• VPN
• SSH 

Downstream SaaS pivot #1: Salesforce

The actor also pivoted into Salesforce using federated sign-in.

Entra sign-in telemetry showed multiple successful SAML-based accesses to Salesforce shortly after the attacker established the Microsoft cloud session. The reviewed Salesforce logs support the conclusion that the actor successfully accessed Salesforce, but the evidence reviewed in this case did not show large-scale CRM data extraction.

Salesforce logs showed a “SuspiciousActivity” event followed by successful execution of “FreezeUser” and “SendEmail”, indicating that Salesforce's automated anomaly-detection containment triggered, freezing the account and notifying the customer's Salesforce administrator.

Downstream SaaS pivot #2: ServiceNow

The largest non-Microsoft impact in this case came from attacker access to ServiceNow.

Entra telemetry showed a successful federated sign-in to the organization’s ServiceNow tenant. Subsequent ServiceNow logs from the same user context showed:

• A successful login and session establishment
• Navigation through dashboard views
• Repeated access to the sys_user list view
• Export activity targeting sys_user
• Read access to the generated attachment sys_user.csv

Related export metadata indicated that the resulting CSV contained approximately 2,500 records.

The sys_user table that was targeted stores a record of everyone who logs in or interacts with ServiceNow and can include details such as name, email, phone number, roles, department, and manager. The presence of specific fields depends on the organization’s configuration settings. 

The information gathered from this would give the threat actor insight into:

• Who exists in the platform
• How user accounts are structured
• How the organization is modeled

Combined with the contact information listed there, this information could be sold or used to conduct additional, more convincing social engineering attacks. In this case, the organization continued to receive numerous phishing and vishing attempts which may have utilized such information.

Notably, the same session later touched the CMDB [Configuration Management Database] Computer (cmdb_ci_computer) list view, indicating at least some additional browsing beyond the user directory. This can contain information about hardware inventory including computer names and operating systems. However, no evidence of export from that table was identified. 

Microsoft Teams access

Purview logs contained a TeamsSessionStarted operation performed by the threat actor, indicating Microsoft Teams was launched. Microsoft records events for activities such as message creation, edits, deletions, participant additions, and the creation of new chats or teams, but it does not audit the passive viewing of existing messages in chats and channels a user already has access to. This is a commonly overlooked gap. Threat actors can gather significant sensitive information through passive reconnaissance of Teams chats without leaving any audit trail of what was read.

Defense evasion and cleanup

The actor did not create inbox rules, forwarding rules, or new applications — a notable absence in a case that otherwise resembles modern BEC and SaaS intrusion playbooks.

Instead, the only observed cleanup behavior in Exchange was the deletion of two messages:

• One warning users about active vishing attempts in the environment
• One additional message of unknown content

That first deletion is particularly telling. The organization had already begun warning users about the scam calls, but the compromised user was kept from seeing that warning because the actor removed it from their mailbox.

Recommendations

This intrusion is a useful illustration that identity-centric attacks no longer stop at the mailbox. The recommendations below are scoped to the specific behaviors observed in this case and are prioritized by the leverage they would have given defenders against this exact intrusion path.

Harden the account recovery surface, not just sign-in

Phishing-resistant MFA is increasingly the default conversation for sign-in, but the same scrutiny rarely extends to recovery. In this case, the entire intrusion was unlocked because the SSPR flow accepted an SMS code the user handed over during a vishing call. 

For organizations not yet able to remove SMS and voice entirely from SSPR, several intermediate controls reduce exposure:

• Prefer phishing-resistant factors (FIDO2 security keys, passkeys, Windows Hello for Business, certificate-based authentication) as the highest-priority registered method for recovery flows
• Where SMS is retained, scope it tightly. Exclude administrative accounts, require explicit registration rather than directory-sourced phone numbers, and treat SSPR initiations from anonymizing infrastructure or unexpected geolocations as detection signals
• Monitor SSPR flows for behavioral anomalies (rapid registration of a new device immediately after reset, geographic mismatch between SSPR initiation and recent legitimate sign-ins)
• Pair technical controls with targeted user awareness. The vishing pretext in this case was specifically that "the help desk" needed an MFA code; users should be trained that legitimate help desk staff will never request an MFA or verification code by phone, and any such request should be reported

Treat device registration as a privileged operation

The pivot from "stolen password" to "durable cloud foothold" happened the moment the actor registered a new Windows device against the compromised identity. Once that device existed, PRT-backed sessions made every downstream pivot look routine. Defenders should:

• Review device onboarding and enrollment processes. Confirm there are appropriate checks to verify both the user's identity and ownership of the device before enrollment is approved. Ensure enrolment is restricted to authorized device types and managed hardware where possible.
• Alert on any new device registration within a short window of a password reset, MFA method change, or anomalous sign-in
• Require MFA on device registration itself (not just on the sign-in that precedes it)
• Pair device registration alerts with automated session revocation for the associated identity until a human verifies the registration is legitimate

Assume the blast radius is the whole SaaS estate

Once the actor held a valid identity, lateral movement happened through federation, not exploitation. Mail, SharePoint, Salesforce, and ServiceNow were all reachable through the same Microsoft cloud session, and the actor moved between them in a single afternoon. That means:

• Containment cannot end at "reset the password." Effective containment requires revoking active sessions and refresh tokens across the identity provider and every federated SaaS platform the identity could reach
• SaaS platforms with high-value identity or organizational data including ticketing, ITSM, and CRM systems should be added to the incident-response runbook alongside email and file-sharing systems
• ServiceNow in particular warrants dedicated detection coverage. The sys_user and cmdb_ci_computer tables are high-value reconnaissance targets and bulk export from either is a strong investigative signal
• Salesforce's automated anomaly containment (which triggered in this case and froze the actor's session) is a useful complementary control, but customers should validate that equivalent automated containment exists in their other federated SaaS platforms

Hunt and monitor for post-compromise reconnaissance, not just initial access

A lot of identity-compromise detection is front-loaded around the sign-in event itself. In this case, the most telling activity happened after the actor was already inside: structured Graph API enumeration, SharePoint keyword searches for credentials and PII, and federated SAML sign-ins to downstream SaaS. Defenders should build hunts for:

• GraphApiAuditEvents activity consistent with directory, role, and service principal enumeration from a single user session
• SearchQueryInitiatedSharePoint events containing terms like password, cred, aws, vpn, ssh, or the name of the organization's own identity or MFA vendor
• MailItemsAccessed volume anomalies, particularly access to security-awareness and account-notification emails followed by their deletion
• Federated SAML sign-ins to SaaS applications from sessions that have not previously accessed those applications, especially when MFA is satisfied by an existing token claim rather than an interactive prompt
• Bulk export operations against identity, CMDB, and CRM tables in federated SaaS platforms

Sophos protections

The target of these attacks was not, prior to the events in this article, a Sophos customer. Sophos customers would have been protected from this series of events at various points, including:

Proactive rules

• Sophos ITDR flags tenants for which SMS, voice call, and email OTP remain enabled as authentication methods, and for which SSPR for non-admins accepts a single method. These checks push account recovery away from verification codes that can be handed over during a vishing call.
• Sophos ITDR flags tenants that do not block high-risk users or high-risk sign-ins, and checks whether geographic Conditional Access controls and trusted named locations are configured. Trusted locations give Entra ID Protection more context for risk calculation; these controls help with follow-on sign-ins when the source is out of region or scored as risky, rather than directly governing the SSPR flow.
• Sophos ITDR flags tenants that do not protect the “Register or join devices” action with Conditional Access requiring MFA or block for all users, and tenants without policy protecting security-information registration. It also recommends defining trusted IP-based named locations, which customers can use as a signal when scoping registration from known corporate networks.
• Sophos ITDR flags tenants that do not require compliant devices in Conditional Access, or do not enforce session controls such as sign-in frequency and non-persistent browser sessions on unmanaged devices. These controls reduce the durable access available to a freshly registered, unmanaged device.
• Sophos ITDR flags tenants where administrators can still use SSPR through the authorization policy (check: “Prevent Weak Admin Authentication by Disabling Authorization Policy SSPR”).

Reactive rules

• “Azure Device Registration and Unseen Login Property” correlates device registration with a login from an unseen IP, ASN or user agent within one hour. It matches this sequence closely, but is currently a research rule and does not alert. A separate alerting rule applies when unseen-IP sign-in is followed by security-info registration and a new Authenticator device, which this article does not confirm.
• Sophos ITDR alerts on Azure CLI or PowerShell use by a user with no prior history. This could provide coverage if the Graph reconnaissance used one of those clients, but the investigation does not identify the client, so we should not claim that it would have fired. We do not currently have direct coverage here for general Graph directory, role or service-principal enumeration from a single session.
• Sophos XDR alerts on “Unusual Login and File Download Behavior Detected from Single IP for a User,” correlating an anomalous login with mass SharePoint downloads from the same IP within one hour. A second alerting variant covers unusual login followed by downloads through a suspicious or non-standard client.

Behavioral signaling

• Sophos identity analytics baseline IP address, ASN, country and user agent per user. Previously unseen values, including a switch to new attacker infrastructure, feed higher-confidence compromise correlations; “Multiple Unseen Countries for User” can also alert when the locations meet that condition.
• Sophos identity analytics baseline application access and client properties such as user agent, IP, ASN and country. Previously unseen applications or client properties add context to post-compromise activity, but are supporting signals rather than proof of compromise by themselves.

Conclusion

No single step in this intrusion was novel. The actor reset a password, registered a device, used a refresh token, queried Graph, and signed into federated apps. Every one of those actions is a workflow Microsoft and the surrounding SaaS ecosystem designed to be frictionless for legitimate users. The novelty was in the assembly: a vishing call at the front end and a ServiceNow user-table export at the back end, with a fully sanctioned cloud session connecting them.

That is a harder problem for defenders. There is no malware to find, no exploit to patch, and no obviously malicious tool to block. The activity blends with normal use because, mechanically, it is normal use performed by the wrong person. Programs built around identity behavior, session lineage, and cross-SaaS correlation will see most of it.

For organizations still treating BEC as a mailbox problem, this case is a useful prompt to widen the scope. The mailbox is rarely the destination anymore; it is just the first room the attacker walks through.

The indicators of compromise associated with this attack will be made available on our GitHub.

Acknowledgements

Joosua Santasalo contributed the “Sophos protections” section of this writeup.

MITRE mapping