DNS Attack

DNS is truly the unsung hero of the internet: Without it, we would be lost in a numeric soup of IP addresses. And when something goes wrong in the network, what do we blame first? That’s right: DNS. 

So, if DNS is so important, why does no one ever discuss securing it? 

DNS attacks are malicious campaigns directed at DNS weaknesses with the intent of capturing data or causing disruption to internal and external resources. Some important categories of DNS attacks include DNS poisoning, DNS tunneling, DNS floods, and DNS hijacking.

This article will examine some of the more common ways that your DNS system may be in danger, how to lock it down, and how to identify and mitigate issues while securing DNS from attack.

Summary of DNS attacks

The following is a summary of the most important DNS attacks.

The impact of a DNS attack

A DNS attack will impact the entire company structure, typically affecting most users and resources, if not all. The image below shows the extent of the impact reported by 1,080 companies surveyed for the IDC 2022 Global DNS Threat Report. DNS attacks can lead to private company data being exposed as well as information relating to customers, employees, and third-party vendors. A DNS attack can literally destroy a business from the inside out.

‍

Types of DNS attacks

DNS attacks come in several forms, usually as a combination attack where DNS is affected alongside other services. Here are some common attacks and significant examples.

DNS cache poisoning

DNS cache poisoning occurs when a threat actor successfully corrupts the records that are kept in cache on a DNS Server. This can be done through various methods, including man-in-the-middle (MITM) attacks, spoofing IP addresses to look like another DNS server, and direct manipulation of records inside a DNS server. The diagram below shows a framework for such an attack.

This is an example of a possible internal DNS attack. First, the threat actor (TA) will initiate a man-in-the-middle attack (MITM), which involves the TA placing a device they own or control between two other devices in a network that are having a conversation. Next, the TA will attempt to poison the ARP cache of any devices looking for the MAC address that belongs to the DNS / DHCP / default gateway router or server. The TA’s device responds to the ARP requests with its MAC address, impersonating the router/server, and starts serving DHCP requests. Inside the DHCP requests is the IP of the TA’s DNS server. This server then begins handing out falsified DNS records. 

DNS tunneling

In the example above, the attacker has managed to poison DNS, but how can this be exploited?

The attacker will start with a web server, somewhere out on the Internet, that they own. Traffic will be redirected from the intended target IP to their web server IP via the poisoned DNS server, and malware will be installed on the host. Once the malware is installed, data can be extracted from the corrupted host. This moving of data from the corrupted machine out of the network by hiding data in DNS traffic is called DNS tunneling.

One potential issue with tunneling is that most corporate and small business environments normally have a firewall. Luckily for our attacker, though, none of these firewalls will typically inspect DNS queries. DNS query inspection can reduce processing performance because every device makes many queries rapidly. (You can read more on the effects of deep packet inspection here). Armed with this knowledge, our attacker starts to hide the data payload inside the DNS query! The queries will move through the firewall to the attacker’s web server and deliver the stolen data. Below is a simplified diagram of how this would work.

In 2017, Unit42 identified a string of DNS tunneling attacks from the threat group OilRig, most of which targeted financial institutions and government installations in the Middle East. These particular attacks began with a phishing scam designed to infect a host on the target network. An Excel document containing an “incompatible worksheet” was sent through email to the target, who was asked to enable content, and then a macro was run in the background. This macro would concatenate the worksheet to create a .HTA file that would be run in the background with mshta.exe (which executes HTML files), installing a backdoor trojan. 

When the trojan captured data, it would respond to DNS queries created with random values from various subdomains (to avoid cached responses) and create responses with start/stop delimiters represented by specific IP addresses. This would completely disguise the payload in a way that no firewall would detect it. Other variations of the attack showed DNS queries being used to transmit the Mimikatz tool (password extraction and encryption software) in pieces of data meant to be reassembled by the trojan on the host; this is a large file and required too many DNS queries to transmit the data, which made it prone to detection.

{{banner-23="/design/banners"}}

