Wazuh FIM Investigation
Wazuh FIM (syscheck) alerts on changes to monitored files and Windows registry entries. The question is always: expected change (patching, config management) or tampering/persistence?
Core syscheck rules (stock ruleset)
| Event | Files | Windows registry key | Windows registry value |
|---|---|---|---|
| Modified | rule 550 (level 7) | rule 594 (level 5) | rule 750 (level 5) |
| Deleted | rule 553 (level 7) | rule 597 (level 5) | rule 751 (level 5) |
| Added | rule 554 (level 5) | rule 598 (level 5) | rule 752 (level 5) |
Groups: syscheck, plus syscheck_entry_modified / syscheck_entry_deleted / syscheck_entry_added
and syscheck_file / syscheck_registry. Query by group:
get_wazuh_alerts rule_groups=["syscheck"] agent_id="<id>" timestamp_start="now-24h".
FIM health signals (monitoring gaps, not attacks): rule 560 (level 7, "FIM real-time queue is full") and rule 233 (level 12, "The maximum limit of files monitored has been reached") mean changes may have been missed — record it and hand off to platform-engineer.
Key fields
| Field | Use |
|---|---|
syscheck.path | What changed |
syscheck.event | added / modified / deleted |
syscheck.mode | realtime, whodata or scheduled — scheduled scans only tell you the change happened since the last scan |
syscheck.md5_before/after, sha1_*, sha256_* | Content change; hashes go to threat-intel for reputation |
syscheck.size_before/after | Truncation, appended payloads |
syscheck.perm_before/after, uname_*, gname_*, uid_* | Permission / ownership changes (e.g. SUID, world-writable) |
syscheck.changed_attributes | Which attributes changed |
syscheck.diff | Text diff (only when report_changes is enabled for the path) |
syscheck.audit.user.name, .audit.effective_user.name, .audit.process.name, .audit.process.id, .audit.process.ppid | Who-data: which user and process made the change (Linux auditd / Windows SACL) |
If syscheck.audit.* is absent the path isn't in who-data mode — you know what changed, not who.
Say so rather than guessing.
High-value paths
| Linux | Why |
|---|---|
/etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/* | Account creation, privilege (T1136, T1548) |
/root/.ssh/authorized_keys, ~/.ssh/authorized_keys | Persistence via keys (T1098.004) |
/etc/crontab, /etc/cron.*, /var/spool/cron/* | Scheduled persistence (T1053.003) |
/etc/systemd/system/*, /lib/systemd/system/*, /etc/init.d/* | Service persistence (T1543.002) |
/etc/ld.so.preload, /etc/profile.d/*, ~/.bashrc | Hijacking / shell persistence |
Web roots (/var/www/*) | Web shells (T1505.003) |
Binaries in /bin, /usr/bin, /usr/sbin | Trojaned tools |
| Windows | Why |
|---|---|
HKLM\...\CurrentVersion\Run, RunOnce, HKCU equivalents | Logon persistence (T1547.001) |
HKLM\SYSTEM\CurrentControlSet\Services\* | Service creation/modification (T1543.003) |
| Startup folders | Persistence |
C:\Windows\System32\drivers\etc\hosts | Traffic redirection |
C:\Windows\System32\* executables | Binary replacement |
Procedure
- Scope: pull all syscheck alerts for the agent in the window; list changed paths.
- Baseline the change: check for package activity in the same window — rule 2902 (level 7, "New dpkg (Debian Package) installed"), rule 2903 (dpkg removed), rule 2932 (level 7, "New Yum package installed"), rule 2933 (Yum package updated). A binary modified minutes after a matching package update is probably routine; the same change with no package activity is suspicious.
- Correlate with account events: rule 5902 (level 8, "New user added to the system"), rule 5901 (level 8, "New group added to the system"), rule 5904 (level 8, "Information from the user was changed"), rule 2833 (level 8, "Root's crontab entry changed").
- Who did it: use who-data if present; otherwise look for logins/sudo on the agent around the change (e.g. rule 5402 (level 3, "Successful sudo to ROOT executed")).
- Process context: if a process is implicated, hand off to investigation (it holds
get_agent_processes/get_agent_ports) unless you are investigation. - Hashes: send
sha256_afterof new/modified executables to threat-intel for reputation. - Deletions: bulk rule 553 on data directories plus new files with unusual extensions is a ransomware pattern — escalate immediately (see ir-playbook-ransomware).
Noise
Log rotation, package managers, configuration management (Ansible/Puppet/Chef runs at fixed times), antivirus definition updates, and editors creating temp files. Suggest a scoped level-0 child rule via detection-engineer rather than disabling FIM on a path.
Output
add_entities: file paths (typefile), hashes (typehash), user and process from who-data.link_mitrefor the persistence/tampering technique you can support with evidence.add_finding: what changed, when, who (or "who-data not enabled"), routine-vs-suspicious verdict with the evidence (package event present/absent), and standard refs such asMITRE-ATTACK:T1547.001,PCI-DSS-4:11.5,CIS-v8.1:3.
