Skip to content
Back to work
Detection Engineering

SSH Brute-Force Detection & Analysis

A SOC-style Splunk dashboard built on a real public SSH authentication dataset, correlating failed-login patterns across thousands of events to identify brute-force sources and confirm whether any resulted in compromise.

The Problem

SSH login attempts are one of the most common sources of security alerts in enterprise environments — driven by brute-force attempts, misconfigurations, or insider misuse. Turning that raw log volume into an actionable signal is a core SOC skill.

Objective

To analyze a real SSH authentication dataset end-to-end in Splunk and build a SOC-style dashboard that surfaces brute-force activity the way an analyst would in production.

Approach

  • Sourced a real SSH authentication log dataset (ssh.log.gz) from the public MACCDC 2012 dataset and ingested it into Splunk under a dedicated sourcetype.
  • Extracted key fields — source/destination IP and port, authentication status, timestamp, and data direction — to structure the analysis.
  • Built a 5-panel SOC dashboard: total authentication attempts, success-vs-failure ratio, top source IPs by volume, a brute-force detection panel binning failed attempts into 5-minute windows, and a per-IP success/failure breakdown to check for compromise.
  • Defined a brute-force threshold of more than 20 failed attempts from a single IP within 5 minutes, and used SPL (`bin`, `stats`, `where`) to flag IPs exceeding it.

Tools & Technologies

  • Splunk
  • SPL

Outcome

Out of 7,143 total authentication attempts, the dashboard identified 5,069 failed logins, 301 successful, and 1,773 undetermined. The top source IP (192.168.202.141) alone generated 2,380 attempts — 2,365 of them failures — clearing the brute-force threshold. Cross-referencing successful logins by IP confirmed none of the flagged high-volume sources also had a successful login, ruling out compromise from the observed activity.

Lessons Learned

  • Real-world log data is messier than synthetic data — handling an 'undetermined' auth-status bucket required deliberate decisions about field extraction, not just clean success/fail parsing.
  • This analysis was built on static, pre-collected logs; the natural next step is extending it to real-time ingestion and live alerting.

Links