Masscan Scans Entire IPv4 Internet in One Hour on Gigabit Line

vissago

Stateless packet synthesis allows a single terminal on commodity gigabit fiber to sweep the entire IPv4 address space in under an hour, crashing enterprise firewalls and exposing unprotected infrastructure that defenders fail to monitor.

AI-assisted summary of Massscanning the Internet - Defcon 22 (2014) — original source. Check the original for full context.

Source published: 2014-10-01

Key ideas

• Masscan leverages a stateless architecture and custom TCP/IP stack to scan the entire IPv4 address space across a single gigabit link in roughly an hour at speeds reaching 1,000,000 packets per second. (43:29)
• Enterprise firewalls, switch CAM tables, and intrusion detection systems regularly fail or experience state exhaustion when subjected to line-rate, randomized port sweeps across large IP blocks. (30:04)
• Global vulnerability assessments reveal systemic exposure of embedded hardware, unauthenticated Redis instances, digital billboards, and critical infrastructure, while security teams over-index on noisy inbound alerts rather than compromised outbound responses. (8:07)
• Advanced scanning workflows use decoupled architectures, including spoofed SYN packets routed back to mobile endpoints and distributed cloud fleets to process deep application-layer banners asynchronously. (31:53)

Detailed notes

## Background This presentation was uploaded to YouTube by the channel vissago on October 1, 2014, capturing a talk from DEF CON 22. According to the page description, speakers Rob Graham, Paul McMillan, and Dan Tentler discuss the practical and operational quirks of scanning the entire internet.

## TL;DR Security researchers demonstrate Masscan, an asynchronous, stateless port scanner engineered to probe the entire IPv4 address space in under an hour from a single commodity gigabit connection. The speakers contrast its custom TCP/IP architecture and SYN cookie design against traditional synchronous tools like Nmap, highlighting how bypassing kernel connection state achieves wire-speed throughput. Alongside technical mechanics, the panel explores operational challenges, including handling upstream abuse complaints, crashing fragile enterprise firewalls, and avoiding automated blacklists. They also detail real-world discoveries and scanning pipelines, revealing exposed industrial control hardware, unauthenticated VNC sessions, open Redis databases leaking credentials, and unpatched Heartbleed instances scattered across the internet.

## Atmosphere & style The presentation carries the irreverent, energetic vibe of a classic DEF CON conference, balancing deep technical engineering with casual hacker humor and war stories. The dynamic among Rob Graham, Dan Tentler, and Paul McMillan is loose and collaborative, featuring witty banter about angry sysadmins, broken intrusion sensors, and live demos running actively in the background while they speak. It feels fast-paced, pragmatic, and slightly mischievous, capturing the thrill of treating the entire global IPv4 internet as a local subnet to experiment on in real time.

## Bulletin - [43:29](https://www.youtube.com/watch?v=UOWexFaRylM&t=2609s) Masscan leverages a stateless architecture and custom TCP/IP stack to scan the entire IPv4 address space across a single gigabit link in roughly an hour at speeds reaching 1,000,000 packets per second. - [30:04](https://www.youtube.com/watch?v=UOWexFaRylM&t=1804s) Enterprise firewalls, switch CAM tables, and intrusion detection systems regularly fail or experience state exhaustion when subjected to line-rate, randomized port sweeps across large IP blocks. - [08:07](https://www.youtube.com/watch?v=UOWexFaRylM&t=487s) Global vulnerability assessments reveal systemic exposure of embedded hardware, unauthenticated Redis instances, digital billboards, and critical infrastructure, while security teams over-index on noisy inbound alerts rather than compromised outbound responses. - [31:53](https://www.youtube.com/watch?v=UOWexFaRylM&t=1913s) Advanced scanning workflows use decoupled architectures, including spoofed SYN packets routed back to mobile endpoints and distributed cloud fleets to process deep application-layer banners asynchronously.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=UOWexFaRylM&t=0s) Commodity gigabit uplinks and raw packet generation make scanning the entire 4-billion-address IPv4 space feasible from a single terminal. - [25:40](https://www.youtube.com/watch?v=UOWexFaRylM&t=1540s) Masscan achieves up to 1,000 times the speed of traditional tools like Nmap by eliminating connection state tracking and using asynchronous probe dispatch. - [04:05](https://www.youtube.com/watch?v=UOWexFaRylM&t=245s) Target-space randomization ensures packet drops predominantly occur on local network switches or upstream transit routers rather than target endpoints. - [08:07](https://www.youtube.com/watch?v=UOWexFaRylM&t=487s) Organizations fall victim to the 'streetlight effect' by obsessing over noisy inbound scan alerts while ignoring outbound responses that indicate actual vulnerabilities. - [11:55](https://www.youtube.com/watch?v=UOWexFaRylM&t=715s) Automated abuse reporting systems frequently generate false complaints against scan engines due to misconfigured intrusion detection sensors located outside target IP ranges. - [16:10](https://www.youtube.com/watch?v=UOWexFaRylM&t=970s) Cellular mobile carriers assign publicly routable IP addresses to smartphones, directly exposing consumer mobile devices to internet-wide probes. - [19:38](https://www.youtube.com/watch?v=UOWexFaRylM&t=1178s) Multi-stage scanning pipelines filter out millions of spurious SYN-ACK responders by verifying real services with secondary application-layer probes. - [30:04](https://www.youtube.com/watch?v=UOWexFaRylM&t=1804s) Stateful defensive appliances like Next-Generation Firewalls can suffer total state-table exhaustion and crash when processing randomized high-volume packet bursts. - [31:53](https://www.youtube.com/watch?v=UOWexFaRylM&t=1913s) Split-scanning decouples probe generation from response capture by spoofing a secondary IP address, shielding high-bandwidth scan nodes from abuse takedowns. - [34:40](https://www.youtube.com/watch?v=UOWexFaRylM&t=2080s) Global sweeps indicate that lingering vulnerabilities like Heartbleed concentrate primarily on embedded firmware and unmanaged networked appliances rather than mainstream web servers. - [46:12](https://www.youtube.com/watch?v=UOWexFaRylM&t=2772s) Massive unauthenticated surfaces, including digital billboards, county law enforcement terminals, and active IBM mainframes, remain directly accessible across IPv4. - [47:11](https://www.youtube.com/watch?v=UOWexFaRylM&t=2831s) While brute-forcing the 128-bit IPv6 address space remains mathematically infeasible, targeted scanning relies on allocation heuristics and observed prefix patterns.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=UOWexFaRylM&t=0s) Demystifying Internet-Scale Scanning

