Linking Windows Events into Attack Chains with Wazuh, Vector and a Behavior Model

Security teams face a constant deluge of alerts, each a potential piece of a larger puzzle. The challenge lies in connecting these isolated, often low-fidelity signals to reconstruct an adversary’s multi-stage attack. This article explores a defensive system designed to automate this correlation, built on the open-source Wazuh platform. You will learn how it ingests Windows event logs via Vector, scores each event using a supervised machine learning model, and links them into coherent attack chains based on process lineage and MITRE ATT&CK tactics. We’ll cover the architecture, the explainable behavior model, the fault-tolerant log pipeline, and how the resulting high-context alerts are surfaced for analyst review and response.

Architecture: From Raw Logs to Actionable Chains

The system’s core data flow is designed for resilience and clarity. A Wazuh agent on a Windows host forwards logs from nine key channels—including Security, Sysmon, PowerShell, and Task Scheduler—to a central Wazuh server. Crucially, the server is configured to write every raw event to a persistent archives.json file. This becomes the single source of truth for two independent processing pipelines managed by Vector.

Vector, acting as a robust observability pipeline, reads this file with two separate configurations. The first pipeline archives the raw logs into an Elasticsearch index for long-term storage and reference. The second, more critical pipeline batches the logs and sends them via HTTP to a dedicated analysis service. This service performs normalization, feature extraction, and scoring using a pre-trained machine learning model. Flagged events are then fed into a correlator module that groups them by process tree. When a chain meets specific criteria—containing at least one high-confidence alert and evidence of at least three distinct ATT&CK tactics—an attack chain alert is generated. These alerts are written to a local file, which custom Wazuh rules pick up and display in the standard dashboard, integrating seamlessly into the existing SOC workflow.

Event-to-chain flow: Linking Windows Events into Attack Chains with Wazuh, Vector and a Behavior Model — Event-to-chain flow (simplified)

The WAD Behavior Model: Scoring and Explainability

At the heart of the detection capability is the Windows Anomaly Detection (WAD) model, a two-tier supervised logistic regression classifier. Trained on over 550,000 events from public attack simulation datasets, its first tier outputs a probability that a given log event is malicious. A two-threshold system is applied: events with a probability of 0.5 or higher are classified as high-confidence alerts (da_bao), while those between 0.3 and 0.5 are marked as suspicious (nghi_ngo). Only events crossing the lower threshold proceed to the second tier, which assigns one of eight MITRE ATT&CK tactics (Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Command and Control).

The model’s strength lies in its explainable, additive design. Each event is transformed into a 60,981-dimensional feature vector combining:

Categorical Encodings (578 dims): Event properties like provider, event ID, and image class.
Numerical & Behavioral Flags (52 dims): Includes command length, entropy, and 47 pre-defined behavioral indicators (e.g., f_encoded for encoded commands, b_lsass_target).
Text Features (60,000 dims): TF-IDF on character n-grams from command lines, PowerShell script blocks, and object paths.
Sigma Rule Features (351 dims): Tokens from Sigma rule titles and mapped ATT&CK tactics.

The final score is a sum of weighted feature contributions, allowing analysts to understand why an event was flagged. For example, a high score might be driven by a combination of features like img_class_shell, f_encoded, and a Sigma rule match for defense evasion. This transparency supports trust and faster triage.

Process-Tree-Based Correlation Logic

Isolated event scoring is valuable, but real attacks unfold as sequences. The correlator module addresses this by grouping flagged events (da_bao and nghi_ngo) based on process lineage. It primarily uses Sysmon’s ProcessGuid and ParentProcessGuid fields to build a graph. For Security event 4688 (process creation) which lacks GUIDs, it performs a lookup using Process ID (PID) and Parent PID within a configurable time window, merging these nodes into the main ProcessGuid tree.

An attack chain, or “incident,” is formally triggered when the events within a single process tree meet two conditions: 1) There is at least one da_bao (high-confidence) event, and 2) The flagged events (excluding those labeled unknown) cover at least three distinct ATT&CK tactics. This tactic diversity requirement helps filter out noisy, single-behavior false positives. The chain is assigned a score that sums the maximum malicious probability per observed tactic, with a bonus added if the tactics appear in a logical order (e.g., Execution before Discovery). This logic effectively reconstructs the Cyber Kill Chain stages from ATT&CK tactic labels.

Fault-Tolerant Log Pipeline with Vector

To ensure no attack evidence is lost during system hiccups, the log ingestion pipeline is built for resilience. Vector is configured with disk-backed buffers, creating a write-ahead log that survives service restarts. The pipeline sending logs to the analysis service uses small batches (max 10 events or 1 second) for low latency and includes retry logic with exponential backoff. The analysis service itself employs an idempotent design: each log event is assigned a unique ID based on a hash of its source agent, channel, record ID, and timestamp. This allows safe retries and enables a reconciliation job that periodically compares raw and processed log stores, re-ingesting any missing events to prevent gaps in attack chains.

