blueblog - by Christian J. Dietrich - Botnets

Feederbot - a bot using DNS as carrier for its C&C

nospam@example.com (Christian J. Dietrich) — Fri, 02 Sep 2011 18:05:00 +0200

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+jb1WQxtZN7PR9Wf0sfnAqxDOJD9LgmwfFaU

Go6fdtgZ0lIQyAx1VWJw+vzdHdxMpHu6xfMRq8sVSfqwPvI9TEIV8pkXw4P4TCSH05

BAO1LGPMQ+XD+TYLY2woxM1j06mCMhrNjWzI8WbmCBlj2/dpR73KBnDl/DRmheKWMJ

x2dUTp4iFMH4N9kXjeOYis

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!

DNS as carrier for botnet C&C

nospam@example.com (Christian J. Dietrich) — Mon, 22 Aug 2011 17:49:00 +0200

Botnets have become one of the biggest security issues on the Internet imposing a variety of threats to Internet users. Advances in malware research have challenged botnet operators to improve the resilience of their C&C traffic. Partly, this has been achieved by moving towards decentralized structures (like P2P) or by otherwise obfuscating and even encrypting communication.

Recently, Christian Rossow and me, we looked into what we term covert communication, that is command and control communication which is hidden in what seems to be regular Internet traffic. We discovered and reverse engineered Feederbot, a botnet that uses DNS as carrier for its command and control. Using k-Means clustering and a Euclidean Distance based classifier, we correctly classified more than 14 million DNS transactions of 42,143 malware samples concerning DNS C&C usage. Interestingly, this analysis revealed yet another bot family with DNS C&C. In addition, we correctly detected DNS C&C in mixed office workstation network traffic.

Our paper dealing with DNS as carrier for botnet command and control channels got accepted at this year's EC2ND conference. I will be presenting the results at EC2ND which is going to take place in Gothenburg, Sweden, September 6-7 at Chalmers University.

Secure Network and Server Administration

nospam@example.com (Christian J. Dietrich) — Wed, 26 May 2010 15:35:00 +0200

Being a system administrator myself I have to say that secure system administration has become much more challenging in the last few years. With SSH bruteforce attacks hammering down on your servers and frequent software updates that need to be applied, administrators have a hard time keeping a server farm secure.

But not only fixing known vulnerabilities is important these days. In my experience as a malware and botnet researcher I have learned another important lesson: Know your network. Whenever there is an intrusion, it is surprising that more often, system administrators realize it by help of characteristic statistics of their network and its servers - especially if (for whatever reason) intrusion detection systems are not in use. Let me give an example:

Say, you work as a sysadmin of a corporate computer network. Say people are allowed to send email only via your own smarthost and your internet gateway thus blocks outbound TCP port 25 (SMTP). Do you count the SMTP connection attempts to outside servers (that your firewall blocks)? What is the typical number of blocked SMTP connection attempts (on a weekday)? Why could this be an interesting metric, you may wonder.

Let me explain. We analyze the network behavior of quite a bit of malware. It is not surprising that nowadays, lots of malware comes as a bot, i.e. a remote-controllable flexible piece of software that awaits instructions from a botmaster. Furthermore, neither is it a surprise that many bots are used to send spam. Ah, you get the point? Let us assume one of the computers on your network is infected. Then there is quite a bit of a chance that it is trying to send spam to outside mail servers. "But", you might say, "that spam is blocked, so there is no harm." Indeed, yes. But who says that the same piece of malware does not steal credentials or is involved in a click fraud or DDoS campaign? Even if you cannot do anything against it, it might be good to just know that there is an infected host in your network.

The number of (failed/blocked) connections attempts is not the only useful metric in this context. Based on my experience, I can recommend:

number of (failed/blocked) outbound connection attempts for TCP port 445 (infection attempts)

number of (failed/blocked) outbound SSH connection attempts for TCP port 22 (bruteforce scan attempts)

number of (failed/blocked) outbound DNS connection attempts (UDP port 53)

Depending on your environment, you may want to use a relative metric instead of absolute numbers, i.e. number of failed/block connection attempts over number of total connections.

Will Conficker destroy the world on April 1st?

nospam@example.com (Christian J. Dietrich) — Wed, 01 Apr 2009 00:25:00 +0200

Rumors are that one of the most widespread malware, Conficker (or Downadup) might strike on April 1st, 2009. I gave a short interview to the German TV station ARD that was partly broadcast as part of the ARD Mittagsmagazin (also broadcast on ZDF at the same time).

To me, there is no reason to wait for a specific date such as April 1st, for a malware to become active. This is a bit different if the malware itself spreads via email, such as Storm worm, and is completely based on social engineering. Furthermore, in my eyes, system administrators are fully aware of the danger that Conficker might pose, once its activated and thus look for it with special attention on April 1st. Any other date would then - from the attacker's point of view - make much more sense.

You can watch it at the ARD Mediathek at http://www.ardmediathek.de/ard/servlet/content/2006500 - 'Conficker'-Großangriff zum 1. April bleibt aus (only in German).

Safer Internet Day 2009

nospam@example.com (Christian J. Dietrich) — Wed, 11 Feb 2009 21:00:00 +0100

On the occasion of today's Safer Internet Day, Feb 11th, the German radio station SWR broadcast an interview of a couple of IT security researchers. The program (in German) is available online at http://www.swr.de/swr2/programm/sendungen/kontext/-/id=4352076/nid=4352076/did=4362270/lqo6w8/index.html

The McColo story from the spam and botnet perspective

nospam@example.com (Christian J. Dietrich) — Tue, 25 Nov 2008 22:22:00 +0100

On Thursday 11/11/2008, the US company McColo (AS26780) got cut off the Internet. McColo has been known for some doubtful activities - some say that McColo is responsible for as much as 75% of all spam sent on the Internet. These activities have stopped instantly as McColo got disconnected. I looked into this at our blacklist mirror. Since Thursday evening (2200 local time CET), the total number of requests on the blacklist are much lower than on the previous days. The traffic that is caused by the requests has - compared to the peaks - nearly halved.

After McColo (AS26780) "went" offline on 11/11/2008, the global spam volume has remained for about 10 days at about half as much as before. The low volume which even hit an annual minimum on 11/21/2008 was probably amplified by the fact that a lot of command and control channels of botnets were hosted at McColo.

On 11/15/2008, I realized that McColo suddenly reappeared for short periods of time through other Autonomous Systems, such as TeliaNet Global Network, AS 1299). At the bottom of this post, I have added some screenshots of bgplay that show the changes in the routing to McColo.

By the way, on 11/21/2008 one of the largest distributed denial of service attacks became public. The attackers targeted the German Hosting company InternetX with more than 40,000 bots and 800,000 packets/second causing a total bandwidth of 20 GBit/s during peaks. It is difficult to say whether the attack was done using McColo-controlled botnets. Interestingly, the number of requests to the blacklist once more decreased heavily on 11/21/2008 and the following day.

This might have been caused by the fact, the those bots while participating in the DDoS attack have stopped spamming.