Submit a Lab
Did you know Mad Hat Labs takes community-built cloud security labs? If you have found a misconfiguration worth teaching or an attack path you want to showcase, we want to see it!
Do not build the lab yet. Send us the idea, and we will tell you whether it has a path to acceptance before you spend a weekend writing Terraform. The requirements below exist so you can gut-check your own concept first. Most rejections are scenarios that cost too much to keep running or that cannot survive a shared tenant.
01 WHAT WE TAKE
We build cloud security labs. Not boxes that happen to live in a cloud. There's enough box makers already.
- Misconfiguration hunts. A default nobody changed, a permission that outlived its project, a setting that looks fine until you understand what it actually allows.
- Identity and privilege paths. Anything where a workload identity, a role assignment, or a trust relationship gets a learner somewhere they should not be.
- Detection and telemetry hunts. The signal is in the logs and the job is to find it. No exploitation required.
- Incident reconstruction. The breach already happened. Rebuild it from what the platform recorded.
- Policy and IaC review. The flaw is in the template, before anything is even deployed.
What we do not take: a Linux privilege escalation within a virtual machine. If your scenario would work identically on a single laptop, it is not a cloud lab. The cloud has to be the reason the flaw exists.
02 COST AND FOOTPRINT
Read this one first! More good ideas die here than anywhere else on this page.
- A lab sitting idle must cost under $15 USD a month. The less the better and gets accepted faster.
- Reach for consumption and serverless tiers by default. If the lesson does not require a machine that is switched on, do not switch one on.
- No GPU SKUs. No premium, provisioned, or dedicated tiers unless the flaw genuinely lives in that tier.
- Where compute is unavoidable, use burstable sizes and ship an auto-shutdown schedule with it.
- Tell us the estimated monthly cost and how you worked it out. A number with no reasoning behind it reads as a guess, because it is one.
- If the lab writes logs, tell us the expected gigabytes per month. SIEM ingestion bills by volume and will become the largest thing on the invoice while you are only looking at compute.
- Never require a learner to spend their own money to complete the lab. Open source and free stuff is obviously fair game.
03 BLAST RADIUS
Our labs run in a shared tenant. Yours has to play nice with everything else in it.
- The learner identity is read-only unless the lesson makes that impossible. Where writes are genuinely required, scope them to one resource group, project, or account and nothing wider.
- Never require subscription Owner, AWS root, or organisation-level admin.
- Nothing the lab creates may touch anything outside its own boundary.
- No real credentials, no real customer data, no live third-party keys. Not expired ones either.
- Simulated exfiltration terminates inside the lab or inside synthetic telemetry. Nothing leaves for a real destination.
- One learner must not be able to ruin it for the next. If a resource can be renamed, emptied, or deleted, ship the automation that puts it back.
- A flag must never sit somewhere the learner needs write access to reach.
04 BUILD STANDARDS
- Labs arrive as infrastructure as code: Bicep or ARM, CloudFormation, Deployment Manager, or Terraform. A sequence of portal clicks is a description, not a build.
- One command stands it up. One command takes it down and leaves nothing behind. Orphaned resources are a defect.
- Deployment is idempotent. Run it twice, get the same estate, not two of them.
- Names take a prefix and a unique suffix so cohorts can run in parallel. Storage accounts, buckets, and vaults are globally unique and will collide.
- Any synthetic addressing uses the documentation ranges reserved for exactly this (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). Attacker domains in a scenario must resolve to nothing.
- No licensed software, no paid marketplace images, no trials that expire mid-cohort.
- US English throughout.
- The estate must read like a company that exists. Tags, names, and app content should look inherited from a real team under deadline. If it reads like a demo, it teaches like one.
05 EVIDENCE AND FLAGS
- Planted flags use
MadHat{lower_case_with_underscores}. - We prefer flags that are real values read off the platform: a role name, an account name, a detection threshold, the result of a query. When the answer is the evidence, submitting it proves the work.
- Every flag must be unobtainable without doing the step. If a sharp learner can infer it from the briefing, it is decoration.
- Flags can live in an object, a secret, a resource tag, a configuration value, or a query result. Tell us exactly which, down to the path.
- Values that expire, rotate, or regenerate need to be flagged as such. We will be running this lab long after you stop thinking about it.
06 TELEMETRY LABS
If the job is hunting rather than exploiting, this section is the whole submission.
- Ship the generator, not the data. Seeded and deterministic, so every cohort hunts identical events.
- Bury the signal in credible noise. A dataset where the answer is the only row is a lookup, not a hunt.
- Include at least one honest decoy: something that defeats the obvious query and rewards the better one. Volume-based reasoning should fail before technique-based reasoning succeeds.
- Never ship data exported from a real tenant, however scrubbed you think it is.
- State the retention window and refresh cadence. Frozen timestamps slide out of relative-time queries and kill a lab months later without a single error message.
- If your evidence has to live in a managed table you cannot write to, say so, and explain how it gets generated for real instead.
07 DOCUMENTATION
Required when you submit the build. Not needed for the pitch below.
- The intended path, start to finish, in something we can edit. Markdown preferred.
- All templates, deploy scripts, teardown scripts, and generators.
- The exact permissions the learner needs, including any directory or identity roles that sit outside the resource permission model. This is the single most common omission we see.
- Every flag, its location, and its value.
- Any step that cannot be scripted and has to be clicked, written out.
- Estimated cost and log volume.
- Anything that expires or needs regenerating on a schedule.
- Which platform behaviours the path leans on, so we know what a provider update might quietly break.
08 DIFFICULTY
Rated by how far the learner has to reach, not by how many commands they type.
WHITE HAT
- Lives inside a single service
- The flaw is visible in the console to someone who knows which page to open
- No identity pivot
- Reading configuration, not writing queries
- Each step follows plainly from the last
GREY HAT
- Crosses two services, or one service and its telemetry
- One identity pivot, or one query the learner has to write
- Requires joining two facts the console never shows together
- Signposted enough that a careful operative will not stall
BLACK HAT
- Three or more services in the chain
- Demands understanding of the trust model, not just the interface
- At least one step exists only in the logs, never in configuration
- Enumeration expected; the route is not marked
MAD HAT
- Crosses an account, subscription, tenant, or cloud boundary
- Chains flaws that are each individually defensible
- Learner writes their own tooling or non-trivial queries
- Dead ends allowed where the dead end itself teaches something
Difficulty should come from the depth of the reasoning, not from withholding information. A lab nobody can finish is an unfinished one.
09 AUTOMATIC REJECTIONS
No review, no discussion. Check yourself against this list before sending.
- The author never deployed it. We will find the step that has never worked, usually inside ten minutes.
- It cannot be torn down cleanly.
- It needs Owner, root, or organisation admin.
- It contains real credentials, real customer data, or a live third-party key.
- It costs more than the cap with no justification attached.
- It only works inside your account, your tenant, or your subscription.
- A flag sits behind write access.
- It targets a real company, product, or person by name.
- It leans on a preview feature without saying so.
- It contains anything degrading, or content included purely to provoke.
10 ON AI ASSISTANCE
Draft with whatever tools you like. What we will not accept is a lab or a walkthrough you have not personally deployed and verified end to end. Every command, every permission, every flag location has to be something you confirmed with your own eyes in a live environment. The tell is always the same: a step that reads perfectly and has never once been run.