How to build a detection pipeline that catches real threats. Full Wazuh + Elastic setup, writing your own detection rules, and learning how to triage and hunt.
A SIEM · Security Information and Event Management system · is the central nervous system of a detection operation. It collects logs from every system in your environment, correlates events across them, and surfaces the things worth investigating.
The problem is that enterprise SIEMs like Splunk cost six figures a year. Wazuh paired with the Elastic Stack gives you 80% of that capability for free. That's what we're building in this room.
You'll need a Linux machine · physical or VM · with at least 4GB RAM and 20GB disk. Ubuntu 22.04 LTS works well. We install everything from scratch.
Wazuh is an open-source security platform that handles log collection, file integrity monitoring, vulnerability detection, and active response. Elastic (formerly ELK stack) handles the data storage, search, and visualization layer.
Together they give you a full SIEM pipeline: agents on your endpoints push logs to the Wazuh manager, which processes them against detection rules and forwards them to Elastic for storage and dashboards.
Wazuh has a one-line installer that handles the manager, indexer, and dashboard. Run this on a clean Ubuntu machine:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash wazuh-install.sh -aThe -a flag installs all components on the same machine. For production you'd split them, but for a lab this is fine. Installation takes 5-10 minutes.
Once complete, verify everything is running:
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboardAll three should show active (running). Access the dashboard at https://YOUR-IP · the default credentials are printed at the end of the install script.
An agent runs on every system you want to monitor and ships its logs back to the manager. To add a Linux agent:
# On the endpoint you want to monitor
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor > /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt update && apt install wazuh-agent
# Set your manager IP
WAZUH_MANAGER='YOUR.MANAGER.IP' apt install wazuh-agent
systemctl enable wazuh-agent && systemctl start wazuh-agentWazuh rules are XML files that define what triggers an alert. Every rule has an ID, a level (severity 0-15), and conditions that match against log fields.
<rule id="100001" level="10">
<if_group>authentication_failed</if_group>
<match>Failed password</match>
<description>SSH brute force attempt detected</description>
<group>authentication_failures,</group>
</rule>Custom rules go in /var/ossec/etc/rules/local_rules.xml. Never edit the default rules · they get overwritten on updates.
Sigma is a vendor-neutral detection rule format. You write a rule once, then convert it to Wazuh, Splunk, Elastic, or any other platform. This is how threat intel teams share detection logic.
title: Suspicious PowerShell Download
status: experimental
description: Detects PowerShell downloading files from the internet
logsource:
product: windows
service: powershell
detection:
selection:
EventID: 4104
ScriptBlockText|contains:
- 'DownloadFile'
- 'WebClient'
- 'Invoke-WebRequest'
condition: selection
level: mediumWhen an alert fires, the goal is to quickly determine: is this a true positive, a false positive, or something that needs more investigation?
My triage process: 1) Look at the raw log that triggered it. 2) Check what else that host did in the 10 minutes before and after. 3) Pivot on any IPs, hashes, or usernames involved. 4) Make a call: close it, escalate it, or keep watching.
Most alerts are false positives. That's normal. Your job is to tune your rules over time so the signal-to-noise ratio improves. Document every false positive you close so you can write a suppression rule.
Detection rules catch known-bad behavior. Threat hunting is about finding things your rules missed. You start with a hypothesis · "I think there's lateral movement happening" · and go looking for evidence.
In Elastic/Kibana, start with these queries to spot anomalies:
# Unusual process spawning
process.parent.name: "winword.exe" AND process.name: "cmd.exe"
# Outbound connections on unusual ports
destination.port: (4444 OR 1337 OR 31337)
# Multiple failed logins followed by success
event.action: "logon-failed" AND user.name: *