Bottom line
Cloud intrusions follow trust, not infrastructure. The routes that matter run through stolen identities, SaaS integrations, pipeline permissions and third-party software, and most end in data theft rather than encryption. Defenders who plan for ransomware in the cloud are planning for the minority outcome. Mandiant found ransomware in 3 percent of cloud-related incidents and data theft as the primary goal in 73 percent.
Key judgments
| Judgment | Confidence and basis |
|---|---|
| Cloud intrusions are mostly identity and trust-relationship intrusions. In Mandiant engagements, third-party compromise and stolen credentials each accounted for 21 percent of initial access, vishing 17 percent and email phishing 12 percent. Misconfiguration was 7 percent and vulnerability exploitation 2 percent. | High. Direct incident observation. The listed categories total 90 percent and the source does not account for the rest. |
| The dominant objective is data theft. Data theft was primary in 73 percent of cloud-related incidents. Of all intrusions, 45 percent were silent exfiltration with no immediate extortion and 28 percent were theft with extortion indicators. Business email compromise was 10 percent and ransomware 3 percent. | High. Same dataset. Mandiant’s cases over-represent organizations that called for help. |
| In Google Cloud environments, exploitation of third-party software has overtaken weak credentials as the leading way in. It reached 44.5 percent of observed initial access, while weak or absent credentials fell to 27.2 percent from 47.1 percent. Mandiant also saw cryptominers deployed within about 48 hours of a widely used web-framework flaw becoming public. | Moderate. One provider’s telemetry, covering a subset of observed activity. It should not be read as representative of all cloud platforms. |
| Trust between systems is the path. SaaS integration tokens, hardcoded keys at vendors and pipeline trust to cloud roles let attackers move without a conventional login. | Moderate to high. Several documented campaigns, no prevalence measure. |
| Attackers remove recovery and evidence. They delete logs, snapshots and backups, and in some cases compromise cloud tenants to destroy infrastructure backends. | Moderate. Documented in named incidents, not quantified. |
Six observed paths
| Path | How it unfolds | Evidence | Chokepoint |
|---|---|---|---|
| 1. Integration token to downstream cloud | Stolen OAuth tokens for a third-party app give direct access to a CRM. The actor exports records, then searches them for cloud keys, passwords and warehouse tokens to use elsewhere. | Salesloft Drift campaign, tracked as UNC6395. Google judged the main aim to be credential harvesting. The cause was not a flaw in the CRM platform. | App scopes, source IP enforcement, secrets found inside business data. |
| 2. Pipeline trust to production | A compromised developer account or malicious package yields pipeline access. A trust relationship between the code platform and the cloud account turns that into a cloud role. | Mandiant describes an OIDC trust between GitHub and AWS abused to reach production within 72 hours. Malicious npm packages delivering credential stealers are also reported. | Which repositories and branches may assume which roles. Role permissions. Package controls. |
| 3. Help desk to cloud admin | A vishing call produces an MFA reset or authorizes a data tool. SSO then opens cloud consoles and SaaS tenants. | Vishing was the largest phishing-related vector in cloud and SaaS cases. | Reset verification. New MFA method and new device alerts. |
| 4. Exposed software to workload identity | An internet-facing application flaw gives code execution on a cloud workload and the permissions attached to it. | Rapid exploitation after disclosure of a popular web framework flaw. Third-party software exploitation led Google Cloud initial access. | Patch speed for exposed workloads. Permissions attached to workload identities. |
| 5. Identity control plane abuse | Misconfigurations are used to issue certificates or create admin accounts that bypass MFA, or a rogue federated identity provider is added. | Reported by Mandiant. The joint advisory on Scattered Spider describes the federation technique. | Alerts on identity configuration changes by anyone outside a small, known set. |
| 6. Destruction and denial | Before or instead of extortion, the actor deletes logs, snapshots and backup objects. | Storm-0501 deleting cloud data and backups. Qilin affiliates targeting Veeam backup infrastructure before encryption. | Separate-account backups and logs. Deletion protection. Alerts on retention changes. |
Analysis
The node attackers need is a credential or trust that works without a login event. Google Threat Intelligence observed compromised OAuth tokens enabling bulk data access across SaaS tenants without standard login alerts. Where the access is a token, an API key or a role assumption, detection built around sign-ins has nothing to fire on. The telemetry that matters is query volume, role assumption from unexpected sources and administrative changes.
SaaS and pipelines belong in the cloud estate. Three of the six paths pass through a CRM, a code platform or a vendor. Teams that scope cloud security to the hyperscaler accounts leave the intermediate nodes unmonitored. The vendor holding your hardcoded key is part of your attack path whether or not it appears in your asset inventory.
Planning for the wrong outcome has a cost. A ransomware tabletop assumes visible disruption and a ransom note. The more common cloud outcome is quiet extraction that may never produce a demand. Detecting it depends on logs retained long enough to scope it. Mandiant notes that 90-day retention is insufficient for scoping long intrusions, and attackers delete logs in cloud environments precisely to remove that evidence.
What should change
-
Map paths, not findings. Pick the data store that would hurt most to lose, then walk backwards: which identities, tokens, integrations and pipelines can reach it. Fix nodes that combine reach with exposure first.
-
Put identity, pipeline and backup systems in the highest protection tier. The identity provider, CI/CD platform and backup infrastructure all give an attacker leverage over everything else.
-
Constrain trust between systems. Restrict which repositories and branches can assume cloud roles. Limit connected-app scopes and source IPs. Replace long-lived keys with short-lived credentials.
-
Detect on behavior of trusted access. Useful signals include bulk queries or exports by connected apps, a new federated identity provider, role assumption from an unexpected repository or address, token use from new infrastructure, and any deletion or retention change on logs, snapshots and backups.
-
Protect evidence and recovery from the same accounts that run production. Keep logs and backups in separate accounts with deletion protection.
-
Rehearse a data-theft scenario with no ransom note. Test who notices, how scope would be determined, and which logs would answer it.
Gaps and limits
The figures come from Mandiant engagements and one provider’s observed activity. They describe what responders were asked to investigate, not the whole population of cloud intrusions. Percentages from different datasets cannot be added. Named incidents show that a path is real. They do not show how often it is used.
Next step
Choose one of the six paths and test it against your estate: could an attacker holding that first node reach your most sensitive data, and would anyone see it happen?
Sources
-
Google Cloud: Cloud Threat Horizons Report cloud.google.com
-
Google Cloud, Mandiant: M-Trends cloud.google.com
-
Google Threat Intelligence Group and Mandiant: Data Theft from Salesforce Instances via Salesloft Drift cloud.google.com
-
CISA and FBI: Scattered Spider joint cybersecurity advisory cisa.gov
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.