Detecting T1530 Data from cloud storage

How T1530 data from cloud storage shows up in your environment

T1530 Data from cloud storage is the Collection technique (TA0009) in which an adversary gathers data of interest from cloud storage services, such as object buckets, file shares hosted by a cloud provider, or document libraries in SaaS applications. It matters because these stores often hold much of an organization's most sensitive material, and the reads that move that data frequently resemble ordinary application or user traffic. The SOC lead's problem is not whether the technique exists but whether the organization can tell a legitimate bulk read from a collection step before data leaves the environment. This page targets Enterprise ATT&CK version 20.0, so mappings should be checked against that version before they are tuned.

In ATT&CK terms, the technique spans three places where the data sits. On IaaS, the reads land on object and file storage that the cloud provider's control plane and data plane both record. In Office Suite tooling, collection happens against shared document repositories and mail or file stores tied to user identities. In SaaS, the same pattern appears in collaboration and file platforms where access is granted through tokens, connected apps and sharing links. Each platform writes different records, so your first decision is which of these three you can actually see. Confirm with your cloud and SaaS teams which access logs are enabled, where they are retained, and whether they reach your SIEM at the level of individual object or file reads rather than only administrative events.

The practical check is to inventory which storage accounts, buckets, drives and SaaS workspaces hold regulated or high-value data, then confirm that read-level logging covers them. Ask whether the identities that read those stores are service accounts, human users or both, because a collection pattern from a service identity looks different from a person opening files. Treat sudden growth in read volume, reads from identities or locations that do not normally touch a store, and bulk listing followed by large downloads as the conditions worth a closer review. Plan for gaps: if read events are sampled, delayed or not logged for a platform, record that as a risk to accept or remediate, not as a detection you have.

Which telemetry reveals cloud storage collection

This table maps each detection data component to the platform where it appears, the signal to look for and the open-source collector that gathers it. Read it as a coverage checklist: a row is only useful if the provider's audit logs and network sensors actually reach your SIEM. Most cloud storage signals depend on forwarded provider audit logs, so confirm that coverage before relying on any row.

Data component and platform	Signal to look for	Open-source collector	Dependency to confirm
User Account Authentication on IaaS and SaaS identity	Sign-ins to storage consoles or APIs from unfamiliar locations, devices or service principals, followed by bulk object listing	Wazuh with cloud integrations or a log shipper feeding Wazuh or Security Onion	Identity provider sign-in logs are forwarded and retained with user, client and source address fields
Cloud Storage Access on IaaS object storage	Large numbers of object read or list events from one identity in a short window, or reads of buckets that identity rarely touches	Wazuh or Security Onion ingesting the provider's storage audit trail	Data access logging is enabled for the storage service, which many providers leave off by default
Cloud Storage Access on office suite and SaaS file platforms	Bulk download, sync or share-link creation events by a single user or app token, especially outside working hours	Wazuh ingestion of SaaS audit logs through API collection	Audit log retention and API access for the tenant are enabled, and the plan tier includes the events you need
Network Traffic Content on egress paths	Sustained transfers to storage endpoints from hosts that do not normally use them, visible in decrypted or metadata-level content	Zeek and Suricata inside Security Onion, with TLS metadata and HTTP logs	Sensors see the egress path, and you know whether TLS is inspected, since encrypted payloads limit content visibility
Network Connection Creation to storage endpoints	New connections from workstations or servers to object storage or file sync hosts, with unusual byte volumes	Zeek connection logs in Security Onion, forwarded to Wazuh for correlation	Your DNS and proxy logs resolve storage hostnames, and you maintain an allowlist of expected storage endpoints
Command Execution and Process Creation on hosts running sync or CLI tools	Storage command-line or sync clients launched by unexpected parent processes, or run against many paths	Wazuh endpoint agent process telemetry, and Velociraptor for hunts on hosts	Endpoint agents cover the hosts in scope, and command-line arguments are captured in your configuration
Audit log integrity and forwarding	Gaps in provider audit streams, disabled logging or changed retention settings	Wazuh rules on provider configuration change events, and health checks on log sources	Someone owns alerts for missing log sources, because silent forwarding failures hide every row above

