masscan for internet-scale asynchronous TCP port scanning

masscan is an asynchronous SYN-packet port scanner capable of transmitting 10 million packets per second, intended for authorized internet-wide surveying, asset inventory, and exposure research.

Tool	robertdavidgraham/masscan — Internet-scale asynchronous TCP port scanner written in C, ~26k stars, AGPL-3.0
Category	Network reconnaissance / port scanning
Primary Use	Rapid SYN scanning of large IPv4/IPv6 ranges for open-port discovery and banner grabbing during authorized assessments and internet-wide research
Safe Use	Use only on networks and address space you own or have explicit written authorization to test, in labs, internal asset inventories, or documented research scans with exclusion lists
Telemetry Note	Extremely distinctive traffic signature: high-rate randomized SYN packets from raw sockets via libpcap; defenders detect it with rate-based IDS rules, honeypots, and darknet monitoring; RST-heavy flows and never-completed handshakes are telltales

masscan occupies a singular niche in the reconnaissance toolchain: it is a port scanner built for scale rather than depth. Its README opens with the claim that it can scan the entire Internet in under five minutes, transmitting 10 million packets per second from a single machine. That is not a marketing flourish so much as an architectural statement — everything about the tool, from its ad hoc TCP/IP stack to its randomized target ordering, follows from the decision to optimize for asynchronous, high-volume SYN transmission across millions of hosts rather than careful interrogation of one. For operators who already live in nmap, the learning curve is deliberately shallow: parameters and output conventions mirror nmap, and the README explicitly says that features supporting widespread scanning of many machines are supported while in-depth scanning of single machines is not.

The internal design is the interesting part for anyone evaluating the tool professionally. Unlike nmap, which leans on the host operating system's network stack, masscan ships its own userspace TCP/IP implementation. This is what allows it to fire SYNs asynchronously at wire speed, similar in spirit to earlier scanners like scanrand, unicornscan, and ZMap, but with more flexibility in specifying arbitrary port and address ranges. The tradeoff is real, though: because the local kernel also sees returning SYN-ACK packets, it will helpfully answer with RST, killing connections before masscan can act on them. The README is unusually candid about this failure mode and prescribes two mitigations — either give masscan its own source IP with --src-ip, or carve out dedicated source ports with --src-port and firewall them away from the OS using iptables, pf, or ipfw. This is exactly the kind of systems-level detail that separates a scanner you can trust in production from one that will quietly break things.

Installation is refreshingly dependency-free for a tool of this sophistication: a C compiler and make are essentially all you need. On Debian-family systems the workflow is sudo apt-get install git make gcc, then git clone https://github.com/robertdavidgraham/masscan, make, and optionally make install, which drops the binary into masscan/bin. The README notes the source is many small files, so make -j speeds builds considerably — with the caveat that parallel builds can exhaust a Raspberry Pi's 2GB of memory, where -j4 is the safer choice. Portability is broad: Linux is the primary target, but Windows via Visual Studio or MinGW, macOS via Xcode or the command line, and FreeBSD via gmake are all documented, and the author observes that x86 binaries perform well even under ARM emulation on macOS.

Basic invocation follows the familiar pattern. A representative example from the documentation is masscan -p80,8000-8100 10.0.0.0/8 2603:3001:2d00:da00::/112, which scans both an IPv4 and an IPv6 range for port 80 plus the range 8000-8100, printing results to standard output. Note that masscan refuses to guess: there are no default ports, so -p is mandatory, and targets must be raw IP addresses or simple ranges — no DNS names, no nmap's flexible expressions like 10.0.0-255.0-255. A particularly useful introspection feature is --echo, which dumps the fully resolved configuration and exits; that output is itself valid input, enabling a save-modify-replay workflow for repeatable scans.

