* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
If you discover some domain (domain.tld) that is **being used by some service inside the scope** but the **company** has l**o**st the **ownership** of it, you can try to **register** it (if cheap enough) and let know the company. If this domain is receiving some **sensitive information** like a sessions cookie via **GET** parameter or in the **Referer** header, this is for sure a **vulnerability**.
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 take over.
There are several tools with dictionaries to check for possible takeovers:
### Subdomain Takeover Generation via DNS Wildcard
When DNS wildcard is used in a domain, any requested subdomain of that domain that doesn't have a different address explicitly will be **resolved to the same information**. This could be an A ip address, a CNAME...
For example, if `*.testing.com` is wilcarded 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 point 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 Gihub 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](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
Recently, I [wrote](https://0xpatrik.com/subdomain-takeover-basics/) about subdomain takeover basics. Although the concept is now generally well-understood, I noticed that people usually struggle to grasp the risks that subdomain takeover brings to the table. In this post, I go in-depth and cover the most notable risks of _subdomain takeover_ from my perspective.
_Note: Some risks are mitigated implicitly by the cloud provider. For instance, when subdomain takeover is possible on Amazon CloudFront, there is no way you can set up TXT records to bypass SPF checks. The post, therefore, aims to provide risks on general subdomain takeover. Nevertheless, most of these apply to cloud providers as well._
Note that step #7 requests _sub.example.com_ rather than _anotherdomain.com_. That is because the web browser is not aware that _anotherdomain.com_ even exist. Even though CNAME record is used, the URL bar in the browser still contains _sub.example.com_. This is the **transparency** for the browser. If you think about that, the browser places all the trust in the DNS resolver to provide accurate information about the domain. Simplified, subdomain takeover is a DNS spoofing for one particular domain across the Internet. Why? Because any browser performing the DNS resolution on affected domain receives A record set by an attacker. The browser then happily shows whatever is received from this server (thinking that is legitimate).
Such a domain makes a perfect scenario for phishing. Attackers are often using [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) or so-called [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) to mimic the legitimate domain/website for phishing purposes. After an attacker takes over some legitimate domain name, it is almost impossible for a regular user to tell whether the content on the domain is provided by a legitimate party or an attacker. Let's take for instance a random bank. If one of the bank's subdomains is vulnerable to subdomain takeover, an attacker can create an HTML form which mimics the login form to the bank's internet banking system. Then, an attacker can run spear phishing or mass phishing campaign asking users to log in to and change their passwords. At this stage, the passwords are captured by an attacker who is in control of the domain in question. The URL provided in the phishing e-mail is a legitimate subdomain of a bank. Therefore users are not aware of something malicious going on. Spam filters and other security measurements are also less likely to trigger the e-mail as spam or malicious because it contains domain names with higher trust.
Indeed, the domain name itself place a significant role in a successful campaign. Having 5th level subdomain vulnerable to subdomain takeover is much less _"legit"_ that having a 2nd level subdomain with some friendly subdomain name. I saw several instances of perfect subdomains for phishing, including:
* _purchases.SOMETHING.com_
* _www.SOMETHING.com_
* _online.SOMETHING.com_
* _shop.SOMETHING.com_
All of them vulnerable to subdomain takeover. All of them were big brands. Talking about perfect phishing?
Nevertheless, recent phishing campaigns host content on domains with long domain names that include name of the brand (see [Apple example](https://www.phishtank.com/target\_search.php?target\_id=183\&valid=y\&active=All\&Search=Search)). Having valid SSL certificate (more on that below), keyword in domain name and website which mimics the website of targeted brand, people tend to fall into these attacks. Think about chances with a legitimate subdomain of this brand.
The attack above can be enhanced by generating a valid SSL certificate. Certificate authorities such as [_Let's Encrypt_](https://letsencrypt.org/) allow automatic verification of domain ownership by content verification:
That is, if there is a specific content placed on a specific URL path, Let's Encrypt will approve the issuance of a certificate for a given domain. Since an attacker has full control over the content of the domain which is vulnerable to subdomain takeover, this verification can be done in a matter of minutes. Therefore attackers are also able to generate SSL certificate for such domain which only lowers the suspicion of a phishing attack.
This goes hand-in-hand with browser transparency but has different consequences. Web browser implements many security policies to prevent malicious websites from causing harm. This includes things such as [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin\_policy). One of the primary security responsibilities of a browser is to secure saved cookies. Why? While HTTP is a stateless protocol, cookies are used to track sessions. For convenience, users often save cookies for an extended period to prevent logging in every single time. These cookies, therefore, act as a login token which is presented to the web server and the user is identified. Attacks such as [_Session hijacking_](https://en.wikipedia.org/wiki/Session\_hijacking) naturally evolved from this concept.
The browser automatically presents stored to cookies with every request to the domain that issued them. There is an exception to that such that cookies might be shared across subdomains ([read here](https://tools.ietf.org/html/rfc6265#section-8.6), also notice section 8.7). It usually happens when the website uses cookie-based [Single sign-on](https://en.wikipedia.org/wiki/Single\_sign-on) (SSO) system. Using SSO, a user can log in using one subdomain and share the same session token across a wide range of subdomains. The syntax for setting a regular cookie is the following:
If this cookie is issued by web server residing on _example.com_, only this server can access this cookie later on. However, the cookie can be issued for wildcard domain (for the reasons explained above) in the following manner:
The cookie will be included in HTTP requests to _example.com_ but also to any other subdomain such as _subdomain.example.com_. This behavior creates a possibility of high severity attacks using subdomain takeover. Suppose that some particular domain is using session cookies for wildcard domain. If there is one subdomain vulnerable to subdomain takeover, the only thing for gathering user’s session token is to trick him or her into visiting the vulnerable subdomain. The session cookie is automatically sent with the HTTP request.
The browser also implements additional security mechanisms for cookies:
* **HttpOnly cookie** — Cookies can by default be accessed by Javascript code running in the context of the website which created the cookies. Javascript can read, update, and delete the cookies. _HttpOnly_ cookie flag (set by the web server) indicates that the particular cookie cannot be accessed by Javascript code. The only way to get it is through HTTP request and response headers.
* **Secure cookie** — When the cookie has the _Secure_ flag set by the web server, it can be communicated back to the web server only if HTTPS is used.
If the domain is vulnerable to subdomain takeover, an attacker can gather cookies issued by that domain in the past just by tricking users into visiting that website. HttpOnly and Secure flags don't help since the cookie is not being accessed using Javascript and SSL certificate can be easily generated for the taken domain.
Cookie stealing using takeover was explained in bug bounty [report](https://hackerone.com/reports/172137) by Arne Swinnen. The report explains the problem with one of the _Ubiquiti Networks_ subdomains (_ping.ubnt.com_). This subdomain was vulnerable to subdomain takeover, pointing to unclaimed AWS CloudFront distribution. Since Ubiquiti Networks is using SSO with wildcard session cookies, all users visiting _ping.ubnt.com_ could have their session cookies stolen. Even though this domain is pointing to AWS CloudFront, CloudFront distribution settings allow logging cookies with each request. Therefore the scenario with extracting session cookies is entirely possible even with subdomains pointing to AWS CloudFront. In 2017, Arne also demonstrated similar attack vector against [Uber's SSO system](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).
The behavior explained above is not limited to cookies. Since Javascript scripts have full control over the websites, they are run on, having ability to replace such scripts on the legitimate website might lead to catastrophic consequences. Suppose that website is using Javascript code from the external provider using _script_ tag and _src_ attribute. When the domain of external provider expires, the browser fails silently, i.e., it doesn't trigger any alerts visible to regular users. If the external code is not doing any important stuff (e.g., it is used only for tracking) such external provider might stay on the website for an extended period. An attacker can take over this expired domain, match the URL path of provided Javascript code and thus gain control over every visitor that visits the original website.
There is, however, one way of protecting the integrity of Javascript files in a browser. _Subresource Integrity_ [was proposed](https://www.w3.org/TR/2016/REC-SRI-20160623/) as a mechanism to include cryptographic hash as an attribute _integrity_ to _script_ tag in HTML5. When the provided cryptographic hash does not match the download file, the browser refuses to execute it.
When CNAME subdomain takeover is possible, MX records can be set up by an attacker to an arbitrary web server as well. It allows receiving e-mails to a legitimate subdomain of some brand - particularly useful again in (spear) phishing attacks where interaction between an attacker and victim is necessary. Attackers usually spoof `Return-Path` header to receive a reply to the e-mail. With correct MX records, this problem is bypassed.
On the other side, sending e-mails is also possible. Although it is trivial to spoof `From` header to include any e-mail addresses, SPF filters are usually checking `Return-Path` header and allowed mail-sending hosts for the domain. SPF stores configuration in DNS TXT records. With subdomain takeover, TXT records are in control of attacker too - SPF checks can be passed easily.
_As I noted in the beginning, these tactics usually don't work with majority of cloud providers since you don't have control over DNS zone directly._
The concept of subdomain takeover can be naturally extended to NS records: If the base domain of at least one NS record is available for registration, the source domain name is vulnerable to subdomain takeover.
One of the problems in subdomain takeover using NS record is that the source domain name usually has multiple NS records. Multiple NS records are used for redundancy and load balancing. The nameserver is chosen randomly before DNS resolution. Suppose that the domain _sub.example.com_ has two NS records: _ns.vulnerable.com_ and _ns.nonvulnerable.com_. If an attacker takes over the _ns.vulnerable.com_, the situation from perspective of the user who queries _sub.example.com_ looks as follows:
1. Since there are two nameservers, one is randomly chosen. This means the probability of querying nameserver controlled by an attacker is 50%.
2. If user's DNS resolver chooses _ns.nonvulnerable.com_ (legitimate nameserver), the correct result is returned and likely being cached somewhere between 6 and 24 hours.
3. If user's DNS resolver chooses _ns.vulnerable.com_ (nameserver owned by an attacker), an attacker might provide a fake result which will also be cached. Since an attacker is in control of nameserver, she can set TTL for this particular result to be for example one week.
The process above is repeated every time the cache entry expires. When an attacker chooses to use TTL with high value, the fake result will stay in DNS cache for that period. During this time, all requests to _sub.example.com_ will use fake DNS result cached by an attacker. This idea is even amplified when public DNS resolvers (e.g., Google DNS) are used. In this case, public resolvers are likely to cache the fake results which means that all users using the same DNS resolver will obtain fake results until the cache is revoked.
In addition to control over the source domain name, control over all higher-level domains of source domain name is gained as well. That is because owning a canonical domain name of NS record means owning the full DNS zone of the source domain name.
In 2016, Matthew Bryant [demonstrated](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html) a subdomain takeover using NS record on _maris.int_. The .INT top-level domain is a special TLD, and the only handful of domains are using it. Bryant showed that even though registration of such domain names is approved exclusively by IANA, nameservers can be set to arbitrary domains. Since one of _maris.int_ nameservers was available for registration (_cobalt.aliis.be_), subdomain takeover was possible even on this restricted TLD.
Matthew also [demonstrated](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html) even higher severity attack where he was able to gain control over nameserver of .IO top-level domain. Gaining control over .IO means controlling responses for all .IO domain names. In this case, one of .IO nameservers were _ns-a1.io_ which was available for registration. By registering _ns-a1.io_ Bryant was able to receive DNS queries and control their responses for all .IO domains.
* **Remove the affected DNS record** — The simplest solution is to remove the affected record from the DNS zone. This step is usually used if the organization concludes that the affected source domain name is no longer needed.
* **Claim the domain name** — This means registering the resource in particular cloud provider or a case of a regular Internet domain, repurchasing the expired domain.
To prevent subdomain takeover in the future, organizations should change the process of creating and destructing resources in their infrastructure. In case of resource creation, the DNS record creation has to be the _last step_ of this process. This condition prevents DNS record to be pointing to a non-existing domain at any point in time. For resource destruction, the opposite holds: DNS record needs to be removed as the _first step_ in this process. Tools such as [aquatone](https://github.com/michenriksen/aquatone) include checks for subdomain takeover. The checks should be periodically performed by a security team of an organization to verify that there are no vulnerable domains. Processes for central collection of exposed domain names are often not efficient inside organizations (due to global teams, etc.) and external monitoring is usually the best way to go.
Mitigation strategy for cloud providers should be considered as well. Cloud services are not verifying the domain ownership. The reason behind this is primarily convenience. Cloud provider is not introducing any vulnerability by not verifying ownership of a source domain name. It is therefore up to the user to monitor its DNS records. Another reason is, that when cloud resource is removed, the user is usually no longer a customer of that service. The question cloud providers then ask themselves is: Why should we even care?
Providers such as [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/) realized that subdomain takeover is an issue and implemented a domain verification mechanism.
_Some parts of this post are excerpts from my_ [_Master's Thesis_](https://is.muni.cz/th/byrdn/Thesis.pdf).
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