Detection ideas for bulk cloud storage reads

T1530 rarely shows up as a single malicious event. It shows up as an identity or workload reading far more objects, at unusual times or places, and then moving that data somewhere new. The cards below describe detection concepts in words, with thresholds you must set against your own baseline and the false positives you should expect to suppress.

Unusual volume of object reads

Count object or file reads per identity over a fixed window, such as an hour, and compare each identity against its own rolling history rather than a single global number. The logic is simple: a service account that normally reads a few hundred objects a day and suddenly reads tens of thousands is worth a look. Tune the multiplier and minimum count to your baseline and review the top talkers first. Expected false positives: backup jobs, analytics pipelines, search indexers and data migrations, which should be tagged by identity so they can be excluded deliberately.

Reads from identities without a baseline

Flag storage read activity from an identity or host that has no prior record of touching that bucket, container or share within your lookback period. New workloads are common after deployments, so the signal is strongest when the new identity reads sensitive containers or reads in bulk on first use. Confirm the lookback length with your storage audit logs before relying on it. Expected false positives: newly provisioned applications, scaling events and onboarding of new analytics tools.

Access outside normal hours or regions

Compare read events against each identity's usual working hours, source regions and network paths. A reporting account that has only ever read storage during business hours from one region is a poor fit for large reads at 03:00 from an unfamiliar country. Define the allowed windows per identity class, not per organization, because batch jobs and follow-the-sun teams break simple rules. Expected false positives: scheduled batch windows, travelling staff and failover to another region during an incident.

Reads followed by unfamiliar egress

Correlate a burst of storage reads with outbound transfers from the same identity or host within a short window, and flag destinations that are not on your known list of partners, SaaS endpoints or internal networks. Network Traffic Content and Network Connection Creation telemetry help here, but confirm what your sensors can see when traffic is encrypted. Treat the correlation as a lead for investigation, not proof of exfiltration. Expected false positives: approved backup targets, content delivery to customers and vendor file exchanges.

Storage policy and audit gaps

Watch for changes that make bulk reads easier to hide or harder to see, such as disabled object access logging, new public access grants, or broadened bucket policies. These changes sit upstream of the reads and often show up before any unusual volume does. Compare the current configuration with your approved baseline on a schedule. Confirm with your cloud provider which control plane events are logged and retained for your account. Expected false positives: planned migrations, new public content sites and infrastructure-as-code changes that have not yet been reviewed.

How to validate the T1530 detection in a lab

This sequence proves that the T1530 detection fires on a controlled, approved access pattern against cloud object storage, and it records what the team saw, when it saw it and which telemetry was missing. The output is a repeatable test record that the team can rerun after every rule change.

