How attackers discover vulnerable CNAME records

Step 1 - Finding Subdomains

There is only so much you can do to "lock" DNS. DNS records are not secrets — and security-through-obscurity doesn't work. Even with zone transfers disabled (as you should), attackers have many ways to enumerate CNAMEs and other entries. Discovering candidate subdomains is the first and easiest step in a subdomain-takeover workflow.

Common approaches to find subdomains include:

• Public resource discovery (Certificate Transparency logs, public SVC records, cloud provider hostnames)
• Brute forcing / wordlists (trying common hostnames)
• Content analysis (scraping pages, JS, or assets for hostnames)
• Third-party repositories and datasets (public scans, OSINT feeds, passive DNS)

One of the richest sources is Certificate Transparency. Visit crt.sh and search your domain; certificates often include subdomains and hostnames, so a single query can reveal many subdomains that are otherwise not advertised.

Example (illustrative): a certificate may surface an entry like:

sentry-api.ops.na.vn.cloud.tesla.com

Resolving that name can show it’s a CNAME pointing to a cloud or third-party endpoint:

$ dig +noall +answer +multiline sentry-api.ops.na.vn.cloud.tesla.com CNAME  

That CNAME target reveals it points to an AWS ELB. If that ELB is later removed and the original CNAME remains, someone who can claim the ELB hostname (or equivalent provider resource) can host content on that name — and the original subdomain will appear to serve attacker-controlled content.

Finding one such example can take under a minute for a single domain; at scale, attackers rely on tools and datasets to enumerate thousands of candidates automatically.

Useful defensive note: this reconnaissance itself is not inherently illegal — it’s public OSINT. But it is the precursor to attacks, which is why detection and remediation are essential.

Step 2 — Automate Reconnaissance (How Attackers Scale It)

Attackers don’t stop at manual discovery; they automate it. At scale they:

• Aggregate public data sources: CT logs, passive DNS feeds, open Git repos, sitemap/index scans, search engine results, and cloud provider naming patterns.
• Fingerprint provider patterns: Many managed services have predictable hostname formats (GitHub Pages, S3, Heroku, ELB, Zendesk, etc.). Automated scripts match CNAME targets against known provider signatures.
• Correlate evidence: The more signals that point to a disposable/third-party service, the higher the candidate score (and the more attractive the target).
• Queue candidates: Results are ranked and stored; records with high likelihood of becoming available are monitored for resource deletion or expiration.

Common tooling (used for research and defense as well as offensive reconnaissance) can enumerate subdomains and map them to provider fingerprints quickly. From a defender’s perspective, this is valuable intelligence: the same techniques can be used to find your own risky records before attackers do.

Defender takeaway: automation is why manual spot-checks fail — you need automated monitoring that continuously watches the DNS footprint and flags records that point to ephemeral or third-party services.

Step 3 — From Candidate to Exploitable Target (Conceptual)

Once a candidate is identified, attackers watch for the moment it becomes exploitable. That moment is usually when the third-party resource:

• Is deleted or deprovisioned by the legitimate owner, but
• The DNS CNAME or record pointing to it remains.

At that point, an attacker who can legitimately acquire the now-unused provider resource (for example, a free GitHub Pages repo with a matching name, or a cloud resource with a predictable hostname) can serve content under the original subdomain. That content can be used to:

• Host convincing phishing pages that look like the real service
• Capture credentials or tokens entered by users
• Serve malware or redirect traffic to malicious infrastructure

Important: discussing this conceptually is useful for defense. Publishing step-by-step instructions for acquiring third-party resources would facilitate malicious activity, so we avoid those specifics here.

How to Detect & Prevent Subdomain Takeover (Defender Playbook)

Below are practical, actionable defensive measures you can implement immediately.

1. Inventory & Ownership

• Keep a central inventory of all domains and subdomains your organization owns or uses.
• Track owner/team, purpose, and lifecycle status (active, deprecated, retired).

2. Enforce Decommissioning Workflows

• Make DNS cleanup part of the service decommission checklist. When a service is retired, remove related DNS records or replace them with safe placeholders.

3. Monitor DNS Continuously

• Automate scans for DNS records that point to third-party providers (GitHub Pages, S3, ELB, Zendesk, etc.) or to hosts with short TTLs or ephemeral patterns.
• Alert on records that reference provider targets commonly used in takeovers.

4. Prioritize Risk

• Not all dangling records carry equal risk. Prioritize remediation for:
  • Subdomains visible to customers (login, support, billing)
  • Records pointing to third-party platforms with easily-claimable names
  • Records linked to account or credential collection systems

5. Control Delegation & Permissions

• Restrict who can create or change DNS records. Use RBAC and approval workflows for DNS changes.
• Audit DNS changes regularly.

6. Use DNS & Email Protections

• Implement SPF, DKIM, and DMARC to reduce phishing success even if a domain is imitated.
• Consider HTTP security headers and strong authentication on exposed services.

7. Perform Regular OSINT Checks

• Periodically check Certificate Transparency logs (crt.sh), passive DNS databases, and public code repositories for unexpected entries that reference your domain.

8. Integrate Remediation with Alerts

• When a risky record is found, provide an actionable remediation workflow: who should remove it, proposed replacement, and audit trail.

Why Continuous Monitoring Beats One-Off Audits

Subdomain takeover risk is dynamic:
records are added, systems are decommissioned, and cloud resources are created or removed regularly. One-time audits catch problems at a moment in time — continuous monitoring catches them when they become dangerous.

That’s the core value proposition for DNS monitoring systems: they make an invisible, fast-moving risk visible and actionable.

Closing Thoughts

Finding vulnerable CNAME records is straightforward for anyone who knows where to look. The defensive question is: will you find them first?

Automated detection and a short remediation workflow dramatically reduce the window of opportunity for attackers. Whether you build or buy a monitoring solution, the critical steps are the same: inventory, automate detection, prioritize risk, and remediate quickly.

If you manage domains, make DNS hygiene part of your lifecycle and deployment processes — and treat forgotten DNS entries as a security issue, not an IT annoyance.