Cybersecurity research podcast

ZMap: Fast Internet-Wide Scanning and its Security Applications

Durumeric, Wustrow and Halderman built a stateless scanner that made comprehensive, single-port public-IPv4 surveys practical on a commodity machine; on their gigabit system, a scan took about 44 minutes. For exposure teams, that enables repeatable discovery, but an address response does not establish the application or owner, and a single probe can miss responsive web hosts.

Episode 25 Aug 2026 · Paper 13 Aug 2013 · 22nd USENIX Security Symposium (USENIX Security 13) · VERSION of RECORD

Progress will be saved on this device
Listen continuously

Research summary

A technical explanation of the paper's research question, method, reported findings and limitations. On the authors’ gigabit test system, a single-probe scan of public IPv4 took about 44 minutes. Controlled trials estimated that a single probe found nearly all responsive hosts, so high speed did not mean perfect completeness. For comparable single-port…

ZMap turned a public-IPv4 single-port scan into a commodity-scale, repeatable measurement and directly seeded hundreds of papers, Censys, Sonar, and commercial exposure products. It also removed obscurity for adversaries. Modern successors must join IPv4, sampled IPv6, protocol and domain identity, cloud context, ethical operations, and verified remediation; an address hit is not an owned asset or a fix.

Paper details

Authors: Zakir Durumeric , Eric Wustrow , J. Alex Halderman

Transcript

Highlighting follows the podcast. Select any word to seek.

ZMap: Fast Internet-Wide Scanning and its Security Applications. This 2013 work by Zakir Durumeric, Eric Wustrow and Alex Halderman appeared at the USENIX Security Symposium. It addressed the gap between attackers with botnets and legitimate researchers by making comprehensive, single-port scans of public IPv4 practical on one commodity machine. The episode explains how repeatable scanning makes exposure observable, and why scanning alone does not establish ownership, priority or remediation.

ZMap creates probes and checks replies without keeping a connection record for every target in memory. That stateless design matters because a transport-layer response does not prove that the expected application completed a handshake. Later tools added protocol identification, hostname context and application handshakes, including finding services on unexpected ports.

The work investigated whether legitimate teams could make comprehensive single-port public-IPv4 measurement fast enough to repeat routinely on ordinary hardware, without needing a botnet. The authors also tested whether that capability could support real security investigations. One survey measured encrypted web services; another found Internet-accessible devices susceptible to recently disclosed library vulnerabilities. A separate analysis used scan-derived fingerprints to locate most allocated Tor bridges, then warned that certificate and secure-shell key fingerprints could track devices across changing addresses. The same visibility that helps defenders can also remove obscurity for targets.

To cover the address space efficiently, ZMap generated a pseudorandom ordering of IPv4 targets, spreading probes rather than walking through adjacent addresses. It sent fixed probes without storing per-target connection state, embedded a secret value that let it validate replies, and separated the sending and receiving paths. Modules could send connection-opening probes, network-control probes or application-specific connectionless probes. Responsive addresses could then move into a second stage that completed an application handshake.

On the authors’ gigabit test system, a single-probe scan of public IPv4 took about 44 minutes. Controlled trials estimated that a single probe found nearly all responsive hosts, so high speed did not mean perfect completeness. For comparable single-port coverage, ZMap was more than 1,300 times faster than the most aggressive tested Nmap default settings.

In a staged survey of encrypted web services, the team found 34.5 million hosts with the target port open, but identified only 22.8 million as servers speaking the expected encryption protocol. That gap is a concrete reminder that an open port is discovery evidence, not application identity. Another application used scan-derived fingerprints to locate most allocated Tor bridges and warned that certificate and secure-shell key fingerprints could track devices as their addresses changed. In these evaluated applications, high-speed measurement revealed exposed services and located most allocated Tor bridges.

Several boundaries matter. On the technical side, the original analysis judged exhaustive IPv6 scanning infeasible and did not know whether moving to 10-gigabit rates would overload networks. Measurement posed a separate challenge: hostname-dependent encrypted web services weakened results based only on network addresses. Later validation also found that a single ZMap probe missed about 2.7 percent of responsive web hosts, while using observation points in different parts of the network generally helped more than repeating probes from one place. Finally, an address does not reliably establish ownership. Carrier-grade address sharing can put multiple subscribers behind one public address, while cloud load balancers can separate a visible front end from the application owner and origin.

For teams running exposure scans, make traffic identifiable and collect only what is necessary. Avoid authentication attempts, and keep contact and opt-out paths working. Then make each observation actionable. Record where it came from and how confident it is, add cloud and business context, prioritize the risk, and track the response. Notifications can help, but later randomized evidence found that even detailed notices improved remediation only relative to a control group; most contacted operators still did not act. Scanning creates visibility, not verified ownership or a verified fix.

ZMap’s specific contribution was to turn single-port public-IPv4 exposure into a measurement that a small legitimate team could repeat on commodity hardware. Detection engineers, Internet-measurement researchers and attack-surface teams can use that kind of observation to find candidates for deeper investigation. They should verify the application protocol, connect an address to a current owner or cloud resource, and carry findings through remediation workflows. They should not infer that an address hit identifies a single asset, establishes priority, or proves remediation.

Download plain-text transcript