Skip to content

DNS tunneling vs network security controls part 5

The last part of DNS security scenarios — this time DNS will be used as a command and control (C2) channel. DNS has limitations, which is why using it for data transfer is quite slow and impractical. However, using it for a C2 channel is a completely different story.

My lab scenario

For C2 communications, I’m using CNAME records — normally used for domain aliases. How does the scenario look? The client is constantly polling for the CNAME record of a particular domain. In my scenario, the domain is: poll.sessionid.c2.io. The server does nothing until a command is issued. Once a command is sent, the server responds to the client’s query for the CNAME record with: command-encoded-to-base32.c2.io. Then the client executes the command and sends the response back to the server, again querying for the CNAME records of subdomains: response-encoded-to-base32.c2.io. The response is sent in chunks. The server decodes from Base32 and assembles the chunks.

The client script was written in PowerShell.

The server script was written in Python.

See an example of how it works.

Which of the previously tested vendors (Fortinet, Cisco, Palo Alto) is able to detect such C2 communications. Unfortunately, none of them, so this time I do not have any recordings from my lab.

Summary

DNS is a crucial network protocol, but unfortunately, it can be used for malicious purposes as well. I tested different DNS tunneling scenarios such as data infiltration, exfiltration, DGA, and C2. The results were as expected — protection for DNS is quite poor, mainly based on detection of known tools (like iodine, dnscat) and simple domain categorization.

I’m really curious how a dedicated solution for DNS protection, like Infoblox, will behave in such a scenario. I’m planning to test it, but I guess the behavior will be similar. Will see soon…

Join the conversation

Your email address will not be published. Required fields are marked *