DNS flood

This next attack is effectively a distributed denial of service (DDoS) attack using DNS queries. A DDoS attack aims to take down a resource by literally flooding it with packets; in a DNS flood, the attacker uses infected hosts or bots to take down DNS servers. For more details, see our in-depth article on DNS floods.

There are many different types of DNS flood attacks, but we will focus on three in our discussion: a DNS query flood, a DNS reflective attack, and DNS water torture. Here is a simple diagram of the overall concept:

DNS query flood

In a DNS query flood, the threat actor will use several bots to send tons of DNS queries with spoofed source IP addresses.

DNS reflective attack

A DNS reflective attack is much more aggressive and will be more difficult to trace than a query flood. In this variation, a target IP address is designated and the requests are sent to several different DNS servers to avoid flooding any one DNS server. 

DNS water torture attack

DNS water torture attacks aim to take down authoritative DNS servers. Many bots make thousands of very small subdomain queries, like a thousand tiny drops (hence the name “slow drip” or “water torture”).

{{banner-24="/design/banners"}}

DNS hijacking

DNS hijacking occurs when an authoritative server is compromised and the threat actors gain access to change public A records. As a result, any endpoint or DNS resolver trying to reach a website would be redirected to a poisoned A record of the threat actor’s choosing. The example below discusses how Amazon’s DNS servers were hijacked using falsified BGP advertisements (more on the attack here).

In 2018, threat actors launched a DNS hijacking attack against myetherwallet.com. Threat actors began advertising BGP routes for 205.251.199.0/23, which belongs to the authoritative DNS servers for Route 53, the AWS DNS service. Several DNS servers, including those of Cloudflare, accepted these routes. The TAs then started to redirect www.myetherwallet.com to a malicious website via the public A record for this top-level domain. On closer inspection, the advertised TLS certificate was self-signed, but if users chose to continue to the website, the TA could capture all of the information sent. This attack resulted in about $160,000 worth of Ethereum cryptocurrency being stolen over two hours.

Identifying an attack

In most instances, these attacks can go undetected for a significant amount of time because they are just very deceptive. When looking for signs of a DNS attack, it is important to pay close attention to the reports coming in from your end users and various organizational departments. If there is an influx of issues with your primary intranet site or an external web site indicating that the site “looks weird” or is completely down, it is time to take these reports very seriously. 

Another good indication of these attacks would be reports of duplicate IP addresses on the network, which could be a rogue DHCP server handling requests. Any uptick in bandwidth consumption from specific machines or the DNS server itself is a good marker of an attack.

Consider the following example scenario. Suppose that Dave is the website administrator for DavesCompany.com and starts receiving multiple reports that the website is running very slow and some claiming that it is down entirely. Dave begins investigating by testing the website from his local browser and receives the output shown below:

Dave then uses the ping utility from his local workstation to test connectivity to the web server, as shown in the image below. Judging by the high latency of the ping requests, Dave becomes suspicious of a possible DDoS attack.

Now Dave is on high alert. He immediately looks over the logs in the firewall associated with the authoritative server for davescompany.com. The results show high numbers of DNS queries from a specific IP subnet. These signs suggest that the DNS server holding records for davescompany.com is experiencing a DNS flood attack. Dave now needs to deal with this issue, as discussed in the next section.

Mitigating and preventing DNS attacks

DNS attacks range in severity and should be dealt with using measures appropriate to the specific attack. Here are some individual attack mitigation and prevention strategies for the various attack types described above.

DNS cache poisoning

The best course of action for mitigation here is to identify the source of the attack. In some instances, this will be a node on your internal network, so you will need to find the rogue device. Use network scanners to find devices that have makes, models, or MAC addresses that don’t fit with your standard deployments. Also check for machines on your network that are disconnected in your control software and devices that are offline but shouldn’t be.

Once the rogue device is identified and eliminated from the network, you will want to flush the DNS on all of your network devices. In Windows, this can be done with the command ipconfig /flushdns, but a good, old-fashioned reboot is often the best approach. 

