What Microsoft Learned From 1,000+ Salesforce Breaches

Attackers pulled data from more than 1,000 Salesforce environments last year without breaking Salesforce once, and Microsoft just published how. Here is what your team must change.

Microsoft just published the anatomy of how attackers walked into more than 1,000 Salesforce environments over the past year, and the most unsettling part is what was not involved. There was no flaw in Salesforce’s code. There was no failed login, no malware, no alarm. Every one of those organizations did the security basics, and attackers still pulled their data out through a connection the company had already chosen to trust, on defaults and integrations that no one, on either side, was watching closely enough.

That finding, published on July 13, should change how every security leader thinks about their integrations, and after more than nineteen years architecting and securing Salesforce as a Certified Technical Architect, it matches exactly what I have watched play out in the field. The perimeter your team spent a decade defending is the login, and the authorization still runs through it, but the attack no longer does.

Mandiant’s M-Trends 2026 report, built on more than 500,000 hours of frontline investigations, named the shift plainly, calling integrations the new perimeter. Attackers are harvesting long-lived OAuth tokens and session cookies that stay valid after a user logs out, which lets them operate without ever triggering a multi-factor prompt. Salesforce was one of the platforms Mandiant named as being hit this way.

In the sections below I will walk through what Microsoft found across those breaches, the blind spot that let the campaign run undetected for a full year, what Microsoft and Salesforce shipped to close it, and the ten priorities every security leader should be handing their Salesforce team now.

The core finding is a blind spot, not a vulnerability

Microsoft’s threat intelligence team grouped a year of this activity, running from mid-2025 into mid-2026, into three techniques. The first is a voice-phishing call in which an attacker poses as IT support and walks an employee through Salesforce’s OAuth consent screen to authorize a malicious app disguised as a data tool. The second is the theft of OAuth tokens from a trusted software vendor, which lets an attacker export data across many customer orgs at once. The third is misconfigured guest access to Experience Cloud sites, where a guest role was left able to read far more than intended.

The reason all three worked for a year is the part every security leader needs to understand, because it is not obvious from the headlines. Once a connected app is authorized through one of the user delegated flows, it acts inside Salesforce as the user who approved it, so every query it runs looks like legitimate activity from a known identity. The token it holds keeps working after that user logs out, which means there is no second login event for a conditional-access rule to catch and no failed-authentication pattern for a monitoring tool to flag. The identity controls most of us built over the last decade, with MFA, conditional access, and session policies, were designed to scrutinize the human login. They were never built to watch what a trusted integration does once it is already inside.

That is the blind spot, and it explains why mature teams with strong authentication still lost data. Detection was never the failure here. The failure was that nothing was watching what a trusted connection did after it was trusted.

The scale of the campaign is the reason this cannot wait

The breadth here is not a handful of headlines. Independent analysis corroborates breaches at more than 1,000 organizations, with the crew claiming roughly 1.5 billion stolen records. The Salesloft Drift wave alone reached about 760 organizations, and the named victims read like a global directory, including Google, Cisco, Adidas, Chanel, Louis Vuitton, Qantas, Air France-KLM, and Allianz Life. One caution belongs here, because the same activity is attributed to ShinyHunters, to Google’s UNC clusters, to Microsoft’s Storm-3138, and to a crew calling itself Icarus, and these labels overlap and get claimed opportunistically. The method is consistent even when the name is not.

The platform code itself was not breached, and it is worth being precise about that, because the security community says so too. Independent researchers describe these guest-user exposures as a tenant configuration problem rather than a flaw in the Salesforce product, and one that teams have flagged for years. That precision cuts both ways. Configuration is the customer’s job under Salesforce’s shared-responsibility model, yet the defaults at the center of these attacks were permissive enough to catch out experienced teams, which is why Salesforce spent the past year tightening them, moving connected apps to require admin approval by default rather than letting any user authorize one. Responsibility here is genuinely shared, and pretending otherwise in either direction misses how this kept happening.

Microsoft’s report traces the campaign across a handful of high-impact dates

The report anchors the year to the moments that mattered most:

• Mid-2025 is when the voice-phishing wave began, and Google confirmed one of its own Salesforce instances was hit that June.
• August 2025 is when stolen Salesloft Drift tokens exposed roughly 760 organizations.
• November 2025 is when a Gainsight token-theft wave reached more than 200 Salesforce instances.
• June 2026 is when the Klue compromise hit LastPass, BeyondTrust, and other security vendors.
• July 13, 2026 is when Microsoft published the research and, with Salesforce, shipped new tooling to catch it.

