What is a subdomain takeover?
Subdomain takeover occurs when an attacker exploits a DNS record that redirects a subdomain to an inactive or non-existent external resource. To achieve a takeover, the attacker must take control over the external resource that the subdomain points to. Consequently, anyone accessing the compromised subdomain will unknowingly receive content from the resource under the attacker’s control.
How can a subdomain takeover happen?
For a subdomain takeover to be possible, the following two conditions must be met: firstly, a defunct DNS record exists which is configured to point a subdomain to an external resource that has been deleted or de-provisioned. Secondly, the service provider responsible for hosting the external resource does not properly verify ownership of the subdomain. Bottom of Form
Who can be affected?
Ultimately, subdomain takeover is caused by poor DNS hygiene resulting in obsolete DNS records not being removed or amended.
This is more likely to occur in organisations that regularly create and delete resources, and whom do not have sufficient monitoring and visibility over changes in their assets.
As organizations become progressively more reliant on cloud-based virtual hosting platforms (like Azure and AWS) and various third-party service providers (like Github, Helpjuice and Squarespace etc.), there is an increasing likelihood of DNS records for inactive external resources being overlooked.
Why would an attacker want to do this?
The consequences of a successful subdomain takeover can be prolific, and so too are the benefits for a malicious actor.
Some of the many motives for conducting a subdomain takeover include stealing session cookies to gain unauthorized access to a legitimate application, launching phishing campaigns to steal sensitive information from victims, and defacing the website to cause reputational damage.
Digging Deeper: DNS and Subdomain Takeover
At its core, the Domain Name System (DNS) functions to translate human-friendly domain names (like example.com) to machine-usable IP addresses (like 192.172.40.5). To provide this service, DNS utilises a variety of different types of records.
Most commonly, subdomain takeover will target vulnerable canonical name (CNAME) records. This type of record is effectively an alias which maps one domain name to another domain name (such as oldsite.com to newsite.com). If a CNAME record has been configured for a domain, any users visiting the domain will in fact be served content from the other domain that is it is pointing to.
However, subdomain takeover is not restricted to only CNAME records. Various forms of DNS record — including NS, MX and A records — can be exploited by subdomain takeover if vulnerable.
Example subdomain takeover scenario
An organisation — ExampleOrg — own the website examplesite.com. The organisation wants a knowledgebase to support customers in using their product.
ExampleOrg decide to use a third-party service to create this knowledgebase. In this scenario, the example third-party service is ‘KB-Provider’.
ExampleOrg register with KB-Provider and are given an instance of their knowledgebase at examplesite.kb-provider.com.
ExampleOrg want to keep the application, and their brand, looking consistent. To do so, they want the knowledgebase to be accessible via one of their sub-domains — help.examplesite.com.
KB-Provider, like many third-party service providers of its kind, allow ExampleOrg to do this by creating a CNAME record that points help.examplesite.com to examplesite.kb-provider.com, like so:
Now, when customers visit help.examplesite.com, DNS will return the IP address of the web server hosting examplesite.kb-provider.com:
Importantly, DNS performs this redirection in the background. Neither the end-user nor the browser is aware of this translation or that examplesite.kb-provider.com even exists because the browser continues to display the original domain in the address bar, like so:
A few months later, ExampleOrg cancels its subscription to KB-Provider. Their knowledgebase instance (examplesite.kb-provider.com) is deleted. Crucially, ExampleOrg forget to remove the CNAME record. Whilst the CNAME record exists, help.examplesite.com will continue to be advertised as an active domain but it won’t route requests to an active resource. This is also referred to as a ‘dangling DNS record’.
An attacker, using one of the many tools available to discover vulnerable subdomains, identifies help.examplesite.com and associated dangling CNAME record and decides to target the organisation.
The attacker creates an account with the third-party service and registers the name and instance of examplesite.kb-provider.com.
The attacker now has full control over what the vulnerable subdomain serves to the end-user until the CNAME record is removed or amended.
This is subdomain takeover.
Digging Deeper: The Risks
As discussed in the example scenario above; neither the user nor the browser is aware when DNS resolves a requested subdomain to another resource. The CNAME record is a behind-the-scenes mapping that redirects the request to the specified domain pointed to by the record, but the user’s browser is unaware of this redirection and continues to display the original domain in the address bar. The user only sees the requested subdomain and has no awareness that the content being displayed is actually coming from a different location. Consequently, users would not have any visible indications to alert them if an attacker gains control over the external resource and manipulates the content to closely resemble the legitimate application.
Additionally, because the browser implicitly trusts the information that the DNS resolver returns, the built-in security protections that a browser provides (including the same-origin policy) are circumvented.
Due to the factors above, subdomain takeover is a particularly effective exploit that can be leveraged in a wide array of attacks. Some of the notable objectives of such attacks are discussed in more detail below.
Cookie Theft
In most web applications, session cookies are provided following authentication and supplied with every subsequent request to the application in order to verify the identity of a user. Hence, if an attacker can steal a valid session cookie, they can bypass the authentication process and gain unauthorized access to the user’s account, with the same privileges and permissions as the legitimate user.
Consider the following common cookie configuration:
Set-Cookie: session=value; domain=example.com; HttpOnly; Secure; SameSite=Strict
The domain attribute determines which hosts cookies can be sent to. In the configuration above, browsers will send the session cookie in all HTTP requests sent to example.com, including any subdomains of example.com. Therefore, should there be a subdomain takeover on example.com, the attacker would be able to steal the session cookies of any user who accesses the compromised subdomain.
Note that in the event of a subdomain takeover, the security attributes applied to the cookie (e.g HttpOnly, Secure and SameSite) provide no protections.
Phishing Campaigns
In a regular phishing attack (without subdomain takeover), an attacker would register a domain that resembles the legitimate application as closely as possible in order to fool a victim into clicking a seemingly innocuous link. For example, they may create the domain mys1te.com to mimic the legitimate domain mysite.com. Hopefully, most security-savvy users would detect the difference and realise they are not interacting with the genuine application.
With subdomain takeover, the domain matches the user’s expectations of the application. When combined with content that is designed to be a lookalike of the legitimate application, this creates a highly convincing phishing scenario. Hence, subdomain takeover enables an attacker to leverage the reputation of the organisation that owns the genuine domain to entice even tech-savvy users into divulging sensitive information such as credentials, PII, and payment details.
Defacement
If a malicious actor wishes to damage the reputation of an organisation, they could exploit subdomain takeover to serve defaced content over the subdomain. Such content might include offensive or defamatory material, or even just the hacker’s signature (as evidence of the attack). Resultantly, this could damage the brand and lose trust and credibility from its users.
How can organizations protect themselves from subdomain takeover?
Subdomain Management
Ensure you have complete visibility over your external assets. Maintain a comprehensive inventory of all subdomains associated with your domain. Regularly monitor and review subdomains to ensure they are active and owned by authorized personnel. Remove or update DNS entries for decommissioned subdomains promptly.
Regular Auditing and Review
Perform regular audits and reviews of the domain infrastructure, including subdomains, DNS configurations, and associated services. This helps identify any weaknesses or inconsistencies that could be exploited for subdomain takeover.
DNS Monitoring
As an additional layer of protection, consider employing DNS monitoring services or tools to receive alerts about any changes or unauthorized modifications to DNS records. Monitor DNS resolution and track DNS queries to detect any suspicious activities or unauthorized access attempts.
How can external attack surface management help mitigate subdomain takeover?
External attack surface management (EASM) can play a critical role in mitigating subdomain takeover attacks by providing organizations with visibility over their external attack surface and identifying the potential vulnerabilities that could be exploited by attackers.
Here are some specific ways that external attack surface management can help:
Gain visibility over your exposed subdomains
External attack surface management tools can scan an organization’s external infrastructure to identify all subdomains that are currently accessible. This can help organizations discover old, inactive or obsolete subdomains that could be targeted in a subdomain takeover.
Identify potential vulnerabilities in third-party services
Vulnerability discovery tools within external attack surface management platforms can also monitor third-party services used by an organization to identify any misconfigurations or vulnerabilities that could be exploited by attackers. This is particularly important as many subdomain takeover attacks occur through third-party services that are not properly configured.
Monitor domain registrations
In order to identify any unauthorised or fraudulent domain registrations that might be used to launch subdomain takeover attacks, external attack surface management solutions can also monitor domain registrations.
Track changes in activity
External attack surface management tools can monitor for changes to an organization’s external infrastructure, such as changes to DNS records or SSL certificates. This can help organizations identify any unauthorized changes that could indicate a subdomain takeover attack in progress.
Final thoughts
As we have explored in this article, subdomain takeover can lead to highly effective attacks against your organisation and user base, with potential consequences ranging from reputational damage to theft of sensitive user information and unauthorized access to the application.
Without proactive monitoring, it can be impossible to detect a subdomain takeover until it’s too late.
External attack surface management can help organizations gain visibility over their internet-facing infrastructure, empowering them to detect and remediate potential vulnerabilities before they can be exploited by attackers. By taking a proactive approach to external attack surface management, organizations can significantly reduce the risk of subdomain takeover attacks and other types of cyber attacks.
