Sn1per Deep Dive Part 6: A Full Sweep Against Northbridge Freight

This series has read Sn1per’s real source (Parts 1 through 3), documented what’s closed-source and vendor-described instead (Part 4), and worked out what each phase looks like from a defender’s side (Part 5). This closing post runs the whole pipeline, mode by mode, against Northbridge Freight, the small local lab introduced in Part 1, using each mode’s actual logic as read from source rather than a live sniper invocation, since the Community Edition’s own root requirement (Part 1) made that impossible in the environment this series was originally researched in. Every artifact quoted below was genuinely captured against the lab during this series; the mode logic applied to it is quoted directly from the same source files the earlier posts already read. Part 7 reruns this same shape of walkthrough for real, with genuine root, against a rebuilt version of this lab.

Stage one: building the target list

Part 2 covered recon mode’s five subdomain sources and discover mode’s three-pass nmap sweep. Against a real domain, that’s whois, Sublist3r, Amass, Subfinder, dnscan, and a crt.sh scrape, merged and deduplicated. Against Northbridge Freight, a real IANA whois lookup for the top-level namespace it would sit under returns a genuinely boring, correct result:

domain:       COM
organisation: VeriSign Global Registry Services

That’s not a finding, it’s a reminder of what stage one actually is: mostly quiet, mostly automatic, and mostly aimed at services that aren’t the target at all, exactly as Part 5 described. The interesting part starts once there’s a live host to scan directly.

Stage two: discover mode’s port sweep, applied for real

A genuine nmap -sV connect scan against the lab, run with the real Ubuntu-packaged nmap 7.80 binary this series extracted in Part 1:

PORT     STATE  SERVICE VERSION
22/tcp   open   ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.16 (Ubuntu Linux; protocol 2.0)

That’s a real, live result, not a fixture. And a separate genuine banner grab against a small demonstration service stood up for this series on a non-standard port:

220 ProFTPD 1.3.3c Server (Northbridge-Migration) [127.0.0.1]

That version string, ProFTPD 1.3.3c, isn’t a random choice. It’s the exact version tied to a specific, real, well-known backdoor: the software shipped with a malicious backdoor inserted into its source between November 2010 and December 2010, and that backdoor is exactly what Part 1 found hardcoded into normal mode’s port 21 branch as unix/ftp/proftpd_133c_backdoor.

Stage three: what normal mode’s logic says happens next

This is the point in the series where it matters that Parts 1 and 5 already established this precisely, because there’s no ambiguity to walk through: per the real source quoted in Part 1, an open port 21 with a banner Sn1per’s own per-port branch checks against triggers msfconsole -q -x "...use unix/ftp/proftpd_133c_backdoor; run;..." unconditionally, no confirmation, no version-matching logic beyond the port being open. This series doesn’t run that exploit, against this lab or anywhere else. What’s worth taking from it instead is the shape of the decision Sn1per’s automation is making: it isn’t asking “is this specific host running the vulnerable build,” it’s asking “is this the kind of banner that historically goes with this exploit,” and firing on the second question alone. Part 5’s framing of this as the single highest-value detection opportunity holds regardless: any current IPS watching this exchange has a two-decade-old signature ready for exactly this pattern. Part 7’s real testing confirmed the same firing behavior against a different service (SSH rather than FTP) on a real lab target, so this isn’t a one-off read of a single branch.

Stage four: web mode, applied by hand against real captured headers

Part 3’s sc0pe templates run against text files sn1per has already saved, so applying them by hand against Northbridge Freight’s real captured response is exactly reproducing what the tool does internally:

Server: Werkzeug/2.2.3 Python/3.10

Server_Header_Disclosure.sh matches (SEARCH='positive', pattern Server\:), severity P5 - INFO. CSP_Not_Enforced.sh matches on absence, severity P5 - INFO. Running Part 3’s scoring formula (INFO*1) against just these two: a score of 2. That’s the entire mechanical output an automated sweep produces against this host’s headers, and it’s genuinely correct as far as it goes; both are real, fixable findings.

It’s also nowhere near the actual story. robots.txt, fetched for real during this series, disallows four paths:

Disallow: /admin
Disallow: /staging
Disallow: /backup.zip
Disallow: /internal-notes.txt

Part 5 described exactly this pattern from the defender’s side: an automated tool reads robots.txt as a hint list rather than a request, and requests the disallowed paths next. Doing exactly that against Northbridge Freight, /internal-notes.txt returns:

TODO before go-live:
- rotate the staging DB password (still default from the vendor image)
- remove /backup.zip from web root, it has last month's DB dump
- ask IT to close 2121, that was only for the migration script

Nothing in sc0pe’s template model, or in any of Part 3’s positive/negative header checks, has a mechanism for reading a text file and recognizing “this describes a live default credential and an open port someone forgot about” as more significant than a missing CSP header. That recognition is a human judgment call about what a sentence means, not a pattern match against what’s present or absent in a response, and it’s exactly the kind of finding that would sit in a sc0pe score of 2 next to two cosmetic header notices, with nothing in the tooling to say which of the three actually matters.

Where the automation’s logic runs out

This is the actual handoff point this series has been building toward. Everything through stage four is inside what Sn1per’s own source, read across five posts, actually does: enumerate, scan, fingerprint, pattern-match, and in normal mode’s case, fire a fixed set of exploit modules keyed to old CVEs. None of that logic has anything to say about a staging database password that’s “still default from the vendor image,” because acting on that requires knowing what the vendor’s default credential actually is, trying it against whatever’s listening on the port the note just disclosed, and then deciding what to do with whatever comes back. That’s the Impacket and password-cracking territory this site has already covered in detail: the Impacket Deep Dive series for what comes after a credential works against a Windows-shaped target, Password Cracking and Wordlist Engineering for turning “default password, never rotated” into something more specific when it isn’t quite that simple, and Pivoting and Tunneling for what happens once that access needs to reach something a step further into the network than the host directly in front of you.

Sn1per’s real contribution, verified across this series, is compressing what used to be a morning of manual whois lookups, subdomain brute forcing, and port-by-port service checks into one invocation, and it does that job honestly. What it was never going to do is read a TODO comment and understand it the way a person does. That gap is not a bug in Sn1per specifically; it’s the same gap the AI Pentest Agents series found in autonomous agents built to go further than Sn1per ever tried to. Orchestrating known techniques quickly is a solved problem. Recognizing which finding actually matters, in a pile of findings that all look the same shape on a report, still isn’t.

Update: verified for real in Part 7

Everything above was reconstructed by hand from source and real captured artifacts, because the environment this series was written in had no root and Sn1per’s own $EUID check refuses to run without it. That gap has since been closed: Part 7 reruns this same shape of walkthrough against a rebuilt version of the Northbridge Freight lab with genuine root, alongside a second real target and modes this post never touched (nuke, airstrike, the mass-scan variants). The stage-three prediction above, an unconditional exploit attempt keyed to a banner rather than a confirmed vulnerability, held up exactly as described once it could be tested against real infrastructure rather than reasoned about from source.