AWS Account Compromise Lab: GuardDuty and CloudTrail
It is 02:14 UTC and GuardDuty says the credentials of an EC2 instance role are being used from outside AWS. Triage it, revoke the session, scope it with CloudTrail, find what the attacker left behind and close the gap. This lab is about a stolen role session, not a leaked key; for a leaked key, try the Leaked Cloud Key Lab. For prevention, see the AWS Hardening Lab and the Secure AWS architecture guide.
You are Sam Rivera, the on-call security engineer at Quillstack Software. At 02:14 UTC a GuardDuty finding lands for the production workload account (111122223333). Across 11 decisions you triage, contain, scope with CloudTrail, find persistence, judge data exposure, fix the root cause and set guardrails. Everything is fictional: the account ids are AWS documentation examples, the addresses are reserved test ranges, and no exploit or command appears. Each call is scored 0 to 10 with the AWS documentation behind the rationale. This is a different incident from the Leaked Cloud Key Lab: the stolen credential here is a short-lived role session, not a long-term access key.
Make it yours
Replace the sample names so the scenario and the debrief you export are about your organisation.
TL;DRWhat this lab is
5 points
- A scenario lab: a GuardDuty finding says temporary credentials from an EC2 instance role are being used from outside AWS. You make 11 scored decisions, from triage to guardrails.
- It covers what makes this different from a leaked access key: the credential is a short-lived role session, so you revoke sessions rather than deactivate a key, and you isolate the instance instead of terminating it.
- You scope the session with CloudTrail, handle a 40-minute logging gap, find persistence (a new IAM user and an external principal in a trust policy), judge data exposure when object-level logs were never on, and fix the root cause.
- Each decision is scored 0 to 10 with the AWS documentation behind it, read on 4 November 2026. Wording is ours; nothing is copied from AWS.
- Free to play. Fictional account ids (111122223333, 444455556666), reserved test addresses, no exploit code or commands. The debrief can be downloaded through the usual download gate.
Frequently asked questions
What does the lab teach?
How to respond when temporary AWS credentials from an EC2 instance role are used from outside AWS. You practise triage, revoking role sessions, isolating an instance without destroying evidence, scoping with CloudTrail, handling a logging gap, removing persistence, judging data exposure, fixing the root cause and setting organization guardrails.
How is it different from the Leaked Cloud Key Lab?
The Leaked Cloud Key Lab is about a long-term access key (the AKIA kind) found in a public repository. This lab is about a temporary role session (the ASIA kind) taken from an instance. That changes containment: you cannot deactivate a temporary key in the console, you revoke the role's sessions instead.
Is the scenario based on a real incident?
No. It is a fictional composite built from AWS documentation of the GuardDuty finding types, IAM session revocation, CloudTrail and the Well-Architected Security Pillar. The company, accounts, addresses and bucket names are invented.
Does it contain attack instructions?
No. There is no exploit, payload or command. The weakness is described in words, and every account id and address is a documentation or reserved test value.
How is it scored?
Each decision scores 0 to 10 and your final score is the share of the maximum, with a band from "Still in the account" to "Contained and scoped". Feedback names the AWS page behind the rationale.
Is it free?
Yes, you can play it free. Downloading the debrief as a document goes through the site download gate.
Sources
AWS documentation pages read on 4 November 2026. The scenario is fictional; the controls and finding names are from these pages.
- Amazon GuardDuty: IAM finding types
- Amazon GuardDuty: Remediating potentially compromised AWS credentials
- AWS IAM: Revoke IAM role temporary security credentials
- AWS IAM: Temporary security credentials in IAM
- AWS CloudTrail: What is AWS CloudTrail?
- AWS CloudTrail: Creating a trail for an organization
- AWS CloudTrail: Validating CloudTrail log file integrity
- AWS CloudTrail: Logging data events
- Amazon VPC: Control traffic to your AWS resources using security groups
- AWS IAM: What is IAM Access Analyzer?
- Amazon EC2: Use instance metadata to manage your EC2 instance (IMDSv1 and IMDSv2)
- Amazon EC2: Configure instance metadata options for new instances
- AWS Organizations: Service control policies (SCPs)
- AWS Organizations: Service control policy examples
- Security Pillar: Incident response
- Security Pillar: Detection
- Security Pillar: AWS account management and separation
- AWS SRA: Security OU, Security Tooling account
- AWS SRA: Security OU, Log Archive account
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.