How to Configure File Integrity Monitoring (FIM) in Wazuh

File Integrity Monitoring (FIM) is one of the most important security controls for detecting unauthorized changes across servers, workstations, and critical infrastructure.

Whether the changes originate from a malicious attacker, malware infection, insider threat, or accidental configuration drift, monitoring file integrity helps security teams identify suspicious activity before it leads to a major incident.

Organizations today face a growing number of cyber threats that target critical system files, application configurations, registry settings, and sensitive business data.

Attackers frequently modify files to establish persistence, hide malicious code, escalate privileges, or disable security controls.

Without a file integrity monitoring solution in place, these changes can go unnoticed for weeks or even months.

This is where Wazuh’s File Integrity Monitoring (FIM) capability becomes valuable.

Built into the Wazuh platform, FIM continuously monitors files, directories, registry entries, and system configurations for unauthorized changes.

When modifications occur, Wazuh generates detailed alerts that allow security teams to investigate and respond quickly.

FIM is also a key requirement for many security frameworks and regulatory standards, including PCI DSS, HIPAA, NIST, ISO 27001, and CIS Controls.

Implementing effective file integrity monitoring helps organizations strengthen their security posture while supporting compliance initiatives.

Wazuh implements file integrity monitoring through its Syscheck module, which tracks file creation, modification, deletion, ownership changes, permission changes, and integrity violations using cryptographic hashes and real-time monitoring techniques.

The solution works across Windows, Linux, and macOS environments, making it suitable for organizations with diverse infrastructure.

Use Cases For Wazuh FIM

Common use cases for Wazuh FIM include:

• Detecting unauthorized modifications to system files
• Monitoring web server directories for website defacement
• Identifying ransomware activity through mass file changes
• Tracking configuration drift across servers
• Monitoring sensitive application files
• Supporting regulatory compliance audits
• Detecting insider threats and unauthorized administrator actions

According to the PCI Security Standards Council, organizations should deploy file integrity monitoring mechanisms to alert personnel to unauthorized modification of critical files and system configurations.

This makes FIM a foundational component of many modern cybersecurity programs.

What We Will Cover

Throughout this guide, we’ve covered the complete Wazuh File Integrity Monitoring setup process, including:

• Understanding Syscheck architecture
• Configuring monitored directories
• Enabling real-time monitoring
• Creating scheduled integrity scans
• Monitoring permissions and ownership changes
• Reducing false positives
• Building custom detection rules
• Troubleshooting common issues
• Optimizing performance

In this guide, you’ll learn how to configure File Integrity Monitoring in Wazuh, enable real-time monitoring, customize Syscheck rules, monitor critical directories, reduce false positives, and validate that your FIM deployment is working correctly.

If you’re new to the Wazuh platform, you may also want to read our  How to Install a Wazuh Agent on Windows Server before configuring file integrity monitoring on Windows systems.

What Is File Integrity Monitoring in Wazuh?

Understanding FIM

File Integrity Monitoring (FIM) is a security process that continuously monitors files, directories, registry keys, and system configurations for unauthorized changes.

The primary goal is to identify modifications that could indicate malicious activity, policy violations, configuration drift, or operational errors.

Instead of relying solely on malware signatures or network-based detection, FIM focuses on the integrity of critical assets.

By maintaining a trusted baseline and comparing current file states against that baseline, security teams can quickly identify unexpected changes.

Detecting Unauthorized File Changes

Attackers frequently modify existing files to maintain persistence, disable security controls, or conceal their activities.

Wazuh FIM detects these changes by comparing current file attributes and cryptographic hashes against previously recorded values.

Examples include:

• Changes to system configuration files
• Modification of web application code
• Tampering with security tools
• Unauthorized updates to scheduled tasks
• Changes to registry settings on Windows

When a monitored file changes, Wazuh immediately records the event and generates an alert for further investigation.

Monitoring File Creation, Deletion, and Modification

Wazuh monitors several types of file system activity:

• New file creation
• Existing file modifications
• File deletions
• File renaming events
• Directory changes

This visibility helps security teams identify suspicious activity patterns such as malware dropping payloads, attackers deleting evidence, or unauthorized users modifying critical configurations.

Tracking File Permissions and Ownership Changes

In addition to content modifications, Wazuh can monitor:

• File ownership changes
• Group ownership changes
• Permission modifications
• Access control changes

These events are often indicators of privilege escalation attempts or unauthorized administrative activity.

Monitoring permissions is particularly important for Linux and Unix-based systems where attackers commonly alter file permissions to gain persistence.

How Wazuh FIM Works

Wazuh provides File Integrity Monitoring through a component called Syscheck, which runs on monitored endpoints and reports file changes back to the Wazuh Manager.

Introduction to Syscheck

Syscheck is the Wazuh module responsible for:

• Monitoring files and directories
• Calculating file hashes
• Tracking metadata changes
• Performing periodic integrity scans
• Generating security alerts

Syscheck maintains a database of monitored files and continuously compares current file states against previously recorded baselines.

 Wazuh Syscheck Documentation — https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/

Real-Time Monitoring vs Scheduled Scans

Wazuh supports two primary monitoring methods.

Real-Time Monitoring

Real-time monitoring uses operating system event notifications to detect changes immediately after they occur.

Benefits include:

• Near-instant alert generation
• Faster incident response
• Reduced attacker dwell time
• Better visibility into active threats

Scheduled Scans

Scheduled scans periodically evaluate monitored files and compare them against stored baselines.

Benefits include:

• Lower resource consumption
• Detection of missed events
• Validation of integrity databases
• Suitable for large file repositories

Many organizations use both approaches simultaneously for maximum coverage.

File Hashing and Integrity Verification

To verify file integrity, Wazuh calculates cryptographic hashes such as:

• MD5
• SHA1
• SHA256

When a monitored file changes, Wazuh recalculates the hash and compares it against the previously stored value.

If the hash differs, Wazuh records:

• Previous hash value
• New hash value
• File path
• Timestamp
• User information (when available)

Hash-based verification makes it difficult for attackers to alter files without generating detectable evidence.

The importance of cryptographic integrity validation is also highlighted by guidance from the National Institute of Standards and Technology (NIST), which recommends integrity monitoring as part of effective system security monitoring programs.

Alert Generation Process

The Wazuh FIM workflow typically follows these steps:

1. Syscheck establishes a baseline.
2. A file event occurs.
3. The file is rescanned.
4. Metadata and hashes are compared.
5. Wazuh evaluates the event against detection rules.
6. An alert is generated.
7. Security analysts investigate the event.

For advanced environments, these alerts can be correlated with custom detection logic.

If you want to build more sophisticated detections, see our  How to Create Custom Detection Rules in Wazuh (With Examples).

Benefits of Wazuh File Integrity Monitoring

Threat Detection

FIM helps detect:

