Lab 24: The Attack Ran. The Alerts Fired.

In Lab 13, I ran a brute force attack and got zero alerts.

In Lab 24, I ran the same attack in Splunk.

15 alerts fired in under 2 seconds.

That's the difference between a detection gap and a detection capability — and this lab is the proof.

The Attack

Same simulation I've been running since Lab 13. A scripted loop generating ten consecutive failed SSH authentication attempts against a non-existent user account:

for i in {1..10}; do ssh -o ConnectTimeout=5 invalid_user@127.0.0.1; done

Ten connection attempts. Each one targeting invalid_user@127.0.0.1. Each one rejected.

What's worth understanding is why ten connections generated 48 events. Every SSH connection attempt that fails produces multiple log lines — Invalid user, Failed none, Failed password, Connection closed. One connection attempt, four events. The auth.log doesn't just record that someone failed to authenticate. It records every step of that failure in detail.

That granularity is what makes auth.log such a valuable log source for brute force detection.

The Detection Results

The SSH Brute Force Detection rule from Lab 23 was live and watching.

15 alerts fired.

Real-time. Per-result. Within seconds of the attack starting.

The Triggered Alerts dashboard showed all 15 firing between 16:19 and 16:21 CDT — a two-minute window covering the entire attack simulation. Alert name, severity, timestamp, all documented.

Then I ran a post-simulation SPL search to validate the full event count:

source="/var/log/auth.log" "invalid_user" earliest=-15m

48 events returned.

All confirmed as SSH brute force activity from the simulation. All timestamped within the attack window. All sourced from /var/log/auth.log via rsyslog into Splunk's index.

The Full Detection Pipeline

Here's what happened between the attack and the alert, and how fast it happened:

Attack executed
  → auth.log updated
    → rsyslog forwarded to Splunk
      → Splunk indexed the event
        → Real-time rule evaluated
          → Alert fired

Total time from attack event to alert: under 2 seconds per event.

That pipeline — from attack activity on the host all the way through to a triggered alert in the SIEM dashboard — is what end-to-end detection actually looks like. Not a report. Not a scheduled scan. Real-time visibility into active attack behavior.

Why This Matters More Than It Looks

Lab 24 isn't just a validation exercise. It's a demonstration of something that matters in a real SOC environment.

In production, a rule like this doesn't fire on simulated attacks. It fires on real ones — on the 3 AM brute force campaign targeting an internet-facing SSH service, on the lateral movement attempt from a compromised internal host, on the credential stuffing attack that's been running quietly for six hours.

The analyst who built this rule, understands why it's configured the way it is, and knows how to verify it's actually working — that analyst is ready to operate in a real environment.

That's what this series has been building toward.

Splunk vs Elastic — The Comparison

This is the fourth time I've run an SSH brute force simulation across this lab series. Here's what the comparison looks like:

Different platforms. Different alert counts — because different rule configurations produce different per-event alert behavior. Same detection logic. Same attack. Same result: the attack was caught.

Platform-agnostic detection in practice.

What's Next

The detection pipeline is proven. The alerts are firing.

Lab 25 is the final Splunk lab — threat hunting. Not waiting for alerts to fire. Proactively searching the data for patterns that indicate malicious activity, even when no rule was triggered.

That's where detection engineering becomes threat intelligence.

Full lab report on GitHub: github.com/RouteToRoot

Follow the journey:
GitHub: github.com/RouteToRoot
YouTube: youtube.com/@RouteToRoot_Sec
Portfolio: routetoroot.io