Old Kit, New Kit Part 4: Service and Tech Fingerprinting — Httpx-Toolkit and Naabu vs Nmap -sV and Whatweb
Third pair, and the first one to split down the middle rather than favor one side cleanly. nmap -sV and whatweb on the classic side, naabu and httpx-toolkit on the modern side, both pairs doing the same two jobs, find the open ports and identify what’s actually running behind them, against target-web and target-wordpress. One half of this pairing goes about as badly for the modern tool as this series has seen. The other goes clearly the other way.
How this was verified
Both targets have a Wazuh agent enrolled, so this is one of the pairs that can actually check the detection angle properly rather than just the timing. Every command and timing figure below is a real run.
The classic baseline
nmap -sV first, full port range on both targets:
$ time nmap -sV -p- -T4 10.10.10.40 -oN nmap-target-wordpress.txt
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 10.0p2 Debian 7+deb13u4 (protocol 2.0)
80/tcp open http Apache httpd 2.4.68 ((Debian))
Nmap done: 1 IP address (1 host up) scanned in 9.37 seconds
real 9.45starget-web gave the identical two-port shape in this series’ Part 2 post, 7.72 seconds for the same full-range scan. Then whatweb, the classic tech-fingerprinting side:
$ time whatweb -v 10.10.10.30
Summary : Apache[2.4.68], Cookies[nb_session], HTML5, HTTPServer[Debian Linux][Apache/2.4.68 (Debian)], PasswordField[password]
real 4.88s
$ time whatweb -v 10.10.10.40
Summary : Apache[2.4.68], HTML5, HTTPServer[Debian Linux][Apache/2.4.68 (Debian)], MetaGenerator[WordPress 7.0.2], WordPress[7.0.2]
real 3.47sWhatweb pulled the exact WordPress version straight off the meta generator tag, plus the session cookie name on the staff-portal target. Combined time for both: 8.35 seconds.
Naabu: a real gotcha, not a design flaw
Naabu’s real selling point is the same as rustscan’s, an async SYN scan much faster than nmap’s default. That’s not what happened here:
$ time naabu -host 10.10.10.30,10.10.10.40 -p -
[INF] Running CONNECT scan with non root privileges
10.10.10.30:80
10.10.10.40:80
10.10.10.30:22
10.10.10.40:22
[INF] Found 2 ports on host 10.10.10.30 (10.10.10.30)
[INF] Found 2 ports on host 10.10.10.40 (10.10.10.40)
real 264.38sA SYN scan needs raw sockets, which needs root or CAP_NET_RAW, neither of which this run had, so naabu silently fell back to a full TCP three-way-handshake connect scan across the entire 65535-port range on both hosts. 264.38 seconds, over four minutes, to find the same two ports per host nmap found in under ten seconds each. That’s roughly 25 to 30 times slower than the classic tool, for an identical result. This isn’t naabu being a worse design than nmap, it’s what happens when the tool that needs elevated privileges to do its real trick doesn’t have them, and nothing about the command or its output makes that limitation obvious unless you’re reading the log line closely. Running it as most people would the first time, without sudo or a setcap grant, this is the honest result you’d actually get.
The httpx name collision
The next command should have been straightforward, and instead turned into its own small investigation:
$ printf "10.10.10.30\n10.10.10.40\n" | httpx -tech-detect -title -server -sc
Usage: httpx [OPTIONS] URL
Error: No such option: --version (Possible options: --json, --no-verify, --verbose)/usr/bin/httpx on this Kali install isn’t ProjectDiscovery’s recon tool at all:
$ dpkg -S /usr/bin/httpx
python3-httpx: /usr/bin/httpxThat’s a Python HTTP client library’s own CLI, an entirely different tool that happens to share the name. Kali actually ships the real recon tool under a different binary specifically to dodge this:
$ which httpx-toolkit
/usr/bin/httpx-toolkitNothing about the obvious command from any tutorial warns you of this. It just runs the wrong tool and fails in a way that looks like a flag problem rather than a naming collision.
Httpx-toolkit, correctly invoked
$ time printf "10.10.10.30\n10.10.10.40\n" | httpx-toolkit -tech-detect -title -server -sc
[INF] Current httpx version v1.9.0 (outdated)
http://10.10.10.30 [200] [Northbridge Freight Co. - Staff Portal] [Apache/2.4.68 (Debian)] [Apache HTTP Server:2.4.68,Debian]
http://10.10.10.40 [200] [Target WordPress Site] [Apache/2.4.68 (Debian)] [Apache HTTP Server:2.4.68,Debian,MySQL,PHP,WordPress Block Editor,WordPress Site Editor,WordPress:7.0.2]
real 1.29sBoth targets, 1.29 seconds combined, against whatweb’s 8.35 seconds combined for the same two hosts. It also separately called out MySQL, PHP, and the WordPress Block and Site Editor components on target-wordpress, comparable-to-richer detail than whatweb’s summary line, in roughly a sixth of the time. It even flagged its own version as outdated, a small honest note on modern-tool maintenance drift showing up unprompted.
What ends up in the log, and what doesn’t
Checking target-web’s Apache log against the traffic from all three tools:
10.10.10.5 - - [29/Aug/2026:17:36:43 +0100] "GET / HTTP/1.1" 200 619 "-" "WhatWeb/0.6.4"Whatweb self-identifies in its own User-Agent string, plainly, in every request it sends. Httpx-toolkit’s requests carried no equivalent signature in the same log window, no giveaway string marking them as reconnaissance traffic rather than an ordinary browser hit. This is the first pair in this series where the modern tool is actually quieter in the raw log, not because Wazuh caught anything different between them, but because whatweb chose to announce itself and httpx-toolkit didn’t.
And checking the Wazuh manager directly:
$ ssh -i ~/.ssh/wazuh-lab michealg@10.10.10.10 "sudo grep -A2 -E 'target-web|target-wordpress' /var/ossec/logs/alerts/alerts.log | tail -80"Every alert returned was from checking the log itself, our own SSH and sudo activity, exactly the same pattern as Part 2’s finding. Zero alerts fired for naabu’s four-minute connect scan, zero for whatweb, zero for httpx-toolkit. This Wazuh deployment’s default web-log ruleset doesn’t distinguish any of these four tools from each other or from ordinary traffic, whatweb’s loud self-identification included. The quieter log footprint is real, but it isn’t buying anything against this particular defensive setup, since nothing here is watching for that signature either way.
Verdict
This pair splits cleanly rather than favoring either generation outright, which is itself the useful result. On ports, nmap won decisively, not because naabu’s underlying design is worse but because its real advantage needs privileges a default, unprivileged run doesn’t have, worth knowing before reaching for it expecting rustscan-like speed. On tech fingerprinting, httpx-toolkit won clearly on both time and detail, and happened to leave a quieter trace doing it. Detection-wise, none of it mattered against this lab’s out-of-the-box Wazuh configuration, every tool here is equally invisible to it by default. Pick nmap for ports unless naabu is running with the privileges it actually needs, and pick httpx-toolkit over whatweb for fingerprinting once you know to type the right binary name.