• Web shell deployments
• Persistence mechanisms
• Rootkit activity
• Unauthorized software installation
• Configuration tampering

Many post-compromise activities involve file system changes, making FIM an effective early-warning mechanism.

Compliance Support

Numerous security standards require integrity monitoring controls, including:

• PCI DSS
• HIPAA
• ISO 27001
• NIST 800-53
• CIS Controls

Wazuh’s reporting and alerting capabilities help organizations demonstrate compliance during audits.

Insider Threat Monitoring

Not all threats originate externally. Authorized users may intentionally or accidentally modify sensitive files.

Wazuh provides visibility into:

• Unauthorized administrator actions
• Changes to critical business documents
• Policy violations
• Configuration drift caused by internal users

This additional layer of monitoring helps security teams identify risky behavior before it becomes a larger problem.

Malware and Ransomware Detection

Modern ransomware operations often generate thousands of file modifications within a short period.

Wazuh FIM can help identify:

• Rapid file encryption activity
• Unauthorized executable deployment
• Malicious script modifications
• Suspicious changes to backup configurations

When combined with other Wazuh capabilities such as endpoint monitoring and log analysis, FIM becomes an important component of a layered defense strategy.

For a broader comparison of Wazuh’s security monitoring capabilities against other platforms, see our Wazuh vs OSSEC and Security Onion vs Wazuh.

How Wazuh FIM Architecture Works

Understanding the architecture behind Wazuh File Integrity Monitoring (FIM) helps you troubleshoot issues, optimize performance, and configure monitoring more effectively.

Wazuh’s FIM capability is built around communication between the Wazuh Agent, the Wazuh Manager, and the Syscheck module.

When a monitored file changes, the agent detects the modification, collects relevant metadata, and forwards the information to the manager for analysis.

The manager then evaluates the event against detection rules and generates alerts when necessary.

Wazuh Agent Responsibilities

The Wazuh agent performs most of the file monitoring activities on the endpoint itself.

This design minimizes network traffic while providing detailed visibility into file system activity.

Collecting File Change Information

The agent continuously monitors configured files and directories for events such as:

• File creation
• File deletion
• File modification
• File renaming
• Permission changes
• Ownership changes

Depending on your configuration, monitoring can occur through real-time operating system notifications or periodic scheduled scans.

For Linux systems, Wazuh typically leverages inotify, while Windows agents use native file system monitoring APIs to detect changes efficiently.

Computing Checksums

Whenever a monitored file changes, Syscheck calculates one or more cryptographic hashes to verify integrity.

Common hash algorithms include:

• MD5
• SHA1
• SHA256

These hashes allow Wazuh to determine whether the contents of a file have changed, even if the modification is not immediately visible.

For example, if an attacker injects malicious code into a web application file, the resulting hash will differ from the original baseline, triggering an integrity alert.

Sending Events to the Manager

After collecting file information and calculating checksums, the agent sends event data to the Wazuh Manager.

A typical event may contain:

• File path
• Event type
• Timestamp
• File size
• Ownership information
• Previous hash value
• Current hash value
• Permissions metadata

This information provides security analysts with the context needed to investigate suspicious changes.

Wazuh Manager Responsibilities

Once the manager receives Syscheck events, it performs centralized analysis and alert processing.

Event Analysis

The Wazuh Manager parses incoming Syscheck events and extracts relevant information for evaluation.

The manager determines:

• What changed
• Where the change occurred
• Whether the change is expected
• The severity of the event

This centralized approach allows organizations to monitor hundreds or thousands of endpoints from a single location.

Rule Matching

After analysis, events are compared against Wazuh detection rules.

Rules can identify:

• Sensitive file modifications
• Changes in critical directories
• Unauthorized permission changes
• Creation of suspicious files
• Compliance-related violations

Organizations can also create custom detection logic to tailor monitoring to their environment.

For advanced alert customization, see our How to Create Custom Detection Rules in Wazuh (With Examples).

Alert Generation

When a rule is triggered, Wazuh generates an alert containing detailed information about the event.

Alert data typically includes:

• Rule ID
• Severity level
• File path
• Description
• User information
• Hash values
• Timestamp

Security teams can use these alerts for incident response, threat hunting, and compliance reporting.

Dashboard Visualization

Alerts appear in the Wazuh Dashboard, where analysts can:

• Search FIM events
• Build visualizations
• Create dashboards
• Investigate file changes
• Correlate events with other security data

This centralized visibility makes it easier to identify patterns that may indicate compromise.

Syscheck Components Explained

Firstly, Syscheck is the core Wazuh component responsible for file integrity monitoring.

Syscheck Daemon

The Syscheck daemon runs on monitored endpoints and performs:

• File scans
• Integrity validation
• Metadata collection
• Real-time event monitoring
• Baseline comparisons

The daemon operates continuously and sends findings back to the manager whenever changes are detected.

Monitoring Database

Syscheck maintains a local database containing information about monitored files.

This database stores:

• File paths
• Hash values
• File attributes
• Ownership information
• Permissions data

During subsequent scans, Syscheck compares current file states against this baseline to identify changes.

Integrity Checks

Integrity checks are the foundation of FIM.

For each monitored file, Syscheck evaluates:

• File content changes
• Size changes
• Permission changes
• Ownership changes
• Timestamp changes

Any deviation from the baseline can trigger an event, depending on the configured monitoring options.

According to guidance from the Center for Internet Security (CIS Controls), organizations should actively monitor critical assets for unauthorized modifications to strengthen detection and response capabilities.

Prerequisites

Before configuring File Integrity Monitoring in Wazuh, ensure that your environment is properly configured and that all required components are functioning correctly.

Taking a few minutes to verify these prerequisites can prevent many of the issues administrators encounter during deployment.

Before You Begin

Working Wazuh Deployment

You should already have a functioning Wazuh environment consisting of:

• Wazuh Manager
• Wazuh Agent(s)
• Wazuh Dashboard
• Indexer (if applicable)

If your environment is not yet operational, complete the installation and connectivity validation process before continuing.

Access to the Wazuh Manager

You will need administrative access to the Wazuh Manager server to:

• Review alerts
• Modify configurations
• Restart services
• Validate agent communication

Installed Wazuh Agent

File Integrity Monitoring operates through the Wazuh Agent.

Ensure the agent is installed on every endpoint you intend to monitor.

If you have not deployed agents yet, see our  How to Install a Wazuh Agent on Windows Server.

Administrative Privileges

You will need elevated permissions to:

• Modify ossec.conf
• Restart services
• Access protected directories
• Configure monitoring settings

On Linux, root or sudo access is typically required.

On Windows, use an Administrator PowerShell session.

Verify Your Environment

Before configuring Syscheck, confirm that both the manager and agent services are running properly.

Verify the Agent Status

Linux:

systemctl status wazuh-agent

Expected output should indicate:

active (running)

Verify the Manager Status

On the Wazuh Manager server:

