DNS attacks are any type of attack that involves the domain name system (DNS). There are many different ways that attackers can take advantage of weaknesses in the DNS. Most of these attacks are focused on abusing the DNS to stop internet users from being able to access certain websites. These fall under the wing of denial-of-service (DoS) attacks.
DNS weaknesses can also be leveraged to divert site visitors to malicious pages, in what is known as DNS hijacking. Attackers can also use the DNS protocol to sneak sensitive data out of organizations, like in DNS tunneling.
But we need to take a step back before we can go into depth on the wide range of DNS attacks. We’ll begin by laying the foundations, explaining what the DNS is and how it works, before moving on to individual discussions on each type of attack.
The domain name system (DNS) is a phone book
One of the most popular and simplest analogies for the DNS, is to think of it as a phone book. Perhaps it’s a little dated because phone books are mostly obsolete, but let’s get nostalgic for a moment (or ask your parents if you’re too young to have ever used one).
Why did people use phone books? Because they wanted to call a person whose name they knew, but whose number they didn’t. Knowing someone’s name, but not their number was such a common occurrence that we developed mighty tomes for everyone’s house to solve the problem.
But did you ever have a reverse phone book? You probably don’t remember knowing a person’s number but not their name, then rushing to a book of biblical proportions to figure it out, do you? Sure, there were those number lookup services, but most of us would have used them rarely, especially when compared to the regular phone book.
Did you ever wonder why it mostly happened in the one direction?
It’s not just that it would be weird if people started naming their babies 2982940293, it’s also much harder to remember a 10-digit phone number than a person’s first and last names.
Thankfully, phone books stepped up to the plate and solved the problem. They allowed us to use number systems without having to remember every single one. All we needed was our desired contact’s name, and we could look them up in the directory, type in the number, and then hopefully they would pick up.
The domain name system is much like our phone books. It acts as a directory, and saves us from having to remember a bunch of long numbers. However, instead of converting people’s names to their phone numbers, it converts domain names such as Comparitech.com, into IP addresses, like 209.58.135.68.
Domain names
Domain names are pretty simple. They’re essentially the alphanumeric string of characters that you type in to visit a website, like Comparitech.com or Wikipedia.org. These are registered through domain name registrars like GoDaddy or NameCheap. Most importantly, the string of words or letters we use in most domain names is far easier for people to remember than the corresponding IP addresses.
IP addresses
IP stands for Internet Protocol, which is the main protocol that we use for transferring data across networks over the internet. Your IP address is essentially your address on the Internet Protocol, and every internet-connected device has one.
You can think of them much like physical addresses. If you want a courier to pick up a package from your business and send it to another, both addresses are necessary so that the courier knows where to find it, and where to drop it off.
Similarly, when you visit a website like Comparitech.com, your computer’s browser needs to find Comparitech’s server through its IP address, 209.58.135.68. As part of the interaction, your computer’s IP address is also essential, so that our server knows where it’s sending the data. You can keep your IP address hidden from a site using VPNs, TOR, and other privacy tools, but those are out of the scope of our article.
Why do we use both domain names and IP addresses?
There are a couple of different reasons for this. If we only used IP addresses to visit websites, how many different ones do you think you could keep in your head? Probably about the same amount as phone numbers – not a lot.
Compare that to how many domain names you have kicking around in your skull? It could be in the hundreds or thousands. Even if you’ve never visited a website before and don’t know its address, there’s a good chance that you would be able to find it just by typing in the business or person’s name without spaces and a .com at the end. In many cases, you wouldn’t even need a tool like Google to help you get there.
You couldn’t do this if we only used IP addresses. Domain names are simply easier for people to deal with than IP addresses. Since machines use IP addresses rather than the various names people choose for their websites, we need some way that we can translate one into the other and vice-versa.
Another benefit of having both is that websites can either temporarily or permanently change their IP addresses without it affecting their visitors. If Comparitech changed its IP address, you wouldn’t even notice. Your browser would have to reach out to another address, but you would still type in Comparitech.com and end up at Comparitech.com, even if it’s technically at a new location.
DNS: How the internet’s phonebook works
The domain name system is a decentralized structure that we mainly use as a directory to translate between domain names and IP addresses. While it may seem dull and technical, it’s a core component of the internet, which would be severely constrained without it.
Let’s say you want to visit comparitech.com.
Under the domain name system, when you type a domain name into your browser, the first step is for your browser and operating system to look and see if they already know the IP address of the particular web page.
The IP address may already be cached from previous requests. This means that if you have already been through the process before, the IP address may have been stored to make things easier in the future. If the IP address is already cached, your browser can directly contact the website’s server to access the page.
If neither your browser nor your operating system already know the IP address for the domain, the stub resolver, which is a simple DNS resolver built-in to your operating system, asks another server known as the recursive resolver. This type of DNS server is often operated by ISPs. If the recursive resolver has the listing cached, it will send you the IP address, so that your browser can find the website.
If the recursive resolver doesn’t already have the IP address, then it goes to work for you and tries to find it. Its first step is to contact the root nameserver. The root nameserver doesn’t keep the IP addresses itself, but it does know where to redirect the query. It sends the recursive resolver the directions to the relevant top level domain (TLD) servers. This is based on the extension of the requested domain. This is the part at the end, such as .com, .org, .net, etc..
In the case of your search for comparitech.com, you would be sent to the TLD for .com domains. The .com TLD would then reply to your recursive resolver with the authoritative nameserver for the domain you are looking for.
Your recursive resolver then contacts the authoritative nameserver, and asks it for the IP address. Authoritative nameservers know the IP addresses within their groupings because they have access to the original data from the registry. This contains listings of domain names alongside their corresponding IP addresses.
The authoritative nameserver then sends the recursive resolver the relevant IP address, which stores it in its cache, delivers to the operating system, and then transfers it to the browser. It’s a convoluted process, but finally, your browser knows the IP address and can direct you to the website. Although the process may seem arduous, it all happens in the blink of an eye, and before you know it, you have the page you wanted in front of you.
One exception is if the authoritative nameserver replies with NXDOMAIN. This basically means that if the website exists, the authoritative nameserver has no clue how to find it. If you receive a NXDOMAIN response you won’t be able to access the website you are looking for. When you receive a NXDOMAIN response for a website you are certain is correct, it generally means that the site is either offline or having server problems.
How the domain name system retrieves IP addresses.
To summarize:
- Your browser checks if the IP address is already cached locally.
- If it isn’t, the stub resolver asks the DNS recursive resolver.
- If the recursive resolver doesn’t have the IP address stored, it queries the DNS root nameserver.
- The root nameserver then replies to the recursive resolver with which TLD nameserver it should contact.
- When the recursive resolver contacts the relevant TLD nameserver, it tells the recursive resolver which authoritative nameserver to contact.
- The recursive resolver contacts the authoritative nameserver, which looks up its records, then sends the corresponding IP address back to the recursive resolver. The recursive resolver finishes the process by forwarding it to your machine. Your browser can then use the IP address to connect to the website.
- If the authoritative nameserver doesn’t have the DNS record, it will respond to the recursive resolver with NXDOMAIN.
Of course, if the DNS records are found in the earlier steps, the website can be accessed without having to continue the whole way through the process.
Types of DNS attack
The DNS system is complicated, and attackers can take advantage of it in a range of different ways, with various end goals in mind. Many of these attacks aim to make websites, networks or machines unreachable, often by bombarding their systems with fake traffic, which prevents legitimate traffic from being able to access or use the targeted service.
In a general sense, these are known as denial-of-service (DoS) attacks, which are common in cybersecurity. The most common form of DoS attack is a distributed denial-of-service (DDoS) attack, which basically means that the attacker’s traffic isn’t coming from a single source. Instead, the target gets hit from thousands of different IP addresses, which are usually part of a botnet. This makes DDoS attacks much harder to defend against than DoS attacks.
This article will only discuss DoS and DDoS attacks that involve the domain name system, and not those that take advantage of other parts of the internet infrastructure. These domain name system DoS attacks include DNS flooding, along with its subtypes, NXDOMAIN attacks, random subdomain attacks, and phantom domain attacks.
Amplification attacks are also a type of denial-of-service attack, although they are different from those listed above because they use reflection to magnify the strength of the attack.
DNS rebinding allows cybercriminals to break into systems, while DNS tunneling lets them send data both in and out. In contrast, DNS hijacking focuses on changing DNS configurations to take users to unintended websites.
The lines between the different types of DNS attacks aren’t always clear, but we’ve tried to arrange them as neatly as possible to help you understand how they compare to each other.
DNS flooding
If a DNS server is inundated in a DDoS attack, any websites that use the server may experience interruptions to their traffic. Attackers often use botnets to target servers with huge volumes of DNS requests. When the servers are flooded by these malicious requests, it means that legitimate requests can’t get through.
The result?
If you try to visit a website and you don’t already have its IP address cached, your DNS request won’t be able to get through because of the competing requests. The attack’s overwhelming volume takes up all of the DNS server’s resources, so it won’t have the spare capacity to send you the IP address you are looking for.
If you can’t get the IP address, then your web browser doesn’t know where to go. It has no idea how to find the server that hosts the website you are trying to visit, so it can’t connect you. Even if the website is technically still online, you won’t be able to visit it if you don’t already have the IP address cached. This is true for everyone trying to access the website, which means that DNS floods can significantly reduce traffic to websites.
Not only can DDoS attacks overwhelm servers with their own fake traffic, but users that can’t connect to the website tend to continually refresh their pages. This results in an even greater volume of requests than normal, making the attack far worse.
Flooding attack against Dyn’s DNS servers
One of the best examples of an attack against DNS servers is the 2016 Dyn cyberattack. Dyn is an internet infrastructure company that provides a managed DNS platform. According to the company, on October 21, 2016, it came under attack just after 11am UTC. It suffered another one later in the afternoon.
Initially, the DDoS attack targeted Dyn’s managed DNS platform in the Western US, Asia Pacific, South American and Eastern European regions. As Dyn mounted its response, the attack pivoted and focused on the Eastern US, flooding large volumes of UDP and TCP packets to port 53 from a significant number of different IP addresses.
The second attack was more global in its focus, but the company was able to recover by the evening. There were also a number of smaller probing attacks over the next several days, but Dyn managed to mitigate them without affecting customers or users.
From an internet user’s perspective, the most significant effect of the attack was that it prevented some of them from being able to access websites. Those on the East coast of the US were more likely to have been affected. Impacted websites included Netflix, Spotify, Etsy, PayPal, Reddit, Twitter, GitHub, and many more.
It’s important to note that the sites themselves weren’t down, because their hosting services were unaffected by the attack. The issue was for site visitors who did not have the IP addresses cached. Because Dyn’s DNS servers were overwhelmed, these visitors were unable to complete their DNS lookups, so they weren’t sent the respective IP addresses.
As we discussed in the previous section, this attack also caused those who were trying to connect to continually refresh their pages, resulting in even more congestion from the repeated requests.
The attack was mounted by the Mirai botnet, which was a huge botnet mainly made up of poorly secured IoT devices like routers and cameras. This army of devices was commanded to make DNS requests in unison, overloading Dyn’s servers and making it difficult for legitimate traffic to get through.
DDoS flood attacks against root nameservers
It’s also possible for DDoS attacks to target the DNS root nameservers. Theoretically, if an attack has enough power and is sustained for a long enough period of time, it could affect the DNS all over the world, hampering internet users from resolving their requests and preventing them from accessing websites.
In reality, attacks of this magnitude are impractical, because the DNS is decentralized and resilient. Actual attacks against DNS root nameservers have had more specific focuses.
One example is the 2015 attacks carried out against several of the root nameservers. On the 30th of November and the 1st of January, several of the root nameservers received large volumes of traffic from a variety of sources, reaching up to five million queries per second at the peak of the attack.
On each day of the attack, a different domain name was inundated with the massive load of queries. These attacks targeted most, but not all of the DNS root nameservers. The queries originated from seemingly random IPv4 addresses, which are easily spoofed, making it difficult to determine the source of the attack.
While the attack involved unusually heavy loads, it did not have a significant impact on internet users. According to the statement from the Internet Assigned Numbers Authority (IANA), there were “no known reports of end-user visible error conditions during, and as a result of, this incident.”
IANA went on to state that as far as it was aware, the only impacts would have been some potentially minor delays in DNS lookups, which would have been “barely perceptible” to internet users. It attributed this to the “overall robustness” of the DNS root nameserver system.
In 2016, two VeriSign researchers presented a talk at a conference in Buenos Aires, detailing their investigation into the attack. They found that although the DNS root nameservers were impacted in the attack, they were not the main targets. Instead, the researchers asserted that the real targets were two Chinese IP addresses.
NXDOMAIN attack
A NXDOMAIN attack is a specific type of flood attack that involves a hacker sending a large quantity of invalid requests to a targeted DNS server. The server then queries the authoritative name server for IP addresses that don’t exist, expending the resources of both servers. If the attack is powerful enough, it can lead to both of them being overwhelmed.
This results in both servers being inundated by the invalid requests, hampering their response times for real requests, and potentially halting all of their DNS resolution services. In practical terms, it means that when internet users try to visit a website that uses the attacked DNS server, they will experience delays or be unable to reach it if they don’t already have the IP address cached.
NXDOMAIN attacks can be difficult for DNS server administrators to detect, because they may presume that the system is suffering performance issues, instead of being inundated by the countless invalid requests of a NXDOMAIN attack.
In April 2023, the US Government’s Health Sector Cybersecurity Coordination Center (HC3) issued an alert detailing a significant number of NXDOMAIN attacks targeting the healthcare sector.
The attacks consisted of a “large amount of DNS queries for non-existent hostnames under legitimate domains.” Rather than respond by blocking IP addresses, which could prevent legitimate users from accessing public services, HC3 suggested several other mitigation responses. These included lowering the timeout for recursive name lookup to free up resources in the DNS resolver, and implementing DNS Response Rate Limiting.
Random subdomain attack
A random subdomain attack is somewhat similar to a NXDOMAIN attack. However, instead of querying for an invalid or nonexistent domain, they involve making requests for subdomains that don’t exist.
To illustrate the point, let’s say that the root domain example.com is real, and the organization behind it operates a forum, a support center and a career section on the website. Each of these are located at their own subdomains, forum.example.com, support.example.com, and career.example.com, respectively.
If you wanted to launch a random subdomain attack against example.com, you wouldn’t send DNS requests for forum.example.com or any of the other existing subdomains. Instead, you would generate a string of random characters as invalid subdomains, and make requests for those.
These invalid subdomains might look something like this:
n78tofoahdk.example.com
94nfajfo8.example.com
a4nkasof874.example.com
When you make requests for invalid subdomains, the recursive server expends its time and resources repeatedly querying the authoritative nameserver for subdomains that don’t exist, before returning failure messages.
This puts additional stress on both the recursive server and the authoritative name server. If you launch the attack with a large botnet, with each slave (a member of the botnet) making just a few of these requests, it can take up a tremendous amount of resources, preventing legitimate requests from getting through.
Just like in NXDOMAIN attacks, when people try to access example.com without already having the IP address cached, they will either be delayed or prevented from reaching the site. This is because the DNS server is so overwhelmed by the requests for invalid subdomains from all of the slaves.
Random subdomain attacks can be difficult to detect. When they originate from botnets of devices that have been taken over by cybercriminals, it’s hard to discern which queries are actually legitimate.
A good example of a possible random subdomain attack was published by the FBI in February 2020. Bleeping Computer reported seeing an FBI document that indicated that the DNS server for a voter registration website had received high volumes of DNS requests that were consistent with a random subdomain attack.
Over the course of a month, the DNS server experienced a number of spikes, peaking at more than 200,000 requests across time periods that normally received about 15,000 requests. These requests were mostly for subdomains that didn’t exist, and were originating from IP addresses that belonged to recursive DNS servers. This obfuscated the attacker’s origin. It’s not publicly known whether the FBI was able to further track down the attacker in its investigations.
Phantom domain attack
Under a phantom domain attack, a hacker first sets up a series of domains that are configured to either not respond, or to respond extremely slowly to DNS requests. The attacker then sends large volumes of requests for these domains to their targeted DNS recursive resolver. The server continually queries these phantom domains waiting for a response.
Once again, this eats up the recursive server’s resources, and can either slow it down significantly or cause it to fail, preventing internet users from making legitimate DNS requests to the server. Ultimately, this can prevent them from being able to access the site they are trying to visit.
DNS amplification attacks
DNS amplification attacks are a little bit of a departure from those that we have already covered. Each of the techniques we discussed above involve finding ways to overload the DNS servers that websites use, in turn, either preventing access or making it more difficult for people to reach the affected websites.
While DNS amplification attacks aim to crash or slow down services, they don’t do so by attempting to overload the DNS servers. Instead, they use the DNS servers as weapons.
DNS amplification attacks are a specific type of reflection attack. DNS reflection attacks involve cybercriminals making requests to DNS servers for IP addresses. However, they do this without using their own addresses – they forge the request and insert the target’s details instead.
When an attacker makes requests with a spoofed address, the DNS servers receive the queries, then send out the responses to the forged address of the target. If the attacker creates large volumes of these requests, the huge number of responses sent to the target can slow down or overwhelm it.
The server for the targeted website becomes inundated with the responses for queries that it never even made, draining its resources and potentially causing it to be unavailable.
Under normal circumstances, an attack of this nature would require an extremely large volume of spoofed requests to overwhelm the victim with responses from DNS servers. But what if the hacker could set up the attack so that each request instigated a much larger response in return? This kind of magnification would make it far easier to max out the target’s resources and crash it.
This is the essential concept behind DNS amplification attacks – maximizing efficiency by finding a way to send relatively small requests that will end up returning extremely large responses from DNS servers.
A good example of an extremely efficient amplification attack is the DDoS attack using Memcached servers over UDP, first written about by Cloudflare in 2018. Note that this attack did not use the DNS protocol, but it’s still a good example of how the principles behind amplification can make attacks far more powerful.
According to Nexusguard’s DDoS Statistical Report for 2022, amplification attacks grew by more than 414% compared with the previous year.
DDoS attack using Memcached servers over UDP
Let’s start by unpacking the acronyms and jargon in the title so that we are all on the same page. First, we have DDoS, which we have already mentioned is short for distributed denial-of-service attack.
Memcached is open source software that’s used to speed up certain websites by caching some data. It’s been used by Wikipedia, Google Cloud, Facebook, and a bunch of other websites, so it’s a pretty important component of how we interact with the internet.
UDP is the User Datagram Protocol, which is one of the foundations of the internet protocol suite, allowing computer applications to send messages (known as datagrams) over the internet in a standardized format.
When Memcached servers are misconfigured, attackers can leverage them in amplification attacks over UDP. As highlighted in the Cloudflare article, a request to a Memcached server of just 15 bytes can lead to a response of 750 kilobytes, which amounts to amplification of 51,000 percent.
By mounting an amplification attack using this technique, it becomes far easier for hackers to overwhelm their targets. All they have to do is make a series of small requests from the slaves on their botnet, and the target is quickly inundated, preventing legitimate access to the website.
Amplification attacks are usually difficult to defend against because the responses come from legitimate servers. The good news is that version 1.5.6 of Memcached — and all subsequent versions — helped to mitigate this specific type of amplification attack, by disabling UDP by default. However, out-of-date versions of Memcached, as well as a range of other services, can still be used to mount amplification attacks.
DNS rebinding
DNS rebinding is an attack technique that involves abusing the DNS to break into a private network. It’s a sneaky maneuver that allows cybercriminals to circumvent the same-origin policy.
In essence, the same-origin policy is a concept in web application security where one webpage can only access data from a second page if they both have the same origin – they both come from the same host name, port number and identifying number.
The same-origin policy is critical for our online security. Without it, you could be logged into your bank account in one tab and browsing an insecure site on another. If the insecure site hosted malicious JavaScript, it could request data from your banking tab, access your account and even transfer all of your money to a foreign bank.
Thankfully, the same-origin policy stops this from happening, because your bank and the insecure site have different origins.
We’ll use an example to explain how DNS rebinding can be used to get around the same-origin policy. Let’s say that you are feeling sinister, and want to access an organization’s private network to steal data or use its resources to send spam.
Your first step in a DNS rebinding attack would be to register a domain, such as DNSrebindingexample.com. You would then need to connect the domain to a DNS server that is also under your control.
On this DNS server, you would have it configured for an extremely short time to live (TTL). With regards to the DNS, a TTL is the length of time that a DNS record can be cached for.
If you configure your DNS server’s TTL to 10 or so seconds, you effectively prevent DNS records from being cached. This means that anyone trying to visit the domain will have to contact the server each time.
The next step is to lure the victim to the domain. There are a bunch of ways to do this, but if you are targeting a specific organization, let’s say you spam each of its staff members with phishing emails that contain the URL, under the pretext that it’s the website for a potential new client.
Let’s presume that the organization has bad cybersecurity training practices, and at least one employee falls for the message and clicks on the link. As their web browser tries to reach your website, it first contacts your DNS server. The DNS server responds to the victim with DNSrebindingexample.com, IP address, which we will say is 1.2.3.4.
The victim connects to your website, which hosts malicious JavaScript that automatically runs as a drive-by download. The script will execute a payload on the victim’s private network, which will then search around for insecure devices that have not had their default passwords changed. Let’s say you find a router with an IP address of 4.4.4.4 behind the organization’s firewall.
When the target’s browser tries to reconnect to your website, the short TTL means that it has to contact your DNS server again. However, instead of sending your site’s IP address of 1.2.3.4, this time you configure your DNS server to respond with the router’s IP address of 4.4.4.4.
This allows you to get around the browser’s same origin policy, because both 1.2.3.4 and 4.4.4.4 appear to have the same origin, DNSrebindingexample.com. You can then easily access the router behind the organization’s firewall, because the browser sees no reason to block access that appears to come from the same location.
From this point, you can penetrate further into the network to steal data, or launch a number of other attacks.
In 2017 a security researcher from Google discovered a vulnerability in the Blizzard Update Agent that put all of its users at risk. Attackers could take advantage of it to install malware, and the Update Agent would presume that the files were simply updates for games.
The Update Agent created a JSON RPC server with an endpoint that didn’t require authorization, but other requests needed to have a valid authorization header alongside the token. Blizzard’s Update Agent was set up in such a way that it allowed websites to send requests to the daemon with XMLHttpRequest(). It was vulnerable to DNS rebinding because websites can easily create DNS names that they are authorized to connect with, then make them resolve to the local host.
The result of Blizzard’s Update Agent setup was that any website could feasibly send privileged commands to it, allowing hackers to escalate their attacks. Despite some miscommunication with the bug’s discoverer, the issue was finally patched at the beginning of 2018.
In 2021, researchers discovered a critical vulnerability that left approximately six million Sky Broadband customer routers at risk of a DNS rebinding attack. The flaw, which wasn’t fixed for more than 17 months, could be exploited to allow attackers to change the router’s configuration and enable remote management.
DNS hijacking
Attackers can also take advantage of the DNS system to send victims to fake websites, using a technique called DNS hijacking. It’s an umbrella term that’s also known as DNS redirection, while methods that focus on an attacker changing the DNS response are known as DNS spoofing. Attacks that fill the DNS resolver’s cache with fake IP address records are known as cache poisoning.
Under DNS hijacking, attackers divert their victims away from the popular websites that they usually visit, using DNS-related tricks to bring them to fraudulent sites. These fake websites are often designed to look like the legitimate site, and aim to fool their victims into typing in their login credentials or credit card details. Hackers then use this information to access their accounts or commit fraud and other crimes.
Alternatively, cybercriminals can also use DNS hijacking to send victims to websites that host malware. This could include ransomware, spyware, adware, Trojans and a range of other malicious programs. Ultimately, the hackers use this malware to get whatever it is they want out of the victim, whether it is information, access or money.
Attackers also take advantage of DNS hijacking to reroute victims to websites they control so that they can make money from ad revenue. In what’s known as pharming, instead of ending up at their intended website, victims are redirected to a site controlled by the attacker that’s heavily laden with ads. The attacker then makes money based on views or clicks.
ISPs, DNS service providers and national censorship infrastructure like the Great Firewall of China use DNS hijacking for displaying ads, collecting data and blocking access to certain websites. This is a controversial practice in the security community, because not only are people directed away from their intended websites, but it can also leave them vulnerable to cross-site scripting (XSS) attacks and hamper the functionality of various systems, exposing them to further security issues.
In many situations, ISPs use DNS hijacking for their own business purposes, however they are sometimes ordered to redirect visitors from certain sites by court order. A good example of this is when the Dutch courts ordered ISPs to block the torrenting site, The Pirate Bay. This ruling was subsequently overturned at the court of appeals in The Hague, which described the technique as “ineffective.”
Different types of DNS hijacking
DNS hijacking uses several different techniques to divert an internet user from their intended website to a malicious page:
- Local hijacking – This type of DNS hijacking involves an attacker installing malware on a target’s computer, then changing the local DNS settings to reroute them to a malicious site instead of the intended webpage.
- Router hijacking – Many routers have firmware vulnerabilities or still use their default passwords. Attackers can take advantage of these security weaknesses to access and reconfigure the router’s DNS settings. If they change the DNS settings for certain sites to those of a malicious site, anyone connecting through the router will be diverted to the malicious site when they try to access the websites that had their DNS details altered.
- Compromised server – Hackers can compromise DNS servers and alter their configurations so that the IP addresses of targeted websites actually point to sites under the control of the attackers. Any internet user whose machine makes a DNS request to one of the targeted websites on the compromised server will be redirected to the malicious website, where they might encounter malware, phishing or pharming.
- Man-in-the-middle DNS hijacking – In a man-in-the-middle attack, cybercriminals insert themselves into a communication channel and either listen in or alter the messages. The process is similar in DNS hijacking, with the attacker intercepting the messages sent between a DNS server and a user. The attacker alters the DNS server’s response to the IP address of their malicious website, sending the user to the malicious site.
A good example of local DNS hijacking was discovered by Bitdefender researchers in March 2020. The attack involved targeting routers and reconfiguring their DNS settings, which would send victims to malware-laden sites instead of the pages they intended to visit.
The attack mainly seemed to target various Linksys router models. While the researchers aren’t 100 percent sure of how the routers were being compromised, they presumed it was through brute-forcing Linksys cloud accounts or by finding online access to the routers’ management consoles.
Once the hackers had access, they would change the DNS settings so that victims trying to access sites like disney.com or aws.amazon.com would be diverted to pages that were under the control of the cybercriminals.
Upon arrival at the page, victims were greeted by a popup with a fake message from the World Health Organization, telling them to download and install an app that contained information on COVID-19.
Of course, those that fell for the trap really ended up downloading a malicious .exe file from a Bitbucket repository, which set off a chain of events, leading to the installation of the Oski infostealer. This malware could then steal a wide variety of sensitive data from its victims, including cryptocurrency passwords and login credentials.
DNS Tunneling
DNS tunneling is an attack technique that leverages the DNS protocol to transport encoded data. Hackers frequently use it to exfiltrate sensitive information from targeted organizations. They can also take advantage of DNS tunneling to contact a command and control server from within the targeted network, then download further malware inside the organization’s firewall.
The DNS protocol is an essential and seemingly benign component of the internet. Many organizations don’t monitor it carefully, which leaves an opening for cybercriminals. Sure, there are many other protocols that are better suited for transporting data, but these tend to be closely guarded. DNS tunneling gives attackers an opportunity to get around firewalls and detection methods.
Before hackers can use DNS tunneling to steal data from within an organization’s network, they first need access within the organization’s network. This is often achieved with phishing or another form of malware delivery.
Attackers also need to have a DNS server outside of the targeted network under their control, as well as a website with DNS records that are accessed via this DNS server. Once everything is set up, the next step is to exfiltrate sensitive data through the DNS tunnel.
The hackers install a local DNS tunneling client within the target organization’s network, then use it to encode the sensitive information as DNS queries for the attacker-controlled website. These queries are sent to the DNS server that is under the attacker’s control, under the guise that someone from within the organization is actually trying to access the attacker’s website.
Because the DNS protocol often isn’t scrutinized closely, this technique allows the encoded data to be exfiltrated without being detected. Unless the target organization carefully monitors the DNS protocol, the hacker can slip out the sensitive data as what appears to just be harmless DNS queries. Throughout the process, the attacker’s DNS server sends back replies to make the requests look legitimate.
Once the DNS queries are outside of the targeted network and into the attacker’s hands, they are decoded back into their original form, as the sensitive information. From this point, the attacker can sell the information, use it for fraud, or commit a range of other crimes.
OilRig’s DNS tunneling
A great example of DNS tunneling was analyzed by the security team, Unit 42. As part of its investigations into the actions of the OilRig threat group, Unit 42 discovered a custom Trojan known as ALMA Communicator.
Once the ALMA Communicator was installed on the target’s system, it would communicate back to the command and control center and exfiltrate data through DNS tunneling. However, it could only exfiltrate a limited amount of data, with each DNS request only capable of 10 bytes. Large files would require a significant number of requests, increasing the likelihood of detection.
Preventing DNS attacks
Due to the wide range of DNS attacks, a number of different approaches are necessary for protection, some of which are out of control of the individual or organization. As an example, if your website used Dyn’s DNS servers during the 2016 attacks mentioned above, there isn’t much you could have done to make your site available for those who needed its IP address, unless you had a backup DNS server.
However, there are still many things that your organization can do:
- Conduct a DNS audit – Over time, it’s easy to forget about old subdomains or test domains under your control. Some of these may be running outdated software, or can easily be accessed by attackers. Auditing your DNS zones will give you the insight you need to discover DNS-related vulnerabilities, helping you understand what needs to be addressed.
- Use a dedicated DNS server – It’s tempting for smaller companies to host their DNS server alongside their application servers. However, this increases the risks of web application attacks. That’s why it’s best to run DNS services on an isolated server.
- Limit zone transfers – DNS zone transfers are copies of the DNS zone. If your DNS zone transfer falls into an attacker’s hands, it can give them a better understanding of your network’s structure. You can prevent attackers from performing zone transfers by going into the configuration file of your DNS software and restricting zone transfers to specific IP addresses.
- Turn off DNS recursion – If your server is configured to allow DNS recursion, it means that hosts from third parties can query the nameservers. This makes it easier for cybercriminals to perform cache poisoning attacks and DNS amplification attacks. DNS recursion can be disabled by altering the named.conf file.
- Update your DNS servers – Cybercriminals love taking advantage of vulnerabilities in old software, so running patches as soon as possible is essential. This applies across the board, including for those who run their own nameservers. The latest versions of software like Microsoft DNS and BIND support security specifications like DNSSEC, which provides authentication and data integrity measures.
- Use a DDoS mitigation service – If your DNS servers are targeted in a large DDoS attack, it can make the services unreachable, causing business disruptions. It’s best to use a DNS mitigation provider like Cloudflare or Akamai, whose resources can help keep your DNS servers online.
Because of the wide variety of DNS attacks, it’s not feasible to discuss every important defense mechanism in the detail they deserve. Each organization has its own infrastructure, software and needs, so it’s hard to give sound advice to suit every situation.
The important thing to understand is how the DNS protocol works, and how it can be abused in an array of different ways. Organizations will only be able to protect themselves if they understand the risks they face, and take a proactive approach to their defense. Otherwise, they may face the serious consequences of business disruption, data theft or worse.