Home / Alt manpages / chklastlog(8)

  • chklastlog(8)
  • Admin command
  • linux

Spot Wiped Login Records with chklastlog

Someone with root can scrub their own line from /var/log/lastlog, and chklastlog is the old trick for catching that. It compares login records in /var/log/wtmp with the per-user records in /var/log/lastlog, takes about ten minutes on a single host, and only reads files, so it normally needs no elevated privileges.

The route

Jump straight to the step you need, or tick off Done means at the end.

  • You need: a shell and the chkrootkit package.
  • A hit is a lead, not a verdict. A reported account is something to investigate. It is not proof of compromise.

1. Check the installed version and command

On the system used for this guide, Debian package version chkrootkit 0.58b-1 provides the command. Check your own package before comparing results with another host, because this is an old utility with platform-specific limitations:

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

On a non-Debian distribution, use its package query tool and confirm the command is actually installed.

Tip

Do not copy the version shown above into an incident record unless your own command reports it.

2. Confirm both input files are readable

chklastlog reads the whole wtmp login and logout database, then checks each user it finds against lastlog. Check both paths first:

$ ls -l /var/log/wtmp /var/log/lastlog
$ test -r /var/log/wtmp && echo 'wtmp: readable'
wtmp: readable
$ test -r /var/log/lastlog && echo 'lastlog: readable'
lastlog: readable

The command needs read access to both files. If either test fails, stop and arrange access through your normal operations process.

Warning

Do not change ownership or permissions just to make a rootkit check run. That alters the evidence and could expose authentication history.

Checkpoint

Both files exist and are readable, and you have noted their paths. The manual calls the second database lastlog in its file list, although its description also spells it lastlogin. On this Linux installation the path is /var/log/lastlog.

3. Run the comparison

Run the command with no options. It has no documented flags or interactive mode:

$ chklastlog
$ status=$?
$ printf 'chklastlog exit status: %s\n' "$status"
chklastlog exit status: 0

A clean run normally prints no account names and returns status 0, as it did on the machine used here. Capture the status immediately, because running another command first replaces it.

When there is something to see, the output is a list of users found in wtmp without matching information in lastlog. Save the terminal output with the host name, time and package version.

Warning

Do not edit either log to make the result disappear.

4. Treat a reported user as a lead

A missing lastlog entry can suggest someone tried to cover their tracks, which is why the tool exists. It does not tell you who changed the file, when, or whether the account was compromised. Your order of work:

  1. Preserve the originals. Keep the original records and the exact command output.
  2. Review the account. Look at it, the authentication logs and other independent evidence.
  3. Follow your incident procedure. Let it decide what happens next.

For a quick, read-only record of the account database, look up the named account without changing anything:

$ getent passwd -- 'ACCOUNT_NAME'
ACCOUNT_NAME:x:1001:1001:Account Name:/home/ACCOUNT_NAME:/bin/bash

Replace ACCOUNT_NAME with the name chklastlog printed. If the lookup returns nothing, that is another fact to record, not a reason to create or delete an account.

Warning

Avoid locking, resetting or removing the account until an authorised responder has decided containment is required. Those actions can destroy useful evidence or interrupt a legitimate service.

5. Know what the check cannot prove

The result is bounded by the two databases. Three limits to keep in mind:

  • An incomplete wtmp. The manual warns that wtmp may itself be incomplete, because not every program records activity through utmp logging. A clean result does not prove every login was legitimate or that the host is free of rootkits.
  • A timing blind spot. If a user logs in after a lastlog entry was deleted, the later login can recreate the entry and the deletion may go undetected. Run the check promptly when you suspect an event, and compare it with logs held in separate storage or collected by another route.
  • SunOS roots. The program was originally designed for SunOS 4.x. It is usable for this Linux workflow, but the manual says output is undefined on other systems, so do not use an unverified result as a cross-platform compliance control.

6. Record and repeat safely

The utility makes no documented changes to the log files, so there is nothing to undo. Save the output and status in your case notes, then repeat only when you need a fresh comparison:

$ hostname
HOSTNAME
$ date --iso-8601=seconds
2026-09-22T16:00:00+01:00
$ chklastlog
$ printf 'exit=%s\n' "$?"
exit=0

Replace the illustrative host name and time with the real output from your machine.

Recovery

If the command cannot open a file, keep that error, check the path and permissions again, and look into log rotation or an unusual logging layout. An empty result only counts if the command completed and you captured its status.

Done means

  • The version is recorded. You have the installed chkrootkit version and command path.
  • Both logs were readable. /var/log/wtmp and /var/log/lastlog opened without any permission changes.
  • The evidence is saved. That means the complete chklastlog output and its immediate exit status.
  • Hits are leads. Any reported account is under investigation, not treated as automatic proof of compromise.
  • Limits are accounted for. Incomplete wtmp logging, later logins recreating entries and the platform limitation are all noted.