Feederbot - a bot using DNS as carrier for its C&C(DNS信道马)

DNS as carrier for botnet C&C seems to be getting popular. Concerning its usage as botnet C&C, DNS has not been seen so far. Additionally, in typical network environments, DNS (at least when destined for the preconfigured DNS resolvers) is usually one of the few protocols – if not the only one – that is allowed to pass without further ado. Thus, botnets using DNS as C&C benefit from the fact that currently there is no specifically tailored detection mechanism, which in turn, raises the probability for the botnet to remain undetected.

During our work on covert communication of botnet command and control channels, we analyzed Feederbot in some detail and monitored it over the last year. In this post, I will provide some insight on the C&C.
Not only Feederbot, but also Morto seems to be using DNS as carrier for its command and control channel.

But let us focus on Feederbot for now. Feederbot uses valid DNS syntax for its DNS messages. Messages from the C&C server to the bot are transmitted in the rdata field of a TXT resource record. The DNS requests have the several different schemes for the question domain name (qname), similar to the following where [CHUNK-ID] is an int >= 0, incremented by 1:

[50 bytes].[CHUNK-ID].[qdparam].0.f2.[TLD].   IN   TXT

The DNS responses typically carry one TXT RR in the answer section (sometimes repeated in the authority section) with a 220 byte string that is base64 encoded. Here is an example:

xMtwHYRyZu/z4QbhBKZIVWvPBfiuGn+jb1WQxtZN7PR9Wf0sfnAqxDOJD9LgmwfFaUGo6fdtgZ0lIQyAx1VWJw+vzdHdxMpHu6xfMRq8sVSfqwPvI9TEIV8pkXw4P4TCSH05BAO1LGPMQ+XD+TYLY2woxM1j06mCMhrNjWzI8WbmCBlj2/dpR73KBnDl/DRmheKWMJx2dUTp4iFMH4N9kXjeOYis

Once base64 decoded, the messages are still no real plaintext, because they are encrypted with RC4. Feederbot uses a variety of different RC4 encryption keys and even stacks RC4 encryption. A specific part of the DNS query domain name is used to transmit parameters for key derivation. As an example, one such parametrized key derivation function takes as input a substring of the query domain name, denoted as 'qdparam' in the example above. The value of the substring 'qdparam' is then RC4-encrypted with the (constant) string “feedme” (hence the name of the bot) and the result is used to initialize the RC4 decryption of the actual C&C message chunks. The stream cipher is used in a stateful manner, so that if a message chunk gets lost, decryption of all subsequent message chunks will fail. In addition, Feederbot’s C&C message chunks make use of cyclic redundancy checks to verify the decryption result. The CRC32 checksum preceeds message chunk payload and is not encrypted.

The fact that CRC32 checksums are used makes it comfortable to know whether decryption works or not. Interestingly, we have seen ANY as resource record type in some of the queries, too. In order to perform the DNS requests, the bot relies on Windows DNSAPI.dll::DnsQuery_W.

The following figure shows an important part of the disassembled RC4 initialization routine:

Well, the drawback of encryption is that you need a key and you better choose one that is easy to remember, such as:

So, what is the lesson we learn from Feederbot? Watch your DNS traffic!

quote: http://blog.cj2s.de/archives/28-Feederbot-a-bot-using-DNS-as-carrier-for-its-CC.html