Beginner·200 points·7 solves

SSH Brute Force Detection

Students learn to triage SSH authentication logs by grouping failures by source, distinguishing password guessing from password spraying, and determining whether an attack actually succeeded rather than simply reporting the loudest one.

The vulnerability

An internet-facing SSH host logs constant brute-force noise, so the analyst's real job is deciding whether any of it worked. The evidence sits in /var/log/soc. auth.log holds a day's worth of SSH authentication events - far too many to read in order, so they have to be grouped before they are read. sshd_config.txt records how the server is configured and which hardening gaps the platform team has accepted, and it can explain an outcome the log alone cannot: OpenSSH prints the same failure line whether the password was wrong or the account was never permitted to log in at all. asset-inventory.csv says which accounts authenticate with passwords rather than keys, and which source ranges are corporate - that pairing is what separates an ordinary password login from a suspicious one. ssh-auth-reference.md covers how to read the failure messages and the difference between password guessing, which works through many passwords against one account, and password spraying, which tries a couple of passwords against many accounts to stay under lockout thresholds. Two separate external sources are active on the night under review and they are nothing alike in volume. Volume is the easiest signal to see and the least correlated with impact: counting failures tells you that you were attacked, only the successes tell you whether you were breached.

Your tasks

Group the failures by source

Count the 'Failed password' lines in auth.log grouped by source address instead of reading the file in order. The distribution is the finding: note every external address that appears and its failure count, including the quieter ones that the largest source buries. Be exact about what you count - the noisiest source also emits connection-teardown lines ('Disconnected ... [preauth]') which are not authentication attempts, so a bare match on the address inflates the total.

Characterise the high-volume campaign

Describe the shape of the dominant source: how many distinct accounts it targets, how fast the attempts arrive, and over what window. Then ask the question analysts skip and search that address for 'Accepted' to establish whether it ever got in. The log will not tell you why the outcome is what it is - read sshd_config.txt and check how the server is configured to treat the account being targeted.

Find the attack that actually worked

Stop counting failures and look at what succeeded. Most 'Accepted' lines are publickey logins by staff; only a handful are password logins, and several of those are ordinary business - 'Accepted password' on its own is not a finding. Use asset-inventory.csv to establish which accounts authenticate with passwords and which source ranges are corporate, then test every password success against both: expected account type from an unexpected network is what separates the breach from a contractor doing their job. Record the account, the source address and the exact timestamp; auth.log omits the year, so take that from the incident brief.

Classify both campaigns

Apply the definitions in ssh-auth-reference.md - guessing is many passwords against one account, spraying is a few passwords against many accounts - and decide which label fits each source from the shapes you measured. Then explain why the quieter shape defeats this host's defences: sshd_config.txt caps attempts per connection rather than per account, and the platform team's notes there record what else is switched off. Finally, map both campaigns to the single MITRE ATT&CK technique that covers them; the two shapes are sub-techniques of the same parent.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

How do you detect SSH brute force attacks?

Look in auth.log for many failed password entries from one source in a short time, then check for any accepted login from the same or related addresses. Counting failures per source and per username quickly reveals brute force activity.

What is the difference between brute force and password spraying?

Brute force tries many passwords against one account, creating noisy failures. Password spraying tries a few common passwords across many accounts or hosts, staying under lockout and volume thresholds, which makes it harder to spot.

Is the SSH brute force detection lab free?

Yes. The lab is free and suited to beginners. You triage real-looking auth.log data in the browser and learn to find the successful breach that a simple volume alert would miss.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us