Define the scenario and approval scope
The detection owner and the cloud platform owner agree in writing on one scenario, the storage accounts or buckets in scope, the identity used for the exercise, and the time window. Sign-off also covers which test data is synthetic and where the range boundary sits. The step is done when the scenario sheet is approved and every in-scope resource is tagged as belonging to the exercise, so no production data is involved.
Prepare the identity and storage scope
The team creates a dedicated test identity with access limited to a seeded set of synthetic objects, such as sample files with planted markers that are easy to search for in logs. The owner confirms which access policies, sharing settings and network paths apply, and records them so the expected behavior is known before the test. The step closes when the baseline configuration is exported and stored with the test record.
Write the expected log events in advance
Before anything runs, the analyst writes down which events should appear for the scenario, mapped to the telemetry the detection depends on: cloud storage access records, user account authentication events, and network traffic content or connection records where the platform provides them. Each expected event lists the source, the fields that should be populated and the Sigma or Wazuh rule expected to fire. The step is complete when the list is reviewed by a second analyst and frozen with a version number.
Execute the approved access pattern
A designated operator performs the agreed access pattern against the seeded objects, following the written scenario and nothing beyond it. The operator logs the start and end time of each action in the exercise log, and an observer confirms each action on the storage console. The step closes when the operator signs the log and the exercise identifiers match the tags on the test resources.
Record alert timing and populated fields
The analyst compares the exercise log with what reached the SIEM and the alerting pipeline, such as Wazuh or Security Onion. For each expected event, the analyst records whether it arrived, the delay between action and ingestion, the time the rule fired, and whether key fields like user, source address, object name and authentication method were populated. The output is a results table with pass, partial or fail for each event.
Document telemetry gaps and false positives
Any expected event that was missing, delayed beyond what the detection can tolerate, or stored with empty fields becomes a telemetry gap with an owner and a remediation note, such as enabling a logging category or fixing a parser. The analyst also notes any alert that fired on unrelated activity during the window. The step is done when every gap has a ticket and every noisy alert has a documented reason.
Set pass criteria and repeat after rule changes
The team judges the run against the pass criteria agreed in step one, which should name the events that must alert, the fields that must be present and the maximum acceptable ingestion delay. After any rule, parser or logging change, the same scenario is rerun on the same ATT&CK version the mapping targets, and the results are compared with the previous record. The step closes when the new run is filed, the change is linked to it, and the detection owner accepts the result.

Mitigations that limit what can be collected

Cloud storage collection succeeds when data is readable, reachable and unlogged. The cards below cover the two primary ATT&CK mitigations for this page, Encrypt Sensitive Information and Audit, followed by the identity and training mitigations that also map to Collection techniques.

Encrypt sensitive information at rest

Encryption at rest (mitigation M1041, Encrypt Sensitive Information) limits what an adversary gets from a stolen or copied bucket, share or document library, because the stored objects are unreadable without the key. For T1530, check which storage services hold regulated or sensitive data, whether keys are managed by the customer or the provider, and who can read the key material. Encryption does not stop an authenticated identity from reading data through the normal API, so pair it with access controls. Evidence to keep includes the encryption configuration per bucket or volume and key access logs.

Audit storage access events

Audit (mitigation M1047) is the control that produces the evidence for T1530 detection. Enable object-level or data-access logging on every cloud storage service in scope, and confirm that logs leave the tenant or account into a store the storage administrators cannot edit. Without object-level records, a collection event may appear only as a generic login. Ask each platform owner which data-access events are recorded by default and which need explicit enablement, and test that a read of a sensitive object produces a record.

Limit identities that can read storage

User Account Management (M1018) reduces the number of accounts that can reach cloud storage at all. Review which service accounts, applications and staff roles hold read permissions on sensitive containers, and remove standing access that is no longer used. Stale accounts and broad roles are the most common reason a single compromised identity can enumerate large amounts of data. Confirm the review cadence and the owner of each storage role in writing.

Require multi-factor authentication

Multi-factor Authentication (M1032) is mapped to Collection techniques in ATT&CK, and for T1530 it raises the cost of using a stolen password to sign in to a storage console or SaaS suite. It does not protect data already reachable by a token that was issued before enrollment, so check token lifetimes and session revocation. Confirm that administrator and service paths are covered, not only the user sign-in page, and that exceptions are recorded.

Train users on sharing risks

User Training (M1017) is also mapped to Collection techniques. For T1530, staff who create public share links or move files to personal accounts can expose data without any attacker tooling. Training should cover approved sharing methods, how to report unexpected access notices, and what to do with a link that was shared in error. Ask the training owner to record completion and to tie the content to the sharing settings your platforms actually allow.

Triage steps when a storage read alert fires

The first task is to decide whether the read was legitimate, and that decision rests on three checks: the identity, the source host and the data touched. Confirm the calling identity against the owning team's change records and expected workload, including whether it is a human user, a service principal, an instance role or a SaaS integration token. Next, check the source: the IP address, cloud region or network path, and whether the client is a managed device or a known automation runner. Then establish what was actually read, using object keys, bucket or container names, SharePoint or Drive site identifiers and the sensitivity labels or classification tags on those items. A read of public marketing assets by a known service account is a very different event from a bulk read of customer exports by an interactive user at an unusual hour. Record each answer in the case notes as it is confirmed, because the scoping and escalation steps depend on them.

