Hunting in logs

Log hunting is mostly filtering: reduce thousands of lines to the dozen that matter, then read those dozen carefully. The method below works on any auth log, from a laptop to a fleet.

The narrowing pattern

Start wide, then narrow. First list the failures (grep Failed auth.log) — volume tells you whether anyone is even knocking. Then group by source: one address repeating against root is a different story from scattered failures across accounts. Then check the adjacent successes: a login that follows a burst of failures from the same address is the classic shape of a guessed password, and it is the single pattern to memorize from this lesson.

$ grep Failed auth.log | cut -d' ' -f11 | sort | uniq -c | sort -nr
      7 203.0.113.9
      1 198.51.100.23
$ grep Accepted auth.log
03:03:05 Accepted password for root from 203.0.113.9

Seven failures then a success, same host, same account, minutes apart. That is the whole case.

Count as you go

How many failures, from where, against which accounts, over what window. Numbers turn a feeling into a finding, and they are what your detection rule will encode next: 5+ failures from one host in 10 minutes is literally the count you just did, formalized. In this lab an overnight auth.log holds exactly one break-in — find it before you theorize, and bring the count.

What to do with the answer

A confirmed guess-and-enter means: the password is burned (rotate it), the source is hostile (block and watch for siblings), and the session's aftermath is unknown (check what the login did — new keys, new users, outbound connections). Containment first, then eradication, covered properly in the response lesson.

Key takeaways

• Narrow wide → by-source → adjacent successes. Bursts-then-login is the shape to memorize.
• Counts become detections: your next lesson encodes this exact pattern as a rule.
• A found break-in triggers rotation, blocking, and aftermath review — in that order.