Natlas: Building a Distributed Attack Surface Scanner Before ASM Was Cool
Hook
Before ‘Attack Surface Management’ became a market category, a small open-source project was already solving the core problem: how do you track what’s exposed across thousands of IP addresses without losing your mind?
Context
Traditional vulnerability scanning suffers from a fundamental mismatch: security teams don’t need a fire hose of CVEs—they need to know what’s exposed. Is anyone running SSH with password authentication? Are there rogue NFS shares accessible from the internet? Which SSL certificates expire next week? These questions require continuous reconnaissance, not periodic vulnerability assessments.
Natlas was built from this insight. Rather than creating yet another vulnerability scanner, it focuses exclusively on exposure tracking using nmap’s extensive capabilities. The architecture is straightforward: agents fetch scan targets from a central server, execute nmap with configurable scripts, and push results to Elasticsearch for search and analysis. This design enables continuous, distributed monitoring of large IP ranges with centralized visibility.
Technical Insight
The core design in Natlas is its distributed work orchestration model. Agents pull work from the server in a stateless pattern that handles agent failures and variable scan durations naturally. When an agent requests work, the server generates targets using what the project describes as a cyclic pseudorandom number generator (PRNG)—a deterministic sequence designed to ensure complete IP space coverage over time without requiring massive state storage. This cyclic PRNG was developed by contributor Ross Snider specifically for target selection.
The agent workflow appears to follow a simple pattern: request a target from the server, execute nmap with server-configured scripts and port lists, then submit the results back. This stateless design means you can scale horizontally by launching more agent containers—no complex orchestration required. Each agent operates independently, making the system resilient to individual agent failures.
The server manages scan configuration centrally (which nmap scripts to run, which ports to scan, timing parameters) and handles result indexing into Elasticsearch. Since Natlas uses nmap’s standard capabilities, you can leverage any default nmap scripts in your scans. The server parses nmap output and structures it for Elasticsearch, making the reconnaissance data searchable.
This indexing approach enables compliance monitoring at scale. You can search for hosts running specific services, identify weak configurations, or track SSL certificate status—the full nmap script output becomes searchable intelligence rather than raw scan data.
The cyclic PRNG approach is particularly clever for ensuring coverage. Rather than random target selection (which might scan the same host multiple times while missing others), the deterministic generator cycles through the configured IP space systematically. This guarantees complete coverage without maintaining a massive queue of pending targets—the server tracks position in the cycle rather than storing all pending work.
Gotcha
Natlas makes some opinionated choices that won’t fit every use case. The Docker-only deployment model, introduced on June 15, 2020, is mandatory. If you’re in an environment with containerization restrictions or need to deploy on legacy infrastructure without Docker support, you cannot use Natlas. The project deliberately removed alternative installation methods to reduce maintenance burden.
You’re also managing three separate systems: Elasticsearch, the Natlas server, and one or more agents. While Docker helps, this isn’t a single-binary deployment. You need to understand Elasticsearch basics, monitor disk usage (scan results accumulate quickly), and handle version compatibility between components. The README points to Elastic’s official documentation for setup, which means you’re expected to understand persistence, memory allocation, and cluster health on your own.
Nmap scanning is inherently noisy. Every scan generates network traffic, triggers IDS/IPS alerts, and appears in firewall logs. If you need stealth reconnaissance or are scanning third-party networks (which raises serious legal and ethical questions), Natlas isn’t the tool. It’s designed for scanning networks you control, where port scanning is acceptable and expected. The platform also doesn’t perform deep vulnerability assessment—it identifies exposure, not exploitability. You won’t get CVE scores or remediation advice out of the box.
Verdict
Use Natlas if you’re managing large internal networks and need continuous exposure monitoring with full control over scan parameters. It’s ideal when you want to enforce security policies at scale—ensuring no SSH servers accept passwords, tracking SSL certificate expiration, finding unauthorized services. The distributed architecture shines when you need to scan from multiple network segments or balance load across scanning infrastructure. Skip it if you need commercial support, want pre-built compliance dashboards, or require vulnerability scoring beyond basic port and service enumeration. Also skip if Docker isn’t an option, you’re scanning networks you don’t own, or you need stealth capabilities. For internet-wide reconnaissance, commercial services provide broader coverage without infrastructure overhead. For vulnerability management, stick with dedicated vulnerability scanners.
