Host-Based Detection Part 5: Enrolling a Real, Mixed Fleet

A manager with no agents is an expensive way to look at an empty dashboard, a line From Dropbox to Daily Driver Part 7 used almost exactly, and it’s worth taking seriously. Everything in Parts 1 through 4 of this series is infrastructure for a capability that doesn’t exist until something is actually enrolled and reporting.

The single-host case, in real detail

Part 7’s Pi enrollment is the clean, worked example. Wazuh ships architecture-specific packages rather than one universal build, so a Pi (arm64) needs a different .deb than the amd64 manager VM from Part 6: wazuh-agent_4.14.7-1_arm64.deb, installed with the manager’s address passed as an environment variable on the dpkg invocation, WAZUH_MANAGER='192.168.1.4' dpkg -i ..., which bakes the address straight into the agent’s config during the package’s own post-install step rather than needing a manual edit afterward. The agent showed up under the dashboard’s Endpoints view within seconds of the service starting, correctly identified by OS and agent version.

That’s the part worth being honest about, though, and Part 7 was. “Active” in a dashboard confirms the network path and the enrollment worked. It says nothing about whether anything useful is actually being detected. The only real way to test that is to generate real activity and see what turns up, which is exactly what happened next: a few ordinary SSH sessions produced 225 real hits in the manager’s Security Events view, sshd authentication success, PAM session open and close, and a successful sudo to root, all correctly classified, all without writing a single custom rule. Part 7 of this series covers why that worked out of the box.

The mixed-fleet case

Old Kit, New Kit’s lab enrolled a genuinely more varied set: a metasploitable2 box, a minimal current Debian host, a live WordPress install, a hardened, non-domain-joined Windows Server 2022 host, and a from-scratch Active Directory domain controller, most carrying an enrolled agent. That’s arm64 Linux, amd64 Linux, and Windows all reporting to the same manager, which is a more representative picture of what enrolling “a fleet” actually looks like than a single Pi ever could be on its own: different package formats again, Windows takes an MSI, not a .deb, different default log sources, Windows Event Log channels rather than syslog or journald, and, per Old Kit, New Kit Part 11, at least one case where the interesting finding wasn’t what the agent caught but what auditing had to be manually turned on before it could catch anything at all. Certificate Services auditing isn’t enabled by default on a fresh AD install, so a real ESC1 exploitation chain against that lab’s domain controller left no CA-side audit trail whatsoever until that was fixed.

What “enrolled” actually buys you, and doesn’t

Across both fleets, the pattern holds. Getting an agent installed and showing Active is the easy, mechanical part, package format and manager address are the only real variables. What it buys you is exactly what got demonstrated twice, real, correctly-classified visibility into events the agent’s default configuration already knows how to recognise. What it doesn’t buy you automatically is coverage of everything worth watching. SCA, FIM, and certain audit-policy prerequisites, like the AD certificate-auditing gap above, all need a deliberate configuration step on top of enrollment, which is where the rest of this series goes next. Part 3’s note about 5.0 changing agent transport, HTTPS on 1517 with per-agent bearer tokens replacing 1514/1515, is worth remembering here too: none of the mechanics above have shipped in a stable release yet, but enrollment itself is one of the areas that changes shape once it does.