Introduction: Why Are There Alternative C&Cs?

Before discussing alternative botnet command and control (C&C) technology, its advances over the years, and the latest in both operational and technological innovation, we need to ask ourselves: why create alternative technology when good, old IRC usage is still valid, useful, and moreover, better than most new approaches?

For over a decade, botnet technology has been based on IRC. Meaning, the Trojan horses acting as bots would use the IRC protocol to connect as clients to IRC servers. These servers would then be the means by which the botnet controller (also known in recent years as botnet master or herder) would control the army.

IRC technology is robust and has been around for a long time, but there are several key issues that make it last longer than most other technologies when used for botnet C&Cs:

IRC has proven itself many times over, but it also has an Achilles’ heel—it is centralized. By definition, a botnet is an army of compromised computers reporting to receive commands from a central location. That very same central location (or locations), if discovered, could be interrupted. It could be reported to the authority hosting it (in all likelihood, unwillingly) and it could get blocked or null-routed by ISPs. There are people out there from the authorities to volunteer botnet hunters who do this daily: find a C&C server and file a complaint to the ISP. Although often this is all they do, these C&C servers are also susceptible to eavesdropping. For example, when sitting on the IRC chat channel that the bots in a particular botnet connect to, one could potentially listen in on the commands given by the botnet controller, and perhaps even emulate him.

This is dangerous to the botnet controller, because he’d like to maintain control over his botnet and not risk it being taken over by a competing botnet controller, or even disassembled (think of uploading a new file to each bot by issuing a download command on IRC, and that way destroying the botnet. This is not exactly legal or ethical, but it is an example of what could be done, which IRC makes easy).

As useful as IRC is to the people running botnets, there are some inherent threats for them. For a long time these threats were non-existent beyond the theoretical realm, and later on not significant. Today, these threats have become commonplace, forcing botnet controllers to adapt. IRC is still the most commonplace form of a C&C server. It is slowly being complemented with obfuscation and security using alternative or more advanced C&C technologies, but while there are quite a few C&C servers running on different protocols and applications, most of these are still IRC based.

Historical C&C Technology as a Road Map

Looking back to history and the most basic C&C mechanisms, we can establish basic terminology, which will help us to determine the usefulness and risks of newer technologies introduced later on.

In the beginning, bots and botnets indeed were legitimate tools used mainly for functional purposes, such as maintaining an IRC channel open when no user is logged in or maintaining control of the IRC channel.

The first botnets of the new age of Trojan horses (Trojan horses have been here for years, but became popular mass-infection devices in 1996–1997). Controlling one compromised computer is easy. Controlling a thousand becomes a logistical nightmare. When an infection would happen, the Trojan horse would phone home by connecting to an IRC server. Once logged on to the server, the Trojan horse (now bot, more commonly referred to back then as a drone) would seek to let its master know it was there. This would most commonly be achieved by sending a private message to a logged on user (the botnet controller) or by joining a chat channel. The bot would then echo something such as:

“Hi! I am here master! My IP is 127.0.0.1 and I am listening on port 666!”

The nickname or chat channel would be the control channel, while the announcement message sent would be the echo.

As the technology advanced, control channels became more sophisticated. As an example, a chat channel would be used but it would be password protected (a key would be set on IRC). Botnets became a menace. Mostly they would be IRC based, and they would connect to public IRC networks. They would mainly be used to attack users on IRC, on and off IRC (“flood” on IRC or distributed denial of service attack—DDoS—off IRC). The public networks needed this stopped. To that end, they would take over control channel nicknames or chat channels and make sure the botnet controller would not be able to use them. This caused the bad guys to change strategy and use private or compromised computers for their bot army, achieving a higher level of security.

At this stage, folks would look for these private servers and try to listen in and disturb the botnet operations—snoop. This caused the bad guys to once again escalate and start adding further security to their private servers as well to their bots (the Trojan horses):

