Since the start of the pandemic, cyber attackers have increasingly sought to exploit DNS channels to steal data, launch DDoS attacks and deploy malware, and the cost of these attacks is increasing. According to IDC’s 2020 Global DNS Threat Report, the average cost of such an attack is now approaching $ 1 million, and the impacts can range from direct expenses related to the downtime of applications or services to more factors. difficult to quantify, such as damage to a company’s brand reputation.
These attacks are also much more prevalent than many realize. An EfficientIP study found that nearly nine in ten organizations (87%) experienced one or more DNS attacks in 2020, with victims being hit an average of 7.6 times during the year.
One of the most common types of threats organizations face is DNS tunneling, in which attackers encode data from other programs or protocols into DNS queries and responses. This allows cybercriminals to insert malware or pass stolen information into DNS queries, which freely enter and leave a network, creating a secret communication channel that bypasses an organization’s firewalls. It essentially becomes an open channel for data exfiltration, access to your internal network, and malware command and control.
Where does the DNS tunnel come from and where it goes
The use of DNS as a transport method to access blocked content has been around for decades. Before free Wi-Fi was ubiquitous, some smart and savvy techies who didn’t want to pay in the face of a captive portal noticed that in many situations, they could ping a server outgoing and get a response even without a connection. Internet. . Whether they were connected to the internet or not, DNS was always running in the background. If a user had an “authoritative” server for a namespace they controlled, DNS traffic would flow into and out of it regardless of the captive portal.
From there, they created software capable of slicing out an outgoing message to embed the payload in DNS queries, decode received traffic, and encode the name server response. The limits of the size of a transmission had to be taken into account and the message slicing process was very slow, but it worked and the process became the base of the tunnel.
When first designed, a DNS tunnel was difficult to set up, but the toolkits and instructional videos widely available online today leveled the playing field. The tactic has been adopted enough so that even novice hackers can now use it to access content, steal data and documents, and implant malware into an organization’s networks.
DNS tunneling allows attackers to escape a network firewall to obtain information in or out of a network by encoding data from other programs or protocols into DNS queries and responses. These responses also often included data payloads that can be added to an attacked DNS server and that can be used to control a remote server and applications. State actors routinely use DNS tunneling to exfiltrate sensitive information from infected hosts, but it is widely considered to be one of the most “accessible” threat vectors, allowing even the most uninformed hackers to dig deeper into the dark. otherwise secure domain.
Easy to deploy; Hard to stop
This is not a threat to be overlooked; even though they are now easy to set up, DNS tunnels remain difficult to detect. Unfortunately, the techniques for discovering and identifying DNS tunneling attempts require analysis of both traffic and live domains associated with bad actors, making them difficult and time consuming to identify.
As indicated in the MITER ATT & CK framework:
âThe DNS protocol performs an administrative function in computer networks and can therefore be very common in environments. DNS traffic can also be allowed even before network authentication is complete. DNS packets contain many fields and headers in which data can be hidden. Often referred to as a DNS tunnel, adversaries can abuse DNS to communicate with systems under their control within a victimized network while mimicking normal expected traffic.
While this is not the only protocol that can be used to form a tunnel, its prevalence in normal network communications makes it easier to ignore. Additionally, since DNS queries and responses are not completely uniform, it is not always easy to spot those that are abnormal or may not be up to standards. Despite these challenges, the potential for damage requires organizations to take every precaution.
How to spot activity on your network
So what can you do to detect a potential DNS tunnel on your network? Start by examining the DNS queries themselves. Since DNS is not typically used for data transfer, many organizations do not monitor this type of traffic for malicious activity as it would with other types of traffic.
A good threat intelligence flow should include information gleaned from a variety of sources that can be used to keep your SIEM or other perimeter security devices up to date. This can help you block DNS queries sent to all sites known to be bad, malicious, or which are known DNS tunnel endpoints. If you have your own recursive service or if you subscribe to one that offers filtering at the DNS layer (i.e. a DNS firewall), you may be able to block outgoing requests to that Stadium. It’s also important to keep a close eye on the areas themselves, as well as the frequency and source of specific requests over time.
Running secure recursive resolvers inside the network and setting them up with DNS firewalls might work if and when a bad address is known. It may be appropriate to configure your firewall to block all traffic exiting port 53 from any machine inside the firewall (other than company-approved recursive servers), because authoritative servers will bind to this port.
The key is to identify abnormal traffic operating under the cover of DNS. To do this, you need to keep a close eye on things like the length of subdomain names in queries, as it can be encoded data. Other things to look for are DNS queries with high entropy or high level of disorganization. Most of these requests follow a fairly organized pattern. Since DNS traffic is transmitted in the clear by default, it is possible to spot traffic that does not look like the others. Make sure to examine the overall network traffic, looking for unusual data flows or new DNS queries from processes or clients that typically do not communicate on the network.
Finally, always track network-wide malware infections, especially if a strain is known to build DNS tunnels. Do not assume that only one device has been affected. By proactively correcting customers who may have been exposed, you can save yourself a lot of trouble down the line.