Netz: Building an Internet-Scale Scanner That Can Map IPv4 in Under an Hour

Hook

The entire public IPv4 address space contains roughly 3.7 billion addresses. With the right hardware and kernel bypass techniques, netz can scan all of them for open ports in about 20 minutes—then immediately identify which services are running without authentication.

Context

Security researchers face a fundamental tension: offensive reconnaissance tools like masscan and zgrab2 are incredibly powerful, but running them at internet scale requires deep infrastructure knowledge, careful orchestration, and the ability to handle network saturation that can knock out your own SSH connections. Before netz, setting up a scanning pipeline meant manually provisioning cloud instances, configuring specialized network interfaces, wrestling with PF_RING kernel modules, coordinating the handoff between port scanning and service enumeration, and hoping your logging survived the network flood.

The problem isn't just technical complexity—it's reproducibility. Security research often requires running the same scan across different IP ranges or repeating scans over time to track misconfiguration trends. Manually recreating scanning infrastructure is error-prone and time-consuming. SpectralOps built netz to solve this orchestration problem: treat internet-scale scanning as ephemeral, reproducible infrastructure that provisions itself, executes the pipeline, streams results, and tears everything down automatically.

Technical Insight

Netz's architecture centers on a Go-based control plane that manages AWS ECS resources as code. Rather than being a scanner itself, netz is a meta-tool that orchestrates the heavyweight scanners masscan and zgrab2 inside containerized workflows. The genius lies in how it handles the infrastructure lifecycle.

The provisioning phase creates everything needed for high-throughput scanning: IAM roles with appropriate permissions, c4.8xlarge EC2 instances (chosen for their 10 Gbps networking), multiple elastic network interfaces to maximize packet throughput, CloudWatch log groups for centralized output, and security groups configured to handle the massive bidirectional traffic. Here's how netz defines a basic scan configuration:

// Example scan configuration
scanConfig := &ScanConfig{
    IPRanges: []string{"0.0.0.0/0"},
    Ports: "80,443,8080,9200",
    Rate: 3500000, // packets per second
    MasscanArgs: "--excludefile exclude.txt",
    ZgrabModules: []string{"http", "elasticsearch"},
}

// Netz provisions AWS resources and runs the pipeline
scanner := netz.NewScanner(scanConfig)
if err := scanner.Provision(); err != nil {
    log.Fatal(err)
}
defer scanner.Destroy() // Cleanup happens automatically

results, err := scanner.Execute()

The two-phase pipeline is where netz shows its real sophistication. Phase one uses masscan in TCP SYN mode to discover open ports across IP ranges. Masscan's stateless design allows it to send packets at extreme rates without tracking connection state—it simply fires SYN packets and listens for SYN-ACKs. Netz captures masscan's output (IP:port pairs) and immediately streams it to phase two.

Phase two pipes these targets into zgrab2, which establishes full TCP connections and performs application-layer protocol handshakes. This is where you discover the actual security issues: an open port 9200 could be anything, but zgrab2's Elasticsearch module will confirm whether it's actually Elasticsearch, attempt to fetch the cluster health endpoint, and verify if authentication is required. The pipeline might discover 50,000 open ports but only 200 actually-accessible Elasticsearch clusters.

For extreme performance scenarios, netz supports PF_RING ZC (Zero Copy), a kernel bypass technology that allows userspace applications to read packets directly from NIC ring buffers without kernel context switches. This requires specialized Intel NICs and licensed drivers, but the performance gains are substantial:

# Standard masscan might achieve 1M packets/second
$ masscan 0.0.0.0/0 -p80,443 --rate 1000000

# With PF_RING ZC on multiple NICs, netz can orchestrate:
$ masscan 0.0.0.0/0 -p80,443 --rate 3500000 \
  --pfring-cluster-id 99 --pfring-interface zc:eth1

The infrastructure-as-code approach means netz handles failure scenarios gracefully. If a scan gets interrupted, the destroy command can clean up orphaned resources. If you need to scan the same range again with different parameters, netz provisions fresh infrastructure rather than dealing with state contamination. The entire lifecycle—provision, scan, destroy—becomes a repeatable, version-controlled operation.

Netz also solves the observability problem cleverly: since network saturation during scanning can make SSH unusable, it streams CloudWatch logs directly to your local terminal in real-time. You're watching remote scan progress without maintaining a persistent connection that would be severed by the scanning traffic itself. The logs show both masscan's discovery rate and zgrab2's enumeration progress, giving you visibility into both pipeline phases simultaneously.

Gotcha

The elephant in the room: netz generates traffic that looks identical to a distributed denial-of-service attack. ISPs will throttle you, intrusion detection systems will flag you, and depending on your jurisdiction and target selection, you may be breaking laws. Running a full IPv4 scan without explicit authorization is legally dangerous. Even with authorization, your cloud provider may suspend your account if you don't notify them in advance. AWS has specific procedures for penetration testing notifications that you must follow.

The technical limitations are equally significant. That CloudWatch logging solution? It becomes unreliable during peak scanning intensity because the scanning traffic itself saturates your network connection. You'll miss log lines, making debugging difficult. SSH connections to your scanning instances will timeout or lag unbearably. Netz acknowledges this in its documentation, but it means you're partially flying blind during the most critical phase. The tool also assumes significant AWS expertise—you need to understand ECS task definitions, IAM policies, VPC networking, and CloudWatch configuration. If something goes wrong with provisioning, debugging requires deep AWS knowledge that isn't abstracted away.

Verdict

Use netz if: You're a security researcher with explicit authorization conducting internet-wide reconnaissance for vulnerability disclosure programs, academic research on misconfiguration prevalence, or authorized red team operations. You have the budget for c4.8xlarge instances and multiple ENIs. You're comfortable with AWS infrastructure-as-code and can debug ECS/IAM issues. You need reproducible scanning pipelines that can run repeatedly with different parameters. Skip netz if: You lack written authorization to scan target networks (this is non-negotiable). You need to scan specific organizations or smaller target lists—dedicated tools like Nuclei or even manual zgrab2 are more appropriate. You want pre-indexed data rather than running scans yourself (use Shodan, Censys, or Rapid7's Project Sonar datasets instead). You can't afford the cloud spending or don't have AWS expertise. You need production-grade reliability with guaranteed observability—netz is a research tool that trades some operational polish for raw scanning power.