From this point on it was a never-ending war of escalations—the botnet hunters looking to disturb the botnet operations and thus adapting to the latest technology (reacting) and the botnets controller inventing new technologies to maintain operations.

DNS and C&C Technology

Following from the use of private servers and passwords, C&C technology continued to develop.

The first technology to be introduced consisted of multiple IRC servers interconnected (or linked) using the IRC server technology, rather than just stand-alone servers. IRC is built in a fashion that several servers can be inter-linked to form a network of hubs, branches, and leaves. When you use this technology, the address of all servers are hard-coded into a bot, and it tries to connect to each of the addresses. When a connection is made, the same IRC channel can be entered (joined), where the botnet controller will be giving instructions.

By itself, this technology would make it difficult for the botnet hunters to take down the whole network, especially if new servers were introduced constantly. Yet, how were the bots to know where the new servers were, if they were hard-coded with an address of servers that no longer existed? This technology had its limits, introducing the use of DNS records (RRs) to the C&C realm.

Back then and up to about the year 2002, DNS was manifested in two main uses: domain names and multihoming. Both of them were facilitated, finding the botnet C&C, as well as keeping it alive on the Internet, before connection to the actual C&C server.

Alternative Control Channels

Alternative control channels are exactly as named, an alternative communication channel by which to control a botnet.

When the C&C server (or servers) is down, the botnet is effectively dead. There is no way for the botnet controller to issue instructions or even know what bots are under his control. For that reason, if all else fails, the alternative control channels are introduced.

In most bots, these are hard-coded as a backdoor, opening a TCP port on the system, allowing for remote connection, which will give administrative control of the compromised computer. Effectively, a different control interface for the bot. A push from the botherder rather than a pull from the bot client.

In other cases, there are backup C&Cs in place, at times using a different control channel altogether. That way, if communication is lost, the bot can reestablish communication with its master and be redirected—jumped, to a new C&C server.

In one noteworthy case in late 2004 involving a large botnet, 350,000 hosts strong, the C&C server was sinkholed (redirected and tapped by the good guys) to an IP controlled by botnet hunters. In a matter of just a couple of days, most of these bots stopped connecting to the C&C. Presumably they were jumped elsewhere.

Web-Based C&C Servers

IRC may be the origin as well as the most-used type of C&C, but it is not the only one, by far. The most commonly used C&C type after IRC is the Web server. A Web-based C&C server does much the same as an IRC-based C&C server; the main difference is the control channel, which in this case is a different protocol altogether.

There are two types of Web-based botnets: echo based and command based.

Echo-Based Botnets

Echo-based means the bot would simply announce its existence to the C&C. There are several ways of doing this with different volumes of data relayed.

 Connect & forget

 File data

 URL data

Connect & Forget

Connect & forget means that the bot would connect to the Web server and that’s that. The botnet controller would need to collect these connections somehow, usually by the means of a log file, to be able to view the IP addresses of the bots.

In some cases, Web counters (visit-count) services have been used for this purpose, rather than a specially created Web site, as another example. The botnet controller would then connect to each and every one of these bots, mostly via a backdoor port that the Trojan horse opens.

There are some IRC-based botnets that run much the same way. The bot connects to the IRC server and does nothing else. It is hidden to anyone but the server administrators.

File Data

Another type of C&C similar to connect & forget botnets are Web servers that host files with instructions for the bot, so that when it connects, it downloads the new instructions. Instead of instructions, an executable can be placed on the Web site. In that case, the bot will download it as an update to replace itself with, or as yet more malware to be installed on the compromised computer.

URL Data

In some occasions, the bot would send a full URL to the Web server. That URL would contain information of importance to the botnet controller, such as the port of the backdoor software or the password required to access this specific bot, both of which are randomly selected for each bot.

A URL will look something like:

http://botnet1.example.com/blah.txt?port=34556password=qwerty211

This URL will later be parsed for the relevant information, and the controller will use it to connect to all the bots and give them instructions.

Command–Based Botnets

