Leaked Cloud Key Lab
An AWS access key lands in a public repository. Four minutes later it is being used. Within the hour there are GPU miners in regions you never use and someone has looked at your customer bucket. Make eight to ten scored decisions and see how each one changes the story.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A developer at Contoso Freight pushes a commit to a public repository. It contains an AWS access key. Within minutes someone is using it. You are the incident lead: contain the key and the sessions it already minted, sweep every region, find the persistence, decide what the logs can and cannot prove about the data, and deal with the bill. Choices change the story.
Make it yours
Replace the sample names so the scenario and the debrief you export are about your organisation.
What this template gives you
- A realistic timeline: the key is pushed at 14:02, scraped by 14:06, mining in sa-east-1 by 14:09.
- Choices branch: deleting the key breaks production, terminating miners too early destroys evidence and they come back, and missing the quiet backdoor lets the attacker return two days later.
- Teaches the containment order that matters: key, live sessions, every region, persistence, then cleanup — and an honest data-access answer when object-level logging was off.
- Rename the organisation, repository and bucket so the debrief you export fits your own environment.
Frequently asked questions
Should I delete or deactivate a leaked AWS access key?
Deactivate first. Setting the key to Inactive stops it working, is reversible if something important breaks, and keeps the key ID tied to the user while you investigate. Delete it once you have moved its legitimate consumers to a new credential and finished the investigation. Either way, deal with sessions the attacker already created with the key — they can outlive it.
Why do attackers launch instances in regions I do not use?
Because nobody looks there. Owners check the console in their home region, see nothing and assume all is well. Attackers spread GPU instances across several unused regions and often add an auto-scaling group or scheduled function so terminated instances come back. Sweep every enabled region by script and deny unused regions with an organisation policy.
How can I tell if a leaked key was used to download data from S3?
Only if object-level logging was on: CloudTrail data events for S3 or S3 server access logs. Management events show bucket-level calls such as listing buckets or reading a bucket policy, but not reading individual objects. If neither was enabled, you cannot rule out access, and that is what you tell counsel.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free 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.