Wazuh FIM not detecting file changes: the 12-hour default, measured

Wazuh FIM not detecting file changes

Usually it is detecting them, just not yet. In the default 4.14.7 configuration, file integrity monitoring scans every 12 hours (<frequency>43200</frequency>) and no directory is monitored in real time. A file you change now is reported at the next scan, up to 12 hours later. And the first scan after you add a directory only records a baseline: it raises no alerts for files that were already there.

Dong Nguyen, ATK New Technology · 2 October 2026 · measured on Wazuh 4.14.7 (manager container, Linux)

Stuck on this right now? Email your custom rules or decoders, one sample log line and your Wazuh version to dongnx@atkvn.com. We run them on that exact version and reply within 24 hours with what we find. Free. Remove hostnames, IPs and usernames first. Rather not send them? Run the free pre-check in your browser; your files never leave your machine. Rather have it fixed? USD 149 fixed price per problem, reproduced on your version, and you pay only after it works on your system. Our first three customers pay USD 49 for one fix, in exchange for an anonymised write-up we can publish.

How to check in one minute

On the host that owns the file (agent or manager), see how the directory is monitored:

grep '(6003)' /var/ossec/logs/ossec.log | tail -n 20

Each line lists a monitored path and its options. If your path is missing, it is not monitored at all. If it is there but the options do not end in realtime (or whodata), changes wait for the next scheduled scan. Then:

grep -A1 '<frequency>' /var/ossec/etc/ossec.conf
grep -E '\(600[89]\)' /var/ossec/logs/ossec.log | tail -n 4

The first shows the scan interval in seconds; the second shows when the last scans started (6008) and ended (6009).

Why it happens

The <syscheck> block in the 4.14.7 manager image's default ossec.conf:

<frequency>43200</frequency>
<scan_on_start>yes</scan_on_start>
<alert_new_files>yes</alert_new_files>
<directories>/etc,/usr/bin,/usr/sbin</directories>
<directories>/bin,/sbin,/boot</directories>

No realtime or whodata attribute on any directory. We added two test directories, one plain and one with realtime="yes", and changed files after the first scan:

What we did (Wazuh 4.14.7)	Alert
first scan after start, files already present	none (baseline only)
modified a file in the plain directory, default 12 h interval, waited 25 s	none
same, with `<frequency>60</frequency>`	550, level 7, Integrity checksum changed, mode `scheduled`, after about 64 s
modified a file in the `realtime="yes"` directory	550, level 7, mode `realtime`, within seconds
created a new file there	554, level 5, File added to the system, mode `realtime`

Fix

1. Real-time on the paths that matter. On the agent (or in the agent group's agent.conf):

<syscheck>
  <directories realtime="yes" check_all="yes">/etc/nginx,/var/www/app/config</directories>
</syscheck>

Keep real-time to the directories you would actually act on. Real-time monitoring of large or busy trees is what turns FIM into noise. The (6003) line for that path should now end in realtime, followed by (6012): Real-time file integrity monitoring started.

2. Or shorten the scan interval for everything else, knowing every scan reads every monitored file. 12 hours is the default for a reason on busy hosts.

3. Do not test right after adding a directory. Wait for the (6009) scan-ended line, then change a file. Changes before the baseline exists are not alerts.

Limits of what we measured

Measured on the Wazuh 4.14.7 manager container, with wazuh-syscheckd monitoring its own Linux filesystem; the agent uses the same module, but we did not run a separate agent. We did not measure whodata (audit-based, records who changed the file), Windows, FIM on network shares, inotify watch limits on very large directories, or how much noise real-time adds on a busy server.