systemctl status wazuh-manager

Expected output:

active (running)

If either service is stopped or failing, resolve those issues before proceeding.

If your agent cannot communicate with the manager, review our troubleshooting guide:

Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work

Understanding the Syscheck Configuration File

All File Integrity Monitoring settings are configured within the Wazuh configuration file.

Location of Syscheck Settings

Linux

/var/ossec/etc/ossec.conf

Windows

C:\Program Files (x86)\ossec-agent\ossec.conf

The <syscheck> section of this file controls how File Integrity Monitoring behaves.

Key Syscheck Configuration Elements

The following directives are commonly used when configuring Wazuh FIM.

<syscheck>

Defines the File Integrity Monitoring configuration block.

Example:

<syscheck>
</syscheck>

All Syscheck settings are placed inside this section.

<directories>

Specifies directories that Wazuh should monitor.

Example:

<directories>/etc</directories>

Multiple directories can be monitored simultaneously.

<ignore>

Excludes files or directories from monitoring.

Example:

<ignore>/etc/mtab</ignore>

This is useful for reducing noise from frequently changing files.

<frequency>

Controls how often scheduled scans occur.

Example:

<frequency>43200</frequency>

This example performs a scan every 12 hours.

<scan_on_start>

Determines whether Syscheck performs a scan when the agent starts.

Example:

<scan_on_start>yes</scan_on_start>

This helps establish an updated baseline immediately after service startup.

<alert_new_files>

Controls whether alerts are generated when new files are created.

Example:

<alert_new_files>yes</alert_new_files>

This setting is especially useful for detecting malware drops and unauthorized software installations.

 Wazuh File Integrity Monitoring Documentation — https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/

Basic Wazuh File Integrity Monitoring Setup

Now that you’ve verified your environment and reviewed the Syscheck configuration options, it’s time to configure File Integrity Monitoring.

The following example enables real-time monitoring of critical system directories and generates alerts whenever files are created, modified, or deleted.

Step 1: Open the Agent Configuration

Open the Wazuh agent configuration file.

Linux:

sudo nano /var/ossec/etc/ossec.conf

Windows:

notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"

Locate the existing Syscheck section or create one if it does not exist.

Example:

<syscheck>
</syscheck>

All File Integrity Monitoring settings will be added within this block.

Step 2: Add Directories to Monitor

Specify the directories you want Wazuh to monitor.

Linux Example

Monitor critical system configuration files:

<directories check_all="yes" realtime="yes">/etc</directories>

Monitor web server content:

<directories check_all="yes" realtime="yes">/var/www/html</directories>

Windows Example

Monitor critical operating system files:

<directories check_all="yes" realtime="yes">C:\Windows\System32</directories>

Monitor application directories:

<directories check_all="yes" realtime="yes">C:\Program Files</directories>

Understanding the Attributes

check_all="yes"

Instructs Wazuh to monitor:

• File contents
• Permissions
• Ownership
• Size
• Modification times
• Attributes

This provides the most comprehensive visibility into file changes.

realtime="yes"

Enables immediate event detection rather than waiting for the next scheduled scan.

Benefits include:

• Faster threat detection
• Improved incident response
• Better ransomware visibility
• Reduced attacker dwell time

Step 3: Enable Real-Time Monitoring

The key configuration option is:

realtime="yes"

Example:

<directories check_all="yes" realtime="yes">/etc</directories>

With real-time monitoring enabled, Wazuh receives file change notifications almost immediately after modifications occur.

For most security-sensitive directories, real-time monitoring is strongly recommended.

Security experts at the SANS Institute frequently emphasize reducing detection time as a critical factor in limiting the impact of cyberattacks.

Step 4: Save Configuration and Restart Agent

After saving the configuration file, restart the Wazuh Agent so the new settings take effect.

Linux

sudo systemctl restart wazuh-agent

Verify the service starts successfully:

systemctl status wazuh-agent

Windows

Open an elevated PowerShell session:

Restart-Service WazuhSvc

Verify the service status:

Get-Service WazuhSvc

Expected output:

Status : Running

Once the agent reconnects to the manager, Wazuh will begin building its baseline and monitoring the configured directories for integrity violations.

In the next section, we’ll configure advanced Syscheck options, including file exclusions, monitoring frequency, hash settings, registry monitoring, and strategies for reducing false positives in large environments.

Understanding Important Syscheck Attributes

Wazuh’s File Integrity Monitoring capabilities are highly configurable through Syscheck attributes.

Understanding these settings allows you to fine-tune monitoring behavior, improve detection accuracy, and reduce unnecessary alerts.

Below are the most important Syscheck attributes you’ll encounter when configuring FIM.

check_all

The check_all attribute enables monitoring of all supported file attributes.

Example:

<directories check_all="yes">/etc</directories>

When enabled, Wazuh monitors:

• File contents
• Permissions
• Ownership
• Group ownership
• Modification timestamps
• File size
• Hash values

When to Use It

Use check_all="yes" when monitoring critical directories where maximum visibility is required.

Practical Example

<directories check_all="yes">/etc</directories>

This configuration ensures any modification to Linux configuration files generates an event.

realtime

The realtime attribute enables immediate change detection using operating system file notification APIs.

Example:

<directories realtime="yes">/etc</directories>

Instead of waiting for the next scheduled scan, Wazuh detects file modifications as soon as they occur.

Practical Example

<directories check_all="yes" realtime="yes">
/etc
</directories>

This configuration generates alerts almost instantly whenever a file inside /etc changes.

report_changes

The report_changes option stores and displays content differences between file versions.

Example:

<directories report_changes="yes">
/etc
</directories>

When a monitored text file changes, Wazuh can show exactly what changed.

Practical Example

If an attacker modifies:

PermitRootLogin no

to

PermitRootLogin yes

Wazuh can record and display the difference for investigation purposes.

Benefits

• Faster forensic analysis
• Easier troubleshooting
• Improved compliance auditing
• Better change management visibility

check_sha1sum

Calculates SHA1 hashes for monitored files.

Example:

<directories check_sha1sum="yes">
/etc
</directories>

Practical Example

When a file changes:

Old SHA1:
6f4d1a8...

New SHA1:
d90f99a...

Wazuh identifies the integrity violation and generates an alert.

check_sha256sum

Calculates SHA256 hashes.

Example:

<directories check_sha256sum="yes">
/etc
</directories>

SHA256 is generally preferred because it offers stronger cryptographic protection than SHA1.

Practical Example

<directories
check_sha256sum="yes"
check_all="yes">
/etc
</directories>

Many organizations standardize on SHA256 for integrity validation.

check_md5sum

Calculates MD5 hashes.

Example:

<directories check_md5sum="yes">
/etc
</directories>

Although MD5 is considered cryptographically weak for security-sensitive applications, it remains useful for change detection and backward compatibility.

Practical Example

