A stolen Microsoft 365 identity can become a cross-SaaS incident before anyone creates a suspicious inbox rule. A new Sophos investigation shows why defenders should connect account recovery, device registration and downstream application activity instead of treating business email compromise as an email-only problem.

Source: Sophos X-Ops — Beyond the mailbox: Graph reconnaissance and ServiceNow user enumeration in a modern identity intrusion, by Andrew Bonwell. The case findings below are attributed to Sophos; the response priorities are Bulwark Black analysis.

What Sophos observed

Sophos reports that an attacker impersonating help-desk personnel persuaded a user to disclose an SMS verification code during self-service password recovery. The attacker reset the password, registered a Windows device in Entra ID and established a Primary Refresh Token-backed session. That identity subsequently accessed Microsoft 365 and federated SaaS applications.

The investigation identified approximately 100,000 unique SharePoint file downloads and a ServiceNow user-table export containing roughly 2,500 records. Salesforce access was confirmed, but the reviewed evidence did not establish large-scale CRM extraction. Sophos also reports that the attacker deleted a vishing-warning email. No new inbox rules, forwarding rules or applications were observed.

Why this matters for smaller teams and contractors

Single sign-on reduces friction for legitimate workers. It can also extend the reach of an attacker-controlled session. An account with ordinary business access may expose shared mailboxes, document libraries, customer systems and staff directories without acquiring administrator privileges.

For government contractors, the investigative question is not simply whether email was read. Determine which repositories the identity could reach, what information those repositories held, and what evidence establishes access or collection. Do not assume that all downloaded files were sensitive government information, or that a generic user-directory export contained particular fields: validate actual content and configuration before making impact or reporting decisions.

A practical containment sequence

  1. Preserve the timeline while containing access. Retain identity sign-in and audit records, password-reset events, device registrations and authentication-method changes. Export relevant application logs before retention windows close. Evidence collection should not delay urgent containment.
  2. Contain the identity and its sessions. Block the affected account as appropriate, revoke supported sessions and refresh tokens, remove unauthorized authentication methods, and investigate newly registered devices. A registered device is not automatically a compliant or trusted device.
  3. Follow federation into each application. Coordinate with the owners of Microsoft 365, ServiceNow, Salesforce and other reachable services. Invalidate downstream sessions using each platform's supported controls; do not assume an identity-provider action instantly terminates every application session.
  4. Scope data access separately from sign-in. Review SharePoint downloads and searches, mailbox access, shared-mailbox permissions, SaaS exports and access to generated export attachments. Distinguish confirmed collection from browsing or access alone.
  5. Plan for follow-on impersonation. If directory information was exported, warn help-desk and business teams that callers may possess convincing names, reporting relationships or contact details. Verify sensitive requests through established channels, not contact details supplied by the caller.

Detect the sequence, not a single unusual event

Prioritize correlations: a password reset followed by an unfamiliar device registration; a new session enumerating directory objects through Microsoft Graph; unusual SharePoint collection; and first-seen federated application access followed by bulk export. Graph requests and exports have legitimate uses, so assess volume, user role, device history and session context rather than treating every query as hostile.

Inventory whether your logging actually captures these events and how long it retains them. Sophos notes a blind spot around passive reading of existing Teams conversations: absence of message-creation activity does not establish that no content was viewed. Similarly, a sign-in marked “MFA previously satisfied” describes authentication context, not proof that the current operator is legitimate.

Bulwark Black assessment

The highest-value improvement is a cross-SaaS recovery drill: choose one compromised-user scenario, identify every application owner, and prove that your team can preserve evidence and terminate access throughout the chain. Harden recovery and device-enrollment workflows alongside phishing-resistant sign-in controls, checking which protections your actual platform supports. Train staff that a legitimate help desk does not need a verification code read aloud over the phone.

Bottom line: closing the mailbox alert is not the same as recovering the identity. Scope the incident across the services that trusted it.