Rob Graham took the stage alongside co-presenters Paul McMillan and Dan Tentler, opening with an early-morning joke for the DEF CON 22 crowd, hoping that attendees were still awake from the night before rather than waking up at such an ungodly hour. While McMillan and Tentler worked on setting up live demonstrations in the background, Graham framed the premise of their talk: scanning the entire IPv4 address space. Despite how formidable that sounds, Graham stressed that internet-wide scanning is not actually a monumental technological leap. Instead, it was simply an area where tools historically had not existed because researchers had never bothered to build them.

The landscape shifted once commodity internet service providers began offering gigabit fiber uplinks to everyday users. Viewed through the lens of modern networking speeds, the IPv4 internet is surprisingly compact, consisting of only about four billion addresses. Graham described the visceral thrill of sitting at a terminal, configuring Nmap-style flags, entering the `/0` root subnet as the target, and watching an unbroken torrent of real-time scan results flood across the console. As Rob Graham observed, “This is really an exciting thing to do is to sit down on your command line using Nmap style options and just say I want to scan the subnet the /0 subnet that and immediately start getting results back just watching your screen just flow and flow and flow and flow.”

- Masscan was built to bridge the gap between traditional port scanners and modern gigabit uplink capabilities. - The entire IPv4 internet consists of approximately 4 billion IP addresses, making a comprehensive `/0` sweep feasible from a single high-speed terminal. - Traditional tools lacked native high-speed architectures, whereas Masscan leverages raw packet synthesis to stream responses back in real time.

---

