Menu
Domain hijacking and subdomain takeover are two closely related forms of attack that can be used to launch a variety of potentially devastating exploits against organisations. There are a variety of potential attack vectors and variants, and a similarly broad range of potential exploits available to attackers, all of which have seen documented instances “in the wild.” Unlike many other vulnerabilities, instances of domain hijacking or subdomain takeover can typically be attributed not to coding errors or infrastructure misconfigurations, but to simple failures in procedures or asset management practices. They can often be overlooked by organisations in securing their attack surface, since they are not caught by common security programme measures such as most commonly encountered technical controls.
In this blog post we outline the several types of domain takeover and hijacking that are possible, investigate their potential causes, the harm or damage that can result should they be exploited, and how they can best be both prevented from occurring, or else detected should the worst happen.
The internet relies upon a number of underlying protocols for communication. These operate at different layers of the network “stack”, with data being encoded and passed down from systems operating at one layer to the next, an abstraction that simplifies the development and implementation of individual services since the operation of underlying services that it relies on doesn’t need to be understood in great detail – data can simply be entrusted to lower network layers for transmission and routing. Network stacks are typically modelled conceptually as a 7-layer stack under the widely known OSI (“Open Systems Interconnection”) model, however the internet operates functionally on something more resembling a 5-layer model incorporating a protocol stack known as the Internet Protocol Suite. The underlying concept is that hardware or software systems functioning at a given layer only need to communicate with adjacent (vertical) layers to perform their dedicated function or task: software running in a higher layer does not have to know about or perform tasks delegated to lower layer functions and vice versa. The key layer used for host-to-host routing that underpins the operation of the internet is the Network Layer based upon the Internet Protocol (IP).
Whilst this system is technically solid, the numerical addresses used for internet routing – consisting of a quartet of dot-separated octets such as “192.27.14.224” under IPv4 (and even longer strings under newer versions of the IP protocol) do not lend themselves readily to human usage: they are incredibly hard to remember in any significant volume since for humans they are, essentially, lacking in context and meaning.
Humans prefer to work with memorable names, and since the earliest days of the internet and preceding ARPANET in the 1970s, efforts were therefore made to provide systems to deliver mapping between these memorable names (for humans) and the underlying IP addresses (for computers) to which they relate. Initial efforts at manually maintaining and updating directories of every hostname-to-IP-address mapping in a central repository swiftly became unmanageable as ARPANET developed into or was succeeded by the burgeoning internet.
The translation between addresses and domain names is now performed primarily by services based upon the Domain Name System (DNS). This effectively acts as a giant distributed directory of name to IP address mappings. The directory contents are termed the domain name space and exists as a distributed tree data structure in that it is hierarchical and split into cascading series of zones beginning with the root zone – an individual hostname consists of a dot-delimited chain of labels, in the form [hostname].[domain].[domain]….
Queries to perform lookups (such as resolving names to IP addresses and vice versa) are performed by clients against name servers that maintain the records for a specific zone. Since administrative responsibility for the maintenance of the “name to address” mappings within a zone are handed over at each level of the tree to a discrete party responsible for that zone, the system is distributed and no one central party is burdened with maintaining an unmanageable number of records. Each domain has at least one authoritative DNS server that publishes information about that domain and the name servers of any domains subordinate to it, and which can be queried by clients to perform directory lookups such as resolving a given name into an IP address. The top of the hierarchy is served by root name servers, the servers to query when looking up (resolving) a Top-Level Domain (TLD).
Modern web application deployments will typically operate a primary, canonical domain, such as www.example.com, and make use of various, secondary domains (such as “images.example.com”, “myaccount.example.com”, “cdn.example.com”, “en-gb.example.com”, “mail.example.com” and “api.example.com”) to host specific content broken down by criteria such as content type, region, language, or functional purpose.
Web applications, even those that are hosted in-house, will also often integrate external components from cloud-based service providers to add functionality or content to the application (such as Amazon AWS, Shopify, Heroku, WordPress, or Microsoft Azure). Each of these providers offer a method of integrating their services using a hostname that is consistent with a customer organisation. For example, rather than hosting a Shopify online shop at https://example.myshopify.com, Shopify permits the use of a DNS record to access the same resource at the more recognizable name, such as https://shop.example.com. This is achieved through the creation of a Canonical Name (CNAME) DNS record type. CNAME records are used to create an alias to another DNS record: in the case of cloud-service providers that means an alias in your domain pointing to a hostname at the provider.
For example, to host a Shopify shop at http://shop.example.com, the following CNAME record could be created within the example DNS Zone.
shop.example.com CNAME shops.myshopify.com
At the provider side, the resource is configured to recognise requests for “shop.example.com” and route to the correct online shop (the original hostname is submitted in the HTTP host header). This method of routing is often referred to as virtual hosting.
“Domain hijacking” and “Subdomain takeover” are two very tightly coupled vulnerabilities, the former referring to canonical domains, and the latter to subdomains. Both terms refer to a class of vulnerability that allows an attacker to hijack or assume ownership of an organisation’s domain or subdomain without their approval or consent. As we shall see, the methods for doing so do not necessarily consist of an “attack” and are not necessarily criminal or even unethical in some circumstances, which makes this a highly unusual type of vulnerability. Instead, many forms of domain or subdomain takeover consist of an attacker taking entirely legitimate action that takes advantage of failures of an organisation to effectively manage and administer its resources.
In order to understand this, it’s necessary to explain the domain registration system, under which domains are leased by organisations from a domain registrar. This means that organisations are essentially “temporary occupiers,” or tenants of a given domain. If we consider property rental as an analogy, we can see how there are many ways that a company could come to harm even though a property it rented had its lease lapse and be taken over by another party. That party could, for example, continue to use the former business’ logos on the building and pretend that there was continuity of operation, tricking customers into paying them for work done by the prior tenants, for example. Although this is clearly illegal, the actual lease transfer itself is not.
Although there are different forms of domain and subdomain takeover, and not all relate to domain registration directly, it is an important principle to bear in mind when considering several of the variant forms. It means that domain hijacking can be essentially an exploit in two parts: an initial “hijacking” of the domain (which despite the name, can be an entirely legitimate transfer); and then a secondary abuse of that ownership by the new “tenant” to perform an actual exploit.
Unusually, there is no specification classification or classifications for domain hijacking vulnerabilities under the CWE (Common Weakness Enumeration) scheme, so it is arguable if there are one, two, or more specific variants. As well shall see below, the takeover can be performed in a number of highly variant ways, each with differing outcomes.
A domain takeover vulnerability can arise in one of the following scenarios:
As we saw above, domains cannot be purchased in perpetuity by an organisation, but rather are leased to them for a given term under the domain registration scheme. Organisations also do not have any inherent right to lease a specific domain name, and so long as a reasonable argument to association with the domain name can be made, then domain names are often leased on a “first come, first served” basis. Domains can therefore potentially end up in the hands ultimately of whichever organisation with a claim to a domain has the deepest pockets, in order to negotiate a transfer of the domain from its original registrant.
For example, the domain “browns.com” could plausibly relate to any number of organisations, such as “Browns the Greengrocer,” “Browns of York Ltd,” or “Browns Fashion”: instead, it is, as of 2022, leased by and redirected to the primary site of the US-based professional American football team the “Cleveland Browns”, after 102 changes to registration going back over 19 years.
However, this system of domain registration relies on a process of domain registration renewal at the end of the lease term. It is possible for a domain referenced by an organisation’s systems and applications to expire and to – legitimately – be leased in turn by an unrelated individual or organisation.
We shall see later why this is potentially a major issue and how it can be exploited.
Domain registration hijacking is the act of changing the registration of a domain name without the permission of the original registrant, without the registration lapsing. For example, adversaries may gain access to an email account for the person listed as the owner of the domain. The adversary can then claim that they forgot their password and request that the registrar reset it: since the email originates as far as the registrar can tell from the legitimate owner, they may action this request. The attacker is then able to login to the domain registry and to amend the domain registration, such as transferring ownership to themselves. Other possibilities include social engineering a domain registration helpdesk function to gain access to an account.
Domain slamming (also known as unauthorized transfers or domain name registration scams) is a type of fraud or scam in which the offending domain name registrar attempts to trick domain owners into switching from their existing registrar to theirs, under the pretense that the customer is simply renewing their subscription to their current registrar. The term derives from telephone slamming. Whilst this can be done for potentially commercial reasons alone, it is also possible for it to be used in a more malicious manner to completely take over the domains of organisations once transferred.
Modern web application deployments, even those that are hosted in-house, will often integrate external components from cloud-based service providers to add functionality or content to the application such as AWS, Shopify, or Microsoft Azure. Each of these providers offer a method of integrating their services using a hostname that is consistent with your organisation. For example, rather than hosting a Shopify online shop at https://example.myshopify.com, Shopify permits the use of a DNS record to access the same resource at the more recognizable name such as https://shop.example.com. However, these DNS records pointing to cloud-based service providers can become orphaned if the service expires, is misconfigured, or deleted. If the configuration entry is deleted, then the alias will be deleted with it, but the DNS record may remain unchanged. When this happens, accessing the subdomain will often return a “holding page” hosted by the cloud-based service provider. This can be used by attackers as an indication that that subdomain is potentially available for registration. If left unchecked, an attacker could register the service and hijack the domain.
Second-order domain takeover refers to the takeover of a domain that is entirely outside of an organisation’s control, but on which resources are based that the organisation calls for inclusion in its web application. Examples of this type of resource might include elements of a code “supply chain,” hosting common functional libraries such as JavaScript or other resources that are available for open usage, such as “fonts.google.com.” Second-order takeover involves the malicious takeover of domains which are used by an organisation in a way similar to this and can have a significant impact. Because these domains can be referenced by potentially thousands of organisations, they can make incredibly attractive attack vectors for attackers.
One last attack vector that is worth mentioning is “typo-squatting.” Although not technically domain hijacking (since no hostile transfer of domain or subdomain ownership is involved) many of the same exploits can be conducted, and it is worth being aware of. If resources such as scripts or images are imported from an external domain, such as “static.example.com,” then an attacker might choose to (legitimately) register a very similar domain such as “static.examoke.com” which substitutes characters closely located on a physical keyboard that are frequently accidentally transposed when typed. If there are enough instances of a domain name being typed by developers, it’s entirely plausible that one or more instances of this typo may occur in a web application. Whereas normally a resource called from such a resource would simply fail to load when the HTTP request timed out, an attacker could (legitimately) register this domain, and configure it to return malicious JavaScript in response to any requests, which the victim website would faithfully retrieve.
Since domain names make use of DNS entries that ultimately resolve to IP addresses via “A” record types, then via misconfigurations or other errors it is possible for a domain to point to an IP address that is not owned and operated by the organisation. If the IP address is not currently assigned, then as with domain registration, an attacker could register it and use it to host malicious content.
Now that we have outlined the various forms of domain takeover and how they occur, it’s time to see how attackers can actually perform the domain takeover – and then what issues this can cause.
In order to takeover a domain, then as with any form of vulnerability, an attacker needs to analyse the attack surface and find gaps that can be exploited. In the case of domain takeover, this often involves trying to locate so-called “dangling DNS entries” – when a DNS record points to a resource that isn’t available. Most often this is in the form of a dangling CNAME record. Common types of records stored in a DNS authoritative server are Start of Authority (SOA), IP addresses, name servers (NS), pointers for reverse DNS lookups (PTR), and canonical name records (CNAME). A CNAME acts as an alias from one domain to another. If an organisation neglects to remove a CNAME entry from their authoritative DNS server after the associated service is decommissioned, it is described as being left “dangling”: an attacker who sees the expired domain can register it with a third party and now controls the domain.
In order to identify these dangling DNS entries, attackers will perform subdomain enumeration, a form of OSINT (“Open-Source Intelligence”) intelligence gathering during the early information gathering / reconnaissance phase of an attack. This can be done via querying DNS servers, especially if domain zone transfers are supported and unsecured.
It is also possible to enumerate domains quite often by examining an organisation’s SSL certificates. Because of features known as Server Name Indication (SNI) and the use of the “subjectAltName” field on SSL certificates, it is often possible to discover a list of multiple subdomains and identify any that are in a “dangling” state.
Much of this OSINT process is now possible via open-source toolsets freely available on sites such as GitHub that permit attackers to automate subdomain enumeration and other information gathering that enable domain hijacking to be automated at scale. Additionally, reports from “white hat” hackers and bug bounty hunters show that some run continuous scanning, and continuous checks of datasets to identify dangling DNS entries as soon as they become available within minute: it is a safe bet that malicious hackers have the same capabilities and practices.
As we shall see, domain hijacking and subdomain takeover can be leveraged by attackers to capture the authentication credentials of users, to deploy malware, and to capture sensitive information such as cookies that permit further attacks. The following is just a partial list of some of the most common issues that can arise once an attacker has managed to hijack a domain or subdomain via one of the methods outlined above:
Cookies are stored within a user’s browser as a data storage device and often contain sensitive information, including session tokens that are used to provide access to authenticated sessions on a server. Cookies are automatically appended to requests that a client’s browser sends to a website, but they have an in-built mechanism that limits which websites are provided with the data stored within a cookie. This means that each website can only access data that is within its permitted scope and is governed by the cookie’s “Domain” attribute.
For instance, if a cookie is set from example.com with that hostname as the value of its Domain attribute, browsers will attach it to all HTTP requests sent to example.com or any subdomain thereof. It is fairly common however to bind a session cookie to a wildcard domain such as *.example.com so that all subdomains are able to access the cookie. This is useful in instances where, for example, the subdomain auth.example.com is used during login, but then once logged in a client can access services on other subdomains, such as shop.example.com.
If an attacker has managed to take over *any* subdomain then they will be able to access all cookies set with a wildcard scope on the domain. By using a simple backend script on a malicious server set up to respond to requests to that subdomain, the attacker can retrieve the session cookie for any user of the site, compromising potentially thousands of user accounts for more popular websites.
If a subdomain that has been taken over was being used to call a JavaScript resource, then an attacker can substitute a malicious script of their own in its place at the same path. This malicious script will then be served to any requesting client and executed within the context of their browser.
As with account takeover via cookie harvesting, XSS (Cross-site scripting) can be used by attackers to retrieve the values of cookies such as session cookies too. However, XSS also offers attackers a broader range of exploit options, including keylogging (recording the user’s keystrokes) or even dynamically rewriting webpages that they request, injecting their own content instead.
If a subdomain or domain is hijacked, then it may be that the domain is being referenced for serving webpages, rather than JavaScript, as in the above example. In this instance, an attacker can hijack the content of a page and present their own content entirely. The exact form that this takes may depend on the motives of the attacker as well as their level of technical sophistication and organisation.
Relatively crude options may include simple defacement of the website and replacement with a political message if the attacker is politically motivated, or else replacement with a simple crude or offensive message if the attacker is simply motivated by causing disruption. This can lead to reputational harm for the organisation, such as negative press about the organisation’s inability to secure its estate, as well as the brand damage and loss of trust. For e-commerce websites in particular, customers may choose to close their accounts due to this failure, leading to direct loss of revenue, which may threaten business continuity and viability.
If a domain or subdomain is hijacked by an attacker but is no longer referenced or called by any other domain, an attacker has limited opportunity to perform many of the attacks above since they have no direct way of serving malicious content. Options do exist, such as “seeding” links to the hijacked domain or subdomain on what is known as “watering holes” – sources of web traffic such as forums.
However, attackers may also choose to use hijacked subdomains or domains to perform phishing campaigns. This is especially true if the domain or subdomain that is hijacked has an active MX (mail server) record. This enables the attacker to potentially receive emails addressed to the organisation, as well as sending emails that appear to originate from within the organisation’s network.
Domain or subdomain takeover can potentially involve the takeover of domains that are referenced within various DNS record types – some of which we covered above – such as “A,” “CNAME,” “MX,” “NS,” and “TXT” entries. The “NS” or “nameserver” record type is potentially the most serious of all if an attacker is able to hijack a domain with an associated DNS record of this type. A successful hijack of such a domain can result in full control over the entire DNS zone for the victim organisation’s domain. This allows an attacker to create, remove, and modify any and all other DNS records as they wish, meaning that they can potentially conduct every single attack variant seen above, as well as perform other exploits not previously covered such as simple blanket denial of service (DoS) by removing all associated DNS records for the organisation, crippling its entire technical infrastructure, and effectively knocking it offline indefinitely.
In some cases, DNS zone takeover has even occurred for top-level domains (i.e., “.com” or “.uk”). Although rare, hijacking the country-code top-level domain of a sovereign state can have serious and widespread negative implications, especially if the domain were to fall into the hands of a foreign adversary.
Maintaining an asset register of owned and operated resources isn’t a particularly sexy form of cybersecurity. However, maintaining an inventory of all domains owned as well as subdomains created, along with associated details such as registrars and renewal dates is and important pre-requisite for sane management of domains and prevention of issues such as domain expiry. It is important especially for organisations operating internationally or across multiple domain registrars.
Enabling two-factor authentication if available is a strong preventative measure that can be applied at several points of potential weakness: on administrative accounts on domain registrar administration portals where domains are managed; on access to key DNS servers; and on access to email accounts, especially those registered as primary administrative contacts for domain registrars. This helps to reduce the likelihood of an attacker managing to make malicious changes to domain registration or subdomain entries within DNS.
Many domain registrars now offer features that deliver a form of enhanced domain transfer protection: that is, extra restrictions that apply if an attempt is made to transfer the ownership of a domain. Often called “domain locking” or “registry locking,” this adds additional requirements that must be met before a domain can be transferred. The exact additional measures required will vary from one registrar to another but may involve additional identity verification such as proof of possession of a hardware token, “dual control” authorisation from multiple parties, or delays to requested transfers which are actioned only after a cool-off time that includes notification in writing to the organisation at their registered address.
Procedural hygiene can take many forms. Simply performing a periodic review of your organization’s DNS records and domain registrations in an ongoing cycle will ensure that any “dangling records” are detected and can be cleaned up. However, arguably more important in minimising the window of attack is to ensure that sounds procedures are following whenever discontinuing or terminating a service so that any domain registrations and DNS records are safely redacted, and in the correct sequence.
Some vendors offer specific forms of “external attack surface management” (EASM) tools to continuously scan and monitor domains to detect any exploitable changes to an organisation’s external attack surface. Vulnerability scanners such as AppCheck have built-in checks for subdomain takeover vulnerabilities that are performed as standard within standard vulnerability scans of an estate.
An additional preventive measure is to ensure that all application code goes through a code review process prior to being published. Reviewing application code for references to specific subdomains can allow the detection and update of incorrect or outdated subdomain references that could be exploited via either Typo-squatting or domain hijacking.
One final measure that is included only for completeness is the option of becoming a domain registrar yourself. Although financially feasible for only exceptionally large organisations that operate a large number of domains, it is possible to become ICANN accredited as a domain registrar. An organisation is then able to screen and filter any domain registration applications, and to restrict these to applications from internal sources only, for example.
Domain hijacking is a vulnerability that it is strongly advantageous to prevent from occurring rather than attempting to detect and correct after the event. Especially if a domain has legitimately lapsed and been legitimately acquired by another party, attempting to retrieve the domain can sometimes, depending on the registrar and circumstances, be extremely protracted.
However, if a domain has been hijacked then only two responses are possible to remediate the issue:
The first option is to simply remove the affected DNS record if the organisation still has NS (nameserver) control. This may or may not be feasible depending on the exact circumstance – it can be safely performed if the domain name or subdomain in question is no longer needed but is obviously problematic if the domain is still requiring to be actively used.
The last resort in the case of domain registration hijacking is to attempt to reclaim the domain name — this means registering the resource with the particular cloud provider in the case of a service provider domain or attempting to re-lease the expired domain via the domain registrar. In some cases, an organisation may not be able to simply re-register the domain to regain control over it immediately and may need to pursue legal action to obtain the court-ordered return of the domain, a potentially expensive and protracted process without guarantee of success.
AppCheck can help you with providing assurance in your entire organisation’s security footprint, by detecting vulnerabilities and enabling organizations to remediate them before attackers are able to exploit them. AppCheck performs comprehensive checks for a massive range of web application and infrastructure vulnerabilities – including subdomain takeover.
AppCheck analyses all hostnames encountered while crawling your web application to determine if a Domain Takeover attack is possible. When a vulnerable domain is identified, a detailed report is provided along with supporting evidence. In cases where no vulnerabilities are found, an audit report is provided to list each tested domain within a table. Where applicable, a domain aging report is also generated to show domains soon to expire along with domains recently registered (a possible compromise indicator).
For an example of the output, you can expect from this module, see sections 4.6 and 4.16 in this sample report:
https://appcheck-ng.com/wp-content/uploads/AppCheck_Sample_Report.pdf
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
