Deploying Wazuh SIEM/XDR: A Hands-On Walkthrough Using a Simulated Breach

When I set out to evaluate a security monitoring platform, I didn’t want to just read the marketing page and call it a day. I wanted to stand one up, point it at a machine, and see whether it would actually catch an attacker doing attacker things. So I built a scenario, a fictional medical-supply distributor called MedSecure Logistics that got breached. and used it as a target to test Wazuh end to end.

This post walks through that build: what Wazuh is, how I deployed it on the cloud, how I enrolled an agent, and what each of its core modules surfaced when I turned them loose. If you’ve been meaning to get hands-on with a SIEM but found the enterprise options either too expensive or too heavy to spin up, this is the gentle-but-real introduction I wish I’d had.

What Wazuh Actually Is (and the SIEM vs XDR distinction)

Wazuh is a free, open-source security platform that combines two things that used to be sold separately: SIEM (Security Information and Event Management) and XDR (Extended Detection and Response). It was originally forked from OSSEC back in 2015, is maintained by Wazuh Inc. and a global open-source community, and has racked up more than 20 million downloads.

A quick analogy before we go further, because these two acronyms confuse a lot of people:

• Think of a classic SIEM as a security guard sitting in a room full of CCTV monitors. Every camera (server, firewall, workstation) streams footage in, and the guard’s job is to watch the feeds and shout if something looks wrong. It’s centralized visibility, but it’s fundamentally passive. It aggregates and correlates logs that other systems send it.
• XDR is what happens when you give that guard the ability to walk up to a door and lock it. Instead of only watching, lightweight agents sit directly on each endpoint, so the platform can inspect what’s happening on the machine itself and react.

Wazuh does both. That distinction matters enormously for incident response, because the single most important number in a breach is dwell time; how long an attacker sits inside your network before you notice. A platform that only watches logs after the fact reduces dwell time far less than one that’s inspecting the endpoint in real time and can act. In the MedSecure scenario, the attacker went undetected for three weeks; the entire point of this evaluation was to see how much of that Wazuh would have collapsed.

For the test, I deployed Wazuh on the cloud-hosted environment (version 4.14.4) with agents on several Linux, Windows, and macOS endpoints, plus one Ubuntu 22.04 LTS box set aside specifically as the simulated MedSecure workstation.

Step 1: Deployment and Configuration

I used the cloud-hosted trial at cloud.wazuh.com. The nice thing about the cloud route is that it hands you a fully managed instance with the three core components already wired together:

Going cloud removes all the infrastructure plumbing while giving you the same functionality as a self-hosted install — which is exactly what you want when the goal is learning the platform, not learning to babysit servers.

Enrolling the first agent

Agent deployment runs through a guided workflow in the dashboard. For my Ubuntu 22.04 LTS ARM64 virtual machine, the steps were:

1. Choose the matching package (DEB aarch64 for this ARM64 box).
2. Enter the cloud manager’s address.
3. Select the default password.
4. Name the agent medsecure-endpoint so it was obvious which box it was in the scenario.

The dashboard generates an install command, you run it on the endpoint, and within a few seconds of the service starting, the agent registers with the manager. As soon as enrollment succeeded, the endpoint auto-populated with inventory data. CPU cores, 8.6 GB of memory, hostname, OS, the works.

Then came the first genuinely eye-opening moment. Within minutes of connecting, Wazuh’s first scan flagged:

• 148 critical vulnerabilities
• 1,731 high-severity vulnerabilities
• 4,197 medium-severity vulnerabilities

No manual tuning, no rule-writing; the platform builds a security baseline for you the moment an agent checks in. If you’ve ever wondered “where do I even start hardening this machine,” Wazuh answers that for you before your coffee gets cold.

A crucial config tweak: File Integrity Monitoring

One setting deserves special attention because it becomes a plot point later. File Integrity Monitoring (FIM) watches directories and tells you when files are created, changed, or deleted. Out of the box, Wazuh scans on a 43,200-second cycle. That’s 12 hours.

For the demo I edited the agent’s ossec.conf and dropped that scan time down to 60 seconds so I could watch file changes appear in near real-time. The /etc/ directory is monitored by default on Linux endpoints, which is the standard out-of-the-box Wazuh configuration and exactly where you’d want eyes, since so much system-level tampering lands there.

Why this matters: think of FIM’s scan interval like a night watchman doing rounds. If he walks the building once every 12 hours, a burglar who slips in and out during that gap leaves no trace on his log. Tighten the rounds to once a minute and suddenly he’s very hard to miss. Hold onto that idea.

Step 2: Exploring the Core Modules

With the agent live, this is where the platform earns its keep. I worked through each major module the way an analyst would during a real investigation.

2.1 Threat Hunting and Event Collection

The Threat Hunting module pulled together 876 security events across the enrolled agents in the first 24 hours. Wazuh sorts these into rule groups, PAM authentication, syslog, systemd, rootcheck, and automatically maps them to compliance frameworks like PCI DSS.

Each entry in the events feed carries the details you need to triage fast: timestamp, agent name, rule description, severity level, and rule ID.

The value here is reduction. 876 raw events sounds like noise, but structured this way you can filter, sort, and zero in on the handful that actually matter instead of drowning.

2.2 Anomaly and Rootkit Detection

This was the standout finding. While monitoring the medsecure-chizom agent, Wazuh’s rootcheck module caught that TCP port 55555 was hidden at the kernel level, throwing the alert:

Port ‘55555’(tcp) hidden. Kernel-level rootkit or trojaned version of netstat.

