How T1619 cloud storage object discovery exposes what an attacker can reach
T1619 Cloud Storage Object Discovery sits under the Discovery tactic (TA0007) in MITRE ATT&CK and matters because it is often the step where an attacker with cloud access turns a foothold into a map of data. For a SOC lead, the risk is not the listing itself but what the listing reveals: buckets and containers in an IaaS account may hold customer records, backups, configuration files or credentials that were never meant to be found. Discovery of this kind is quiet, uses legitimate platform functions and can happen before any obvious data movement. An adversary who already holds valid cloud credentials or a compromised workload identity typically enumerates the storage services the identity can see, then reviews the names, prefixes and metadata of the objects inside them to decide what is worth collecting. This happens in the cloud control plane and the storage data plane, and it often follows broader cloud discovery such as instance or account enumeration. In intrusions, this step usually appears between initial access or privilege gain and collection or exfiltration, which is why it is a useful early warning point. The decisions that shape how much this technique exposes sit with your platform and identity teams. Confirm which identities can list storage across accounts or subscriptions, which buckets or containers hold sensitive data and whether their object names reveal that data, and whether storage access is logged in a way your SIEM can query. Your cloud provider's audit log documentation will define which storage events are recorded and whether data-plane reads are included, so verify that in your own environment before you rely on it.
Which cloud telemetry reveals T1619 storage enumeration
This table maps the two telemetry sources named for T1619, Cloud Storage Enumeration and Cloud Storage Access, to the signal a defender should look for and the open-source collector that can gather it. Read each row as a question to answer in the client's own environment, since audit log coverage differs by provider and account configuration. The main takeaway is that enumeration evidence is usually thinner than access evidence, so confirming which listing events are logged is the first step.
| Telemetry | Signal to look for | Open-source collector and check |
|---|---|---|
| Cloud Storage Enumeration | Bucket or container listing calls from a principal that does not normally list storage, especially across many containers in a short window | Collect provider audit logs with a cloud log collector feeding Wazuh or Security Onion. Confirm that listing operations are recorded at all, since some providers log them only in data event modes |
| Cloud Storage Access | Object read or metadata requests against storage the principal has not used before, or requests from unfamiliar source addresses or agents | Forward storage access logs to Security Onion or a Wazuh indexer. Confirm whether object-level logging is enabled, because it is often off by default and can carry cost |
| Principal and identity context | The calling identity, its role or key, and whether it was created or changed recently | Pair storage events with identity provider and account management logs in Wazuh. Confirm the identity fields are present in each event so enumeration can be tied to a principal |
| Source network context | Requests originating outside expected cloud network paths, VPN ranges or known automation hosts | Correlate storage logs with flow or DNS telemetry in Zeek or Suricata where the environment provides it. Confirm that flow logs are enabled for the relevant subnets |
| Sequence and volume | A burst of listing calls followed by targeted access, or access to storage tagged as sensitive | Build correlation rules in Wazuh or Sigma-format rules converted for the chosen SIEM. Tune thresholds during range rehearsal rather than adopting defaults |
| Data components for Discovery | Discovery detection strategies reference Process Creation (DC0032), Command Execution (DC0064) and File Access (DC0055); cloud storage events map most directly to File Access | Use host telemetry from Velociraptor or Wazuh agents for workloads that call storage APIs. Confirm which data components the target ATT&CK version maps for T1619 before writing rules |
| Coverage caveat | Whether listing, object access and identity fields are logged depends on the cloud provider, the service and the account configuration | Ask the platform team to confirm log coverage per account and region in writing. Treat any gap as a finding to document, not an assumption to accept |
How detection logic for cloud storage discovery is built
Detection for T1619 Cloud storage object discovery starts from one question: who normally lists objects, from where, and how many containers do they touch in a normal window? Separate the legitimate listing population into named identities, such as backup service roles, analytics pipelines and application workloads, and describe each by its expected source network, expected buckets or prefixes, and typical request rate. Enumeration by a principal that falls outside that population, from an unfamiliar address or cloud region, or across many buckets in a short window is the pattern worth alerting on. A single listing call by an application role is usually noise; the same role listing every bucket in an account within minutes is not. Your first deliverable is a written inventory of these identities and their expected behavior, agreed with the teams that own the backup and analytics jobs.
Baselines have to be kept per identity and per workload, not per account. A shared baseline hides an abusive principal inside the average of busy services, so compare each identity against its own history over a rolling window and set thresholds on the number of distinct buckets listed, not only on raw call counts. Confirm with your cloud provider which audit log records storage listing and object access events, whether data event logging is enabled for those buckets by default or must be switched on, and how long those logs are retained. Those answers determine whether the Cloud Storage Enumeration and Cloud Storage Access telemetry your rules depend on exists at all. Test the baseline logic against a few weeks of your own logs before turning on alerts, because the first baseline usually reveals identities nobody documented.
Name the ATT&CK version in every detection record, for example the version your mapping was built against, because the framework changed its structure recently. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies and analytics and deprecated data sources in favor of data components, so a rule written against an older page may map to different identifiers now. Recent releases, including v19 and v20, can also rename, deprecate or revoke techniques. Record the version, the detection strategy identifier and the data components your analytic uses, and review the mapping when a new release lands. The MITRE ATT&CK updates page lists each release so the review is scheduled rather than discovered during an incident.
Detection ideas for T1619 that SOC teams can tune
Storage listing is a routine operation, so no single event proves T1619 Cloud storage object discovery. The ideas below combine volume, identity, source, sequence and failure signals so that each alert has a clear reason to exist. Each threshold is a starting point that the SOC should baseline against its own storage traffic before enabling alerts.
Unusual listing volume per identity
Count object listing calls per identity and per bucket or container over a rolling window, then alert when an identity exceeds its own historical baseline by a set multiple. Start with a window of one hour and a multiple your baseline supports, such as three times the 14-day median, and tune it per identity class. Main false positives are backup jobs, data pipelines and inventory tools that list every object on a schedule. Exclude those service identities by name and review their schedules before tuning.
Listing from new sources
Alert when an identity lists storage from a source address, autonomous system, or region it has not used in the prior baseline period. This matters for T1619 because discovery often follows stolen or newly issued credentials used from unfamiliar infrastructure. Check whether the source is a known VPN egress, a managed CI runner or a corporate proxy before escalating. Enrich each alert with the identity's last seen locations so analysts can compare quickly.
Enumeration followed by sensitive access
Correlate a listing event with a subsequent read of objects under sensitive prefixes within a short window, such as exports, backups, key material or customer data paths. The sequence is more specific than listing alone, so it can be tuned to a low-noise high-severity rule. Define the sensitive prefix list with data owners and keep it in version control. Expect false positives from restore runbooks and data migrations, so require a change ticket lookup before paging.
Listing by dormant identities
Flag the first storage listing by an identity that has no storage activity in its prior history, including service accounts created recently. Dormant identities that suddenly enumerate storage are a common sign of a reused or misconfigured credential. Tune the dormancy period to your environment and exclude identities created by approved provisioning workflows during onboarding. Confirm with the owning team whether the identity is expected to touch storage at all.
Clustered failed listing attempts
Alert when one identity or source generates a cluster of denied or not-found responses on listing calls within a short window, especially across several buckets or containers. Denials can show an actor probing for permissions before finding a reachable scope. Set the cluster threshold from your own denial rate, since misconfigured applications and retry logic also produce failures. Pair the alert with the identity's policy changes so analysts can see whether a recent permission change explains the failures.
How to validate that the T1619 detection fires
This sequence proves that the T1619 detection fires on purpose-built test buckets in a lab or cyber range, under written authorization. It produces timestamped evidence of what was detected, what was missed and which tuning changes are needed.
Confirm scope and written authorization
The security lead and the cloud platform owner agree in writing which accounts, projects, regions and storage services are in scope, who may run the exercise and what must stay untouched. The exercise lead confirms that the test environment is a lab or cyber range account separate from production. The step is done when the signed scope document names the test identities, the time window and the escalation contact for anyone who sees unexpected activity.
Confirm the ATT&CK version and emulation plan
The detection engineer checks which ATT&CK version the emulation plan and the detection mapping target, then reviews the T1619 entry against that version, because releases can rename, deprecate or revoke techniques. The plan should reference the data components the detection relies on, such as Cloud Storage Enumeration and Cloud Storage Access, so each planned action has a named expected signal. The step is done when the plan lists the ATT&CK version and each expected signal is traceable to a rule.
Provision synthetic test buckets
The platform team creates a small set of test buckets in the range account, each holding clearly synthetic data such as generated files marked as test records, and no real customer or employee data. Buckets are tagged with an exercise identifier and a delete-by date agreed in the scope document. The step is done when an inventory lists each bucket, its contents category, its tags and the identities allowed to touch it.
Run the approved emulation and log the actions
The exercise operator runs the approved emulation steps against the test buckets from the designated test identity, following the plan without improvising. The operator records a timestamped log of each action, the identity used, the source address and the target bucket, which becomes the ground truth for comparison. The step is done when the log is complete and the operator signs that every action in the plan was executed or explicitly skipped.
Compare expected alerts with what fired
The detection engineer pulls the alerts from the SIEM, such as Wazuh or Security Onion, for the exercise window and matches each one against the ground-truth log using timestamps, identities and bucket names. Each planned action is marked as detected, detected late, detected with the wrong identity or missed. The step is done when every planned action has one of those four outcomes and the time from action to alert is recorded.
Measure detection gaps and record evidence
The team writes up the gaps, separating missing telemetry (for example, cloud audit events not forwarded to the SIEM) from rule logic that did not match the activity. Screenshots, exported alert records and the ground-truth log are stored together with the exercise identifier. The step is done when the gap report names an owner for each gap and the evidence package can be re-read without the operator present.
Feed results back into tuning and retest
The detection engineer adjusts the rule, the log sources or the alert thresholds for each confirmed gap, then records the change in version control with a reference to the exercise. Known benign activity from the platform team is documented as an allowlist entry so future noise is explained. The step is done when a retest with the same plan shows the targeted actions now produce the expected alerts, or the remaining gap is accepted in writing with a reason.
Clean up test resources and close the exercise
The platform team deletes the test buckets, removes the test identities and revokes any temporary access granted for the exercise, then confirms deletion in the cloud audit trail. The security lead signs the closure record, which lists the ATT&CK version, the scope, the detection outcomes and the open items. The step is done when the inventory shows no remaining exercise resources and the closure record is filed with the evidence package.
Preventive controls that reduce T1619 exposure
Discovery of cloud storage objects depends on what an identity is allowed to list and read, so most preventive work sits in identity and access management. The cards below group the controls that narrow that reach and the logging that shows when it is used. Confirm each provider-specific setting with your cloud vendor, since storage permission models differ between platforms.
Least privilege for storage listing
Mitigation User Account Management (M1018) is the primary control for T1619 Cloud storage object discovery. Start by reviewing which identities can list buckets or containers and which can list objects within them. Many roles grant listing across an entire account when they only need one bucket, so scope list permissions to named resources where the platform supports it. Ask your cloud vendor which storage actions are separate from read actions in your environment, because listing is often granted more broadly than teams expect.
Separation of duties for storage access
Keep the people who provision storage accounts apart from the people who administer access to the data within them. When one identity can both create a bucket and grant itself read access, a compromised account can enumerate and expose objects without a second approval. Under M1018, document which roles may change storage policies and require a second reviewer for changes to bucket-level access. Confirm how your platform records policy changes so the separation can be tested.
Review of standing access
Standing storage permissions that nobody reviews are the most common source of unexpected listing reach. Run periodic access reviews that compare each identity's storage permissions against its current job, and remove grants tied to former projects, shared service accounts or old automation. Include workload identities and cross-account trust, which often hold storage listing rights for convenience. Record each review and its decisions, since auditors will ask for that evidence under the same mitigation.
Audit logging of storage enumeration
Mitigation Audit (M1047) supports the preventive controls by making listing activity visible. Confirm that object and bucket listing events are written to a central log store and retained long enough to investigate a suspected enumeration run. Check whether your platform logs list operations as data events, since some providers record them only when data-event logging is enabled. Map the resulting events to the Cloud Storage Enumeration and Cloud Storage Access telemetry used for detection.
Restricting unused identities and keys
Disable or delete identities and access keys that have not been used recently, especially those belonging to departed staff or retired pipelines. Dormant credentials are attractive because their owners are unlikely to notice misuse. Ask your cloud vendor whether it reports last-used timestamps for identities and keys, and whether you can automate a report of inactive identities. Treat the result as an input to the standing access review rather than a separate project.
Triage and response when a T1619 alert fires
Start triage by answering one question: is this listing something the identity was supposed to do? Confirm the identity behind the call first, whether it is a human user, a federated role, a workload identity or a service account, and record the source IP, user agent, client application and time window from the cloud audit log. Then check the owner and change calendar for that identity. A backup job, a data pipeline or an inventory tool listing buckets on a schedule is a common benign explanation, and it should match a known job name, role and network path. If the identity has no documented reason to enumerate storage, or the source is an unfamiliar network, treat the alert as suspicious until proven otherwise. Confirm with the owning team in writing and keep their answer with the case record.
Next, look for what happened after the listing. Enumeration matters most when it is followed by reads of objects, download activity, changes to bucket policies or access control lists, or the creation of new keys and sessions. Pivot on the same identity across the audit trail for the hours before and after the alert, and on the storage access logs where your provider supplies them. Scope the affected buckets by sensitivity, because a listing against a bucket holding public assets is a different case from one against a bucket holding regulated records. If follow-on access is confirmed, containment should not wait for the full picture. Suspend or disable the identity or session, revoke active tokens and keys, and tighten the bucket policy to the minimum required principals. Preserve the relevant cloud audit logs, storage logs and identity logs by exporting them to write-protected storage before any cleanup, and escalate to incident response with the timeline so far. Confirm with your provider which logs are retained by default and for how long in your environment.
Close the case with documentation and lessons learned while the details are fresh. Record the alert, the triage decisions, the evidence preserved, the containment actions and who approved them, and whether the activity was benign, a misconfigured automation or a real intrusion. Then feed the outcome back into the detection. Tune the rule against the legitimate job you confirmed, add the approved identity or network to a documented allow list with an owner and review date, and check whether the identity had broader rights than its task required. Those rights are the usual target of the ATT&CK mitigation User Account Management, so tie the findings to that control. Rehearse the same path in your private cyber range so the team has practised the decisions before the next alert. Map the detection to the ATT&CK version you target, because releases can rename or revoke content, as noted in the MITRE ATT&CK updates page.
Rehearsing T1619 detection in a private cyber range
The range should mirror your production IaaS logging path without touching production data. Use a dedicated test account or project that is segmented from business workloads, with its own identity boundary, and populate it with synthetic buckets that contain clearly fake records. Before any exercise, record a baseline for the identities that will act in the range, including which service accounts normally list or read storage, so that later deviations are measurable. Route cloud audit events into an open-source logging stack such as Wazuh or a Security Onion deployment, and confirm the ingestion path end to end before the first exercise.
- Segmented test account: Keep the range in its own account or project with separate billing, network boundaries and administrative roles.
- Synthetic buckets: Create buckets with fabricated content and naming that cannot be confused with production data.
- Baselined identities: Document which roles and users are expected to enumerate or access storage, and capture their normal activity.
- Logging stack: Confirm that cloud audit events for storage listing and object access reach the SIEM with timestamps, identities and source addresses intact.
- Retention and access: Set retention for range logs and limit who can read them.
Before the exercise, confirm with your cloud provider which storage audit events are generated by default and which need explicit configuration.
Injects are scripted, authorized activities that the exercise control team triggers so that the SOC can practice detection and response. For T1619, injects should cover broad enumeration of storage containers from an identity that does not normally perform it, followed by object-level access across several containers. Scoring should reward evidence that analysts saw the activity, understood which identity and scope were involved, and acted on it. Good detection means an alert or hunt query fires on the enumeration pattern, the alert carries the account, source and affected containers, and the analyst can distinguish the event from the documented baseline. Good response means the analyst confirms the identity is in scope, contains the credential or session, preserves the audit trail and escalates according to the playbook.
- Inject design: Script enumeration from an unexpected identity, then vary volume and timing so that both noisy and quiet patterns are tested.
- Detection criteria: Score whether the Cloud Storage Enumeration and Cloud Storage Access events were ingested, parsed and correlated.
- Triage quality: Score whether the analyst separated the test activity from the baseline and documented the scope.
- Response steps: Score containment actions, such as disabling the credential or restricting the role, against the written playbook.
- Control team log: Keep a timestamped record of every inject so the SOC timeline can be matched to the telemetry.
Agree on the scoring rubric with the SOC lead before the exercise so that results can be compared across future runs.
The debrief turns the exercise into findings and owned actions. Walk through the timeline from inject to detection to containment, and compare what the SOC saw with what the control team did. Separate detection gaps (telemetry missing, rules not firing, alerts without context) from process gaps (escalation delays, unclear ownership, unclear containment authority). Record metrics that the team can reproduce in the next exercise, and avoid setting targets until several baseline runs exist. Useful measures include whether each inject produced an alert, the time between inject and first analyst action, whether the identity and scope were correctly identified, and whether the containment step matched the playbook.
- Timeline reconstruction: Align control team timestamps with log timestamps and analyst actions.
- Gap classification: Label each finding as telemetry, rule logic, enrichment, process or access.
- Reproducible metrics: Record whether each inject produced an alert, the elapsed time to first analyst action, and scope identification accuracy.
- Rule and playbook updates: Assign owners and due dates for changes to Sigma or Wazuh rules and to the response playbook.
- Mitigation review: Check whether User Account Management controls, such as least-privilege storage roles and periodic access reviews, limited the blast radius.
Re-run the same injects after changes so the team can confirm that each finding was closed and that metrics moved for the reasons expected.
Questions SOC leads ask about T1619 detection
How do I separate backup jobs from attacker listing of cloud storage?
Separate them by identity, source and pattern, not by the API call alone. Backup and sync services normally run under named service identities, from known network paths, on a predictable schedule, and they list the same buckets or containers every time. An adversary using a stolen credential usually shows an identity that has never listed storage before, a source address or client outside the normal range, listing across many containers in a short window, and listing followed by reads of unfamiliar objects. Build an allow list of approved backup identities with their expected sources and schedules, then alert on anything outside it. Review the allow list whenever a backup platform changes, because an out-of-date list is the most common cause of noisy alerts.
How should we handle delays in cloud provider audit logs?
Assume the logs will arrive late and design the alert around that delay. Provider audit logs for storage activity can take time to appear in your pipeline, and the delay varies by provider, log type and service. Confirm the typical and worst-case ingestion latency with each provider and with your own log pipeline, and record the figures in your runbook. Then set detection windows and correlation rules to tolerate that lag, and make sure responders know that a quiet dashboard may simply mean logs have not arrived. Monitor ingestion health itself, so a broken feed raises an alert instead of silently hiding activity.
Which MITRE ATT&CK version should our T1619 detections map to?
Map detections to a named ATT&CK version and record that version in every rule. Enterprise ATT&CK 20.0 is the version these pages use, and MITRE published it on 2026-10-13 according to the attack-stix-data repository index. ATT&CK releases can rename, deprecate or revoke techniques and change detection content, so a mapping built against one version needs review when you move to the next. Check the ATT&CK updates page before each upgrade and compare the technique and data component references for T1619 against your rule set.
How can we test T1619 detections without touching production data?
Test in a private cyber range that mirrors your storage naming, identity model and logging configuration, using synthetic buckets or containers and dummy objects. Create a test identity that performs listing activity in a controlled way, record the resulting provider logs, and confirm that your rules fire with the expected fields. Never run listing tests against production buckets, and never use real customer or regulated data as test content. Keep the test scripts and expected results under version control so each rule change can be re-tested the same way.
How do we tune thresholds for storage listing alerts?
Start from a baseline of normal listing activity per identity, then set thresholds per identity group rather than one global number. Measure how many distinct containers each approved identity lists in a day, at what hours and from which sources, and set alerts for deviations from that profile. Tune in stages: run rules in a non-paging mode first, review the hits with the owning teams, adjust allow lists, and only then route alerts to on-call. Log each tuning change with a reason, so auditors and future analysts can see why a threshold exists.
Does the ATT&CK mitigation User Account Management help against T1619?
It reduces the chance that a listing attempt succeeds and makes the activity easier to attribute. ATT&CK maps User Account Management (M1018) to T1619 and related discovery techniques. In practice this means least-privilege storage roles, separate identities for backup and application workloads, regular access reviews, and removal of stale service accounts. Confirm the exact coverage with your cloud provider's identity model, because role names and permission boundaries differ between platforms. Mitigation does not replace detection, so pair these controls with the allow list and alerting described above.
How DeployOpen builds T1619 detections and range scenarios
DeployOpen works on T1619 Cloud storage object discovery as a defined engagement inside the client's own cloud accounts or networks. The work turns the technique into written scope, detection logic on open-source tooling, validation evidence and range exercises that the client's own team can repeat.
How we scope
- Confirm which IaaS accounts, storage services and log sources fall inside the written scope.
- Record which cloud storage telemetry is available, such as enumeration and access events, and where it is retained.
- Agree in writing which ATT&CK version and mitigation mappings the detections will target before work starts.
How we build
- Write detection logic for cloud storage enumeration and access patterns in Sigma and map it to the data sources available.
- Ingest cloud audit logs into the client's chosen open-source stack, such as Wazuh or Security Onion, and test parsing and field mapping.
- Document the User Account Management controls that limit which identities can list or read storage objects.
How we hand over
- Deliver detection rules, test cases and expected alert outputs with a written record of what was validated.
- Run rehearsal scenarios in a private cyber range so the client's analysts can see the detection fire and triage it.
- Provide a response runbook covering triage, scoping and containment steps for storage discovery alerts.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, rule updates after ATT&CK version changes and continuous testing are available as a retainer.
- Quotes follow from the written scope, so ask for the scope items and assumptions that drive the cost.
