Views: 5

Introduction

The Wazuh Agent

At the heart of every monitored endpoint sits the Wazuh agent — a lightweight, cross-platform component that acts as your eyes and ears on the systems you care about. Once deployed, it establishes an encrypted, authenticated connection to the Wazuh server and streams data back in near real-time, giving you continuous visibility without exposing that traffic to tampering or interception.

Performance was a core design constraint from the start. Wazuh needed an agent that could sit on everything from a single workstation to thousands of servers without dragging down system resources. The result runs across all major operating systems and averages just 35 MB of RAM — light enough to deploy broadly without a second thought.

What the Agent Actually Does

The agent isn’t just a log shipper — it’s a multi-purpose security sensor bundling several capabilities into one lightweight package:

• Log collection — gathers logs from across the system for centralized analysis
• Command execution — runs commands and captures their output for monitoring or response
• File integrity monitoring (FIM) — flags unauthorized changes to critical files and directories
• Security configuration assessment (SCA) — checks system configurations against security baselines
• System inventory — maintains an up-to-date picture of installed software, hardware, and running processes
• Malware detection — identifies indicators of known malicious activity
• Active response — takes automated action when threats are detected
• Container security — extends visibility into containerized workloads
• Cloud security — monitors cloud-based infrastructure and services

Getting an Agent Installed

Installation is operating-system specific, so the first step is simply picking your platform and following the corresponding setup instructions.

One compatibility note worth keeping in mind: the Wazuh manager should always be running a version equal to or newer than the agents connecting to it. Running an agent ahead of the manager isn’t a supported configuration.

If you’d rather skip the manual route entirely, the Wazuh dashboard offers a guided path — head to Agents management > Summary and click Deploy new agent to walk through the process interactively.

Then follow the steps on the Wazuh dashboard to deploy a new agent.

Exploring Wazuh: A Tour of the Capabilities Under the Hood

If you’ve spent any time in the Wazuh dashboard, you’ve probably noticed the endpoint view has more depth than it first lets on. Click into an agent, and beyond the obvious tabs sits a “More…” menu that quietly reveals just how much ground Wazuh actually covers — four categories, each bundling a set of capabilities that could be its own product in a lesser platform: Endpoint Security, Threat Intelligence, Security Operations, and Cloud Security.

This post is a walk through that menu, module by module — what each capability actually does, how it works under the hood, and where it fits into a real detection and response workflow.

Endpoint Security

File Integrity Monitoring (FIM)

FIM is one of those features that sounds simple on paper — “tell me when a file changes” — but gets genuinely interesting once you look at how it’s implemented.

At its core, the FIM module (internally, syscheckd) maintains a baseline database of the files and directories you’ve told it to watch. On Linux, this is typically driven by real-time monitoring through inotify, giving near-instant detection of changes. On Windows, it hooks into the USN Journal or falls back to periodic scanning depending on configuration. Either way, the agent isn’t just noting that a file changed — it’s recording a full before-and-after picture: permissions, ownership, size, and a cryptographic hash (MD5, SHA1, and SHA256 by default) of the content itself.

That hash matters more than it might seem. A timestamp change or a permissions tweak is one thing; a content hash mismatch is what tells you the actual bytes of a file were altered — which is exactly the signal you want when you’re hunting for a tampered binary, a modified authorized_keys file, or a webshell dropped into a directory that should never write new files.

FIM events flow back to the manager and land in analysisd for rule evaluation, which is what lets you go beyond “file changed” alerts and build real detection logic — flagging changes to /etc/passwd outside a maintenance window, or a new executable appearing in a startup folder, as high-severity events rather than routine noise.

Malware Detection

Wazuh’s malware detection isn’t a traditional signature-based AV engine — that’s a deliberate design choice, not a gap. Instead, it leans on rootcheck, a component that looks for the behavioral fingerprints of compromise: hidden processes, unusual file permissions, known rootkit file signatures, and system call anomalies that suggest something is actively trying to hide itself from the OS.

This pairs naturally with FIM and log analysis — a rootkit that hides its files from ls won’t hide them from a hash comparison against a known-good baseline, and a process trying to conceal itself in ps output often leaves other traces (open sockets, loaded kernel modules) that rootcheck is specifically looking for.

Configuration Assessment (SCA)

Security Configuration Assessment is Wazuh’s answer to “is this system actually configured securely, not just monitored.” It runs policy checks against industry hardening benchmarks — most notably the CIS Benchmarks — evaluating things like password policy settings, unnecessary running services, filesystem permissions, and insecure default configurations.

Each check is defined in a YAML policy file with a rule, a condition, and a remediation description, which the agent evaluates locally and reports back as pass/fail. The practical value here is that SCA turns “we should be CIS-compliant” from an annual audit exercise into something you can see drift on continuously — a system passes its CIS check today, a config change breaks compliance next week, and you find out from a dashboard instead of from an auditor.

