Data extortion has split away from ransomware. The attacker’s leverage is the stolen data and the pressure on people, not locked systems. Backups answer the wrong question.
Key judgments
Observed means a named source reported it. Assessed means it is our reading of that evidence.
| # | Judgment | Confidence |
|---|---|---|
| 1 | Extortion campaigns now run in cloud and SaaS environments without encrypting anything. Theft, and in one case deliberate destruction, is the lever. (Observed) | High |
| 2 | Pressure is applied to individuals, and sometimes long after the theft. Demands have gone directly to employees months after the data was taken. (Observed, one tracked campaign) | Medium |
| 3 | Stolen data is also intrusion input. Actors search it for credentials and secrets, so one theft can seed the next compromise. (Observed) | Medium |
| 4 | Most victims now decline to pay, so the quality of your evidence about what was taken matters more than your payment stance. (Assessed) | Medium |
The context
Verizon’s latest Data Breach Investigations Report finds ransomware present in 48% of breaches, with ransom payments shrinking and businesses often choosing not to pay. WaterISAC’s summary of the same report puts the share of victims who declined to pay at 69%. The report is breach data, not extortion-specific data, so it shows the direction of travel rather than the size of the extortion market.
Attackers have adapted to that. The campaigns below do not depend on a victim paying to get systems back.
Observed patterns
| Pattern | What happens | Reporting | Where defenders can see it |
|---|---|---|---|
| Cloud destroy-and-extort | After taking over identity, the actor exposes storage, copies data with AzCopy, then deletes snapshots, restore points and backup containers, removing locks and immutability settings first. Contact came through Microsoft Teams from a compromised account. | Microsoft analysis of Storm-0501 | Resource Manager activity, storage key retrieval, public-access changes, bulk egress, deletion operations. |
| Social engineering into SaaS, delayed extortion | Voice phishing persuades an employee to authorize a malicious connected app, often a renamed Data Loader. Data is exported in bulk. Extortion by a separate cluster followed months later, with a 72-hour bitcoin demand aimed at employees. | Google Threat Intelligence Group, UNC6040 and UNC6240 | Connected-app authorizations, API-enabled users, large exports, logins from VPN and Tor exits. |
| Integration-token theft and secret mining | Stolen OAuth tokens from a third-party app were used to export records from many Salesforce orgs. The actor counted records first, then exported, then searched the data for AWS keys, passwords and Snowflake credentials. Google assessed the aim as credential harvesting. | Google Threat Intelligence Group, UNC6395 | Connected-app activity, unique-query events, bulk exports from the integration user. |
The Storm-0501 case is the clearest break from the ransomware model. Microsoft describes an actor that steals and destroys cloud data rather than encrypting endpoints. Where Azure resource locks or immutability policies blocked deletion, the actor removed those protections first. Where Key Vault soft-delete limited the damage from deleting an encryption key, recovery was possible. A control that a single role can switch off protects less than it appears to.
Why backups and endpoint tooling do not answer this
Backups restore availability. Extortion on stolen data is a confidentiality event, and a perfect restore changes nothing about what the attacker holds. Where recovery is part of the attack, backups can be the target. Endpoint detection sees workstations and servers. A bulk export through a SaaS API, or a copy from a storage account using a retrieved access key, may never touch a monitored host.
The harder problem is proof. When a message arrives claiming your customer records, the first question is whether it is true. Actor claims are not evidence; Google’s analysis notes the extortion messages claimed a well-known group’s name while assessing that a separate actor may be monetizing the data. Only your own logs can say what left, and only if they cover the right systems for long enough.
What defenders should change
-
Instrument data movement, not only intrusion. Collect and alert on bulk API exports, new connected-app authorizations, storage access-key retrieval followed by large egress, and changes that make storage public.
-
Govern export power. Limit who holds API-enabled and data-export permissions, require approval for connected apps, and restrict app and user access to trusted IP ranges. These are the controls Google recommends after the Salesforce campaigns.
-
Treat recovery as a target. Use immutable storage, resource locks, purge protection and a backup administration identity that is separate from production admins, as Microsoft recommends. Alert on deletion of snapshots and restore points.
-
Retain logs longer than the extortion delay. If demands can arrive months after the theft, a retention window shorter than that leaves you unable to scope the loss. Check what each SaaS license tier actually retains.
-
Decide before the demand. Agree who handles contact, who verifies claims, who talks to legal and regulators, and what staff should do if they receive a direct threat. Employees who are contacted personally should report, not respond.
-
Scan your own data for secrets. Credentials sitting in support cases, tickets and CRM notes are what actors mine after theft. Find and rotate them before someone else does.
Hunting hypotheses
-
A user or integration that exports far more records than its normal pattern, preceded by a count-style query.
-
A connected app approved by a user who does not normally administer integrations, close to a help desk or IT-support call.
-
Storage account key retrieval followed by sustained outbound transfer.
-
Deletion of snapshots, restore points or backup containers, particularly where a lock or immutability policy was removed just before.
What we do not know
There is no reliable count of extortion incidents. Leak sites show only the victims who refused or were posted; many never appear. Payment data is incomplete. The campaigns above are the best-documented ones and may not represent the typical case. Attribution among the actor clusters is itself uncertain, as the vendors say.
What to do with this
Ask your incident lead one question: if a message arrived tomorrow claiming your customer data, how quickly could you say from your own logs what was taken and what was not? The gap between that answer and “within hours” is the work to do.
Sources
-
WaterISAC, Summary of Verizon’s Data Breach Investigations Report
-
Microsoft Security Blog, Storm-0501’s evolving techniques lead to cloud-based ransomware
-
Google Cloud Threat Intelligence, UNC6040 voice phishing and data extortion analysis
-
Google Cloud Threat Intelligence, Data theft from Salesforce instances via Salesloft Drift (UNC6395)
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionDetect, Respond & RecoverSpot attacks early and get back to business fast.See how we work →Related service
Threat Intelligence
Use this to improve threat-informed security decisions.