Inspect UTMP and WTMP Records Safely with utmpdump

You will use utmpdump to turn a binary UTMP or WTMP file into readable records, save the result for later analysis, and watch a WTMP file as new records arrive. The workflow is read-only. It deliberately avoids --reverse, which writes edited text back into a login database.

Allow about ten minutes. You need a shell and the util-linux package. The examples use /var/run/utmp for current sessions and /var/log/wtmp for login history. File locations can differ on another distribution, so check the path before substituting it.

The installed package here is util-linux 2.39.3-9ubuntu6.6. The command found first in this shell is /home/linuxbrew/.linuxbrew/bin/utmpdump, which reports util-linux 2.42.4. Always check the executable on the machine where you will run the investigation.

1. Check the executable and its options

Start with ordinary, read-only checks. No elevated privileges are needed for the command itself:

$ command -v utmpdump
/home/linuxbrew/.linuxbrew/bin/utmpdump
$ utmpdump --version
utmpdump from util-linux 2.42.4
$ utmpdump --help
Usage:
 utmpdump [options] [filename]

The help output confirms the useful options: --follow watches appended data, --output FILE sends the dump to a file, and --reverse writes a dump back into a UTMP or WTMP file. The final filename is optional. Without it, input is read from standard input.

Checkpoint: if command -v points into a user-local directory but your package manager describes a different version, use an explicit path in evidence and record both facts. A shell path can otherwise make two operators run different builds while believing they used the same command.

2. Dump current sessions from UTMP

Pass the UTMP path as the filename. This reads the file and writes formatted records to standard output:

$ utmpdump /var/run/utmp | head -n 6
Utmp dump of /var/run/utmp
[2] [00000] [~~  ] [reboot  ] [~           ] [6.8.0-139-generic   ] [0.0.0.0        ] [2026-09-11T14:58:41,014846+00:00]
[6] [01225] [tty1] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [2026-09-11T14:59:13,059298+00:00]
[7] [2533405] [ts/0] [andy    ] [pts/0       ] [9.246.33.98         ] [9.246.33.98    ] [2026-09-27T10:12:11,284335+00:00]
[8] [1427658] [ts/1] [        ] [pts/1       ] [                    ] [82.132.244.49  ] [2026-09-27T16:25:07,192145+00:00]

The header identifies the input. Each following line contains bracketed fields including the record type, process ID, terminal or identifier, user, line, host information and a UTC timestamp with microseconds. The exact entries are live system data, so do not treat the sample values as universal.

Use elevated privileges only if the file permissions deny your ordinary account. Prefer granting the narrow read access required by your operating policy. Do not make the database world-readable merely to avoid a permission error.

3. Inspect WTMP history and preserve a report

WTMP is also a binary record file, but it normally contains historical entries. Dump it in the same way:

$ utmpdump /var/log/wtmp | head -n 6
Utmp dump of /var/log/wtmp
[8] [949143] [    ] [        ] [pts/0       ] [                    ] [0.0.0.0        ] [2026-06-11T23:07:47,786264+00:00]
[8] [1003000] [    ] [        ] [pts/5       ] [                    ] [0.0.0.0        ] [2026-06-11T23:58:35,208084+00:00]
[7] [1903087] [ts/0] [andy    ] [pts/0       ] [150.228.103.105     ] [150.228.103.105] [2026-06-12T06:28:57,332930+00:00]
[7] [2215216] [ts/5] [andy    ] [pts/5       ] [tmux(2215216).%32   ] [0.0.0.0        ] [2026-06-12T06:28:58,044084+00:00]

For a report, use --output rather than relying on terminal scrollback:

$ report='/tmp/wtmp-dump.txt'
$ utmpdump --output "$report" /var/log/wtmp
$ wc -l "$report"
N /tmp/wtmp-dump.txt
$ sed -n '1,3p' "$report"
Utmp dump of /var/log/wtmp
[8] [949143] [    ] [        ] [pts/0       ] [                    ] [0.0.0.0        ] [2026-06-11T23:07:47,786264+00:00]

The line count and records will vary. Treat the report as sensitive: it can contain usernames, terminal names, host addresses and precise login times. Store it with the same care as the source log, and remove it through your normal retention process when it is no longer needed.

4. Use standard input when a pipeline supplies the file

Because the filename is optional, another command can supply the binary input. A redirection keeps the example simple:

$ utmpdump < /var/run/utmp | sed -n '1,4p'
Utmp dump of /dev/stdin
[2] [00000] [~~  ] [reboot  ] [~           ] [6.8.0-139-generic   ] [0.0.0.0        ] [2026-09-11T14:58:41,014846+00:00]
[6] [01225] [tty1] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [2026-09-11T14:59:13,059298+00:00]

The header now says /dev/stdin, because the program no longer knows the original pathname. If the source filename matters for an audit, pass it directly or add that context to your report metadata.

5. Follow appended WTMP records

--follow keeps the command in the foreground and outputs data appended as the file grows. This is useful during a controlled login test or short observation window:

$ timeout 30 utmpdump --follow /var/log/wtmp
Utmp dump of /var/log/wtmp
[7] [12345] [pts/2] [alice   ] [pts/2       ] [                    ] [192.0.2.10       ] [2026-09-27T17:30:00,000000+00:00]

timeout is a separate utility, not a utmpdump option. It stops this demonstration after 30 seconds; without it, press Ctrl-C when you have enough data. A quiet follow command is not evidence that nothing happened: it may simply be waiting for an append.

6. Do not use reverse mode on live records

Do not run utmpdump --reverse against /var/run/utmp or /var/log/wtmp. The option converts edited text back into binary login records and writes the result to the selected file or standard output arrangement. The manpage warns that the format depends strongly on the input and describes the command as a debugging tool, not normal administration.

If you need to investigate a suspicious entry, keep the original file unchanged, make a separately controlled copy according to your incident process, and work on that copy. A copied dump is not a safe substitute for a forensic image, and editing the text can destroy context. There is no general undo for an overwrite of a live accounting file; recovery means restoring a verified backup or rebuilding the file under an approved maintenance procedure.