Web-based botnets that are command based are an addition to any other type of botnet, which helps the botnet controller manage the army.

These are GUI Web interfaces by which the botnet controller can issue instructions, much like typing them on IRC, only it works in push mode rather than pull. The C&C connects to all the bots, rather than the bots connecting to it and awaiting instructions.

Figure 3.1 is a screenshot of one of the very earliest command-based Web botnets:

Figure 3.1 Command-Based C&C GUI

As you can see, it enables the controller to do the following:

 Have the bot download files from the Web.

 Upload a file to the compromised computer.

 Give the bot direct shell commands.

 Save screenshots.

 Block URLs from surfing.

 Change the hosts file, so that the user goes to malicious Web sites instead of ones to which he intends to surf.

Some later GUI C&Cs also enabled browsing of the botnet, choosing bots by country, ISP, bandwidth, and other options, and instructing them directly, as well as gathering statistics. Consider this a Web service—a Web application to help run a botnet.

Drop Zones and FTP-Based C&Cs

Like many other protocols, FTP has also been experimented with as a control channel for botnets. Today, it isn’t commonly seen in the wild. However, there is a type of bot that regularly reports back (echoes) to an FTP C&C, and that is the phishing or banking Trojan horse.

These bots, such as Dumador or Haxdoor, are basically key loggers, only very advanced ones. They listen in (sniff) communication when the user on the compromised computer surfs the Web. When the user enters an HTTPS (encrypted) Web site, they perform a man-in-the-middle attack on the computer itself. Maybe we should call this a man-on-the-inside attack, since the attack takes place inside the victim’s computer. Then the bot presents the user with a fake Web site locally. This way, they break through the encryption and log the user’s credentials (such as a username and password).

The stolen credentials are then uploaded to an FTP server maintained by the botnet controller. Botherders maintain elaborate statistics about the credentials stolen and where they come from. Figures 3.2 and 3.3 show statistics about the origins of credentials gathered by a botnet.

Figure 3.2 Origins of Credentials Gathered by a Botnet

Figure 3.3 Bot Statistics

The botnet controller can then steal the user’s credentials and steal their financial information and money, as well as potentially perform an identity theft. In essence, these C&Cs, which are called drop zones, will record all credentials, no matter for what Web site, and feed them directly to the criminals on the other end.

Some more advanced drop zones also provide with instructions, such as, “If the user surfs to www.mybank.com, use this signature to steal only the information we need!” Or even more advanced, “automatically send the selected information in, so that we can direct you to change the user’s transaction on the fly, in real time, and send it instead to our account.”

Although these banking and phishing bots’ drop zones do not answer the pure definition of what a C&C does, they are indeed a control channel, and one that is a lot more live and active than most C&Cs of other types.

FTP is not the only protocol used for drop zones, but it is a leading one.

Some more information about economic uses for botnets can be found in the following article:

www.beyondsecurity.com/whitepapers/SolomonEvronSept06.pdf.

Advanced DNS-Based Botnets

As we already discussed, DNS is used as a layer of obfuscation and security for botnet C&Cs, providing redundancy and robustness, rather than serving as the control channel itself. So far we discussed the trivial concepts of using the DNS to represent IP addresses (as it was meant to), and multihoming, pointing to several IPs using one DNS RR. Now we will try to cover more advanced subjects, introduced by the bad guys to help with the stability of their botnets against take downs.

Games and tricks used by the bad guys to do this vary, but they mostly rely on the Time to Live (TTL) setting. The TTL determines how long the results of a DNS query would be cached locally on any remote name server that obeys the TLL. If the TTL is set to a very low setting (a small number), the IP addresses the record points to can be rapidly and consistently changed.

“The TTL is a very interesting knob for working with DNS, both for the good and bad guys.”

– Paul Vixie and Gadi Evron, defcon 14.

Dynamic DNS

