DNS Data Collection and Transfer
This article discusses the use of DNS service to collect data (exfiltration) to send commands in order to carry out an attack (Command & Control (C2). The following website provides further information on DNS service and what is it used for: https://www.verisign.com/en_US/website-presence/online/how-dns-works/index.xhtml When we are at home or work and want to access a website (for instance everis.com or google.com), our device sends a query to DNS servers online and retrieves the IP address required to access the website on our browser.
This means if our protection (firewall, proxy, IPS) did not allow this type of traffic to leave the source and reach the corresponding servers, no access to the Internet or email exchange would work. This is why all traffic in port UDP/53 can access any DNS server in the world without restrictions. This can be seen in the Firewall rules.
This traffic is not subjected to any sort of filtering or blocking, directly accessing the Internet without prior analysis. This behavior, together with the lack of analysis, creates a type of attack known as data exfiltration or extrusion.
How is this attack carried out?
This attack involves malware infiltrating a network and collects data from the machines or from the network.
The details of this type of collection deserve another article, but the most common methods are via DNS, HTTP, HTTPS, and FTP.
As soon as malware is installed on the device, it starts mapping the network and collecting any data worth transferring. In general, the files are located in the ‘Documents’ folder and in the network drive (also known as file server).
After detecting the location of the files, the easiest step is the transfer to the Internet. This transfer uses the DNS protocol (UDP/53). Since it is a UDP port, it is not overloaded, as the size of the IP header is smaller than the TCP, and no data delivery receipt is received (as opposed to TCP, which performs this verification).
Since DNS traffic is not inspected/parsed/filtered, and it passes through firewalls freely to communicate with Internet addresses, this makes the transfer of data to the Internet easier.
However, the most disturbing aspect of this type of communication involves home devices of end users, because it is very hard to ensure that all users have an antivirus capable of blocking this type of malware.
Since many of these machines are continuously connected to download an episode
of Game of Thrones or another popular show, the machines can be used to perform DDoS attacks on a corporation.
How does this happen?
You may be wondering, how can the machine do all of this without users noticing? This is possible because thousands of machines, sometimes millions, perform the attacks.
Some may have heard of the networks known as botnets. The vast amount of machines infected by these bots can create a botnet large enough to carry out a DDoS attack on a company or access provider, which in turn leaves the company inaccessible and isolated.
How are these attacks carried out? How do the devices know they have to perform a denial of a service attack on a specific company?
Going back to the case of malware installed on a device (laptop, phone, or computer) in the context of a home, it remains there, collecting all the information it can retrieve from the device (exfiltration) and transferring it to a different location. How does it know where to send this information?
When the machine is infected, one of the first things the malware does is establish communication with one or various URLs. This communication is performed so the software can contact the command and control center (C&C or C2).
Therefore, it is possible to download malware (not all at once, but piece by piece, to fool the antivirus) and have the machine ready to launch DDoS attacks against a company.
What happens if this malware is installed on a device of your corporate network? What information does it collect from your network and what can we do to prevent this issue?
The following recommendations will help avoid this problem:
• Analyze and filter all DNS traffic through an IPS.
• Set your internal DNS topology so that DNS traffic can only be released through an internal DNS server. This means that if a user enters the address 126.96.36.199 on your device, they will not be able to resolve a name.
• Check which servers are used in your searches and only allow DNS traffic access to them.
• Use a tool to analyze the traffic requested and act as a DNS firewall.
• If you publish a service online and use it internally in your company too, use a resource called DNS Views, which makes it possible to customize the response, using the source of the query as a validator. This prevents the creation of Network Address Translation (NAT) rules and other malicious activities that make individuals within organizations access services published outside.
• Use only slave servers to respond to DNS queries. Use the Master server only as the basis of the configuration and as originator of the synchronisms thereof. This prevents issues like DNS poisoning.
• Use the honeypot feature and conduct early analysis of anything that may become an issue for your business in the future.