Offensive security assessments

Subdomain Takeover

A subdomain takeover happens when a DNS record (usually a CNAME, sometimes A/NS) still points to a cloud service or external provider that is no longer claimed. An attacker registers the dangling resource on that provider and serves their own content from the victim's subdomain,…

Why it matters

A subdomain takeover happens when a DNS record (usually a CNAME, sometimes A/NS) still points to a cloud service or external provider that is no longer claimed. An attacker registers the dangling resource on that provider and serves their own content from the victim's subdomain, enabling phishing, cookie theft, OAuth redirect abuse, and bypass of domain-scoped CSP or CORS trust.

How we test it

Our operators follow a structured checklist for this topic, adapted to your API surface and authentication model.

Testing approach

  • A team provisions app.example.com - example.s3.amazonaws.com (or Azure, GitHub Pages, Heroku, etc.)
  • The service/bucket is later deleted, but the DNS record stays
  • The subdomain now resolves to an unclaimed resource, which the attacker re-creates.
  • subfinder -d example.com -all -o subs.txt amass enum -passive -d example.com subs.txt
  • dnsx -l subs.txt -cname -resp -o cnames.txt
  • httpx -l subs.txt -status-code -title -o live.txt
  • Match the fingerprint against the can-i-take-over-xyz list, then validate by claiming the resource with a harmless proof file (do not host malicious content).
  • Remove DNS records the moment the backing resource is decommissioned (deprovision DNS before the service).

What we look for

  • A team provisions app.example.com - example.s3.amazonaws.com (or Azure, GitHub Pages, Heroku, etc.)
  • The service/bucket is later deleted, but the DNS record stays
  • The subdomain now resolves to an unclaimed resource, which the attacker re-creates.
  • subfinder -d example.com -all -o subs.txt amass enum -passive -d example.com subs.txt
  • dnsx -l subs.txt -cname -resp -o cnames.txt
  • httpx -l subs.txt -status-code -title -o live.txt
  • Match the fingerprint against the can-i-take-over-xyz list, then validate by claiming the resource with a harmless proof file (do not host malicious content).
  • Remove DNS records the moment the backing resource is decommissioned (deprovision DNS before the service).

Related topics

TopicSummary
AWSWe validate this area during scoped assessments, documenting impact and remediation guidance.
AzureWe validate this area during scoped assessments, documenting impact and remediation guidance.
GCPWe validate this area during scoped assessments, documenting impact and remediation guidance.