Blog · Recon

Subdomain takeover monitoring: catching dangling records before someone else does

A subdomain takeover is one of the cleanest findings in bug bounty: no exploitation gymnastics, just a DNS record that outlived the service it pointed at. The catch is timing. Dangling records are a race — whoever notices the window first claims it. That makes takeover a monitoring problem, not a scanning one.

What a takeover actually is

A subdomain takeover happens when a DNS record (usually a CNAME) still points at a third-party service — a cloud bucket, a hosting platform, a SaaS app — that has been deprovisioned. The DNS says “this name belongs here,” but nothing is actually there anymore. If an attacker can register that now-free resource on the third-party service, they control what loads at the organization's subdomain: phishing that inherits the brand's trust, cookie theft on the parent domain, OAuth redirect abuse, and more.

The tell is a dangling record: a subdomain resolving to a provider, returning that provider's “no such site / bucket not found” fingerprint instead of a real page.

Why it's a timing race, not a one-off scan

Here's what makes takeover a monitoring problem. A subdomain that is safe today can become dangling tomorrow the instant an engineer tears down a staging app but forgets the DNS record. If you scanned that scope last week, you saw a healthy subdomain and moved on. The window opened after your scan — and it will close when someone else claims it or the organization cleans up the record.

One-off recon can only tell you the state at the moment you ran it. Continuous monitoring watches for the transition: the day a healthy subdomain starts returning a takeover-prone fingerprint, that's the signal, and being the first to see it is the whole advantage.

What to monitor for

• New subdomains appearing in scope — especially ones pointing at third-party providers.
• CNAMEs to known-takeoverable services (cloud storage, static hosting, SaaS platforms with claimable subdomains).
• Changed responses — a subdomain that used to serve a real app and now returns a provider's error/placeholder fingerprint.
• Resolution changes — records that start or stop resolving, which often bracket the exact window a takeover is possible.

Doing it continuously

The manual version is a cron job that re-enumerates subdomains, resolves them, fingerprints the responses against a list of takeover signatures, and alerts on matches. It works — and like any self-hosted recon stack, it also breaks quietly, which for a timing-sensitive finding means missed windows. We covered that trade-off in monitoring bug bounty scope for new subdomains.

ASMHunter runs this as part of continuous monitoring: subdomains are re-enumerated on your chosen cadence, responses are fingerprinted, and takeover-prone changes surface in the diff feed with an alert — stamped with the scan and date, so if a report pays you can trace it straight back. You watch the feed, validate the candidate, and file before the window closes.

ASMHunter monitors your bug bounty scope for new and changed subdomains, including takeover-prone fingerprints, on managed infrastructure with alerts and attribution. Start free, or read the guide to continuous attack surface monitoring.