So I Made a Botnet…

This is one of those projects where I had the idea a long, long time ago and filed it away under the “wouldn’t it be cool if I could…” section of my brain. As I slowly plug away at reading and watching everything I can get my hands on in relation to information security, programming and networking, some of these ideas start to percolate into real tangible projects.

Once they start to form, they become subject to being broken down into small actionable items. Rather like a feature turns from an idea in a Product Owner’s mind, is translated into a user story by being written down, and is groomed, discussed, broken down and finally developed; the same occurs subconsciously for things in the “wouldn’t it be cool if I could…” bucket of my brain.

Sometimes it takes a long time for it to get changed from the “wouldn’t it be cool if I could…” to the “I might actually be able to…” compartment, and it’s usually not at all in relation to learning a particular morsel of knowledge, more an evolution of the way I think about problems.

In fact this specific project first came to mind reading an article about DDOS attacks and cyber-crime. Specifically that there were hundreds of such botnets around the world, under the control of criminals, and used for nefarious purposes. Mine will  be none of the above.

So what is a botnet?

Well as the portmanteau of a name suggests, it is a literal network of bots. Generally there will be somewhere between hundreds to millions of bots on a botnet, or ‘slaves’ with one ‘master’ controlling them. The Master tells the Slaves to perform an action, which they do so, in droves.

This is the point of a botnet, to perform multiple actions automatically, where automation of a single computer can be far outstripped by automating thousands of others. Spam emails are harder to trace, block and otherwise prevent if they are sent from millions of IP addresses as opposed to one big obvious spamming IP.

So our acceptance criteria is going to use this vague definition as the basis. We want to be able to input commands or data on one computer, and have several other computers perform that command.

We are also going to make this a Minimal Viable Product (MVP), which means that we will have the most basic feature set. There will be no GUI, there will be bugs, there will be almost zero features. It will be a proof of concept. Maybe in the future we will extend the botnet. The most advanced botnets have update channels for their Masters to introduce new features, evade detection better etc. So, onto our basic structure.

Command and Control (C&C) can be handled in a variety of ways, from old school  channels of communication like IRC, to more modern methods involving looking up domains from a list of thousands to receive instructions. We are going to use the least elegant, but quickest and most functional version of C&C. We are going to connect to the slaves using sockets.

Python provides pretty simple methods for working with sockets, so we are going to essentially program the following.


  1. Create a socket
  2. Ask for a command
  3. Send the command


  1. Bind to a socket (listen)
  2. Listen for commands
  3. Perform the command

The command we can perform can be something pretty normal, like visiting a website. I have  recently been attempting to automate some web testing (checking) with a Python library called splinter. It is based on Selenium Webdriver and is pretty easy to use. We can use that the skeleton of the “Perform a command” section.

The roles of Masters and Slaves can be fulfilled by virtual machines. In fact the Master role can be taken by the PC we do the development on, and a tailored image can be used for the Slaves. I created a standard Ubuntu 14.04 install, and removed around 50% of the software on it. We will pretty much only need networking, python and a web browser.

Virtual Box also allows us to clone VM’s, so I made 4 copies of the initial VM. I also set their IP’s to be static, and put them all on a virtual network in the range. This way we can use a list containing the IP’s without worrying about finding them.

The code for the Master looked like this.

We make a short list of IP addresses, and ask the user for input which should be the url to visit.

A short for loop will iterate through each of the IP’s in the list and create the socket connection to each, and send the data. We close each socket after we are done with it as a form of housekeeping.

Next, let’s take a look at the Slave code.

Here we are creating a socket to listen for incoming connections. It will listen indefinitely, until either the process is killed, or the socket is created, receives data, and is closed by the server. Once the socket is created, we listen out for data, and whenever we receive it, we use the splinter Browser object to visit that url.

In testing this, of course it didn’t work. In fact there was, for hours, nothing I could do to figure it out. I could get the code to run on one VM, but never on more than one. If I had more than one concurrent machine listening, it just would not respond. In fact it would randomly choose a machine to fail on and give me an error message.

After a while I resorted to the tried and tested debugging methodology of “print all the things you are doing” and then working backwards. The fix, was in hindsight, obvious.

After cloning all the VM’s I changed their static IP’s so they would all be, in iterations of 10. I never restarted the networking service though, so they all thought they were Some quick rebooting of the VM’s led to the screenshot below.1

Hitting enter, and a brief period of holding my breath led to this!


Huge success!

I had set up my Kali VM on the same virtual network, and slightly edited the standard web page presented when connecting to it. As you can see, all the Slaves visited the page. The MVP is complete!

Now the point of an MVP is just a  proof of concept, in order to get people on board with the idea, let it gain traction, and then iterate, iterate and iterate some more. In fact in his excellent book The Lean Startup, Eric Ries talks about the importance of iterating on an MVP.

He talks specifically about the Build, Measure, Learn feedback loop, which is where you Build your MVP, or product, or whatever it is you are making. Measure the effect of the product you have created.

Google Analytics is excellent for doing this with web pages. If you are making a physical item, it is imperative you talk to your customers about it. Show it to them, make them hold it. Let them tear it apart, tell you what is wrong with it, tell you what is the best thing about it.

It is super important to choose useful and enlightening metrics to measure too. Use A/B testing to find out what is the best option. Then throw out the badly performing one. That is probably the most difficult part of A/B testing, as when we build things, we really want to see them out in the wild, working and making things better, but if it is not performing well, you have to kill it.

Then comes the hard part. Learn. This is the part where you go back to the drawing board, and come up with a new iteration to try out. At this point you are back where you started. The quicker you can go through this Build, Measure, Learn feedback loop, the more refined and better the product you make will be.

With all this in mind, what kind of iterations should we make for our Botnet? Probably the ability to do more than simply visit a web page. Going to a web page to perform an action is probably a good start (Reddit/Imgur upvote bot anyone?).

We might also want to send it commands to perform on the file system. We could achieve that by packaging the ‘os’ module from Python. Maybe we want to configure it to send emails using SMTP, and become a spambot.

But these things are for another day. I hope that this shorter post has been helpful or informative. Also you should read The Lean Startup, its a really fantastic book even if you aren’t an entrepreneur (I am certainly not) which seems to be it’s target audience. It is hugely useful to anyone wishing to effect change in their organisation, and move themselves towards higher agility and flexibility in product design. That probably covers 80% of the people reading this.

If you would like to avoid becoming part of a botnet yourself, there are a couple of things you can do.

  1. Don’t click on every link you see.
  2. Install Avast (just the Anti Virus) and EMET
  3. Avoid visiting dodgy websites, even in incognito mode 😉

These won’t completely protect you, but they will guard against a lot. I hope you have an awesome week!

Leave a Reply

Your email address will not be published. Required fields are marked *