The Salesforce breach pattern is really a SaaS identity checklist

The Salesforce breach pattern is really a SaaS identity checklist

A recurring wave of Salesforce-linked data theft stories has a cleaner lesson than “change your password.” The public record points to a broader SaaS failure mode: attackers do not need to break the application when they can persuade a person to approve access, add a device, authorize an app, or leave bulk-export telemetry unread.

Salesforce said in March 2025 that it had observed threat actors using social engineering, including voice phishing, to impersonate IT support and push employees or third-party support workers toward phishing pages that steal credentials and MFA tokens. Salesforce also said some victims were prompted to visit its connected-app setup page and add a malicious connected app; in some cases, the malicious app was a modified version of Data Loader, renamed or rebranded. Once attackers gained account access or added the connected app, Salesforce said they used it to exfiltrate data.

Mandiant’s January 2026 reporting describes the same problem at a wider SaaS level. It said clusters associated with ShinyHunters-branded extortion operations used vishing and victim-branded credential-harvesting sites to obtain SSO credentials and MFA codes, then targeted cloud-based SaaS applications for data theft and extortion. Mandiant explicitly framed the activity as not a security vulnerability in vendor products or infrastructure, but as social engineering that bypassed identity controls and moved into SaaS environments.

That distinction matters. If the breach path is “valid access plus native export tools,” the control checklist has to move beyond password resets.

The checklist:

1. Treat help-desk identity changes as high-risk transactions.

Mandiant says these campaigns frequently exploit password resets, device enrollments and MFA changes. Its guidance calls for high-assurance verification for account-change requests, including independent callback to a known-good number and out-of-band approval from a known manager. It also warns help desks not to act on inbound vendor-support claims without independently contacting the company’s designated account manager through trusted contact information.

The practical test: Can your help desk prove who requested a reset, which trusted channel confirmed it, and who approved it before a new factor or device was enrolled?

2. Move MFA away from codes, prompts and phone workflows.

MFA is still necessary; Salesforce says passwords alone are not sufficient and that MFA is required for access to its services. But Mandiant’s warning is sharper: the campaigns it tracks compromised SSO credentials and MFA codes, then enrolled unauthorized devices. Mandiant’s recommended long-term defense is phishing-resistant MFA such as FIDO2 security keys or passkeys, which are more resistant to social engineering than push-based or SMS authentication.

The practical test: Are privileged users and help-desk-adjacent roles using phishing-resistant MFA, or can an attacker still win by talking someone through a code or approval prompt?

3. Audit connected apps like production infrastructure, not app-store clutter.

Salesforce’s own account of the pattern centers on malicious connected apps and Data Loader-style abuse. Its guidance tells customers to review who has “Customize Application” and either “Modify All Data” or “Manage Connected Apps,” to restrict API access with connected apps, and to allowlist known safe apps.

The practical test: Can security staff list every connected app, who approved it, what scopes it has, where it can be used from, and whether it can reach bulk-export paths?

4. Watch API and bulk-export behavior, not just logins.

Mandiant says modern SaaS intrusions often abuse native capabilities such as bulk exports, connected apps and administrative changes. It warns that without visibility into which identity authenticated, what permissions were authorized and what data was exported, organizations may not learn about the campaign until an extortion note appears. For Salesforce specifically, Mandiant says basic login history is not enough for activity such as Data Loader use and large-scale access patterns; it points to telemetry covering logins, configuration changes, connected app/API activity and export behavior.

The practical test: Would your alerts fire on unusual API use, report exports, Bulk API result downloads, permission changes and connected-app activity before an attacker sends a demand?

5. Put SaaS logs in one investigation path.

Mandiant’s examples stretch beyond Salesforce into identity providers, Google Workspace, Microsoft 365, DocuSign, Atlassian and other SaaS surfaces. Its guidance says the first reliable signals after vishing and MFA manipulation may appear in the SSO control plane, while later theft can show up in document, mail, CRM or collaboration logs.

The practical test: Can responders reconstruct one user’s path across SSO, device enrollment, OAuth authorization, Salesforce API access, mailbox changes and file exports without opening six separate consoles under pressure?

6. Control local and non-human accounts.

Mandiant recommends reviewing SaaS “local accounts” that are not governed by the main identity provider, limiting non-human accounts, monitoring OAuth/API tokens for abnormal activity, and tracking programmatic identities by owner, system, usage and access scope. That is the quiet part of many SaaS incidents: not every useful identity is a human login in the central IdP.

The practical test: If a contractor account, legacy admin account, integration token or API key were abused tonight, would anyone know its owner, expected behavior and blast radius?

7. Restrict where access can originate.

Salesforce recommends login ranges and trusted IPs, including profile-level IP restrictions. Mandiant recommends limiting access to trusted egress points and managed compliant devices, and restricting SaaS access from unmanaged devices where possible.

The practical test: Can a newly phished session immediately operate from an attacker-controlled device and network, or do device posture and trusted-location rules slow it down?

The accountability question is not whether a company “has MFA.” It is whether the company can see and govern the steps after a successful social-engineering call: a new factor, a new device, a new app authorization, a mass export and a pivot into adjacent SaaS tools.

For readers running SaaS environments, the cleanest tabletop exercise is simple: pick one sensitive CRM user and ask how the organization would detect and stop a caller who convinces that user, or the help desk, to authorize the attacker’s access. If the answer depends mostly on the user noticing something feels wrong, the control plane is still doing too much trust cosplay.

Sources:

• Salesforce Security Team, “Protect Your Salesforce Environment from Social Engineering Threats,” March 12, 2025, updated March 14, 2025: https://www.salesforce.com/blog/protect-against-social-engineering/
• Mandiant / Google Threat Intelligence, “Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft,” January 30, 2026: https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
• Mandiant Services, “Guidance from the Frontlines: Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS,” January 30, 2026: https://cloud.google.com/blog/topics/threat-intelligence/defense-against-shinyhunters-cybercrime-saas

---

Shadowfetch is a technology publication. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.