Identify and prevent subdomain takeover vulnerabilities before attackers exploit them. Automated scanning detects dangling DNS records pointing to unclaimed cloud services across AWS, Azure, Heroku, GitHub, and 40+ platforms.
Understanding the attack vector helps prevent exploitation
Your team creates a subdomain (promo.yourcompany.com) pointing to a cloud service like AWS S3, Heroku app, or GitHub Pages for a marketing campaign or temporary project.
The project ends and the cloud resource is deleted—S3 bucket removed, Heroku app destroyed, or GitHub repository deleted. The DNS CNAME record remains active pointing to the now-unclaimed service.
An attacker scans for dangling DNS records using automated tools. They identify that your subdomain points to a service identifier that no longer exists or is unclaimed.
The attacker creates a new resource with the exact same identifier (S3 bucket name, Heroku app name, etc.). Your DNS record now resolves to their controlled resource.
The attacker now controls your subdomain and can host phishing pages, steal session cookies, distribute malware, damage brand reputation, or perform SEO poisoning—all appearing to come from your legitimate domain.
The impact extends beyond the compromised subdomain
Attackers host convincing phishing pages on your subdomain. Users trust the domain and enter credentials, payment information, or personal data. The attack appears legitimate because it uses your company's domain.
If your application sets cookies for the parent domain, the compromised subdomain can access those cookies. Attackers steal authentication tokens and session identifiers, gaining unauthorized access to user accounts.
Malicious content hosted on your domain damages customer trust and brand reputation. Search engines may flag your entire domain. Customer complaints and negative media coverage follow when attacks are discovered.
Attackers use your subdomain to host spam content, black-hat SEO pages, or malicious redirects. Your domain authority is exploited to rank their content. Google may penalize your entire domain in search results.
Subdomain takeovers may violate data protection regulations if customer information is exposed. Compliance frameworks (SOC 2, ISO 27001) require asset inventory management. Auditors flag dangling DNS records as security gaps.
Average time between service decommissioning and discovery is 6-12 months. Attackers have extended access to your subdomain during this period. The longer the exposure, the greater the potential damage and harder the cleanup.
Comprehensive coverage across 40+ cloud platforms and hosting services
Static website hosting on deleted buckets. Bucket names are globally unique and claimable.
Deprovisioned apps with custom domains. App names can be recreated by attackers.
Deleted repositories with custom domains. Repository names are reclaimable.
Cloud Services, App Service, Traffic Manager endpoints. Deleted instances remain claimable.
Deleted stores with custom domains. Store names can be registered by attackers.
Removed CDN configurations. Service names become available for claiming.
Deleted distributions pointing to removed S3 origins or custom origins.
Deleted App Platform apps and Spaces buckets with custom domains.
Deleted Firebase Hosting sites. Project identifiers can be reused.
Deleted blogs with custom domains. Blog names become available.
Deleted deployments with custom domains. Project names can be claimed.
Deleted sites with custom domains. Site names are reclaimable.
Our detection engine maintains an updated database of vulnerable service fingerprints across 40+ platforms. We continuously add new services as cloud providers evolve. Detection logic is updated weekly based on research from the security community and our own testing.
Multi-stage verification process minimizes false positives
Extract all CNAME records from your subdomains. Identify records pointing to external services rather than your own infrastructure. Parse target hostnames to determine the cloud provider and service type. Filter out internal services and known safe configurations.
Attempt connections to each subdomain over HTTP and HTTPS. Record response codes, headers, and body content. Analyze redirect chains and certificate information. Measure response times and connection failures indicating service unavailability.
Compare response content against known vulnerable service fingerprints. Detect error messages like "NoSuchBucket" (AWS S3), "No such app" (Heroku), or "There isn't a GitHub Pages site here" (GitHub). Match HTTP status codes and headers characteristic of unclaimed services.
Perform platform-specific checks to verify the service doesn't exist or isn't owned by you. For AWS S3, verify bucket doesn't exist or has public access restrictions. For Heroku, check app existence via API. For GitHub, verify repository status.
Eliminate false positives through multiple verification rounds. Recheck findings across different geographic locations. Verify consistency over multiple scan cycles. Filter out intentional redirects and maintenance pages that mimic vulnerability signatures.
Assign severity levels based on exploitability and impact. Critical: Confirmed takeover vulnerability with simple exploitation. High: Likely vulnerable but requires additional verification. Medium: Suspicious configuration requiring investigation. Provide remediation guidance for each finding.
Remediation: Either delete the DNS CNAME record immediately, or recreate the S3 bucket with the same name and configure proper bucket policies to prevent unauthorized access.
Remediation: Remove the CNAME record or recreate the Heroku app with the same name. If recreating, ensure proper access controls and monitoring are in place before updating DNS.
Remediation: Remove the DNS record or recreate the GitHub repository with Pages enabled. Verify the custom domain configuration in GitHub repository settings matches your DNS records.
When decommissioning cloud services, remove DNS records simultaneously—not as a separate cleanup task. Implement deployment pipelines that automatically remove DNS entries when services are destroyed. Use infrastructure-as-code to manage both resources and DNS together.
Document all subdomains and their associated cloud resources. Record service identifiers (bucket names, app names, repository names). Track ownership and lifecycle information. Regular audits identify orphaned DNS records before they become vulnerable.
Require manager approval for subdomain creation. Document business justification and expected lifecycle. Set expiration dates for temporary subdomains. Automated reminders alert owners before resources are scheduled for decommissioning.
Continuous automated scanning detects takeover risks within minutes of configuration changes. Alert security teams immediately when vulnerabilities are found. Historical tracking shows trends and helps identify problematic processes or teams.
For critical subdomains, reserve the service identifier even after decommissioning. Keep minimal placeholder S3 buckets, Heroku apps, or GitHub repositories to prevent claiming. This costs little but provides strong protection.
Use DNS Certification Authority Authorization (CAA) records to control which CAs can issue certificates for your domains. While this doesn't prevent takeovers directly, it limits the attacker's ability to obtain valid SSL certificates for the compromised subdomain.
Security researchers discovered multiple Microsoft subdomains vulnerable to takeover through dangling Azure DNS records. Affected domains included marketing sites and product documentation. The vulnerability persisted for months before discovery.
Lesson: Even major technology companies with substantial security teams can fall victim to subdomain takeovers when DNS hygiene isn't maintained.
Multiple UK government subdomains were found vulnerable to takeover via GitHub Pages. Researchers demonstrated control by hosting proof-of-concept pages. The vulnerability existed for an extended period across several departments.
Lesson: Organizations with distributed teams and multiple departments need centralized DNS management and automated monitoring to prevent gaps.
Security researcher discovered multiple Uber subdomains vulnerable through various cloud services. Some subdomains had existed in vulnerable state for over a year. Researcher received bug bounty payouts for responsible disclosure.
Lesson: Regular security testing and bug bounty programs help identify vulnerabilities, but automated continuous monitoring provides faster detection and remediation.
Start detecting dangling DNS vulnerabilities today. Free plan includes weekly scans. Professional plan offers continuous monitoring with real-time alerts.
Start Free Security Scan