Authentication Log Analysis: Reconstructing Logins

You are handed a host and one question: did someone log in who shouldn't have? Before an attacker can run a process, open a port, or plant a backdoor, they almost always have to authenticate first — and authentication is one of the most reliably logged events on a Linux system. Every SSH attempt, every sudo, every console login leaves a line behind.

This lesson follows one incident from start to finish: an SSH brute force from 203.0.113.66 that hammered the host with failed passwords and then, eventually, succeeded. Your job is to reconstruct that story purely from the auth records and pin down the exact moment of compromise.

Think of it like a building's badge-entry log. A door reader records every swipe — accepted or denied. A legitimate employee shows up as a single clean accepted swipe each morning. But a thief trying stolen badges leaves a very different trace: a long run of denied swipes at one door, late at night, then suddenly one accepted swipe. That one accepted swipe — right after the wall of denials — is the break-in moment. Auth logs are that badge reader, and 203.0.113.66 is the person at the door.

The single most common way an auth investigation stalls is looking in the wrong file, finding nothing, and wrongly concluding the box is clean. Where sshd, sudo, and PAM write their authentication events depends on the distribution:

• Debian / Ubuntu → /var/log/auth.log
• RHEL / CentOS / Fedora / Rocky → /var/log/secure
• systemd hosts → the same events also live in the journal, queryable by unit (ssh or sshd) or by command name (_COMM=sshd)

On most modern systems both exist: rsyslog writes the flat file and journald keeps a binary copy. Knowing all three means you are never stuck on an unfamiliar box.

sshd narrates every connection in a small, predictable vocabulary. Learn the handful of phrases and you can read an attack like a sentence. Here are the lines that matter, from a single sequence in our incident:

Two more line types complete the picture — what happens after a successful login. PAM (the Pluggable Authentication Modules layer) logs the session lifecycle, and any privilege escalation shows up as sudo or su lines:

Alongside the text logs, the kernel and login programs keep three binary databases you read with dedicated tools — not with cat or grep, because they're not text files. Each answers a different question:

• `last` reads `/var/log/wtmp` → a history of successful logins, logouts, and reboots
• `lastb` reads `/var/log/btmp` → a history of failed login attempts (root-only)
• `lastlog` reads `/var/log/lastlog` → the single most recent login time for every account

The trap to internalize now: last and lastb read different files. Look in the wrong one and you'll see the wrong outcome.

Now you put it together into the workflow that turns thousands of log lines into one conclusion. A real attack buries its one successful login under a mountain of failures — you can't read them line by line. So you aggregate: count failed passwords per source IP. The IP with hundreds of failures is the brute force; everything else is noise.

This is the badge-log method from step 1, made concrete: tally the denied swipes by who was swiping, find the one address responsible for the wall of denials, then look for that same address's first accepted swipe.

You have the attacker IP. Now answer the question that actually matters: did they ever get in, and when? Search that exact IP for the first Accepted line. A brute force with zero Accepted lines failed; one with an Accepted line succeeded, and that line's timestamp is the moment of compromise.

You have a real root shell. Run these read-only reads in order — the same sequence you'd use on a 'did someone log in?' call. There may be nothing malicious on this box; the point is to make the moves reflexive. Each command is safe and read-only: you are reading existing records, not changing anything. Note anything that breaks the pattern — odd hours, external IPs, a lopsided failure count — as you go.