Old Kit, New Kit Part 12: The Verdict

Ten pairs, one lab, one Wazuh manager watching the whole time. Part 1 opened with a promise not to hand over a single “modern wins” headline, and ten posts later that promise held up better than expected — not because the results were wishy-washy, but because they kept pointing at a sharper, more useful question than “which generation of tool is better.” This post pulls all ten together, adds the lab-build lessons that never made it into any single pair post, and answers the question the series was actually built to answer.

The scoreboard

Pair	Winner on speed/capability	Winner on stealth/detection
Rustscan vs Nmap	Neither — rustscan’s port sweep is fast, but -sV hands off to the same nmap engine either way	Neither — zero Wazuh signal for either
Amass/Dnsx vs Whois/Dig/theHarvester/Sublist3r	Neither — both sides agreed on the same (empty) result; the real gap was tooling maturity, not capability	No detection story on either side — nothing to log against
Httpx-Toolkit/Naabu vs Nmap -sV/Whatweb	Split — nmap beat naabu on ports (privilege gap), httpx-toolkit beat whatweb clearly on fingerprinting	Httpx-toolkit, the first quieter modern tool in the series — though it didn’t matter, nothing was watching
Feroxbuster/Ffuf vs Dirb/Gobuster	Feroxbuster for depth, ffuf for everything else — not a strict either/or	Classic — for the first time, an unmissable, correlated Wazuh alert flood, on both sides equally
Nuclei vs Nmap’s Vulnerability Scripts	Nuclei — actual verified exploitation (root shells, working creds) beats version-string inference	Nuclei — realistic rotating User-Agents against nmap NSE’s self-identifying default string
NetExec vs Enum4linux/Smbclient	Genuine split — netexec wins structurally against a hardened target, enum4linux’s legacy RID-cycling still wins against a legacy one	Neither — Wazuh keyed off the SMB/NTLM protocol itself, blind to which tool produced it
Gowitness vs Manual Screenshotting	Gowitness, decisively — ~22x faster plus free metadata and a portable report	Neither — a clean, correct zero on both sides
Chisel vs ssh -D/socat	ssh -D on deployment cost, chisel on raw simplicity — socat paid the worst of both worlds	Reversed — chisel got caught and named by Defender, and the SIEM never even saw the one thing that worked
evil-winrm vs psexec/Manual RDP	evil-winrm, on reliability — the third time in this lab WinRM proved the most dependable execution channel	psexec was the loudest thing in the whole series, caught twice over independently; RDP’s one alert was the most precisely worded of any pair
BloodHound/Certipy vs ldapsearch/net	Certipy and bloodhound-python, decisively — full domain compromise the classic side can’t even see, let alone reach	An incidental lab-maintenance alert, not the attack itself, was the loudest and most precisely mapped event of the entire series

Six pairs split or came out even. Three went cleanly to the modern side. None went cleanly to the classic side on capability alone — the closest classic tools came to a clean win were narrower wins within a split decision (enum4linux against vintage Samba, nmap against an unprivileged naabu). That’s worth sitting with for a second, because it’s not the same as “modern tooling wins”: it means modern tooling more often does something structurally new, while classic tooling’s wins came from doing the same old thing against a target old enough to still be vulnerable to it.

Nine things that kept recurring

A few findings weren’t confined to one pair. Listed in the order they first showed up:

1. Detection depends on which ruleset the traffic pattern actually trips, not on which era the tool is from. Part 5’s feroxbuster/ffuf run produced the loudest volume in the series purely because high-volume 400-error traffic against a web server is exactly what Wazuh’s default web ruleset watches for — nothing about “modern” or “classic” changed that.
2. Passive, version-based checks and active, verifying checks carry different evidentiary weight, independent of which generation wrote them. Nuclei’s confirmed root shells in Part 6 mean something nmap’s vulners CVE-matching never could, on its own terms.
3. “Modern” isn’t a universal upgrade even within one pair. Part 7’s netexec beat enum4linux structurally against a hardened target and lost outright against a legacy one, in the same test, on the same tool.
4. A clean modern win exists too, and doesn’t need a nuanced split to be worth including. Part 8’s gowitness is the counterweight to point 3 — sometimes the modern tool is just better.
5. Deployment cost can be the real story even when runtime performance is identical. Part 9’s socat and ssh -D finished in the same fraction of a second once running; getting either one running cost wildly different amounts of real effort.
6. Local antivirus catching a tool tells you nothing about whether the SIEM watching the same box also sees it. Chisel’s Defender catch in Part 9 never reached Wazuh at all, because the Defender operational log wasn’t forwarded.
7. A “classic” tool can trip two independent detections at once, one of which doesn’t even need the antivirus signature to fire. Part 10’s psexec got caught by Defender and, separately, by Wazuh’s own service-install rule watching the raw event.
8. A diagnostic flag’s exit code can flatly lie about whether authentication actually succeeded. xfreerdp’s +auth-only mode in Part 10 reported failure on every attempt that the target’s own logs show succeeded.
9. ACL-based attack paths and certificate-template misconfigurations are structurally invisible to membership/attribute-only enumeration, not just slower to find — and a real AD background process can silently undo a deliberately-planted test condition hours later, a lab-maintenance lesson as relevant to real red and blue teams as it is to a home lab. Part 11’s own correlation added a tenth footnote worth keeping on its own: the loudest, most correctly-classified detection of the whole series came from cleanup activity working around that same background process, not from the headline attack.

