Artifact Analysis: Linux Connection Logs (wtmp, btmp, lastlog)

Note

Executive Summary: While text-based logs like auth.log or secure provide high-definition details of the authentication process, Linux systems also maintain a parallel set of structured binary files (wtmp, btmp, lastlog). For DFIR analysts conducting post-mortem analysis on a disk image, these binary artifacts are essential for rapidly establishing a timeline of who logged in, from where, and when, as well as detecting automated brute-force attacks or anti-forensic tampering.

1. The Binary Log Trio

Unlike plain text logs, these files cannot be reliably parsed with standard tools like cat or grep without risking data corruption or misinterpretation. They are typically located in /var/log/ and require specific command-line utilities to decode their C-structure records.

wtmp (Successful Logins)

Records historical data of all successful user logins, logouts, and system reboots/shutdowns. Parsed using the last command.

btmp (Failed Logins)

Records all failed authentication attempts. Critical for identifying brute-force or password spraying attacks. Parsed using the lastb command.

lastlog (Latest Activity)

A sparse file database that records only the most recent login date and time for every UID on the system. Parsed using the lastlog command.

(Note: The utmp file records the current live state of logged-in users. It is highly volatile and generally cleared upon reboot, making it less relevant for offline post-mortem analysis.)

2. Tracking Successful Authentications (wtmp)

The wtmp file serves as the primary access timeline. When conducting offline analysis on a mounted forensic image (e.g., at /mnt/analysis/), analysts must force the tools to read the evidence file rather than the host system’s live logs.

parse_wtmp.sh

# -f targets the specific forensic artifact
# -F prints full dates (including the year) to avoid timeline confusion
last -F -f /mnt/analysis/var/log/wtmp

Hunting Focus

• Anomalous Source IPs: A successful login from an external IP address on a server that should only be accessed via a management VPN is a critical red flag.
• Service Account Hijacking: Observing an interactive shell session for accounts like www-data, apache, or postgres is a near-certain indicator of a Web Shell or a spawned reverse shell.
• System Reboots: Attackers frequently reboot systems (shutdown or reboot entries in wtmp) to load malicious kernel modules or clear in-memory artifacts.

3. Hunting Brute-Force Activity (btmp)

The btmp file is the primary artifact for quantifying credential attacks.

parse_btmp.sh

lastb -f /mnt/analysis/var/log/btmp

DFIR Interpretation

• Brute-Force vs. Human Error: A few failed attempts followed by a success in wtmp usually indicates a typo. Thousands of failures from a single IP over a few minutes indicate an automated attack.
• Targeted vs. Opportunistic: If the btmp file shows attempts targeting non-existent or generic accounts (admin, test, oracle), the attack is likely an opportunistic automated scan. Attempts specifically targeting valid, unprivileged employee usernames suggest a targeted password spraying campaign.

4. Profiling Dormant Accounts (lastlog)

The lastlog file is uniquely structured; it is a table mapping UIDs to their latest login timestamp.

parse_lastlog.sh

# -R specifies the root directory, allowing the tool to map UIDs to usernames
# using the compromised system's /etc/passwd file rather than the analyst's workstation.
lastlog -R /mnt/analysis/

DFIR Interpretation

Analysts must look for the “awakening” of dormant accounts. If a former employee’s account or a service account (bin, daemon, adm) transitions from “Never logged in” to a recent date aligning with the incident window, the attacker has likely resurrected or hijacked that account for persistence.

5. Advanced Parsing & Anti-Forensics (utmpdump)

Threat actors are aware of these logs and frequently attempt to wipe them using commands like echo > /var/log/wtmp or custom wiping tools.

When native commands like last fail due to file corruption, or when analysts need to export the data to a SIEM, utmpdump is the surgical tool of choice. It translates the raw binary structures into human-readable text.

utmpdump_export.sh

utmpdump /mnt/analysis/var/log/wtmp > wtmp_export_forensic.txt

Detecting Log Wiping

If an attacker uses a crude log wiper that overwrites entries with null bytes (\x00), the last command might silently ignore the corruption and skip entries. However, utmpdump will reveal these anomalies, displaying malformed or empty records that definitively prove intentional anti-forensic tampering.

6. Critical DFIR Pitfalls

1. The Timezone Trap: The last and lastb commands format timestamps based on the analyst workstation’s local timezone, not the timezone of the compromised system. Analysts must meticulously account for this offset or use utmpdump to view raw, unadjusted timestamps to avoid catastrophic errors in timeline reconstruction.
2. Log Rotation: Linux aggressively rotates logs. Analysts must ensure they also parse archived files (wtmp.1, btmp.1) to capture the full scope of older intrusions.
3. Empty Artifacts: If wtmp or btmp are 0 bytes in size on an operational server, it is highly probable that the threat actor executed a destructive wipe. Analysts must immediately pivot to searching for the attacker’s actions in the Linux Shell History.

---

References & Further Reading

• SANS Institute: Advanced Incident Response and Threat Hunting
• Related Artifact: Linux Authentication Logs (auth.log & secure)
• Related Artifact: Linux Shell History (.bash_history) Analysis