Wazuh and AI: Anomaly Detection and Event Correlation Explained

Modern security operations face a deluge of alerts from disparate sources, making it difficult to distinguish isolated noise from coordinated, multi-stage attacks. The challenge lies in moving beyond individual event analysis to understand the broader narrative of an intrusion. This article explains how an integrated monitoring system, built around the open-source Wazuh platform and augmented with artificial intelligence, can automate anomaly detection and event correlation. You will learn about the system’s architecture, how the AI model was trained and evaluated, the design of custom detection rules, and the methodology for linking discrete events into coherent attack chains for analyst review.

System Architecture and Data Flow

The lab system is built on a layered architecture that integrates multiple detection sources and analysis engines. At its core is the Wazuh stack, comprising a Manager for rule analysis, an Indexer for data storage, and a Dashboard for visualization. This is complemented by Suricata for network intrusion detection and a separate AI and Correlation Processor. The primary monitored endpoint was an Ubuntu virtual machine (IP 172.20.0.3) running the Wazuh agent, Suricata sensor, and various services. A Kali Linux machine (IP 172.20.0.4) served as the simulated attacker.

Data flows from endpoints to the central analysis hub. The Wazuh agent forwards system and application logs to the Wazuh Manager over an encrypted channel. Simultaneously, Suricata generates structured EVE JSON logs containing network flow records and alerts. A critical component is the AI and Correlation Processor, which runs natively on the host system. It ingests data, performs machine learning inference, and executes correlation logic, outputting standardized results that are fed back into the Wazuh Indexer for display alongside traditional alerts.

The FlowMLP AI Model for Network Traffic Classification

To augment signature-based detection, the system employs a custom AI model named FlowMLP—a supervised Multilayer Perceptron neural network built with PyTorch. Its purpose is to classify completed network flows into behavioral categories based purely on statistical features, providing an additional lens for identifying suspicious traffic patterns.

Model Design and Training

The model architecture is a feedforward network with 24 input neurons, two hidden layers (128 and 64 neurons), and a final output layer for 6 classes. It uses ReLU activation, a dropout rate of 0.1 for regularization, and contains a total of 11,846 trainable parameters. It was trained for 30 epochs using the AdamW optimizer with a learning rate of 0.001 and a batch size of 2048 on an NVIDIA GeForce RTX 4050 Laptop GPU.

The training data was primarily derived from the public CICIDS2017 dataset, supplemented with 384 lab-generated BENIGN traffic records to better reflect the test environment. The final prepared dataset contained 550,200 records. The model’s task is multi-class classification into the following six categories:

• 0: BENIGN
• 1: FTP-Patator
• 2: SSH-Patator
• 3: Bot
• 4: PortScan
• 5: DDoS (displayed as DoS)

Feature Engineering and Inference

The model’s 24 input features are carefully engineered statistical summaries extracted from Suricata flow records. They include transformed values for flow duration, packet and byte counts in each direction, average packet sizes, data rates, and protocol indicators. Key preprocessing steps involve a log1p transformation (log(1 + x)) for skewed values and setting a minimum duration floor of 0.001 seconds. Categorical features like application protocol and flow state are one-hot encoded. Notably, identifying information like IP addresses and port numbers is excluded from the feature vector; these are reserved for correlation purposes. Features are standardized using means and standard deviations calculated from the training set only.

For operational use, an alert threshold is calculated to convert the model’s multi-class probability output into a binary signal. The threshold (tau) is set at the empirical 99th percentile of the attack score on the BENIGN validation data, where the attack score is defined as 1 minus the probability of the BENIGN class. This aims to limit false positives while flagging anomalous flows.

Rule-Based Detection with Wazuh and Suricata

The system relies heavily on rule-based detection from Wazuh and Suricata as its foundational layer. Wazuh’s native rule set was extended with 30 custom rules (IDs 119200–119225 and 119250–119254) designed to detect specific behaviors observed in the lab. These rules have carefully assigned severity levels from 0 (ignored) to 15 (critical). For instance, rule 119204 for repeated password failures is set to level 10, while rules 119220 and 119222 for a verified reverse shell trigger the maximum level 15.

Suricata was configured with custom signatures to detect patterns like pure TCP SYN packets (SID 9900003), SQL injection attempts in URIs (SID 9900101, 9900102), and HTTP request pressure (SID 9900104). It is crucial to understand that these signatures match defined conditions—such as a specific packet flag or string pattern—but do not by themselves prove a successful scan or exploitation.

Detection Source	Rule/Alert Type	Example Purpose
Wazuh Custom Rules	Composite rules based on frequency, timeframe, and field matching	Detect 8 failed SSH auth attempts from the same source in 60 seconds (rule 119204).
Suricata Signatures	Signature-based network alerts	Flag TCP packets with only the SYN flag set (SID 9900003).
Custom Detectors (AI Processor)	Threshold-based logic on normalized data	Identify ≥20 distinct destination ports contacted in 10 seconds as ‘possible_recon’.

