Wazuh File Integrity Monitoring (FIM) Guide

What FIM Actually Detects, and Why It Matters

File Integrity Monitoring watches a defined set of files and directories and alerts when their content, attributes, ownership or permissions change. In Wazuh this is the syscheck module. It computes a baseline of cryptographic hashes (MD5, SHA1, SHA256) plus metadata (size, owner, group, permissions, modification time) and then reports any deviation from that baseline.

The detection value is concrete. Attackers who gain a foothold modify system binaries to plant backdoors, edit configuration files to weaken security, drop web shells into web roots, and tamper with scheduled tasks for persistence. Each of those actions changes a file. FIM is often the control that catches an intrusion that evaded every preventive layer, because the attacker eventually has to write to disk.

FIM is also the control most frequently demanded by auditors. PCI DSS, ISO 27001, HIPAA and SOC 2 all expect change-detection on critical files. The difference between a passing and failing assessment is frequently whether your FIM is monitoring the right paths, attributing changes to users, and producing reports the assessor can read.

It helps to think of FIM as the last line of detection rather than the first. Preventive controls (access management, patching, hardening) aim to stop the attacker before they reach disk, and behavioural rules try to catch them in the act. But a determined attacker who slips past those layers must, sooner or later, write something to the filesystem to persist or to act. FIM watches that final, unavoidable step, which is exactly why it so often produces the alert that exposes an intrusion the earlier layers missed.

Configuring syscheck: Directories, Frequency and Tuning

Syscheck is configured in the <syscheck> block of ossec.conf (or, better, in a centralised agent group configuration). You declare which directories to watch with <directories>, and you control behaviour per directory with attributes like check_all, report_changes and realtime.

Sensible defaults for Linux include /etc, /bin, /sbin, /usr/bin, /usr/sbin and your web roots. On Windows the equivalents are C:\Windows\System32, C:\Program Files and application install directories. The frequency setting controls how often the full scheduled scan runs; a common value is every 12 hours, supplemented by real-time monitoring on the highest-value paths.

Tuning matters as much here as in alert rules. Directories that change constantly by design (log directories, temp folders, package caches) generate FIM noise and should be excluded with <ignore> entries or restricted with <nodiff> so their content is not stored in alerts. The art is monitoring everything an attacker would touch while excluding everything that changes legitimately every minute.

Real-Time FIM versus Scheduled Scanning

By default syscheck runs scheduled scans on the configured frequency. The weakness is latency: a file changed just after a scan is not detected until the next scan, potentially hours later. For high-value paths that delay is unacceptable, because an attacker can plant and remove a web shell inside one scan window.

Real-time monitoring closes that gap. Adding realtime="yes" to a directory tells Wazuh to watch it continuously. On Linux this uses the kernel's inotify subsystem; on Windows it uses ReadDirectoryChangesW. Either way, a change to a watched file generates an alert within seconds rather than at the next scheduled scan.

Real-time monitoring does consume a watch descriptor per monitored file, so on Linux you may need to raise fs.inotify.max_user_watches for large trees. The practical pattern is real-time on the critical, lower-volume paths (web roots, system binaries, key configs) and scheduled scanning for broader, slower-changing trees. This balances immediacy against resource cost.

Who-Data: Attributing Every Change to a User and Process

Knowing that /etc/passwd changed is useful. Knowing which user, running which process, with which parent process, made that change at that exact second is what turns a FIM alert into an actionable investigation. That attribution is what Wazuh calls who-data.

Enabling whodata="yes" on a directory makes Wazuh integrate with the operating system's native audit facility. On Linux it hooks into the Linux Audit subsystem (auditd) to capture the user, group, process, and syscall behind each change. On Windows it leverages System Access Control Lists (SACLs) and the Security event log to capture the same attribution.

Who-data transforms incident response. Instead of seeing that a binary changed and then spending an hour correlating across logs to find the responsible process, the FIM alert itself carries the answer: user, effective user, process name, process id and parent process. For PCI and forensic work this is the difference between 'something changed' and 'this account, via this process, made this change'. Who-data implies real-time monitoring, so enabling it also gives you immediate detection.

Windows Registry Monitoring

On Windows, an enormous amount of security-relevant state lives in the registry rather than in files. Persistence mechanisms (Run keys, services, scheduled-task definitions), security configuration, and many forms of tampering all manifest as registry changes that pure file monitoring never sees.

Wazuh syscheck monitors the registry through the <windows_registry> directive. You declare the keys to watch (for example HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run and the Services hive), and Wazuh baselines and reports changes to keys and values exactly as it does for files. Real-time registry monitoring and who-data style attribution apply here too.

Practical high-value registry targets include the autorun keys (a classic persistence location), the Services configuration, security policy keys, and application-specific keys that control authentication or encryption behaviour. Monitoring these catches a category of attacker activity that is invisible to file-only FIM, and it is frequently the detection that exposes how an attacker survived a reboot.

As with file paths, registry monitoring needs tuning to stay useful. Some keys are written constantly by legitimate software and will flood you with noise if watched naively, so scope monitoring to the keys that carry security meaning rather than the entire hive. Done with that discipline, registry FIM becomes one of the highest signal-to-noise detections available on Windows, because the keys that matter for persistence and security configuration change rarely under normal operation, which means almost any change to them is worth an analyst's attention.

FIM as PCI DSS Requirement 11.5 Evidence

PCI DSS Requirement 11.5 mandates the deployment of a change-detection mechanism (such as file integrity monitoring) to alert personnel to unauthorised modification of critical files, and to perform critical file comparisons at least weekly. Wazuh FIM is a direct, assessor-recognised way to meet this requirement.

To produce clean evidence, configure syscheck to monitor the files PCI cares about (system binaries, configuration files, and the content of in-scope payment application directories), enable who-data so each change is attributed, and ensure alerts flow to the Wazuh indexer where they are retained for the audit window. The scheduled scan satisfies the weekly comparison requirement; real-time monitoring exceeds it.

When the assessor arrives, you demonstrate three things: the monitored-path configuration showing critical files are covered, the alert stream showing changes were detected and attributed, and the report templates showing the SOC reviewed and dispositioned those alerts. Codesecure includes FIM configuration and PCI-aligned report templates in every managed SOC engagement, and beyond PCI the same configuration supports ISO 27001 Annex A.8.16 and HIPAA audit-control expectations.