Subdoler: Multi-Stage Subdomain Enumeration Through Tmux Orchestration

Hook

Most subdomain enumeration tools assume you already know the domain names you're hunting. Subdoler starts from just a company name and works backward through IP ranges to discover domains you didn't even know existed.

Context

Bug bounty hunters and red teamers face a cold-start problem: how do you enumerate subdomains when you don't even have a complete list of root domains? Traditional tools like Amass, Subfinder, or Sublist3r are excellent at expanding a known domain into its subdomains, but they require you to already know what domain to target. If you're researching a large enterprise with acquisitions, subsidiaries, or infrastructure under different domain names, you're left manually researching corporate structures and guessing domain patterns.

Subdoler approaches this reconnaissance challenge differently. Instead of starting with domains, it begins with company names, extracts associated IP ranges, performs reverse DNS lookups to discover domains, then fans out into parallel subdomain enumeration across multiple tools. This multi-stage pipeline transforms the reconnaissance workflow from a series of manual steps into an orchestrated process. The tool emerged from the bug bounty community where comprehensive asset discovery—finding every possible entry point into an organization's infrastructure—directly correlates with finding vulnerabilities that other researchers miss.

Technical Insight

Subdoler's architecture is built around tmux session orchestration, treating terminal multiplexing as a primitive for parallel process management. Rather than implementing multiprocessing or threading in Python, the tool spawns tmux panes running independent subprocess calls to external enumeration tools. This design choice is deliberately unconventional but pragmatic: subdomain enumeration tools like Amass can run for hours, and wrapping them in Python's subprocess with proper signal handling and cleanup is complex. Tmux sessions provide natural process isolation, persist beyond SSH disconnections, and allow users to reattach and check progress.

The tool's pipeline follows a clear data flow. First, it scrapes IPv4info.com to extract IP ranges associated with company names:

for company in companies:
    url = f"https://ipv4info.com/?act=check&ip={company}"
    response = requests.get(url)
    soup = BeautifulSoup(response.text, 'html.parser')
    # Extract IP ranges from table rows
    for row in soup.find_all('tr'):
        cols = row.find_all('td')
        if len(cols) >= 3:
            ip_range = cols[0].text.strip()
            ip_ranges.append(ip_range)

These IP ranges feed into reverse DNS enumeration, which uses tools like dnsx or custom scripts to perform PTR lookups, building a list of domains. This is where the tool uncovers domains that might not appear in certificate transparency logs or DNS datasets—infrastructure that's intentionally low-profile.

The third stage spawns parallel tmux panes for each enumeration tool. The tmux orchestration looks like this:

import subprocess

def create_tmux_session(session_name, commands):
    subprocess.run(['tmux', 'new-session', '-d', '-s', session_name])
    
    for idx, cmd in enumerate(commands):
        if idx > 0:
            subprocess.run(['tmux', 'split-window', '-t', session_name])
            subprocess.run(['tmux', 'select-layout', '-t', session_name, 'tiled'])
        
        subprocess.run(['tmux', 'send-keys', '-t', f'{session_name}.{idx}', cmd, 'Enter'])

# Example: Parallel subdomain enumeration
commands = [
    f"amass enum -d {domain} -o amass_results.txt",
    f"gobuster dns -d {domain} -w wordlist.txt -o gobuster_results.txt",
    f"python3 sublist3r.py -d {domain} -o sublist3r_results.txt",
    f"python3 fdns_parser.py {domain} > fdns_results.txt"
]

create_tmux_session('subdomain_enum', commands)

Each pane writes results to separate files, which Subdoler later aggregates and deduplicates. The tool tracks provenance—which enumeration method discovered each subdomain—and writes this metadata to CSV and Excel outputs with multiple sheets. This attribution is valuable for understanding which tools provide the best coverage for your target, allowing you to optimize future reconnaissance by focusing on high-yield methods.

The configuration system uses a simple dictionary to enable/disable tools:

config = {
    'amass': True,
    'gobuster': True,
    'sublist3r': True,
    'fdns': False,  # Requires downloading 200GB+ datasets
    'dnsdumpster': True,
    'theharvester': True,
    'pwndb': False  # Requires Tor service
}

This flexibility is essential because FDNS datasets are enormous (Rapid7's Forward DNS data exceeds 200GB compressed), and PwnDB requires a working Tor installation to query dark web credential databases. Users can start with lightweight tools and progressively enable heavier data sources as needed.

The aggregation phase merges results, performs DNS validation to filter out dead subdomains, and optionally enriches data with HTTP probing to identify live web services. The final output includes columns for subdomain, IP address, HTTP status, discovery tool, and associated IP range. This structured output integrates directly into bug bounty workflows where researchers need to quickly identify high-value targets from hundreds or thousands of discovered subdomains.

Gotcha

The tool's biggest limitation is its dependency on external services and web scraping, making it fragile. IPv4info.com scraping is brittle—any HTML structure change breaks IP range extraction, and the site could implement rate limiting or CAPTCHAs that would require proxy rotation or headless browser automation. The tool has no fallback mechanism; if IPv4info fails, the entire company-name-to-IP-range pipeline collapses.

Installation complexity is another significant barrier. You're not just pip installing a package; you're installing Amass (requires Go), Gobuster (also Go), Sublist3r (Python 2 in older versions), potentially downloading 200GB of FDNS data, and configuring Tor for PwnDB access. Getting all dependencies working across different operating systems and Python versions is non-trivial. The repository's 15 stars and limited recent activity suggest minimal community support for troubleshooting these installation issues. If a dependency updates with breaking changes, you're likely fixing it yourself. The tool also assumes tmux is available, which is standard on Linux/macOS but requires extra setup on Windows (WSL or Cygwin), limiting its portability for researchers on diverse platforms.

Verdict

Use if: You're conducting comprehensive reconnaissance for bug bounty programs or red team engagements where you need to map an organization's entire attack surface starting from minimal information, you're comfortable with command-line tools and don't mind spending an hour on installation and configuration, you value the ability to run long-duration enumeration tasks in detached tmux sessions that survive SSH disconnections, and you need provenance tracking to understand which tools provide the best subdomain coverage for your specific targets. The company-name-to-IP-range discovery is particularly valuable for researching large enterprises with complex infrastructure footprints. Skip if: You need a lightweight, single-purpose subdomain enumeration tool without heavy dependencies, you're working in environments where installing multiple Go and Python tools is problematic, you require active maintenance and community support for a production workflow, or you're just starting with subdomain enumeration and want modern, well-documented tools like ProjectDiscovery's Subfinder. The tool's maintenance uncertainty and installation complexity make it better suited for experienced researchers who can troubleshoot dependency issues and adapt the code when external services change.