<directories
check_md5sum="yes"
check_sha256sum="yes">
/etc
</directories>

This approach provides compatibility with older workflows while maintaining stronger SHA256 verification.

recursion_level

Controls how many subdirectories Wazuh scans beneath a monitored directory.

Example:

<directories recursion_level="3">
/var/www
</directories>

Practical Example

Directory structure:

/var/www
├── site1
├── site2
├── site3

A recursion level of 3 allows Wazuh to inspect nested folders without traversing an entire deep directory tree.

Benefits

• Reduces resource usage
• Improves scan speed
• Prevents monitoring unnecessary paths

restrict

The restrict attribute limits monitoring to files matching a specific pattern.

Example:

<directories restrict=".conf$">
/etc
</directories>

Only files ending in .conf will be monitored.

Practical Example

Monitor only configuration files:

<directories
check_all="yes"
restrict=".conf$">
/etc
</directories>

Monitor only shell scripts:

<directories
check_all="yes"
restrict=".sh$">
/usr/local/bin
</directories>

Benefits

• Reduces noise
• Lowers storage requirements
• Improves scan performance
• Focuses monitoring on high-value assets

 Wazuh Syscheck Reference — https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/syscheck.html

Configuring Real-Time File Integrity Monitoring

Real-time monitoring is one of the most powerful features available in Wazuh File Integrity Monitoring. Instead of waiting for periodic scans, Wazuh detects changes immediately after they occur and generates alerts within seconds.

What Real-Time Monitoring Does

Real-time monitoring leverages operating system file notification mechanisms such as:

• Linux inotify
• Windows FileSystemWatcher APIs
• Native filesystem event notifications

Whenever a monitored file changes, the agent immediately records the event and forwards it to the Wazuh Manager.

This significantly reduces detection time compared to scheduled-only scanning.

Benefits of Real-Time Detection

Real-time monitoring provides several security advantages:

• Immediate visibility into attacks
• Faster incident response
• Early ransomware detection
• Detection of unauthorized administrator activity
• Improved compliance monitoring
• Better threat hunting capabilities

According to the SANS Institute, reducing attacker dwell time remains one of the most effective ways to limit breach impact.

Example Configuration

Enable real-time monitoring for Linux configuration files:

<directories realtime="yes" check_all="yes">
/etc
</directories>

This configuration generates alerts immediately whenever files within /etc are created, modified, or deleted.

When to Avoid Real-Time Monitoring

Although real-time monitoring is highly effective, it is not appropriate for every directory.

High-Volume Directories

Avoid enabling real-time monitoring on locations that change constantly, such as:

/var/log
/tmp
/var/tmp

These locations can generate excessive alerts and unnecessary resource consumption.

Performance-Sensitive Servers

Exercise caution when monitoring:

• Database storage directories
• High-transaction application servers
• Large file repositories
• Build servers

In these environments, scheduled scans may be more appropriate.

Monitoring Critical Linux Files

Certain Linux directories should almost always be considered for integrity monitoring.

Recommended Directories

/etc

Contains:

• System configuration files
• Service configurations
• Authentication settings

/usr/bin

Contains:

• Executable binaries
• System commands

/usr/sbin

Contains:

• Administrative utilities
• System management tools

/boot

Contains:

• Kernel files
• Bootloader configuration

/root

Contains:

• Root user files
• Administrative scripts

Compromise of these directories often indicates significant security issues.

Example Linux FIM Configuration

<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>

  <directories check_all="yes" realtime="yes">
    /usr/bin
  </directories>
</syscheck>

Many organizations expand this list to include:

/usr/sbin
/boot
/root
/opt

depending on their environment.

Monitoring Critical Windows Files

Windows systems contain several high-value directories that should be monitored closely.

Recommended Directories

C:\Windows\System32

Contains:

• Core operating system files
• DLLs
• System executables

C:\Program Files

Contains:

• Installed applications
• Security software
• Business applications

C:\Users

Contains:

• User documents
• Desktop files
• Downloads
• Potential malware staging locations

Example Windows Configuration

<syscheck>
  <directories check_all="yes" realtime="yes">
    C:\Windows\System32
  </directories>
</syscheck>

Additional directories can be added as needed.

Monitoring Specific Files Only

In some environments, monitoring entire directories may generate excessive noise.

Why Monitor Individual Files

Monitoring individual files allows you to focus on the most critical assets.

Benefits include:

• Reduced alert volume
• Improved performance
• Easier investigations
• Better compliance alignment

Example

<directories check_all="yes">
/etc/passwd
</directories>

Only the specified file will be monitored.

Common Files to Monitor

Linux administrators frequently monitor:

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config

Changes to these files can indicate:

• Privilege escalation
• Account manipulation
• SSH backdoor creation
• Authentication policy modifications

Excluding Files and Directories

Not every file should be monitored.

Frequently changing files often generate excessive alerts and increase storage consumption.

Using Ignore Rules

The <ignore> directive excludes files or directories from monitoring.

Example:

<ignore>/var/log</ignore>

Ignoring Temporary Files

Example:

<ignore>/tmp</ignore>
<ignore>/var/tmp</ignore>

Ignoring Backup Files

Example:

<ignore type="sregex">.bak$|.old$|.tmp$</ignore>

Reducing Alert Noise

Effective exclusion rules help:

• Reduce false positives
• Improve dashboard visibility
• Simplify investigations
• Lower resource usage

When properly tuned, Syscheck focuses analyst attention on genuinely important file integrity events rather than routine operational changes.

Configuring Scheduled Integrity Scans

While real-time monitoring provides immediate visibility into file changes, scheduled scans remain an important component of a complete File Integrity Monitoring strategy.

Many organizations deploy both methods simultaneously to maximize coverage and ensure no changes are missed.

Understanding Scan Frequency

Syscheck periodically scans monitored files and compares them against its baseline database.

The interval between scans is controlled by the <frequency> setting.

Default Behavior

By default, Wazuh performs integrity scans at regular intervals defined within the Syscheck configuration.

During each scan, Wazuh evaluates:

• File hashes
• File size
• Ownership
• Permissions
• Timestamps
• Metadata changes

Any detected differences generate integrity events.

Customize Scan Interval

The frequency value is specified in seconds.

Example:

<frequency>21600</frequency>

This configuration performs a scan every:

21,600 seconds = 6 hours

Additional examples:

Balancing Performance and Security

Choosing the correct scan interval depends on your environment.

More Frequent Scans

Advantages:

• Faster detection
• Better compliance coverage
• Improved visibility

Disadvantages:

• Increased CPU usage
• Increased disk activity
• More frequent hashing operations

Less Frequent Scans

Advantages:

• Reduced resource consumption
• Better performance on large servers

Disadvantages:

• Longer detection windows
• Delayed alerting

Most organizations combine scheduled scans with real-time monitoring for critical directories.

Enabling File Content Change Detection

