Sn1per Deep Dive Part 9: What a Pen Tester Without Sn1per Would Have Found

Part 8 covered building a genuine Windows target and running Sn1per against it for real. The results were thinner than the tool’s own reputation suggests: a port-list gap that skipped a live Elasticsearch RCE entirely, a Jenkins Script Console URL crawled and logged without ever being flagged, and a bruteforce phase that failed against every protocol it tried, for reasons that had nothing to do with whether the credentials were actually weak.

This post works the same box by hand, with nothing but nmap, curl, and two purpose-built credential tools, and puts the two approaches side by side. It closes the series.

Starting from nothing, the way a human would

A tester who’d never seen this box starts with a port scan, not a tool-specific mode name:

nmap -sV -p- 10.10.10.50

That’s the single command Sn1per’s own initial pass effectively wraps too, and it finds the same four ports: 445, 3389, 8080, 9200. Nothing about a plain nmap sweep misses anything Sn1per’s front end also caught. The difference isn’t in discovery. It’s in what happens next.

Port 9200, the one Sn1per never tested

A human who sees 9200/tcp open http doesn’t need a mode to know what that number usually means. A single request answers the question:

curl -s http://10.10.10.50:9200/

That returns Elasticsearch’s version banner directly, "number" : "1.1.1", no scanning required. A version number from 2014 next to an open, unauthenticated management port is the kind of thing that gets flagged by reflex, not by running a tool’s automated checklist. The CVE, script_mvel_rce, is a five-minute search away from that version string, and confirming it doesn’t need nuke mode’s per-port loop at all, since that loop never gets to port 9200 in the first place. This is the clearest example in this whole series of a manual, first-principles approach catching something an automated mode’s hardcoded list structurally cannot.

Port 8080, the one Sn1per saw and said nothing about

curl -s http://10.10.10.50:8080/ returns a Jenkins login page, or in this case, given the security settings, no login page at all, straight into the dashboard. Sn1per’s WhatWeb pass already identified this correctly as Jenkins 2.568.1. A human tester finishing that identification does the obvious next thing: checks whether the instance requires authentication at all, and if it doesn’t, goes straight for /manage/script, the Groovy Script Console. That URL is public knowledge for anyone who has looked at Jenkins security documentation once. Sn1per’s spider walked past the exact same URL and logged it as one line among hundreds. The gap here isn’t discovery, both approaches see the same page. It’s judgment: recognizing which line in a long crawl result matters.

Ports 445 and 3389, and where automation actually helped

This is the one place automation pulled its weight over a purely manual approach. Guessing a working credential by hand, without a lead, is slow. Sn1per’s embedded bruteforce tooling tried and failed on both protocols, for tooling reasons rather than credential-strength reasons: Hydra’s SMB module couldn’t negotiate this SMB 3.1.1 stack, and its RDP module, labeled experimental by Hydra’s own project, couldn’t even open a connection.

The fix wasn’t more automation. It was switching tools:

netexec smb 10.10.10.50 -u Administrator -p 'Summer2026!'
netexec rdp 10.10.10.50 -u Administrator -p 'Summer2026!'

Both came back Pwn3d! in seconds. NetExec, the actively maintained successor to CrackMapExec, handles modern SMB dialects and RDP NLA cleanly in a way the older Hydra modules embedded in Sn1per’s bruteforce phase don’t. This is worth stating plainly: the credential was never the hard part. Once a plausible weak credential exists (and on a real engagement, that shortlist usually comes from OSINT, breach-list overlap, or a default-creds check, not blind guessing), the tool that actually proves or disproves it matters more than whether the process is automated. Sn1per picked the wrong tool for this job. A human picking NetExec instead, on the first try, gets a definitive answer in the time it takes to type two commands.

FreeRDP’s own CLI cost more time than either NetExec command, mostly from chasing an X11 display requirement and a certificate flag that moved to a namespaced /cert: syntax in recent versions. NetExec sidestepped all of that. Worth remembering the next time RDP needs a quick credential check rather than an interactive session: reach for the tool built to answer yes/no, not the one built to open a desktop.

Standard tooling, side by side

Finding	Sn1per (Part 8)	Manual (this post)
Elasticsearch 1.1.1 / CVE-2014-3120	Never scanned, port not in nuke’s test list	Found and confirmed with one curl
Jenkins unauthenticated Script Console	Correctly identified as Jenkins, URL crawled, never flagged	Found by following up on the identification manually
SMB weak Administrator credential	Bruteforce failed, wrong SMB dialect assumption	Confirmed in seconds with NetExec
RDP weak Administrator credential	Bruteforce failed, experimental module couldn’t connect	Confirmed in seconds with NetExec
Port discovery	Correct, all four ports found	Identical, plain nmap

Automation won on speed of discovery. It lost on everything that required either judgment about what a finding meant, or a tool actually capable of finishing the job it started. Neither list is longer than the other by much, which is itself the finding: the tool didn’t fail because it’s a bad tool, it failed because port-list gaps, spider blind spots, and one brittle bruteforce implementation are the kind of thing that only shows up when someone runs it for real and reads the output critically, exactly the discipline this whole re-verification effort has been built around since Part 7.

What this project found overall

Across nine parts, Sn1per did real work: fast, correct service and version identification across every target it was pointed at, a scoring engine whose arithmetic held up under a dozen-plus independent checks, and a genuinely useful first pass at attack surface on a box nobody has looked at before. It also has a source-verified pattern of firing exploit modules regardless of applicability, a scoring bug that mislabels a security-positive header as a vulnerability on every target tested, a packaging gap that breaks its own nuclei integration, and, now confirmed against a real Windows target, gaps in what its most aggressive mode actually tests versus what it claims to test.

None of that makes the tool useless. It makes it exactly what an automated scanner is: a fast way to establish a baseline, not a substitute for reading the output it produces or reaching for a better tool the moment its own comes up short. That’s the same conclusion the site has reached about every other category of automated offensive tooling covered so far, from the AI Pentest Agents series’ autonomous swarms down to hashcat’s own GPU benchmarks: the tool narrows the search space, the judgment about what the results mean still has to come from somewhere else.

This closes the Sn1per Deep Dive series at nine parts.