Reference

Daemons

Normalization engine modules

The modules of the Wazuh normalization engine work together to transform raw events into structured and enriched security data. Each module is responsible for a specific stage of the event processing pipeline, including event reception, decoding, normalization, enrichment, and output generation. This modular architecture constitutes a unified event processing workflow.

Server

The Server module includes two HTTP servers. The events socket receives raw events from the Remoted module or the Vulnerability Detector module. The management API socket exposes operations that internal client dev tools and other Wazuh manager components use. These operations include managing routes, running tester sessions, applying content changes, querying GeoIP and IOC state, toggling raw event indexing, and reading metrics. Both sockets use HTTP with JSON bodies. Protocol buffers (protobuf) define the schema for every request and response.

Orchestrator

The Orchestrator is the runtime hub of the Wazuh normalization engine. It owns the routes table that maps each space to the active security policy and the priority at which events are evaluated, plus the session table used by the tester. When an event arrives, the Orchestrator forwards an independent copy to each active policy, allowing a single incoming event to produce multiple output documents, one for each active policy. Routes can be added, replaced, or removed at runtime without restarting the normalization engine, which is what makes hot-swapping of synchronized content possible.

Builder

The Builder turns the declarative content stored in the Engine Content Manager into an executable graph that the Backend can run. It validates field types against the Schema, resolves variables and definitions, and links every helper function used in check, parse, and normalize stages. The Engine Content Manager calls the Builder whenever content changes allowing the Orchestrator to register the resulting graph as a route.

Backend

The Backend is the runtime that executes the compiled graph for every event. It goes through the stages described in event policy processing: pre-filter, decoders (including KVDB lookups), enrichment (Geo and IOC), post-filter, and outputs.

Engine Content Manager

This is the local mirror of the content managed in the Wazuh indexer. It is organized by spaces. The Engine Content Manager has three responsibilities:

• Storage of decoders, filters, KVDBs, integrations, and policies on the normalization engine endpoint.

• Synchronization with the Wazuh indexer (CMSync), which periodically compares per-space content hashes and pulls the full content when they differ.

• CRUD which validates and applies any mutations issued through the management API.

After every applied change, the Engine Content Manager hands the affected policies to the Builder and asks the Orchestrator to swap the corresponding routes.

Schema

The Schema module loads the Wazuh Common Schema (WCS) document at startup and exposes it to the Builder for build-time field validation and to the Backend for runtime validation of dynamic values. It guarantees that every document the engine emits is type-consistent with the mappings configured in the Wazuh indexer.

KVDB

Per-space key-value databases that decoders and filters consult during event processing, for example, mapping identifiers to canonical names or merging default values into events. Regular KVDBs are part of the per-space content which are synchronized along with the rest of the space's assets and rebuilt on the normalization engine when their source changes.

IOC

Indicators of compromise databases are used at the IOC enrichment stage to match fields in incoming events against threat intelligence. These databases are shared across spaces and are independent of the regular content sync. They are kept up to date by a dedicated IOC synchronizer that downloads updates into a temporary database and then atomically swaps it in, so readers never observe a partially updated database.

Geo

The Geo module performs GeoIP and ASN lookups using MaxMind MMDB databases. Like the IOC databases, the Geo databases are global rather than per-space. They are refreshed in the background and hot-reloaded without restarting the Wazuh normalization engine. Refer to the Geo enrichment section of the documentation for more information.

Indexer connector

The indexer connector is the single component that communicates with the Wazuh indexer. It manages three traffic flows: outbound processed events (driven by policy outputs), inbound content (consumed by the Engine Content Manager and the IOC synchronizer), and inbound runtime configuration (consumed by the Configuration module). Concentrating all Wazuh indexer traffic in one place is what allows the rest of the normalization engine to stay independent of the Wazuh indexer transport details.

Stream Log

Stream Log provides asynchronous, rotating log channels with size-based and time-based rotation, gzip compression, and retention by file count and total size. It backs the file outputs that policies can configure, and it is also what the optional event dumper uses to persist raw events for forensic investigation. Hot-path writes never block on disk I/O.

Configuration

The local configuration is loaded from the Wazuh manager XML/ini at startup, allowing every module to read from it. A subset of runtime parameters is also pulled periodically from the Wazuh indexer as remote configuration, so operators can tune behavior without restarting the engine. Remote configuration changes are applied with rollback if a module rejects the new values.

Shared libraries

The table below lists the shared libraries provided by the Wazuh manager, their roles, and the components that use them.

CLI tools

The Wazuh manager provides a set of command-line interface (CLI) tools for managing, monitoring, and troubleshooting its components. The table below lists the available CLI tools and their purposes within the Wazuh manager.