One of the most valuable Syscheck features is the ability to record actual file content changes.

This functionality is enabled using the report_changes attribute.

Using report_changes

Example:

<directories report_changes="yes" realtime="yes">
/etc
</directories>

When a monitored text file changes, Wazuh records the difference between versions.

For example:

Before:
PermitRootLogin no

After:
PermitRootLogin yes

This information appears within the generated alert.

Benefits

Identify Exactly What Changed

Instead of simply knowing that a file changed, analysts can see the specific modifications.

Faster Incident Investigations

Investigators spend less time manually comparing files.

Better Compliance Reporting

Auditors often require evidence showing exactly what changed and when.

Improved Threat Hunting

Security teams can quickly identify:

• Backdoors
• Malicious configuration changes
• Unauthorized account additions
• Security control modifications

Security Considerations

Because report_changes stores file differences, administrators should use it carefully.

Consider avoiding this setting on:

• Files containing credentials
• Sensitive secrets
• Private keys
• Confidential business data

For highly sensitive systems, integrity monitoring through hash validation may be preferable to storing content differences.

Organizations following compliance frameworks such as PCI DSS, NIST, and CIS Controls commonly use a combination of file hashing, scheduled scans, and real-time monitoring to achieve comprehensive integrity monitoring coverage.

Monitoring File Permissions and Ownership Changes

File content changes are important, but attackers frequently alter permissions and ownership settings without modifying the file contents themselves.

Monitoring these metadata changes can help uncover privilege escalation attempts, persistence mechanisms, and unauthorized administrative activity.

Why Permissions Matter

File permissions determine who can read, write, and execute files on a system.

An attacker who gains access to a server may attempt to:

• Make malicious files executable
• Grant unauthorized users elevated access
• Modify system configurations
• Create hidden persistence mechanisms
• Change ownership of sensitive files

Without permission monitoring enabled, these activities can easily go undetected.

For example, changing a file from:

-rw-r--r--

to:

-rwxrwxrwx

could indicate a serious security issue.

Detecting Privilege Escalation Attempts

Privilege escalation often involves modifying permissions on critical files.

Examples include:

• Changing permissions on /etc/sudoers
• Modifying ownership of SSH configuration files
• Granting write access to privileged binaries
• Altering application service account permissions

By monitoring ownership and permission changes, Wazuh can alert security teams before attackers achieve persistent elevated access.

The MITRE ATT&CK framework identifies permission modification and account manipulation as common techniques used during post-compromise activity.

Example Configuration

Enable permission and ownership monitoring:

<directories
check_perm="yes"
check_owner="yes">
/etc
</directories>

You can combine these settings with other Syscheck options:

<directories
check_all="yes"
check_perm="yes"
check_owner="yes"
realtime="yes">
/etc
</directories>

This configuration monitors:

• File contents
• Permissions
• Ownership
• Metadata changes
• Real-time events

Verifying That File Integrity Monitoring Is Working

After configuring FIM, you should validate that Wazuh is correctly detecting file changes.

Create a Test File

On a Linux endpoint:

touch /etc/fim-test.txt

Wait a few moments for Wazuh to process the event.

Modify a File

Add content to the file:

echo "test" >> /etc/fim-test.txt

This action should generate a file modification event.

Review Generated Alerts

Check the Wazuh Dashboard or manager logs for new Syscheck alerts.

You should see events indicating:

• File creation
• File modification
• Hash changes
• Metadata updates

Validate Detection Results

Verify that the alert contains:

• Correct file path
• Event type
• Timestamp
• Agent name
• Hash information

If alerts are not appearing, revisit the troubleshooting steps in our Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work guide.

Viewing FIM Alerts in the Wazuh Dashboard

Once monitoring is active, most investigations will occur through the Wazuh Dashboard.

Navigating to Security Events

Open:

Security Events

or:

Threat Hunting

depending on your Wazuh version.

From there, you can search, filter, and analyze Syscheck alerts.

Filtering Syscheck Events

Useful search filters include:

rule.groups: syscheck

syscheck.path: /etc/passwd

rule.level >= 7

Filtering helps isolate file integrity events from other security alerts.

Common FIM Alert Types

File Added

Generated when a new file appears within a monitored directory.

Examples:

• Malware payload dropped
• Unauthorized script created
• Backdoor uploaded

File Modified

Generated when an existing file changes.

Examples:

• Configuration changes
• Website defacement
• Malicious code injection

File Deleted

Generated when monitored files are removed.

Examples:

• Log tampering
• Removal of security tools
• Destruction of evidence

Permission Changed

Generated when file access controls are modified.

Examples:

• Unauthorized privilege escalation
• Access control weakening
• Ownership changes

Understanding Alert Severity Levels

Wazuh assigns severity levels based on the rule that generated the alert.

Typical ranges include:

Critical system file modifications should generally generate higher-severity alerts than routine operational changes.

Proper severity tuning helps analysts prioritize investigations and reduce alert fatigue.

Creating Custom FIM Detection Rules

Out-of-the-box Syscheck rules provide strong file integrity monitoring coverage, but many organizations need more granular detection capabilities.

Custom rules allow you to assign higher severity levels to specific files, generate more descriptive alerts, and focus attention on assets that are especially important to your environment.

Why Create Custom Rules

Not all files have the same security value.

For example:

• Changes to /etc/passwd are more critical than changes to temporary files.
• Modifications to sshd_config may indicate unauthorized remote access changes.
• Updates to web application configuration files could signal compromise.

Custom rules help prioritize these events.

Common use cases include:

• Monitoring SSH configuration changes
• Tracking modifications to privileged account files
• Detecting changes to application configurations
• Highlighting compliance-sensitive assets
• Escalating alerts for critical infrastructure systems

For a complete walkthrough of rule creation, see our How to Create Custom Detection Rules in Wazuh (With Examples).

Example Custom Rule

The following rule increases the severity of events involving the SSH daemon configuration file.

<rule id="100500" level="10">
  <if_group>syscheck</if_group>
  <match>sshd_config</match>
  <description>
    Critical SSH configuration modified
  </description>
</rule>

When Wazuh detects modifications involving sshd_config, the event will generate a level 10 alert.

What This Rule Does

• Evaluates Syscheck events
• Searches for “sshd_config”
• Assigns a severity level of 10
• Generates a custom description

This helps security teams immediately recognize high-risk configuration changes.

Testing the Rule

After creating the rule:

1. Save the rule file.
2. Restart the Wazuh Manager.
3. Modify the monitored file.
4. Confirm the custom alert appears.

Example:

sudo echo "# test" >> /etc/ssh/sshd_config

Then review generated alerts in the dashboard.

You should see:

Critical SSH configuration modified

rather than the default Syscheck message.

Deploying Custom Rules

Custom rules are typically stored in:

/var/ossec/etc/rules/local_rules.xml

After saving the file, restart the manager:

sudo systemctl restart wazuh-manager

