AWS incident response example: leaked key to crypto-mining

Fictional scenario. Everything in this post — the company, the people, account 111122223333, the keys, the bucket — is invented. IP addresses come from the documentation ranges of RFC 5737. It is the data behind the Try a sample button on the analyzer, so you can reproduce every step.

TL;DR. On the fictional 14 September 2026, developer dev-marco's access key is used from a VPS running Kali Linux. In 48 minutes the attacker validates the key, enumerates the account, creates an administrator user backup-admin with its own key and console password, deletes GuardDuty in two regions, downloads 320 objects from acme-customer-exports and launches eight GPU instances in ap-southeast-1 that mine to a pool. The logs show all of it. The verdict is Compromised, and the remediation list has to cover two keys, one user, one policy, two detectors, eight instances and a notification assessment.

The evidence

The sample ZIP mirrors real exports:

Four quiet days (10–13 September) give the baseline: ops-julia signs in to the console with MFA from the office address 198.51.100.24; dev-marco uses the CLI with his long-term key from the same address; an ECS task role is assumed daily.

Timeline (UTC, 14 September 2026)

The credential report adds a posture finding: backup-admin has a console password and no MFA.

How the investigation unfolds

1. The verdict. Twenty-three findings, several of them high-severity with attacker-side signals (access anomaly, defense evasion, exfiltration, impact): the verdict is Compromised. The main reasons listed are the offensive user agent, the key used from a new IP, the admin policy, the key created for another user and the two GuardDuty deletions.

2. The entry point. Pivot on AKIA3EXAMPLEMARCO123 in the Entities tab: four days from 198.51.100.24 with a macOS CLI, then, from 09:02, 203.0.113.77 with a Kali build string. The very first call from the new address is GetCallerIdentity — the textbook leaked access key opening. How the key leaked (the scenario says a public repository) is outside AWS logs.

3. The second key. Pivot on 203.0.113.77: besides dev-marco's key it used AKIA3EXAMPLEBKUP4567, the key minted at 09:09:05 for backup-admin. From 09:12 on, the attacker never uses the leaked key again. Deactivating only dev-marco's key would have changed nothing. This is the IAM persistence pattern in its plainest form.

4. Defense evasion. Both detectors are deleted within a minute, three minutes after the backdoor exists. CloudTrail itself is left running — no StopLogging — which is why the rest of the story is visible. GuardDuty findings survive only because they had been exported; see the defense evasion post.

5. The data. 320 GetObject in 21 minutes from one principal on one bucket, seen twice: in CloudTrail data events and in server access logs. The object keys (exports/2026/customers/customers-0001.csv.gz to -0320) are the disclosure inventory. Note that VPC Flow Logs show nothing here: the download went from S3 to the attacker's host over the internet, never through the VPC — exactly the limit described in S3 data exfiltration evidence.

6. The cost. A region with no activity during the baseline, a quota increase, a key pair, SSH open to the world and eight GPU instances; from 09:52 their interfaces talk to one address on pool ports every minute. The crypto-mining post covers this phase.

7. The console session. At 09:50 the attacker signs in as backup-admin without MFA. Anything done in the console from then on would appear with sessionCredentialFromConsole; in this dataset the session ends the story.

The remediation list it produces

Containment first, with values from the logs:

1. Deactivate AKIA3EXAMPLEMARCO123 and AKIA3EXAMPLEBKUP4567; replace dev-marco's key and scrub it from the repository.
2. Save, then delete backup-admin (policy, key, login profile).
3. Detach AdministratorAccess from backup-admin and review other holders.
4. Deny API calls from 203.0.113.77 while investigating.
5. Snapshot one instance, terminate the eight in ap-southeast-1, check every other region; delete key pair ops-maint and the open security group; withdraw quota request L-417A185B.
6. Re-enable GuardDuty in us-east-1 and eu-west-1 (ideally everywhere).
7. Treat acme-customer-exports as exfiltrated: list the 320 objects, assess notification duties.
8. Open an AWS Support case about the unauthorised usage.

What this example does not show

Real incidents are messier: noisy CI roles, several attacker IPs, role chaining, activity spread over weeks, logs missing exactly where you need them. The sample is deliberately clean so the method is visible. Read the limits of log-only investigation before applying the same confidence to real data, and use the step-by-step analysis guide for the workflow.