| name | investigating-aws-incidents |
| description | Investigate a suspected AWS compromise from the control plane — CloudTrail management and data events (queried with Athena or CloudTrail Lake), GuardDuty findings, VPC Flow Logs, and CloudWatch — to reconstruct IAM/STS abuse, persistence, data access, and log tampering into a timeline. Use when the evidence is AWS API calls and cloud logs rather than a host. Preserve the logs before the attacker's retention or a StopLogging call erases them. |
| verified | 2026-08-08T00:00:00.000Z |
Investigating AWS Incidents
In AWS the crime scene is the API log, not the disk. Almost every action —
assuming a role, minting an access key, reading a bucket, turning off the trail —
is a CloudTrail event with an identity, a source IP, a user agent, and a
timestamp. The investigator reconstructs the intrusion from that record. The
urgency is that the record is itself a target: an attacker who reaches the
logging configuration can stop the trail or shorten retention, so preservation
comes before analysis.
Confirm the account is in scope per AGENTS.md, and treat
findings as sensitive cloud data kept in the engagement store. This skill is
read-only investigation; containment actions (revoking keys, isolating a role)
are the operator's call and belong to the wider incident.
When to Use
- A suspected AWS compromise where the evidence is control-plane logs
- Tracing IAM/STS abuse: AssumeRole chains, new users/keys, console logins
- Confirming data access or exfiltration from S3 and other services
- Finding cloud persistence (new principals, trust-policy edits) and log tampering
- Building an AWS attack timeline for an incident
When NOT to Use
- On-host artifacts of an EC2 instance — use (or acquire the disk/memory); this skill is the control plane
