Host-Based Detection Part 9: Alternatives, and Handing Off to the Blue Team

Nine parts in, Wazuh has been this series’ only real subject, which risks implying it’s the only sensible choice. It isn’t, and closing this series with the alternatives side by side, plus a clear list of what’s actually left for the follow-up series, is a better ending than one more Wazuh feature.

The field, recapped from Part 2

OSSEC, still genuinely maintained under Atomicorp, OSSEC 4.3.0 shipped in August 2026, contrary to the easy assumption that it stalled once Wazuh forked, covers Wazuh’s original scope and nothing more: log analysis, FIM, rootcheck, active response, no indexer, no dashboard, no SCA module. It’s the right choice for exactly the case Wazuh has arguably outgrown: a small, single-purpose HIDS with no interest in becoming a SIEM.

Sysmon is Windows-only and produces no alerts of its own, just far richer process, network, and image-load telemetry than the Windows Event Log gives by default, via a kernel driver and an XML configuration file. It needs something else consuming its output to be useful at all, which in a Wazuh-based fleet means it’s a data source alongside Wazuh’s own Windows agent, not a competitor to it.

auditd is the Linux kernel’s own syscall-level audit subsystem, lower-level and higher-fidelity than Wazuh’s FIM or rootcheck modules, it can record exactly which process touched exactly which file, regardless of whether that process logs anything itself, and also, on its own, just a firehose with no alerting layer. This series’ own source material already made a real, deliberate call on exactly this tradeoff: From Dropbox to Daily Driver Part 7 skipped enabling auditd on that Pi specifically because of the write-wear and log-volume cost on a microSD card, a real, concrete instance of “more capable” and “worth running” not being the same decision.

osquery is a genuinely different paradigm: system state as a SQL-queryable database, queried on demand or on a schedule, rather than a continuous stream of events waiting to trip a rule. It answers “show me every host in the fleet with this specific file present right now” in a way a rule-based tool structurally can’t, and it complements Wazuh rather than replacing it, Wazuh ships its own osquery integration wodle for exactly this reason.

Falco watches syscalls via eBPF, purpose-built for container and cloud-native runtime behaviour: an unexpected shell spawned inside a container, an outbound connection from a workload that has no business making one. It’s the tool for a gap this site’s own Cilium, Kubernetes Networking, and Security Built on eBPF post and the Container Networking Deep Dive series never covered: runtime behaviour inside a running container, not its network path.

Commercial EDR, CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, and similar, is the umbrella superset of most of the above: cloud-correlated telemetry, vendor threat-intel feeds, and usually kernel-level tamper protection none of the open-source tools above bundle on their own, at a real licensing cost and with a detection engine you generally can’t read.

When Wazuh specifically is the right call

Wazuh earns its place in this list, rather than just being what happened to already be running, when the requirement is a single open, inspectable pipeline from raw log to alert, covering FIM, rootcheck, and SCA out of the box, across a genuinely mixed fleet, Part 5 of this series enrolled arm64 Linux, amd64 Linux, and Windows onto the same two managers with no separate tooling per platform, without needing to stitch Sysmon, auditd, and osquery together by hand or pay for a commercial platform. It’s not the highest-fidelity option in any single category, auditd sees more at the syscall level, osquery answers fleet-wide questions Wazuh’s rule engine can’t, but it’s the one that already does the whole job end to end, which is exactly why two real deployments on this site’s own infrastructure picked it over any of the above.

What Series 3 still needs, now that this exists

This series exists specifically to unblock the next one: pointing this same detection capability at the site’s entire existing offensive-technique library. Old Kit, New Kit already got a head start on that without calling itself part of this arc. Real captured Wazuh alert data already exists for SMB and NetExec enumeration, Chisel pivoting, evil-winrm and psexec remote access, and BloodHound and Certipy AD enumeration, the last one against the real domain controller named in Part 5 of this series. Metasploit Deep Dive closed its own series the same way, pointing its real exploitation runs at Wazuh after the fact and finding a genuinely useful gap: a healthy, reporting agent on a WordPress target that was completely blind to the actual RCE that had just run through it, no file-integrity or application-layer visibility on the exploited directory.

What hasn’t happened yet, and what a follow-up series should actually do rather than re-explain how Wazuh works: replay Impacket’s Kerberoasting, AS-REP roasting, and DCSync techniques against the same live domain controller this series has already been enrolling and watching, rather than the documented-only lab those posts originally used, and test persistence and anti-forensics directly against the HIDS itself, an attacker going after Wazuh’s own logs or agent process, which is a genuinely different and harder question than anything this series has asked so far. Both of those need no new infrastructure. The manager, the agents, and the domain controller are already built and already watching. What’s missing is someone actually running the techniques with this series’ understanding of what’s being watched, and why, in hand.