Sn1per Deep Dive Part 5: What an Automated Sweep Looks Like From the Blue Team's Side

The first four posts in this series read Sn1per’s own source to establish what it actually does, mode by mode. This post turns that around: given everything Parts 1 through 3 verified about the tool’s default behavior, what does a target’s own logs, DNS provider, and IDS actually see when someone points Sn1per at them. This is the same exercise the AI Pentest Agents series ran against autonomous pentest agents: automation has a noise signature a careful human operator doesn’t, and that signature is detectable well before anything resembling a breach.

Most of the recon phase never touches the target at all

This is worth stating first because it cuts against the intuition that “recon” means “footprints on the target.” Re-reading Part 2’s list of what recon mode’s own source files run: Sublist3r and Subfinder query third-party passive sources, not the target. Amass’s reverse whois queries registration data, not the target. The crt.sh scrape hits Certificate Transparency logs on crt.sh, not the target. Shodan and Censys are queries against those services’ own indexes. Of everything in Part 2, the only pieces that reach infrastructure the target organization actually controls, at the script level, are dnscan’s active brute-force resolution, the massdns bulk resolution pass at the end, and the OSINT-stage dig queries for SPF/DMARC/DKIM records against the target’s own DNS. Part 2 was later corrected once root-verified testing showed the CLI’s -m recon mode chains into a much larger, actively-touching-the-target pipeline than recon.sh and osint.sh alone suggest, so that correction applies here too: the passive picture above describes what the subdomain-enumeration stage specifically does, not everything -m recon triggers end to end.

That has a direct consequence for a defender even accounting for the correction: watching your own web server logs will miss the subdomain enumeration phase specifically, because it never asked your web server anything by itself. What it will hit is your authoritative DNS: a burst of distinct subdomain lookups (many for names that don’t exist) arriving in a tight window, most of them resolving through whatever public resolvers dnscan and massdns are configured to use rather than your own resolvers. A DNS provider or resolver that logs query volume per source, or per requesting pattern, has a much better vantage point on this specific phase than the web server ever will.

Discover mode’s signature is a textbook horizontal scan

Part 2 traced discover mode’s three commands in order: an nmap -sP ping sweep across the whole target range, then a SYN scan against a fixed $QUICK_PORTS list, then a UDP scan against a fixed $DEFAULT_UDP_PORTS list, all from one source, back to back, against every address in the range regardless of whether the previous stage got a response. That’s about as textbook a horizontal-scan signature as exists: one source IP, a burst of ICMP echo requests across a contiguous range, immediately followed by half-open SYNs to the same fixed short port list against every host in that range, immediately followed by UDP probes to a second fixed list. Any NIDS with basic scan-detection thresholds (the kind that ships enabled by default in most commercial IPS products) catches this without needing a signature specific to Sn1per at all, just a rate-of-distinct-destination-ports-per-source-IP counter.

Normal mode’s real exposure: it fires actual exploits, unconditionally, on a banner match

This is the finding from Part 1 worth repeating here because it’s the single highest-value thing for a defender to act on. normal mode’s per-port branches don’t stop at fingerprinting. An open port 21 gets msfconsole runs of exploit/unix/ftp/vsftpd_234_backdoor and unix/ftp/proftpd_133c_backdoor, real exploit attempts, not scanner probes, fired automatically once the port is found open, with no confirmation that the specific version behind that banner is actually vulnerable. Port 22 gets scanner/ssh/libssh_auth_bypass (CVE-2018-10933). Port 135 gets exploit/windows/dcerpc/ms03_026_dcom, an exploit for a vulnerability from 2003.

That last one matters disproportionately. MS03-026 is old enough that its exploitation traffic pattern has been a known IDS/IPS signature for two decades; there is no reasonably current intrusion prevention product that ships without a rule for it. The practical implication: any organization running even a baseline commercial IPS with default signatures will very likely see an alert on a Sn1per normal mode sweep within seconds of the port scan completing on any host with port 135 open, whether or not that host is actually vulnerable to the fifteen-plus-year-old exploit being thrown at it. This is genuinely good news for defenders and worth knowing precisely because it means the highest-signal detection opportunity here costs nothing beyond signatures most IPS deployments already have turned on. Root-verified testing in Part 7 confirmed this pattern directly rather than just from source: a real msfconsole run in nuke mode fired the libssh CVE-2018-10933 module at two OpenSSH targets that were never running libssh in the first place, the same pattern-not-precision behavior described here reproduced live.

The web checks leave a distinctive request pattern too

Part 3’s sc0pe templates aren’t invisible either. Trace_Method_Enabled.sh means an actual HTTP TRACE request goes out, a method essentially no legitimate browser traffic uses. The header-disclosure and CSP/HSTS-absence checks require fetching both the HTTP and HTTPS version of the same resource in quick succession purely to diff their headers, a pattern a real visitor has no reason to produce. And Part 1’s Northbridge Freight lab illustrates a cheap, tool-agnostic heuristic worth building regardless of what’s scanning you: requesting robots.txt and then, within the same short session, requesting every path that file disallows, in close succession, is not something a human visitor does. It’s exactly what an automated recon tool does, because robots.txt’s disallow list functions as a hint file for anything that reads it as one rather than as a request not to look. A web server logging a robots.txt fetch immediately followed by hits on every disallowed path, from the same source, inside a few seconds, has caught something worth looking at regardless of which scanner produced it.

Confirmed with root: brute-force actually gets defeated

This is the strongest defensive-side result from Part 7’s real testing, and it belongs here alongside everything else in this post. nuke mode’s forced bruteforce stage ran two different attacks against SSH on two real Linux lab 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 the same port to Hydra with a 123-entry wordlist, and Hydra didn’t just fail to find a password, it errored out of the attack entirely: “all children were disabled due too many connection errors,” before completing a single full pass. That’s modern OpenSSH’s own connection-rate throttling doing exactly its job against a purpose-built, multi-threaded brute-force tool. It’s worth citing as a positive control alongside everything else in this post: unmodified, current OpenSSH defaults were enough on their own to blunt an out-of-the-box automated brute-force attempt, no additional hardening required.

What this adds up to

None of these signals require Sn1per-specific tooling to catch. Horizontal scan detection, IPS signatures for decades-old CVEs, DNS query volume monitoring, and a simple robots.txt-then-disallowed-path correlation rule are all generic controls that would catch plenty of other automated tools too, Sn1per included incidentally rather than as the specific target. That’s arguably the right way to think about defending against this class of tool in general: Sn1per’s value to an attacker is that it runs a lot of known techniques quickly and without an operator second-guessing any individual step, and every one of those techniques was individually detectable before Sn1per existed. Orchestration doesn’t make the underlying actions quieter, it just makes them happen faster and closer together, which if anything makes the aggregate pattern easier to correlate, not harder. And as Part 7 showed, some of the most basic defensive controls, like connection-rate throttling on SSH, still hold up against exactly the kind of automated attack Sn1per’s nuke mode is built to run.

Part 6 closes this series by running through what a full sweep against the Northbridge Freight lab actually looks like end to end, from the first DNS query to the point where Sn1per’s own logic runs out and a human has to pick up the ghost shells and pivoting technique this site has already covered in the Impacket and Pivoting and Tunneling series.