To make it easier to understand, let’s imagine the internet as a vast network of interconnected buildings. Each building represents a website, and these websites each have various rooms. These individual rooms are the “subdomains”. For instance, consider a website as a skyscraper, and one of its subdomains as a particular room within that skyscraper.
Imagine your company leases offices in a towering skyscraper. Each office within represents a subdomain, akin to a meeting room. Picture the third floor, where you find meeting rooms named after cities worldwide—say, “Tel Aviv,” “London,” and “Tokyo.”
This year, the Chief Operating Officer has decided that the “London” meeting room is no longer needed, and instead, they’d like to allocate the funds for more enjoyable activities.
However, the COO overlooks the crucial step of formally terminating the lease for the “London” conference room. They forget to inform the office manager, and everyone within the company continues to believe that the “London” meeting room is still company property.
All signs within the building still point to the “London” meeting room, the calendar system continues to offer it for meetings, and everyone remains under the impression that it’s a legitimate part of the company’s assets.
Now, picture some threat actors who become aware that the “London” room is available for rent. They decided to legally lease it, exploiting the fact that your company’s employees still believe it belongs to your organization. Once these bad guys gain control of the “London” room, they have a multitude of possibilities at their fingertips.
These threat actors can now use the “London” meeting room as a base for deceptive activities, such as organizing fake meetings, conducting unauthorized discussions, or even eavesdropping on sensitive conversations. Since everyone still thinks it’s a legitimate company space, they can manipulate your employees and visitors into divulging confidential information without them knowing they entered a trap.
Just as the threat actor in the example above can utilize the company’s meeting room, the same principle applies to hijackable subdomains within the company’s domain. In practical terms, the “London” meeting room is a subdomain that the threat actor effortlessly takes control of, resembling the analogy. This deceptive maneuver leads users to believe they are accessing the legitimate company website when, in fact, they are entering a territory now under the threat actor’s ownership.
So How Does Subdomain Hijacking Actually Work?
Domain Hijacking represents a widely recognized security threat that can be executed through various methods. Apart from tactics involving social engineering or unauthorized access to the domain owner’s account, there is the method of misconfigured DNS records configured for SAAS services.
Subdomain hijacking, also known as dangling DNS, occurs when a threat actor gains control of a subdomain of a legitimate domain. This can be done by exploiting misconfigured DNS records, taking over unused or abandoned subdomains, mostly for cloud services.
DNS records are what tell browsers where to go to find a website. If a DNS record is misconfigured, it can point a subdomain to the threat actor’s website instead of the legitimate website.
Hijackable subdomains arise when an organization cease using a cloud service and fails to remove or update the DNS records directing to them. Additionally, organizations might overlook the need to renew domain names, making them available for purchase by anyone.
These abandoned domains and subdomains expose organizations to potential risks of hijacking and takeover attacks, meaning that anyone could assert ownership over the deserted domain within that cloud service.
Threat actors often identify unused or abandoned subdomains by using specialized tools to enumerate subdomains that are not actively in use. These tools and techniques are explored further in this report.
Exploiting this attack vector is relatively simple, as it only requires claiming a subdomain on a cloud provider or registering an expired domain for only few dollars, and sometimes can even be free. It is also stealthy, as there are no notifications sent to the original domain owner regarding the new configuration or purchase.
What is a CNAME record?
A CNAME (Canonical Name) record is a type of DNS record used to create aliases for subdomains. They allow one subdomain to point to another subdomain’s address, often used for load balancing or making subdomains easier to manage.
For example, the following CNAME record would map the alias domain `blog.example.com` to the canonical domain `example.com`:
`blog.example.com CNAME example.com`
CNAME records can be used for a variety of purposes, such as:
- Mapping a subdomain to a main domain: For example, a company might use a CNAME record to map the subdomain `www.example.com` to the main domain `example.com`. This means that when a user visit `www.example.com`, their browser will be redirected to `example.com`.
- Mapping a domain to a subdomain: For example, a company might use a CNAME record to map the domain `example.net` to the subdomain `example.com.blog`. This means that when a user visits `example.net`, their browser will be redirected to `example.com.blog`.
- Mapping a domain to a third-party service: For example, a company might use a CNAME record to map the domain `example.org` to the third-party service `mail.google.com`. This means that when a user visit `example.org`, their browser will be redirected to `mail.google.com`.
How Can Threat Actors Exploit CNAME Records in Subdomain Hijacking?
Subdomains are vulnerable to hijacking when a specific subdomain, such as “subdomain.example.com,” was initially configured to link to a specific online service like Amazon Web Services (AWS), GitHub, or similar platforms, but subsequently, this service is either intentionally removed or deleted by the user or owner. This situation creates an exploitable opening that threat actors can leverage to gain control over that subdomain.
Let’s make it easier to understand with an example:
Imagine your company needs to link one of its domains, let’s say “example.company.com,” to an Amazon S3 AWS cloud bucket to host its content. To make this connection, your IT team creates a DNS CNAME record for the chosen subdomain that points to the S3 cloud bucket:
This setup allows visitors to access content hosted in the S3 bucket via the subdomain.
Now, here’s where the security issue comes in. At some point, your company decides to stop using this specific S3 cloud bucket and deletes it. The subdomain “example-bucket.s3.amazonaws.com” is no longer claimed by the company, but the DNS record still points to it:
Here’s where the threat actor comes into play. They notice that the company didn’t remove the CNAME record linking to the S3 AWS cloud service. The threat actor legally registers the same S3 bucket on the cloud service website, and practically claims ownership of the subdomain. What simplifies and makes this attack effortless is the ease of creating S3 buckets. The threat actor doesn’t have to exert much effort; they can simply create the bucket on the AWS website, for free. In many cases, this convenience extends to other SAAS or cloud services, where it might cost only a few dollars or even be entirely free.
With the CNAME record already in place, the connection is automatically approved. The threat actor now has control over the content hosted in the S3 bucket under the company’s subdomain.
When customers or visitors navigate to the company subdomain page, example.company.com, they will see the attacker’s content. This puts them at risk of encountering various attacks or being exposed to potentially harmful content.
How Do Threat Actors Find Subdomains Vulnerable to Hijacking?
In reality, this process is far more accessible than one might imagine. Subdomain hijacking is a relatively easy attack to carry out, even for someone with limited technical skills. There are many tools, penetration kits, and tutorials available on both the dark web and the open web that can guide anyone through the process step-by-step. This means that even a child with the right (or wrong) intentions could potentially launch a subdomain hijacking attack.
What’s even more concerning is that the risk isn’t limited to cases where threat actors specifically target your organization. Today, there are automated tools capable of scanning the entire internet to identify vulnerable subdomains. This means that the risk is more widespread, and your organization, even if it’s not the primary target, could be vulnerable to significant risks from such an attack.
To demonstrate how easy it is to find tools that can help threat actors find subdomains that are vulnerable to hijacking, here are a few examples of easily accessible resources:
GitHub Tutorials
There are many detailed tutorials on GitHub that explain how to find and hijack subdomains. These tutorials often include real-world examples of successful attacks, as well as step-by-step instructions and lists of the tools and code used.
Free online tools
A quick Google search or a browse through dark web forums or Telegram channels will reveal a variety of free tools that can help you identify subdomains that are vulnerable to hijacking.
Some of the tools threat actors use to discover subdomains include: Subfinder, Sublist3r, DNSdumpster, Subjack, Subjack, TKO-Sub.
Threat actors can also use web application scanners to find vulnerabilities in web applications that could be exploited to hijack subdomains. Some popular web application scanners include Nmap, Nessus and Acunetix.
Impact of Subdomain Hijacking Attacks
Subdomain hijack attacks have wide-ranging and severe impacts that extend beyond security aspects. When successfully executed, these attacks can lead to a range of harmful consequences, including:
- Reputation Damage: A subdomain hijack can damage an organization’s reputation, eroding the trust of its customers, partners, and stakeholders. When attackers misuse a subdomain to host malicious content or engage in illegal activities, the affected organization may be wrongly associated with these actions, leading to reputational harm that can be difficult to repair.
- Financial Losses: Subdomain hijacking can result in direct financial losses. For example, if threat actors redirect e-commerce subdomains to counterfeit websites, it can lead to fraudulent transactions and revenue loss. Additionally, organizations may incur costs related to incident response, legal actions, and regulatory fines.
- Phishing and Fraud: Hijacked subdomains are often used for phishing attacks. Attackers create deceptive websites that mimic legitimate organizations, tricking users into divulging sensitive information such as login credentials, credit card details, or personal data. These phishing attacks can lead to identity theft, financial fraud, and compromised accounts.
- Malware Distribution: Subdomain hijacking provides attackers with a platform to distribute malware. Malicious software delivered through compromised subdomains can infect users’ devices, leading to data theft, system compromise, or unauthorized access. Malware can also be used for further cybercriminal activities.
- Operational Disruption: Subdomain hijacking can disrupt an organization’s operations. For instance, if attackers compromise subdomains responsible for critical services or communication, it can lead to operational disruptions, delays, and increased downtime.
How To Prevent Subdomain Hijacking
Subdomain hijacking underscores the critical importance of vigilant management of DNS configurations and services to prevent unauthorized control and misuse of subdomains after the removal or deletion of their associated services, even on cloud platforms like AWS.
To prevent hijackable subdomains, Cyberint recommends the following:
- Regularly check your DNS records. This means checking your DNS records for any unauthorized changes, or unused or abandoned subdomains. You can do this by manually reviewing your DNS records or using a DNS monitoring tool.
The Cyberint Argos platform continuously monitors our clients’ subdomains that could be vulnerable to hijacking. If the system detects a potential risk to one of the client’s company’s subdomains, it immediately notifies the client and recommends mitigation. Furthermore, the system can identify domains and subdomains that belong to the client, which may not even be on the client’s radar, perhaps because they are outdated or undocumented. The system then alerts the client to any issues that arise concerning these domains.