Put together, those nine (ten, really) points are the actual finding of this series. Not “pick the modern tool” or “the classics still hold up,” but: detection in a real environment is a function of what’s actually configured to fire, and that has almost nothing to do with which decade produced the tool tripping it.

Building the lab: what we’d do differently

Every pair in this series ran on real, hand-built infrastructure, and building it produced its own lessons — some of which cost real time to discover the hard way, more than once. If this lab were being built again from scratch, here’s what would change.

NTP would be day-zero infrastructure, not something discovered by accident. Clock skew shows up as a confusing footnote as early as Part 7, gets flagged again in Part 9, gets a real root cause in Part 10 (a VM’s timezone quietly set to Pacific Standard Time), and only gets properly fixed during Part 11’s build, when the new domain controller became the lab’s own NTP authority for every other host to sync against. That’s four separate posts touched by the same underlying gap. A lab-wide NTP hierarchy, verified against a real external source before anything else gets built, should have been the first thing stood up alongside the Wazuh manager itself, not a fix that arrived five parts late.

Windows VM defaults would be settled once, not relearned per VM. Two separate builds in this series hit the identical class of problem from opposite directions: a VirtIO network adapter that Windows Server 2022 simply can’t see without a driver it doesn’t have (Part 9’s pivot host), and a VirtIO disk controller that made an entire Windows install invisible at setup (the domain controller build for Part 11). Same root cause, same fix (e1000 for networking, SATA for storage), discovered twice. A standing rule, decided before the second Windows VM ever got created, would have saved a repeat investigation.

The QEMU Guest Agent would be enabled on every VM from creation. It was, for the domain controller. It wasn’t, for the box used as the pivot and remote-access target across three separate posts, which produced a real false alarm — a “100% memory usage” reading that turned out to be Proxmox reporting the full allocation because it had no way to see actual usage inside the guest. Cheap to enable at creation, expensive to diagnose after the fact.

A couple of small, repeatable conventions would be written down once instead of re-discovered. Querying alerts.log (multi-line blocks) and alerts.json (one JSON object per line) need genuinely different tooling, and that distinction cost real time in Part 11 alone. Every Wazuh timestamp correlation needs to be anchored on the manager’s own UTC field, never a locally-displayed clock on either end — a rule this series learned the hard way in Parts 5 and 6, then had to re-learn a third time in Part 11. And any credential containing ! needs single-quoting before it ever reaches a zsh prompt, a small thing that nonetheless recurred often enough across Summer2026!, Winter2026!, and Autumn2026! to be worth a standing note rather than a fresh diagnosis each time.

None of these are dramatic. That’s rather the point: the friction that actually cost time in this series was almost never the pentesting tooling the series was ostensibly about. It was lab plumbing, the kind of thing that’s invisible in a tidy how-to but very much present in a real build.

The actual verdict

Don’t retire the classic tools, and don’t reflexively reach for the modern ones either. The honest pattern across ten real pairs is that the interesting differences sit in three separate places, and they don’t always move together: raw capability (does the tool structurally see what’s there at all), operational cost (what does it actually take to deploy and run), and detectability (what does a real SIEM, configured with realistic defaults rather than a hardened reference config, actually notice). A tool can win on one axis and lose on another in the same test, and several pairs in this series did exactly that.

If there’s one thing worth taking away and actually acting on, it’s this: check what your own detection stack is actually configured to catch, rather than assuming coverage because a tool is old and well-known or new and widely blogged about. This lab’s default Wazuh configuration had zero visibility into Windows process creation for an entire pivoting exercise, no forwarding for Defender’s own operational log, and no CA-level audit logging at all going into an AD compromise that ended with a real Domain Administrator hash. None of that is a Wazuh problem specifically — it’s what “default configuration” actually means, in this lab and very possibly in yours. The tools in this series, old and new alike, mostly did what they were supposed to do. What was actually being tested, ten pairs in, wasn’t really the tools at all.