A domain name is an identification string within the Internet that specifies a sphere of administrative autonomy, authority, or power. Organizations sometimes shift to different domains due to business or technical requirements and forget to renew the old ones. These abandoned domain names are very rare to find these days. When compromised, these abandoned domains affect the organization’s reputation and lead to various serious security issues. This blog will discuss different attack vectors using that an attacker can exploit abandoned domains takeover.
Don’t get confused between domain takeover and subdomain takeover. They are two separate vulnerabilities.
Subdomain takeover generally occurs when the subdomain of a domain is pointing to a service that has been removed or deleted. When the attacker takes over a subdomain, they control the vulnerable subdomain alone. All other subdomains are unaffected.
If you want to read more about subdomain takeover vulnerability, we scanned the whole internet for instances vulnerable to it, check out the study here.
Its obviously quite an embarrassing vulnerability where an attacker can takeover one of your organization’s subdomain. Now, think of an attacker taking over the whole domain? Alarming? Let’s talk a little more about it.
In contrast to subdomain takeover, Domain Takeover occurs when the organization did not renew its domain but still use it in their code and infrastructure. When the attacker registers the abandoned domain, they own the domain, including its subdomains and other types of DNS records.
If you ever encountered a domain that is in allowlist in request-response during testing, it can be an interesting attack vector to exploit. At RedHunt Labs, during an assessment of a mobile application, we encountered the same scenario. A request-response contains allowlist domains, and it was found out that one of the domains from the list is expired, and anyone can register it from the domain provider.
Request and Response looked like this.
Domain Takeover can be a severe issue as it may impact the organization’s reputation as well. There are multiple instances where one can chain the domain takeover to perform further attacks and increase the impact. This blog will talk about how we chained the Domain Takeover with deep links during a pentest and a few other attack vectors using which an attacker can exploit the domain takeover.
Exploitation Scenario 1: Chaining with Deep link
Deep links are URI (uniform resource locator) which helps to connect a particular part of the mobile application rather than simply opening the application. For example, we can generate the shareable links of specific pages of your app, and when we click on those links, that particular page of our mobile application is shown. It sends users to your app directly.
Deep Linking uses the custom URL scheme or intent scheme, which acts as a bond between the links and the mobile application. They help provide a better user experience by moving users to a particular portion of the app using a single tap.
During a pentest, we found out that allowlist domains could be loaded in the webview of the android application. We looked into the other webviews to understand how webviews are working in the application, created a Deeplink Redirect PoC for an expired domain, and hosted it on our webserver.
<!DOCTYPE html> <html> <head><title>Deeplink redirect</title></head> <body> <h1> <a href="vulnapp://internal/web_view?url=http://takeover.blog"</a> click</h1> </body> </html>
Since we were not sure that our assumptions were correct, rather than registering the takeover.blog from the domain provider, we pointed our localhost to “takeover.blog” and hosted a simple HTML page.
<!DOCTYPE html> <html> <head> <title>RedhuntLabs</title> </head> <body> <p>Deeplink PoC</p> </body> </html>
The exploit worked perfectly and was sufficient to prove the issue as further exploitation was not permitted by the client. The client made sure to remove all mentions of the domain from their code and configurations and thus mitigated the risk.
Let’s discuss some other attack vectors using which an attacker can exploit the domain takeover.
Exploitation Scenario 2: Accessing Sensitive Information and Email
E-mail is an essential asset of every organization and generally a primary source of internal and external communication. Emails are also used to register on third-party services like GitHub, Slack, Atlassian, etc. It can be easily identified using historic Mail Exchange(MX) Records which mail service was used by the organization.
An attacker can use Mail Exchange(MX) Records to register again on the email service used by the organization. Sometimes it is also possible to get the old email and documents from mail services. After gaining control over the domain, an attacker can modify the MX Records to catch all incoming emails. If any email address was associated with some internal or confidential email list, it gets delivered to the attacker. This can be further exploited by finding the email address associated with the domain using OSINT techniques and using those emails to reset the password of third-party services like LinkedIn, Github, etc.
Here is a link to one such case study: https://blog.gaborszathmari.me/hacking-law-firms-abandoned-domain-name-attack/
Exploitation Scenario 3: Phishing / Domain Abuse
Phishing not only affects the organization’s reputation but can also cause severe damage if an attacker gains control over the domain. Phishing can happen in many different ways.
- Phishing Using Email IDs: Attackers can use the emails to send phishing emails to the user or organization employees to gain access to the internal network. As the domain might have been used in the past for sending emails, it would have higher trust and reliability and a lesser chance of being detected as spam or phishing.
- Phishing using Social Media: Attackers can reset the password of social media accounts (if created using takeover domain email id) and launch a mass phishing campaign. Twitter crypto phishing is a pretty common example of this type of attack.
- Website Phishing: Attackers can use the domain to host a phishing page to spread malware or ask for money from users. To make the phishing attack more realistic, the attacker can find the old pages previously hosted on the vulnerable domain using services like the Wayback Machine.
Exploitation Scenario 4: Extracting Sensitive Information Using LOGS
Sometimes an application internally sends requests to allowlist domains, including sensitive information such as API keys, authentication tokens etc. After a successful domain takeover, an attacker can listen for such logs and may find sensitive information like authentication tokens, PII, and other sensitive data in web requests. These tokens can be used to login into accounts or perform sensitive actions.
Exploitation Scenario 5: Login using SSO
Single Sign-On is an authentication mechanism that allows users to login into services using one set of credentials. Generally, internal applications use SSO to login into services. Suppose an organization allows the vulnerable domain(takeover.blog) email IDs(email@example.com) to login into other domains or subdomains(internal.website.com). In that case, an attacker can register itself on the Identity provider and then simply login into internal panels because the service provider is (internal.website.com) trusts the identity provider, which in the below example is google.com.
There is no specific methodology to check for Domain Takeover, but here are a few places where a pentester must look to discover potential domains:
- Organization/Developers’ Github / Gitlab / Bitbucket public accounts
- URLs in the application (current/historic)
- Application Request/Response
- Application 3rd party Requests
Once you have a list of possible domains, search them for availability using bulk domain search tools such as https://www.namebright.com/BulkSearch.
A successful domain takeover impacts organizations financially, technically as well as their reputation. The best and easiest way to protect the organization from domain takeover is to set up monitoring for domain expiry and renew old domains even if they are not in use. Another complex method is to perform regular code/configuration review and change all the instances where the expired domain and its subdomain are used, and delete all the third-party accounts registered using the expired domain.