Sigma event journal

A Sigma rule is matched against a journal of normalized events, not against the raw recording. The Event journal viewer lets you read those events, so you can see exactly what a rule had to work with and why it did or did not match.

Opening it

• In Triage → Detection, expand Scanned inputs and click the Event journal row.
• In a Sigma finding’s Details…, press Journal event #N beside an evidence location.

The journal is a read-only view. Open file hands the raw JSONL file to your desktop, Copy path copies its path and Reload reads it again; the viewer itself never writes it.

What it shows

The header says whether the journal is Complete or Partial. This describes the journal file, not the scan outcome: the Event journal row of Scanned inputs is Succeeded whenever the Sigma adapter ran. A complete journal has an end record saying every recorded call and packet was normalized and none was left out. A partial one says why: for example there is no usable end record, or it does not cover every recorded call. The header also shows the events per category, the file’s path, size (as N bytes (X.Y KB)) and SHA-256, and whether this file is the one the scan read (Identical to the journal this scan read., or a warning that finding event numbers may not apply, in which case scan again).

Below it:

• a category dropdown (All categories, then each category with its count) and a Search category, field or value box, with Search and Clear;
• the event table with Event, Category, Time, Process and Fields, in pages of 100 (Previous, Next). A click on a column header sorts the events of the current page;
• the selected event with every field, Copy fields, its time, and its Source: a link to the call in Syscall Trace or the packet in Network.

A field that was not captured for an event is absent, not empty.

Inferred fields

A value that comes from tracking state or from matching two sources, not from one recorded call, is listed in the event’s _inferred field, and the selected event shows it as, for example, CurrentDirectory (inferred). Inferred values are:

• IsNewFile (and TargetFilename of an O_TMPFILE open) when a file is judged new because its path was not seen earlier in the run;
• CurrentDirectory reached by chdir or fchdir;
• DestinationHostname, matched from the DNS answers in the run’s capture;
• a path joined from the working directory;
• auditd’s exe, comm, cwd, and name or nametype when they come from tracked state.

Where events come from

Events are converted from the syscall trace and, for DNS and HTTP, from the packet capture as TShark parsed it. The categories, the fields each one carries and what stays unavailable are in Detection engines. In short:

Source	Events
Exec and fork	process_creation with the parent, working directory and, with a base built for 0.7.0 or later, User, LogonId and Hashes; the launched program’s own process_creation, built from the launch record
Task exit	process_termination, one per process that ended
File calls, including io_uring and AIO requests	file_event, file_access, file_delete, file_rename, antinomie_file_metadata
Sockets	network_connection
bpf	antinomie_bpf
Packet capture	dns_query, http_request
The same calls, for service: auditd rules	SYSCALL, EXECVE, PATH, SOCKADDR, CWD and PROCTITLE records

PROCTITLE holds the arguments joined with NUL bytes, hex-encoded and cut at 128 bytes, as the kernel does. A run that lived through a transport reconnect has one journal over all its recording segments.

Format

The journal is format 3, which added the credential and hash fields (User, LogonId, Hashes, HashSkipped and the auditd uid family). Format 2 added _inferred. Journals in formats 1 and 2 still open and scan; their events lack the newer fields, which are missing, not empty.

Sigma findings keep the exact journal event number. Findings saved by older versions link by call or packet (In journal shows the first event recorded for that source) and say so when one source produced several events. Journals are read on a worker, in bounded pages, and a read is cancelled when you switch runs.

The file is stored with the run; see File formats.