Beyond open/closed determination, masscan can complete TCP connections and perform banner grabbing across a substantial protocol list: FTP, HTTP, IMAP4, memcached, POP3, SMTP, SSH, SSL, SMBv1, SMBv2, Telnet, RDP, and VNC. This is where the separate-IP or firewalled-port requirement becomes mandatory rather than optional, since banner grabbing requires the connection to survive long enough for the application layer to respond. The README also mentions --heartbleed as effectively a specialized form of banner checking — a reminder that this tool has genuine research pedigree from the era of internet-wide vulnerability epidemiology.

Output handling is thoughtfully engineered for the realities of large surveys. Five formats are supported: XML via -oX, grepable via -oG, JSON via -oJ, a simple list via -oL, and a compact binary format that exists specifically so a full-Internet scan doesn't fill the operator's disk. Binary files are parsed back with --readscan, which can re-emit them as XML. The list format is minimal and machine-friendly — <state> <protocol> <port> <ip> <timestamp> — making it trivial to pipe into downstream tooling, a database, or comparison scripts for tracking exposure drift over time.

The README's section on internet-wide scanning deserves attention because it is unusually responsible for a tool of this class. It states plainly that scanning the entire Internet is bad, that parts of the network react badly to it, and that scan-tracking services will banlist your address space and firewall you off from useful parts of the network. It accordingly promotes --excludefile as a core workflow component, and suggests keeping a persistent exclusion list in the default configuration file at /etc/masscan/masscan.conf so it applies automatically to every scan. Reputable internet-scale research projects — the Censys and Shadowserver school of measurement — follow exactly this pattern of documented exclusions and rate discipline, and operators should treat that as the baseline expectation rather than an afterthought.

Rate control is called out as IMPORTANT in the README's own emphasis, and it is the single most consequential knob. Defaults are conservative: 100 packets per second, which the author notes would take effectively forever against the full IPv4 space. Raising it to --rate 100000 means roughly ten hours per port across the entire Internet. Capability varies by platform — around 300,000 packets/second on Windows or from VMs, and 1.6 million packets/second on bare-metal Linux. The README's phrasing is memorable: that is fast enough to melt most networks, though it consoles that you will only melt your own, since randomization of target IPs spreads load so distant networks aren't overwhelmed. That randomization is permanent and non-configurable — one of several implicit nmap-equivalent settings always in effect.

It's worth enumerating those implicit settings because they explain behavioral surprises. masscan operates as if -sS, -Pn, -n, --randomize-hosts, and --send-eth were permanently set: SYN-only scanning, no host discovery pings (fundamental to async operation), no DNS resolution, always-randomized target order, and raw transmission via libpcap. Running masscan --nmap prints the full list of nmap-compatible options for cross-reference. The XML output format is likewise inspired by nmap, easing integration with existing parse pipelines, though the asynchronous architecture means results semantics differ in places.

From a defensive standpoint, masscan is less a threat to underestimate and more a signal to instrument for. Its traffic signature is loud and characteristic: high-rate, uniformly randomized SYN packets that never complete handshakes, originating from raw sockets. Rate-based anomaly detection, SYN-flood heuristics repurposed for recon detection, honeypots and darknet monitors all catch it readily. Defenders can also fingerprint scanner behavior from the source-port patterns and IP ordering, and network-level rate limiting or tarpits degrade its utility cheaply. For blue teams, masscan is equally useful on the friendly side — it is an excellent tool for continuous internal asset inventory and verifying that exposure policies match reality across owned ranges.

In an authorized workflow, the practical positioning is: masscan for breadth, nmap for depth. Sweep your scoped ranges at a rate your uplinks tolerate, exclude what shouldn't be touched, land results in binary or XML, and hand the interesting host-port pairs to nmap or service enumeration tooling for detailed interrogation. With roughly 26,000 stars, an AGPL-3.0 license, an active CI badge, and a maintainer with deep credibility in internet measurement, masscan remains the reference implementation of asynchronous scanning — a tool whose design decisions teach you as much about network measurement as they do about reconnaissance.

Official project repository for robertdavidgraham/masscan.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.