You can validate the configuration using:

/var/ossec/bin/wazuh-logtest

This utility allows you to test detection logic before deploying it to production.

As your environment grows, custom rules become an essential part of reducing noise and improving alert quality.

Advanced FIM Configuration Techniques

Basic File Integrity Monitoring provides strong visibility, but advanced configurations can significantly improve performance, reduce false positives, and focus monitoring on the assets that matter most.

Monitor Only Certain File Types

Large directories often contain thousands of files that are not security relevant.

Instead of monitoring everything, you can focus on specific file types.

Examples include:

• .conf
• .cfg
• .ini
• .xml
• .sh
• .ps1

This approach reduces:

• Storage requirements
• CPU utilization
• Alert volume
• Investigation workload

Restrict Monitoring with Regex

The restrict attribute uses regular expressions to determine which files are monitored.

Example

Monitor only configuration files:

<directories restrict="\.conf$">
/etc
</directories>

Only files ending in .conf will be evaluated.

Additional Examples

Shell scripts:

<directories restrict="\.sh$">
/usr/local/bin
</directories>

XML files:

<directories restrict="\.xml$">
/opt/app/config
</directories>

PowerShell scripts:

<directories restrict="\.ps1$">
C:\Scripts
</directories>

This targeted approach improves monitoring efficiency while maintaining visibility into high-value assets.

Monitor High-Risk Configuration Files

Certain files deserve individual monitoring because compromise could have a significant security impact.

Examples include:

Linux

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config
/etc/crontab

Windows

C:\Windows\System32\drivers\etc\hosts
C:\Windows\System32\config
Group Policy files
PowerShell profile scripts

Many security teams create dedicated custom rules for these assets to ensure high-severity alerts.

Multiple Directory Monitoring Strategies

Large environments often require different monitoring policies for different asset types.

Strategy 1: Critical System Directories

Use aggressive monitoring:

<directories
check_all="yes"
realtime="yes">
/etc
</directories>

Strategy 2: Application Directories

Use moderate monitoring:

<directories
check_sha256sum="yes">
/opt/application
</directories>

Strategy 3: Large Data Repositories

Use scheduled scans only:

<directories>
/data
</directories>

Strategy 4: Compliance-Focused Monitoring

Monitor only sensitive files:

<directories>
/etc/passwd
</directories>

<directories>
/etc/shadow
</directories>

This layered approach helps balance:

• Security visibility
• Performance
• Storage utilization
• Alert quality

Organizations operating large Wazuh deployments frequently adopt multiple monitoring profiles rather than applying the same configuration everywhere.

Advanced FIM Configuration Techniques

Basic File Integrity Monitoring provides strong visibility, but advanced configurations can significantly improve performance, reduce false positives, and focus monitoring on the assets that matter most.

Monitor Only Certain File Types

Large directories often contain thousands of files that are not security relevant.

Instead of monitoring everything, you can focus on specific file types.

Examples include:

• .conf
• .cfg
• .ini
• .xml
• .sh
• .ps1

This approach reduces:

• Storage requirements
• CPU utilization
• Alert volume
• Investigation workload

Restrict Monitoring with Regex

The restrict attribute uses regular expressions to determine which files are monitored.

Example

Monitor only configuration files:

<directories restrict="\.conf$">
/etc
</directories>

Only files ending in .conf will be evaluated.

Additional Examples

Shell scripts:

<directories restrict="\.sh$">
/usr/local/bin
</directories>

XML files:

<directories restrict="\.xml$">
/opt/app/config
</directories>

PowerShell scripts:

<directories restrict="\.ps1$">
C:\Scripts
</directories>

This targeted approach improves monitoring efficiency while maintaining visibility into high-value assets.

Monitor High-Risk Configuration Files

Certain files deserve individual monitoring because compromise could have a significant security impact.

Examples include:

Linux

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config
/etc/crontab

Windows

C:\Windows\System32\drivers\etc\hosts
C:\Windows\System32\config
Group Policy files
PowerShell profile scripts

Many security teams create dedicated custom rules for these assets to ensure high-severity alerts.

Multiple Directory Monitoring Strategies

Large environments often require different monitoring policies for different asset types.

Strategy 1: Critical System Directories

Use aggressive monitoring:

<directories
check_all="yes"
realtime="yes">
/etc
</directories>

Strategy 2: Application Directories

Use moderate monitoring:

<directories
check_sha256sum="yes">
/opt/application
</directories>

Strategy 3: Large Data Repositories

Use scheduled scans only:

<directories>
/data
</directories>

Strategy 4: Compliance-Focused Monitoring

Monitor only sensitive files:

<directories>
/etc/passwd
</directories>

<directories>
/etc/shadow
</directories>

This layered approach helps balance:

• Security visibility
• Performance
• Storage utilization
• Alert quality

Organizations operating large Wazuh deployments frequently adopt multiple monitoring profiles rather than applying the same configuration everywhere.

Performance Optimization Best Practices

File Integrity Monitoring is extremely valuable for security, but poorly configured monitoring can consume unnecessary CPU, memory, disk I/O, and storage resources.

As environments grow, performance optimization becomes increasingly important.

The goal is to maximize security visibility while minimizing operational overhead.

Avoid Monitoring Large Dynamic Directories

One of the most common mistakes is enabling FIM on directories that change constantly.

Examples include:

/var/log
/tmp
/var/tmp

Windows examples:

C:\Windows\Temp
C:\Users\*\AppData\Local\Temp

These locations often generate thousands of events per day and rarely provide meaningful security insights.

Problems caused by monitoring dynamic directories include:

• Alert fatigue
• Increased CPU utilization
• Larger Syscheck databases
• Excessive storage consumption
• Longer scan times

Focus monitoring on critical configuration files and system directories instead.

Use Exclusions Strategically

The <ignore> directive is one of the most effective ways to improve Syscheck performance.

Example:

<ignore>/var/log</ignore>

Regular expression exclusions can also be used:

<ignore type="sregex">
\.tmp$|\.bak$|\.swp$
</ignore>

Common exclusion candidates include:

• Temporary files
• Backup files
• Cache directories
• Log files
• Application-generated artifacts

Strategic exclusions reduce unnecessary scanning and improve alert quality.

Tune Scan Frequency

Scheduled scans should align with the risk profile of the monitored assets.

Example:

<frequency>21600</frequency>

This performs a scan every six hours.

Recommended intervals:

Running scans too frequently can consume unnecessary resources without providing meaningful security benefits.

Limit Recursive Scans

Deep directory trees can dramatically increase scan times.

Instead of scanning entire directory structures, limit recursion depth.

Example:

<directories recursion_level="3">
/var/www
</directories>

Benefits include:

• Faster scans
• Lower CPU usage
• Reduced memory consumption
• Smaller monitoring databases

This approach is especially useful for application servers and file repositories.

Reduce Storage Consumption

