What happened
SANS ISC published the Atuin forensic note on August 7, 2026. Attribution posture: The SANS ISC forensic note describes evidence handling, not threat activity, and names no actor. Atuin’s primary SQLite artefacts are ~/.local/share/atuin/history.db, history.db-wal and history.db-shm. Relevant supporting files include ~/.local/share/atuin/key, ~/.local/share/atuin/session and ~/.config/atuin/config.toml. The ATUIN_CONFIG_DIR variable can override the default configuration location, while individual database, key and session paths can also be changed in the configuration.
The history table records timestamp, duration, exit, command, cwd, session and hostname, with deleted_at used as a soft-delete marker. The read-only triage opening syntax is sqlite3 “file:history.db?mode=ro&immutable=1”. Atuin may sync commands from other machines into the local database, so hostname and session fields are required for attribution. The cited source did not establish that absence of a command proves it did not run; filters, scripts and non-interactive shells can create gaps. Standard shell-history files may still coexist with Atuin and should be cross-referenced rather than discarded. The ATUIN_CONFIG_DIR variable can override the default configuration location.
Why this matters now
Command history often shapes the first incident timeline on Linux systems, including whether an administrator, attacker or automation account changed controls, retrieved credentials or deployed persistence. Missing the Atuin database can discard timestamps, working directories, exit status and session context that flat history does not normally preserve. Missing the write-ahead log can also lose uncommitted or prior row data.
The same richness creates an attribution hazard. Synchronisation can place commands from a different machine into the acquired database, and soft deletion can preserve records a user believed removed. Investigators who report every row as local execution may expand or close the incident incorrectly. The control requirement is therefore collection plus provenance validation, not simply acquiring more files.
The decision for security leaders
Direct incident response and endpoint engineering to add Atuin discovery to Linux acquisition profiles. Collection should include the database, write-ahead log, shared-memory file, encryption key, server-session token and configuration before interactive examination. Analysts should work from hashed copies, use read-only SQLite access and record any custom path or filter settings that limit completeness.
Require timelines to retain hostname and session fields and to distinguish local execution, synchronised history and unverified origin. Where another hostname appears, the incident commander should evaluate that host for scoping rather than treating the row as proof of compromise. Legal and privacy owners should review collection of synchronised personal or cross-system command history before routine enterprise deployment.
Evidence of closure
- The forensic image contains all located Atuin database and configuration artefacts.
- Hash records prove originals remained unchanged during analysis.
- The command timeline records hostname and session provenance.
- The closure report documents history filters, sync behaviour and known evidence gaps.
The Security.io assessment
This is a narrow forensic development, but it changes the quality of evidence available during Linux response. Atuin can improve reconstruction because it captures context that conventional history lacks and may retain soft-deleted or write-ahead-log remnants. It should not be treated as an authoritative audit log: users can configure filters, non-interactive activity may be absent and synchronisation complicates host attribution.
Evidence-based closure should state what was collected, how origin was validated and which gaps remain. A clean .bash_history is insufficient when Atuin was active, while an incriminating Atuin row is insufficient without hostname and session context. The practical control test is whether acquisition tooling discovers the artefacts automatically and whether reports preserve their provenance limitations.
Questions for the morning meeting
- Do current Linux acquisition scripts recognise Atuin and its non-default paths?
- Can investigators separate local execution from synchronised cross-host history?
- Are shell-history filters governed or documented on privileged systems?
- Does legal hold preserve write-ahead-log and soft-deleted SQLite evidence?