Scoping means working out the full set of objects or sites the identity touched during the suspicious window, not only the object that triggered the alert. Pull the provider's storage access logs and the identity provider's sign-in logs for the same principal, and compare the read volume, object count and time pattern with its normal baseline. Look for listing operations that precede reads, since enumeration often comes first, and for reads that cross into storage the identity has never used before. Preserve the evidence before changing anything: export the relevant provider and platform logs, including control plane events, data access logs where enabled, sign-in and token issuance records, and any proxy or firewall logs for the source address, to write-once storage with hashes recorded. Confirm with each provider which log categories are on by default and which must be enabled ahead of time, because data access logs are often not retained at the detail you need. Containment should be proportionate: revoke or rotate the credential or session if compromise is plausible, restrict the storage policy or bucket access for the affected principal, and block the source where it is clearly hostile, while avoiding changes that would destroy the evidence or break a business process without an owner's agreement. Escalate to incident response when the identity cannot be explained, when personal, regulated or contractually restricted data was read, or when exfiltration is likely. Bring in legal and privacy counsel early when personal data may have left the environment, because notification clocks are set by the organization's obligations and not by the technical team.

Rehearsing T1530 detection in a private cyber range

The IaaS range should mirror your cloud account structure with a dedicated sandbox account or subscription, a private network segment and no routes to production data. Seed it with synthetic buckets or containers that hold clearly fake records (for example, illustrative customer rows with test identifiers), plus a service identity and a human test identity with scoped read permissions. The facilitator then runs injects at a conceptual level, such as a burst of object reads from an unfamiliar identity, reads from a source network the team has not seen before, or a large number of objects listed in a short window. Good detection means the cloud control plane audit records and the storage access logs reach the SIEM quickly, and an alert on unusual read volume or unfamiliar identity fires within the agreed window. Good triage confirms the identity, the source, and whether the activity matches a change ticket. Good containment revokes or disables the identity, restricts the bucket policy, and preserves logs.

Topology: a sandbox account, a private VPC or virtual network, and a Wazuh or Security Onion collector receiving cloud audit logs.
Decoy data: synthetic objects tagged so that any read is attributable to a test run.
Identities: one service role and one user role, each with read-only access to the decoy bucket.
Injects: bulk reads, listing sweeps and reads from an unrecognized network source.
Measures: time from the first read to alert, triage notes quality, and time to revoke access.

Confirm with your platform team which cloud audit and storage access logs are enabled by default in your provider and which require explicit configuration.

Questions detection engineers ask about T1530

How do I baseline normal read volume on cloud storage?

Start by measuring read activity per identity, per bucket or container and per hour over a period that includes normal business cycles, such as month-end reporting and scheduled batch jobs. Most teams find that a small set of service accounts produces most of the reads, so baseline those identities separately from interactive users. Use percentiles rather than averages, because averages hide the bursts you are looking for. Record which applications, backup jobs and analytics pipelines are expected to read large volumes, and tag them so they can be excluded or handled with separate thresholds. Re-baseline after major changes such as new applications, migrations or retention policy updates, because a stale baseline produces either noise or blind spots. Confirm the exact audit fields your provider emits before you build thresholds on them.

Do Sigma rules cover cloud audit log sources for storage access?

Sigma has community rules for several cloud audit sources, but coverage varies by provider and by log type, so check the rule repository against the exact logs you collect. Treat any community rule as a starting point that needs your field names, your service account naming and your thresholds. Confirm the Sigma log source definitions your pipeline uses map correctly to your cloud audit feed, because a rule that loads without error can still match nothing. For T1530, look for rules that combine storage read or list events with unusual identity, source network or volume. Where no suitable rule exists, write a custom one in Sigma and convert it to your SIEM query language, then test it against recorded events in a cyber range.

