SubDomainizer enumerates subdomains, cloud resource URLs, and leaked secrets from web pages, external JavaScript, and GitHub for authorized bug bounty and assessment workflows.
| Tool | nsonaniya2010/SubDomainizer — Python tool that finds subdomains, S3 buckets, CloudFront URLs, and secrets hidden in pages, external JavaScript, and GitHub |
| Category | Reconnaissance and attack-surface enumeration (Python 3, MIT licensed, ~1.9k stars) |
| Primary Use | Mapping an organization's externally-visible footprint — subdomains, S3 buckets, CloudFront URLs, and hardcoded secrets — during authorized assessments and bug bounty programs |
| Safe Use | Intended for penetration testers and bug bounty researchers working strictly within authorized scope, on assets they own or have written permission to test, and for blue teams auditing their own code for leaks |
| Telemetry Note | Generates measurable outbound traffic: HTTP fetches of every discovered external .js file, plus unauthenticated queries to crt.sh, the Wayback CDX API, and HudsonRock — defenders can fingerprint this scanning pattern in web server and proxy logs |
SubDomainizer is one of those quiet workhorses of the recon phase that has aged into a genuinely modular codebase with its v3.0 rewrite. Written in Python 3 and MIT licensed, the tool answers a deceptively narrow question with a broad blast radius: what is hiding in the pages and external JavaScript files of a target domain? The answer it returns bundles subdomain enumeration, cloud resource discovery, and secret detection into a single pass, which is precisely the combination that makes it a staple in authorized bug bounty workflows rather than a one-trick scanner.
The v3.0 architecture is the most interesting technical development documented in the README. The project was rewritten as a proper Python package under subdomain/, exposing Scanner, ScanConfig, and ScanResult as first-class programmatic interfaces. That means you are no longer chained to shell invocation; a two-line Scanner().scan_url("https://example.com") returns a structured ScanResult object with subdomains, cloud_urls, secrets, and passive_dns attributes. For operators building custom recon pipelines, this importability matters more than any single new flag, because it turns SubDomainizer from a script into a library component.
At its core the tool fetches the target page, identifies external JavaScript files, and mines them for references the developer never intended to expose. Subdomains matching the target TLDs are extracted via -d/--domains, while a curated regex set hunts for cloud storage endpoints across six providers: Amazon AWS (S3 buckets and CloudFront), DigitalOcean Spaces, Microsoft Azure, Google Cloud Services, Dreamhost, and RackCDN. The value proposition is triage speed — an open-to-write S3 bucket or a dangling CloudFront distribution surfaced automatically is exactly the kind of finding a bug bounty report is built on.
Secret detection is the second pillar, and the README is unusually honest about its maturity: the feature is labeled beta. The mechanism combines keyword matching with Shannon Entropy scoring and, new in v3.0, a false-positive blacklist to cut noise. High-entropy strings adjacent to keywords like API keys are flagged, and v2.0 added source tracking so result.secrets maps each secret back to the file or page it came from. Operators should treat output as candidate leads, not confirmed leaks — the author explicitly warns that false positives are expected and accuracy improvements are deferred to later versions.
v3.0 also folds passive subdomain enumeration into every scan with no extra flags required. Three unauthenticated public sources are queried concurrently: crt.sh for Certificate Transparency log entries, the Wayback Machine CDX API covering the last two years of archived URLs, and HudsonRock's Cavalier URL database built from stealer logs. Results are merged into the primary subdomain list and also exposed separately under result.passive_dns keyed by source. The HudsonRock integration is a notable design choice — it surfaces hostnames that appear in infostealer-log-derived datasets, which is defensive gold if you are monitoring your own organization's exposure, since those hostnames indicate previously compromised endpoints or credentials in circulation.
The CLI surface is broad but coherent. Single targets go through -u/--url, bulk scans read a file with -l, and results split across three output sinks: -o for subdomains, -cop for cloud URLs, and the new -sop for a dedicated secrets file. A -j/--json flag prints everything as structured stdout JSON, making the tool trivially pipeable into jq or downstream correlation scripts. -c/--cookie lets authenticated crawling change the visible JavaScript surface — the README demonstrates this with before/after comparisons on facebook.com showing materially different results, a reminder that pre-auth recon sees only part of the attack surface.
GitHub scanning is opt-in via -g/--gitscan and requires a token passed with -gt. When enabled, the tool searches GitHub code for subdomains and secrets associated with the target, saving those findings to -gop. This is where the tool leans closest to OSINT territory: hardcoded tokens committed to public repositories remain one of the most common real-world leak vectors, and having web-content scanning and GitHub code scanning in one invocation shortens the gap between footprint and leak discovery.
Two further modes round out the feature set. -f/--folder recursively scans a local directory of your own files — useful for auditing a client's static asset bundle or a JS bundle snapshot offline — and -san extracts Subject Alternative Names from TLS certificates, with all returning every domain in the cert chain and same restricting results to the target's TLD. SAN mining is a classic certificate-transparency-adjacent trick that often reveals internal or staging hostnames that never appear in DNS bruteforce lists but live in publicly issued certificates.
Installation follows the standard pattern: git clone https://github.com/nsonaniya2010/SubDomainizer.git, then pip3 install -r requirements.txt inside the directory, and invocation via python3 SubDomainizer.py -h to confirm the flag set. Updates are a git pull plus reinstalling requirements. The badge metadata claims Python 3.13 compatibility fixes in v3.0 and requires >3.6, so modern interpreters are supported. There is a -k/--nossl flag that disables certificate verification — convenient for lab proxying but worth avoiding against real targets, since it opens the scanning host to interception.
From a defender's perspective, SubDomainizer is as useful inbound as it is on engagements. Running it against your own organization's domains surfaces exactly what attackers enumerate first: forgotten S3 buckets with permissive ACLs, CloudFront distributions vulnerable to takeover, subdomains decommissioned in DNS but alive in certificate logs, and secrets committed to GitHub years ago. The telemetry profile is also identifiable — every external .js file fetched in rapid succession plus queries to crt.sh, Wayback, and HudsonRock leaves a distinct pattern in proxy and WAF logs that blue teams can alert on. Used inside authorized scope, it is a compact, scriptable checklist for the leak classes that dominate bug bounty leaderboards.
nsonaniya2010/SubDomainizer.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.