Subdomain Takeover Detection: How Vexta Finds the CNAMEs Nobody Is Watching

What is subdomain takeover detection, and why does it need more than a simple DNS lookup? Subdomain takeover detection means finding a subdomain whose CNAME still points at a cloud or SaaS resource that nobody claimed anymore, then confirming an attacker could register that resource and serve content from a trusted hostname. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, builds this on top of its own subdomain enumeration pipeline, fingerprinting CNAME records against more than 30 cloud and SaaS providers and running three non-destructive checks before it ever calls a subdomain a confirmed takeover risk.

How does Vexta build the subdomain list before checking for takeover?

Enumeration runs as a seven-stage pipeline. It starts with passive discovery, where all 26-plus free and keyed OSINT providers fire in parallel. Next comes wildcard detection: Vexta probes three random, made-up hostnames under the target domain, and if any of them resolve, it records the resulting IPs as a poison set so wildcard DNS doesn't flood the results with false subdomains later. Active brute-force follows, resolving each wordlist entry as a candidate subdomain and filtering out anything matching the wildcard poison set. A permutation engine then mutates confirmed hosts with prefix, suffix, swap, and separator variations, bounded to 50 permutations per seed host, to catch naming patterns a wordlist alone would miss.

The last three stages push further. Active recon attempts AXFR zone transfers and runs reverse DNS on every discovered IP. Recursive enumeration re-feeds newly found hosts back through the permutation stage until the results converge, up to 10 levels deep. Enrichment closes the pipeline: DNS resolution, CNAME chasing, and subdomain-takeover fingerprinting all run against the final host list, which is what feeds the takeover check itself.

How does Vexta decide a subdomain is actually takeover-able?

Every CNAME chain Vexta discovers gets fingerprinted against a list of 30-plus cloud and SaaS services with a known takeover pattern: AWS S3 and CloudFront, Azure, Heroku, GitHub Pages, GitLab Pages, Bitbucket Pages, Netlify, Vercel, Firebase, Shopify, and Fastly among them. A CNAME match alone is a candidate, not a confirmed finding, because plenty of CNAMEs point at a provider resource that is still very much claimed and in active use. Vexta runs three non-destructive verification checks on each candidate before it will promote the severity of the finding, confirming the provider-specific signal that indicates the resource is actually unclaimed, rather than reporting every stale-looking CNAME as an emergency.

That two-step approach, fingerprint first, verify second, matters because a takeover report that turns out to be a false positive costs a hunter credibility with a program, and a program's triager time chasing it down. Only candidates that pass the verification checks get their severity auto-promoted, so what lands in the findings list has already cleared a real bar.

Why does asset enrichment matter for a takeover candidate?

Every subdomain Vexta discovers, not just takeover candidates, gets enriched into a full asset record: host, IP addresses, status code, server header, page title, CNAME chain, a Wappalyzer-style technology stack fingerprint, open ports, PTR records, ASN, organization and country data from Team Cymru, and a takeover-candidate flag. Having all of that sitting next to a takeover candidate means a hunter isn't cross-referencing five separate tools to understand what the subdomain was for before deciding whether it's worth reporting; the context that explains why the subdomain existed in the first place is right there in the same record.

That context is often what separates a takeover candidate worth reporting from one that isn't. A subdomain with an active status code, a live technology fingerprint, and current PTR records is probably still in use by someone even if its CNAME briefly resembles a known-vulnerable pattern. A subdomain returning an error status, an empty page title, and no recent server response, sitting next to a matching CNAME pattern, is a much stronger candidate, and having both signals in the same asset record lets a hunter make that call in seconds instead of pivoting between a DNS tool, a screenshot tool, and a technology fingerprinting tool separately.

What does a takeover-hunting workflow look like in practice?

A hunter working a wide-scope program typically starts by letting the full seven-stage pipeline run unattended, since passive discovery and the permutation engine between them tend to surface far more subdomains than a manually curated wordlist would. From there, the takeover-candidate flag on the asset record is the natural filter: instead of reviewing every one of a few thousand discovered hosts, a hunter can jump straight to the handful flagged as pointing at a recognized provider pattern and work through the verification detail for each one.

The CNAME chain and the provider match Vexta records for each candidate also do double duty as documentation. When a candidate clears verification and gets reported to a program, the same fingerprint data, which provider, which pattern matched, what the three checks confirmed, becomes the basis of the report itself, since a triager reviewing a takeover claim wants to see exactly that evidence rather than a bare claim that a subdomain 'looks vulnerable.'

How does asset diffing catch takeover risk between scans?

Vexta compares assets across scans of the same target and flags each one as new, removed, or changed, with a diff badge shown in the dashboard. A subdomain that keeps existing but whose CNAME target changes between two scans is exactly the kind of change that diffing surfaces automatically, which matters because a resource that was safely claimed on one scan can become unclaimed later without anyone touching the DNS record itself. Re-scanning a target on a schedule and watching the asset diff is a cheap way to catch that drift before an attacker notices it first.

Key takeaways