Large FIM deployments can generate significant storage requirements.

To reduce storage usage:

• Monitor only critical assets
• Use file type restrictions
• Configure exclusions
• Limit content-diff storage
• Reduce unnecessary alert generation

Example:

<directories
restrict="\.conf$"
check_sha256sum="yes">
/etc
</directories>

Monitoring only configuration files often provides better security value than monitoring every file on a system.

The Center for Internet Security (CIS) recommends prioritizing monitoring efforts on high-value assets rather than attempting to monitor every file indiscriminately.

Compliance Use Cases for Wazuh FIM

File Integrity Monitoring is not only a security control—it is also a requirement or recommended practice across numerous regulatory frameworks and security standards.

Organizations often deploy Wazuh FIM to satisfy audit requirements while simultaneously improving threat detection capabilities.

PCI DSS Requirements

The Payment Card Industry Data Security Standard (PCI DSS) places significant emphasis on file integrity monitoring.

PCI DSS Requirement 11.5 specifically requires organizations to:

Deploy a change-detection mechanism to alert personnel to unauthorized modification of critical files.

Wazuh FIM helps satisfy this requirement by:

• Monitoring critical system files
• Detecting unauthorized modifications
• Generating alerts
• Maintaining audit trails
• Recording file integrity violations

Common PCI DSS monitoring targets include:

Payment applications
Web servers
Authentication systems
Configuration files

PCI DSS Documentation — https://www.pcisecuritystandards.org/

HIPAA Compliance

Organizations handling protected health information (PHI) must implement safeguards to protect sensitive data.

While HIPAA does not explicitly mandate File Integrity Monitoring, FIM supports several HIPAA Security Rule objectives by helping organizations:

• Detect unauthorized changes
• Monitor access-related configurations
• Identify insider threats
• Maintain audit evidence

Healthcare organizations commonly use Wazuh FIM to monitor:

• Electronic medical record systems
• Authentication services
• Clinical application servers
• Critical operating system files

SOC 2 Controls

SOC 2 audits focus heavily on security, availability, and integrity controls.

File Integrity Monitoring helps organizations demonstrate:

• Change management processes
• Security monitoring controls
• Incident detection capabilities
• System integrity protections

Wazuh provides evidence that monitored files are continuously evaluated for unauthorized modifications.

This audit trail is often useful during SOC 2 assessments.

CIS Benchmarks

The CIS Benchmarks and CIS Controls recommend monitoring critical files and system configurations for unauthorized changes.

Examples include:

• Linux configuration files
• Windows system files
• Privileged account configurations
• Security policy settings

Wazuh aligns well with these recommendations through its Syscheck functionality.

Organizations implementing CIS hardening standards frequently pair benchmark compliance with FIM monitoring.

ISO 27001 Requirements

ISO 27001 requires organizations to implement controls that preserve the confidentiality, integrity, and availability of information assets.

File Integrity Monitoring supports several ISO 27001 objectives by helping organizations:

• Detect unauthorized modifications
• Monitor critical systems
• Validate change management procedures
• Maintain audit records

Common ISO 27001 use cases include:

• Monitoring configuration drift
• Detecting unauthorized changes
• Supporting internal audits
• Maintaining evidence for certification reviews

Many organizations leverage Wazuh FIM as part of a broader Information Security Management System (ISMS).

Common Wazuh FIM Issues and Troubleshooting

Even properly configured deployments occasionally encounter File Integrity Monitoring issues.

Understanding the most common problems can significantly reduce troubleshooting time.

No File Change Alerts Generated

Symptoms

• Files are modified
• No Syscheck alerts appear
• Dashboard remains empty

Possible Causes

• Directory not configured
• Syscheck disabled
• Agent disconnected
• Configuration syntax errors
• Scan interval too long

Troubleshooting Steps

Verify the monitored directory exists:

grep syscheck /var/ossec/etc/ossec.conf

Validate configuration syntax:

/var/ossec/bin/wazuh-control info

Confirm the agent is connected:

/var/ossec/bin/agent_control -lc

If connectivity issues exist, review our Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work guide.

Real-Time Monitoring Not Working

Symptoms

• Scheduled scans work
• Immediate alerts do not appear

Possible Causes

• Missing realtime="yes"
• Unsupported filesystem
• OS notification limitations
• Agent service issues

Verify Configuration

Example:

<directories
check_all="yes"
realtime="yes">
/etc
</directories>

Restart the agent after making changes:

sudo systemctl restart wazuh-agent

Review Agent Logs

Linux:

tail -f /var/ossec/logs/ossec.log

Look for Syscheck-related errors.

Excessive False Positives

Symptoms

• Large numbers of alerts
• Frequent notifications
• Analyst fatigue

Common Causes

• Monitoring log directories
• Monitoring temporary files
• Application-generated file changes
• Backup operations

Solutions

Add exclusions:

<ignore>/var/log</ignore>

Ignore temporary files:

<ignore type="sregex">
\.tmp$|\.bak$
</ignore>

Use targeted monitoring instead of broad directory scans.

High CPU Usage

Symptoms

• Agent consumes excessive CPU
• Slow endpoint performance
• Long scan durations

Common Causes

• Monitoring large directories
• Deep recursive scans
• Excessive hash calculations
• Short scan intervals

Solutions

Reduce recursion depth:

<directories recursion_level="2">
/var/www
</directories>

Increase scan interval:

<frequency>43200</frequency>

Exclude nonessential files.

Agent Not Reporting Syscheck Events

Symptoms

• Syscheck scans appear to run
• Manager receives no events

Verify Agent Status

Linux:

systemctl status wazuh-agent

Windows:

Get-Service WazuhSvc

Verify Manager Status

systemctl status wazuh-manager

Restart Services

Agent:

sudo systemctl restart wazuh-agent

Manager:

sudo systemctl restart wazuh-manager

Missing Dashboard Events

Symptoms

• Alerts exist on the manager
• Events do not appear in the dashboard

Possible Causes

• Indexing issues
• OpenSearch problems
• Dashboard filters
• Permission issues

Troubleshooting Steps

Verify indexer health.

Check:

• OpenSearch status
• Index creation
• Dashboard connectivity
• User permissions

Organizations using OpenSearch-based deployments may also find it helpful to review our Wazuh vs OpenSearch comparison for additional architectural considerations.

Useful Troubleshooting Logs

Agent log:

/var/ossec/logs/ossec.log

Manager log:

/var/ossec/logs/ossec.log

These logs provide the most valuable information when diagnosing Syscheck issues.

In most environments, reviewing agent connectivity, Syscheck configuration, and dashboard indexing resolves the majority of File Integrity Monitoring problems within minutes.

Wazuh FIM Best Practices

Configuring File Integrity Monitoring is only the first step.

To maximize security value while minimizing operational overhead, organizations should follow a set of proven best practices.

