Reading your first run
On this page
A run file, top to bottom: the host, the signals, the entities and the telemetry - and the order in which to read them.
The examples on this page come from WS-ALPHA, a host in Signal's own sample fleet: synthetic test data, built so every part of a run has something to show.
The order to read a run
-
1. Telemetry first
Before trusting any signal - or the lack of one - check what Signal could see: which logs were read, whether process creation auditing was on, which sources were missing.
-
2. Entities by severity
Start with the entities: one program, account or task with every signal about it from every module. The highest severity first.
-
3. Each signal's evidence
Open a signal: read what happened, why it matters and what to do next, then its source - which log, which event, which record.
-
4. The tables
Use the small tables (logon sources, persistence entries, installed applications) for context and for comparing hosts.
The top of the file
{
"run_id": "alpha-sample",
"tool": "signal",
"schema_version": 63,
"mode": "live",
"started": "2026-10-26T16:00:00Z",
"duration": "3s",
"host": {
"hostname": "WS-ALPHA",
"os": "Windows 11 Pro",
"os_version": "24H2",
"is_domain_controller": false,
"elevated": true,
"timezone": "UTC"
}
}Every time in a run is in UTC. The host's time zone and its offset are in host, so you can convert. See Time in Signal.
A signal
Each module lists its findings: one per rule that fired. A finding's text answers three questions:
Field | Question | Example (EXEC-OFFICE-SPAWNED-SHELL) |
|---|---|---|
| What happened? | An Office application was the direct parent of a shell or script host. |
| Why does it matter? | Office documents do not normally start shells; it typically marks the first stage of a phishing compromise. |
| What do I do next? | Find the document open at that time, read the child's command line, look for what that stage did next. |
Under the finding are its observations: the signals themselves, one per thing the rule matched.
{
"time": "2026-10-22T16:00:00Z",
"time_is": "process started",
"entity": "cmd.exe /c whoami",
"context": "C:\\Windows\\System32\\cmd.exe",
"fields": {
"process.command_line": "cmd.exe /c whoami",
"process.parent_name": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
"process.user": "CORP\\alice",
"process.token_elevation": "limited (not elevated)"
},
"enrichment": {
"process": { "still_running": false },
"gaps": [{ "item": "process exit (4689)",
"reason": "Process Termination auditing is off: Windows does not record a process's exit" }]
},
"source": {
"evidence": "process_creation",
"proves": "a process started at the record's time, from this parent, as this user - it may have exited since",
"description": "process creation (historical) - Security log, event ID 4688, record number 1400"
},
"count": 1
}Entities
The run's entities group every signal by what it is about. On WS-ALPHA, the scheduled task \Microsoft\Windows\WinSvcUpdate is one entity with six matches from two modules: Scope (it matches the incident's pivot points) and Persistence (the task is hidden). It is related to the program it runs, C:\Users\Public\svc.exe, and to the account that created it.
Investigating the entity, rather than each signal on its own, is the fastest way through a run. See Entities.
Telemetry
[
{ "id": "process_creation_audit", "label": "Process Creation auditing on",
"state": "on", "category": "Security Log Audit" },
{ "id": "commandline_logging", "label": "Command lines recorded",
"state": "on", "category": "Logging settings" }
]A telemetry item says whether a source of evidence was there. When Process Creation auditing is off, the absence of process signals means nothing. See Telemetry.
Next
Try it on your own machine: Lab: survey your own machine.