Threat Intelligence

Threat Hunting

The Threat Hunting view is less a distinct engine and more a purpose-built lens over everything else Wazuh is already collecting — logs, FIM events, SCA results, inventory — surfaced through a search interface built for iterative investigation rather than passive alert review. This is where you go from “an alert fired” to “let me pivot across every event tied to this host, this user, or this process ID over the last 24 hours.”

It’s worth pairing conceptually with what we covered in the last post: this is the human layer sitting on top of analysisd‘s automated correlation — the place where an analyst does the pattern-matching a rule set hasn’t been written for yet.

Vulnerability Detection

Wazuh’s vulnerability module works by inventorying installed software and OS packages on each agent, then cross-referencing that inventory against vulnerability feeds — including the National Vulnerability Database (NVD) and vendor-specific feeds (Red Hat, Debian, Canonical, and others depending on OS).

The important nuance here: this is a known-CVE-matching engine, not an active vulnerability scanner. It’s not sending exploit payloads at your endpoints; it’s comparing “you have OpenSSL 1.1.1k installed” against “OpenSSL 1.1.1k has these published CVEs” and surfacing the match with severity scoring. That makes it lightweight and safe to run continuously, but it also means it’s only as good as the software inventory feeding it — which is why this module leans directly on the System Inventory data the agent already collects.

MITRE ATT&CK

Rather than being a standalone detection engine, this is Wazuh’s mapping layer — rules and alerts are tagged against MITRE ATT&CK tactics and techniques, and the dashboard aggregates those tags into the framework’s familiar matrix view.

For a detection engineering workflow like the one you’re building, this is genuinely useful beyond the pretty visualization: it gives you a fast answer to “which techniques do I have real coverage for, versus which ones I’m just hoping a generic rule catches.” A LOLBAS technique like certutil.exe misuse maps to T1105 (Ingress Tool Transfer) or T1140 (Deobfuscate/Decode Files) depending on how it’s used — and having that mapping live in the platform, not just in your documentation, closes the loop between what you’ve built and how it’s categorized.

Security Operations

IT Hygiene

IT Hygiene is inventory-as-a-security-control. It aggregates what’s installed, what’s running, what ports are open, and what users exist across your fleet — not to alert on any single event, but to answer the unglamorous but critical question: do we actually know what’s on our network?

This sounds basic, but it’s the foundation everything else depends on. Vulnerability Detection can’t tell you about unpatched software it doesn’t know exists. SCA can’t assess a configuration on a system that isn’t inventoried. IT Hygiene is the quiet dependency underneath the more exciting modules.

Compliance Mapping — PCI DSS, GDPR, HIPAA, NIST 800-53, TSC

These aren’t separate detection engines — they’re compliance overlays. Wazuh maps its existing rules, SCA checks, and alerts to the specific controls required by each framework:

• PCI DSS — cardholder data environment controls: logging, FIM on payment systems, access control monitoring
• GDPR — data protection–relevant events: unauthorized access to personal data, retention violations
• HIPAA — safeguards over electronic protected health information (ePHI)
• NIST 800-53 — the broad federal control catalog, mapped at the individual control level
• TSC (Trust Services Criteria) — the control set behind SOC 2 reporting

The practical benefit is auditor-facing: instead of manually proving “we log access to sensitive files” for four different frameworks separately, you configure the control once and Wazuh shows you which compliance requirements that same piece of telemetry already satisfies.

Cloud Security

Wazuh extends the same agent-based philosophy into cloud and SaaS platforms — though here it shifts from endpoint agents to API-based, agentless integrations pulling telemetry directly from provider control planes:

• AWS — ingests CloudTrail, GuardDuty, and Config data, extending FIM-like thinking to S3 bucket policy changes, IAM modifications, and security group changes
• Google Cloud — pulls from Cloud Audit Logs for equivalent visibility into GCP resource and IAM changes
• GitHub — monitors organization-level audit logs: repository access changes, permission escalations, and suspicious authentication events
• Office 365 / Microsoft Graph API — surfaces mailbox access anomalies, conditional access policy changes, and Entra ID (Azure AD) sign-in and audit events

The architectural shift matters: these integrations run as manager-side modules polling provider APIs on a schedule, not as agents installed on infrastructure you don’t control. It’s the same detection philosophy — collect, correlate, alert — applied to a control plane instead of an OS.

Why This Matters as a Whole

Looking at these four categories together, a pattern emerges: Wazuh isn’t really four products stapled together. It’s one telemetry and correlation pipeline — the same analysisd engine, the same rule and decoder architecture we covered last post — with different collectors feeding into it depending on what you’re watching: a file on disk, a package version, a cloud API log, or a compliance control.

That’s the real value of understanding this menu in depth. When you’re building detections, the question stops being “which Wazuh tool do I use” and becomes “what telemetry do I need, and which collector already gets it to the same place everything else lands.”