Host-Based Detection Part 1: What a HIDS Sees That a NIDS Never Will

This site has spent a lot of words on what happens on the wire. tcpdump recipes, a whole rst-forensics tool, Suricata and Sigma named in half a dozen detection-mirror closing chapters, an entire “A Day in the Life of a Packet” series walking a frame through a FortiGate’s fast path. What it hasn’t spent any words on, until two other series backed into it by accident, is what happens on the host itself once a packet has already arrived and stopped being a packet.

That gap got closed twice without anyone planning it as a series. From Dropbox to Daily Driver stood up a Wazuh manager on pve so a hardened Raspberry Pi would have something watching it after the fact, not just locking doors in advance. Old Kit, New Kit built a second, dedicated Wazuh instance specifically so a pentest lab’s targets would have an agent watching while ten classic-versus-modern tool pairs got run against them. Both are real, both are live, and neither post stopped to explain what a host-based intrusion detection system actually is, how it differs from everything this site has already covered, or why Wazuh specifically rather than one of several genuine alternatives. This series is that explanation, built around the two deployments that already exist rather than a third one from scratch.

Two different vantage points

A network-based intrusion detection system, Suricata and Zeek being the two most commonly named on this site so far, sits on a span port, a tap, or a bridge, and watches traffic as it passes. It sees every packet that crosses that point, regardless of which host sent or received it, which makes it a genuinely efficient way to watch many hosts from one vantage point. It also means it’s structurally blind to two things: anything that happens entirely inside a host and never touches the network (a local privilege escalation, a file getting modified, a scheduled task getting planted), and anything encrypted end to end between two points it can’t decrypt, which on a modern network is most of it.

A host-based intrusion detection system sits on the host itself. It reads log files, watches specific files and directories for changes, checks running processes and open ports against what’s expected, and in some implementations watches system calls directly. It sees exactly what happens on that one machine, encrypted traffic included, because by the time TLS matters the host has already decrypted it for its own use. What it can’t see is anything happening on a different host, or on the wire between two hosts that never terminates on the one it’s installed on.

Neither one is the complete picture on its own. A NIDS watching a segmented network with TLS everywhere sees connection metadata and not much else. A HIDS with no agent on a compromised host sees nothing about it at all, which is exactly what Old Kit, New Kit’s own lab found when a pivot target had no agent installed: not a subtle miss, just a real, complete gap. Host-based detection can only ever cover what it’s actually deployed on.

Where EDR fits, and why this series isn’t about it

Commercial EDR products (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, and others in that category) are, broadly, a HIDS with a lot more built on top: cloud-correlated telemetry, threat intelligence feeds, kernel-level tamper protection, and usually a vendor’s own detection engineering behind the rules rather than an open ruleset you can read yourself. That’s a real and often correct choice for a business. It’s also not something this series can meaningfully lab at home, since the interesting parts of an EDR product are exactly the parts a vendor doesn’t publish. This series stays with what’s actually inspectable: Wazuh specifically, since it’s what’s already running on two of this site’s own boxes, with the broader open-source landscape (OSSEC, Sysmon, auditd, osquery, Falco) covered for contrast in Part 9.

What this series covers

Nine parts: a brief history of how Wazuh got here from OSSEC, its actual architecture and what’s changing in the still-in-beta 5.0 line, standing up a manager two different ways for two different reasons, enrolling a real mixed fleet of agents, file integrity monitoring and rootcheck, how a raw log line actually becomes an alert, active response and the real risk of a security control that acts on its own, and a closing comparison against the alternatives with a handoff to the next series, which points this same detection capability at the site’s entire existing attack-technique library: Metasploit, Impacket, BloodHound, Password Cracking, Pivoting and Tunneling, and everything else already published under an offensive banner.

Nothing here needed a new lab build. The manager, the agents, and most of the real evidence this series draws on already exist, in From Dropbox to Daily Driver Part 6, Part 7, and Old Kit, New Kit. This series is the explanation those two builds never stopped to give.