The cost lands hardest where customers lose trust

The financial exposure behind that breadth is severe. A breach in the United States now averages 10.22 million dollars. The damage does not stop at the incident invoice, and it does not stop when the forensics close. After the Allianz Life breach, one of the named victims in this very campaign, EzProtect research found that 43 percent of affected customers went looking for an alternative provider and 15 percent said they would never use the company again. That is the real bill, and it is the number that should reach your board.

Microsoft and Salesforce shipped real tooling to close the gap

The encouraging development is that the same research came with a response. Microsoft worked with Salesforce to surface what happens after access inside Defender for Cloud Apps. For customers running Salesforce Shield, the upgraded connector onboards Real-Time Event Monitoring for near-real-time detection and adds connected-app attribution, tying each action to a specific app identity and the OAuth scopes it holds. Alongside that, Microsoft added governance features that show which connected apps carry elevated privileges, flag apps that have gone inactive for ninety days or more while keeping live permissions, and assign each app a risk score.

The goal is to find the over-permissioned and forgotten integrations before an attacker does. It is also worth being precise about its limits. Everything Microsoft and Salesforce shipped works to improve detection and visibility, telling you faster and more clearly when a connected app is doing something it should not. What none of it does is own what happens after the alert. The finding that ran through all 1,000-plus breaches was never that no one saw the activity. It was that no one was accountable for what came next, and more on that below.

Ten priorities for CISOs and CTOs to direct their Salesforce teams on

Every one of these paths maps to a control you already own, and the work belongs on your roadmap to be implemented with your teams right away. These are the ten I would put in front of any security leader:

• Commission a full inventory of every connected app and OAuth grant, and set a standing policy to remove any integration unused for ninety days, which is exactly the risk Microsoft’s new tooling surfaces.
• Mandate that connected apps default to Admin approved users are pre-authorized, the setting Salesforce recommends for the most control over who can reach an app, so no employee can authorize a new integration alone.
• Make least-privilege OAuth scopes a procurement gate, granting only what an app needs rather than full access.
• Require refresh token expiry and rotation as a configuration standard, and enforce IP range restrictions on integration users and connected apps, so a stolen token cannot become long lived access from an unexpected location.
• Require system to system integrations to run on the server to server flows, JWT bearer or client credentials, rather than a user delegated flow standing on someone’s login, because Salesforce documents these as the server to server patterns and JWT bearer never issues a refresh token for an attacker to steal.
• Fund Salesforce Shield Real-Time Event Monitoring and assign a named owner to watch what each connected app queries.
• Order an Experience Cloud guest-access audit across every public-facing site, reviewing field-level security object by object as Salesforce instructs, so a guest role cannot read beyond its purpose.
• Rehearse your help desk against voice phishing with a mandatory callback policy on any access change, the countermeasure Mandiant recommends after these calls succeeded.
• Define detection thresholds for bulk exports and API spikes, and keep a token-revocation runbook ready for the moment an integration behaves oddly.
• Assign a named human owner and a defined response process to every alert, mapped to the current NIST incident-handling guidance, so detection actually leads to a verified fix.

The next wave will move faster than your team can react manually

None of this gets slower as attackers adopt AI. CrowdStrike’s 2026 Global Threat Report found that the average time from initial access to lateral movement fell to 29 minutes, with the fastest case on record at 27 seconds, and that AI-enabled adversary activity rose 89 percent in a year. In the same dataset, 82 percent of detections involved no malware at all, which means the activity looked like legitimate access, exactly the pattern behind these Salesforce breaches.

The World Economic Forum 2026 Global Cybersecurity Outlook reported that 87 percent of organizations now rank AI-related risk as their fastest-growing cyber concern. The attack surface underneath that is already enormous, with the typical enterprise carrying more than a thousand active OAuth integrations and 64 percent of third-party apps reaching sensitive data with no documented business reason.

Microsoft’s research centered on OAuth abuse, and the adjacent vector it points to is the malicious link and file. As AI industrializes phishing, those links and payloads increasingly arrive not through email that a gateway inspects, but inside Salesforce itself, in case comments, Experience Cloud submissions, and file attachments that email security never examines. Scanning the URLs and files entering your Salesforce org, at the moment they enter, is going to matter more every quarter.

Detection is not resolution, and the gap between them is where the damage lives

