What the Sensor Detects
The behavioural families that raise a finding, the rule formats accepted beside them, and the key that turns one off.
On this page (5)
What the Sensor Detects Documentation
Every family below observes. A match is held, not contained: the sensor recorded it and did not act. Turning that into an action is the response ladder.
All of them read the same event stream, described in how the sensor works.
The behavioural families
| Family | What it correlates | Key |
|---|---|---|
| Ransomware | encryption behaviour across a process tree, and destruction of the means to recover | ransomware |
| Process injection | a process writing into another's memory, by the shape of the mapping left behind | injection |
| Event chain | a sequence that crosses event kinds, where no single event is remarkable | eventchain |
| Lateral movement | authenticated movement between hosts, per service used | lateralmovement |
| Defense evasion | tampering with logging, and with the tools that would notice | defenseevasion |
| Collection | staging of local data ahead of taking it | collection |
| Credential access | reads of credential stores and secrets on disk | credaccess |
| Generated domain names | machine-generated names in the host's own DNS questions | dga |
| Critical configuration | changes under a closed list of paths that decide what runs at boot or as another user | configWatch |
| Rule evaluation | the bundled Sigma content, and any rule you add | sigma |
The critical-configuration watch marks the parent directories of the paths it holds and refuses to follow a symlink out of them, so replacing a watched file by way of a link is itself the event.
Turning one off
A key is on when it is absent or true. Only an explicit false disables it, so the file can only ever narrow what the sensor does.
{
"sensor": {
"enabled": true,
"ransomware": false
}
}
On Linux the file is /etc/whisper/sensor.json; apply a change with sudo -E whisper service restart --sensor. The sensor service has the rest of the paths.
The second pass
Two things the host cannot answer alone are answered off it. A binary the host has not seen before is checked against known-bad hashes. A destination is checked against the Whisper graph, which knows who announces the address, who registered the name and which feeds list it. Coverage is what a clean answer from that pass does and does not mean.
The host's own process and connection graph is joined to that reading, which is how a finding arrives with the process that caused it attached rather than as a bare indicator.
Rule formats
The sensor evaluates Sigma rules, and maps its event kinds onto Sigma log sources as exec to process_creation, file to file_event, conn to network_connection and dns to dns_query. Your own rules sit beside the bundled ones: add your own rules.
Where findings land
A held finding goes onto the detection ledger, readable per host with kind: 'task':
curl -s -X POST https://graph.whisper.online/api/query \
-H 'content-type: application/json' \
-H 'X-API-Key: <your key>' \
--data-binary @- <<'JSON'
{"query": "CALL whisper.agents({op: 'list', kind: 'task'})"}
JSON
The same rows drive the console's attention list and its ATT&CK view, which maps what actually fired onto the matrix. Alerts and incidents is how they decide whether to interrupt you.