T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide: Spotting Stolen Key Enumeration Early

The first thing an attacker does with a stolen cloud key is ask the cloud what it can see, and those list and describe calls are often the earliest reliable sign that a non-human identity has been compromised. MITRE ATT&CK T1580 Cloud Infrastructure Discovery covers enumeration of IaaS resources such as instances, snapshots, storage and databases through provider APIs and CLIs. T1619 Cloud Storage Object Discovery covers enumeration of the objects inside cloud storage, the cloud equivalent of browsing a file system. Both sit in the Discovery tactic (TA0007) on the IaaS platform in ATT&CK v20. This guide treats them together because they appear together in real intrusions, and focuses on telling hostile enumeration apart from the large volume of legitimate read calls. It is for detection engineers, cloud security teams and anyone who owns workload credentials. For discovery techniques across on-premises and cloud see the Discovery and Reconnaissance Techniques Guide.

Key takeaways

• Discovery is the early warning. It sits between key theft and impact; catching it means responding before data is copied or resources are changed.
• Read calls are noisy, identities are not. Millions of Describe and List calls are normal, but a workload role suddenly calling dozens of services it has never touched is not.
• Storage enumeration is a separate signal. ListBuckets says what exists; ListObjectsV2 or List Blobs across many prefixes says someone is preparing to take data.
• Object-level listing is not logged by default. In AWS, ListObjectsV2 is a CloudTrail data event; in Google Cloud, object listing is Data Access logging, which is off until enabled.
• Least privilege shrinks the map. ATT&CK's only mitigation for both techniques is user account management: a key that cannot list cannot plan.

How the attack works

ATT&CK describes adversaries enumerating resources with a compromised user's access keys to determine which are available, then using the results to decide next steps such as persistence, making a bucket public or assessing the value of a database. It distinguishes T1580, which discovers components of services, from identity discovery and from T1526 Cloud Service Discovery, which finds the services themselves.

Stolen keys are frequently probed for value before any listing. In the LLMjacking campaigns, attackers checked GetModelInvocationLoggingConfiguration to see whether prompts were logged and sent deliberately invalid model invocations to test access, behaviour that belongs in the same detection family.

Where it shows up

• Extortion groups: ATT&CK records Scattered Spider enumerating AWS environments, including S3 buckets, to identify server and backup management infrastructure, and ShinyHunters using S3 Browser and WinSCP to collect bucket configuration and access S3 objects. See the Scattered Spider Threat Actor Profile.
• Hybrid ransomware: Storm-0501 enumerated compromised cloud environments to find critical assets, data stores and backup resources before exfiltration and deletion.
• Leaked key exploitation: keys exposed in code or web pages are tried quickly; the Football Australia AWS keys exposure shows how far one key's view can reach, with 127 buckets reportedly accessible.
• Offensive toolkits: Microsoft Defender for Resource Manager has alerts for MicroBurst, PowerZure and Azurite enumeration, which indicates how common scripted Azure discovery is.

Impact

Discovery does no direct damage, but it decides what happens next. A successful enumeration tells the adversary which buckets hold backups, which databases are large and reachable, which snapshots can be shared and which identities to target next. It precedes T1530 Data from Cloud Storage, T1537 Transfer Data to Cloud Account and impact techniques. The detection value is time: every minute between the first list call and the first copy is a chance to revoke.

Detection

The ATT&CK v20 detection strategies describe the defender's view: repeated listing or describing of instances, snapshots, buckets and volumes by new or untrusted identities, from unusual locations, or as rapid multi-service discovery, correlated with later snapshot creation or instance changes; and for storage objects, large-scale enumeration in short windows, from unexpected regions or unusual accounts.

Tuning advice

• Allow-list scanners by identity: CSPM, CIEM, backup and inventory tools enumerate constantly. Exclude them by role ARN or service principal and source, never by API name, and alert if those identities are used from anywhere else.
• Baseline workloads tightly: application roles call a small, stable set of APIs, which makes any new service a strong signal. See the Service Account Behavioural Baselining Guide.
• Escalate on sequence: discovery alone is low severity; discovery followed by a permission change, snapshot share or bulk read within an hour is high.
• Plant decoys: an unused access key or a bucket nobody should list is a near zero false positive tripwire for enumeration, in line with D3FEND decoy techniques.

