How to Automate Recon and Detect Subdomain Takeovers with Amass, Subfinder and Nuclei

Key takeaways

• Chain tools in order: Subfinder and Amass to enumerate, httpx to find live hosts, then Nuclei's http/takeovers templates to match fingerprints.
• The permanent fix is defensive: delete or reclaim DNS records that still point to de-provisioned services such as GitHub Pages, Heroku or S3.
• Schedule the pipeline against your own domains so new dangling records are caught early, and run it only on authorised scope.

A subdomain takeover is one of the most preventable high-severity issues, and the same automation that finds it for a bug-bounty report is what a security team should run against itself. This walks through the workflow and, just as importantly, how to close the gap for good.

What is a subdomain takeover?

A subdomain takeover happens when a subdomain, say blog.example.com, still has a DNS record pointing to a third-party service, GitHub Pages, Heroku, an S3 bucket or a help-desk tool, but that service is no longer claimed by the owner. If anyone else can register the dangling resource on that provider, they can serve content from your subdomain. That enables convincing phishing, cookie theft on the parent domain in some setups, and reputational damage, because the address bar genuinely shows your domain.

The root cause is almost always a DNS record that outlived the service it pointed to.

Why automate the check

Large organisations create and retire subdomains constantly, and a dangling record can appear the day after a clean audit. Manual enumeration does not keep up. Automating it lets you continuously enumerate your estate, confirm which hosts are live, match them against known takeover signatures, and get an alert the moment something new appears. Treat it as monitoring, not a one-off scan.

Before you run anything: scope and the law

Run this pipeline only against domains you own or a bug-bounty or engagement scope that explicitly authorises it. Enumerating and probing a third party's subdomains without permission can attract liability under India's Information Technology Act, 2000, regardless of intent. Actually registering someone else's dangling service to "prove" a takeover can cause real harm and goes beyond most bug-bounty rules, so report the dangling record instead of claiming it. Keep a record of your authorisation.

The recon pipeline, step by step

1. Enumerate subdomains (Subfinder + Amass)

Subfinder does fast passive discovery; Amass adds deeper passive and active enumeration. Combine and de-duplicate their output.

subfinder -d example.com -silent -o subfinder.txt
amass enum -passive -d example.com -o amass.txt
sort -u subfinder.txt amass.txt > all_subs.txt

2. Find the live hosts (httpx)

Not every name resolves to a running service. httpx filters to live hosts and records status codes, titles and detected technology, which already hints at which third-party services are in play.

httpx -l all_subs.txt -silent -status-code -title -tech-detect -o live_subs.txt

3. Match takeover fingerprints (Nuclei)

Nuclei's community templates include a maintained set of subdomain-takeover checks. Point them at your live hosts. The current template path is http/takeovers:

nuclei -l live_subs.txt -t http/takeovers/ -o takeover_findings.txt

Treat every hit as a lead to verify by hand, not a confirmed issue. Takeover templates produce false positives as providers change their policies, so confirm the DNS target really is unclaimed before you act or report.

4. Schedule it

Wrap the steps in a script and run it on a schedule against your own estate so new dangling records surface quickly.

#!/usr/bin/env bash
set -euo pipefail
target="example.com"
stamp="$(date +%F)"
subfinder -d "$target" -silent -o subfinder.txt
amass enum -passive -d "$target" -o amass.txt
sort -u subfinder.txt amass.txt > all_subs.txt
httpx -l all_subs.txt -silent > live.txt
nuclei -l live.txt -t http/takeovers/ -o "report_${stamp}.txt"

How to verify and fix a finding

1. Confirm the dangling target. Resolve the record (CNAME or A) and check the provider says the resource is unclaimed or missing, not merely down.
2. Fix on the DNS side. If the service is retired, delete the DNS record. If it is still needed, reclaim the resource on the provider so it is owned again.
3. Close the process gap. Decommissioning a service and removing its DNS record should be a single checklist item, so records never outlive services.
4. Re-scan. Confirm the finding is gone and keep the monitoring running.

The tools at a glance

Where to go next

This pipeline is a slice of reconnaissance and attack-surface management. To use it responsibly, understand how DNS actually resolves and how recon fits into a lawful engagement. If you want to build these skills formally, structured training ties the tools, the scope rules and the reporting together.

Related reading

• Mastering Recon-ng| What is Recon-ng and how can ethical hackers use it for OSINT?
• Top 15 Best Vulnerability Scanner Tools in 2026 | Features, Pros & Cons for IT Security
• How are hackers using DNS blind spots to hide and deliver malware in 2026, and what can organizations do to detect and prevent these DNS-based cyber attacks?