Input-state probing tool or shell/browser history read on Linux

Siemphony@siemphonylowT1497.002unverified

AN1183 names two ways a sandbox check confirms a real user is present: running a tool that reads keyboard/mouse input state (xdotool, xinput, xev), and reading artifacts a real session accumulates (shell history, browser profile data). Both of the brief's log-source entries for this analytic resolve to the same auditd Sigma logsource, so one rule can hold both legs: an auditd SYSCALL record whose `exe` is one of the three input-probing tools, or a PATH record naming .bash_history or the .mozilla profile directory. The brief also lists reads of /dev/input directly; that path is deliberately not included as a third selection, because /dev/input is what the X server and every libinput-based input driver read continuously as part of normal GUI operation on any desktop session — a selection on that alone would be indistinguishable from the X server simply running. AN1183's `ArtifactCountThreshold` knob (alert only after N distinct artifacts are touched) is not implemented; lib/sigma has no counting or aggregation, so this fires on the first matching read or execution, not a threshold of them. AN1182, the Windows leg of this strategy, is not attempted here. Its observable is process execution correlated with a preceding 4800/4801 workstation lock/unlock event within a time window, which is a cross-event join lib/sigma cannot express — a rule on the process-creation leg alone would have to guess at which registry keys or commands count as "probing user activity artifacts," a specificity MITRE's own analytic description does not commit to. AN1184, the macOS leg, is not attempted either: its unifiedlog source has no standardised Sigma field names for the CGEventState APIs or plist reads it names, and inventing them would produce a rule that renders in every backend and matches nothing. Prerequisite: none of these paths or syscalls are audited by default. This needs an execve-auditing rule to catch the tool launches (for example `-a always,exit -F arch=b64 -S execve -k input_probe`) and explicit watches for the artifact paths — auditd watches take no wildcards, so covering every account means either per-user `-w /home/<user>/.bash_history -p r` and `-w /home/<user>/.mozilla -p r` entries or a directory-prefix syscall rule over /home. Without either, this returns zero rows, which here means the sensor is blind rather than that no probing occurred. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0420, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="SYSCALL" AND (exe="*/xdotool" OR exe="*/xinput" OR exe="*/xev")) OR (type="PATH" AND (name="*.bash_history*" OR name="*.mozilla*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "syscall" AND (TO_LOWER(exe) LIKE "*/xdotool" OR TO_LOWER(exe) LIKE "*/xinput" OR TO_LOWER(exe) LIKE "*/xev")) OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*.bash_history*" OR TO_LOWER(name) LIKE "*.mozilla*")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^SYSCALL$</field>    <field name="exe" type="pcre2">(?i)(/xdotool$|/xinput$|/xev$)</field>    <description>Input-state probing tool or shell/browser history read on Linux (1/2)</description>    <mitre>      <id>T1497.002</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(\.bash_history|\.mozilla)</field>    <description>Input-state probing tool or shell/browser history read on Linux (2/2)</description>    <mitre>      <id>T1497.002</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: discovery_recon
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 5844d49c-4fc6-4555-a02e-36e8f46832b2

ATT&CKT1497.002

T1497.002User Activity Based Checks

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondiscovery recon

discovery reconAI draft — unreviewed

01 · What this rule detects

User Activity Based Checks (T1497.002) — malware or an implant confirms a real human is present before running its payload, rather than a sandbox or analysis VM. MITRE's AN1183 names two ways this happens on Linux: running a tool that reads keyboard/mouse input state, and reading artifacts a real session accumulates over time, such as shell history or browser profile data. This rule covers both.

02 · Telemetry you need

Linux auditd. Nothing here is captured by default: you need an execve-auditing rule for the tool launches (for example -a always,exit -F arch=b64 -S execve -k input_probe) and explicit watches for the artifact paths. auditd watches take no wildcards, so covering every account on the box means either per-user entries (-w /home/<user>/.bash_history -p r, -w /home/<user>/.mozilla -p r) or a directory-prefix syscall rule over /home. Without either, the rule returns zero rows, and here that means the sensor is blind, not that no probing occurred.

03 · How the logic works

Both of the brief's log-source entries for AN1183 resolve to the same auditd Sigma logsource, so one rule holds both legs, joined with 1 of selection*. selection_tool_exec matches a SYSCALL record where exe ends with /xdotool, /xinput, or /xev — the three named input-state-probing tools. selection_artifact_read matches a PATH record where name contains .bash_history or .mozilla. The brief also lists direct reads of /dev/input; this is deliberately excluded as a third selection, because /dev/input is what the X server and every libinput-based input driver read continuously as part of normal GUI operation — a selector on that alone would be indistinguishable from the X server simply running. MITRE's ArtifactCountThreshold knob — alert only after N distinct artifacts are touched, which would meaningfully cut noise here — is not implemented; lib/sigma has no counting or aggregation, so this fires on the first matching read or execution rather than a pattern of them. The Windows leg (AN1182: process execution correlated with a preceding lock/unlock event) needs a cross-event join lib/sigma cannot express, and the macOS leg (AN1184: unifiedlog CGEventState APIs) has no standardised Sigma field names — both are skipped rather than faked.

04 · Common false positives

Three sources are named, and they are severe. Launching Firefox itself reads and writes its own profile under ~/.mozilla on every start — on any host where Firefox is installed, this is the loudest source of matches by a wide margin, which is exactly why level is set to low rather than higher. Tiling window managers and keybinding daemons (i3, bspwm, and similar setups that shell out to xdotool for window focus/move/resize) and GUI test-automation frameworks built on xdotool are legitimate and routine on any Linux desktop that uses them. Interactive shell use and dotfile/backup tooling reading .bash_history as a side effect — history-search plugins, shell-history sync utilities, and home-directory backup jobs like rsync, borg, or restic — also match.
A reviewer noted selection_artifact_read uses name|contains: '.mozilla', which matches any path containing that substring — a directory listing or file-manager thumbnailing of the .mozilla folder would also match, not only reads of history or bookmark files specifically. Given the auditd watch prerequisite is read-scoped (-p r), this is a limitation to document rather than a defect to fix outright.

05 · Detection maturity

tier_1: This rule has never been run against a log line. It sits at the lowest DeBMM maturity tier until it has been run against real auditd data from a host with the prerequisite watches configured.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

If your fleet's baseline browser is Firefox, this rule is close to unusable without a per-host allowlist on interactive-shell PIDs, since ordinary browser startup will dominate every alert queue. Consider scoping the .mozilla watch to specific subpaths (profile history/places files) rather than the whole directory tree if your auditd version supports it.

Declared by the author

Launching Firefox itself, which reads and writes its own profile under ~/.mozilla on every start — on any host where Firefox is the installed browser this is the loudest source of matches by a wide margin and is why this rule is scored low rather than higher.
Tiling window manager and keybinding daemons (i3, bspwm, and similar setups that shell out to xdotool for window focus, move or resize actions) and GUI test-automation frameworks built on xdotool, both legitimate and routine on any Linux desktop that uses them.
Interactive shell use and dotfile/backup tooling reading .bash_history as a side effect — command-line history search plugins, shell-history sync utilities, and home-directory backup jobs (rsync, borg, restic) that walk the whole home directory including this file.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1497.002, evaluated against their — events.

Share this rule

/u/siemphony/5844d49c-4fc6-4555-a02e-36e8f46832b2

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Input-state probing tool or shell/browser history read on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it