Learn Wazuh - Active Response & Malware Detection

#Introduction

In episode 7 you learned to monitor file integrity with syscheck and read every suspicious change. But there's a gap that often troubles the real world: between an alert appearing and an analyst opening a terminal, valuable time passes. During that pause, an attacker can keep moving.

Episode 8 closes that gap with two topics: active response and malware detection. Active response lets Wazuh act automatically when an alert fires, such as blocking an IP, killing a process, or quarantining a file. Malware detection takes us through rootcheck for rootkits, YARA integration, and the newest malware scan module in Wazuh 4.10.

By the end of this episode you'll have a detection machine that doesn't just notify, but can also defend itself.

#The Active Response Concept

Active response is an action executed on the agent when a rule is met. Instead of waiting for a human, Wazuh directly executes the command according to a predefined policy. The command runs on the agent where the alert originated, so its effect is close to the source of the problem.

One thing to understand from the start: active response is not a replacement for the analyst, but a time-buying tool. Automatic actions stop the impact fastest, while humans still do the thorough investigation and make the final decision. This approach balances speed with accuracy.

#Active Response Components in ossec.conf

The active response configuration is made of two interrelated parts: the command list and the trigger rules. The commands section defines the available executables and their arguments, while the active-response section connects a specific command to the alerts that trigger it.

<ossec_config>
  <command>
    <name>firewall-drop</name>
    <executable>firewall-drop.sh</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>
 
  <command>
    <name>host-deny</name>
    <executable>host-deny.sh</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>
</ossec_config>

Executable scripts like firewall-drop.sh live in the /var/ossec/active-response/bin/ directory on the agent. The timeout_allowed element gives the command permission to accept a time parameter, which is later used to undo the automatic action after the deadline.

#Building Agent Commands: Block IP, Kill Process, Quarantine

Once the commands are registered, the next step is creating the agent block that connects commands to trigger rules. The active-response section holds the command name, the triggering rule, the action location, and the timeout.

<ossec_config>
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>100001</rules_id>
    <timeout>300</timeout>
  </active-response>
 
  <active-response>
    <command>host-deny</command>
    <location>local</location>
    <rules_id>100002</rules_id>
    <timeout>600</timeout>
  </active-response>
</ossec_config>

The location value sets where the command runs: local means only on the agent that generated the alert, while server means on the manager. The location choice depends heavily on the nature of the action. Blocking an IP in a local agent firewall is enough for a single host, but blocking at the network gateway requires a command that runs on the server or central firewall.

To kill a process, a command can call a script that finds and terminates processes by name. For file quarantine, a command moves the suspicious file to an isolated directory and locks access, so the file can't be executed again but remains available for forensic analysis.

FILE="$1"
QUARANTINE="/var/quarantine"
mkdir -p "$QUARANTINE"
mv "$FILE" "$QUARANTINE"
chmod 000 "$QUARANTINE/$(basename "$FILE")"

The example above moves the file to a quarantine folder and removes all permissions. The result is the file can't be run, but investigators can still read its contents with special access rights. This pattern is far better than deleting a file that might be key evidence.

#Timeout and Frequency

Timeout determines how long an active action lasts before it's undone. Wazuh undoes an action by running the same command in delete mode, so the firewall rule or deny entry created earlier is removed. A timeout value of zero means the action is permanent until handled manually.

Frequency is a parameter on the rule side that determines how many times an alert must appear within a given period before the action triggers. This prevents automatic actions from reacting to a single alert that might be noise, only acting on genuinely repeated patterns.

The combination of the two keeps the balance: frequency holds back the action until the pattern is clear, timeout ensures the action doesn't hang forever. For production environments, start with a short timeout and high frequency, then tighten as you understand your normal traffic profile.

#Rootcheck: Rootkit Detection

Moving to malware detection, the oldest and most fundamental component is rootcheck. Its job is to detect signs of rootkits and backdoors on the system. It runs on the agent and evaluates several categories: suspicious files, hidden processes, unusual kernel modules, and changes to credentials and listening ports.

Rootcheck compares inspection results against a signature database containing known rootkit patterns. Because it's signature-based, it excels at classic rootkits but can fall behind on newer techniques. Even so, its cost is low and its baseline value remains high for environments that don't yet have more advanced detection.

/var/ossec/bin/wazuh-control restart
/var/ossec/bin/rootcheck -s

Rootcheck results appear as high-level alerts in the rootcheck group. Alerts like this are rarely false positives, so once one appears, it deserves investigation as top priority. Rootcheck is still relevant today, but for more modern detection you'll rely on YARA and the malware scan module.

#YARA Integration

YARA is a pattern matching engine that's very popular in the threat hunting world. Through its integration with Wazuh, YARA is used as a scanner that checks specific files and registry areas against malware rules. YARA rules are written in a simple text format and can be updated without touching Wazuh code.

The first step is enabling the integration in the agent's ossec.conf by pointing to the YARA rules directory, then directing the scan to the directories or keys you want checked.

<ossec_config>
  <yara>
    <rules>/var/ossec/ruleset/rules/yara.rules</rules>
    <scan-on-start>yes</scan-on-start>
    <remove-old-scan>yes</remove-old-scan>
    <directories>c:\Users</directories>
    <registry>HKEY_LOCAL_MACHINE\Software</registry>
  </yara>
</ossec_config>

When a YARA rule matches a file, Wazuh creates an alert with the details of the matched rule name. This integration is very flexible because the threat intel community routinely shares YARA rules for the latest malware. You just add new rules to the rules file and the next scan will use them.

#The Malware Scan Module in Wazuh 4.10

Since Wazuh 4.10, the agent ships with a new malware scan module that complements traditional detection. This module offers on-demand and scheduled scanning, complete with the ability to quarantine infected files directly from the agent. Its design unifies what was previously separate: YARA detection and automatic response.

The key approach in this new module is the separation of policy and runtime: rule definitions are updated from the server, while the agent simply executes the scans. This model mimics how modern antivirus works, where the detection database is updated centrally without needing to replace the agent itself.

When choosing between rootcheck, classic YARA, and the malware scan module, remember that all three complement each other. Rootcheck catches signs already embedded in the system, YARA catches malware based on file and registry content, and the malware scan module provides response capabilities and more structured quarantine handling.

#Conclusion

This episode turns Wazuh from a passive observer into a guardian that can act. You understand that active response is an action trigger on the agent: block IPs via firewall drop, kill suspicious processes, and quarantine dangerous files, all orchestrated through the combination of timeout and frequency. On the detection side, rootcheck, YARA, and the malware scan module give you three overlapping layers that cover each other.

Key takeaways:

• Active response is split into a command list and trigger rules in ossec.conf.
• Agent actions include block IP, kill process, and quarantine file, with a local or server location.
• Timeout undoes automatic actions after the deadline; frequency prevents reactions to single alerts.
• Rootcheck detects signs of rootkits with a signature-based approach and low false positives.
• YARA integration matches files and registry against centrally updated malware rules.
• The Wazuh 4.10 malware scan module adds scheduled scanning and structured quarantine.

In episode 9 we enter the realm of post-install detection: Vulnerability Detection. We'll see how Wazuh compares installed packages against the CVE database, schedules scans, and presents all findings in the Vulnerabilities dashboard. See you there!