Sn1per Deep Dive Part 1: From Recon Script to Attack Surface Platform

Impacket gives you a toolbox of protocol-level primitives. Pivoting and Tunneling and the password cracking series are the same shape: pick up a tool, understand exactly what it does on the wire, use it deliberately. Sn1per is a different animal. It doesn’t hand you a primitive, it hands you a pipeline: point it at a target, and it runs whois, DNS, subdomain brute forcing, port scanning, service fingerprinting, web scanning, and in some cases live Metasploit exploitation, one stage feeding the next, with no operator in the loop between steps.

That’s worth a series of its own, because the questions it raises are different from the ones Impacket or Chisel raise. Those tools ask “what does this protocol actually do.” Sn1per asks “what happens when you let a scanner decide what to try next, and is that decision-making something you can audit.”

This post covers where Sn1per came from, what the three editions actually contain, and what its scan modes look like once you’ve read the code that implements them rather than the page that sells them. The two posts after this go inside discover and web mode specifically. Part 4 covers the Professional 2026 architecture, which is closed-source and has to be described from the vendor’s own documentation rather than verified directly. Part 5 flips to the defensive side: what an automated Sn1per sweep looks like in your logs. Part 6 runs a full sweep against a small lab target built for this series and follows the automation’s own logic through to the point where a human has to take over. Part 7 goes back over all six of these with genuine root access and a rebuilt lab, checking every claim below against what the tool actually does when it runs.

Everything in this post is read from the real 1N3/Sn1per Community Edition source, cloned fresh for this series, not the project’s marketing copy.

Origin and editions

Sn1per’s own README describes it as “built by pentesters since 2015,” authored by a contributor going by xer0dayz (the handle stamped into the tool’s ASCII banner as @xer0dayz). It ships in three editions today:

Community Edition is free, source-available under a custom EULA, and lives in the public GitHub repository. Everything in this series that’s marked as verified comes from reading that code directly.

Professional is a paid tier, $984/year per seat at time of writing, aimed at individual operators and small teams. It adds a web UI, the full set of commercial integrations, and email support, all running on the same core scan engine as Community.

Enterprise is quote-based, aimed at SOCs running Sn1per across an entire external attack surface on a schedule rather than one engagement at a time.

The split matters for how this series is written. The pro/ directory in the open repository contains a single file, notepad.html. The Professional engine itself isn’t in the source tree, which means Part 4’s coverage of workspaces and the 2026 architecture is necessarily documented from Sn1per’s own release notes rather than read from source the way the rest of this series is.

The Community Edition actually requires root, and won’t start without it

The very first thing sniper (the main entry script) does is check its own privilege level:

if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root"
   exit 1
fi

That’s not a soft warning. If $EUID isn’t 0, the script prints that line and exits before touching the config file, before checking for updates, before anything. There’s no --no-root flag or degraded mode. This is worth stating plainly because it shapes most of this series: the sandbox originally used to research Parts 1 through 6 has no root, so nothing in those posts was run as a live end-to-end sniper -t <target> scan. What was verified directly at that stage: the real source of every scan mode script, the real CLI help text, and the individual tools Sn1per orchestrates (a genuine nmap 7.80 binary extracted from the Ubuntu 22.04 package without root, run against a small local lab target described below). What was described rather than executed at that stage: any run of the sniper wrapper script itself. Part 7 removes that constraint entirely, with a rebuilt lab and genuine root access, and checks every claim in this series against real, live execution.

The community script that was cloned for this series identifies itself as VER="9.2". The README’s marketing banner talks about “Sn1per Professional 2026,” which is the paid tier’s release line, not the version number baked into the Community script. Real root testing in Part 7 reconfirmed the same v9.2 identifier months later, consistent with Community lagging the Professional engine’s release cadence.

What Sn1per actually orchestrates

Counting tool invocations across the Community Edition’s mode scripts gives a concrete picture of where the engineering effort actually sits, rather than the “90+ integrations” headline number:

Tool	References across scan modes
nmap	619
dirsearch	139
msfconsole	80
curl	74
wpscan	52
zap	24
whatweb	20
nuclei	18
gobuster	17
nikto	12
arachni	12
whois	11
dig	11

