Lab 12: How I Taught My SIEM to Recognize an Attack

Lab 11 got the pipeline running.

Logs were flowing from my Kali Linux host into Elastic SIEM. The agent was enrolled. The data was real. But a SIEM that ingests logs and does nothing with them is just an expensive storage system.

Lab 12 was where I flipped the switch from passive to active — from collecting data to actually detecting threats.

What Detection Rules Actually Are

Before I get into the lab, it's worth explaining what a detection rule is, because it's one of those terms that sounds more complicated than it is.

A detection rule is a condition. It tells the SIEM: if you see this pattern in the logs, fire an alert.

That's it. The sophistication is in how you define the condition — what data you're looking at, what pattern you're matching, and how you tune the rule to catch real threats without drowning analysts in false positives.

Elastic Security gives you two ways to build detection coverage. Prebuilt rules developed and maintained by Elastic's security team, mapped directly to the MITRE ATT&CK framework. And custom rules you write yourself, tailored to your specific environment.

In Lab 12, I used both.

The Prebuilt Rules: Standing on the Shoulders of Elastic's Security Team

My first move was installing three prebuilt Elastic detection rules targeting Linux-based attack techniques:

• Linux User Account Credential Modification — detects changes to user credentials, a common post-exploitation technique

• Potential Internal Linux SSH Brute Force Detected — flags repeated failed SSH authentication attempts from inside the network

• Potential Linux Hack Tool Launched — identifies execution of known offensive security tools on a Linux host

Each of these rules is mapped to specific MITRE ATT&CK techniques. The SSH brute force rule, for example, maps to T1110 (Brute Force), T1110.001 (Password Guessing), and T1110.003 (Password Spraying). That mapping matters because it gives analysts immediate context when an alert fires — not just what happened, but where it fits in the attacker's playbook.

Installing prebuilt rules is straightforward. You navigate to the Detection Rules section in Elastic Security, browse the rule library, and enable the ones relevant to your environment. Three clicks and you have enterprise-grade detection logic written by people who track real threat actors for a living.

That's not something to take lightly.

The Custom Rule: Writing My First KQL Detection Logic

Prebuilt rules cover common attack patterns. But every environment has unique characteristics that prebuilt rules can't anticipate. That's where custom rules come in.

For Lab 12, I wrote a custom rule to detect failed SSH authentication attempts on my Kali Linux host using KQL — Kibana Query Language. KQL is Elastic's search syntax, and it's readable enough that you can understand what a query is doing even if you've never written one before.

The rule settings:

• Name: SSH Authentication Failure Detected

• Severity: Medium

• Risk Score: 47

• Rule Type: Custom Query

• Query Language: KQL

The query targets authentication events where the outcome is a failure — specifically catching the pattern of repeated failed login attempts that characterizes a brute force attack.

Writing this rule taught me something that reading about KQL never would: the query has to match the data that's actually in your environment. If your log source isn't structured the way your rule expects, the rule won't fire — even if the attack is happening. The rule is only as good as the data behind it.

Testing the Rules: Simulating an SSH Brute Force Attack

Rules that have never been tested are rules you can't trust. So I ran a simulation.

Using the Kali Linux host, I generated repeated failed SSH authentication attempts against the local SSH service:

sudo systemctl start ssh
ssh invalid_user@127.0.0.1

Multiple failed attempts. Multiple invalid users. The kind of activity that, on a real network, would indicate someone systematically trying to guess their way into a system.

Then I went to the Elastic Security Alerts dashboard and waited.

The rules fired.

Not all of them — and that matters, which is exactly what Lab 13 is about. But the detection logic was working. The pipeline from attack activity to log ingestion to rule evaluation to alert generation was intact.

That's a working SOC detection workflow, built from scratch.

What This Lab Actually Taught Me

Detection engineering is about more than writing queries. It's about understanding the relationship between attacker behavior, log data, and detection logic — and knowing where that chain can break.

A few things that landed differently after doing this hands-on:

MITRE ATT&CK isn't just a framework for reading. When you see your own detection rules mapped to T1110 and its sub-techniques, the framework stops being abstract. It becomes a practical tool for understanding what you're detecting and what gaps you still have.

Prebuilt rules are a starting point, not a finish line. They give you solid baseline coverage fast. But real detection engineering means understanding your environment well enough to write the rules that prebuilt libraries don't cover.

Rule tuning is the real work. Getting a rule to fire is easy. Getting it to fire on real threats without burying your analysts in noise is the skill that separates good detection engineers from great ones.

What's Next

The rules are configured. The simulation ran. Some alerts fired.

But not all of them — because there was a detection gap I didn't know about yet. One that would take eight more labs to find and fix.

That's Lab 13.

Full lab report and documentation on GitHub: github.com/RouteToRoot

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