CloudTrail Anomaly: Correlating a Credential-Compromise Chain
The challenge
These are CloudTrail events from your AWS account. One access key fails to log in a few times, then suddenly assumes a privileged role and starts reading objects out of the finance bucket from a region you never use. The other keys are doing their normal jobs. Correlate the chain - failed logins, then AssumeRole, then GetObject - and submit the compromised access key id.
What you'll learn
- Read CloudTrail events as a per-credential timeline rather than a flat list
- Correlate ConsoleLogin failures, AssumeRole, and GetObject into one attack chain
- Use region as an anomaly signal for credential misuse
- Distinguish a compromised key from keys doing normal single-purpose work
- Attribute a cloud intrusion to a specific access key id
Skills tested
Prerequisites
- Basic AWS IAM concepts (access keys, roles, AssumeRole)
- Familiarity with S3 and CloudTrail event names
- Understanding of AWS regions
How it works
In the cloud, an attack rarely shows up as a single bad event. A stolen credential is used in a sequence: get in, escalate, then reach the data. CloudTrail records each of those steps as a separate event, so the skill is to stop reading rows individually and start reading the timeline for one principal - here, one accessKey - across several event types and fields.
Follow AKIA9XPLOIT77 in time order and the whole intrusion lines up: three ConsoleLogin failures (password guessing), then a ConsoleLogin success, then an immediate AssumeRole on role/FinanceAdmin (privilege escalation), then a sustained run of GetObject calls pulling files out of s3://finance-bucket - payroll, bank accounts, wire transfers, tax records. Two extra signals confirm it: the target is a sensitive bucket, and every event for this key comes from ap-south-1, a region the account otherwise never touches. The benign keys each do one consistent job in eu-west-1.
This is what d4 correlation looks like: no single column gives the answer. event:AssumeRole alone shows an escalation, event:GetObject alone shows reads, and the region alone shows an oddity - but only by stitching the same access key across all of them does the compromise become undeniable.
Common mistakes
- Judging a single event. One failed login or one GetObject is normal; the answer is the key whose whole sequence forms an attack chain.
- Ignoring the region column. The anomalous
ap-south-1region is a strong confirmation that the benigneu-west-1keys lack. - Picking the role instead of the key.
role/FinanceAdminwas abused, but the question asks for the access key id that assumed it. - Blaming AKIA4FINANCE01 for touching S3. That key reads its own reports bucket in the normal region - it never escalates and never touches finance-bucket from a foreign region.
How to defend against it
Cloud credential compromise is detectable because the attack chain is noisy in CloudTrail. Build detections on the same correlation you just did by hand.
- Alert on repeated
ConsoleLoginfailures followed by a success for the same principal. - Alert when a key calls
AssumeRoleon a privileged role it has never used, especially from a new region. - Enforce MFA on console logins and rotate or scope down long-lived access keys.
- Flag access to sensitive buckets like
finance-bucketfrom any region outside your normal operating region.