Subdomain takeover is a vulnerability where an attacker gains control of a company's subdomain by exploiting a dangling DNS record — a CNAME or A record that still points at a cloud service or third-party platform that the company has already deprovisioned. The DNS entry exists; the resource behind it does not. Any attacker who re-registers that deprovisioned resource instantly inherits the authority of your brand's subdomain. For Indian companies scaling rapidly on cloud infrastructure, this is one of the most underestimated attack surfaces in existence.
How Subdomain Takeover Actually Works
The mechanics are straightforward, and that is precisely what makes this dangerous.
A development team provisions a staging environment on a cloud platform — say, an S3 bucket, a GitHub Pages site, or a Heroku app — and creates a DNS CNAME record pointing staging.yourcompany.com to that resource. The project ends. The engineer deletes the cloud resource. The DNS record, however, is never touched. It continues to exist in your zone file, quietly pointing at nothing your company owns anymore.
An attacker runs subdomain enumeration against your domain. They discover staging.yourcompany.com resolves via a CNAME to yourcompany-staging.s3-website-ap-south-1.amazonaws.com. They attempt to create an S3 bucket with that exact name. Amazon allows it — the name is unclaimed. The attacker now controls what loads at staging.yourcompany.com.
staging.company.com]:::safe --> B[CNAME points to
cloud service resource]:::safe B --> C[Resource decommissioned
by team]:::warn C --> D[DNS record left behind
dangling CNAME]:::danger D --> E[Attacker enumerates
subdomains]:::danger E --> F[Attacker re-registers
the cloud resource]:::danger F --> G[Attacker fully controls
staging.company.com]:::danger G --> H1[Phishing pages
under trusted domain]:::danger G --> H2[Session cookie
and OAuth theft]:::danger G --> H3[Malware hosting
under brand subdomain]:::danger classDef safe fill:#1e3d2f,stroke:#10B981,color:#e2e8f0 classDef warn fill:#3d3010,stroke:#F59E0B,color:#e2e8f0 classDef danger fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
The entire attack requires no zero-day, no social engineering, and no breach of your infrastructure. It exploits a process gap — the gap between infrastructure decommissioning and DNS hygiene.
Why Indian Companies Are Particularly Exposed
Indian companies have been on an aggressive cloud adoption curve across the last decade. Fast-moving engineering teams provision resources to meet sprint deadlines; decommissioning processes rarely receive the same attention. The result is accumulated DNS debt — dozens or hundreds of CNAME records pointing at resources that no longer exist.
The exposure compounds when organisations use multiple SaaS platforms, PaaS providers, and CDN vendors simultaneously. Each integration creates potential dangling records when that contract or project ends.
The Real-World Impact
Understanding what an attacker can actually do once they control a subdomain is essential context for any risk conversation with leadership.
Phishing under a trusted domain. A subdomain like login.yourcompany.com or portal.yourcompany.com carries immediate brand authority. Users — and email security filters — see the parent domain and extend trust. A phishing page hosted there is substantially harder to detect than one on an unrelated domain.
Session cookie theft. Browser cookie scope is domain-based, not URL-based. If your application sets cookies on .yourcompany.com without the Domain attribute scoped narrowly, a controlled subdomain can read those cookies. An attacker hosting JavaScript on your subdomain can exfiltrate session tokens.
OAuth redirect abuse. Many applications register OAuth redirect URIs as wildcard patterns or at the domain level. A controlled subdomain can be used as a valid redirect target, capturing authorisation codes for your own application's OAuth flows.
CSP and SPF bypass. If your Content Security Policy allowlists your own domain (*.yourcompany.com), scripts hosted on a controlled subdomain pass the CSP check. Similarly, if the takeover subdomain can send email, SPF records that include your IP ranges may extend partial trust to attacker-controlled mail.
Malware hosting and SEO poisoning. The attacker can host any content under your domain — malware payloads, phishing kits targeting your users, or spammy SEO pages that damage your domain reputation with search engines.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanHow Attackers Find Your Dangling Records
Attackers do not enumerate your infrastructure manually. They use automated tooling and passive intelligence sources.
Certificate Transparency logs. Every TLS certificate issued for your subdomains is publicly logged in CT logs (crt.sh, Censys). Attackers query these logs to enumerate every subdomain that has ever had a certificate — including long-decommissioned ones.
Passive DNS databases. Services like SecurityTrails, DNSDB, and VirusTotal's passive DNS maintain historical resolution records. An attacker can see every CNAME that *.yourcompany.com has pointed at, even years back.
Active subdomain enumeration. Tools perform brute-force DNS enumeration using wordlists, then fingerprint each response. CNAME records returning HTTP 404 or service-specific "no such app" pages are reliable indicators of takeover candidates.
Automated takeover scanning. Open-source tools purpose-built for this task identify the specific error message signatures for dozens of cloud providers — the exact response that Heroku, GitHub Pages, AWS S3, Azure App Service, Fastly, and others return when a resource is unclaimed.
This is not attacker tradecraft that requires skill or access. It is largely automated reconnaissance available to anyone.
Detection: How to Find Dangling Records Before Attackers Do
The detection workflow is systematic. It does not require sophisticated tooling — it requires process.
| Step | Method | What to Look For |
|---|---|---|
| 1. Enumerate all DNS records | Export full zone file from your DNS provider | Every CNAME and A record across all subdomains |
| 2. Resolve each CNAME chain | Automated DNS resolution | CNAMEs that resolve to third-party domains |
| 3. Check resource existence | HTTP request to the resolved endpoint | 404s, "No such app", "NoSuchBucket", "There is no app configured at this URL" |
| 4. Cross-reference against CT logs | Query crt.sh for your domain | Subdomains with certificates that no longer have active resources |
| 5. Verify ownership | Confirm your team controls each resource | Any resource you cannot identify is a finding |
| 6. Monitor continuously | Scheduled scan or external monitoring | New dangling records created between audits |
Prevention: A Decommissioning Checklist
The right time to prevent subdomain takeover is during decommissioning — before the cloud resource is deleted.
| Decommissioning Step | Action Required | Owner |
|---|---|---|
| Cloud resource scheduled for deletion | Remove corresponding DNS records first | Infrastructure lead |
| SaaS platform subscription cancelled | Audit all subdomains pointing at that platform | Platform or DevOps |
| Contractor or agency engagement ends | Review all DNS records created during engagement | IT / Security |
| Domain migration or rebranding | Audit old zone for residual CNAME records | Infrastructure |
| CDN contract ends | Remove CNAME records before CDN deprovisioning | DevOps |
Additional preventive controls:
- Subdomain ownership registry. Maintain an internal record of every subdomain, its purpose, the resource it points at, and the team responsible. Make updating this registry a required step in both provisioning and decommissioning runbooks.
- Certificate Transparency monitoring. Tools like crt.sh alerts and open-source CT monitoring scripts alert you when new certificates are issued for your domain. An unexpected certificate for a subdomain you do not recognise is an early warning signal.
- DNS record TTL discipline. Low TTLs (300–600 seconds) on CNAME records mean that once you remove a record, the change propagates quickly. High TTLs extend the window during which stale resolutions persist.
- Require ownership tokens at provisioning. Many cloud platforms now support ownership verification via DNS TXT records. Enforce this as a provisioning requirement so that future decommissioning is verifiable.
How Attack-Surface Scanning Catches Subdomain Takeover
Manual DNS audits are periodic by nature. Attackers scan continuously. The gap between your last audit and your next is your exposure window.
Automated attack-surface scanning closes this gap. A continuous external scan — the kind performed during a free VAPT scan — enumerates your subdomains from an attacker's perspective, resolves CNAME chains, fingerprints provider-specific takeover signatures, and flags dangling records before they can be exploited.
Bachao.AI (by Dhisattva AI Pvt Ltd, a DPIIT Recognized Startup) automates this kind of continuous external reconnaissance as part of its attack-surface assessment. Rather than waiting for an annual penetration test to surface a dangling record, the platform flags it as part of routine DNS hygiene monitoring.
For organisations with compliance requirements — whether under RBI's IT Framework for NBFCs, SEBI's CSCRF guidelines, or MeitY's DPDP Act obligations — a documented DNS hygiene process with evidence of regular scanning is increasingly expected. CERT-In's guidelines on information security practices reference attack surface management as a foundational control. More context on data protection obligations is available on the DPDP compliance page.
What to Do Right Now
If you have not audited your DNS zone in the last quarter, you almost certainly have dangling records. The question is not whether the risk exists — it is whether an attacker finds them before you do.
Start with your DNS provider's zone export. Look for every CNAME pointing at a third-party domain. Verify that your team currently controls each resource at the end of that chain. Remove any record where the resource is gone or unverifiable.
Then operationalise it: add a DNS hygiene step to every decommissioning runbook, and put an external scan on a regular schedule.