Detection coverage in DCV across AWS, Azure and GCP for Data from Cloud Storage Object, plus the corresponding Sigma rules in the CloudSigma library. Source data refreshed 2026-04-24.
Adversaries may access data from cloud storage.
Many IaaS providers offer solutions for online data object storage such as Amazon S3, Azure Storage, and Google Cloud Storage. Similarly, SaaS enterprise platforms such as Office 365 and Google Workspace provide cloud-based document storage to users through services such as OneDrive and Google Drive, while SaaS application providers such as Slack, Confluence, Salesforce, and Dropbox may provide cloud storage solutions as a peripheral or primary use case of their platform.
In some cases, as with IaaS-based cloud storage, there exists no overarching application (such as SQL or Elasticsearch) with which to interact with the stored objects: instead, data from these solutions is retrieved directly though the Cloud API. In SaaS applications, adversaries may be able to collect this data directly from APIs or backend cloud storage objects, rather than through their front-end application or interface (i.e., Data from Information Repositories).
Adversaries may collect sensitive data from these cloud storage solutions. Providers typically offer security guides to help end users configure systems, though misconfigurations are a common problem. There have been numerous incidents where cloud storage has been improperly secured, typically by unintentionally allowing public access to unauthenticated users, overly-broad access by all users, or even access for any anonymous person outside the control of the Identity Access Management system without even needing basic user permissions.
This open access may expose various types of sensitive data, such as credit cards, personally identifiable information, or medical records.
Adversaries may also obtain then abuse leaked credentials from source repositories, logs, or other means as a way to gain access to cloud storage objects.
Platforms: IaaS, Office Suite, SaaS.
DCV maps 108 detections across 3 cloud providers to T1530. Coverage by source:
| Source | Cloud | Findings mapped | Avg confidence |
|---|---|---|---|
| AWS Config Rules | AWS | 36 | 0.79 |
| AWS Security Hub | AWS | 24 | 0.83 |
| AWS Macie | AWS | 14 | 0.90 |
| Azure Policy | Azure | 10 | 0.89 |
| AWS GuardDuty | AWS | 8 | 0.90 |
| Microsoft Defender for Cloud | Azure | 8 | 0.92 |
| Azure Regulatory Compliance | Azure | 4 | 0.95 |
| GCP Security Command Center | GCP | 3 | 0.87 |
| GCP Chronicle | GCP | 1 | 0.90 |
CloudSigma ships 3 production-ready Sigma rules that detect T1530 across 3 platforms. Every rule below is validated against its source SIEM dialect before publication.
High-fidelity detection of T1530 requires correlation
across multiple events. For example, a credential-validation call
followed by a reconnaissance chain (List* /
Describe*) within a short window from an unfamiliar
source. A single-event Sigma rule on
GetCallerIdentity alone fires constantly on
legitimate CLI, SDK and CI/CD activity.
Where you have a specific advisory, vulnerability disclosure or blog post that exercises T1530-style abuse, CloudSigma can generate a starting-point rule from that input. You then deploy it in your SIEM and combine it with the SIEM's native correlation features (timeframe joins across users, source-IP anomalies, impossible-travel checks). For T1530 specifically the generated rule is rarely sufficient on its own; pair it with the SIEM-side correlation logic before enabling in production.