I went back to the file added to the system alert in the Cabana UI.
Right now,
this alert fires whenever a file is added to one of the monitored file paths.
But how do we know this?
Let's search for the rule that fired this alert.
First off, we get the rule ID.
Then we search the Wazuh ruleset on GitHub for that ID.
Basically,
all you need to do is enter 554 into the search field when
you're within the Wazuh ruleset repo.
Okay, it looks like we got a match.
Let's check this out.
All rules need to be triggered by some event.
In this case, pay particular attention to the decoded_as field.
All events that come into Wazuh go through a decoder that classifies the event.
As far as what values can exist in this field,
I suggest you go through the decoder files in course notes number 9.
However, Wazuh defines certain decoders internally that aren't seen in this link.
My suggestion is to go through the ruleset repo and
look for different decoded_as values.
The values are pretty self‑descriptive.
In this example,
syscheck_new_entry corresponds to the new files that are observed by _____.
To note, this rule won't trigger when an existing file is changed or deleted.
For that, let's do a little more searching.
Above, we see rule 553 sysheck_deleted, or in other words, a file is deleted.
And further, in 550 above that,
we see syscheck_integrity_changed or Integrity checksum changed.
As we're seeing, multiple rules can correlate to a file operation.
To keep things simple, Wazuh classifies rules into groups.
Further, we notice that all of the rules are within the syscheck rule group.
Let's keep this in mind for the rule we're about to create.