Find Deleted wtmp Entries with chkwtmp

Someone tidied up after themselves, and chkwtmp is the quick check for whether they scrubbed the login history. It looks for null-filled entries in /var/log/wtmp and reports the timestamps around a suspected deletion. This guide takes about ten minutes, and the result is a narrow integrity check, not a complete audit of login activity.

• You need: the chkrootkit package and a shell. On the system used here that is chkrootkit 0.58b-1, and the installed manual page is dated 23 October 2021.
• Privileges: normally none, because /var/log/wtmp is commonly world-readable. Your local permissions may differ.

1. Confirm the installed command

Check which executable the shell will run and record the package version:

$ command -v chkwtmp
/usr/sbin/chkwtmp
$ dpkg-query -W -f='${Package} ${Version}\n' chkrootkit
chkrootkit 0.58b-1

The path and version are useful evidence if you later compare results with another machine. Do not assume a similarly named tool from another package behaves the same way.

Checkpoint: command -v printed a path. If it printed nothing, stop, install or repair the package through your normal system-management process, and do not copy an executable from an unrelated host.

2. Check the wtmp file without changing it

Inspect the file's permissions, then run the command with no arguments:

$ ls -l /var/log/wtmp
-rw-rw-r-- 1 root utmp 966528 Sep 22 18:26 /var/log/wtmp
$ chkwtmp
$ printf 'exit status: %s\n' "$?"
exit status: 0

chkwtmp has no documented options or input-file argument, and it always examines /var/log/wtmp. On this machine the check produced no report and returned zero. The manual defines no special success message, so silence is not a phrase your scripts can parse.

If the command does print timestamps, save the complete output and the time of the check. Those timestamps are the entries immediately before and after one that looks overwritten. They show where the missing area sits in the recorded history. They do not identify who removed it or prove when the file was modified.

3. Handle an unreadable file

If the command cannot read the file, check access first without changing permissions:

$ test -r /var/log/wtmp && echo 'readable' || echo 'not readable'
$ id
$ namei -l /var/log/wtmp

Use sudo only when your access policy requires it, and only for this read-only command:

$ sudo chkwtmp
$ printf 'exit status: %s\n' "$?"

Warning: do not change the file's mode or ownership just to make the check convenient. That alters the security boundary around login history and may conflict with your distribution's log-management policy.

If elevated execution works, record that with the result so a later reviewer knows how the check was run.

4. Treat a reported deletion as a lead

A reported entry means the program found one whose time information contains null bytes. The manual calls this an overwritten entry. Review the result alongside other evidence rather than declaring a compromise from this one signal.

$ chkwtmp > /tmp/chkwtmp-report.txt
$ status=$?
$ printf 'chkwtmp status: %s\n' "$status"
$ sed -n '1,80p' /tmp/chkwtmp-report.txt

This stores the report in a temporary file and leaves /var/log/wtmp untouched. The path is deliberately under /tmp, so move the report into your approved evidence store if you need to keep it.

Tip: in a multi-user environment, check that the destination is not a symlink to a sensitive file before redirecting output into it.

For follow-up, preserve the original wtmp file and collect related records according to your incident process. Useful comparisons include the output of who, other authentication logs and system time records, but each source has its own retention and rotation rules.

Warning: do not edit, truncate or rotate logs while you are trying to establish what happened.

5. Understand the detection limit

chkwtmp recognises an overwritten entry only when the time information has been replaced with null bytes. It can miss:

• Edits that leave non-null values.
• A replaced file. Swapping out the whole file defeats it.
• Attacks on another logging path.
• Changes made after log rotation.

A clean run means that one pattern was not found in the current /var/log/wtmp. It does not prove the login history is complete.

The manual also warns that the program was originally designed for SunOS 4.x and that output is undefined on other systems. The Debian package supplies it on Linux, but that does not remove the limitation. Keep the installed version and platform with any report, and avoid building automation around undocumented output formatting.

6. Keep the check read-only

There is nothing to enable, repair or configure in chkwtmp. It reads the fixed wtmp path and writes any findings to standard output. Do not run it with a proposed alternative file name, because the manual documents no such mode. Do not use shell redirection to overwrite an existing evidence file unless that replacement is intentional.

If you made the temporary report and have verified it is no longer needed, remove only that exact file:

$ rm -- /tmp/chkwtmp-report.txt

Warning: this deletion is irreversible. If the report may be evidence, keep it and let your retention or incident procedure decide when it can go. The check itself made no change that needs undoing.

Done means

• The command is identified. Its path and the installed chkrootkit version are recorded.
• The log was untouched. chkwtmp ran against /var/log/wtmp without modifying it.
• Timestamps are preserved. Any reported range is treated as a lead, not a verdict.
• Access was handled cleanly. Unreadable-file handling used inspection or narrowly scoped sudo, not permission changes.
• A clean result is worded carefully. It is documented as absence of the null-byte pattern only.