That distinction is the whole game, and it is where most incident response quietly breaks down. Once an alert fires, the clock starts on a chain of human decisions: who picks it up, who validates the scope, who signs off that it is contained, and who can prove all of it later. Mandiant’s warning about proving scope is really a warning about ownership, because when the audit trail has gaps, a company ends up disclosing the worst case by default, not because the breach was that bad, but because it cannot prove otherwise. That is the accountability gap. Detection has been solved for years, and Microsoft’s new tooling makes it sharper still. The distance between an alert and a verified, documented, owned resolution has not been solved, and it is where the cost and the legal exposure actually accumulate.

Nowhere does that gap get more expensive than in a courtroom. Qantas is already facing a legal complaint over its breach that could become a class action, and it will not be the last. When a breach becomes a lawsuit, the organization that can produce an immutable, timestamped record of exactly who did what and when stands in a very different place from the one reconstructing events from memory. That gap is what my team built Argus to close. EzProtect detects the malicious files and URLs reaching your Salesforce environment, and Argus owns the response from there, assigning a named human to every incident, driving it through the full NIST SP 800-61 Revision 3 lifecycle with phase gates that cannot be skipped, and holding an immutable evidence trail at every step. This is the gap that we help EzProtect customers close. We are not doing that with just another layer of detection when it comes to Argus. We are doing it with named ownership and documented closure that turns “we believe it was contained” into a record that stands up when it counts.

Microsoft’s research settles the argument that has run through every one of these breaches. The way in was never a flaw in Salesforce’s code. The way in was a trusted connection that no control was watching and no person was accountable for once it turned. The Salesforce teams that come through the next year intact will treat every integration as an identity under watch, and every alert as an incident someone owns until it is proven closed. That is the whole lesson of the past twelve months, and acting on it is what separates the companies that recover from the ones that end up explaining themselves on a leak site.

If you want your Salesforce and security team working through these exact scenarios with practitioners instead of reading about them after the fact, we host a bi-weekly Salesforce Security Office Hours. Register here.

---

Frequently asked questions

Was Salesforce itself hacked in 2025 and 2026?

No public evidence points to a flaw in Salesforce’s platform code. Independent researchers classify the guest-user exposures as tenant configuration issues rather than product vulnerabilities, and the largest waves stole OAuth tokens from third-party vendors such as Salesloft Drift and Gainsight rather than from Salesforce directly. Responsibility is shared: customers own configuration under the shared-responsibility model, and Salesforce has been tightening once-permissive defaults over the past year.

How did attackers bypass multi-factor authentication?

They did not defeat MFA, they went around it. An OAuth refresh token is a bearer credential issued after the initial login, and once stolen it mints new access tokens with no password and no MFA challenge, generating no failed logins for anyone to notice. That is why Mandiant now calls integrations the new perimeter, because the token, not the login, became the point of entry.

What was the ShinyHunters and Salesloft Drift Salesforce campaign?

It was a year of activity from mid-2025 into mid-2026 that Microsoft grouped into three techniques: voice phishing to authorize a malicious connected app, theft of OAuth tokens from a trusted vendor, and misconfigured Experience Cloud guest access. Analysts corroborate breaches at more than 1,000 organizations, with roughly 1.5 billion records claimed. Attribution overlaps across the names ShinyHunters, UNC6395, Storm-3138, and Icarus, so the method matters more than the label.

How can I tell whether my Salesforce org is exposed?

Start by inventorying every connected app and OAuth grant and removing anything unused, then review Real-Time Event Monitoring for unusual API calls or bulk exports, and audit Experience Cloud guest access field by field. Because a stolen token produces no failed logins, the signal you are looking for is unexpected behavior from a known integration, not a suspicious sign-in.

What is the difference between detecting a Salesforce breach and responding to one?

Detection tells you something happened. Response, or accountability, is the work of owning that alert to a documented, proven resolution, with a named person, a defined process, and an audit trail. Most tooling improves detection, and the distance between an alert and a closed, provable outcome is where cost and legal exposure accumulate. That accountability gap is the problem Argus was built to close, by driving each incident through the NIST SP 800-61 Revision 3 lifecycle with an immutable evidence trail.

What should a CISO do first to secure a Salesforce org?

Three moves give the most protection for the least effort. Set connected apps to admin-approved authorization so no employee can authorize a new integration alone, move system-to-system integrations onto the JWT bearer or client credentials flows that never issue a stealable refresh token, and turn on Real-Time Event Monitoring with a named owner watching what each connected app queries.