Sn1per Deep Dive Part 7: Verified With Root

Six posts in this series were built entirely from source, real individual tool binaries, and a small local Python http.server lab, because the sandbox this series was researched in has no root and Sn1per Community Edition’s own $EUID check refuses to start without it (Part 1). That constraint is gone. This post reruns the tool for real: airstrike, nuke, and all four mass-scan modes, against a rebuilt lab with genuine root, on an isolated network with no route to anything else. Every command below is a real terminal transcript, not a description of what the source implies would happen.

The rebuilt lab

The lab moved off the original Werkzeug http.server prototype from Part 1 onto three proper VMs on an isolated bridge with no route to the internet or anything else on the network: target-metasploitable2, the standard vulnerable Linux target used elsewhere on this site; target-web, an Apache-hosted staff portal for the same fictional Northbridge Freight Co. cover story Part 1 introduced, now serving Server: Apache/2.4.68 (Debian) with a real password-protected login form instead of the original bare Python prototype; and target-wordpress, a genuine WordPress 7.0.2 install on the default Twenty Twenty-Five theme, added specifically to test Sn1per’s WPScan integration against a real CMS rather than a static page that correctly reports itself as not running WordPress.

What held up exactly as read from source

Parts 1 through 5 made several claims from reading modes/*.sh directly, without ever running the tool. Almost all of them held up unchanged against real execution. airstrike mode does loop stealth mode across every target in the list, real banner and all:

+ -- --=[ Launching stealth scan: 10.10.10.30

nuke mode forces bruteforce on and prints exactly the warning Part 1 quoted:

+ -- --=[WARNING! Nuking ALL target!

And Part 1 and Part 5’s biggest claim, that normal-family modes fire real Metasploit exploit modules keyed to a banner match rather than a confirmed vulnerability, reproduced exactly: nuke mode’s SSH branch ran auxiliary/scanner/ssh/ssh_version, an OpenSSH user-enumeration scanner, and the libssh CVE-2018-10933 auth-bypass module, against two targets that were never running libssh in the first place. Pattern-match, not precision-match, confirmed with a real msfconsole invocation rather than reasoned about from source.

The one real correction: recon mode does far more than recon.sh alone

Part 2 read modes/recon.sh and modes/osint.sh and described recon mode as five subdomain-enumeration sources plus an OSINT pass, all of it passive or close to it. That’s an accurate description of what those two files contain. It’s an incomplete description of what actually runs when -m recon is invoked from the command line. Against a real domain (this site’s own, since testing that pass anywhere else would have meant scanning someone who never agreed to it), -m recon triggered a BlackWidow spider of the entire site, the full dozen-category static-analysis pass (XSS, SQLi, SSRF, RCE, IDOR, LFI, SSTI, redirect, debug, plus interesting-extensions and interesting-parameters checks), a directory brute-force attempt, a WPScan run, an HTTP request-smuggling probe, a nuclei attempt, both sc0pe scans, and finally a full nmap SYN port scan against the live host. None of that is in recon.sh or osint.sh. The sniper wrapper evidently routes the CLI’s recon mode through a much larger share of the same pipeline web mode uses, not the standalone passive step its name and Part 2’s original framing suggested.

The scan was stopped mid-port-scan once this became clear, well before it ran long enough to matter, and nothing about the result changes what this site already knew about its own headers or lack of a WordPress install. The lesson for anyone else reaching for this tool is worth stating plainly: -m recon is not a safe passive-only flag. Treat it as running most of web mode’s active checks plus a port scan, and reach for the individual passive tools by hand, whois, dig, theHarvester -b crtsh, sublist3r, if a genuinely passive pass against a domain is the actual goal.

Mode depth varies more than the naming suggests

Running the same target list through massportscan, massweb, masswebscan, and massvulnscan back to back showed a real difference in depth that the parallel naming doesn’t convey. massweb runs the same full active pipeline web mode does: spider, static analysis, WPScan, smuggling probe, nuclei, both sc0pe scans, several minutes per target. massportscan, masswebscan, and massvulnscan are all much lighter: an nmap pass and a quick sc0pe scan, seconds per target, no spidering or smuggling probes at all. airstrike sits between the two: a single lightweight stealth-mode pass per target (whois, a modest port scan, passive sc0pe) rather than the full pipeline massweb or nuke run. None of this is obvious from the mode names alone, and it’s worth knowing before picking one for a large target list on a time budget.

Real, current CVE data against a real, current OpenSSH build

Both Linux lab targets run a recent OpenSSH build, 10.0p2 on Debian 13. nuke mode’s vulners NSE integration returned real, current CVE data against it rather than anything synthetic: CVE-2026-60002 at a CVSS of 9.4, three entries at 8.1 (CVE-2026-35414, CVE-2026-35386, CVE-2026-35385), and a further run of mediums and lows down to CVE-2026-35388 at 2.5. That’s the vulners integration working as designed, pulling from a live vulnerability feed rather than a bundled, aging local database, confirmed by the fact that the CVE numbers returned are from this year rather than years old.

Brute-force actually gets defeated

This is the most useful defensive-side finding from this whole session. nuke mode’s forced bruteforce stage ran two different attacks against SSH on both targets, and both failed cleanly. Nmap’s ssh-brute script tried a short list of default credentials, root/root, admin/admin, and a dozen more, and got zero hits. BruteX then handed off to Hydra with a 123-entry wordlist, and Hydra didn’t just fail to find a password, it errored out of the attack entirely:

[ERROR] all children were disabled due too many connection errors
0 of 1 target completed, 0 valid password found

That’s OpenSSH’s own connection-rate throttling doing exactly its job: a multi-threaded, purpose-built brute-force tool couldn’t sustain enough concurrent connection attempts to complete a single full pass against the wordlist, let alone succeed. Worth citing precisely because it’s a clean, positive control: unmodified, current OpenSSH defaults are enough on their own to blunt an out-of-the-box automated brute-force attempt.

A real tooling gap: Metasploit’s ssh_version scanner can’t talk to post-quantum KEX

Metasploit’s ssh_version auxiliary module failed against both targets with Net::SSH::Disconnect. The reason is visible in the same nuke run’s ssh-audit output: OpenSSH 10.0p2 offers post-quantum key exchange, mlkem768x25519-sha256 and sntrup761x25519-sha512, ahead of anything the bundled net-ssh gem’s negotiation logic in this Metasploit build knows how to handle. A current friction point between a widely used offensive tool and a server simply doing what modern SSH implementations increasingly do by default: a scanner built to fingerprint SSH servers can’t get far enough into the handshake to do it once the server leads with a key exchange method the scanner has never heard of. A second module, opensshuserenum, behaved better here: run against the WordPress-hosting target, it detected its own results were a false positive and aborted rather than reporting garbage, a small thing worth noting when so much else in this post is about tools firing without checking their own output.

What a real WordPress install actually leaks by default

target-wordpress gave WPScan something to find, unlike Part 1 and Part 6’s static-page lab, which correctly reported itself as not running WordPress every time it was asked. Against a real, freshly installed WordPress 7.0.2 on the default Twenty Twenty-Five theme, WPScan’s passive checks alone surfaced: XML-RPC left enabled (xmlrpc.php, still a real pingback-abuse and brute-force-amplification vector even now), the readme.html file disclosing the exact WordPress branding, the uploads directory serving a full listing, the external WP-Cron endpoint reachable, and the exact theme version pulled straight from style.css. None of that required an aggressive scan or a plugin vulnerability, it’s what a default, unhardened install exposes to a purely passive check by default, a concrete answer to “what does WordPress leak out of the box” that the earlier, non-WordPress lab in this series couldn’t provide.

Two sc0pe bugs and a missing template set, confirmed live

Part 3 described the sc0pe engine as a directory of small positive/negative pattern-match templates. Real testing surfaced two bugs in that engine worth knowing about before trusting its output at face value. First, the clickjacking check flags a target regardless of the actual header value: a target correctly serving x-frame-options: DENY, the secure setting, still gets logged as a P4-LOW “Clickjacking” finding, exactly the same as a target with no header at all. Second, every nuclei invocation across every mode and every target in this session failed identically: [FTL] Could not run nuclei: no templates provided for scan, a packaging or configuration gap in how Community Edition bundles the nuclei template set rather than anything target-specific. Neither bug is disqualifying on its own, sc0pe’s other checks and the tool as a whole are still useful, but both are worth knowing before treating a clickjacking line item or an absent nuclei section as meaning what it appears to mean.

Two workspace-management flags also didn’t behave as documented. --status -w <workspace> ignores the -w flag entirely, it’s a hardcoded ps/netstat monitor regardless of which workspace name is passed. --export -w <workspace> errors with “You need to set a workspace via the -w switch” even when -w is passed, unless the flag is moved ahead of --export on the command line: sniper -w <workspace> --export rather than the documented order. Small things, but the kind that cost real time mid-engagement if they aren’t expected.

The scoring formula, confirmed at scale

Part 3’s CRITICAL*5 + HIGH*4 + MEDIUM*3 + LOW*2 + INFO*1 formula was checked by hand against every sc0pe report this session produced, from single-digit scores on quiet hosts up to a score of 78 against the WordPress target once its CVE-linked SSH service and full WordPress disclosure list were both counted. The arithmetic matched exactly, every time, across more than a dozen separate reports. It’s a simple weighted count, as Part 3 described, and it held up under real, repeated testing without exception.

What this changes, and what it doesn’t

None of this changes the argument this series has been building since Part 1: Sn1per orchestrates real, known techniques quickly and without an operator second-guessing any individual step, and that’s useful and detectable in roughly equal measure. What real, root-verified testing added was precision. The source reading in Parts 1 through 6 got the shape of the tool right almost everywhere; what it couldn’t catch were the handful of places where documentation, mode naming, and actual runtime behavior quietly diverge: recon mode’s real scope, the clickjacking mislabeling, the workspace flags that don’t do what their names say. Those are exactly the kind of gaps that only show up when something actually runs, which is the reason this follow-up exists. A Windows-based target and a full run through Sn1per’s bruteforce, airstrike, and workspace-scheduling flags against it remain on the list for a future post; everything above is what came out of the Linux side of the lab.