Botnets cover a wide range of application domains, and one of the more common ones is distributed denial of service. I try to avoid covering DDoS-oriented botnets since others are often larger threats to the public, but at a certain scale of infection, anything that can update or download other malware is a serious threat.
Madness Pro is a distributed denial of service botnet growing in size and popularity. It infects computers running Windows with a PE bot, and communicates with its command and control server via HTTP using a simple client-server model. It does not demonstrate the resilience of P2P botnets. After a somewhat dated version was leaked, there was an increase in the number and size of these botnets and it caught my attention.
On execution, the bot will copy itself to %APPDATA%\<bot id>\svchost.exe then use CACLS to make it so the current user can no longer write to the file. It also stores its original location in the registry temporarily then executes the new version and exits.
Once executed from its new location, it gathers the original location from the registry and deletes the original file. After this, it attempts to add itself to the Windows Firewall policy as an allowed application. In the temporary directory, it creates files named "per", "perper", "perperper" and "perperperper". These list registry locations where it attempts to install means of persistence. Afterwards, it starts its loop of checking the command and control server. The communication protocol and commands will be covered later. For more specific information about the bot's general execution, you can check out the analysis provided by Malwr.com here.
Many botnets that are sold by the developers on a per use basis are distributed with utilities called "builders". Instead of supplying the bot source code, they supply building applications that modify a stock binary and overwrite the configuration with values supplied to the builder. This allows for the malware developers to protect their investment and obscure/encrypt/hide the configuration. Builders can also be developed by other malicious agents looking to pirate the malware. In this case, the configuration is stored in various strings in the application, encoded with base64 that has been tampered with to not appear to be base64. This tampering is done with a simple substitution.
^ <=> j
@ <=> H
* <=> d
Once these substitutions are applied to strings found in the bot PEs, they can be base64 decoded and parsed for configuration information. Depending on the version, there can be differences in the configuration format. The command and control definition format changed between version 1.13 and 1.14.
The difference in the format is essentially tripling each character being written into the configuration. From these configuration strings we can get our needed information to access the command and control server as a bot. The URI of the panel and the "mk" GET parameter are what we need for any panel past version 1.14. A proof of concept of extracting configuration data statically can be found here.
The following is a very loose Yara rule which has been effective at detecting the bot binary, even when packed with ASPack.
author = "@botnet_hunter"
date = "2014-03-13"
description = "Identify Madness Pro"
$c = "YXBvS0FMaXBsaXM9"
$str5 = "d3Rm" fullword
$str6 = "ZXhl" fullword
all of them
There appears to be a learning curve for signature based detection when it comes to detecting the bot PEs. There is a trend of new versions appearing, but only being detected by a few engines at first. With mathematical model-based detection, we do not have those types of delays. With Infinity-based products, detecting these bots is a cinch, as our lowest detection confidence is 98% across all Madness Pro samples.
Here we can see CylanceV making no mistake about detecting these as malware across the board.
Command and Control Communications
These bots calls back to the index.php file in the root of the command and control panel. It only uses HTTP GET requests with a fairly easy to identify set of parameters. In the following example, the command and control panel is in the root of the web server.
GET /?uid=88037690&ver=1.14&mk=bb3b62&os=WinXP&rs=adm&c=1&rq=0 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; m18) Gecko/20010131 Netscape6/6.01
If all the parameters are accepted, the command and control panel responds with a 200 HTTP response code and base64 encoded commands in the response body. In some early versions of the panel, there was no validity checking on the parameters. After a few versions, a mandatory 'mk' parameter containing six characters in the hex range was introduced to restrict access to the command and control server. It is likely more request filters will be implemented to make monitoring these botnets more difficult.
The commands for the bots are mostly for distributed denial of service attacks, but not exclusively. Most commands can have a parameter, which is separated by the original command by an equals sign. Below are the commands gathered from version 1.19.
cfa - Opens iexplore.exe to supplied parameter, then over a span of 15 seconds, attempts to hide the window, but never closes it (speculating this stands for "click for affiliate")
cmd - Calls the command parsing function on the supplied parameter (nested commands)
exe - Downloads and executes exe from supplied parameter
upd - Self updater from supplied URL
wtf - Idle command
def - Causes the bot to self terminate but not uninstall
ds1 - Simple HTTP GET flood with WinSock
dd1 - HTTP GET flood with WinSock and configurable User-Agent, Cookie and Referer
dd2 - HTTP POST flood with WinSock
dd3 - HTTP GET flood with InternetOpenUrlA
dd4 - HTTP POST flood with HttpOpenRequestA
dd5 - ICMP flood with raw WinSock
dd6 - UDP flood with WinSock
dd7 - HTTP GET flood with URLDownloadToFileA
dc1 - HTTP GET flood similar to dd1 but applies received cookie to following requests
As part of the Cuckoo Sandbox project, the developers created a Cuckoo module type called "Signatures". These are great for gathering somewhat abstract information from the report and identifying behavior with a signature. One of the public signature modules is for detecting these bots' command and control communications. It can be found here and is a great addition to the Cuckoo Sandbox project. It should be noted that these communications will only be detected if the bot is able to connect to anything it believes is the command and control server, and will not appear if the virtual machine is running completely isolated.
The panel has a more appealing design than others, and has a few tactics implemented to remain hidden. If the root of the bot panel is accessed without the correct request parameters (if the request is not done as a bot would connect), the following page is presented.
It is likely this page has been stolen from a legitimate host (intellectdesign.ru appears to be a valid Russian web hosting provider). The text translates to the following:
Site is disabled. Perhaps this is due to non-payment of bills for hosting.
Contact Technical Support by phone: (495) 542-39-84 or e-mail: firstname.lastname@example.org
The botnet administration login page of the version I acquired looks like the following:
Once we login, we can see a traditional panel with basic functionality of bulk or individual commands being set.
There are a few options for selecting different bots and putting commands on timers. If we add our own fake bot, we can see it added to the bottom.
This is by far not the most dangerous or advanced botnet out there, but these botnets are commonly over 1,000 nodes. This botnet is capable of dropping other malware as well as a wide range of denial of service attacks. This malware is not hard to identify, but only about half of conventional AV engines are detecting new versions.
0948f69e0d7567dac5d7225d547d71ee (first seen on 2014-04-07) (ASPack)
495e8b08575e0ae51a9108d32f2e0066 (first seen on 2014-04-11)
40aecbf8cb8cda3869bfa0334301d463 (first seen on 2014-04-13)