Old Kit, New Kit Part 1: Introduction
Every post in this series answers the same underlying question about a different pair of tools: if you swap the classic, well-worn Kali utility for its newer, quieter-looking replacement, what actually changes? Not what the marketing copy says changes, not what a blog post from three years ago claims, what actually happens when both are run for real, against the same targets, on a lab with a genuine Wazuh SIEM watching.
That’s the whole premise. Ten tool pairs, one real isolated lab, and a rule that held for the entire series: every command below is a real run, every timing figure is a real time measurement, every log line is copied from an actual alert, not reconstructed from documentation or memory. Where something failed, broke, or needed a workaround nobody warns you about, that’s in the post too, because half of what “modern tooling” actually costs shows up in exactly that kind of friction, not in a benchmark table.
The lab, briefly
Everything ran on an isolated Proxmox range with its own dedicated Wazuh manager, built specifically for this series rather than borrowed from an earlier one. Targets varied by pair: a deliberately vulnerable metasploitable2 box for the classics that need something genuinely old and holed; a minimal, current Debian host running just SSH and Apache; a live WordPress install; a hardened, non-domain-joined Windows Server 2022 box once the series moved onto Windows-specific tooling; and, for the one pair that needed it, a from-scratch Active Directory domain controller with real, independently-verified vulnerable configuration planted on it, not just a checklist claiming it was vulnerable. Most targets carried an enrolled Wazuh agent, which is what makes the detection half of each post possible rather than aspirational.
Each post follows the same shape: run the classic tool, run the modern one, report the real timing and real output, then check what — if anything — ended up in Wazuh’s alert log. Nine times out of ten there was a real, verifiable answer either way. The tenth time, the honest answer was “nothing, and here’s why that’s not actually surprising.”
Why “Old Kit, New Kit”
This series started under a different working title, and it stayed a working title on purpose — naming it properly before running a single test would have meant guessing at a thesis before having one. Ten pairs in, the actual thesis turned out to be less tidy than “new tools win” or “old tools are underrated,” and a title that promised either would have been misleading. What kept recurring instead was that “modern” and “classic” turned out to be poor predictors of almost everything that actually mattered: speed, capability, stealth, and especially what a SIEM configured with sensible defaults would or wouldn’t notice. Sometimes the modern tool won outright. Sometimes the classic one did, for reasons specific to the target rather than the tool’s age. Sometimes neither mattered at all, because the actual detection gap sat one layer below either tool, in whether a particular audit policy was switched on. “Old Kit, New Kit” doesn’t pick a side, because by the end of testing, neither did the evidence.
The ten pairs
This is the planned lineup for the series. Each pair’s name links to its own post once that part is actually live; until then it’s listed here as plain text so nothing points at a page that doesn’t exist yet.
| # | Pair | Category |
|---|---|---|
| 2 | Rustscan vs Nmap | Port and service discovery |
| 3 | Amass and Dnsx vs Whois, Dig, theHarvester, and Sublist3r | Subdomain and DNS recon |
| 4 | Httpx-Toolkit and Naabu vs Nmap -sV and Whatweb | Service and tech fingerprinting |
| 5 | Feroxbuster and Ffuf vs Dirb and Gobuster | Content and parameter discovery |
| 6 | Nuclei vs Nmap’s Vulnerability Scripts | Vulnerability scanning |
| 7 | NetExec vs Enum4linux and Smbclient | SMB enumeration |
| 8 | Gowitness vs Manual Screenshotting | Web screenshotting |
| 9 | Chisel vs ssh -D / socat | Pivoting |
| 10 | evil-winrm vs psexec and Manual RDP | Remote access |
| 11 | BloodHound and Certipy vs ldapsearch and net | AD enumeration |
Part 11 was the one pair gated on infrastructure that didn’t exist yet, a real Active Directory forest, which is why it landed last chronologically even though it sits fifth in the outline’s own topic order. Worth knowing going in: it’s also the pair with the sharpest result in the series, a certificate-template misconfiguration that a classic enumeration pass can’t even see, let alone exploit, and a modern one closes out in two commands, all the way to a real Domain Administrator credential.
What to expect, and what not to
Some of these pairs are clean wins for one side. More of them aren’t. A few produced a genuinely large, unmissable Wazuh alert flood; a few produced nothing at all, correctly, because the traffic simply wasn’t the shape anything was watching for. One pair’s most interesting finding wasn’t about either tool — it was a defensive Windows mechanism nobody planted on purpose getting in the way of a planted attack path, and behaving exactly like it would in a real domain. None of that was scripted in advance. The outline that shaped this series predicted a detection angle for each pair going in; more than one post spends real time explaining why the prediction didn’t quite hold, and what actually did instead.
If you’re after a single “modern wins” or “classic still holds up” headline, this series won’t hand you one, on purpose. What it will hand you, across all ten pairs, is real evidence for a more useful question: not which generation of tool is better, but which specific capability, cost, or blind spot you’re actually trading away by picking one over the other, and whether your own detection stack would notice either way. Part 12 pulls all ten together once the whole series is out; until then, each post stands on its own.