T1619 Cloud Storage Object Discovery: Detecting Bucket and Blob Listing by Compromised NHIs

An attacker holding a leaked cloud key usually lists your buckets and their contents before taking anything, and in most accounts that listing is never logged. MITRE ATT&CK T1619 Cloud Storage Object Discovery covers adversaries enumerating objects in cloud storage, using the same list APIs that applications call every minute: ListObjectsV2 in Amazon S3, List Blobs in Azure Storage and object listing in Google Cloud Storage. ATT&CK v20 places it in the Discovery tactic (TA0007) on the IaaS platform, with no sub-techniques. This guide covers what the listing looks like in each provider's logs, which logs are off by default, how to baseline the service principals and access keys that legitimately list storage, and how to test the detections. It is for cloud security engineers, detection engineers and SOC analysts, and is defensive only.

Key takeaways

• Listing is the step before theft. ATT&CK describes T1619 as the cloud equivalent of file and directory discovery: the result shapes which objects the adversary requests next under T1530 Data from Cloud Storage.
• Object listing is a data event, and data events are off by default. AWS CloudTrail, Google Cloud Data Access audit logs and Azure Storage resource logs all need to be switched on before object listing is recorded.
• The caller is usually a non-human identity. Leaked IAM user access keys, service account keys and SAS tokens are the common way in, so baselines should be per key and per workload, not per person.
• Volume and novelty beat signatures. A new principal, a new source network or a burst across many buckets in minutes is the signal; one ListObjects call never is.
• Least privilege on list permissions is the only ATT&CK mitigation. M1018 User Account Management: grant listing only to identities that need it, and scope it to named buckets and prefixes.

What T1619 covers

ATT&CK v20 says adversaries may enumerate objects stored in cloud infrastructure and use the result during automated discovery to shape follow-on behaviour, including requesting all or specific objects. It typically follows T1580 Cloud Infrastructure Discovery, which finds the storage services and buckets, and precedes T1530 collection. For the wider cloud discovery picture see the T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide; this page goes deeper on object listing alone.

Two gaps matter. The AWS S3 CloudTrail page lists ListObjects, ListObjectVersions and ListParts as general purpose bucket data events, so check how your own trail records V2 calls before writing a rule on the event name. Google states that Cloud Audit Logs do not track access to resources made public through allUsers or allAuthenticatedUsers, even with Data Access logs on; usage logs are the source there.

How adversaries use it

ATT&CK v20 records four procedure examples. They show the technique is mostly carried out with stolen keys and ordinary tools, not custom malware.

Case: Bling Libra (ShinyHunters) in AWS

Unit 42 published an investigation in August 2024 into an intrusion it attributes to Bling Libra, which overlaps with ShinyHunters. The attackers took an IAM user's access key from a sensitive file exposed on the internet. The user had the AWS managed AmazonS3FullAccess policy. An IAM ListUsers call failed, then the attackers used the AWS CLI to call ListBuckets, browsed buckets with S3 Browser (which generated GetBucketLocation and GetBucketObjectLockConfiguration events) and used WinSCP, which generated ListBuckets. About a month later they deleted buckets, created many new ones by script and sent an extortion email. Because CloudTrail S3 data events and server access logging were off, the victim could not see object-level activity or prove what left. In lab tests Unit 42 found that S3 Browser issues ListObjects and other calls automatically, and that the user agent strings S3 Browser/, WinSCP/ and aws-cli/ help separate tool automation from operator actions. See the ShinyHunters Threat Actor Profile.

The exposure that makes T1619 possible is common. In the Football Australia AWS keys exposure, researchers reported that access keys left in public website code gave access to 127 storage buckets. No misuse beyond the researchers was reported, but any holder of those keys could have listed every bucket.

What to detect and where

ATT&CK v20 maps one detection strategy, DET0578, with analytic AN1594 for IaaS. It looks for enumeration through ListObjectsV2, List Blobs or GCP ListObjects and correlates it with the account's role, user context and prior authentication to find an unusual account, unexpected region or large-scale enumeration in a short window. The log sources it names are the data components Cloud Storage Enumeration (CloudTrail ListObjectsV2) and Cloud Storage Access (CloudTrail GetObject, CopyObject).

Turn the logs on first

• AWS: Add advanced event selectors for S3 data events on the buckets that hold sensitive data, or on all buckets if cost allows. Keep S3 server access logging for buckets where you need a second record. Enable GuardDuty S3 Protection, which reads S3 data events.
• Azure: Create a diagnostic setting on each storage account (the blob, file, queue and table sub-resources separately) sending StorageRead, StorageWrite and StorageDelete to Log Analytics. Enforce it with Azure Policy so new accounts are covered.
• Google Cloud: Enable Data Access audit logs for Cloud Storage (ADMIN_READ and DATA_READ) at organisation or folder level, with exemptions only for high-volume pipeline identities you have reviewed.

