DΛΣMӨП

// HackTricks · Web Pentesting

Domain/Subdomain takeover

Domain/Subdomain takeover

Domain takeover

If an in-scope service still depends on a domain whose registration has expired, an authorized tester may be able to register it and demonstrate a domain takeover. The impact increases when applications send the domain sensitive data in URL parameters, redirects, or the Referer header.[1]

Subdomain takeover

A subdomain of the company is pointing to a third-party service with a name not registered. If you can create an account in this third party service and register the name being in use, you can perform the subdomain takeover.[2]

There are several tools with dictionaries to check for possible takeovers:

Subdomain Takeover Generation via DNS Wildcard

When wildcard DNS is used, a queried name without a more specific matching record can resolve through the wildcard. The wildcard may provide an A/AAAA record or a CNAME.[2]

For example, if *.testing.com is wildcarded to 1.1.1.1. Then, not-existent.testing.com will be pointing to 1.1.1.1.

However, if instead of pointing to an IP address, the sysadmin points it to a third party service via CNAME, like a GitHub subdomain for example (sohomdatta1.github.io). An attacker could create his own third party page (in GitHub in this case) and say that something.testing.com is pointing there. Because the CNAME wildcard will agree, the attacker will be able to generate arbitrary subdomains for the domain of the victim pointing to his pages.

You can find an example of this vulnerability in the CTF write-up: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api[4]

Lame NS delegation / DNS-provider claim (“Sitting Ducks”)

A domain does not need to expire for its DNS to be taken over. In a Sitting Ducks scenario, the parent continues to delegate a registered domain or subzone to a third-party authoritative DNS provider, that provider no longer has an active zone for it, and the provider lets another account create the same zone on nameservers matching the parent delegation without strong ownership validation. An attacker can then publish arbitrary records without access to either the registrar or the victim’s former DNS-provider account. This is different from registering an expired nameserver domain: the contested resource is the hosted zone at the provider.[5][6]

Read the referral from the parent zone, because a recursive NS query can return cached or child-side data. Then query every delegated server directly and look for an authoritative (aa) SOA response. REFUSED, SERVFAIL, timeouts, or an answer without aa/SOA indicate a broken delegation, but do not prove that the provider will allow the zone to be claimed.[5][6]

zone=delegated.example.com
parent=example.com                 # use the TLD for a registrable-domain apex
pns=$(dig +short "$parent" NS | head -1)

# Obtain the actual parent-side delegation
dig @"${pns%.}" "$zone" NS +norecurse +noall +answer +authority
nslist=$(dig @"${pns%.}" "$zone" NS +norecurse +noall +authority | \
  awk '$4 == "NS" {print $5}')

# A correctly configured server should answer authoritatively for the zone apex
for ns in $nslist; do
  echo "== $ns =="
  dig @"${ns%.}" "$zone" SOA +norecurse +noall +comments +answer +authority
done

If only some servers are lame or claimable, resolution and attacker control can be intermittent. Validate provider ownership requirements separately; a provider error page or one non-authoritative DNS response is only a lead. Creating the zone can disrupt production DNS, so a proof such as an authorized random TXT record should only be attempted with explicit permission. For general delegation-integrity checks, also see Pentesting DNS.[5][6]

Exploiting a subdomain takeover

Subdomain takeover is essentially DNS spoofing for a specific domain across the internet, allowing attackers to set A records for a domain, leading browsers to display content from the attacker’s server. This transparency in browsers makes domains prone to phishing. Attackers may employ typosquatting or Doppelganger domains for this purpose. Especially vulnerable are domains where the URL in a phishing email appears legitimate, deceiving users and evading spam filters due to the domain’s inherent trust.[1]

Check this post for further details[1]

SSL Certificates

SSL certificates, if generated by attackers via services like Let’s Encrypt, add to the legitimacy of these fake domains, making phishing attacks more convincing.[1]

Cookie impact depends on cookie scope. A host-only cookie for example.com is not sent to taken.example.com, while a cookie set with Domain=example.com is sent to matching subdomains. HttpOnly prevents JavaScript from reading a cookie but does not prevent the browser from attaching a domain-scoped cookie to a request to the compromised host. Secure only restricts the transport to HTTPS.[1]

CORS Bypass

It might be possible that every subdomain is allowed to access CORS resources from the main domain or other subdomains. This could be exploited by an attacker to access sensitive information abusing CORS requests.[3]

CSRF - Same-Site Cookies bypass

A compromised subdomain is normally same-site with sibling hosts under the same registrable domain, although it is not same-origin. Therefore, SameSite alone may not block cross-origin requests initiated from that subdomain; correctly validated anti-CSRF tokens and Origin/Referer checks are still important.[1][3]

OAuth tokens redirect

If an OAuth client accepts the compromised subdomain in a redirect_uri, an attacker may be able to receive authorization codes or tokens sent to that URI.[1]

CSP Bypass

If a CSP directive such as script-src trusts the compromised subdomain or an overly broad wildcard, the attacker-controlled host may become a permitted script source and strengthen an injection flaw.[1]

Emails and Subdomain Takeover

Another aspect of subdomain takeover involves email services. Attackers can manipulate MX records to receive or send emails from a legitimate subdomain, enhancing the efficacy of phishing attacks.[1]

Higher Order Risks

Further risks include NS delegation takeover. If a parent zone delegates a domain or subdomain to an attacker-controlled or re-registerable nameserver, the attacker may answer authoritatively for that delegated namespace. Cached records and TTLs affect how quickly changes propagate.[1]

CNAME Record Vulnerability

Attackers may exploit dangling CNAME records that point to an external resource which has been deleted but can be claimed again. Provider-specific ownership validation can prevent the claim, so a dangling record is not automatically exploitable.[2]

Mitigation Strategies

Mitigation strategies include:

  1. Removing vulnerable DNS records - This is effective if the subdomain is no longer required.
  2. Claiming the domain name - Registering the resource with the respective cloud provider or repurchasing an expired domain.
  3. Regular monitoring for vulnerabilities - Tools like aquatone can help identify susceptible domains. Organizations should also revise their infrastructure management processes, ensuring that DNS record creation is the final step in resource creation and the first step in resource destruction.
  4. Coupling delegations to hosted-zone lifecycle - Change or remove parent-side NS records first, wait out their TTL, and only then delete the old provider zone/account. Periodically compare parent delegations with active provider inventory and prefer providers that validate control before accepting a zone.[5][6]

For cloud providers, verifying domain ownership is crucial to prevent subdomain takeovers. Some, like GitLab, have recognized this issue and implemented domain verification mechanisms.[1]

Detection techniques

  • Find dangling DNS records: look for CNAME/A/AAAA/ALIAS/ANAME records pointing to non-existent resources (deleted buckets, apps, pages, load balancers), and inspect NS referrals with the parent-side lame-delegation procedure.
  • Check provider error signatures: match HTTP responses, TLS certs, or DNS errors to known takeover patterns (see can-i-take-over-xyz).
  • Look for orphaned cloud assets: verify S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian, and similar services.
  • Passive DNS and historical records: old CNAMEs often reveal previously used third-party services that may still be vulnerable.
  • Wildcard pitfalls: confirm wildcard DNS vs. explicit records to avoid false positives and understand takeover amplification.

APIs and data sources

References