Shell history file access recorded by auditd on Linux

1title: Shell history file access recorded by auditd on Linux2id: 2e1bb5d0-6091-427b-8931-b4c24d08af0c3status: experimental4description: |5  Matches the file-access leg of AN1085: an auditd PATH record naming one of6  the per-user shell history files, which is the object this technique is7  after — a plaintext record of every command a user typed, including the ones8  where a password was passed as an argument. The names are anchored on the9  filename rather than on an absolute path because auditd records `name=`10  exactly as it was handed to the syscall, so `cat .bash_history` run from11  inside a home directory logs a bare `.bash_history` with no directory part at12  all. The list of file names — bash, zsh, ksh/sh, ash and fish — is assembled13  here and is not MITRE's; MITRE's `ProcessNamePatterns` knob is about something14  else entirely, the set of CLI utilities used to *read* the history, and it15  cannot be applied in this rule at all for the reason immediately below. Three16  limits are structural, and the first17  decides how this rule must be read. auditd emits PATH and SYSCALL as separate18  records for one event, and the accessing process's `exe`, `uid` and `auid`19  live only on the SYSCALL side — so the analytic's central idea, that the20  reader is a process *outside* an interactive shell context, cannot be tested21  inside this selection, and neither can MITRE's `UserContext` or22  `ProcessNamePatterns` knobs. Every23  interactive login shell reads its own history file at startup and appends to24  it at exit, and those events are indistinguishable here from an adversary25  reading the same file; that is not a tuning detail but the dominant content26  of this rule's output, and it is what sets the level. The analytic's second27  log source, an EXECVE record for `cat`/`less`/`grep`, is not used: on a raw28  auditd stream the arguments sit in `a0`/`a1` on a separate EXECVE record from29  the `exe` on SYSCALL, so no single record carries both the tool and the file30  it was pointed at, and selecting on `/cat` or `/grep` alone would match every31  use of two of the most-used binaries on the system. MITRE's `TimeWindow` knob,32  which would fire only on access shortly after an su/sudo transition, needs a33  cross-event join lib/sigma does not model. The macOS arm AN1086 is not34  attempted, because its endpointsecurity and unifiedlog sources have no35  standardised Sigma field names and inventing them would produce a rule that36  parses everywhere and matches nothing; the Windows PSReadline history file37  named in the technique text has no log source in this brief at all.38  Prerequisite: auditd watches none of these paths by default, so this rule39  returns zero rows until a read watch such as40  `-w /home/<user>/.bash_history -p r -k histaccess` is loaded for each home41  directory and for /root, and zero rows reads as quiet when it means blind.42  The `r` permission is what makes the technique visible and is also what makes43  the rule loud — a `wa` watch is quiet but blind to reading, which is the44  whole behaviour here.45  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0385, not hand-written and not tested by its author. Any lab result is on this rule's own page.46references:47  - https://attack.mitre.org/techniques/T1552/00348  - https://attack.mitre.org/detectionstrategies/DET038549author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)50date: 2026-08-1651tags:52  - attack.credential-access53  - attack.t1552.00354logsource:55  product: linux56  service: auditd57detection:58  selection_history_file:59    type: 'PATH'60    name|endswith:61      - '.bash_history'62      - '.zsh_history'63      - '.sh_history'64      - '.ash_history'65      - '.ksh_history'66      - '.histfile'67      - 'fish_history'68  condition: selection_history_file69falsepositives:70  - "The user's own shell. bash, zsh and fish read the history file when an interactive session starts and write it back when the session ends, so with the read watch this rule needs, every single interactive login, su, sudo -i and terminal tab on the host produces matching records. This is the highest-volume match by an enormous margin, it cannot be separated from an adversary's read inside one PATH record, and it is the only reason this rule is low rather than high."71  - "Backup, sync and imaging jobs that walk home directories — restic, borg, rsync, Duplicati, an NFS or cloud home-directory sync agent — each of which opens every dotfile in every home on its schedule, producing one burst of matches per run per user."72  - "Endpoint security and compliance scanning. Antivirus on-access and scheduled scans, DLP content inspection, Lynis, OpenSCAP, osquery file packs and backup-verification passes all read history files as ordinary files while walking the filesystem, from a service account, on every host in scope."73  - "Administrators and support staff reading their own or a colleague's history to reconstruct what was run during an incident or a failed change, which is the same read this rule is built to catch, separated from an intrusion only by who did it and why."74  - "Terminal multiplexers and remote development tooling — tmux and screen panes, the VS Code Remote and JetBrains Gateway integrated terminals, and CI runners that start a login shell per job step — each of which spawns a fresh interactive shell that reads the history file on startup, so one ordinary working session from one user produces dozens of matches on one host."75level: low