wtmp and btmp reveal every login and every failed attempt

the two files that snitch on every login

every time someone logs into a linux box, the system writes it down. every time someone fails to log in, the system writes that down too. these go into two separate binary log files, and most people only ever check one of them, which means they miss half the story. read both together in order and you can literally watch a brute force attack happen and then succeed.

wtmp records successful logins. btmp records failed ones. they live in /var/log/ and neither one is human readable on its own, you need a tool to parse them. that's where last and lastb come in.

breaking down the command

last -f /var/log/wtmp -i

this reads the wtmp file specifically (some distros rotate or truncate it, so pointing at the file directly makes sure you're not missing older entries) and shows a list of successful logins. the -i flag forces it to display the source ip address instead of trying to resolve a hostname, which matters because dns lookups can be slow, unreliable, or just wrong if the attacker is coming from an ip with no reverse dns at all. you want the raw ip, not a guess.

what you're scanning for is anything that doesn't fit the pattern. root logging in from a public ip at 3am when your team is asleep and nobody remembers requesting access. a service account logging in interactively when it should never touch a shell. a login from a country your org has no business in. these jump out once you're actually looking.

lastb -i

this is the failure log. lastb reads btmp by default and shows every failed login attempt, again with -i forcing raw ip addresses. this file is usually way longer than wtmp because bots hammer ssh and other login services constantly. most of it is noise. but noise followed by a hit is not noise, it's a pattern.

the pattern that matters

here's the thing that makes this technique actually useful instead of just log-reading busywork. a pile of failed logins from a single ip means nothing on its own, that's just tuesday for any box exposed to the internet. a successful login means nothing on its own either, people log in correctly all the time.

but failed logins from one ip, repeated, targeting the same or a small set of usernames, immediately followed by a success from that same ip, that's a brute force that worked. you're not just seeing "someone got in." you're seeing exactly how long they tried, which account they went after, and the precise moment they got lucky (or the moment your weak password finally gave out). that timestamp is gold for incident response because now you know exactly when to start looking at what that session did next.

why order and correlation beat one log alone

if you only check wtmp, a successful login from a weird ip just looks like an anomaly you might dismiss or argue away. "maybe someone was traveling." if you only check btmp, a wall of failed attempts just looks like standard internet background radiation, every server gets this. the value is in reading them together, in chronological order, and matching ip addresses and usernames across both files. that correlation is what turns two boring log files into an actual incident timeline.

how to protect your own systems

first, actually look at these logs on a schedule instead of only after something's already gone wrong. a quick lastb -i once a week takes thirty seconds and tells you if you're being hammered.

second, kill password-based ssh brute forcing at the source. disable password auth entirely and require key-based login, or at minimum put fail2ban or a similar tool in front of ssh so repeated failures from one ip get auto-banned before they ever succeed.

third, restrict root login over ssh. if root can't log in remotely at all, a brute-forced root account is a dead end no matter how many attempts someone throws at it.

fourth, ship these logs somewhere off the box. wtmp and btmp can be rotated, truncated, or wiped by an attacker with enough access, so forward them to a central log server or siem where they can't be quietly erased.

the takeaway

wtmp and btmp aren't exciting files, they're plain login records, but read together in order they can hand you an entire attack timeline for free. check both regularly, correlate ip and timing, lock down ssh with keys and rate limiting, and get your logs off the host so nobody can clean up after themselves. the data's already there, you just have to actually read it.