« Worldwide Spam Volume Down 60% !!! | Main| Kaizen for Product Development »

How to Build a Botnet

Tags:
5.5

So, one Washington Times reporter did what a whole "Can Spam" act couldn't do, make a significant dent in spam. It is still down 2/3, which worldwide is huge!

It did make me start to think that if we could figure out how the botnets work technically, then we could begin to shut them down. To defeat an enemy, you must think like them. So, to understand how to build a botnet in detail, I decided to do a "thought experiment" of building a sustainable fault tolerant botnet system. So, the first thing we need are some requirements. The "requirements" if one were to build a botnet, would be the following:
  1. A master server (host) that gives instructions to all the bots
  2. Bots need to check into a host daily to get instructions
  3. Host needs to be able to give it pointers to a list of email recipients and the message(s) for today
  4. Host needs to give bot a number of messages to run (or instructions to run the whole list)
  5. Fault tolerance - Botnet needs to tolerate if a host is unavailable, having the ability to look for another host

Requirement 5 is interesting, as it applies to McColo going off-line, and the recent reduction of spam by 2/3 because the bots are not sending billions of messages. Why? Because they have no controlling host to get instructions from. Where are the botnets going to go next? The spammers have deployed an amazing grid computing platform. I have to believe anyone capable of building such a platform would have thought about what happens if the host becomes unavailable, making it a single point of failure? My design would be for it to try other servers if the default host is unavailable for 1 day.

How to do that? This was a puzzle at first. If you just hard code IP addresses, you give computer forensic researchers (anti-virus companies, government agencies, and hackers) a list of all of your servers. Not a good idea if you run an illegal operation. So, you would generate DNS names randomly. Then look for them. But if you do it randomly, how can the host know which DNS names to create?

The answer for my design would be to have the bots try to connect to a domain name and use DNS to find the server. For example, spammer1.com, spammer2.com, etc. This is still pretty easy to stop. So my design would be to have the domain names generated by the bots based on an algorithm based on date, so they are dynamic. The spammer creates the new domains as needed and points them to the new host computer. This could change daily to avoid the problem of cutting off one host. (Frank's note: This answer is too basic. I think their actual system is more clever than this simple approach).


So that is my idea of how to design a botnet. So when these zombies start reconnecting, and my guess is soon, unfortunately these millions of compromised computers will start to spew more spam.

So the answer here seems to be to find ways to locate and disable the host computers. I prefer technical solutions to legal ones. But in this case, if the techies can notify the government(s) where these hosts are located, maybe that one-two punch will really help to "Can Spam" !


Comments

Gravatar Image4 - What you are referring to is known as "Domain Flux". This is similar to what was used by conficker and storm. The idea behind this approach is to have a mobile command&control channel, so even if the command servers are disabled, the next day there will be new command servers selected and the botnet lives on.

The problem with this approach is that by plugging in future dates, the algorithm can be used to predict the address of the command servers at any time in the future. Since the botnet controllers don't want to register thousands of domains in advance, it is possible for botnet enemies to just skip ahead to a date which generates a command server that has yet to be registered. The botnet enemies can then register this domain and take over control of the botnet as the bots roll over to that server on the date predicted. It is theoretically possible (with some ethical issues) for the botnet enemies to send an update command to all of the bots to change the command server generation algorithm to effectively take control away from the original botnet controllers indefinitely.

To avoid this, the botnet authors have (or are likely to...) implement a non-deterministic algorithm for generating the command servers. An example would be to hash the headline of the top story on yahoo.com. This way, there would be no way for botnet enemies to register the command servers in advance, since the information only manifests on the day that it is required. This minimizes the number of domains the botnet controllers need to register at any given time.

This approach has its flaws as well, but it shows a trend towards increasingly sophisticated and robust command channel designs that will likely provide challenges to defenders for years too come.

Personally I think that pure peer2peer botnet's are likely to be the future's most dangerous malware for a multitude of reasons, most of which are beyond the scope of this reply.

Such an interesting subject. Some brilliant minds on both side of the war.
Emoticon

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Lotusphere

LinkedIn

View Frank Paolino's profile on LinkedIn

Tags

Frank Paolino