Wazuh Rules and Decoders
A Wazuh alert is the output of a decoder (which parses a raw log into fields) and a rule (which matches those fields). Misreading the rule is the most common triage error. References below are from the stock Wazuh 4.14 ruleset.
Alert anatomy
| Field | Meaning |
|---|---|
rule.id, rule.level, rule.description | Which rule fired and how severe Wazuh considers it |
rule.groups | Categories (e.g. sshd, authentication_failed, syscheck) plus compliance tags |
rule.firedtimes | How often this rule has fired for this agent since the manager started — high counts mean recurring noise or a sustained attack |
rule.mitre.id / tactic / technique | ATT&CK mapping shipped with the rule (may be empty) |
rule.frequency | Present on correlation rules: the threshold that triggered |
agent.id / name / ip | The endpoint that produced the log (000 = the manager) |
manager.name | Which manager/cluster node processed it |
decoder.name / decoder.parent | Which decoder parsed the log (e.g. sshd, windows_eventchannel, json) |
data.* | Decoded fields: data.srcip, data.srcuser, data.dstuser, data.win.*, data.aws.* … |
syscheck.* | FIM fields (only on syscheck alerts) |
full_log | The raw log line — attacker-controllable text |
location | Source: file path, EventChannel, syscheck, rootcheck, integration name |
Level scale (0–15)
| Level | Wazuh meaning | Handling |
|---|---|---|
| 0 | Ignored / grouping rule, no alert | Never alerts; used as parents and for suppression |
| 2–4 | System notifications, low-relevance errors, successful events | Context only |
| 5–7 | User-generated errors, "bad word" matches, first-time or low-impact events | Watch for patterns |
| 8–10 | First-time-seen events, repeated errors, possible attacks | Triage |
| 11–12 | Integrity/important security events | Prioritize |
| 13–15 | High-importance events, attacks with high likelihood of success | Immediate |
The level is the rule author's generic estimate. Asset criticality, confidence and sequence (failure then success) matter more — see severity-scoring.
Atomic vs composite rules
- Atomic rules match a single event, e.g. rule 5710 (level 5, "sshd: Attempt to login using a non-existent user") and rule 5716 (level 5, "sshd: authentication failed").
- Composite / correlation rules fire on patterns of earlier matches:
if_sid— child of a parent rule (refines it, e.g. rule 60122 (level 5) is a child of rule 60105).if_matched_sid+frequency+timeframe— N matches of a rule within T seconds. For example, rule 5712 (level 10) fires when rule 5710 matches 8 times in 120 seconds withsame_source_ip; rule 5720 (level 10) does the same for rule 5716; and rule 40111 (level 10) fires on 12authentication_failedgroup matches from the same source within 160 seconds, across services.same_source_ip,same_user,different_*— scoping of the correlation.ignore— suppression window after firing (so one burst yields one composite alert).
- Consequence: a single composite alert represents many underlying events. Pull the child alerts
(
get_wazuh_alertswith the childrule_idand the sameagent_id/window) before sizing the incident.
Compliance tags
Stock rules carry compliance groups such as pci_dss_10.2.4, gdpr_IV_35.7.d, hipaa_164.312.b,
nist_800_53_AC.7, tsc_CC6.1. For example, rule 5712 carries all five families. Use them as evidence for the
compliance agent, not as severity.
MITRE mapping
rule.mitre comes from the rule XML and is a hint, not a verdict — confirm against the behaviour you
actually see (see mitre-attack-mapping). Many rules have no mapping.
Decoders
- Decoders extract fields; if a field you expect is missing, the decoder didn't parse it (different log
format, custom application) — the rule may still have matched on
full_log. - JSON-emitting sources (Windows EventChannel, cloud integrations, Suricata) use the
jsondecoder: fields keep their source names (data.win.eventdata.targetUserName,data.aws.eventName).
Custom rules and tuning
- Custom rules live in
local_rules.xml(or custom files) on the manager and must use IDs in the 100000–120000 range. Example to create: custom rule 100100 raising the level for failed logins against a crown-jewel host. - Tuning options, least to most invasive: add a child rule with
level="0"scoped to the benign pattern; raise/lower level in a child rule;overwrite="yes"on a stock rule (survives until the next ruleset upgrade — document it). - Never propose deleting a stock rule. Proposals go to detection-engineer (propose_detection) — they are never deployed automatically.
Output
When a rule's meaning matters to the conclusion, quote it in the finding: rule <id> (level <n>, "<description>", parent <id>) plus the child-event count behind any composite alert.
