Detecting Brute Force Attacks with Splunk

Brute force attacks aren’t just random password guesses, they are high-volume authentication failures that leave a clear trail in system logs. In this project, I built a Splunk detection workflow to identify brute force activity, create automated alerts, and visualise the results in a dashboard.

This was my first hands-on Splunk project, and here’s how I did it step by step:

Step 1: Ingest Authentication Logs

Before we can detect anything, Splunk needs the right data, so I ingested Linux authentication logs (linux_auth_demo) into a dedicated index called “lab”.

I kept all test logs inside the lab index to avoid mixing them with production or default Splunk data.

Step 2: Search for Failed Logins

The raw logs contain both successful and failed login attempts. To isolate brute force behaviour, I searched for events with the keyword “Failed password”.

This gave me individual failed login attempts, but brute force detection requires grouping them.

Step 3: Identify Suspicious Spikes

Afterwards, I built a query that groups failed logins by source IP (src) and counts them over time.

This makes it easy to spot IPs generating bursts of failed logins within a short time window.

Step 4: Create a Real-Time Alert

Detecting is good, but alerts are what analysts rely on, therefore I converted the search into an alert:

• Type: Real-time
• Trigger: If failed login attempts exceed a threshold (for example: 5 in 5 minutes)
• Throttle: By source IP (so we don’t get spammed)
• Severity: High

This ensures analysts are notified only when brute force activity truly looks suspicious, not just from a user typing a password once by mistake.

Step 5: Build a Dashboard Panel

Finally, I visualized the data in a Splunk dashboard panel:

• X-axis: Time
• Y-axis: Number of failed login attempts
• Split by: Source IP

This gives a clear at-a-glance picture of which IPs are hammering the system.

Step 6: Reduce False Positives

Not every spike is malicious, which is why I filtered out service accounts and test environments to avoid false positives and keep the focus on real brute force attempts.

Conclusion

This project has given me me hands-on experience with Splunk search, alerting, and dashboarding. It has also taught me that brute force attacks are noisy, but without the right filtering, the alerts can drown analysts in false positives.

• Full SPL queries, alert configs, and screenshots are documented in this post.
• You can see my quick video summary on my Instagram @maria.cybersec

What’s next…?

In my second project, I’ll extend this by analyzing network traffic for unusual data exfiltration attempts.