domain-subdomain-takeover.md (13295B)
1 --- 2 title: "Domain/Subdomain takeover" 3 section: "Web Pentesting" 4 sectionSlug: "pentesting-web" 5 sourcePath: "src/pentesting-web/domain-subdomain-takeover.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/domain-subdomain-takeover.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Domain/Subdomain takeover 14 15 ## Domain takeover 16 17 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.<sup>[[1]](#references)</sup> 18 19 ### Subdomain takeover 20 21 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.<sup>[[2]](#references)</sup> 22 23 There are several tools with dictionaries to check for possible takeovers: 24 25 - [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz) 26 - [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot) 27 - [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper) 28 - [https://github.com/haccer/subjack](https://github.com/haccer/subjack) 29 - [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs) 30 - [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com/ArifulProtik/sub-domain-takeover) 31 - [https://github.com/SaadAhmedx/Subdomain-Takeover](https://github.com/SaadAhmedx/Subdomain-Takeover) 32 - [https://github.com/Ice3man543/SubOver](https://github.com/Ice3man543/SubOver) 33 - [https://github.com/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover) 34 - [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover) 35 - [https://github.com/PentestPad/subzy](https://github.com/PentestPad/subzy) 36 - [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator) 37 - [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit) 38 - [https://github.com/projectdiscovery/nuclei](https://github.com/projectdiscovery/nuclei) (use `-tags takeover` with nuclei-templates) 39 - [https://github.com/edoardottt/cariddi](https://github.com/edoardottt/cariddi) (takeover checks in crawling output) 40 41 ### Subdomain Takeover Generation via DNS Wildcard 42 43 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.<sup>[[2]](#references)</sup> 44 45 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`. 46 47 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**. 48 49 You can find an example of this vulnerability in the CTF write-up: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)<sup>[[4]](#references)</sup> 50 51 ### Lame NS delegation / DNS-provider claim ("Sitting Ducks") 52 53 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**.<sup>[[5]](#references)[[6]](#references)</sup> 54 55 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.<sup>[[5]](#references)[[6]](#references)</sup> 56 57 ```bash 58 zone=delegated.example.com 59 parent=example.com # use the TLD for a registrable-domain apex 60 pns=$(dig +short "$parent" NS | head -1) 61 62 # Obtain the actual parent-side delegation 63 dig @"${pns%.}" "$zone" NS +norecurse +noall +answer +authority 64 nslist=$(dig @"${pns%.}" "$zone" NS +norecurse +noall +authority | \ 65 awk '$4 == "NS" {print $5}') 66 67 # A correctly configured server should answer authoritatively for the zone apex 68 for ns in $nslist; do 69 echo "== $ns ==" 70 dig @"${ns%.}" "$zone" SOA +norecurse +noall +comments +answer +authority 71 done 72 ``` 73 74 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](/hacktricks/network-services-pentesting/pentesting-dns#ns-delegation-integrity--lame-delegation).<sup>[[5]](#references)[[6]](#references)</sup> 75 76 ## Exploiting a subdomain takeover 77 78 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_](https://en.wikipedia.org/wiki/Typosquatting) or [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) 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.<sup>[[1]](#references)</sup> 79 80 Check this [post for further details](https://0xpatrik.com/subdomain-takeover/)<sup>[[1]](#references)</sup> 81 82 ### **SSL Certificates** 83 84 SSL certificates, if generated by attackers via services like [_Let's Encrypt_](https://letsencrypt.org/), add to the legitimacy of these fake domains, making phishing attacks more convincing.<sup>[[1]](#references)</sup> 85 86 ### **Cookie Security and Browser Transparency** 87 88 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.<sup>[[1]](#references)</sup> 89 90 ### CORS Bypass 91 92 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.<sup>[[3]](#references)</sup> 93 94 ### CSRF - Same-Site Cookies bypass 95 96 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.<sup>[[1]](#references)[[3]](#references)</sup> 97 98 ### OAuth tokens redirect 99 100 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.<sup>[[1]](#references)</sup> 101 102 ### CSP Bypass 103 104 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.<sup>[[1]](#references)</sup> 105 106 ### **Emails and Subdomain Takeover** 107 108 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.<sup>[[1]](#references)</sup> 109 110 ### **Higher Order Risks** 111 112 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.<sup>[[1]](#references)</sup> 113 114 ### CNAME Record Vulnerability 115 116 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.<sup>[[2]](#references)</sup> 117 118 ### **Mitigation Strategies** 119 120 Mitigation strategies include: 121 122 1. **Removing vulnerable DNS records** - This is effective if the subdomain is no longer required. 123 2. **Claiming the domain name** - Registering the resource with the respective cloud provider or repurchasing an expired domain. 124 3. **Regular monitoring for vulnerabilities** - Tools like [aquatone](https://github.com/michenriksen/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. 125 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.<sup>[[5]](#references)[[6]](#references)</sup> 126 127 For cloud providers, verifying domain ownership is crucial to prevent subdomain takeovers. Some, like [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), have recognized this issue and implemented domain verification mechanisms.<sup>[[1]](#references)</sup> 128 129 ## Detection techniques 130 131 - **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](#lame-ns-delegation--dns-provider-claim-sitting-ducks). 132 - **Check provider error signatures**: match HTTP responses, TLS certs, or DNS errors to known takeover patterns (see can-i-take-over-xyz). 133 - **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. 134 - **Passive DNS and historical records**: old CNAMEs often reveal previously used third-party services that may still be vulnerable. 135 - **Wildcard pitfalls**: confirm wildcard DNS vs. explicit records to avoid false positives and understand takeover amplification. 136 137 ## APIs and data sources 138 139 - [https://securitytrails.com/](https://securitytrails.com/) (historical DNS, passive DNS API) 140 - [https://community.riskiq.com/](https://community.riskiq.com/) (PassiveTotal) 141 - [https://www.farsightsecurity.com/solutions/dnsdb/](https://www.farsightsecurity.com/solutions/dnsdb/) 142 - [https://www.domaintools.com/products/iris/](https://www.domaintools.com/products/iris/) 143 - [https://search.censys.io/](https://search.censys.io/) (certs and host data) 144 - [https://www.shodan.io/](https://www.shodan.io/) (host data) 145 - [https://www.virustotal.com/](https://www.virustotal.com/) (historical DNS, URLs) 146 - [https://chaos.projectdiscovery.io/](https://chaos.projectdiscovery.io/) (subdomains dataset) 147 148 149 ## References 150 151 - [1] [Subdomain Takeover: Thoughts on Risks - 0xpatrik](https://0xpatrik.com/subdomain-takeover/) 152 - [2] [Subdomain Takeover Guide - Stratus Security](https://www.stratussecurity.com/post/subdomain-takeover-guide) 153 - [3] [A Guide To Subdomain Takeovers - HackerOne](https://www.hackerone.com/blog/guide-subdomain-takeovers-20) 154 - [4] [Undocumented JS API - niteCTF 2022 write-up](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api) 155 - [5] [Who Knew? Domain Hijacking is So Easy - Infoblox](https://www.infoblox.com/blog/threat-intelligence/who-knew-domain-hijacking-is-so-easy/) 156 - [6] [Ducks Now Sitting (DNS): Internet Infrastructure Insecurity - Eclypsium](https://eclypsium.com/blog/ducks-now-sitting-dns-internet-infrastructure-insecurity/)