MITRE ATT&CK for Cloud: Mapping Adversary Techniques to AWS Services

MITRE ATT&CK’s cloud matrix provides a shared vocabulary for describing adversary behavior across cloud environments. But reading technique descriptions in the abstract doesn’t build detection capability — you need to understand how each technique specifically manifests in AWS, what API calls it generates, where those calls appear in CloudTrail, and what compensating controls break the technique. This article focuses on five techniques that appear in virtually every cloud incident report.

Five MITRE ATT&CK cloud techniques mapped to their position in the attack chain. T1619 and T1530 together form the most common cloud data exfiltration pattern.

T1078 — Valid Accounts

What it is: The attacker uses legitimate credentials — IAM access keys, assumed-role sessions, or console passwords — to gain access. No exploit required, no malware needed. The credentials are valid and AWS will honor them.

How it manifests in AWS: The primary source is IAM long-term access keys committed to version control. This happens with alarming frequency — a developer creates a key for local testing, adds it to .env, and accidentally commits it to a public GitHub repository. GitHub’s secret scanning and AWS’s own automated IAM key scanning (which monitors GitHub’s public feed) can detect this within minutes and notify the account owner, but the key is often exploited before the notification is acted on. A secondary vector is IAM keys baked into Docker images pushed to Docker Hub — the image’s environment variables or filesystem contain the credentials, exposed to anyone who pulls the image.

Detection signal: CloudTrail will show the GetCallerIdentity call that every attacker makes first. The key signal is context mismatch: the call comes from an IP address outside your organization’s known ranges (check your VPN egress IPs and office IPs), or from a UserAgent string inconsistent with your tooling. A python-requests UserAgent calling sts:GetCallerIdentity for a key normally used exclusively from the AWS CLI is a high-confidence indicator. Automate detection on first-time source IPs per IAM principal.

Mitigation: Enforce IAM access key rotation policies (90 days maximum via IAM password policy and custom Config rules). Eliminate long-term access keys wherever possible — EC2 instance profiles, ECS task roles, and Lambda execution roles all use short-term credentials through STS. Use AWS Secrets Manager to inject credentials at runtime rather than environment variables. Enable AWS Config rule access-keys-rotated and no-unrestricted-route-to-igw.

T1530 — Data from Cloud Storage

What it is: The attacker reads data from cloud storage objects — S3 buckets, specifically — after gaining sufficient IAM permissions.

How it manifests in AWS: Two variants. In the opportunistic case, an attacker discovers a public S3 bucket (no authentication required — just a GET request to the bucket URL) and downloads its contents. In the credential-theft case, the attacker uses stolen IAM credentials to call s3:GetObject on private buckets they’ve identified through the discovery phase. The credential-theft variant is more dangerous because it targets intentionally private data — customer records, financial reports, database backups stored in S3.

Detection signal: For public bucket access, there’s no IAM event — the requests don’t go through the AWS authentication layer, so they don’t appear in CloudTrail data events. S3 server access logs are the only source. For credential-based access, CloudTrail data events on S3 (when enabled) will show high-volume GetObject calls from a principal that doesn’t normally exhibit that pattern, or from external IP addresses. Key metric: GetObject calls per minute per IAM principal exceeding 10x the 30-day baseline for that principal.

Mitigation: Enable Block Public Access at the AWS account level — this prevents any new public bucket configuration and can be enforced via SCP. Apply bucket policies that deny s3:GetObject from requests not originating via a VPC endpoint (aws:sourceVpce condition). For particularly sensitive buckets, add aws:PrincipalOrgID conditions to ensure only principals from your own AWS organization can access the bucket.

T1552 — Unsecured Credentials

What it is: The attacker finds credentials stored insecurely within the environment itself — in EC2 instance user data, Lambda environment variables, unencrypted SSM parameters, or hardcoded in application configuration.

How it manifests in AWS: EC2 user data is the most overlooked. User data scripts run at instance launch and often contain credentials passed in as environment variables to bootstrap configuration management. Critically, this user data is retrievable by anyone with ec2:DescribeInstanceAttribute on that instance — including an attacker who has compromised a low-privilege role. Lambda environment variables are similarly exposed: any principal with lambda:GetFunctionConfiguration can read all environment variables for that function in plaintext (unless encrypted with KMS, which requires opt-in and a separate key ARN). SSM Parameter Store has both SecureString and String types — String parameters are stored and returned in plaintext and appear in CloudTrail reads without any indication the requester is accessing secrets.

