Wazuh Rules & Decoders

The Engine Behind the Alerts

In Lessons 2.1–2.4, you learned to read alerts, build dashboards, and search for events. But you've been treating the SIEM as a black box — logs go in, alerts come out. Now it's time to open that box and understand the engine.

Every alert you've investigated in this course was created by two components working together:

1. Decoders — parse raw log text into structured fields
2. Rules — evaluate those fields against detection logic and generate alerts

Understanding rules and decoders transforms you from a consumer of alerts to someone who can evaluate, tune, and eventually write detection logic. This is the bridge from L1 (triage) to L2 (investigation and detection engineering).

Why This Matters for Your Career: "Can you read a detection rule?" is a common SOC interview question. Understanding rule logic is expected for any analyst role above entry level. In Module 8 (Sigma), you'll write cross-platform detection rules — but first, you need to understand how rules work in one SIEM.

Click to enlarge

Stage 1: Decoders — Parsing Raw Logs

A raw log is just a line of text. Before any detection can happen, Wazuh needs to understand that text — extract the fields, identify the source, and structure the data for rule evaluation.

What a Raw Log Looks Like

Here's a raw SSH failure log from /var/log/auth.log:

Jan 15 06:20:18 linux-web-01 sshd[5102]: Failed password for root from 185.220.101.42 port 44921 ssh2

This is just a string. Wazuh needs to extract: the timestamp, hostname, program (sshd), the event type (failed password), the target user (root), the source IP (185.220.101.42), and the port (44921).

How Decoders Work

Decoders use regular expressions (regex) and field extraction patterns to parse raw logs. They work in a chain:

1. Pre-decoder — extracts the standard syslog header (timestamp, hostname, program)
2. Parent decoder — identifies the log source (e.g., "this is an sshd log")
3. Child decoder — extracts event-specific fields (source IP, user, port)

Decoder XML Example

Here's a simplified version of Wazuh's SSH decoder:

<!-- Parent decoder: identifies sshd logs -->
<decoder name="sshd">
  <program_name>sshd</program_name>
</decoder>

<!-- Child decoder: extracts failed password fields -->
<decoder name="sshd-failed">
  <parent>sshd</parent>
  <prematch>^Failed password for </prematch>
  <regex>^Failed password for (\S+) from (\S+) port (\S+)</regex>
  <order>user, srcip, srcport</order>
</decoder>

Reading this decoder:

After decoding, the raw log becomes structured data:

Stage 2: Rules — Detection Logic

Once the log is decoded into structured fields, the rule engine evaluates those fields against its detection rules. If a rule's conditions match, it generates an alert.

Rule XML Structure

Here's a simplified version of the SSH brute force rule you've encountered throughout this course:

<rule id="5551" level="10" frequency="10" timeframe="120">
  <if_matched_sid>5503</if_matched_sid>
  <same_source_ip />
  <description>sshd: brute force trying to get access to the system.</description>
  <mitre>
    <id>T1110</id>
  </mitre>
  <group>authentication_failed,sshd,</group>
</rule>

Reading this rule field by field:

What This Rule Actually Says

In plain English: "If rule 5503 (single SSH failure) fires 10 times from the same source IP within a 2-minute window, generate a level 10 alert for SSH brute force (T1110)."

This is a frequency rule — it doesn't fire on a single event. It requires a pattern: multiple occurrences of a simpler rule within a time window. This is how Wazuh reduces noise — one failed login is level 5 (low). Ten failed logins from the same IP in 2 minutes is level 10 (high).

Click to enlarge

Rule Types

Wazuh has several rule types, each designed for different detection patterns:

Atomic Rules (Single Event)

The simplest type — matches a single event based on decoded fields.

<rule id="5503" level="5">
  <if_sid>5500</if_sid>
  <match>Failed password</match>
  <description>sshd: authentication failed.</description>
</rule>

