Red Team Lab Engineering Standard
Every lab in this track is an offensive-engineering exercise that teaches a technique and its detection, not a command transcript and not a weapon. The boundary from the overview is enforced at the lab level by three rules:
- Synthetic or owned inputs only. Labs reason over synthetic metadata (event logs, host facts, IAM policies, network graphs, captures) or fixtures you own. No live targets.
- No weaponization. A lab may model, analyze, plan, or detect a technique. It must not be a deployable implant, a working EDR bypass, a real C2 beacon, or an exploit pointed at third parties.
- Every offensive lab ships its detection. If a lab demonstrates an attacker behavior, it also produces the telemetry that behavior emits and a detection (Sigma-style logic or a test) that fires on it. This is what makes the offensive knowledge a defensible, hireable asset.
Required Files
| File | Contract |
|---|---|
README.md | the problem, what you build, the ATT&CK mapping, attack cases the tests cover, run commands, hardening/detection, extensions, interview/resume, limitations |
lab.py (or language equivalent) | learner implementation with focused TODOs; never a blank file |
solution.py (or equivalent) | complete reference with safe defaults, deterministic output, and an explicit limitations note in the docstring |
test_lab.py (or native tests) | positive, negative, adversarial, boundary, and determinism tests, runnable against either module |
| dependency/build manifest | requirements.txt (usually empty/stdlib), Cargo.toml, .csproj, or Makefile; minimal and pinned where practical |
The runnable core is Python (stdlib + pytest), offline, deterministic. Multi-language work (C#/C/C++/Rust/Nim) appears as build specs in the README "extensions" section that the learner implements in their own isolated range.
The two guides per phase
WARMUP.md — explain the technique from zero
A self-contained, zero-to-principal guide. It must contain, in order:
- A table of contents with working anchor links (kept updated).
- One chapter per concept, each covering: zero background → what it is → why it exists → how it works under the hood (mechanism, with diagrams/tables/small code) → what telemetry it emits → how a defender detects it → production/engagement significance → common misconceptions.
- A Lab Walkthrough section: the order to tackle the TODOs and why.
- Success criteria tied to understanding, not just "tests pass."
- Common mistakes / OPSEC failures.
- Interview Q&A with full, principal-level answers.
- A References section (primary sources: ATT&CK, RFCs, vendor internals docs, talks, books).
mdBook-compatible: MathJax for any math, standard Markdown only, no bare <...> angle brackets in
prose (wrap in backticks).
HITCHHIKERS-GUIDE.md — operate it on the range
The operator's range walkthrough: a purpose-built authorized range, the build/observe workflow, safe attack fixtures with expected observations, the hardening/detection tied to the mechanism it changes, runtime verification that proves effective state (not intended config), the telemetry/detection/ triage path, teardown and cost controls, the evidence packet, and the common false claims.
Required Learning Loop
- Authorize — owner, scope, methods, data, time, rates, stop conditions, deconfliction.
- Plan — map the intended technique to ATT&CK; state the OPSEC profile (what it will emit).
- Emulate safely — run the seeded case only against the owned fixture / synthetic data.
- Observe — collect the log, packet, graph, policy decision, or evidence manifest.
- Explain — separate precondition, root cause, demonstrated impact, and plausible impact.
- Detect — produce the telemetry the behavior emits and a detection that fires on it.
- Harden — change design/config/identity, not only the triggering input.
- Regress — prove the attack path is closed and legitimate behavior still works.
- Communicate — write the developer/defender remediation and the executive decision summary.
Test Taxonomy
Every flagship lab includes: happy-path; malformed/oversized input; deny-by-default behavior; cross-scope/cross-tenant/privilege-negative cases where relevant; replay/duplicate/idempotency where relevant; a detection-fires test for the seeded behavior; regression for every seeded weakness; and deterministic output.
Safety Rules
- Use only included fixtures, owned local services, CTFs, or explicitly authorized engagements.
- Do not target public hosts, neighboring networks, real users, or third-party infrastructure.
- Do not commit working implants, real C2, credential-theft tooling, or live exploits.
- Stop at minimum proof; preserve only the data needed to explain and remediate.
- Any range exercise involving vulnerable services, AD forests, cloud accounts, or malware-like samples must pass templates/lab-acceptance-checklist.md.
Definition of Done
A lab is complete only when the reference suite passes, the learner implementation passes after the TODOs are filled in, the setup works from a clean checkout, the detection pairing is present, and the README states the limitations honestly.