> ## Documentation Index
> Fetch the complete documentation index at: https://docs.samschroeder.lu/llms.txt
> Use this file to discover all available pages before exploring further.
# ThreatLab Exercises: SOC Training Scenarios Explained
> Exercises are ThreatLab's core training unit — realistic SOC scenarios with ordered investigation steps, log archives, and expected artifacts to submit.
Exercises are ThreatLab's fundamental training unit. Each exercise pairs a real log archive with a structured sequence of investigation steps so you work through a SOC scenario the same way you would in production — inside your own SIEM, against real events. As you complete each step you submit findings as artifacts, and ThreatLab tracks your progress automatically.
## Exercise Anatomy
Every exercise is made up of the following fields:
A short, descriptive name that identifies the scenario. Displayed on the exercise card and in learning path listings.
A narrative overview of the scenario — the threat context, the environment, and what you are expected to investigate.
One of four tiers: **Easy**, **Medium**, **Hard**, or **Expert**. Difficulty reflects the complexity of the log data and the depth of analysis required.
The estimated time to complete the exercise, expressed in minutes.
The score awarded when you submit all required artifacts and complete the exercise.
One or more ATT\&CK technique or tactic identifiers that map the scenario to the MITRE framework. Use these to build targeted skill coverage across your team.
One or more log archive sections, each carrying LEEF and/or ECS payloads. ThreatLab selects the correct payload format at exercise start based on your SIEM destination. Each section can optionally carry [staged release rules](#section-release-rules) so it ships to the SIEM mid-attempt instead of at start.
An ordered list of steps that guide you through the scenario. Each step carries a prompt and one or more expected artifact values you must submit to advance.
## Archive Formats
ThreatLab supports two log payload formats so exercises can target any supported SIEM:
Log Event Extended Format. Used by **Splunk**, **QRadar**, and any syslog TCP-compatible SIEM. LEEF archives ship as structured key-value event lines.
Elastic Common Schema. Used by **Elasticsearch**. ECS archives contain JSON documents formatted for bulk indexing.
Both LEEF and ECS are **fully supported author-time formats**. When you paste or upload raw logs, ThreatLab detects each row independently:
* **LEEF** is recognised by its `LEEF:|vendor|product|...` header.
* **ECS** is recognised when the row is JSON or NDJSON with an `@timestamp` field and at least one ECS-like field (`event.*`, `host.*`, `source.*`, `destination.*`, `log.*`, `process.*`, `user.*`, or a non-empty `message`).
A single exercise can carry both LEEF and ECS archives simultaneously, so it can be assigned to analysts on different SIEM stacks. When ECS or unknown rows are mixed with LEEF, or when the destination needs a format that doesn't match the raw input, ThreatLab uses **SyslogCanon** to canonicalise the rows and produce the missing side. SyslogCanon is required whenever:
* You enable **Convert to LEEF** on a section.
* A row is detected as ECS but a LEEF destination (e.g. `splunk_hec`, `syslog_tcp`) is enabled.
* A row is detected as LEEF but an ECS destination (e.g. `elastic_bulk`) is enabled.
* Any row is detected as unknown.
If SyslogCanon is unavailable in any of these cases, ThreatLab blocks the publish with an error that names the affected SIEM and format.
**Accepted upload formats** when authoring an exercise: `.zip`, `.tar.gz`, `.tgz`, or paste log text directly into the editor (ThreatLab packs pasted content into a ZIP automatically).
## Section Release Rules
By default, every archive section ships to the SIEM the instant an analyst starts the exercise. That **immediate shipping** model is still the default — you do not need to configure anything for it.
Sections also support an optional **staged release** model so authors can hold individual sections back until specific conditions are met. Each section can declare:
* A **release delay** — minutes after the attempt starts before the section becomes eligible.
* One or more **artifact gates** — expected artifacts that must be submitted before the section becomes eligible.
* A **release condition** that combines them: `delay_only`, `artifacts_only`, `delay_and_artifacts`, or `delay_or_artifacts`.
* An **artifact gate mode** of `all` or `any` when more than one gate is linked.
A section with no delay and no gates always ships immediately, exactly like classic exercises. ThreatLab evaluates the release rules continuously during an attempt and ships each section to the configured SIEM destination as soon as it becomes eligible — the analyst sees per-section status updates on the exercise detail page.
At publish time, ThreatLab runs a **release deadlock check** that blocks an exercise from going Active if no section can release at start, or if a section is gated by an artifact that almost certainly lives in its own logs. Authors can confirm and override the block when the deadlock is intentional.
See [Authoring exercises](/guides/authoring-exercises) for how to configure these rules and [Running exercises](/guides/running-exercises) for how analysts experience them.
## Exercise Lifecycle States
An exercise moves through four states from authoring to analyst completion:
A working state for authors. The exercise is invisible to analysts and does not appear in learning path progress. Drafts are server-backed and **autosaved** — once a title is set, metadata, steps, and section shells persist automatically without uploading archives, finalizing live TCP intakes, or provisioning SIEM indexes. Description, steps, and archives can be incomplete while in draft. See [Author exercises](/guides/authoring-exercises#draft-autosave) for the autosave UX and [Draft vs publish validation](/guides/authoring-exercises#draft-vs-publish-validation) for which checks fire at each stage.
The exercise is published and visible to analysts. It appears in the exercise catalog and counts toward learning path progress. Toggling **Active** on runs the full strict validation pipeline — archive validation, LEEF/ECS readiness checks, deadlock checks, live TCP finalization, and SIEM index provisioning — before the exercise goes live.
An analyst has started the exercise but has not yet submitted all required artifacts. Partial progress is auto-saved after every submission.
The analyst has submitted accepted artifacts for every step. A completion record is created and points are awarded.
## Step Artifacts
Each investigation step defines one or more **expected artifact values** — the answers you are expected to extract from the log data. When you submit a response, ThreatLab matches it against the expected value using **case-insensitive, whitespace-trimmed equality**, so minor capitalisation differences do not cause incorrect failures.
Your progress is auto-saved after every step submission. If you close the exercise and return later, you will pick up exactly where you left off.
## Investigation Notebooks
While working through an exercise you can maintain a private **investigation notebook** — a scratchpad attached to your session. Notebook entries are organised into four categories:
| Category | When to use it |
| --------------- | ---------------------------------------------------------------------- |
| **Observation** | Raw facts you notice in the log data — timestamps, IPs, user accounts. |
| **Hypothesis** | Theories about what the threat actor may have done or intended. |
| **Finding** | Conclusions you are confident enough to include in a report. |
| **Other** | Anything that does not fit the above categories. |
Notebooks are private to you by default. Instructors or administrators with the `review_notebooks` capability can read your notes for coaching and assessment purposes.
Only users with the **Author exercises** (`manage_exercises`) capability can create or edit exercises.