Detection logic

Provider detections help but need the data logs. GuardDuty's Discovery:S3/AnomalousBehavior, Discovery:S3/MaliciousIPCaller and Discovery:S3/TorIPCaller findings are built on S3 data events. Microsoft Defender for Storage raises "Unusual data exploration in a storage account" (Storage.Blob_DataExplorationAnomaly), "Unusual access inspection in a storage account" and "Publicly accessible storage containers successfully discovered" for container guessing. Treat these as starting points and keep your own per-identity baselines. For hands-on CloudTrail work see How to Investigate CloudTrail for a Compromised Access Key.

Where identity fits

Almost every recorded case starts with a valid credential (T1078.004 Cloud Accounts), often a long-lived key found in code, files or a CI log (T1552.001 Credentials In Files). That makes the non-human identity the unit of detection and of response.

• Know every lister: Keep an inventory of which roles, service accounts, managed identities and keys hold s3:ListBucket, s3:ListAllMyBuckets, Storage Blob Data Reader or storage.objects.list, and which of them use it.
• Prefer short-lived credentials: Workload identity federation and instance or pod roles remove the static keys that leak. See the Workload Identity Federation Guide.
• Treat SAS tokens as credentials: An account SAS with list permission is an unscoped lister; prefer user delegation SAS with short expiry.
• Respond per key: When a key lists unexpectedly, disable that key, then review everything it did. The Cloud Access Key Leak Playbook covers the steps.

Mitigations

For bucket-level hardening see the Amazon S3 Security Guide and Azure Storage Security Guide.

How to test

1. Confirm logging: In a test account, list a bucket with a test identity and confirm the event appears in CloudTrail Lake or your SIEM, in StorageBlobLogs and in Cloud Logging, with identity, source IP and user agent populated.
2. Build the baseline: Run the queries in report-only mode for 30 days and record which identities list which stores, from where and how often.
3. Emulate safely: With a dedicated test key on a test bucket, list from an unexpected network and with a GUI client user agent. Confirm the new-lister, wrong-source and unusual-client rules fire. Do not use production keys.
4. Exercise response: Disable the test key from the alert, confirm the next call fails, and time the steps.
5. Roll back noise: If a rule fires on a legitimate job, add a scoped exception by identity and source, never by bucket alone.

Measuring it

• Share of sensitive buckets and storage accounts with data-level logging on (target 100%).
• Number of identities holding list permissions on sensitive stores, and the share that used them in 90 days.
• Number of long-lived storage-capable keys remaining, trending down.
• Median time from an anomalous listing alert to key disabled.
• False positive rate per detection rule per month.

Common failure patterns

• No data events: As in the Bling Libra case, management logs show the bucket names touched but not what was listed or read, so scope of loss cannot be proved.
• Full-access policies on keys: A key used to upload to one bucket can list every bucket in the account.
• Alerting per call: Rules on single ListObjects calls drown the SOC and get disabled.
• Logging only new accounts: Diagnostic settings applied by hand miss storage accounts created later.
• Ignoring anonymous access: Public buckets can be listed without any identity appearing in audit logs.

Framework mapping

Practitioner checklist

• Enable S3 data events, Azure Storage resource logs and GCS Data Access logs on sensitive stores.
• Enforce logging on new storage accounts and buckets with policy.
• Inventory every identity with list rights on sensitive storage.
• Scope list permissions to named buckets and prefixes.
• Replace long-lived storage keys with federated, short-lived credentials.
• Deploy new-lister, breadth-burst, wrong-source and unusual-client rules after a 30-day baseline.
• Turn on GuardDuty S3 Protection or Defender for Storage where you use those services.
• Test with a dedicated key on a test bucket and time the key-disable step.

Standards and references

• MITRE ATT&CK: Cloud Storage Object Discovery (T1619)
• AWS: Amazon S3 CloudTrail events
• AWS: GuardDuty S3 Protection finding types
• Microsoft Learn: Monitor Azure Blob Storage
• Microsoft Learn: Storage logged operations and status messages
• Microsoft Learn: Alerts for Azure Storage
• Google Cloud: Cloud Storage audit logging
• Palo Alto Networks Unit 42: Bling Libra (ShinyHunters) extortion in AWS

Related NHI Mgmt Group resources: T1530 Data from Cloud Storage Defensive Guide · AWS CloudTrail Guide · AWS Access Keys Security Guide · Public S3 Exposure Check