This fires once for every single failed SSH password attempt. Level 5 (low) because one failure is normal — people mistype passwords.

Frequency Rules (Threshold)

Fires when an atomic rule triggers N times within a time window — like rule 5551 above.

Composite Rules (Multi-Stage)

The most advanced type — chains multiple different rules in sequence to detect multi-step attack patterns.

<rule id="100001" level="12">
  <if_sid>5551</if_sid>
  <if_fts>srcip</if_fts>
  <description>Brute force attack followed by successful login from same IP</description>
</rule>

This would fire when a brute force alert (5551) is followed by a successful login from the same IP — indicating the brute force may have succeeded.

Rule Levels: The Severity Assignment

Rule levels aren't arbitrary — they follow a hierarchy that reflects the security significance of the detected event:

How Levels Interact with Frequency

Notice the escalation pattern:

Each step up the chain increases severity because the accumulated evidence is stronger. This is the fundamental principle of detection engineering: context elevates confidence.

Rule Groups and MITRE Mapping

Groups

Groups are tags that categorize rules for filtering and searching:

<group>authentication_failed,sshd,pci_dss_10.2.4,nist_800_53_AU.14,</group>

Groups let you search broadly. Instead of memorizing dozens of individual rule IDs, you can search rule.groups:authentication_failed to find all failed auth events regardless of source (SSH, Windows, PAM, etc.).

MITRE ATT&CK Mapping

Modern Wazuh rules include ATT&CK technique IDs:

<mitre>
  <id>T1110</id>
</mitre>

This maps the rule to ATT&CK T1110 (Brute Force). In the dashboard, you'll see this in the rule.mitre field with the tactic (Credential Access) and technique name. This is what connects your SIEM alerts to the ATT&CK framework you mapped in Lab 1.2.

Rule Tuning: Reducing Noise Without Losing Signal

The most practical skill related to rules is tuning — adjusting rules to reduce false positives while preserving detection of real threats. Poor tuning is the #1 cause of alert fatigue in SOCs.

Why Rules Need Tuning

Out-of-the-box rules are designed to be broadly effective across many environments. But every environment is different:

Tuning Strategies

The Tuning Workflow

1. Identify the noisy rule from your dashboard's top rules widget (Lesson 2.3)
2. Analyze the false positives — what's triggering them? Same IP? Same user? Same schedule?
3. Design an exclusion that covers the FP pattern without blocking real attacks
4. Test the tuned rule against historical data — does it still catch the known-good alerts?
5. Deploy and monitor — track FP rate for the rule over the next week
6. Document the change — what you tuned, why, and what to watch for

Click to enlarge

Where Rules Live

Wazuh rules are stored in XML files organized by category:

The separation between built-in and local files is critical: when Wazuh updates, the built-in rules are replaced. Any changes you made to built-in files would be lost. Always put customizations in the local_ files.

Putting It Together: Following a Log Through the Pipeline

Let's trace a single event from raw log to alert to reinforce the complete pipeline:

1. Raw log arrives:

Jan 15 06:25:01 linux-web-01 sshd[5150]: Failed password for root from 185.220.101.42 port 45030 ssh2

2. Pre-decoder extracts syslog header:

• Timestamp: Jan 15 06:25:01
• Hostname: linux-web-01
• Program: sshd

3. Parent decoder (sshd) matches based on program_name.

4. Child decoder (sshd-failed) extracts fields:

• user: root
• srcip: 185.220.101.42
• srcport: 45030

5. Rule 5503 matches ("Failed password" string matched) → generates a level 5 internal event.

6. Rule 5551 checks frequency: Has rule 5503 fired 10+ times from the same source IP in the last 120 seconds?

• If yes → Alert generated: Level 10, rule 5551, "sshd: brute force trying to get access to the system."
• If no → Event logged but no brute force alert yet.

7. Alert appears in the dashboard with all decoded fields, the rule description, severity level, MITRE mapping, and the original raw log preserved in full_log.