[01:09](https://www.youtube.com/watch?v=UOWexFaRylM&t=69s) The Dual Motivations: Defense and Exploration

Turning to the rationale behind internet-scale scanning, Graham outlined clear benefits for both defensive administrators and offensive security researchers. From a defensive posture, enterprise tools frequently collapse under massive scale. While Nmap remains a staple, scanning hundreds of thousands of internal and perimeter systems with it can take days or weeks. In contrast, Masscan can blast through a 100,000-host enterprise perimeter in mere minutes, which proved essential when organizations scrambled to locate OpenSSL instances vulnerable to Heartbleed. Internet-wide surveys also provide empirical answers to systemic threats, such as enumerating misconfigured NTP servers weaponized in distributed denial-of-service amplification attacks, assessing botnet exposure when vendors like D-Link publish critical router flaws, or analyzing global SSL certificate renewal cadences in the aftermath of major disclosures.

For researchers and offensive practitioners, the motivation often centers on raw discovery and probing the unindexed "deep net"—systems that search engines like Google never crawl. By invoking banner-grabbing features, researchers can locate exposed, hackable devices within minutes of initiating a scan. Graham highlighted the sheer unpredictability of scanning 65,000 potential ports, noting that choosing an arbitrary port often reveals bizarre exposed machinery, including Siemens industrial control systems governing power generation plants or millions of smart home automation appliances operating on obscure ports like 7468. Dan Tentler chimed in to ask the audience if anyone remembered the port number for a newly publicized iPhone backdoor service in the 62,000 range so they could scan the entire planet for it live on stage. Emphasizing the psychological shift that comes from scanning the globe, Rob Graham stated, “We really don't appreciate how small the internet is until we've typed in /0 and run our scan.”

- Scanning for Heartbleed across 100,000 enterprise hosts takes minutes with Masscan compared to hours or days with conventional scanners. - Comprehensive internet sweeps allow researchers to quantify DDoS amplification risks (such as vulnerable NTP daemons) and measure unpatched residential routers. - Using banner enumeration (`--banners`) reveals unindexed infrastructure, industrial SCADA equipment, and exposed embedded devices that search engines cannot discover.

---

[04:05](https://www.youtube.com/watch?v=UOWexFaRylM&t=245s) Bandwidth Overhead, Switch Limits, and Sharding

When users decide to fire up a scanner on an unmetered VPS or a commercial ISP uplink, they quickly encounter the physical realities and quirks of packet transport. On a gigabit Ethernet link, the maximum theoretical throughput for standard scanning is roughly 476 Mbps rather than the full 1,000 Mbps. Because TCP SYN scanning relies on transmitting enormous volumes of tiny probe packets, the per-packet Ethernet framing, preamble, inter-packet gap, and IP/TCP headers consume far more wire bandwidth than the payload itself. At maximum line rate, a gigabit pipe equates to roughly 1.488 million packets per second. However, physical switches almost never sustain that pace during scanning bursts. Rob Graham admitted, “I just know that when I connect I get between 300,000 to maybe 800,000 packets per second I'm not getting what Ethernet tells me I should get even on a well-configured switch that's got nothing on but my but me I don't get the full bandwidth I don't know why.”

Upstream peering arrangements and hosting providers introduce further complications. While some ISPs remain oblivious to outbound micro-packets—sometimes billing a customer for merely a few megabytes after a full sweep of the planet—others enforce strict peering ratios that react harshly to relentless streams of 64-byte packets. Even high-capacity networks can struggle; Graham recalled the Chaos Computer Club conference featuring a 100 Gbps pipe, noting that even with 10 GbE network cards, pushing millions of small packets strains routing hardware and violates carrier agreements. Virtual private servers frequently buckle under the I/O load, and transit routers drop traffic along the path. Because all major modern mass-scanners randomize target ordering across the address space, dropped packets almost never occur at the destination endpoint; packet loss happens locally or within the immediate transit hops. To achieve reliable results without swamping local gear, Graham recommended distributing the load across multiple geographically separated VPS instances using built-in sharding flags.

```mermaid flowchart TD accTitle: Masscan Sharded Architecture and Transit Bottlenecks accDescr: Diagram illustrating distributed Masscan scanning across multiple VPS instances and intermediate network bottlenecks. subgraph DistributedNodes ["Distributed VPS Probes"] N1["Tokyo Node (--shard 1/3)"] N2["Dallas Node (--shard 2/3)"] N3["Paris Node (--shard 3/3)"] end subgraph LocalBottlenecks ["Transit and Switching Limits"] SW["Local Switch (Bottlenecks to 300k-800k pps)"] PEER["ISP Transit / Peering (Small-packet ratio limits)"] end subgraph GlobalInternet ["Target Address Space"] TARGETS["IPv4 Targets (Randomized /0 Space)"] end N1 --> SW N2 --> SW N3 --> SW SW --> PEER PEER --> TARGETS ```

- A gigabit Ethernet connection maxes out at approximately 1,488,000 packets per second for 64-byte probe frames, yielding an effective TCP/IP payload rate around 476 Mbps. - Real-world enterprise switches frequently throttle or drop scan packets, dropping actual output to between 300,000 and 800,000 packets per second. - Target addresses are pseudo-randomized so destination networks do not experience packet loss; packet drops occur almost exclusively on the scanner's local link or upstream provider. - Scanning workloads can be divided cleanly across distinct datacenters (such as Tokyo, Dallas, and Paris) by passing native sharding arguments like `--shard 1/5`.

---

[08:07](https://www.youtube.com/watch?v=UOWexFaRylM&t=487s) Abuse Complaints, IDS Signatures, and Asymmetric Monitoring

The most significant operational obstacle to mass scanning is not bandwidth or processing power, but the inevitable flood of abuse complaints. Modern hosting providers and ISPs face automated abuse reporting systems targeting scanning, scraping, and spam. Even when an upstream provider is technically sympathetic to security research, they often have their hand forced: external networks will routinely blacklist their autonomous system number (ASN) or threaten to sever peering agreements if outbound port scanning continues unchecked. Scanning for active vulnerabilities such as Heartbleed triggers intrusion detection systems worldwide, causing security teams to panic and file emergency complaints. Graham noted that conducting a monthly Heartbleed sweep across the 300,000 remaining vulnerable systems generated staggering volumes of abuse tickets—though humorously, running a standard Tor exit node still managed to draw even more hostility from network operators.

To mitigate complaints and prevent systems from automatically getting added to fail2ban blocks during HTTP probes, Graham urged researchers to configure custom headers via `--user-agent` that politely explain the nature of the research project. Modifying scan signatures to bypass strict intrusion detection rules is also worthwhile, not out of malice, but simply to keep system administrators from panicking over harmless research sweeps. Graham criticized the common industry obsession with monitoring inbound perimeter probes, likening it to the classic joke of the drunk looking for his lost keys under a streetlight simply because the illumination is better there. Organizations fixate on inbound IDS alerts because internet background radiation constantly triggers them, but meaningful defense requires monitoring outbound responses. Rob Graham highlighted this disconnect: “And that's what most organizations do these days is they monitor the inbound attacks for hackers because the light's better because they you put an IDS on the wire and immediately you see alerts coming up because people are there's always this background radiation of someone's doing something on the internet sending you packets and you'll get events the light's better on the inbound side but the detection you really want is on the outbound side what is all the response.”

- Monthly Heartbleed surveys uncovered approximately 300,000 vulnerable servers worldwide, triggering massive volumes of automated IDS abuse reports. - Tor exit nodes operate at an abuse complaint volume that rivals or exceeds global vulnerability scanning sweeps. - Automated defenses like fail2ban frequently blacklist web probes unless scanners customize their request metadata by setting informative `--user-agent` strings. - Network defenders suffer from the "streetlight effect" by focusing on noisy inbound scan probes rather than analyzing outbound responses that indicate actual compromises or data leaks.

[11:14](https://www.youtube.com/watch?v=UOWexFaRylM&t=674s) Heartbleed Inbound vs. Outbound Monitoring and ISP Pressure

Rob Graham points out a major failure in enterprise detection postures regarding Heartbleed: organizations monitor inbound traffic to see whether scanners are probing them, but fail to monitor their own outbound responses confirming that they are indeed vulnerable. As Graham remarks, “they're monitoring our inbound stuff saying that are you vulnerable and not monitoring the outbound stuff saying yes we are and that's really really bad.”

Internet Service Providers (ISPs) are under intense pressure when mass scanning occurs, particularly because the Department of Defense (DoD) gets extremely upset. When DoD officials in suits arrive at an ISP’s office to demand that traffic ceases, the ISP immediately passes that pressure directly down to the researchers, demanding that those specific address ranges be excluded from future sweeps.

[11:55](https://www.youtube.com/watch?v=UOWexFaRylM&t=715s) Exclusion Lists, BGP Data, and Broken Sensor Logic

Handling exclusion requests in Masscan is straightforward and mirrors Nmap’s methodology. The tool accepts a configuration file or command-line parameters specifying an exclude list of IP address ranges. The file supports inline comments, allowing the operators to maintain a sprawling record of every network that has submitted an abuse complaint. Whenever a complaint arrives, the team responds cordially, explaining that they are conducting legitimate security research, and offers to add the requester's IP ranges to the exclude list.

While the team would love to publish a public exclude list, almost every organization asking to be removed explicitly refuses to have their exclusion publicized out of fear that attackers will discover their network blocks. As Paul McMillan points out, this secrecy is fundamentally misguided because organizations assume that hiding their ranges prevents attackers from finding them, yet Hurricane Electric's BGP portal (`bgp.he.net`) indexes and provides this routing information publicly in an easily searchable format.

```mermaid flowchart TD accTitle: Exclusion List Pipeline accDescr: Workflow from incoming abuse complaints to updating Masscan exclude configurations.

subgraph INTAKE["Complaint Intake"] A["Incoming Abuse Complaint"] --> B{"Contains IP Ranges?"} B -- "No" --> C["Lookup ASN / Ranges on bgp.he.net"] B -- "Yes" --> D["Extract Target CIDR Blocks"] C --> D end

subgraph CONFIG["Engine Configuration"] D --> E["Add to Masscan Exclude File"] E --> F["Annotate with Comments & Context"] F --> G["Masscan Skips IP Ranges on Next Run"] end ```

The speakers describe the sheer absurdity of automated Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) abuse complaints. Security appliances deployed across disparate subnets, netblocks, and upstream ISPs routinely dispatch automated notices crying foul over a single SYN packet. In one scenario, a target’s automated abuse messages demanded the removal of their public-facing frontend IPs, yet their monitoring sensors sat on completely different, unlisted networks. As a result, subsequent scans hit the unlisted sensors, generating duplicate complaints demanding the exclusion of addresses that were already excluded. As Dan Tentler vents about the broken logic: “we kept doing scans and their sensors would keep picking up scans and keep complaining for us to take off IPs that were already in the block list and we're like we don't know what you guys are take your crack back to the dealer you got bad crack like tell them you want better crack stop”.

- Masscan exclude lists function identically to Nmap using configuration parameters or an exclude file with full comment support. - Quoting Dan Tentler on hyper-sensitive defenses: “sorry I didn't know a single SYN packet was malicious but you know whatever... it's malicious a single SYN packet it's malicious internet is over”. - Defenders often refuse to disclose their IP ranges while demanding exclusions, forcing the scanners to look up their ASNs and prefixes on `bgp.he.net`.

[14:14](https://www.youtube.com/watch?v=UOWexFaRylM&t=854s) Paranoid Defenders and the Illusion of Targeted Attacks

When conducting internet-wide scans, defenders frequently suffer from confirmation bias because they refuse to believe anyone is actually scanning the entire IPv4 space. An organization might operate well-known corporate IP blocks alongside an obscure, unlinked subnet that was supposed to remain hidden. When Masscan traverses the entire IPv4 address space uniformly, hits both ranges, and flags their services, the defenders assume they are being singled out by an advanced, targeted adversary who somehow mapped their secret internal infrastructure.

Rob Graham illustrates this defender panic with an incident from six months prior. While scheduled to appear as a guest on a podcast, Graham kicked off an internet-wide scan the evening before the show. One of the podcast hosts began tweeting late at night about being jolted awake for an emergency bridge call because his organization was actively under attack. Once the host realized the probe was simply Graham's scan hitting their infrastructure, he had to talk down the incident responders so everyone could go back to sleep. Graham notes that the host's team adapted, so that “whenever I do a scan the the the ticket gets opened up it immediately gets closed is just Rob scanning again.”

[16:10](https://www.youtube.com/watch?v=UOWexFaRylM&t=970s) The Australian Freakout and Becoming `internetpolice.us`

Dan Tentler shares an ordeal that occurred during ShmooCon in February, where the team sat in the hotel lobby until 3:00 AM running mass scans (tentatively for VNC). Tentler hosts his scanning rig with a friend who operates a boutique ISP, a necessity because mainstream tier-1 transit providers will instantly terminate service if a customer requests 800 Mbps of bandwidth solely to scan the internet. Because of this personal relationship, Tentler makes a point of being transparent about scan schedules so his upstream provider can field the inevitable blowback.

The morning after the ShmooCon scan, Tentler’s ISP called to warn him about an aggressive system administrator from Australia who was completely outraged over receiving a solitary SYN packet. Although the ISP cordially replied with links to Tentler's project documentation explaining the benign research context, the Australian administrator was shocked that an actual human responded to an abuse complaint. The administrator flew into an uncontrollable rage, screaming over the phone and threatening to call the "internet police." Seizing on the absurdity, Tentler acted immediately: “3 hours later I own internetpolice.us and now my scans come from internetpolice.us”.

- Tentler’s scanning footprint pushes roughly 800 Mbps of raw SYN traffic. - Scanning mobile carrier IP pools (such as Verizon and AT&T) exposes cell phones directly to public routing, prompting Tentler to joke: “your phone is directly connected to the internet and we will be touching you against your will wherever your phone may be”. - Running a live scan on stage against port 6278 (associated with an Apple/iPhone backdoor rumor) yielded roughly 542,000 responding IPs, which later climbed to 902,000.

[19:38](https://www.youtube.com/watch?v=UOWexFaRylM&t=1178s) Multi-Stage Scanning and Open Redis Instances

A major complication in large-scale measurement is the presence of 1 to 2 million devices on the internet—such as misconfigured firewalls, routers, and load balancers—that return a SYN-ACK to literally every single probe regardless of port. Because of this, internet-scale scanning must be executed in multiple sequential stages rather than relying on a single raw port sweep.

```mermaid flowchart LR accTitle: Two-Stage Scanning Methodology accDescr: Stage 1 high-speed SYN sweep feeding into Stage 2 application-layer validation.

subgraph STAGE1["Stage 1: Broad Sweep"] A["Masscan SYN Sweep"] --> B["Identify Raw Responders"] end

subgraph FILTER["Artifact Elimination"] B --> C{"Responds to Every Port?"} C -- "Yes" --> D["Discard False Responder"] end

subgraph STAGE2["Stage 2: Protocol Deep-Dive"] C -- "No" --> E["Secondary Inspection"] E --> F["Connect & Issue Commands"] F --> G["Collect Unauthenticated Data"] end ```

The first pass uses Masscan to perform a blisteringly fast SYN sweep across the target port to discover raw responders. Once candidates are identified, a secondary process connects at the application layer to validate the service and eliminate devices that simply answer everything.

Tentler illustrates this two-stage pipeline using Redis as an example. Masscan discovers thousands of exposed Redis instances. The secondary process establishes a connection and issues the native `MONITOR` command. While properly secured systems prompt for authentication (which the scanner ignores), an alarming number of databases run wide open without authentication. In those instances, the `MONITOR` stream dumps live credit card numbers, Facebook session cookies, and Twitter session cookies directly across the wire in plaintext. Tentler laments the architectural disconnect where organizations deploy heavily hardened frontends with dual-factor authentication, SSL, and OAuth, while leaving backend data transports completely open and unencrypted to the public internet. Furthermore, the secondary pass demonstrates massive drop-offs from initial port hits: an initial sweep might surface several million raw SYN-ACKs, but only a fraction prove to be real, functional services once protocol-level handshakes occur.

[21:16](https://www.youtube.com/watch?v=UOWexFaRylM&t=1276s) Defensive Misconfigurations and Absurd Abuse Responses

When reviewing large-scale scan results that yielded several million responses for what should have been around 200,000 active hosts, the presenters realized that many perimeter devices were configured to listen and answer on every single TCP port. Dan Tentler noted that certain security appliances—such as Check Point firewalls—offer defensive features designed to thwart scanners like Nmap by responding to every connection request to create confusion. However, facing an 8 Gbps mass scan, this defensive strategy backfires disastrously, often crashing the state tables of firewalls and intrusion detection systems. Tentler joked about late-night scanning sessions in hotel lobbies while an administrator somewhere watched their infrastructure burn: “I'm thinking that like we're doing these in a, you know, in the hotel lobby tinkering around at 3:00 in the morning, and somewhere there's a guy with his head on fire cuz his IDS went down or his firewall went down.”

The team highlighted the absurdity of the complaints they receive in response to scans. Many administrators send boastful notes declaring they have blocked the scanner's IP, prompting Paul McMillan to dismiss them as irrelevant: “So one of my favorite complaints I get back is the one saying, uh, to the effect of, 'We've blocked you at the firewall, na-na-na-na-boo-boo,' of like, I don't care, I don't even know who you are, I don't really care.” Rob Graham added that abuse handling frequently reveals broken organizational processes, pointing to a recurring notice from a South Korean financial group that claimed to be a Class A National Security Objective Facility. Each time Graham scanned their range, the company's automated ticketing system replied by CCing every internal sysadmin in the enterprise, inadvertently handing attackers a comprehensive, ready-made employee directory for spear-phishing campaigns.

- Several defensive products attempt to thwart port scanners by sending SYN-ACK responses on all 65,535 ports, which causes them to exhaust their own state tables when targeted by multi-gigabit scans. - An unnamed South Korean financial institution routinely exposes its entire systems administration staff by CCing every internal operator on external abuse notifications.

[23:00](https://www.youtube.com/watch?v=UOWexFaRylM&t=1380s) ISP Relations, SWIP, and the Fake Internet Police

To manage external scrutiny, the researchers emphasize working closely with upstream network providers rather than hiding. By utilizing the Shared Whois Project (SWIP), operators can have their public IP address ranges explicitly assigned to their own names in ARIN or RIPE databases. In theory, this directs all incoming abuse tickets to the scanner instead of burdening upstream network engineers. In practice, however, complainants still forward reports indiscriminately to any administrative contact uncovered in WHOIS or DNS records, including the upstream ISP and irrelevant postmaster addresses. McMillan cautioned against using legitimate corporate email addresses for registration, as security teams routinely spray abuse notices to every contact associated with any query result.

Meanwhile, Dan Tentler shared an update on his project, `internetpolice.us`, which he maintained as a landing page for bewildered administrators investigating inbound scans. The site had briefly gone offline because Apache was not running, prompting laughs from the panel. Tentler noted that the webpage featured a mock complaint form that silently discarded all user input. Despite receiving low-effort SQL injection and cross-site scripting attacks from frustrated visitors, Tentler mused about the comedic potential of logging what sysadmins actually wrote: “I can't imagine if people have tried to fill this form out and what went into it, because that would be like a whole Tumblr feed, like security reactions, just what goes in that form, that would be so rad.”

- Utilizing SWIP assigns IP block ownership directly to the scanner, reducing uncoordinated upstream transit disconnects. - Nearly 50% of abuse reporters ignore dedicated abuse mailbox fields in SWIP records and continue CCing upstream transit providers and arbitrary postmaster aliases. - Running anonymous scans through budget virtual private server (VPS) providers funded with Bitcoin frequently leads to prompt account termination, whereas major providers like Linode accommodate responsible scanning if approached transparently with verified credentials and throttled transmission rates.

[25:40](https://www.youtube.com/watch?v=UOWexFaRylM&t=1540s) Masscan Architecture: Asynchronous Scanning and SYN Cookies

Rob Graham explained the fundamental architectural difference between traditional scanners like Nmap and Masscan. Nmap operates synchronously: it dispatches a probe to a host, waits for a response, and handles retransmissions if packets drop before advancing to the next target. This stateful, serialized design makes Nmap exceptionally thorough for detailed analysis of small network segments, but severely bottlenecks large-scale operations. Masscan, by contrast, operates asynchronously, borrowing the architectural paradigm of high-throughput web servers like Nginx versus process-bound servers like Apache. It transmits raw SYN packets at full line rate without holding connection state in RAM.

```mermaid flowchart TD accTitle: Masscan Stateless Scanning Mechanism accDescr: Diagram contrasting Nmap's stateful scanning queue with Masscan's stateless SYN-cookie verification.

subgraph NMAP["Nmap: Synchronous & Stateful"] N1["Send SYN probe to Target"] --> N2["Maintain record in local RAM"] N2 --> N3["Wait for SYN-ACK or timeout"] N3 --> N4["Scan next port / host"] end

subgraph MASSCAN["Masscan: Asynchronous & Stateless"] M1["Generate SYN with crypto cookie"] --> M2["Transmit immediately at wire speed"] M2 -.->|"No memory allocated for waiting"| M3["Target receives probe"] M3 --> M4["Target returns SYN-ACK"] M4 --> M5["Validate SEQ/ACK via cookie formula"] M5 --> M6["Log open port without state lookups"] end ```

By discarding state tracking, Masscan can generate four billion packets without running out of memory. To identify valid returning traffic without maintaining a four-billion-entry lookup table, Masscan generates TCP initial sequence numbers using a cryptographic SYN cookie algorithm. When a target host responds with a SYN-ACK, the scanner verifies the acknowledgment number against its internal hashing parameters to confirm that the response corresponds to a legitimate outgoing probe. Graham emphasized that the choice of tool depends entirely on scope: “The only reason that you're using Masscan is because of you want to do million-node networks or billion-node networks.”

- Nmap is stateful and synchronous, tracking active probes in memory and retransmitting lost packets, which caps its throughput on massive CIDR blocks. - Masscan transmits packets without buffering connection state, validating incoming SYN-ACK replies strictly via calculated TCP SYN cookies. - Masscan scales linearly to multi-gigabit speeds, achieving scans up to 1,000 times faster than synchronous scanning engines.

[26:59](https://www.youtube.com/watch?v=UOWexFaRylM&t=1619s) Custom TCP/IP Stacks, Banner Checking, and Sharding

A critical design consideration in Masscan is that it incorporates its own custom TCP/IP stack that bypasses the operating system's kernel network subsystem. While this enables extreme speed, it introduces operating system conflicts when performing banner grabbing or full TCP handshakes. Because the underlying kernel has no knowledge of the outgoing SYN packet generated by Masscan, it treats incoming SYN-ACK replies from targets as unsolicited connections and immediately sends a TCP RST packet to tear them down. To prevent the host OS from killing connections before banners or SSL certificates can be collected, operators must configure an `iptables` rule to drop outgoing RST packets or configure Masscan to transmit using a dedicated, secondary IP address that the host OS stack ignores.

```mermaid flowchart LR accTitle: Operating System Kernel RST Conflict accDescr: Shows how the host kernel interrupts Masscan's banner grabbing unless an iptables rule or separate IP is used.

subgraph Host["Scanning Host Machine"] MS["Masscan Custom TCP Stack"] OS["Host OS Kernel Network Stack"] end

Target["Target Server"]

MS -->|"1. Raw SYN packet"| Target Target -->|"2. SYN-ACK response"| OS OS -->|"3. Unsolicited! Sends RST (kills connection)"| Target MS -.->|"Blocked from receiving Banner/Cert"| Target ```

Graham noted that basic operation requires defining the source IP address, source port ranges, and the local router's MAC or gateway IP address. For banner grabbing, Masscan foregoes Nmap's heavy NSE scripting engine in favor of a lightweight `--hello-string` parameter. Operators can encode raw request payloads—such as proprietary industrial control commands—into a file and instruct Masscan to transmit the payload immediately upon establishing a TCP connection. Additionally, large-scale scanning campaigns can be split across dozens of physical machines using the `--shard <index>/<total>` argument, which mathematically partitions the pseudorandom target sequence so multiple systems scan distinct slices of the Internet without duplicating effort.

- Masscan's custom TCP/IP engine bypasses the host operating system kernel, causing the kernel to automatically transmit TCP RST packets when targets return a SYN-ACK. - The RST conflict is mitigated by implementing firewall drop rules or binding Masscan to an auxiliary IP address unmanaged by the host OS. - Banner inspection supports custom network protocols using `--hello-string <filename>`, enabling users to extract responses from niche industrial control devices. - Scanning tasks can be evenly distributed across a cluster of systems using the `--shard` directive without coordinating via a central server.

[30:04](https://www.youtube.com/watch?v=UOWexFaRylM&t=1804s) Stress-Testing Firewalls and the Infinite Loop

The panel discussed how Masscan’s extreme packet volume makes it an unintentional stress-testing utility for network perimeters. Dan Tentler shared an experience testing enterprise Next-Generation Firewalls (NGFW) with deep packet inspection features during a client deployment. When he pointed Masscan from a standard laptop at a non-existent external IP subnet behind the firewall, the device's state inspection engines immediately choked: “One NGFW had Active Directory authentication, and all of its little gauges went to 100%, and AD broke and it never came back.” A competing vendor's firewall also pegged its CPU gauges to 100% and dropped traffic, recovering only after Tentler killed the scan with Ctrl+C. Tentler also admitted to accidentally exhausting a switch's CAM table in a customer production environment due to excessive MAC and IP state generation.

```mermaid flowchart TD accTitle: Network Appliance State Table Exhaustion accDescr: Flowchart illustrating how Masscan overwhelms stateful inspection engines.

M["Masscan Engine"] -->|"Massive stream of SYN packets"| FW["Next-Generation Firewall (NGFW)"] FW -->|"Deep Packet Inspection (DPI)"| AD["Active Directory Auth Subsystem"] FW -->|"State Table Allocation"| ST["Connection State Table"]

ST -->|"Exhausted (>100k sessions)"| Crash["Packet Dropping & Appliance Freeze"] AD -->|"Query Queue Overwhelmed"| Lockup["Authentication Service Failure"] ```

Rob Graham pointed out that while Masscan easily transmits millions to billions of packets in minutes, conventional network appliances begin experiencing severe performance degradation once their active state tables exceed 100,000 connections. To push this stress testing further, Masscan includes an `--infinite` flag. When this parameter is supplied, the scanner seamlessly loops back to the start of its scanning range as soon as it completes, leaving all unclosed TCP connections open in memory across iterations. This enables an operator to sustain upwards of 100 million concurrent TCP states against a target environment. Finally, Graham remarked that for managing the massive datasets generated by these runs, he prefers writing directly to raw binary output using the `--slob` format rather than parsing plain text.

- Stateful inspection devices and Next-Generation Firewalls routinely exhaust memory and crash when subjected to Masscan traffic due to deep packet inspection overhead. - Masscan can trigger MAC address table (CAM) exhaustion on enterprise switches when operating across broad IP and port spaces. - The `--infinite` option causes Masscan to loop through its target range continuously, holding open previous TCP connections to simulate over 100 million concurrent sessions. - High-rate scanning output is most efficiently preserved using Masscan's native binary format (`--slob`) rather than human-readable text logs.

[31:53](https://www.youtube.com/watch?v=UOWexFaRylM&t=1913s) Split-Scanning with Burner Phones and Spoofed Syns

Rob Graham explains an obscure feature of masscan: saving results in binary format and re-reading them later using the `--rescan` parameter to convert the data into XML, JSON, or text. Moving on to an unconventional scanning architecture discussed with Paul McMillan, Rob details how to split transmission and reception across completely separate networks. A high-bandwidth colocation facility with a gigabit pipe transmits outbound SYN packets at wire speed while spoofing the source IP address of a mobile burner device, such as an inexpensive phone. When internet targets respond, the SYN-ACK packets return at a far lower rate directly to the phone. The primary operational benefit of this decoupled design is abuse mitigation: upstream complaints are routed to the burner phone’s cellular carrier rather than putting the high-speed colo account at risk.

Rob tested this concept using a jailbroken "Ninja Telephone" running masscan compiled for the command line. While T-Mobile blocked the inbound traffic behind a stateful firewall, Clearwire allowed the setup to function properly. Although Clearwire blocks incoming SYNs, it allows unsolicited incoming SYN-ACKs through its edge, permitting masscan to complete the handshake. Because masscan uses a deterministic mathematical seed to generate and validate SYN cookies asynchronously, the receiver verifies whether an incoming packet belongs to the active scan. Once validated, the mobile endpoint can establish a full TCP connection, allowing deep protocol operations such as grabbing SSL certificates or probing for vulnerabilities like Heartbleed. Meanwhile, the raw, multi-gigabit traffic volume originates entirely from the distant colo servers.

```mermaid flowchart LR accTitle: Asymmetric Masscan Architecture accDescr: High-bandwidth colo sends spoofed SYNs while targets send SYN-ACK replies back to a burner mobile device.

subgraph SENDER["Colocation Facility"] C["High-Speed Colo Server<br/>(1 Gbps Pipe)"] end

subgraph TARGETS["The Internet"] T["Target Hosts"] end

subgraph RECEIVER["Mobile Endpoint"] M["Burner Phone / Clearwire<br/>(Masscan Receiver)"] end

C -->|"1. Blasts SYN packets<br/>(spoofs Phone IP)"| T T -->|"2. SYN-ACK responses flow back"| M M -->|"3. Validates SYN cookie seed<br/>& completes TCP connection"| T ```

- Clearwire passes unsolicited SYN-ACK responses through its firewall, while T-Mobile drops them completely. - Verizon is believed to assign public, reachable IP addresses to prepaid devices, making it a viable target for split-scanning. - The panel jokes about using this asymmetric architecture across submarine fiber cables to mystify the NSA: “Set up your phone on the other side of some ocean and just send all the results over there and watch them what the hell is going on.”

---

[34:40](https://www.youtube.com/watch?v=UOWexFaRylM&t=2080s) Exposed Law Enforcement Systems, Mainframes, and Heartbleed

Transitioning to scan findings, Rob presents an image captured by an automated screenshotting pipeline built by Paul. The slide displays an unprotected remote desktop window from a law enforcement agency: “County warrant processing system something or other State Police. The derp is very strong.” Paul contacted an intermediary to report the open host immediately, noting that while the agency likely passed standard regulatory compliance checks, nobody had realized that leaving an unauthenticated Remote Desktop Protocol (RDP) session directly accessible to the open internet was a critical security failure.

``` +--------------------------------------------------------------+ | COUNTY WARRANT PROCESSING SYSTEM - [STATE POLICE] | | | | [!] Remote Desktop Protocol (RDP) listening publicly | | [!] Authentication: NONE REQUIRED | | | | Status: Reported to emergency contact and removed | +--------------------------------------------------------------+ ```

Rob also reviews the ongoing fallout from the Heartbleed vulnerability, sharing that approximately 300,000 systems remain unpatched globally. An analysis of the SSL certificate subject names returned during scanning reveals that the vulnerable surface consists largely of embedded appliances rather than traditional web servers. These include thousands of QNAP and Synology Network Attached Storage (NAS) boxes—such as the Synology TS series—alongside Hikvision surveillance cameras. Because these devices rarely possess dedicated domain names and are mapped exclusively to raw IP allocations, vulnerability discovery requires whole-internet port scanning rather than DNS enumeration. Rob and Dan Tentler also highlight another researcher maintaining a Tumblr feed dedicated to scanning internet-connected IBM mainframes, revealing active installations belonging to departments of motor vehicles, pharmacies, and critical infrastructure exposed directly to the public web.

---

[36:55](https://www.youtube.com/watch?v=UOWexFaRylM&t=2215s) Paul McMillan's Distributed VNC Screenshot Pipeline

Attempting to run a live demonstration on stage, the team encounters network issues with their primary scanning host, `internetsurvey2.arc.com`. While Rob sets up a local alternative, Paul explains the mechanics of his distributed internet screenshot scanner. The pipeline separates discovery from payload processing using an asynchronous queue:

```mermaid flowchart TD accTitle: Distributed VNC Capture Architecture accDescr: Masscan scans port 5900, pushes open IPs into a Redis queue, and cheap cloud workers capture screenshots.

A["Masscan on Friendly Host<br/>Scans Port 5900 (VNC)"] -->|"IPs with port 5900 open"| B[("Redis Queue")]

subgraph WORKERS["Elastic Cloud Fleet (~100 Nodes @ $0.16/hr)"] W1["Worker: Connects & probes VNC auth"] W2["Worker: Connects & probes VNC auth"] end

B --> W1 B --> W2

W1 -->|"Auth bypassed: capture frame"| C[("Image Queue / Web Results")] W2 -->|"Auth bypassed: capture frame"| C ```

Paul scans TCP port 5900 (VNC) across the entire IPv4 space in 15 to 20 minutes from a friendly hosting provider. Rather than having the high-speed scanning machine execute protocol interactions, the resulting open ports are dumped into a Redis queue. A pool of cloud worker instances pulls IPs from the queue, connects to each target, and evaluates the VNC handshake. If the VNC server explicitly indicates that no authentication is required, the worker captures a frame buffer screenshot and pushes the image into a result pipeline intended to be viewed at `results.survey.tx.a`. Paul notes that while the full configuration typically uses around 100 cloud nodes costing roughly $0.16 per hour each, he had to rebuild the deployment shortly before the presentation after losing access to his original staging servers two hours prior.

- The VNC worker script checks for explicit passwordless access: “If the VNC protocol says you may connect without authentication, it's a very explicit thing; we're not, you know, hacking into something that's not authorized.” - Workers only capture screenshots after confirming the remote server permits authentication-free sessions. - Cloud instances are ephemeral and can be scaled elastically for pennies per job: “They cost me 16 cents an hour, so it's perfectly reasonable to spin them up for a job like this and then tear them down when you're done with them.”

---

[40:40](https://www.youtube.com/watch?v=UOWexFaRylM&t=2440s) Live Demonstration: Masscan Mechanics vs. Nmap

While waiting on the web dashboard to resolve access issues on the conference network, Rob opens a terminal to demonstrate masscan in real time directly from the DEF CON network drop. He illustrates how masscan fundamentally differs from Nmap in design and feedback latency. When scanning a subnet with Nmap, the tool performs host discovery, sends ICMP pings, evaluates multiple ports, and retains results in internal memory until a host scan completely finishes. If an operator makes an error in the command-line parameters, they must wait extended periods before seeing the failure: “You start your Nmap scan, you go wait for a coffee and come back, realize you made a mistake in the configuration parameters, do it again, and it's an iterative process.”

| Feature / Behavior | Nmap | Masscan | |:--- |:--- |:--- | | **Scanning Methodology** | Host-centric (pings, checks multiple ports per target in sequence) | Packet-centric / Stateless (one port probe fired at random targets) | | **Result Latency** | High (batches outputs until the target host completes) | Immediate (displays responses as soon as a single SYN-ACK arrives) | | **Pings / Pre-probing** | Defaults to host discovery pings before port probing | No ping pre-checks; directly fires SYN packets to specified ports | | **Global Scan Safeguards** | Scans specified targets directly without broad safety checks | Requires an explicit `--exclude` parameter when targeting `0.0.0.0/0` |

Masscan fires raw TCP SYN packets directly at the requested port without prior ICMP checks, producing instantaneous stdout feedback even at modest rates like 10 packets per second. Rob tests a localized sweep against the `23.0.0.0/8` netblock—a space heavily populated by Akamai, Amazon, and commercial CDN platforms—noting that it consistently yields HTTP responses on port 80 without generating abuse tickets. When he cranks the rate up to 10,000 packets per second, the terminal stream floods with incoming banner updates. Rob explains that masscan includes a built-in safeguard against accidental wide-scale attacks: the program requires the user to explicitly define an `--exclude` address before it will initiate an unrestricted scan across the global internet. Demonstrating a global scan with a dummy exclude rule, masscan immediately begins surfacing active systems across the entire world within seconds.

[43:29](https://www.youtube.com/watch?v=UOWexFaRylM&t=2609s) Masscan Speed, Remaining Time Estimates, and Live Scanning

Rob Graham explains one of the most satisfying operational features of Masscan: its real-time completion countdown. While sending traffic at a sluggish pace will make the progress indicator feel completely hopeless, unleashing the tool at full throttle against the entire global routing table transforms the experience. Rob jokes, “It's like when you copy a file in Windows 95, but it's really cool when you type in that 0.0.0.0/0, the zero subnet meaning the internet, and at a much faster rate like a million packets per second, and it tells you, ‘Yeah, it's about an hour.’”

The speakers demonstrate that these astronomical numbers are not theoretical lab benchmarks but achievable on real-world uplinks. Dan Tentler jumps in to provide actual metrics from a live scan kicked off just before walking into the presentation hall: “Yeah, for reference, I'm getting 690,000 packets a second on my scan that's going right now and it—I started as I walked in and it was telling me an hour and 20 minutes, and that's just on like a modest gig pipe.” With hundreds of thousands of probes firing per second across the wire, the trio attempts to pipe the incoming data live onto the stage screen.

- Target syntax: Probing `0.0.0.0/0` instructs Masscan to scan the entire public IPv4 address space. - Rate comparison: Scanning at 10 packets per second yields an impractical Windows 95-style copy estimate, whereas rates approaching 1,000,000 packets per second can cover the entire public internet in roughly an hour. - Live demonstration metric: An active scan launched on a standard 1 Gbps uplink sustained approximately 690,000 packets per second, forecasting full completion in about 1 hour and 20 minutes.

---

[44:18](https://www.youtube.com/watch?v=UOWexFaRylM&t=2658s) Stage AV Logistics, Network Shenanigans, and the Demo Gods

The transition from theory to the live demonstration descends into the chaotic hardware and networking friction familiar to DEF CON presenters. Between scrambling for VGA-to-HDMI adapters and trying to route live output across machines, the speakers work to expose their collection dashboard (`results.survey.tx.`) where scan data is starting to pour in. When teasing out local IP addresses on the conference network, Dan playfully throws out `192.168.0.1`, before Rob explains the paranoia behind restricting access to the local DEF CON subnet: “Someone got mad last time I did this and exposed it to the whole public internet, so I figured I'll just expose it to all of Defcon and then I can't complain.”

```mermaid flowchart LR accTitle: Live Scan Demo Flow accDescr: High-speed internet scan feeding live survey data into local Defcon stage displays subgraph Scanning ["Masscan Engine"] A["Masscan on 1 Gbps Pipe<br/>(~690k pps)"] -->|"Probes IPv4 (0.0.0.0/0)"| B["Public Internet Hosts"] end subgraph Ingestion ["Stage Collection"] B -->|"Live Responses"| C["results.survey Collector"] C -->|"Internal Defcon Subnet (172.18.x.x)"| D["Audience & Stage Laptops"] end ```

While waiting for the visual feed to bridge onto the main projector, Rob points out Masscan’s portability, noting that it compiles smoothly out of the box across Linux, macOS, and Windows. Yet, in typical live-demo fashion, the audience members on the room’s Wi-Fi can view the web frontend while the presenters’ own laptops struggle to route to it. Rob laughs off the tech glitch as an inevitable rite of passage: “So here's the thing about—here's the rule of Defcon is we call them the demo gods or the demo demons, is that even when your demo is actually working, something does not work.”

- Cross-platform build: Masscan compiles cleanly on macOS, Linux, and Windows environments using basic build tooling (`make`). - Access restriction: The presenters restricted the survey web interface to DEF CON attendees over a private `172.18.x.x` address rather than leaving the dashboard open to the wider public internet. - Audience verification: Attendees in the hall with open laptops confirmed they could reach the live results server before the stage display was able to show it.

---

[46:12](https://www.youtube.com/watch?v=UOWexFaRylM&t=2772s) Internet Quirks: Vulnerable Korean Billboards

As the team sifts through incoming hosts and tries to resolve local browser routing anomalies on `172.18.46.x`, specific real-world artifacts begin surfacing in the scan results. Prominently appearing in the output are unauthenticated remote control endpoints for electronic advertising billboards located across South Korea.

The speakers marvel at the sheer surrealism of having direct, unauthenticated network access to massive physical infrastructure from an auditorium in Las Vegas. Dan highlights the Hollywood-style absurdity of the finding: “And this is one of those opportunities where like you think of Hollywood movies and you're saying, well, so I'm looking at a billboard that's probably in a really big public place and, you know, exploitable—the trolling opportunities.” Rob quips that he should probably steer clear of entire Korean address blocks simply because the exposed billboard controllers show up everywhere and are completely identical. Running out of time with projector routing bugs, the team swaps video cables directly over to Dan's machine so the room can see the raw feed.

- Device discovery: A wide swath of digital advertising billboards in South Korea were found completely exposed on public IPv4 addresses. - Physical-to-digital impact: The systems control digital signs situated in prominent public spaces, presenting severe defacement and trolling vectors straight out of a movie scenario. - Practical mitigation: The presenters jokingly note that staying away from certain regional IP ranges is necessary because vast pools of identical, vulnerable commercial equipment pollute the data.

---

[47:11](https://www.youtube.com/watch?v=UOWexFaRylM&t=2831s) Open Source Release, IPv6 Scanning Feasibility, and the Live Reveal

With only minutes remaining, the speakers open the floor to brief audience questions while final connections are made. An attendee asks whether Masscan is publicly available. Rob Graham confirms that the project is entirely open source and hosted on GitHub under `robertdavidgraham/masscan`. When asked about scanning the vast expanse of IPv6, Rob clarifies the mathematical reality: brute-force scanning the entire IPv6 keyspace is impossible, but targeted discovery is still viable by exploiting allocation patterns: “The question for IPv6 and the implications are is going to not really work; there are some things we can do knowing how IPv6 allocates your addresses and you can maybe do target ranges.”

At that moment, the stage display switches over, finally revealing the live stream of scanned assets on screen to an eruption of cheers and applause from the audience. Dan rushes to emphasize that every host displayed on the screen was discovered in real time over the course of the talk: “So to be clear, these are all results that have been dynamically found while we've been on stage, while they've been furiously typing.” The presentation ends abruptly on a high note as track organizers usher them off the stage, leaving the room with visual proof of an entire internet scan harvested in under an hour.

- GitHub repository: The code is freely available under `https://github.com/robertdavidgraham/masscan`. - IPv6 feasibility: While a brute-force sweep of $2^{128}$ addresses is computationally and bandwidth-prohibitive, intelligence on subnet allocation schemas allows targeted range scanning. - Dynamic demonstration: The live results projected at the close of the talk were gathered entirely during the DEF CON presentation window.

## Notable quotes > [01:09](https://www.youtube.com/watch?v=UOWexFaRylM&t=69s) We really don't appreciate how small the internet is until we've typed in /0 and run our scan. — Rob Graham

> [36:55](https://www.youtube.com/watch?v=UOWexFaRylM&t=2215s) If the VNC protocol says you may connect without authentication, it's a very explicit thing; we're not, you know, hacking into something that's not authorized. — Paul McMillan

## Mentioned Rob Graham, Paul McMillan, Dan Tentler, Masscan, Nmap, OpenSSL, Heartbleed, D-Link, Siemens, Chaos Computer Club, Tor, fail2ban, Department of Defense, Hurricane Electric, bgp.he.net, ShmooCon, Verizon, AT&T, Apple, Redis, Facebook, Twitter, Check Point, ARIN, RIPE, Linode, Apache, Nginx, Active Directory, Clearwire, T-Mobile, Ninja Telephone, QNAP, Synology, Hikvision, IBM, Tumblr, Akamai, Amazon, GitHub, DEF CON 22

## Video description Rob Graham, Paul McMillan and Dan Tentler discuss the some of the quirks of scanning the whole internet

[Source](https://www.youtube.com/watch?v=UOWexFaRylM)