Dynamic DNS, or DynDNS, is the name given to dynamic DNS providers. What these providers basically do is to enable anyone to register an account with them and get free DNS hosting services. You can set up your domain name or use a 3LD with one they provide. Then point it to, for example, your home IP address (which changes every time you get on the Internet if it is dynamic). You could update the dynamic DNS information either via their Web page or using a tool they provide, which will automatically detect your new IP address and set your DNS records accordingly.

These services are perfect for the botnet controllers’ use. They can set up any number of disposable hosts and change the IP addresses they point to very frequently. For this purpose, naturally a low TTL is set.

The dynamic DNS services suffer enormously from this type of abuse and often try to eliminate such abuse of their services.

Fastflux DNS

Fastflux is the name given to DNS records that change constantly, whether every day or every 10 minutes. This was first introduced in the spam world, where spammers would e-mail out spam messages and change the IP address of the site they send people to all the time. The same was soon applied to phishing sites, and indeed, botnet C&Cs.

With the bot going to the DNS name rather than the IP address, even if the IP address representing the C&C server goes down, it can be immediately moved to a different IP address, without ever issuing one instruction to the botnet. Often, the constant change of IP addresses will occur regardless of whether a takedown of the C&C happened. This is one of the reasons taking down botnet C&Cs has become impractical to a large extent.

An interesting way to track such changes is by the use of the passive DNS replication system created by Florian Weimer. For a more-detailed explanation see www.enyo.de/fw/software/dnslogger/. The system caches all DNS results (not the actual requests) it sees while monitoring large DNS servers. An example result (courtesy of Florian Weimer):

This example shows different DNS A records pointing to just one IP address. An interesting domain to watch for from the above is kimble.org, which helped Blaster.E take down a presidential campaign Web site. The date in the table above shows the time when the result was first seen by the system.

More information on fastflux DNS can be found at the Spamhaus Web site: www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#164.

Future Outlook

In the future, we can expect to see far more use of fastflux technology, as well as new C&C technologies being introduced. Still, IRC is going to stay with us as the leading protocol and application for C&C servers for a long time to come.

There have been rumors of ICMP-controlled botnets, as well as of covert channels, such as entries on social networking Web sites like MySpace.com, being used for C&C. Even if they are in fact being used and not only theoretical, the vast majority of C&Cs have been and will remain on IRC.

Where we can definitely expect change is with introduction of more advanced encryption by the bot masters, as well as the C&Cs themselves becoming very hard to take down (or, as shown in fastflux, taking down becomes irrelevant).

Another issue that we can expect to see change is the structure of the botnet. For example, in recent years botnets stopped being very large and became, rather, relatively very small. It is more likely for a botnet controller to hold 20 C&C servers with a few thousand bots on each, than to hold one C&C with several hundred thousand bots on it. The structure of an army becomes more and more clear as time goes by; however, with the introduction of compartmentalization into the equation, it looks more and more like a terrorist organization, with a few bots controlling botnets of their own, and only they as the “cell” leaders get instructions from the main C&C. If a brand is lost, the tree remains alive.

Botnets are here to stay, and the C&C or alternative control channels will be here to direct the armies.

Summary

Botnet technology has been in use for almost two decades, and its most basic form, which is distributed computing, even longer. The fact that botnet controllers now work for pay rather than build and maintain their armies for fun is key. Most botnet controllers either build or rent their armies for malicious usage, as that is where the money is.

In order to maintain revenue, they will do whatever it takes, from using a previously unknown exploit to spread to using new technologies for command and control, which is what this chapter is about. As technology advances on one side, it will on the other, but there are some conclusions we can draw based on our past experience on how whatever technology that follows is going to work:

This all comes down to robustness and reliability, which is what these alternative control channels provide.

DNS is a good example of how C&Cs use multiple layers in their design to ensure they stay up. By diversifying and using different servers and allowing for a quick alteration of what servers these are, the botnet controllers can concentrate on the C&C itself rather than moving all the bots constantly. The Web and P2P are good examples for alternative technologies being used for the actual control mechanisms.

Solutions Fast Track