This is a rule 510, severity 7 alert, and it’s a big deal. A hidden port like this means one of two things: either there’s a kernel-level rootkit, or the system’s own netstat utility has been replaced with a compromised version that lies about what’s listening. Both are hallmarks of advanced persistent threat (APT) activity, precisely the kind of stealthy, dug-in presence the MedSecure attacker had. An attacker who can make their command channel invisible to standard tools is exactly why breaches go undetected for weeks. Wazuh saw through it.

2.3 MITRE ATT&CK Mapping

Raw alerts tell you what happened; they don’t tell you the story. That’s what the MITRE ATT&CK mapping is for. It’s a shared industry catalog of the tactics and techniques attackers use, and Wazuh automatically correlates your events against it.

On the monitored endpoints it lit up four active tactics:

1. Initial Access
2. Persistence
3. Privilege Escalation
4. Defense Evasion

The specific techniques it named: Valid Accounts and Sudo / Sudo Caching abuse; map directly onto the MedSecure breach, where the attacker harvested credentials and rode a misconfigured service account across the network.

The analogy I keep coming back to: individual alerts are like scattered puzzle pieces. ATT&CK mapping is the picture on the box lid. It lets a responder place each piece into a coherent attack narrative instead of staring at disconnected fragments.

2.4 Vulnerability Detection

The vulnerability module continuously compares installed software against known CVE databases. On the medsecure-frank agent alone it found 54 critical vulnerabilities, including CVE-2026-1703, a recently disclosed flaw present across several packages. The single most vulnerable application was Firefox, with 119 vulnerable packages.

This maps straight back to the scenario’s root cause: MedSecure got breached through an unpatched workstation. Continuous vulnerability visibility is the difference between “we think we’re patched” and “here is the exact list of what an attacker could walk through today.”

2.5 File Integrity Monitoring (the payoff)

Remember that 60-second scan tweak from setup? Here’s where it pays off. To simulate the behavior of the malware dropper from the MedSecure attack chain, I created, edited, and then deleted a test file inside the monitored /etc/ directory.

Wazuh caught all three file-system events, correctly attributed them to the root user, and logged the filename, timestamp, and action type for each.

Translate that to the real incident: the malicious PDF dropper that landed on the MedSecure workstation would have tripped FIM the moment it wrote files to disk. Instead of a three-week dwell time, detection could have collapsed to hours. That’s not a marginal improvement; that’s the whole ballgame.

2.6 Configuration Assessment

Finally, Wazuh ran the CIS Ubuntu Linux 22.04 LTS Benchmark v2.0.0 against medsecure-endpoint, an industry-standard hardening checklist. The box scored 44%, failing 107 of 207 checks.

The failures included missing partition security controls and unset nodev / noexec / nosuid mount options, among other gaps. In plain terms: a weakly hardened host is a house with the interior doors left open. Once the MedSecure attacker got in, this kind of soft configuration is exactly what let them move laterally with ease.

Step 3: Bringing It Back to the Breach

The real test of a security tool isn’t the feature list; it’s whether it would have changed the outcome. Replaying the MedSecure timeline with Wazuh in place:

• MITRE ATT&CK would have flagged the Initial Access and Privilege Escalation tactics tied to the phishing-driven credential harvest.
• FIM would have caught the PDF dropper modifying system files within a single scan cycle.
• Rootcheck would have exposed the attempts to hide the malicious channel mimicking Microsoft 365 traffic.
• Most importantly, the SIEM alerting engine, with notification rules configured correctly, would have escalated all of this to the security team immediately, erasing the three-week window that let the attacker quietly exfiltrate procurement data.

There’s a regulatory angle too. Wazuh ships a built-in GDPR compliance module that automatically flags events relevant to Article 32 (security of processing) and Article 33 (breach notification), the exact obligations MedSecure failed to meet in time. For any EU-facing organization, having compliance evidence surfaced automatically is a genuine operational advantage, not just a checkbox.

Step 4: Where Wazuh Falls Short

No honest evaluation ends at the sales pitch, so here are the limitations I ran into that you should weigh before adopting it:

1. That 12-hour default FIM interval is a real gap. Out of the box, an attacker who creates and removes a malicious file inside a single scan window slips through entirely. I only caught my dropper because I manually dropped the interval to 60 seconds. Tune this before you rely on it.
2. It’s noisy at the low end. Alongside the genuinely critical alerts sit hundreds of low-severity events. Without an experienced analyst triaging, the signal can get buried. The platform gives you visibility, not judgment.
3. ARM64 Docker support is missing. Wazuh’s official Docker images don’t natively support ARM64, which makes deployment awkward on Apple Silicon and other ARM-based environments. (Worth knowing if, like me, you’re working on ARM hardware.)
4. It detects, but doesn’t respond automatically. Wazuh excels at seeing threats, but it won’t natively take containment action on its own. To go from detection to automated response at real incident scale, you’d pair it with a dedicated SOAR platform.

Final Thoughts

What impressed me most wasn’t any single feature — it was how much security posture Wazuh reveals in the first few minutes of an agent connecting, entirely for free. Vulnerability baselines, config benchmarks, rootkit detection, ATT&CK correlation: for a small or mid-sized team without an enterprise SIEM budget, that’s an enormous amount of visibility for the cost of some setup time.

The MedSecure scenario is fictional, but the lesson isn’t. Nearly every failure in that breach — the unpatched box, the missed alerts, the three-week dwell time — is something a properly configured Wazuh deployment would have surfaced early. The tooling was never the hard part. The hard part, as always, is configuring it well and having someone watching. If you take one thing from this walkthrough, let it be this: deploy the agent, then go tune that FIM interval before you trust it.

This walkthrough was built on a simulated incident scenario for evaluation and learning purposes. Wazuh version 4.14.4, cloud-hosted. Screenshots throughout are from my own deployment.