Ransomware Detection with Wazuh: Rules, FIM and Active Response (2026 Guide)

Modern ransomware follows a predictable chain: initial access, privilege escalation, disabling backups, then mass encryption. Each stage creates signals Wazuh can detect. The goal is to alert and contain before encryption spreads.

Key ransomware signals

• Deletion of Volume Shadow Copies (vssadmin, wmic shadowcopy, wbadmin).
• Sudden mass file modifications or renames to unusual extensions.
• Ransom note files appearing across many folders.
• Security tools or Windows Defender being disabled.

Enable real time FIM on user data

Alert on shadow copy deletion

With Sysmon forwarding process creation events (Event ID 1), add a custom rule in /var/ossec/etc/rules/local_rules.xml:

Detect mass file changes

Contain automatically with active response

Link high severity ransomware rules to an active response script that isolates the host or kills the process, so containment happens in seconds instead of waiting for an analyst.

Ransomware readiness checklist

1. 1Sysmon deployed on all Windows endpoints and forwarding to Wazuh.
2. 2Real time FIM on user folders and file shares.
3. 3Custom rules for shadow copy deletion and mass file changes.
4. 4Active response tested on a lab host.
5. 5Offline, immutable backups verified monthly.

Deploy Sysmon and forward its events

Most ransomware rules depend on process creation data, which Windows does not log well by default. Install Sysmon with a community config on every Windows endpoint:

Then tell the Wazuh agent to read the Sysmon channel. Add this to C:\Program Files (x86)\ossec-agent\ossec.conf, or push it centrally through agent groups:

Extra high value detection rules

Add these to /var/ossec/etc/rules/local_rules.xml on the manager. Each targets a step attackers take right before encryption:

Use canary files for near zero false positives

Place decoy files that no person or backup job should ever touch, for example C:\Shares\000_canary.docx. Any change to them is almost certainly encryption, which is why rule 100605 is level 15. Make sure the folder is covered by realtime FIM, then run a quick check after placing them:

A complete isolation response

Wazuh ships a netsh active response that blocks the attacker IP on Windows. For ransomware you usually want to isolate the whole host instead. Define the command on the manager:

Save the script on each endpoint as C:\Program Files (x86)\ossec-agent\active-response\bin\isolate-host.cmd. It blocks all traffic except to the Wazuh manager, so you keep visibility:

Safely test your detections

Never test with real ransomware. These harmless commands trigger the rules without deleting anything, because the shadow copy command targets a volume that has no copies on a lab VM:

Within seconds you should see the alerts in Threat Hunting and, if active response is enabled, the host losing network access except to the manager.

Keeping false positives low

• Exclude backup software processes from the mass change rule using a child rule at level 0.
• Exclude Windows Update and software deployment folders from FIM.
• Start the mass change rule at frequency 100 and lower it after a week of observation.
• Review every level 12+ alert for two weeks before turning on automatic isolation.

Frequently asked questions

Can Wazuh stop ransomware completely?

No single tool can. Wazuh detects the early stages and can contain a host automatically, which limits damage. Offline backups and patching remain essential.

Does this work on Linux servers?

Yes. FIM, canary files and the mass change rule work the same on Linux. Use auditd or the Wazuh who-data option instead of Sysmon.

Our 24/7 SOC deploys these detections, tunes them for your environment and responds around the clock. Start with a 30-Day PoC to see them working on your own endpoints.