Linux - Forensics - Get Reboot History

What the Linux reboot history audit does

This Automox Worklet™ reads the kernel reboot record from /var/log/wtmp on every Linux endpoint in scope and writes a structured table to the Automox Activity Log. The Worklet runs the last reboot command, which decodes the wtmp binary log into one row per system boot, then pipes the output through an AWK formatter that prints six fixed-width columns: Event, Kernel Version, Day of Week, Month, Day, and Reboot Time.

Because the Worklet logs to the Automox Activity Log rather than the endpoint console, the reboot record is captured centrally even if the endpoint is later reimaged or wtmp is rotated. The same data is reachable interactively on the endpoint with last -x | grep reboot, journalctl --list-boots on systemd-based distributions, and uptime --since for the most recent boot time. The Worklet collapses those three sources into a single fleet-wide report you can query from the Automox console.

The script is read-only. It does not modify wtmp, btmp, or any other system file, and it does not write to disk on the endpoint, so a daily evaluation policy can run against production database servers and container hosts without introducing any I/O or restart side-effects.

Why audit Linux reboot history from the Automox console

Unexpected restarts on a Linux endpoint are rarely random. A reboot outside a scheduled change window may signal a failed kernel update, an OOM killer event that took init down, or a power loss in a colocation cage. In the worst case, it can signal an attacker clearing memory after privilege escalation. Reading /var/log/wtmp on a single host with last reboot answers the question for that host. Running the same query across a fleet of hundreds of servers, on demand, is the gap this Worklet closes. The output is preserved in the Automox Activity Log alongside the policy run identifier, which gives incident responders a defensible timestamp trail without SSH access to each host.

Schedule this Worklet against the production Linux server group and let the Automox agent pull the same last reboot output you would type interactively, then preserve every result in the Activity Log so the record persists past the next /var/log/wtmp rotation. Compliance frameworks that require system state change tracking, including PCI-DSS 10.2 and SOC 2 CC7.2, map directly to the evidence this collection job produces.

How the reboot history retrieval works

1. Evaluation phase: The evaluation script exits with status 1 unconditionally. This is intentional. The Worklet is a data-collection action, not a drift check, so remediation must run on every policy execution to capture the current state of /var/log/wtmp. Treating evaluation as a no-op signal keeps the design simple and avoids false compliance on endpoints that never report any wtmp entries.

2. Remediation phase: The remediation script defines a get_history function that runs last reboot and pipes the output to an AWK formatter. AWK prints a header row, a divider row, and then six printf-aligned columns built from fields $1, $4, $5, $6, $7, and $8 of each last reboot line. The pipeline is wrapped in an if check that exits 0 when AWK succeeds, and exits 1 with a descriptive message to the Activity Log if the formatter returns non-zero.

Reboot history audit requirements

• Linux endpoint with bash and the standard util-linux package providing the last command

• Read access to /var/log/wtmp (the Automox agent runs as root and meets this by default)

• GNU AWK (gawk) or mawk for the formatting pipeline; both are present on RHEL, CentOS, Rocky, Alma, Fedora, Debian, and Ubuntu by default

• Works on workstations, bare-metal servers, EC2 and other cloud VMs, and container hosts; container guests typically do not maintain wtmp and will return an empty result

• No configurable parameters; the policy runs unchanged on every Linux endpoint in scope

Expected reboot audit output and validation

After a successful run, the Automox Activity Log shows a table with one row per recorded boot, oldest at the bottom. Columns read: Event (always "reboot"), Kernel Version (for example 5.15.0-91-generic or 4.18.0-513.el8.x86_64), Day of Week, Month, Day, and Reboot Time in HH:MM. The depth of the history depends on the endpoint's logrotate policy for wtmp; most distributions retain four weeks by default, configurable in /etc/logrotate.conf or /etc/logrotate.d/wtmp.

Validate the Worklet by spot-checking one endpoint interactively. Run last -x | grep reboot and compare the count and timestamps to the Activity Log table. For systemd-based distributions, journalctl --list-boots gives an independent view that should align with wtmp for any boot inside the journal retention window. Use uptime --since to confirm the most recent boot time against the top row of the Worklet output.

If the Worklet returns an empty table or a non-zero exit, check that /var/log/wtmp exists and is not zero-bytes (a freshly imaged endpoint or container guest may have neither). Verify the agent process has read access with ls -l /var/log/wtmp. For incident response evidence, export the Activity Log entry to your case management system alongside the Automox policy run identifier, the endpoint hostname, and the policy timestamp; this triplet anchors the boot record to a defensible chain of custody.