File Integrity Monitoring Tools: What to Look For

What is file integrity monitoring?

File integrity monitoring watches selected files and directories and reports when they are created, modified, deleted or renamed, or when their permissions change. It does this by recording a baseline, usually including a cryptographic hash of each file, and comparing the current state against it.

Attackers and malware almost always change files: they drop web shells, add SSH keys, edit startup scripts, install services or replace binaries. Administrators change files too, which is why FIM is as much about context as about detection. A good FIM tool tells you not only that /etc/sudoers changed, but who changed it, through which process and what the difference is, so you can tell a planned change from an intrusion.

Because FIM compares against a baseline, the baseline itself has to be trustworthy. Create it from a known-good state, for example right after a build or a reviewed deployment, and protect it from tampering.

Where FIM is required

PCI DSS v4.0 requirement 11.5.2 calls for a change-detection mechanism, such as file integrity monitoring, that alerts personnel to unauthorized modification of critical files and performs critical file comparisons at least once a week. Requirement 10.3.4 applies the same idea to audit logs, so that existing log data cannot be changed without generating an alert.

Other frameworks are less prescriptive but point the same way. ISO/IEC 27001 includes controls for configuration management, change management and monitoring, and FIM records are a straightforward way to show that changes to critical systems are detected and reviewed.

What capabilities must a FIM tool have?

A FIM tool should detect every type of change on the paths you care about, prove what changed with hashes and diffs, attribute each change to a user and process, and alert with a priority that reflects how critical the file is. Coverage of both Linux and Windows and integration with your SIEM come close behind.

Pay close attention to noise. A FIM tool that alerts on every log rotation or package cache update will be muted within a week. Look for exclusions, ways to acknowledge or suppress expected changes, and a way to tie changes to approved change windows.

Also ask how detection works. Some tools react to file system events as they happen; others scan on a schedule and compare against the baseline. Event-based monitoring gives faster alerts, while scheduled scans also catch changes made while monitoring was not running. Many tools combine the two.

How does FIM work on Linux?

On Linux, FIM tools typically combine kernel file event interfaces such as inotify or fanotify, the Linux audit subsystem for user and process attribution, and periodic hashing to verify file content against the baseline. The tool keeps a stored baseline of hashes, permissions and ownership for every monitored file.

Each mechanism has trade-offs. inotify reports file events efficiently, but it is not recursive, so every subdirectory needs its own watch, and it provides no information about the user or process that caused an event. The newer fanotify interface reports the ID of the process behind each event and can watch whole mounts or file systems, which is why some security tools prefer it. The Linux audit system records the user and process behind a write through watch rules like the ones below, at the cost of more log volume.

# /etc/audit/rules.d/fim.rules (w = write, a = attribute change)
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

Paths most worth monitoring on Linux servers include:

• /etc/passwd, /etc/shadow, /etc/group and /etc/sudoers (accounts and privileges).
• /etc/ssh/sshd_config and users' ~/.ssh/authorized_keys files (T1098.004).
• /etc/crontab, /etc/cron.d/ and systemd unit directories, common persistence locations (T1053.003).
• /etc/ld.so.preload and system binary directories such as /usr/bin and /usr/sbin.
• Web roots such as /var/www/html/ and application configuration under /etc or /opt.

Avoid monitoring high-churn paths such as /var/log, /tmp or package caches for content changes. Either exclude them or watch only specific files inside them, for example to detect log files being deleted or truncated.

How does FIM work on Windows?

On Windows, FIM tools use file system change notifications or a file system filter driver for change events, Windows object access auditing to attribute changes to accounts and processes, and hashing to verify content. Many also monitor the registry, because much Windows persistence lives there rather than in files.

Native Windows auditing can attribute file changes, but only where you configure it. With the Audit File System policy enabled and a system access control list (SACL) on the folder, Windows writes event 4663 ("An attempt was made to access an object") with the account name, process name and access rights used. Sysmon adds file events such as FileCreate (event ID 11) and file deletion (IDs 23 and 26). These are useful inputs for a SIEM, while a dedicated FIM agent adds baselines, hashes and diffs. Sysmon's registry events (IDs 12 to 14) help close the gap that file-only monitoring leaves for registry-based persistence.

Locations worth monitoring on Windows hosts include:

• The hosts file in C:\Windows\System32\drivers\etc, a target for name resolution tampering.
• Startup folders and the Run registry keys (T1547.001).
• Binaries and DLLs under C:\Windows\System32 and C:\Program Files.
• Scheduled task definitions under C:\Windows\System32\Tasks.
• IIS web roots such as C:\inetpub\wwwroot and application configuration files.

As on Linux, exclude temp folders, browser caches and update staging areas, or limit monitoring there to the creation of executable and script files.

How does FIM help detect web shells and ransomware?

FIM catches web shells by alerting on new or modified script files in web directories, and it flags ransomware by detecting abnormal numbers of modifications, renames and deletions in a short time. In both cases, the file change itself is one of the earliest reliable signals on the host.

Web shells

A web shell is a script placed on a web server that gives an attacker remote access. It has to reach the disk, usually as a .php, .jsp, .aspx or similar file inside the web root, or as code injected into an existing file. Monitoring web roots for new script files, changes to existing ones and writes by the web server's own account (such as www-data or an IIS application pool identity) catches the typical cases. Legitimate deployments should come from a known deployment user or process, which makes the difference easy to see. Web shells can be very small and hidden inside legitimate files, so comparing hashes of existing files matters as much as alerting on new ones.

Ransomware

Ransomware encrypts data to extort payment (T1486), which shows up as a burst of file modifications, renames to unfamiliar extensions and deletions across many directories, often from a single process. Alerting on change rates rather than single events, and watching a few canary files in shared folders, gives early warning. Attackers often delete backups and shadow copies first (T1490), so pair FIM with process and command-line logging.

Why use FIM and SIEM together?

FIM tells you that a file changed; a SIEM tells you what else happened around it. Sending FIM events to the SIEM lets you correlate a configuration change with the login, process and network activity that led to it, and keeps all the evidence in one place.

Correlation turns ambiguous changes into clear decisions. An edited sshd_config during a change window, made by a known administrator, is routine. The same change made minutes after a run of failed logins and a successful one from an unusual location is an incident. Neither the FIM tool nor the authentication log can tell those apart alone. Read more about correlation in What is SIEM?.

Logchase file integrity monitoring is built this way: Linux and Windows agents report file creation, modification, deletion and renames, permission and ownership changes, SHA-256 hash comparisons, diffs, and user and process context, with path and filename pattern rules and severity-based alerts.

Keep FIM evidence as long as your other security logs. A change is often investigated long after it happened, when an incident is finally discovered; our log retention guide covers how to set retention periods.