How do I separate backup and replication reads from collection?

Backups and replication generate high read volume from privileged identities, which is why they resemble collection in raw telemetry. Separate them by identity, by source network or workload, by schedule and by target location. Maintain an inventory of backup service accounts, their expected source addresses and their job windows, then alert on reads that fall outside those attributes. Be cautious about excluding backup identities entirely, because attackers who compromise a backup credential gain the same read access. A useful pattern is to allow the expected job pattern but alert when the same identity lists or reads containers it has never touched, or when reads occur outside the job window. Document the decision logic so auditors and responders can see why an event was suppressed.

Which fields should I normalize across cloud providers?

Normalize the fields that answer the same investigative questions: who acted, from where, against which resource, what action, when, and with what result. In practice that means mapping identity, source IP, user agent or client application, resource name, operation, timestamp and success or failure into one schema. Keep the original provider field names alongside the normalized ones so responders can verify the mapping. Pay particular attention to how each provider represents service principals, federated users and anonymous or public access, since these are common gaps. Document the mapping in version control, and test it with known events from each provider. Confirm with each provider which audit log categories must be enabled to capture storage read and list operations, because some are off by default or billed separately.

How should I version T1530 rules against ATT&CK v20.0?

Record the ATT&CK version in each rule's metadata and in your detection inventory, and name the version the mapping targets, which for these pages is Enterprise ATT&CK 20.0. Tie each rule to the technique ID, the detection strategy and the data components it relies on, so that a release change can be traced to affected rules. MITRE can rename, deprecate or revoke techniques and changes the detection content across releases, so check the ATT&CK updates pages after each release and compare against the STIX bundle for your target version. Store rules in source control with change history, and review mappings on a fixed schedule as well as after each release. Ask your implementation partner to show how version changes are tracked in the delivered inventory.

How often should I re-run detection validation for T1530?

Re-run validation after every rule change, after changes to log sources or field mappings, after major ATT&CK version updates, and on a recurring schedule set by your risk owner. The schedule is a governance decision, so agree it in writing and record the results as evidence. A practical approach is to keep a small set of repeatable test scenarios in a private cyber range, run them against the production detection logic, and confirm that alerts fire with the expected fields and reach the right queue. Track detection gaps and the date each was fixed. Validation results also show whether a provider change silently stopped audit logs from arriving, which is one of the most common causes of quiet failure in cloud detection.

How DeployOpen builds T1530 detections and range exercises

DeployOpen works on T1530 Data from cloud storage as a fixed-scope engagement inside the client's own cloud accounts or data centers. The work moves from a written scope of which storage services, identity sources and log pipelines are covered, through detection content and cyber range rehearsal, to documented handover and optional ongoing support.

How we scope

Inventory which IaaS object storage, office suite and SaaS file repositories hold data in scope for T1530.
Confirm which identity provider, cloud audit logs and network telemetry sources are available to the detection pipeline.
Agree in writing the ATT&CK version (for example v20) the detection mappings will target and the data components covered.

How we build

Configure log collection for storage access and authentication events in Wazuh or the client's chosen open-source SIEM.
Write Sigma rules describing bulk read, unusual access volume and access from unexpected identities or locations, tuned to the client's baseline.
Map Encrypt Sensitive Information and Audit mitigation controls to the storage services and identity configurations in scope.

How we hand over

Deliver a range exercise plan that replays benign and simulated bulk-access scenarios against the detection content in a private cyber range.
Document each detection with its data sources, logic in plain language, known false positives and the response steps for analysts.
Provide validation results showing which scenarios fired, which did not and what tuning was applied, with the agreed deliverables.

How we support

Review detection content when the client changes storage services, identity providers or ATT&CK versions.
Offer ongoing support, upgrades and continuous testing as a retainer, separate from the initial fixed-scope work.
Confirm with the client what recurring effort and access their environment requires before a retainer is agreed.

T1530 Data from cloud storage