Wazuh Core Ruleset

Wazuh does not run queries against a log store. The manager decodes each incoming event, then walks its rule tree and stops at the best match. A rule is a small XML block that tests decoded fields, and rules are explicitly ordered relative to each other rather than evaluated independently.

That difference drives everything else on this page. In Sigma or Elastic a rule is self-contained and you can read it in isolation. Here, most rules are a refinement of another rule: 3,777 of the 4,423 rules in this ruleset declare if_sid, so reading one alone usually tells you very little.

Each rule has a numeric SID and a level from 0 to 15. Chaining is declared with four elements:

• if_sid — only evaluate when the named parent rule has already matched.
• if_group — only evaluate when a rule carrying the named group matched.
• if_matched_sid / if_matched_group — fire only when the referenced rule matched repeatedly. The window comes from frequency and timeframe attributes on the rule itself, and elements like <same_source_ip/> set what the repetitions have to share. This is Wazuh's correlation.

A rule declaring none of these is an entry point, matched directly against decoded events, usually paired with decoded_as to name the decoder that produced the fields.

Level is not severity in the sense the rest of this site uses. Level 0 means "matched, do not alert" — the standard way to suppress a known-benign case without deleting the parent rule, and 635 rules here are level 0. Alerting starts at the manager's threshold, conventionally level 3.

So a level-0 rule with a frightening name is usually the opposite of a threat: it is somebody turning one off, or declaring a grouping anchor for children to hang from. Rule 500 is exactly that — level 0, no parent, and the root that most OSSEC-decoded rules chain to.

Wazuh rules have no title field, so the name shown here is synthesized from the rule's <description>. Descriptions frequently contain $(...) tokens — $(win.eventdata.image), $(osquery.pack) — which the manager expands from the decoded event at alert time. We render the token as written rather than inventing a value, and append a distinguisher so sibling rules do not collapse into identical names.

Chaining is surfaced two ways: the condition chain walks a rule's if_sid ancestry up to its entry point, and the dependents panel lists rules naming it. Attributes with no home in the shared schema are kept as prefixed tags — wazuh_level:, wazuh_role:, wazuh_parent_sid:, wazuh_matched_sid:.

ATT&CK comes from the rule's <mitre> block. The <group> element is mostly compliance mapping (PCI DSS, GDPR, HIPAA, NIST 800-53), not detection logic.

• A high-level rule that also declares if_sid cannot fire on its own. The parent has to match first.
• Group names are matched literally, with no fuzzy matching. A rule pointing at a group no indexed rule declares will never fire, and we flag that on the rule's page.
• Level 0 rules are indexed and searchable, but they are suppressions and anchors. Read the chain before counting one as coverage.