Creating botnet C&C server. What architecture should I use? IRC? HTTP?

Question

I am doing a project related to botnets and I have to create a lightweight command and control server. But I am stuck: should I use IRC or a HTTP-based C&C?

Even I am not getting any in-depth architecture or analysis of any C&C Server.

I am using hardware device to connect C&C, what should I have to keep in mind?

Answer 1

For a C&C server, you want to achieve the following characteristics:

• The infected system must be able to talk to the C&C. This entails getting some data out of the machine, through whatever network access it has. The easy case is when the machine has full Internet access (possibly through some NAT); however, there are networks (especially in business environments) where machines have only local addresses, there is no NAT, and outbound communications must go through a HTTP proxy. Possibly, the proxy will need some authentication, that may be automatically provided by the OS (Windows...) provided that the OS libraries are used to do so.

  Thus, HTTP increases the probability of succeeding at connecting to an external server, whereas IRC cannot really handle the "proxy only" case.

  On the minus side, HTTP is a client-driven protocol, so the infected machine must "poll" the server (issue requests regularly); it cannot simply wait for an incoming command. This regular activity may allow for easier detection of the infection, and will also increase bandwidth requirements for the C&C, especially for large botnets. IRC would be lighter in that situation.

• You want the data transfers to be undetected by the network administrator. Such sysadmins tend to strongly react to any network activity that uses the traditional ports for IRC (e.g. freenode uses 6665, 6666, 6667 and a few others). There again, HTTP will be more likely to "fly under the radar".

  Plain HTTP requests may be inspected by nosy firewalls. HTTPS may help you here; decrypting HTTPS requests requires installing and maintaining a custom certification authority that produces on-the-fly fake certificates for contacted Web sites. There are appliances that offer that kind of service, but this is not yet fully widespread.

• You want to hide the true C&C server whereabouts. If you have a large botnet, then it is a certainty that some sysadmin, somewhere, will notice something fishy and try to guess where the C&C is. HTTP requests require the client to know the target server IP address. On the other hand, with IRC, the infected host would connect to a nearby "honest" IRC server, and, by the magic of data flow between IRC servers, the data may reach the C&C wherever it currently hides.

  For a more complete solution, you would like the C&C to be hidden as a Tor hidden service. Note that the true IP address of a hidden service remains hidden only as long as the assumptions behind the onion network theory hold, in particular that the "uncorrupted" onion routers remain a large majority. Whether this is true in practice is anybody's guess.

A really efficient botnet would be structured as an old-fashioned spy network, with decentralized cells; botnet machines would not know the C&C address, but merely how to talk to the other machines in the cell, as well as one or two machines from other cells. Messages would then be broadcast by hopping from cell to cell. That kind of structure requires a lot more thinking at the design phase, but would be a lot more resilient to dismantlement by law enforcement forces.

(Fortunately, ill-intentioned people who want to run botnets are no less lazy and incompetent than the rest of the World, so well-designed botnet structures remain a rarity.)

Answer 2

There are many reason for both of them. The main differences:

• irc is a two-way tunnel. Thus, message sending or contact requests initiated by you and your bots would be much easier in both direction, if at least one of them are behind a natting firewall.
• http is much more common, especially if you use https. If your nodes are communicating on well-parametrized https, then no traffic analyse / filtering firewall will be able to say, that you are doing something which is only allowable in a sandbox, as research.
• the http protocol is stateless by main configuration, which means complex communication will be harder to implement (you have to make some session handling). On irc, you can simply open a thread for your clients and then you will have a procedural, single flow of control.
• although irc can be extended by ssl as well, it is not so common as in the http. You will probably have to embed some irc communication library for the task, configuring it to use ssl on a such way that it will be undetected will be harder. In case of http your can select a broad spectrum of different soap / rest / rpc solutions and from libraries utilizing them.

As I know, in the circles of the currently running botnets the https is much more common, but most of them is a nightmare from a programmer point of view.

For research I would use unencrypted irc (easier to program, no need for encryption).