Child decoder for syscheck

5 views
Skip to first unread message

CRIZ

unread,
Aug 11, 2026, 10:44:11 AM (20 hours ago) Aug 11
to Wazuh | Mailing List

Hello Wazuh Community,

I would like to know whether it is possible to create a child decoder for the syscheck_integrity_changed event.

Our requirement is to further decode or extract extension of a file from syscheck_integrity_changed.  Could you please confirm if child decoders are supported for this type of event and, if so, provide guidance or an example configuration?

I am also confused of rule testing for syscheck events, with the full log can we test via rule test in GUI?

Any recommendations or documentation on the appropriate approach would be greatly appreciated.

Thank you for your assistance.

Best regards,
CRIZ

Olamilekan Abdullateef Ajani

unread,
Aug 11, 2026, 11:18:32 AM (20 hours ago) Aug 11
to Wazuh | Mailing List
Hi CRIZ,

Currently, you cannot create a child decoder under syscheck_integrity_changed.

That decoder is different from the normal XML decoders. FIM uses an internal decoder implemented directly in analysisd, the source describes DecodeSyscheck() as a special decoder that does not use the normal decoding library.
For your requirement, I believe it is best to handle the extension in the rule instead. The FIM documentation specifically supports matching the decoded file field this way.
Ref: https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/creating-custom-fim-rules.html


<group name="syscheck,">
  <rule id="100010" level="7">
    <if_sid>550</if_sid>
    <field name="file" type="pcre2">(?i)\.(exe|dll|ps1|bat|vbs)$</field>
    <description>FIM: monitored file extension detected - $(file)</description>
  </rule>
</group>


Rule 550 is for modified files. The same idea can be applied to added or deleted FIM events using their corresponding parent rules.

Regarding wazuh-logtest, the safest option to avoid partial matching is to monitor a test directory with FIM, create/modify/delete a test file, and check the actual generated alert.

The upcoming Wazuh 5 changes this quite a bit. FIM is handled by the new normalization engine and there is now an actual standard FIM decoder called decoder/wazuh-fim/0. Decoders are YAML-based and can explicitly inherit from other decoders using parents.

Wazuh 5 also has a Draft > Test >> Custom workflow and a Log Test tool designed to test the normalization and detection pipeline together, so this area is much better than the curent approach.

Please let me know if you require further clarification on this.

Regards
Reply all
Reply to author
Forward
0 new messages