From subdomain enumeration to takeover detection: a practical 2026 workflow

The subdomains you remember are not the ones that get you owned. It’s the campaign site from two years ago, the staging host that was “temporary,” the vendor integration pointed at a cloud service you’ve since cancelled. Finding those — continuously — is the foundation of external security. Here’s a practical pipeline, the open-source tools that power each step, and the gotchas that bite people.

1. Passive discovery

Start without touching the target. Pull subdomains from public sources — certificate transparency logs, passive DNS, search engines, threat-intel feeds — with a tool like subfinder. Passive enumeration is quiet, fast, and surprisingly complete; CT logs alone surface a huge fraction of what exists because every TLS certificate is published.

Gotcha: passive sources include stale and third-party entries. A name appearing in CT doesn’t mean it’s yours or live — which is why the next steps matter.

2. Resolution and wildcard filtering

Resolve what you found with dnsx. This is where you separate live names from noise and — critically — filter out wildcard DNS, where *.example.com resolves everything to one address and makes naive enumeration report thousands of phantom “subdomains.” Get this wrong and your inventory is garbage.

Gotcha: wildcard detection is non-trivial; test random nonexistent names and discard anything that resolves like they do.

3. Port and service discovery

For the hosts that resolve, find what’s listening with a fast port scanner like naabu, then identify the actual services. Open ports are where the surface really lives — an HTTP service on 8080, a forgotten admin panel, a database that should never have been public.

Gotcha: rate limits and authorization. Scan only what you’re allowed to, within agreed windows and intensity — a bare port sweep across someone’s infrastructure is not a neutral act.

4. HTTP probing and fingerprinting

Probe the live web services with httpx: status codes, titles, response hashes, detected technologies, TLS details, redirects. This turns “port 443 is open” into “an end-of-life nginx serving a login page with an expiring cert” — the context that makes a finding actionable.

5. Takeover detection

Now the payoff. A subdomain takeover happens when a DNS record points at a service you no longer control — a dangling CNAME to a de-provisioned cloud resource that an attacker can then claim and serve content from, under your domain. Classic scenarios: abandoned S3/static-hosting buckets, deleted GitHub Pages or Heroku apps, cancelled SaaS integrations, expired cloud endpoints.

Detection means correlating your DNS records against the fingerprints of services that allow claiming — a dangling CNAME plus a “no such bucket / app” signature is the tell. These are high-impact and easy to miss precisely because the subdomain “looks” like it’s yours.

Gotcha: takeover state is fluid. A record that’s safe today becomes claimable the day a resource is deleted — which is why this has to run continuously, not once a year.

The thread through all of it: do it continuously, and correlate

Run this pipeline once and you get a snapshot. Run it on a schedule and tie each result back to a persistent asset, and you get something far more useful: you learn when a new subdomain first appeared, when a service changed, and when a safe record became a takeover risk. The pipeline is the easy part; the memory and correlation are what make it a program.

That’s the whole idea behind ProbeIQ — this exact discovery pipeline, run continuously, with the output correlated, de-duplicated, and diffed so you see what changed. If you’d rather not maintain the glue code, start here.