Skip to main content
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 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:

LEEF

Log Event Extended Format. Used by Splunk, QRadar, and any syslog TCP-compatible SIEM. LEEF archives ship as structured key-value event lines.

ECS

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:<version>|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 for how to configure these rules and Running exercises for how analysts experience them.

​
Exercise Lifecycle States

An exercise moves through four states from authoring to analyst completion:
1

Draft

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 for the autosave UX and Draft vs publish validation for which checks fire at each stage.
2

Active

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.
3

In Progress

An analyst has started the exercise but has not yet submitted all required artifacts. Partial progress is auto-saved after every submission.
4

Completed

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:
CategoryWhen to use it
ObservationRaw facts you notice in the log data — timestamps, IPs, user accounts.
HypothesisTheories about what the threat actor may have done or intended.
FindingConclusions you are confident enough to include in a report.
OtherAnything 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.