Metrics

• Detection latency: minutes from the first anomalous list call by a compromised test key to an alert, measured in authorised exercises.
• Baseline coverage: share of workload identities with a behavioural baseline.
• List permission spread: share of identities with account-wide list or describe on storage and compute.
• Long-term keys: count of active AKIA user keys and their age, trending to zero.
• Data-plane listing coverage: share of sensitive buckets with object-level listing logged.

Prevention and hardening

• Least privilege on read (M1018): ATT&CK advises limiting permissions to discover cloud infrastructure and restricting object listing to the accounts that need it. Avoid broad managed policies such as account-wide read-only access for workloads; grant list only on the buckets and resources a job uses. See the AWS IAM Policies and Roles Guide.
• Use unused-access analysis: IAM Access Analyzer and provider equivalents identify unused permissions and services so read rights can be trimmed. See the IAM Access Analyzer Guide.
• Remove long-term keys: replace user access keys with roles and federation so a leaked key expires. See the AWS Access Keys Security Guide.
• Bind credentials to networks: condition sensitive permissions on VPC endpoints or source networks so a stolen key cannot enumerate from the internet.
• Protect instance credentials: enforce IMDSv2 so server-side request forgery cannot harvest role credentials for discovery. See the EC2 Instance Metadata Service Hardening Guide.
• Keep the logs that show it: enable data events for listing on sensitive buckets, Azure Storage resource logs and Google Cloud Data Access logs where object discovery matters. See the Cloud Logging and Audit Trail Guide.

Choosing controls

Phased rollout

1. Inventory identities: list every human and non-human principal with list or describe rights, with owners.
2. Build baselines: collect 30 days of API names and services per principal; identify scanners and allow-list them by identity.
3. Alert in shadow mode: run breadth, burst and new-source rules for two weeks, tune, then route to the SOC.
4. Trim permissions: remove unused list and read rights in rings, starting with workload roles; rollback is restoring the previous policy version.
5. Exercise: in an authorised test, use a decoy key from an unusual network and confirm the alert and the revocation steps in the Cloud Access Key Leak Playbook.

Where identity fits

Cloud discovery is almost always done with a non-human credential: a leaked access key, a role session taken from an instance or pipeline, or a service account key. AWS's guidance for GuardDuty findings starts by identifying the entity from the access key prefix (AKIA for long-term user keys, ASIA for temporary STS credentials), reviewing its permissions and Access Advisor data, and confirming with the owner whether the call was legitimate. That only works if every identity has an owner. See the NHI Ownership Guide and the Detection Engineering for Non-Human Identities Guide.

Lessons from incidents

• Attackers check your logging first: the LLMjacking activity included a call to read the model invocation logging configuration before abuse, so alerting on reads of logging settings catches a deliberate step.
• One key's view is the blast radius: the Football Australia case shows that a single over-scoped key can see a whole estate; scoping list rights per job limits what discovery can find.

Framework mapping

Practitioner checklist

• Baseline API usage for every workload identity and alert on new services and read bursts.
• Alert when a long-term key or role session is used from a new network or Tor.
• Allow-list scanners by identity and alert on scanner credentials used elsewhere.
• Enable object-level listing logs on sensitive buckets and containers.
• Turn on managed detections such as GuardDuty discovery and recon findings or Defender for Resource Manager.
• Remove account-wide read and list rights from workload roles.
• Replace long-term user access keys with roles and enforce IMDSv2.
• Plant a decoy key and a decoy bucket and test the alert path each quarter.

Standards and references

• MITRE ATT&CK: Cloud Infrastructure Discovery (T1580)
• MITRE ATT&CK: Cloud Storage Object Discovery (T1619)
• AWS: GuardDuty IAM finding types
• AWS: GuardDuty S3 Protection finding types
• AWS: Remediating potentially compromised AWS credentials
• AWS: Amazon S3 CloudTrail events
• Microsoft Learn: Alerts for Azure Resource Manager
• Google Cloud: Cloud Audit Logs with Cloud Storage

Related NHI Mgmt Group resources: Discovery and Reconnaissance Techniques Guide · Cloud Access Key Leak Playbook · Amazon GuardDuty Guide · Detection Engineering for Non-Human Identities Guide · T1530 Data from Cloud Storage Defensive Guide