SSH brute-force log investigation

Objective

Work through a set of SSH authentication logs the way a SOC analyst would: find out whether anything malicious happened, describe the attacker behavior, and write it up as an incident report.

The full project, including the log file, the commands, and the report, is on GitHub: soc-log-investigation.

Environment

• Dataset: OpenSSH_2k.log from LogHub, a public collection of real system logs. It covers about four hours of activity on one Linux server.
• Workstation: Ubuntu Linux
• Tools: grep, awk, sort, uniq, and wc in a Bash terminal. No SIEM. The point was to understand the raw data before letting a tool summarize it.

Investigation

1. Count the failures

grep "Failed password" OpenSSH_2k.log

The log holds 520 failed password attempts. For a four-hour window on one server, that is not a few people mistyping passwords.

2. Find who was attacking

grep "Failed password" OpenSSH_2k.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

The failures came from 23 different IP addresses, but most of the volume came from a few. One address alone made 286 attempts, more than half the total. The next two made 80 and 46.

3. Find what they were trying to get into

grep "Failed password" OpenSSH_2k.log | awk '{print $(NF-5)}' | sort | uniq -c | sort -nr | head

370 of the 520 failures targeted root. The next most common target was admin, followed by service-style names like support, oracle, and test. About a quarter of the failures (135) were for usernames that do not exist on the server at all. That is the signature of automated password guessing that works from a list of common account names, not someone targeting this server’s real users.

4. Look for anything that got in

grep "Accepted password" OpenSSH_2k.log

Out of all that traffic, exactly one login succeeded: user fztu, from 119.137.62.142.

5. Follow that session

grep "fztu" OpenSSH_2k.log

The session opened at 09:32:20 and closed normally at 09:45:06, about 13 minutes later.

What the successful login does and does not show

This was the part worth slowing down on.

• It succeeded on the first attempt. There were no failed passwords for fztu before it.
• It came from a different address. 119.137.62.142 does not appear anywhere in the brute-force traffic. It shows up only for this one session.

A login that succeeds cleanly from an address with no failed attempts could be a legitimate user. It could also be an attacker using credentials obtained somewhere else. The logs alone cannot tell those apart, and there is no command history to show what the session did. So I rated it medium risk, pending verification, rather than calling it either a compromise or a false alarm.

Assessment

The log shows automated SSH brute-force activity consistent with internet-wide scanning: a few high-volume sources, privileged and common account names, and many usernames that do not exist. None of that traffic succeeded. The one successful login is separate from the attack traffic and needs confirmation from the account owner, along with endpoint logs or command history if they exist.

Recommendations

• Confirm with the owner of fztu whether the 09:32 session was theirs
• Disable SSH login for root
• Require multi-factor authentication or key-based authentication for SSH
• Block or rate-limit sources after repeated failures
• Watch for logins from addresses with no prior history on the server

What I took from it

Most of the work was not finding the attack. 520 failures are easy to spot. The real work was the one quiet line among them, and being precise about what it proves. That is why I’m now building a Splunk lab: I want to see how the same questions become automatic detections, having already answered them by hand.