Pipeline	Target	Batch Size	Buffer	Purpose
R (Raw)	`chain-raw-*` index	100 events / 2 sec	Disk	Long-term raw log archive
G (Scoring)	`http://127.0.0.1:8901/v1/events`	10 events / 1 sec	Disk	Near-real-time analysis & scoring

Alerting, Visualization, and Response Integration

When an attack chain is formed, the service writes a structured JSON alert to a local file. Custom Wazuh rules (IDs 112001 and 112002) monitor this file and generate level 13 alerts visible in the Wazuh dashboard. Simultaneously, a dedicated web interface provides a dynamic, visual representation of active chains, updating every few seconds. This interface allows analysts to drill down into the chain’s process tree, view extracted Indicators of Compromise (IOCs) like IP addresses and file hashes, and mark false positives for feedback.

The system also includes a response module. For chains containing malicious IOCs, it can propose blocking associated IP addresses on a network perimeter firewall like pfSense. This action is governed by configurable automation levels: fully automatic, requiring operator approval, or dry-run only. Critical safeguards are implemented, including a “never-block” list for internal infrastructure and a Time-To-Live (TTL) for automatic blocks to prevent permanent network issues.

Performance and Defensive Value

In lab evaluations using the cross-validation (cv) method on training data, the binary detection layer achieved a recall of 94.2% and a precision of 84.4%, with a false positive rate of 3.49% on benign events. The tactic classification layer showed a macro-F1 score of 0.696, with performance varying by tactic. The fault tolerance mechanisms proved effective in tests, recovering from indexer outages and service restarts with zero logs permanently lost. In a simulated attack using the Caldera framework, the system successfully grouped 11 malicious execution events into two distinct attack chains based on separate agent processes, generating clear Wazuh alerts within seconds.

System Limitations and Considerations

While powerful, the system has defined boundaries that practitioners must understand. Its correlation is limited to a single host; it cannot natively link activities across multiple machines to show lateral movement. The model predicts only ATT&CK tactics, not specific techniques, and does not cover the Collection and Exfiltration tactics. Detection efficacy is entirely dependent on the quality and completeness of Windows logging; missing Sysmon events or disabled audit policies will create blind spots. The response automation is focused on network IP blocking and does not perform endpoint remediation. Finally, the model’s performance on completely unseen, discrete EVTX files was lower, indicating a need for ongoing tuning with diverse data. All lab work of this nature should be conducted only in authorized, isolated environments to prevent unintended impact.

Key Takeaways

Context Over Alerts: The system reduces alert fatigue by correlating isolated events into multi-tactic attack chains based on process trees, providing analysts with a holistic narrative of an intrusion.
Explainable ML for Trust: Using a linear model with interpretable feature contributions allows security operators to understand the rationale behind each alert, speeding up validation and investigation.
Resilient Data Flow: A dual-pipeline design with Vector, disk buffering, idempotent writes, and reconciliation ensures log processing continues through failures, aiming for zero evidence loss.
Seamless SIEM Integration: By outputting to a local file read by custom Wazuh rules, the system surfaces high-fidelity attack chains within an existing, familiar dashboard without complex API integrations.
Guarded Automation: Response actions like IP blocking are designed with mandatory safeguards—approval workflows, never-block lists, and TTLs—to prevent automated actions from disrupting business operations.

Frequently Asked Questions

How does this system differ from Wazuh’s built-in correlation?

Wazuh’s native correlation is primarily based on counting repetitions of the same rule firing. This system introduces a more sophisticated model, grouping events by process lineage (using ProcessGuid and PID) and requiring diversity in MITRE ATTu0026amp;CK tactics within that tree. It also incorporates machine learning confidence scores and considers the logical order of tactics, providing context that simple rule frequency cannot.

What are the most important Windows logs to enable for this to work?

The system is designed to analyze nine channels, but two are particularly critical: the Security log (especially event ID 4688 with command line auditing enabled) and the Sysmon operational log (for events like 1-process creation, 3-network connection, and 11-file creation). PowerShell Script Block Logging and Task Scheduler logs also provide invaluable context for detecting post-exploitation behaviors.

Can the model be retrained with my organization’s own data?

The architecture supports model updates, but the process requires careful curation of labeled training data. The existing model was trained on public attack simulation datasets using a specific feature engineering pipeline. Retraining effectively would necessitate generating similar feature vectors from internal logs labeled with ATTu0026amp;CK tactics, a non-trivial task that demands significant security expertise and data science resources.

Why use logistic regression instead of a more complex AI model?

Logistic regression was chosen for its interpretability, speed, and performance on high-dimensional, sparse data (where most feature values are zero). The coefficients directly show how much each feature (like a specific event ID or behavioral flag) contributes to the malicious score. This transparency is vital for SOC analysts who need to trust and understand automated alerts. Tests showed more complex models like gradient-boosted trees performed worse on the tactic classification task with this feature set.

About the author

admin

admin writes reviews and buying guides for CyberSecLabs.