A Covert Channel is a type of attack that creates a way of communicating through a system for which it was not designed or intended for such communication. That’s why it is one of the main techniques used by attackers to steal data from victims.
A communication system that is usually always open in the network electronics and that, quite often, is not properly secured is the Domain Name System or DNS. This makes the DNS protocol a fantastic channel for carrying out covert channel with barely any restrictions.
Being able to consult Domain Name Systems outside the organization is a serious security issue, not just because of possible covert channels as we will see, but because among others, it allows attackers to check C2 domains without going through the corporate DNS servers and without leaving logs, more than in the network electronics. This, for example, would complicate a cybersecurity investigation.
Designing a Covert Channel system by DNS
As mentioned, DNS is a good system for carrying out Covert Channel and sending information outside an organization without leaving any trace behind. Now, we will see how simple it is to make a proof of concept to steal data through the DNS protocol.
In order to perform the PoC, we need two components, the first of which is a DNS server. This should act as if it were the legitimate DNS server, but it must be able to interact differently before certain names. The second component is the client or malware. This will perform, among other things, DNS requests. Requests should look “normal”, but in reality, they’ll hide key information for a possible victim.
The flow of DNS requests is typical of a client-server architecture. The client makes a request to the DNS server and this responds as appropriate.
For the case at hand, the DNS server must act as it normally does and, before a special domain, it must respond according to the design of the protocol for the Covert Channel.
Next, we describe the protocol used in the PoC that we are going to demonstrate.
The client, for us the malware, will obtain information from the infected system and will send it to the server in the form of subdomains. For example, esto.es.informacion.critica.sothis.tech. The request type will be TXT, although almost any could do, but with the TXT request it could be used to download data from the server.
In the previous image the response to a TXT type DNS request can be seen. The red box is the response in itself and the green box is the information contained in the response. In this case it is a plain text and data referring to the SPF, but any type of data could be used as long as it is transmitted respecting the legible ASCII code.
On the server’s part, we should have a full DNS server, but for the PoC we will only respond to TXT type requests. In addition, the server will only respond to queries from a particular domain. Finally, we will add a control flow to send and receive data.
It should be clarified that this is a very simple and unworkable design, as it has been developed simply as a demonstration.
This is a malicious code that collects data from the infected system and sends it to the outside. For the demo, the malware will obtain the environment variables and transfer them to the DNS server.
Data sent will be in the form of requests to subdomains and, in order for them not to generate alerts or errors, they will be sent according to RFC1034 and we will limit the size of the queries to 63 characters for the subdomain. Furthermore, for our exfiltration protocol design, we’ve added a preamble and an epilogue to the transferred data. Finally, we encrypt the data sent so that there are no issues; this encryption is compatible with the URL format. We will encrypt the data in hexadecimal characters from 0-9 and A-F. But it could, for example, be encrypted with RC4.
Here you have the source code for the client or malware.
The server acts in reverse, basically. The server responds to the TXT requests for the exfiltration domain, for example covert.sothis.tech.
The server must also understand the exfiltration protocol, so the server must identify the preamble, the transferred data and the epilogue. In addition, after extracting the filtered data the server is able to recover it, basically by reversing encryption or encoding.
At this point, the server already has all the data filtered by malware through Covert Channel in DNS. The PoC is only trying to demonstrate how important it is to monitor communications beyond regular use. Because now the server could update the malware, for example, or it could issue orders to a more elaborate malware, so, the possibilities are almost endless.
As has already been stated, the communication is initiated by the client and as far as we’ve seen, the client directly sends the data, but, what if we take it a little further? The server can also send data to the client by responding to the client’s TXT requests, or it could tell the malware to read the input data in another way, for example, https to a specific address.
Using the data sent by the client and the server, our scenario becomes a perfect C&C based on DNS. From the server we can execute commands at the request of the client or malware. We could also send files from the server to the client (for example, new malware, update the current one, etc.). Ultimately, by implementing the necessary logic we would have a completely functional malware and C&C.