Last updated: August 13, 2026 · Reading time: 7–9 minutes
What exactly can Wazuh do? In this article, Leander explains how the open-source security platform processes events, what modules it includes, and how these elements come together in typical everyday scenarios. In the first part of this blog series, he provided a general overview of what Wazuh is and what it’s used for. This second part is about getting a feel for what Wazuh can do and developing a technical understanding of how it works.
The Most Important Points in 30 Seconds
- Wazuh processes events through the following chain: Logs → Decoder → Rules → Alert or Archive; an event only becomes an alert with a log level once a rule is matched.
- Core modules include File Integrity Monitoring, Security Configuration Assessment, Logcollector, Syscollector, Vulnerability Detector, Active Response, and cloud modules for AWS, Azure, and Google Cloud.
- Through Active Response, Wazuh not only triggers an alert in the dashboard, but can also automatically run scripts—for example, to block an attacking IP address via a firewall rule.
How Wazuh Processes Events
Before looking at the individual features, it helps to take a look at how Wazuh processes events. In short, here’s how it works: Logs → Decoder → Rules → Alerts or Archive. I’ll go into this in a little more detail below.
On the monitored systems, the Wazuh agent collects the data using its various modules. This data is sent to the Wazuh Manager, which first converts it into a standardized format. This is usually referred to as the normalization of log data. This is exactly where decoders come into play: They “understand” the structure of the incoming logs (such as Syslog, SSH logs, and web server logs) and break them down into fields such as timestamp, source, user, action, etc.
Wazuh then applies rules to the decoded events. Regular expressions are used for filtering in both the rules and the decoder. These rules define what is considered normal, suspicious, or critical—for example, “multiple failed login attempts within a short period of time” or “a change to a sensitive configuration file.” If an event matches a rule, it is assigned a level (a type of severity) and becomes an alert. If no rule applies, the event is archived. By default, archived events are stored only at the file level and are not sent to the Wazuh Indexer. You can set up a redirect to the Wazuh Indexer. This approach sets Wazuh apart from traditional log management solutions. So, an alert is essentially just an event where a rule has been triggered and a log level has been assigned to it.
Alerts are displayed graphically in the Wazuh dashboard. There are pre-built dashboards available for this, and you can also create your own. Alerts, in turn, can trigger notifications—for example, via email—so that the security team is immediately notified of incidents that reach a certain severity level. So-called “Active Responses ” can also be triggered; these then execute predefined scripts to actively resolve the security issue.
An Overview of Wazuh Modules
Now that we understand how Wazuh works, I’d like to introduce Wazuh’s most important modules and features here.
These ensure that you can begin the security analysis very quickly by providing capabilities, decoders, and rules. This already covers many typical requirements.
Below, I’ll briefly introduce you to the most important modules and provide a short practical example for each one.
File Integrity Monitoring (FIM)
File Integrity Monitoring monitors files and directories for changes. To do this, Wazuh calculates checksums (hashes) of important files—such as configuration files, system binaries, or scripts—and records their status. If something changes, Wazuh detects it and generates a corresponding event. A typical use case is monitoring /etc on Linux servers or critical application configuration directories. This way, you can quickly see if someone has unexpectedly changed an SSH configuration, a web server configuration, or an important script.
Security Configuration Assessment (SCA)
With Security Configuration Assessment, Wazuh checks whether systems comply with specific security policies. The checks are defined in YAML policies, for example, based on CIS benchmarks or other hardening guidelines. The agent compares the system’s current state—such as password policies, exposed services, and permissions—with the defined requirements and reports any discrepancies. This makes it quite easy to determine whether, for example, a Linux server meets the desired minimum hardening standard. A specific use case would be an environment in which you want to check all Linux servers against a set of CIS-like guidelines without having to access each system individually.
Log Collector Module
The Logcollector module handles the collection of logs on the agent. It reads log files (e.g., in /var/log), can process Journald entries, and, on Windows, retrieves events from the Event Viewer. On the server side, Wazuh can also directly receive syslog messages, for example, from firewalls, switches, or other devices. The Log Collector thus serves as a “gateway” for a wide variety of sources—whether traditional server logs, network devices, or specialized appliances. In practice, this means you have a central hub where everything comes together.
Command Module
The Command module allows you to execute defined commands on the agent and send their output to the server. These could include, for example, ` ps`, ` netstat `, or other diagnostic commands. It gets interesting when you have certain commands run on a regular basis or in response to specific events to gather additional information. Here’s an example: If a suspicious network connection is detected, you can automatically run netstat to get context on which process is behind it.
Syscollector Module
The Syscollector module collects inventory and configuration information from the respective agent. This includes, among other things, installed packages, running processes, open ports, network interfaces, and certain hardware information.
This provides the server with a centralized overview of which software versions are running on which systems, which services are active, and how the environment changes over time. This is exciting not only for security, but also for traditional asset and patch management.
Vulnerability Detector
The Vulnerability Detector scans the software installed on a system for known vulnerabilities. To do this, Wazuh uses various feeds, such as the NVD or distribution-specific databases from Red Hat, Debian, and others.
In practice, it works like this: The agent reports which packages and versions are installed; the Vulnerability Detector compares this information with the CVE databases and generates alerts if known vulnerabilities are found. This will give you an initial overview of which systems urgently need patches.
Want to set up Wazuh in your area?
Our consultants take Wazuh from the pilot environment through to production, including integration with existing monitoring and alerting processes.
Get advice now →
Active Response
With Active Response, Wazuh can automatically respond to specific events. The module runs scripts on monitored endpoints when an alert is triggered with a specific rule ID, a specific severity level, or from a specific rule group.
A typical example is handling SSH brute-force attacks: If Wazuh detects an unusually high number of failed login attempts from a single IP address based on its rules, a script can be automatically triggered to create a firewall rule and block that IP address. In this way, mere recognition immediately leads to taking countermeasures.
Cloud Modules
In addition to traditional on-premises systems, Wazuh can also analyze events from cloud environments. There are integrations for AWS, Azure, and Google Cloud that collect and analyze logs and events from cloud services and instances.
This allows, for example, IAM changes, API calls, or security-related events from cloud workloads to be integrated into the same monitoring system as on-premises servers. This is becoming increasingly important for many environments that are moving toward a hybrid model.
Specific Use Cases from Everyday Life
To wrap things up, here are a few examples of how these building blocks might work in practice.
1. Detect and automatically block SSH brute-force attacks
Imagine you’re running several Linux servers with publicly accessible SSH. Automated scans and brute-force attacks are regularly launched against these hosts. The Wazuh agent collects the SSH logs; decoders and rules detect suspicious login patterns, such as numerous failed login attempts from the same IP address within a short period of time.
Wazuh not only generates an alert in the dashboard, but also uses Active Response to trigger a script that blocks the attacking IP address via a firewall rule. You can see what happened in the dashboard, and at the same time, the attack is actively being contained without you having to intervene manually.
2. Overview of Configuration and Compliance Status
Many companies have guidelines regarding how a server should “look. “ Password policies, logging settings, disabled services, etc. With SCA, you can define (or use existing policies) how a system should be configured. The agent regularly checks the current status and reports any discrepancies.
Together with Syscollector, this provides a pretty clear picture: Which servers comply with the policy, where are there vulnerabilities, and where might old services still be running? You can use this information for audits or certifications to demonstrate that you regularly test your systems against defined standards.
3. Identify vulnerabilities in your own portfolio
Suppose you manage a mix of Linux and Windows systems running a wide variety of applications. A critical CVE for a widely used library or web framework pops up somewhere. Instead of painstakingly figuring out by hand which systems might be affected, use the Vulnerability Detector.
The module compares the inventory data from Syscollector with the vulnerability feeds and shows you exactly where the vulnerable versions are running. You can prioritize your patching activities and see afterward if and where the vulnerability is still open.
These examples should give you a better idea of what Wazuh can actually do in everyday use, from log collection to the assessment of security events to automated responses. In future installments of the series, we could then delve deeper into individual modules or typical architectural setups—such as how to set up a pilot environment or integrate Wazuh into existing monitoring landscapes.
