Building a Detection Rule for Brute Force Attacks in Splunk

Problem

Out-of-the-box brute force rules were generating ~200 alerts per day with a >90% false positive rate, mostly from legitimate mobile clients retrying after password changes.

Approach

Rebuilt the detection from the ground up:

1. Stats-based thresholding per user + source IP over rolling 15-minute windows.
2. Outlier detection using eventstats to compare a user's failure rate against their 30-day baseline.
3. Added password-spray logic: multiple distinct usernames from a single source with a narrow failure distribution.
4. Suppression for known mobile device user-agents post-password-reset events.

Example SPL (simplified)

index=auth sourcetype=azure_signin status="Failed"
| bin _time span=15m
| stats dc(user) as uniq_users count as fails by _time src_ip
| where uniq_users > 10 AND fails > 30
| lookup known_mobile_reset ip as src_ip OUTPUT is_known
| where isnull(is_known)

Results

• Alert volume: ~200/day → ~4/day
• True positive rate: >85%
• MTTD on real brute force activity cut from hours to under 4 minutes.

Lessons Learned

Detections age. Schedule quarterly reviews, and always measure precision and recall, not just volume.