socfortress/Wazuh-Rules

A community ruleset layered on top of Wazuh's own. The execution model is identical — the manager decodes an event, walks the rule tree, stops at the best match — so read the Wazuh core ruleset primer first. This page covers only what differs.

The important difference is that these rules are not self-contained as a source. Of the parent SIDs they name, 1,154 belong to Wazuh's core ruleset and only 521 to this one. Most of this content is a refinement layer over rules maintained by somebody else.

Rule IDs sit almost entirely in the 100000+ range Wazuh reserves for local rules — 2,212 of 2,223 here — which keeps them from colliding with core SIDs as upstream grows.

Content is organized by integration rather than by technique: directories for Sysmon, Office365, Crowdstrike, MISP, Auditd, AWS, Duo and a few dozen more, plus a dedicated Exclusion Rules tree of level-0 false-positive suppressions.

The Sysmon rules lean heavily on win.eventdata.* fields, and many carry ATT&CK mapping in a win.eventdata.ruleName field shaped technique_id=T1204,technique_name=User Execution — a Sysmon config convention rather than a Wazuh one. That field appears 838 times.

Because most rules here chain to SIDs defined in a different repository, this source and wazuh-core-ruleset share a resolution group: reference resolution looks across both, so a rule's condition chain can walk out of this source and into the core ruleset rather than dead-ending at the first hop.

Everything else matches the core Wazuh primer — synthesized names, $(...) placeholders left as written, and wazuh_* prefixed tags for level, role and parent SIDs.

• 53 exclusion rules here can never fire. They declare <if_group>sysmon_event_7</if_group>, but no rule in this ruleset or in Wazuh's core declares a group by that name — every rule that means it spells it sysmon_event7, without the second underscore. We do not fuzzy-match group names, so these show on their rule pages as targeting a group nothing declares. If you deployed this ruleset expecting those false-positive suppressions to work, they are not working.
• This is community content with no release cadence guarantee. Check the upstream repo before treating a rule as maintained.