Detection signal: Watch CloudTrail for ec2:DescribeInstanceAttribute calls where the attribute is userData, particularly from principals that don’t own or normally interact with those instances. Similarly alert on lambda:GetFunctionConfiguration calls from principals that are not the Lambda service or the function’s owner. Anomalous ssm:GetParameter calls on parameters named with patterns like *password*, *secret*, *key*, or *token* from unexpected principals are also high-signal.

Mitigation: Store secrets in AWS Secrets Manager (not SSM Parameter Store String type) and reference them at runtime via the Secrets Manager SDK. Enforce this via SCP by denying ssm:PutParameter for parameters with names matching sensitive patterns unless a KMS key is specified. For Lambda, use Secrets Manager references in environment variables (Lambda supports this natively) rather than plaintext values. Regularly audit EC2 user data across the fleet with a Config rule or periodic describe-instance-attribute sweep.

T1580 — Cloud Infrastructure Discovery

What it is: After gaining initial access, the attacker enumerates the cloud environment to understand its topology, identify high-value targets, and find paths to privilege escalation.

How it manifests in AWS: A burst of Describe* and List* API calls across multiple services within a short time window. The canonical pattern is: iam:ListUsers, iam:ListRoles, iam:ListPolicies, iam:GetPolicyVersion, ec2:DescribeInstances, ec2:DescribeSecurityGroups, ec2:DescribeVpcs, rds:DescribeDBInstances, s3:ListBuckets, secretsmanager:ListSecrets, lambda:ListFunctions. Each of these calls is individually benign — they’re read-only and appear in automation tooling constantly. The signal is the cross-service breadth from a single principal within a compressed time window.

Detection signal: Establish a per-principal baseline of which service namespaces are called in a normal hour. A principal that normally calls s3:* and lambda:* suddenly calling iam:*, rds:*, ec2:*, and secretsmanager:* within the same 10-minute window is anomalous regardless of whether each individual call is authorized. An EventBridge rule can detect >50 distinct API calls from a single principal in a 5-minute window by aggregating CloudTrail via CloudWatch Metrics. GuardDuty’s Recon:IAMUser/MaliciousIPCaller finding covers the case where the calling IP is known-malicious.

Mitigation: Least-privilege IAM roles limit the utility of discovery even when it occurs — an attacker who can only call lambda:UpdateFunctionCode on a specific function gets little value from broad enumeration. Enable AWS Config to continuously evaluate IAM policies for cross-service wildcard permissions. Use IAM Access Analyzer to identify and eliminate roles with overly broad List* and Describe* permissions at the organization level.

T1619 — Cloud Storage Object Discovery

What it is: The attacker enumerates the contents of cloud storage — listing S3 buckets and then listing the objects within them — to identify which data is worth exfiltrating.

How it manifests in AWS: A two-stage sequence: s3:ListBuckets to get the complete list of buckets in the account, followed by s3:ListObjectsV2 on each bucket to enumerate objects by prefix and key. An attacker looking for database backups will look for prefixes like backups/, dumps/, exports/. An attacker looking for financial data looks for prefixes like reports/, finance/, invoices/. The enumeration itself doesn’t copy any data, but it directly precedes exfiltration (T1530) in virtually every observed incident.

Detection signal: s3:ListBuckets calls are management events, always logged. Alert on s3:ListBuckets from any principal that hasn’t made this call in the prior 30 days. For s3:ListObjectsV2, this is a data event and requires explicit enabling — but if you have S3 data events enabled on your sensitive buckets, calls to ListObjectsV2 on those buckets from unexpected principals should fire an alert. GuardDuty’s S3/BucketEnumeration finding aggregates these signals automatically.

Mitigation: The key defense against T1619 as a precursor to T1530 is S3 Block Public Access plus VPC endpoint policies. Even if an attacker can enumerate your bucket list via s3:ListBuckets, a bucket policy requiring aws:sourceVpce means they cannot download anything unless they’re inside your VPC — which requires a separate compromise. Combine with S3 Glacier Instant Retrieval for sensitive archives: the objects are still accessible, but bulk retrieval takes longer, giving detection systems more time to fire.

Building Detection Across All Five Techniques

Each of these techniques has detectable signals in CloudTrail when the right logging is in place. The common infrastructure requirements are: multi-region CloudTrail with management events, S3 data events on sensitive buckets, GuardDuty enabled in all regions, and a SIEM with per-principal behavioral baselines.

MITRE ATT&CK isn’t just a taxonomy — it’s a detection checklist. For each technique in the matrix, ask: do we have logging that would capture this? Do we have an alert rule that would fire on it? Would we notice within an hour, a day, or a week? The answers tell you exactly where to invest next.