Sn1per Deep Dive Part 2: What Discover and Recon Mode Actually Run

Part 1 covered where Sn1per came from and what its scan modes are, read from the real sniper --help text and the mode scripts that back it. This post goes inside two of those modes specifically: discover, which turns a CIDR into a list of live hosts, and the recon stage that normal mode calls to turn a domain into a list of subdomains. Both are worth reading in full, because the marketing description (“automatic subdomain brute forcing, DNS zone transfer checks”) compresses a genuinely long chain of individual tools into one line, and the order those tools run in, and what happens to their output, is where the actual engineering is.

Everything below is quoted or paraphrased directly from modes/discover.sh, modes/recon.sh, and modes/osint.sh in the 1N3/Sn1per Community Edition, cloned fresh for this series. A significant correction to the recon-mode section below, based on real root-verified execution rather than source reading alone, is covered near the end.

Discover mode: three nmap passes and a handoff

sniper -t <CIDR> -m discover -w <workspace> runs exactly three commands against the range, in order:

nmap -n -sP $TARGET | tee $LOOT_DIR/ips/sniper-$OUT_FILE-ping.txt
nmap -n -v -p $QUICK_PORTS $NMAP_OPTIONS -sS $TARGET -Pn
nmap -n -v -p $DEFAULT_UDP_PORTS $NMAP_OPTIONS -sU -Pn $TARGET

A ping sweep first, to find anything that answers ICMP. Then a SYN scan against $QUICK_PORTS (a short, fast port list defined in sniper.conf, not the full 65535). Then a UDP scan against a separate default UDP port list. Each command’s output is greped for “open” and piped into its own file: sniper-ping.txt, sniper-tcp.txt, sniper-udp.txt. Those three get concatenated, sorted, and deduplicated into one file, discover-sorted.txt, which becomes the actual target list.

The mode doesn’t stop there. Its last real action is:

sniper -f $LOOT_DIR/ips/discover-$OUT_FILE-sorted.txt -m flyover -w $WORKSPACE

discover mode always ends by launching flyover mode against everything it just found. There’s no confirmation step. Point discover at a /24 and, assuming the process has root and everything else it needs, it will find every live host in that range and then automatically start the next stage against all of them. This is the mechanical version of “external attack surface management”: nobody has to remember to scan the host that showed up after the ping sweep, because the tool never stopped to ask.

Recon mode: five subdomain sources merged into one list

recon mode (triggered by -re on normal mode, or standalone) is where domain-to-subdomain expansion happens. Reading modes/recon.sh top to bottom, in the order the script actually runs them:

Sublist3r runs first, a passive subdomain enumeration tool that queries public sources without touching the target directly:

python3 /usr/share/sniper/plugins/Sublist3r/sublist3r.py -d $TARGET -vvv -o $LOOT_DIR/domains/domains-$TARGET.txt

Amass runs twice: once for active enumeration (amass enum -ip, resolving through a bundled resolver list at plugins/massdns/lists/resolvers.txt), and once for reverse whois (amass intel -whois -d $TARGET), which finds other domains registered under the same details as the target, a genuinely different technique from subdomain brute forcing since it works off registration data rather than DNS.

Subfinder runs next, another passive source, feeding the same resolver list.

dnscan, a Python subdomain brute forcer, runs against a wordlist ($DOMAINS_QUICK) if enabled, explicitly flagged in its own banner as slow: “THIS COULD TAKE A WHILE.”

Certificate transparency logs get scraped directly:

curl -s https://crt.sh/?q=%25.$TARGET

crt.sh mirrors the Certificate Transparency logs every public CA has to publish under RFC 6962. Every subdomain that’s ever had a TLS certificate issued for it, by anyone, shows up here, which makes it one of the highest-signal passive sources in the whole chain: it can’t miss a subdomain due to weak DNS wordlists, only one that never had a cert issued.

Shodan and Censys are the two paid/API-gated sources, each returning both subdomains and the IPs behind them if an API key is configured.

Every source’s output funnels into the same accumulation file, then gets run through massdns for bulk DNS resolution against the merged list, and the final deduplicated result is what the rest of the pipeline (port scanning, web scanning) actually targets.

Five sources with genuinely different blind spots, run unconditionally in sequence rather than any one being treated as sufficient, is the actual design here. Sublist3r and Subfinder are both passive and both query broadly overlapping public sources, so in practice they mostly re-confirm each other. Amass’s reverse whois and the crt.sh scrape are the two doing structurally different work: one is following business relationships instead of DNS, the other is exploiting a legal requirement (Certificate Transparency logging) rather than exploiting anything about DNS naming at all. The site’s own Nmap NSE field guide covers what nmap does with a target list once it has one; Sn1per’s contribution up to this point is entirely in building that list in the first place.

OSINT mode: past subdomains, into people and email

osint.sh runs alongside recon when -o is set, and shifts from infrastructure to organization-level information: whois against the target itself, dig-based checks for SPF, DKIM, and DMARC records (a genuinely useful check on its own: a domain with dig _dmarc.$TARGET txt returning nothing has no policy telling receiving mail servers what to do with spoofed mail claiming to be from it), scrapes against ultratools.com and intodns.com for third-party DNS analysis, theHarvester -d $TARGET -b all for email addresses and employee names pulled from search engines and public sources, and a scrape against email-format.com for the target organization’s email naming convention.

None of this touches the target’s own infrastructure. It’s the same OSINT discipline the password cracking series covers from the wordlist-building side: knowing that a company uses firstname.lastname@ rather than flastname@ changes what a targeted wordlist looks like, and Sn1per gathers that signal automatically rather than requiring an operator to go find it by hand.

Correction, verified with root: -m recon runs far more than recon.sh and osint.sh alone

Everything above is an accurate read of what modes/recon.sh and modes/osint.sh contain, and it’s an incomplete description of what actually happens when -m recon is invoked from the command line. Once this series had genuine root access to test against (Part 7), running sniper -t <target> -m recon end to end against a real domain showed the CLI’s recon mode chains into considerably more than subdomain enumeration and OSINT: a full BlackWidow spider of the target, the dozen-category static-analysis pass (XSS, SQLi, SSRF, RCE, IDOR, LFI, SSTI, redirect, and debug 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 the two files this post read directly. 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 the mode name and this post’s original framing suggested.

The practical correction: recon mode is not a safe passive-only flag to reach for when the goal is genuinely just subdomain and OSINT enumeration with nothing touching the target directly. Treat it as running most of web mode’s active checks plus a port scan, and pick the individual tools covered above apart by hand, Sublist3r, Amass, Subfinder, crt.sh, dig, theHarvester, if a truly passive pass is what’s needed. Part 7 has the full real transcript and the reasoning behind stopping that scan once its actual scope became clear.

What this means for the target list

By the time normal mode’s port scanning and per-service checks (Part 1’s port 21/22/23/25/111/135 branches) actually start, the target list they’re running against has already been built from up to seven independent sources: two nmap passes, five subdomain enumeration tools, plus whatever OSINT ran alongside it. None of that is visible in the final report unless you go looking in the loot directory’s domains/ and ips/ subfolders. Part 5 comes back to this specifically: a target list built this way generates a very distinctive pattern of DNS queries and certificate-log-adjacent traffic before a single port scan packet ever leaves the box, and that pattern is detectable well before the scan itself would trip anything.

Part 3 moves to web mode and the sc0pe scoring engine that turns everything these first two modes found into a single vulnerability score per host.