# Lab 13: The Attack Ran. The Alerts Didn't Fire.

In Lab 12, I built the detection rules.

Three prebuilt Elastic rules targeting Linux attack techniques. One custom KQL rule for SSH authentication failures. The pipeline was configured, the rules were live, and the SIEM was watching.

Lab 13 was the moment of truth — run a real attack simulation and see if the detections held up.

They didn't.

* * *

### The Attack

The setup was straightforward. Start the SSH service on the Kali Linux host, run a brute force loop generating repeated failed authentication attempts against the local SSH service using an invalid username, and watch the Elastic Alerts dashboard for rule triggers.

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

Ten connection attempts. Three failed password entries per attempt. Thirty total authentication failure events generated on the host.

The attack worked exactly as expected. Confirmation came straight from the system journal:

```plaintext
sudo journalctl -u ssh --since "1 hour ago" | tail -20
```

The output was unambiguous — invalid user attempts from 127.0.0.1, failed password entries per connection, connection closed entries confirming authentication denial. Thirty failed authentication events, all logged, all verified.

The attack happened. The logs proved it.

* * *

### The Alerts Dashboard

I pulled up the Elastic Security Alerts dashboard and waited.

Nothing.

Zero alerts. Four rules configured — three prebuilt Elastic rules and one custom KQL rule — and not a single one triggered. The Rule Monitoring tab told the same story: one rule succeeded, three with no response, zero failures, zero errors.

The rules weren't broken. They just hadn't seen anything to alert on.

* * *

### Finding the Gap

This is where the lab shifted from attack simulation to detection engineering.

When an alert doesn't fire, there are only a few possible explanations. The attack didn't happen. The logs weren't generated. The logs weren't collected. The logs weren't in the right data stream. Or the rule query didn't match the data.

I'd already eliminated the first two — the attack happened and the logs were confirmed in the system journal. So I worked down the chain.

The Elastic detection rules query specific index patterns:

*   `filebeat-*`
    
*   `logs-system.auth-*`
    

Neither of those data streams contained the SSH failure events from the Kali host.

Root cause identified: the SSH authentication failure events generated on Kali Linux are stored in the systemd journal and the `/var/log/btmp` binary log file. The Elastic Agent System integration, as currently configured, wasn't collecting those specific log sources. The agent was enrolled and sending data — just not the right data.

The SIEM had blind spots it didn't advertise.

* * *

### What the Detection Gap Actually Means

Here's the thing about detection gaps — they're not failures. They're findings.

In a real SOC environment, this is exactly the workflow: simulate attack activity, monitor for alerts, trace the detection chain when alerts don't fire, identify the gap, document it, remediate it. The gap between attack execution and alert generation has to be traced systematically — host logs → agent collection → data stream → rule query → alert. Every link in that chain is a potential failure point.

The fact that I could run the simulation, confirm the attack in host logs, monitor the SIEM, identify zero alerts, and then trace the root cause to a specific log ingestion configuration issue? That's not a failed lab. That's the lab working exactly as it should.

| Component | Status |
| --- | --- |
| SSH brute force executed | ✅ Confirmed |
| Attack logs on host | ✅ Confirmed (journalctl) |
| Logs ingested to Elastic | ❌ Not confirmed |
| Detection rules triggered | ❌ No |
| Alerts generated | ❌ No |

Detection gap documented. Remediation path identified.

* * *

### What This Taught Me

A SIEM is only as effective as its log sources.

That sounds obvious when you read it. It hits differently when you've just watched thirty brute force events generate zero alerts because the agent wasn't configured to forward the right logs. The detection rule was correct. The attack was real. The gap was a misconfiguration that would have been invisible without running this test.

Real-world SOC environments have these gaps all the time. Misconfigured agent policies, blind spots in log collection, data streams that don't match rule queries. The analysts who find them — by running simulations, tracing detection chains, and documenting what they find — are the ones who actually improve the security posture of their organization.

Documenting a detection gap is as valuable as documenting a successful detection. It demonstrates that you understand the full pipeline, not just the alerts dashboard.

* * *

### What's Next

The gap is documented. The remediation path is clear.

Lab 14 moves into threat hunting in Kibana — but the SSH detection gap doesn't go away quietly. It follows the lab series for the next several labs until it finally gets resolved.

That resolution is coming. But first, there's more to build.

Full lab report on GitHub: [github.com/RouteToRoot](https://github.com/RouteToRoot)

*Follow the journey:*  
*GitHub: github.com/RouteToRoot*  
*YouTube: youtube.com/@RouteToRoot\_Sec*  
*Portfolio:* [*routetoroot.io*](http://routetoroot.io)