Cloud Infrastructure Discovery (T1580) is a technique in the discovery tactic, for IaaS. The adversary tries to learn what infrastructure and resources exist in an environment: compute resources such as instances, VMs and snapshots, and resources from other services such as storage and databases.
How attackers use it
Cloud providers expose this information through APIs and CLIs, and MITRE gives examples:
- AWS: the DescribeInstances API in the EC2 API returns instance information. ListBuckets lists all buckets owned by the caller. HeadBucket checks that a bucket exists and what access the caller has. GetPublicAccessBlock returns a bucket's access block settings.
- Google Cloud: the CLI command gcloud compute instances list lists Compute Engine instances in a project.
- Azure: az vm list shows details of virtual machines.
Adversaries can also discover cloud storage with open source tools through Wordlist Scanning (T1595.003).
With a compromised user's access keys, an adversary can enumerate what those keys can see, which helps them plan the next step, such as persistence. MITRE adds that they may use the information to change a bucket's configuration to make it publicly accessible, so data can be read without authentication.
Discovery is the quiet phase. It changes nothing, so it often goes unnoticed, but it usually comes right before something that does.
How to detect it
MITRE's analytic asks defenders to watch for suspicious enumeration of cloud components through APIs or CLI tools. Look for:
- Repeated list and describe operations across instances, snapshots, buckets and volumes
- New or untrusted identities making discovery calls such as DescribeInstances, ListBuckets, az vm list or gcloud compute instances list
- Enumeration from unusual geolocations or IPs
- Rapid discovery across several services in sequence
Correlate discovery with later actions. Discovery followed by snapshot creation or instance modification is much more telling than discovery alone.
Many legitimate tools list resources too: inventory scanners, cost tools, infrastructure code. Allowlist them by identity so the rest stands out.
How to reduce the risk
MITRE lists one mitigation: user account management. Limit discovery permissions according to least privilege. Keep the number of identities with administrative IAM roles low, work toward removing permanent privileged assignments, and review entitlements on IAM users, roles and policies on a regular basis.
A practical test: for each identity, ask what it can list. A build pipeline that deploys one application does not need to list every bucket in the account.
Check your own environment
# AWS CLI: what does this identity look like to the API?
aws sts get-caller-identity
# AWS CLI: recent discovery events from CloudTrail
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets --max-results 20
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=DescribeInstances --max-results 20
- Which identities make list and describe calls, and are they all expected?
- Are access keys for people and automation short-lived and rotated?
- Do discovery calls from a new identity or a new region raise an alert?
- Is there an asset inventory you trust, so you know what an attacker would find?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is correlation important for discovery alerts?
Legitimate tools also list resources. MITRE notes that discovery followed by snapshot creation or instance modification is much more meaningful than discovery alone.
What can an adversary do after learning which buckets exist?
Plan next steps such as persistence, or change a bucket's configuration to make it publicly accessible so data can be read without authentication.
Which mitigation does MITRE list?
Least privilege through user account management, limiting who can discover cloud infrastructure and reviewing entitlements regularly.