nmap dominates, which makes sense: it’s the fingerprinting backbone every other stage depends on. The msfconsole count is the one worth pausing on. Sn1per doesn’t just detect that port 21 is open and running vsftpd. In normal mode, an open port 21 triggers real Metasploit modules: auxiliary/scanner/ftp/ftp_version, auxiliary/scanner/ftp/anonymous, and then, unconditionally, the actual exploit modules exploit/unix/ftp/vsftpd_234_backdoor and unix/ftp/proftpd_133c_backdoor. Port 22 gets scanner/ssh/ssh_version, scanner/ssh/ssh_enumusers, and scanner/ssh/libssh_auth_bypass (CVE-2018-10933). Port 135 gets exploit/windows/dcerpc/ms03_026_dcom fired automatically. This is real, current source, not a hypothetical: Sn1per’s default posture in several branches of normal mode is scan-and-attempt-exploit in the same pass, against known CVEs tied to the exact service banner nmap just reported. Part 6 walks through exactly what this means for a target running anything with a matching banner, and Part 7 confirms the libssh branch firing for real against modern OpenSSH targets that were never running libssh at all.

Scan modes, from the real help text

sniper --help (read from source, not run, per the root requirement above) documents around a dozen modes. The ones worth knowing before the next four posts:

normal (sniper -t <target>) is the default: recon, full port scan, per-port service checks and exploit attempts as above.

discover (sniper -t <CIDR> -m discover -w <workspace>) sweeps a whole range for live hosts, then automatically re-invokes itself in flyover mode against everything it finds. Part 2 covers exactly what commands this chains together, with a real correction in Part 7 about how much further recon mode specifically goes than its own source files suggest.

web (sniper -t <target> -m web, ports 80/443 only) and webscan layer web application scanning on top, and are where the sc0pe vulnerability engine and its scoring model live. That’s Part 3.

airstrike (sniper -f targets.txt -m airstrike) reads a target list and, contrary to what the “quick fingerprint” framing on the marketing page implies, runs each target through stealth mode in a loop. It’s a batch wrapper, not a lighter-weight mode. Confirmed live in Part 7, banner and all.

nuke (sniper -f targets.txt -m nuke -w <workspace>) is the same batch loop with bruteforce forced on for every target. The tool’s own ASCII banner for this mode reads “WARNING! Nuking ALL target!”, which is at least honest about what it does. Also confirmed live in Part 7.

massportscan, masswebscan, and massvulnscan are narrower batch variants for when you want one specific stage across many targets rather than the full pipeline. massweb, despite the naming parallel, actually runs the same full active web pipeline web mode does, spidering, static analysis, WPScan, and a smuggling probe, across every target in the list rather than a narrower slice of it. Part 7 has the real timing and output differences between all four.

Workspace and scheduling flags round it out: --list, -d (delete workspace), -dh (delete host), --status, --reimport/--reimportall/--reload/--export for loot, and -s daily|weekly|monthly for recurring scans, all Community Edition, all file-based rather than the database-backed workspace model Professional adds. Two of these are worth flagging ahead of Part 7’s real testing: --status doesn’t actually scope to the workspace passed via -w, it’s a hardcoded process and network monitor regardless of which workspace you name, and --export errors when -w comes after it on the command line despite that being the documented order. Both are shown with real terminal output in Part 7.

A lab to point it at

The rest of this series needs something to scan that isn’t a stranger’s infrastructure. I built a small local target for this: a fictional freight company, Northbridge Freight Co., running as a plain Python http.server app on loopback. It’s deliberately unremarkable: a marketing homepage, a /admin staff login form, a robots.txt that disallows /admin, /staging, /backup.zip, and /internal-notes.txt (which of course means a recon tool reads robots.txt first and goes straight for the disallowed paths), and that internal notes file itself contains the kind of thing that ends up on a real forgotten staging box: a reminder to rotate a default password, a note that a migration port never got closed.

Real captured output from it, curled directly during this session:

HTTP/1.0 200 OK
Server: Werkzeug/2.2.3 Python/3.10
Date: Sun, 26 Jul 2026 08:19:00 GMT
Content-Type: text/html
Content-Length: 335

And a genuine nmap -sV connect scan against a real listening service (this one’s actually live, not a lab fixture: OpenSSH on the box this series was written on):

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

That’s the pairing this series uses throughout: real tool binaries doing real work against a small, honest lab, cross-checked against Sn1per’s actual source so the description of what the automation would do next is grounded rather than guessed.

Update: this series now has a root-verified companion

Everything above was accurate as far as it went, but it was written from source and from tools run individually, never from a live end-to-end sniper invocation, for the reason stated above. Part 7 reruns the tool for real against a rebuilt lab with genuine root access: airstrike, nuke, and the mass-scan modes, all executed live rather than read from source. The scan-mode descriptions above held up well against that real testing, with one correction significant enough to warrant its own section: recon mode, covered in Part 2, does considerably more at runtime than the subdomain-enumeration script alone suggests. Part 2 has been updated accordingly, and Part 7 has the full detail.

Part 2 goes inside discover mode and traces exactly what commands it strings together, in order, from the ping sweep to the final target list handoff.