Cloud Infrastructure Discovery

This technique sits right after initial access to the cloud control plane, whether that access came from a leaked long-term access key embedded in a public repository or CI pipeline, a phished console session, or a purchased credential from an infostealer log. A recurring pattern follows: keys exposed in build tooling or a public repository are immediately used to run high-volume Describe and List calls against the victim account, the reconnaissance step before the attacker commits to a specific objective.

What comes next depends on what the discovery sweep finds. A tenant rich in S3 buckets routes toward Cloud Storage Object Discovery (T1619) and bulk exfiltration; a tenant with exposed RDS snapshots routes toward data theft through snapshot sharing; a tenant with idle compute capacity routes toward cryptomining deployment. Stratus Red Team's aws.discovery.ec2-enumerate-from-instance atomic test, referenced by Elastic's detection rule, models the specific case of an attacker pivoting from a single compromised EC2 instance role to enumerate the rest of the account, the same recon-before-commit logic that shows up across ransomware, data-theft and cryptomining cloud intrusions alike.

The overwhelming majority of Describe/List/Get calls in any cloud account are legitimate automation: Terraform plan and apply cycles, AWS Config's continuous resource inventory, CSPM and vulnerability scanners like Prowler or Wiz, cost-management tooling, and CI/CD pipelines that check resource state before deploying. All of these will legitimately trip a naive rule that alerts on any burst of discovery calls, and at scale they will generate far more noise than genuine reconnaissance.

The fix is identity-based baselining rather than call-based filtering. Maintain an explicit allow-list of the ARNs, service principals, and service accounts your automation actually uses, and scope the burst-detection rule to exclude them; Elastic's own rule takes this approach by filtering out known AWS service identities and console sessions before counting. From there, weight new-terms detections heavily: a principal with no prior CloudTrail history running a discovery burst is far more likely to be a stolen key than an established Terraform service account doing its Tuesday-morning plan. Correlating with GetCallerIdentity immediately preceding the burst also cuts false positives, since routine automation rarely calls it first.

When a discovery burst fires, the first question is whether the ARN or service account belongs to a documented automation workflow, and if so, whether the timing and source IP match its normal schedule. If the caller is unfamiliar or the source IP is a VPN exit node, a residential proxy range, or a region the account has never operated from, treat it as a live credential compromise rather than noise. Pull the key's creation date next: an access key issued minutes before the burst, or an assumed-role session with no prior activity, is close to conclusive.

Once compromise looks likely, revoke or rotate the credential immediately, since the enumeration itself does no direct damage but is the last cheap warning before the attacker acts on what it found. Check what the burst actually touched (which services, which regions) to scope what needs closer review: buckets it listed should be checked for subsequent GetObject or bulk-download activity, snapshots it described should be checked for sharing or copy operations to external accounts, and instances it enumerated should be checked for new security-group rules or SSM command execution. Escalate to IR if the same identity shows any follow-on write action within the same session, since that confirms the recon converted into an active intrusion rather than a scan that got interrupted.