These days botnets are all over the news. Often we hear them described in vague, ominous terms designed to grab people’s attention. In simple terms, a botnet is a group of computers networked together running a piece of malicious software that allows them to be controlled by a remote attacker, better known as a botmaster. Often I think people abuse their readers to a certain extent by over-hyping certain threats. I would like to take a more reasonable approach here.
Our team has a lab dedicated to running malicious software that we refer to as our malware lab. We use the lab to ensure our security products work against various real-world threats. Basically, we do things like intentionally leaving hosts un-patched behind security devices and purposefully infect and attack boxes protected by various devices. This helps to ensure that in a worst-case scenario we know our products work. To that end, I periodically track down new samples of malware. Recently, I came across a sample that could be used to create your own botnet.
I will explain exactly what this bot does; I’ll even show you some of the code. This is a very simple and generic example of a bot and is very likely no threat to your network. It’s designed as a kit to be distributed to inexperienced botmasters. It’s the Easy-Bake Oven of botnets, but the concepts I will cover extend to the most complex botnets.
This will be the first in a series of posts exploring a bot written in the Java programming language. Because the Java is easier to read than most, throughout this series we will explore the actual code for the more interesting features.
We will begin exploring this sample by first determining what type of file the botnet payload executable is. The vast majority are in portable executable (PE) format, the standard Windows executable file format. Since most of the good guys are fairly proficient at analyzing standard binaries these days, more often than not, malware authors encode or otherwise obfuscate a binary. Often they use what is known as a packer to try to make it more difficult to analyze. Every now and then we’ll find something slightly different.
The easiest way to determine most formats is to simply use the file command. The file command will parse the file and attempt to determine what type of file it is. The strings command is also fairly useful. This command extracts printable characters from a file and prints them as strings. Things like compression can obfuscate a file since the file’s contents are compacted. You can usually use strings to immediately tell if a file has been obfuscated. An obfuscated file usually does not have any strings consisting of words or sentences. In the real world, binary packers can be used as compression algorithms designed to shrink the size of a binary. When seen in malware, the design of a packer usually focuses on hampering reverse engineering. I usually find that packers either encode nearly all strings as non-printables or encode them as long strings of random characters. In unobfuscated files you will normally see quite a few printable strings consisting of words and sentences, although they may not always be in English. In this case, I started out with the strings command just to see what stood out.
Immediately I noticed that this was not in the standard PE format. Also, all of the the legible ascii strings are a good indicator that the file is not packed or otherwise encoded/encrypted.
The .class entries were a huge give-away; this was simply a Java archive (JAR) file. It’s not necessarily typical for a JAR file to contain all of the source code needed to compile the program, but in this case we got lucky. I had not come across a Java-based bot before so I decided to dissect it further. After extracting the files with a sample decompression program I was pleased to see the author even included a project file for an open-source development platform called Eclipse. I use virtual machines to do most of my analysis. Once I loaded Eclipse onto my virtual machine, the project file loaded all of the source code without any issues.
You can see here that the author does a very nice job of organizing his code to make it easy to follow. A quick glance at the various files gives you a pretty accurate picture of the botnet’s abilities. While in theory it is possible that a bot written in Java is capable of infecting and functioning on a variety of operating systems due to the nature of Java, at this time the bot is only capable of installing itself on Windows machines. It is possible that the author chose Java since some anti virus companies may not be able to properly parse Java byte code.
In the following posts in this series we will focus on several areas. First, we will explore the ways the botmaster controls his network of bots. We will also cover the different ways the botmaster updates and maintains his network of bots. Next we will discuss different types of denial of service (DoS) attacks, digging into the ones supported by our bot. We will then explore combining the actions of several bots to create an effective distributed denial of service attack (DDoS). And finally, we will dig into the features I find most impressive about this bot. These include features that in the past we’ve only seen in much more complex botnets like ozdok, conficker, or waledac.