DNSSEC is an excellent way to further prevent DNS cache poisoning, since DNS lacks any form of authentication by default (RFC 4033 is the standard for DNS security). DNSSEC will use digital signatures and public key cryptography to validate DNS data. If the data being transmitted is not encrypted with the private key, the public key will not be able to decipher the information and will discard the contents, preventing the device from being redirected by poisoned records.

DNS tunneling

This is a much more severe type of DNS attack. It will have some sort of malware involved, and some pretty deep log analysis will be required. 

When filtering your logs, you will want to look for any DNS queries that have complex domain names or anything that looks suspicious; the odds are that there will be a lot of requests and replies to/from these domains. Compare the recent volume of DNS requests with historical DNS requests in a given day, and there will be much more when the attack was initiated and going forward.

As always, run malware scanning tools on all network devices, starting with the machines responsible for the most DNS requests. Be sure to check mail logs and look for increases in spam from specific domains associated with the requests you are seeing, since this was likely initiated by a phishing scam in the first place.

DNS flood

DNS floods will be the easiest to mitigate, and the resources recover much more quickly compared to the other attacks. Blacklisting the IPs that are flooding your server is an absolute must if you intend to stop the attack, and blacklisting entire subnets may be necessary. Next-generation and cloud firewalls should offer filtering options as well as intrusion detection and prevention measures. 

Rate limits can be set to restrict the number of queries that can be transmitted per second, preventing the server from being depleted of resources. Most third-party DNS and security providers will offer automatic detect-and-defeat functions for DDoS attacks. DNS servers should always have redundancy: Having only one DNS server configured within any autonomous system is a big mistake.

DNS hijacking

DNS hijacking can be very difficult to detect without third-party monitoring systems. The BGP protocol is still so widely adopted and so inherently insecure that it is very difficult to prevent another entity from advertising your routes as their own. 

Resource Public Key Infrastructure (RPKI) is an example of a safeguard available for confirming the identity of BGP advertised routes. More information on RPKI and its role in helping prevent DNS hijacking can be found in this blog post.

BGPSEC (RFC 8205) is another significant addition to help secure BGP routes.  While standard BGP will append a neighbor’s AS number to the front of the AS_PATH parameter, secure BGP will also add a cryptographic signature over the top of the AS_PATH.

The Internet Society (ISOC) has a standardization initiative called MANRS that provides required fixes to common security issues within routing protocols.  Participation in and adoption of these standards will position a network to be much more secure and is a highly recommended best practice.

It is very important to keep any edge routing equipment firmware up to date with the latest patches. Something as simple as using a VPN solution will prevent the hijacking of local DNS settings and redirection of end-user devices. Training staff and end-users is a big asset in preventing this kind of attack.

Even if DNS is hijacked, the resulting websites will be very poorly disguised. Anyone with basic training should be able to recognize the signs and leave any false, redirected sites immediately.

{{banner-25="/design/banners"}}

DNS security best practices

As a recap, here are some recommendations for best practices for preventing DNS-based attacks:

• Enable DNSSEC on all DNS servers (note that special considerations apply to IPv6).
• Use rate limiting for DNS queries.
• Implement firewalls and keep firewall definitions up to date.
• Create and/or utilize redundant DNS servers.
• Utilize third-party software to secure public DNS servers.
• Implement RPKI infrastructure to better secure public routes advertised within your AS.

Conclusion

DNS is an absolute requirement for today’s internet; unfortunately, it was never designed with security in mind, which makes it a difficult attack surface to secure. DNS can be manipulated by cache poisoning, facilitating malware injection into your hosts through tunneling. It can completely take down your website in a flood, or worse, your public DNS records may be hijacked. 

Pay close attention to the recommended best practices and maintain a diligent posture when it comes to monitoring and logs. By utilizing some of the extensive third-party options available and implementing proper safeguards to maintain DNS data, you can take one potential catastrophe off your already stacked IT plate.