Skip to main content
Noise log jobs ship LEEF events to your SIEMs on a recurring schedule, keeping your platform populated with realistic background traffic so that exercise investigations feel authentic. Without baseline noise, a SIEM used only for training exercises contains only exercise data, which makes it trivial for analysts to isolate events — noise jobs solve that problem by continuously replenishing the environment.

​
Prerequisites

Before creating your first noise job, confirm the following:

manage_noise_logs capability

Your role must include the manage_noise_logs capability. Contact your administrator if you do not see the Noise Jobs section.

SIEM destination configured

At least one SIEM destination must be configured under Admin > Resources before you can select a target for your job.

​
Creating a noise job

1

Open the Noise Jobs panel

Navigate to Admin > Resources > Noise Jobs and click New Job.
2

Enter job metadata

Give the job a name (up to 80 characters) and an optional description (up to 500 characters). Use a name that identifies the traffic type and destination — for example, Windows endpoint baseline – Splunk.
3

Upload log archives

Upload between 1 and 10 log archives in .zip, .tar.gz, or .tgz format. The archives must contain .txt or .log files. ThreatLab applies the same per-file and total size limits as exercise archives.
4

Choose a SIEM index per archive

For each archive, pick the SIEM index that should receive its events. See Per-archive index routing below for details.
5

Select SIEM targets

Choose between 1 and 20 SIEM destinations from the list of configured targets. Each selected SIEM receives an independent shipment — a failure on one target does not block delivery to the others.
6

Set the schedule

Choose a schedule type and configure it:
Set how often the job fires in seconds. The valid range is 60 to 86,400 seconds (1 minute to 24 hours). Optionally add jitter — up to 600 seconds, or up to the interval value, whichever is smaller — to randomise the exact fire time and avoid thundering-herd effects.
7

Enable and save

Toggle the job to Enabled and click Save. ThreatLab computes the first next_run_at value immediately. The job will fire at the next scheduled time without any further action required.

​
Per-archive index routing

Each archive in a noise job can be routed to its own SIEM index, so you can keep different traffic types (for example, Windows event logs versus firewall logs) separated inside the same SIEM destination. Routing is configured per archive when you create or edit a job and is persisted alongside the archive.

​
When to use it

Reach for per-archive index routing when you want to:
  • Keep different log sources (endpoint, network, identity) in separate indexes so analysts can scope searches.
  • Mirror your production index layout in training so dashboards and saved searches behave the same.
  • Ship a single archive into a brand-new index without touching your destination’s default.
If you don’t care about separation, leave every archive on the destination’s default index — that matches the original noise job behaviour.

​
Choosing an index for an archive

In the New Job or Edit Job dialog, each archive row exposes an index control with three options:
OptionWhat it does
DefaultShips events to the destination’s configured default index.
Existing indexPicks an index already known to ThreatLab — the catalog includes indexes used by exercises and by other noise archives.
New indexCreates a brand-new index. Enter the name in the adjacent field (maximum 120 characters). The name is validated and saved on the archive.
The Noise Jobs table summarises the index choice for each job so you can review routing at a glance without re-opening the dialog. When you save the job, ThreatLab attempts to provision any required indexes on the selected SIEM targets. For Splunk and Elasticsearch destinations this happens automatically. The create or update toast surfaces any warnings — most commonly when a target needs manual setup (see the syslog TCP note below).

​
How events get routed at run time

When the job fires, the orchestrator groups events by archive index and ships each group with the right routing:
  • Splunk and Elasticsearch — events are written to the per-archive index. Default-routed archives keep using the destination default.
  • Syslog TCP (LEEF) — each LEEF line gets an extra threatlabIndex= extension so downstream collectors can route the event. Other LEEF fields are untouched.
  • ECS payloads — grouped per archive index in the same way as LEEF before being indexed.
For example, a LEEF line bound for a custom windows_endpoint index arrives over syslog TCP looking like: 
LEEF:2.0|ThreatLab|NoiseLogs|1.0|login_success|src=10.0.0.5	usrName=alice	threatlabIndex=windows_endpoint

​
Syslog TCP requires manual index setup

ThreatLab cannot create indexes on syslog TCP destinations automatically. When a job references a custom index on a syslog TCP target, the save toast will include a warning such as: 
created my-job; <siem>: create index "windows_endpoint" manually (syslog tcp destination).
Create the index (or routing rule) on the downstream collector before the next scheduled run, otherwise events tagged with that index may be dropped or routed to a fallback index.

​
Wipe and re-fire behaviour

When Propagate on wipe is enabled, wiping a SIEM session also wipes any non-default custom indexes referenced by the job’s archives on Splunk and Elasticsearch before the job re-fires. This keeps custom training indexes in sync with the default index rather than leaving stale events behind.

​
How execution works

When the scheduler fires, the following sequence runs automatically:
  1. The dispatcher posts to /api/noise/run with the job configuration.
  2. All archives are downloaded from storage in parallel.
  3. LEEF timestamps are rebased so the latest event in the archive lands at now + 2 hours — keeping your SIEM timeline current.
  4. Events are shipped to each target SIEM independently. A failure on one SIEM does not abort delivery to others.
  5. Per-execution, per-SIEM results are recorded in the run history.
  6. The job’s next_run_at value is updated for the following execution.

​
Wipe and re-fire

When an administrator wipes a SIEM session (DELETE /api/sessions), any noise jobs with Propagate on wipe enabled automatically re-fire for that SIEM. This ensures your training environment is repopulated with baseline traffic immediately after a wipe, so analysts always land in a realistic SIEM state at the start of a new training cycle.

​
Viewing run history

To review past executions, go to Admin > Resources > Noise Jobs, click the job name, and open the Recent Runs tab. Each run shows the execution timestamp, per-SIEM status, event count dispatched, and any error messages. Use this view to diagnose delivery failures or confirm that a manual trigger succeeded.

​
Validation limits

  • Name: required, maximum 80 characters
  • Description: optional, maximum 500 characters
  • Minimum 1 archive per job
  • Maximum 10 archives per job
  • Accepted formats: .zip, .tar.gz, .tgz
  • Files inside must be .txt or .log
  • Minimum 1 SIEM target, maximum 20 SIEM targets
  • Interval range: 60 – 86,400 seconds
  • Jitter: maximum 600 seconds, and never more than the configured interval
Noise jobs dispatch in LEEF format only. If you have Elasticsearch destinations configured with the ECS payload format, noise jobs will not populate them. Use exercise start to ship ECS-format data to those destinations.