Subzy: How Fingerprint-Based Detection Makes Subdomain Takeover Scanning Actually Scalable
Hook
A single misconfigured DNS record can hand attackers complete control of your subdomain—and with organizations managing thousands of subdomains across dozens of cloud providers, manual verification is impossible.
Context
Subdomain takeover vulnerabilities emerge when an organization points a DNS record to a third-party service (like AWS S3, GitHub Pages, or Heroku) but fails to claim or later abandons that resource. The DNS record persists, creating a window where attackers can claim the abandoned resource and serve malicious content on your domain.
The challenge for security teams isn’t theoretical understanding; it’s scale. A typical enterprise maintains hundreds or thousands of subdomains across multiple providers. Each service has unique error signatures indicating vulnerability. Traditional approaches—manually checking each subdomain, verifying DNS records, and testing service responses—don’t scale. Subzy solves this by automating fingerprint matching against a database of vulnerable service patterns, with configurable concurrent checking to scan hundreds of targets simultaneously.
Technical Insight
Subzy’s architecture centers on fingerprint matching against the can-i-take-over-xyz project, which documents known takeover patterns for major cloud and SaaS providers. When you point Subzy at a list of subdomains, it uses concurrent checking (default 10 workers, configurable via --concurrency) that send HTTP requests and analyze responses—status codes, headers, and body content—looking for telltale signatures.
The concurrency model is what makes Subzy practical for real-world penetration testing. Consider scanning 1,000 subdomains with a 10-second timeout. Serial execution would take considerable time, but concurrent workers dramatically reduce scan duration. Here’s how you’d actually use this in a bug bounty workflow:
# First, enumerate subdomains with your preferred tool
$ subfinder -d example.com -o subdomains.txt
# Run Subzy with increased concurrency for faster scanning
$ subzy run --targets subdomains.txt --concurrency 50 --timeout 5 --hide_fails
# For HTTPS-heavy targets, force HTTPS and skip SSL verification for dev environments
$ subzy run --targets subdomains.txt --https --verify_ssl=false --concurrency 50The --hide_fails flag is particularly useful when scanning large lists—you only see actionable findings, not the majority of subdomains that are properly configured. The --timeout flag deserves attention: default is 10 seconds, which is conservative. For bug bounty work where you’re checking thousands of targets, dropping to 5 seconds may improve throughput.
What’s notable is what Subzy doesn’t do. It’s not a subdomain enumeration tool or an exploitation framework. It assumes you arrive with a pre-enumerated list (from subfinder, amass, or DNS records) and focuses exclusively on the takeover detection problem. This makes it straightforward to chain with other tools:
# Pipeline example: enumerate, filter live hosts, check takeovers
$ subfinder -d example.com -silent | httpx -silent -status-code -mc 200,404 | cut -d ' ' -f1 > live.txt
$ subzy run --targets live.txt --concurrency 100 --hide_failsThe fingerprint database itself is critical infrastructure. Subzy uses patterns from can-i-take-over-xyz, which documents whether each service is vulnerable, what the response looks like, and how difficult takeover is to execute. For example, AWS S3 appears to return “NoSuchBucket” errors based on the fingerprint matching approach. These fingerprints change when providers update their error pages, which means detection quality depends on the upstream fingerprint database maintenance.
One subtle but important feature: protocol handling. By default, Subzy uses HTTP, but the --https flag forces HTTPS. For targets where protocol isn’t specified in your input list, this matters—some services only respond correctly over HTTPS, and you’ll miss vulnerabilities if you’re hitting the wrong protocol. The --verify_ssl flag lets you scan development or staging environments with self-signed certificates without SSL verification failures.
Gotcha
Subzy’s fingerprint-based detection is both its strength and weakness. When cloud providers change their error page design or update their 404 templates, signatures can break. You’re relying on the can-i-take-over-xyz database being current. False negatives are the real risk here—you scan, see nothing, assume you’re safe, but the fingerprint may be stale.
Just as critically, Subzy only detects potential vulnerabilities; it doesn’t prove them. A positive match means the fingerprint matched, not that you can definitely claim the resource. Some services require specific account types or are region-locked. The tool tells you “this looks vulnerable based on the response,” but you still need manual verification before reporting to a bug bounty program. Automated scanners can produce false positives that waste time without confirmation. Subzy gives you leads, not proof. Also, if you’re expecting subdomain discovery, you’re using the wrong tool—Subzy requires you to bring your own enumeration (via --targets file or --target parameter). It’s detection-only, which means you need a separate workflow step before you even run it.
Verdict
Use Subzy if you’re doing bug bounty hunting or penetration testing engagements where you need fast, automated scanning of pre-enumerated subdomain lists. The Go binary is portable, installation is simple via go install, and concurrency controls mean you can tune it from cautious (10 workers) to aggressive (100+ workers) based on your target’s infrastructure. Skip Subzy if you need comprehensive subdomain discovery (pair it with subfinder or amass first), require proof-of-concept exploitation (you’ll need manual verification anyway), or are scanning targets where fingerprints change frequently (internal tools, custom platforms). Also be aware that Subzy checks HTTP responses based on fingerprint matching—you’ll need to verify findings manually and ensure your subdomain enumeration is comprehensive before scanning.