Custom Detectors and Behavioral Labeling

Beyond pre-built tools, the correlation engine uses a set of custom detectors that apply deterministic logic to normalized event data. These detectors generate specific behavioral labels that serve as the building blocks for attack chains. Each label has a defined threshold and is mapped, where applicable, to a MITRE ATT&CK technique.

For example, the repeated_auth_failures label is generated after observing 8 authentication failures within 60 seconds from the same source to the same destination and account, mapping to ATT&CK T1110.001 (Password Guessing). The observed_reverse_shell label requires verifying that a shell process has its standard input and output connected to the same TCP socket involved in an outbound connection, mapping to T1059.004 (Unix Shell). These labels preserve provenance, referencing original log fields like source IP, timestamps, and process IDs.

The Event Correlation and Chain Reconstruction Process

Correlation is the process that ties individual alerts and behavioral labels together into a coherent sequence, or “attack chain.” The system uses deterministic rules—not machine learning—for this step to ensure explainability. It groups related events into “episodes” based on common attributes like source IP, destination IP, and machine name. A new episode is started after 90 seconds of inactivity or if an episode lasts longer than 900 seconds.

Within an episode, events are linked into branches and then into a chain if they represent a logical progression of activity. The correlation logic looks for explicit relationships, such as shared flow IDs, process information, or account names; time proximity alone is insufficient. The system visualizes observed stages distinctly from hypothetical “next steps,” which are suggested from a pre-compiled table only after a chain is formed and has been quiet for at least 90 seconds. These suggested next stages are not counted as evidence or included in risk scoring.

Risk Scoring and Attack Chain Visualization

Each reconstructed attack chain is assigned a risk score to aid in prioritization. This score is a lab-defined operational metric, not a probability of successful compromise. It is calculated as the minimum of 95 or the sum of three components: the highest base score among its stages (R_base), a bonus for starting with a scan (B_scan=10), and a bonus for involving multiple independent behavior groups (B_diversity=5).

Stage base scores are predefined. For instance, possible_recon has a base score of 40, repeated_auth_failures is 65, auth_success_after_failures is 85, and observed_reverse_shell is 95. The final risk score translates into priority levels: Low (<40), Medium (40–69), High (≥70). A score of 95 is classified as Critical. In a test scenario, a chain involving Nmap reconnaissance and a SYN flood DoS achieved a risk score of 60 (Medium). Another chain involving reconnaissance followed by transfer of an EICAR test file—which VirusTotal reported as detected by 65 antivirus engines—received a score of 85 (High).

All results, including raw alerts, AI classification outputs, and fully reconstructed chains, are indexed and displayed in the Wazuh Dashboard. A dedicated Attack Chain view presents chains with their ID, source, destination, risk score, and observed stages, providing analysts with a high-level overview of potential campaigns.

Lab Testing and Observed Results

The system was validated through controlled experiments in the Docker-based lab. Specific attack scenarios were executed from the Kali Linux machine, and the resulting data flow and detection outputs were verified. For example, an Nmap scan triggering the custom detector for possible_recon (≥20 destination ports in 10 seconds) formed a single-stage chain with a base risk of 40. A multi-stage attack involving Nmap reconnaissance, Hydra brute-forcing, and the establishment of a reverse shell was successfully correlated into a single chain (ID: CHAIN-FC4E243C32C3631F) with a risk score of 95, triggering a critical Wazuh alert (level 15).

These tests demonstrated the integrated workflow: endpoint and network data collection, dual detection via rules and AI, normalization, correlation based on shared attributes, and final visualization. It’s important to remember that all such lab work should be conducted only within authorized, isolated environments to prevent any risk to production systems.

Key Takeaways

• Defense-in-Depth through Integration: Combining rule-based detection (Wazuh, Suricata), AI-based behavioral classification (FlowMLP), and deterministic correlation creates a more robust monitoring system than any single approach alone.
• Correlation Transforms Alerts into Insight: Isolated alerts are of limited value; linking them across time, source, and context into attack chains is essential for understanding multi-stage threats and assessing true risk.
• Maintain Data Provenance and Explainability: The system strictly separates raw evidence, detection alerts, AI inferences, and correlation hypotheses. This traceability is critical for analyst verification and trust, especially when using AI components.
• AI Augments, Does Not Replace: The FlowMLP model, with its 24 features and 11,846 parameters, provides a valuable anomaly detection signal on network flows but is treated as one piece of evidence alongside rules and logs, not as definitive proof.
• Controlled Labs Enable Safe Validation: Using Docker and virtual machines allows for the safe construction, testing, and refinement of monitoring pipelines and correlation logic without impacting live environments.

Related reading: From Alerts to Kill Chains: Reconstructing Multi-Step Attacks in a Wazuh Lab

Frequently Asked Questions

About the author