Data From Cloud Storage
Adversaries target cloud storage to achieve two primary goals: steal credentials and exfiltrate or destroy sensitive data for ransomware operations.
#4
Overall Rank
5.5%
Customers Affected
659
Threats Detected
Why do adversaries abuse data from cloud storage?
Most often, a business’s “crown jewels” are the data that exists all throughout the enterprise, which is ever shifting to the cloud. If adversaries are not directly defrauding companies through business email compromise or other direct payment schemes targeting cloud-hosted systems, they target cloud storage. Adversaries may be directly hunting for credentials in cloud storage—API keys, access tokens, passwords, and others—that they can either use themselves or sell. They also target sensitive organizational data for exfiltration and ransomware operations, demanding payment in exchange for not releasing stolen data or for restoring access to destroyed resources.
The reason adversaries target credentials in cloud storage is simple: it’s much easier to log in than to hack in. Rather than investing resources in developing sophisticated exploits or bypassing advanced security controls, threat actors recognize that credentials are ubiquitous across cloud storage environments. Configuration files, backup archives, source code repositories, infrastructure-as-a-service (IaaS) snapshots, and development artifacts regularly contain hardcoded credentials, access keys, and authentication tokens. A single exposed AWS S3 bucket or Azure Storage block can yield valid credentials.
The reason adversaries target credentials in cloud storage is simple: it’s much easier to log in than to hack in.
How adversaries abuse data from cloud storage?
Goal 1: Credential theft for brokering access
The most common adversary goal is to discover and extract credentials from cloud storage. This represents a lower-effort, high-reward attack pattern that has fueled the growth of initial access brokers—threat actors who specialize in obtaining and selling access to compromised environments.
Storage that may contain credentials includes:
- Configuration files: Application config files containing database passwords, API keys, and service credentials
- Infrastructure-as-code repositories: Terraform state files, Ansible playbooks, and CloudFormation templates with embedded secrets
- Backup archives: Complete system backups containing credential stores, SSH keys, and certificate private keys
- Development artifacts: Source code repositories with hardcoded credentials,
.envfiles, container images, and credential caches - Virtual machine (VM) snapshots and disk images: Filesystem snapshots containing credential stores, browser password databases, and SSH keys
- Log files: Application logs inadvertently capturing authentication tokens or credentials
- SaaS applications: Services such as GitHub, Jira, Slack, Teams, Confluence, Google Workspace or other productivity applications that may contain sensitive conversations where users share credentials
This attack pattern requires minimal infrastructure and technical sophistication. Adversaries use automated scanning tools to discover publicly accessible storage accounts, then employ simple scripts to search for common credential patterns—AWS access keys, Azure connection strings, database passwords, and API tokens. This attack pattern is so prevalent that there are entire repositories dedicated to tracking these types of incidents over the past decade.
Goal 2: Data exfiltration and ransomware operations
The second adversary goal builds on the first: using compromised credentials to access, exfiltrate, and potentially destroy sensitive organizational data for financial extortion. This pattern has evolved significantly with the rise of cloud-based ransomware, where adversaries leverage cloud-native capabilities rather than deploying traditional encryption malware.
Threat actor group Storm-0501 exemplifies this evolution. The group transitioned from traditional on-premises ransomware operations to sophisticated cloud-based attacks that combine data exfiltration with data destruction. Their campaigns demonstrate how adversaries target cloud storage.
How traditional ransomware operations evolved to cloud-based extortion
Cloud storage services are designed for massive scale and rapid data transfer—exactly the features adversaries exploit during exfiltration operations. In Storm-0501 campaigns, the threat actor uses AzCopy, Microsoft’s own command-line utility for efficient data transfer, to quickly exfiltrate large volumes of sensitive data to adversary-controlled infrastructure within Azure. This approach provides several advantages for threat actors:
- Speed: Cloud-native transfer tools enable exfiltration of large volumes of data quickly.
- Legitimacy: Using native cloud tools like AzCopy, Azure Storage Explorer (ASE), aws-cli, and gsutil makes malicious activity blend with normal operations.
- Minimal footprint: No malware deployment required, reducing detection opportunities.
When protections like Azure resource locks or immutability policies prevent deletion, the threat actor adapts by encrypting storage accounts with customer-managed keys, such as SSE-C in AWS, which prevents recovery by the cloud service provider. The flexibility of cloud platforms that benefits organizations equally serves adversaries who understand how to manipulate cloud-native features for destructive purposes.
How do they achieve these goals?
How adversaries obtain access to data from cloud storage
1. Establish access
1. Establish accessAdversaries obtain cloud storage access through common cloud attack patterns:
Initial access
Hybrid identity exploitation: Storm-0501 compromises on-premises Active Directory environments, then pivots to cloud by exploiting Microsoft Entra Connect Sync servers. These hybrid identity synchronization systems bridge on-premises and cloud environments, providing adversaries a pivot point.
Exposed credentials
Adversaries may purchase credentials from other access brokers or otherwise exploit exposed credentials in public spaces.
Reconnaissance
Adversaries may leverage enumeration tools like AzureHound to document available and utilized storage services. This allows them to then narrow down the subsequent steps to limit the chance of detection.
Privilege escalation
After gaining initial cloud access, adversaries attempt to escalate privileges to Global Administrator (Entra ID) or other admin roles, providing unrestricted access to storage resources.
Access key theft
Using privileged roles, adversaries extract storage account access keys via API actions, enabling direct storage access.
2. Prepare for exfiltration
Adversaries may modify storage configurations to enable data theft. The most common method is to enable public access. This can be done directly with access control policies or it may take the form of network changes such as security rule changes or disabling firewalls.
Though, as defenders become more familiar with this technique, adversaries may only allow access to third-party cloud environments that they control. This allows them to evade detection in large environments where cross-account sharing is more common. Furthermore, they may have to remove immutability locks on the data before they can modify lifecycle rules or otherwise encrypt the data for impact.
3. Get the goods
Using compromised credentials and modified configurations, adversaries leverage native tools for mass exfiltration. For example, Storm-0501 uses AzCopy to rapidly transfer Azure Storage data.
To maximize extortion leverage, adversaries systematically destroy recovery options:
- Primary data deletion: Mass-delete storage accounts, S3 buckets, or cloud storage buckets
- Backup destruction: Target Azure Recovery Services vaults, AWS backup vaults, or snapshot repositories
Sometimes, adversaries may simply exploit misconfigurations in cloud environments and access data from unintended public access. This has become so common that there are several lists dedicated to documenting publicly accessible cloud storage.
Comparison of data from cloud storage theft across platforms
This technique primarily applies to any cloud provider that offers the ability to store data on the platform, with AWS, Microsoft Azure, and Google Cloud Platform (GCP) being the main providers. Below are the platforms and a non-exhaustive list of potential services that may be targeted by adversaries.
| Platform | Services |
| AWS | S3, EBS, EFS |
| Azure | Azure Storage: Blob, Table, Queue, File, disk snapshots |
| GCP | Google Cloud Storage, disk snapshots |
Beyond the major cloud service providers, SaaS applications present another major risk for storing sensitive data. The Salesloft Drift compromise in 2025 highlights that access credentials that are stored for third-party integrations are a prime target for adversaries and that all threat vectors should be considered.
Prevention techniques generally fall into the same two goals that the adversaries target:
- Protect credentials.
- Implement data loss prevention (DLP) for sensitive business data.
Protect credentials
The most effective defense against credential theft is ensuring credentials never enter cloud storage.
Adopt secrets management solutions
Use AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or 1Password instead of storing credentials in configuration files or code. Applications retrieve credentials programmatically at runtime rather than storing them in storage accounts.
Enable short-term credentials
Wherever possible, enable short-term credentials that get refreshed in short intervals. This will help limit the amount of time an adversary has access to a cloud environment.
Scan for exposed credentials
Implement automated scanning to detect credentials in cloud storage:
- Pre-commit hooks: Scan source code for credentials before committing to repositories.
- Storage scanning: Use tools like git-secrets, TruffleHog, or cloud-native solutions (Azure Defender for Storage, AWS Macie) to scan existing storage for common credential patterns. Refer to Data from Information Repositories for a robust list of credential locations.
- Continuous monitoring: Regularly scan storage accounts for newly uploaded files containing credentials.
- Remediation workflows: Automatically rotate or revoke credentials discovered in storage.
Infrastructure-as-code (IaC) security
For IaC deployments, avoid embedding credentials in state configuration files. Use cloud provider parameter stores for secrets in CloudFormation, ARM templates, or Terraform so you can implement runtime secret availability rather than hardcoded values. Finally, scan IaC repositories and state files for embedded credentials.
In reality, it is not feasible to successfully remove all credentials from your environments. Adversaries, if persistent enough, will always find a way to harvest them. Therefore, beyond all the above techniques to prevent credential disclosure, it is imperative to properly adhere to zero trust principles and defense-in-depth strategies to ensure that when compromises happen they have a limited time duration and blast radius.
Prevent data exfiltration and ransomware
A sufficiently persistent adversary may bypass most security controls. However, below are some suggestions for good strategies to limit or otherwise make adversary goals more difficult for ransomware and extortion campaigns.
Immutability protections
Storm-0501 could not delete storage accounts protected by immutability policies, forcing the adversary to resort to encryption attacks:
- Azure: Implement immutability policies on Blob Storage with appropriate retention periods; enable version-level immutability for granular protection.
- AWS: S3 has several options to protect data, such as Object Lock and versioning.
- GCP: Enable bucket retention policies and object versioning.
Backup segregation
Store backups separately from production storage:
- Use different cloud accounts or subscriptions for backup storage.
- Apply separate IAM policies so production access doesn’t grant backup access.
- Implement Azure Blob backup, AWS cross-account replication, or GCP bucket snapshots to protected projects.
- Enable soft-delete for Azure Key Vaults to prevent encryption key deletion (90-day retention).
Note: The visibility sections in this report are mapped to MITRE ATT&CK data components.
Cloud storage logs
The most direct information related to protecting storage material are cloud storage logs. These will typically detail who accessed, what, and when. However, these logs can be incredibly voluminous and if enabled for the entire environment may be prohibitively expensive. While the logs can directly link activity to specific data, there is also significant noise.
Cloud service logs
These logs will typically detail less common but incredibly impactful API commands that will directly relate to data storage in a cloud environment. Cloud storage logs detail the activity for each piece of data but cloud service logs will detail general settings for the entire service, like S3. This can be incredibly useful because this is where public access changes are typically identified or the attempted removal of DLP. These signals are more common to surface compared to storage logs.
Building robust detections for cloud techniques relies heavily on building a consistent and clear narrative for the activity. Head over to our blog to understand our philosophy around building cloud detections.
Detection of the entire attack chain covers several techniques. For activity surrounding the precursor steps through establishing access, you can refer to the Cloud Accounts technique page. After an adversary establishes access, detection should then be focused on collection techniques before actual exfiltration. As always, detections at the impact stage should be the last line of defense. Defenders should always strive to move detection left of boom.
Reconnaissance
Unless the adversary has some pre-knowledge of the environment and is very targeted with their exfiltration, they most likely will have to canvas the environment for which storage they want to target. We regularly see opportunistic adversaries script out how they search for available storage resources. Most often this is for credential access, and then they might move into ransomware or extortion if the opportunity exists.
Overall, reconnaissance activity is too difficult to isolate to build robust detections. CI/CD pipelines, configuration management, and other automations can mimic adversary reconnaissance and may overload analysts with false positives. However, this activity can help build the threat narrative once more effective alerts have been triggered.
Activity will be related to Get/List/Describe events surrounding the services discussed above. This activity may be very high in volume if the adversary is not attempting to be stealthy. Looking at anomalous spikes of read events related to storage accounts can be helpful for detection if you have a good understanding of environment baselines.
Staging
This part of the threat narrative provides the best place for detections, as it is most often less pervasive than reconnaissance events and it is before the impact phase of the attack. This type of activity revolves around manipulation of storage resources to allow the adversary to exfiltrate or delete the desired data.
Modify storage access
Adversaries will most commonly attempt to enable public access to storage services to then exfiltrate the data. In AWS this may take the form of a PutBuckPolicy command to modify the policy to allow access from anywhere. There could also be modifications of network access rules to allow full internet access. This type of activity should be closely monitored and should be tied to maintaining knowledge if existing security controls are properly implemented.
Beyond full public access, adversaries may attempt to be more subtle and only share access with specific accounts that the adversary controls. For high-value data, any modifications to existing security controls should be closely monitored.
For data destruction or ransomware campaigns, pay specific attention to DLP policies:
- In AWS, this can take the form of modifications to lifecycle policies to automatically rollover data in very short timespans.
- In Azure, it could be the modification of resource locks to remove the immutability of resources to allow deletion.
Having a robust understanding of how your environment leverages backups and DLP should inform where to target detections as that will, therefore, reduce false positives in alerts.
Combine activity
Detection in cloud environments can be dramatically improved by chaining certain types of activity together in sequences. This allows for tighter detections that can cut through the noise of very large environments. Building detections that combine both the reconnaissance and stage activity together can make it much easier for the analyst to make informed assessments. Baking in the threat narrative directly into the alerts themselves can reduce investigation steps that are required to determine if the activity is malicious.
Continuous testing should focus on the two main branches of adversary activity related to data from cloud accounts.
Credential scanning
Numerous tools can be configured to scan various data sources for unsecured credentials. It is relatively simple to test the accuracy of these, by simply injecting credential materials into these data sources and verifying the alerts. One way to improve this is to purposely inject canary credentials to trick adversaries into using them and therefore providing high-quality alerts for your analysts.
DLP verification
Continuous monitoring and testing of DLP implementation is critical to preventing ransomware activity. Measuring the time it takes to respond to an alert being triggered is paramount to fortifying your defenses. In the cloud things move fast, adversaries frequently script out activity or leverage batch processing to increase speed. The time between precursor alert and impact should be closely monitored and understood to build robust playbooks around response and remediation. More so than other techniques, Data From Cloud Storage is a holistic approach between environment baselines, preventions, security controls, detections and remediations. Luckily, it can be quite straightforward to perform purple team exercises to test the whole lifecycle at once. These can be regularly performed as you might for any other disaster scenarios.