How SaaS data exfiltration works, the quiet breaches of 2026

The headline breaches of 2026 had a new shape. Instead of hacking a company's own servers, attackers drained the SaaS platforms those companies live in: Salesforce, Microsoft 365, CRMs, support desks. The ShinyHunters extortion campaign exfiltrated customer data at scale this way; one telecom reportedly lost hundreds of terabytes. And almost none of it involved breaking software. It involved using it.

This is the modern data-theft model, and understanding it changes what "securing your data" even means when your data lives in someone else's app.

The one idea: your data lives in apps you don't control

A decade ago your customer data sat in a database on a server you ran. Today it sits in SaaS platforms, and those platforms are designed to make data easy to access and export. That's a feature for you and a target for attackers. The attack surface moved from "your server's vulnerabilities" to "who and what can log into your SaaS tenant, and what they're allowed to take."

Once an attacker has legitimate access, the platform's own export features do the rest. There's no malware to detect; it looks like normal use.

How they get in: tokens, not exploits

The way into a SaaS tenant is almost always a credential or a token, building on why credentials are the #1 way in:

Phished employee logins, sometimes with the MFA code captured in real time.
OAuth app consent. This is the SaaS-specific one. A user is tricked into clicking "Allow" on a malicious third-party app requesting broad permissions ("read all your files and email"). No password is stolen, the user granted access. The app now holds a token that reads their data directly, and it survives password changes.
Over-permissioned integrations and vendors. A connected tool or contractor with more access than it needs becomes the way in when it is compromised.

The theme: the attacker ends up holding a valid token with broad read scope. From the platform's view, every request that follows is authorized.

How they drain it: the platform's own APIs

With a valid token, exfiltration is just using the API as designed. SaaS platforms expose rich query and bulk-export endpoints so you can integrate and back up your data, exactly what an attacker wants. The pattern, conceptually:

1. Authenticate with the stolen token.
2. List the objects available (accounts, contacts, files, messages).
3. Page through them in bulk and download.
4. Repeat slowly enough to blend into normal traffic.

We won't write a working exfiltrator, but note how boring it is: authenticate, list, page, download. It's the same code a legitimate backup integration runs. That's the whole problem, the malicious export and the legitimate one are indistinguishable at the request level.

Why it's so hard to spot

It's authenticated traffic. No failed logins, no exploit signatures. Every request is "valid."
It mimics normal integration behavior. SaaS tenants have dozens of apps pulling data all day. One more reader hides in the noise.
The data is centralized. One compromised token can reach an entire org's records, because that's how the platform is meant to work for admins and integrations.

The Canvas/Instructure incident (275 million students' data, including private messages) and the SaaS extortion wave all share this: the value was concentrated in a platform, and access to the platform was the whole game.

What actually defends against it

Since you can't patch "the platform works as designed," defense is about governing access to your SaaS data:

Audit OAuth app grants. Review which third-party apps have access to your tenant and what scopes they hold. Revoke the broad, unused, and unknown ones, this directly kills the malicious-consent path.
Least privilege, everywhere. Most users and integrations don't need org-wide read or bulk-export rights. Scope them down so one stolen token reaches little.
Phishing-resistant MFA on the SaaS logins themselves, to make the tokens harder to steal in the first place.
Watch for bulk-export behavior. The one real signal is volume and pattern: a token suddenly paging through every record, an unusual mass download. SaaS platforms increasingly expose these logs, use them.
Encrypt and minimize. Don't put more sensitive data into a SaaS platform than you must, and use field-level encryption for the crown jewels so an export yields less.

Why this is the lesson that matters

"Securing your data" used to mean hardening your servers. When your data lives in SaaS, it means governing access and permissions in platforms you don't control, because the breach won't be an exploit, it'll be a granted permission used at scale. The shift from "break in" to "log in and export" is the defining data-security story of the year.

Understanding the mechanism, valid token plus the platform's own bulk APIs, makes the defenses obvious: shrink who can read, shrink what they can take, and watch for the one thing that looks different, mass export. Reasoning from the attack to the defense like this is the whole approach of the cybersecurity track.