These recommendations help improve detection accuracy, reduce false positives, and ensure that security teams focus on the most meaningful integrity violations.

Monitor Critical Assets First

One of the most common mistakes is attempting to monitor every file on every system.

A better approach is to prioritize high-value assets such as:

Linux

/etc
/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config
/usr/bin
/usr/sbin

Windows

C:\Windows\System32
C:\Program Files
Group Policy files
PowerShell scripts
Security software directories

Start with critical assets and gradually expand monitoring as needed.

This approach provides the greatest security benefit while keeping resource usage manageable.

Enable Real-Time Monitoring Selectively

Real-time monitoring offers the fastest detection capabilities, but it should not be enabled everywhere.

Recommended use cases:

• System configuration files
• Authentication settings
• Administrative scripts
• Security tool directories
• Web application code

Avoid real-time monitoring on:

• Log directories
• Temporary file locations
• High-volume application data
• Large file repositories

Selective deployment helps maintain strong security visibility without overwhelming the system.

Review Alerts Regularly

Even the best monitoring solution is ineffective if alerts are ignored.

Establish a process for:

• Daily alert review
• Incident triage
• Rule tuning
• False positive reduction
• Periodic audit validation

Security teams should periodically evaluate whether monitored files and directories remain relevant as infrastructure evolves.

Create High-Priority Rules for Sensitive Files

Certain files deserve elevated alert severity because changes could indicate a serious compromise.

Examples include:

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/sshd_config

Consider creating custom rules that:

• Increase severity levels
• Generate custom descriptions
• Trigger notifications
• Escalate incidents automatically

For example:

<rule id="100600" level="12">
  <if_group>syscheck</if_group>
  <match>sudoers</match>
  <description>
    Critical privilege configuration modified
  </description>
</rule>

If you haven’t created custom rules before, see our How to Create Custom Detection Rules in Wazuh (With Examples).

Combine FIM with Active Response

File Integrity Monitoring becomes significantly more powerful when combined with Active Response capabilities.

Potential automated actions include:

• Blocking malicious IP addresses
• Isolating compromised hosts
• Terminating suspicious processes
• Disabling user accounts
• Sending notifications to SOC teams

This reduces the time between detection and remediation.

According to research published by IBM’s Cost of a Data Breach Report, organizations with mature detection and response capabilities generally reduce breach impact and recovery costs compared to organizations with slower response processes.

Maintain a Baseline

Effective FIM depends on a trustworthy baseline.

Whenever major changes occur:

• System upgrades
• Application deployments
• Security updates
• Infrastructure migrations

Review and update your baseline accordingly.

Benefits include:

• Fewer false positives
• More accurate alerts
• Better incident investigations
• Improved compliance reporting

Many experienced security teams incorporate baseline validation into their change management processes to ensure integrity monitoring remains accurate over time.

Frequently Asked Questions

Question: Is Wazuh FIM enabled by default?

The Syscheck module is typically enabled by default in Wazuh installations, but the exact directories being monitored vary depending on the operating system and agent configuration.

You should always review the <syscheck> section of ossec.conf to confirm which files and directories are being monitored.

Many organizations expand the default configuration to include business-critical assets and compliance-sensitive systems.

Question: What is the difference between real-time and scheduled monitoring?

The primary difference is how quickly changes are detected.

Real-Time Monitoring

• Detects changes immediately
• Uses operating system event notifications
• Generates alerts within seconds
• Best for critical assets

Scheduled Monitoring

• Runs at predefined intervals
• Performs periodic integrity scans
• Lower resource consumption
• Useful for large environments

Most production deployments use both methods together.

Question: Can Wazuh monitor Windows and Linux systems?

Yes.

Wazuh File Integrity Monitoring supports:

• Linux
• Windows
• macOS
• Unix-based systems

The Syscheck module operates similarly across platforms while leveraging native operating system monitoring capabilities.

This makes Wazuh suitable for hybrid environments containing multiple operating systems.

Does Wazuh detect ransomware-related file changes?

Yes.

Although Wazuh is not a dedicated anti-ransomware product, File Integrity Monitoring can help identify ransomware activity by detecting:

• Rapid file modifications
• File creation events
• File deletion events
• Permission changes
• Suspicious executable deployments

Many ransomware attacks generate large numbers of integrity events that can serve as early warning indicators.

Organizations often combine FIM with custom detection rules to improve ransomware visibility.

How often should integrity scans run?

The ideal scan interval depends on the system being monitored.

General recommendations:

Critical assets should also use real-time monitoring whenever possible.

Question: Does FIM impact system performance?

Yes, but the impact is usually minimal when configured correctly.

Factors affecting performance include:

• Number of monitored files
• Hashing algorithms used
• Scan frequency
• Recursion depth
• Real-time monitoring scope

Performance issues typically occur when administrators monitor large dynamic directories unnecessarily.

Following the optimization recommendations discussed earlier in this guide helps minimize resource consumption while maintaining strong security coverage.

Conclusion

File Integrity Monitoring is one of the most effective ways to detect unauthorized system changes, configuration tampering, malware activity, and potential insider threats.

By implementing Wazuh FIM, organizations gain continuous visibility into critical files and directories across Linux and Windows environments.

Throughout this guide, we’ve covered the complete Wazuh File Integrity Monitoring setup process, including:

• Understanding Syscheck architecture
• Configuring monitored directories
• Enabling real-time monitoring
• Creating scheduled integrity scans
• Monitoring permissions and ownership changes
• Reducing false positives
• Building custom detection rules
• Troubleshooting common issues
• Optimizing performance

For most environments, the following configuration recommendations provide the best balance between security and performance:

• Monitor critical system files first
• Enable real-time monitoring for high-value assets
• Exclude temporary and log directories
• Use SHA256 integrity verification
• Review alerts regularly
• Create custom rules for sensitive files
• Maintain an updated baseline

Remember that the effectiveness of File Integrity Monitoring depends heavily on monitoring the right assets.

Critical authentication files, system configurations, administrative scripts, and security-related directories should receive the highest level of scrutiny.

As your deployment matures, consider enhancing detection coverage by:

• Creating custom Syscheck detection rules
• Integrating alerts with ticketing platforms
• Forwarding alerts to SIEM solutions
• Implementing automated Active Response actions
• Developing compliance-specific monitoring policies

If you’re looking to expand your Wazuh deployment further, the next logical step is learning how to build custom detections. Start with our How to Create Custom Detection Rules in Wazuh (With Examples).

You may also find these related guides useful:

• Wazuh Agent Not Connecting to Manager? 12 Fixes That Actually Work
• How to Install a Wazuh Agent on Windows Server
• Wazuh vs OSSEC
•  Security Onion vs Wazuh
• Wazuh vs Splunk

With proper planning, tuning, and ongoing maintenance, Wazuh File Integrity Monitoring can become a critical component of your organization’s threat detection, compliance, and security monitoring strategy.