Madness DDoS Bot Analysis
“Madness” is a Denial of Service bot targeting Windows machines. While it constantly evolves its capabilities, it certainly represents the progress attackers made in Layer 7 DDoS expertise. The bot author proudly states that “Madness” is the superior successor and an actual hybrid of the notorious DDoS malware families “BlackEnergy”, “gbot”, “DirtJumper”, “Darkness Optima”, “iBot” and “w3Bot”. Its phone-home architecture is based on polling the C&C server. Once a minute it sends a probe to its operator with information on the infected machine (OS and level of privileges) and the number of attack payloads successfully sent, while the C&C will respond with the current attacking command (base64 encoded). DDoS Capabilities Madness DDoS capabilities consist of network floods, such as UDP and ICMP, however the more interesting part is its diversity of HTTP (Layer 7) floods. We can separate its HTTP floods to those using "low-level" libraries such as Windows Sockets API and those using more "high-level" libraries such as “WinInet” and “Urlmon”, which are also used by “Internet Explorer”. All the floods support up to 10 different URLs which might be used to attack different servers or different URLs on the same server. Going "low-level" lets the attacker make the flood much faster, and not less importantly gives him the flexibility in constructing the HTTP request from head to toe to bypass many DDoS protections. The added value of using "high-level" HTTP libraries is that they automatically handle all HTTP protocol aspects such as request construction, managing TCPconnections, caching, cookies and redirections. Those attacks support both simple "GET" requests and more complex "POST" requests with the ability tocontrol the data being sent in the POST body. While analyzing the threat, we have also noticed a very strange version of a SLOW GET attack, which rather may be called a "HOLD" flood attack. It sends a “GET” request containing only the “Host” header, sleeps for 0.1 second and only then completes the request by sending "\r\n". Bypassing Challenges Another aspect indicating a progress in attackers DDoS capabilities is having built-in techniques for bypassing anti-bot challenges. It starts with a simple “Anti-Cookie” feature for bypassing simple challenges, while mainly relying on parsing the response and responding appropriately in order to resemble a real browser. It appends cookies issued by the server either by the “Set-Cookie” response header or a JavaScript containing “document.cookie=” code. It also parses a specific JavaScript challenge issued by a well-known Russian web-hosting service. The challenge is obfuscated JavaScript which sets a cookie once executed. The bot looks for the strings "Cookie", "realauth=<value>" and "location" in the response and sets the appropriate cookie as a legitimate browser which renders JavaScript would do. However, the highlight is “Madness” ability to bypass more complex JavaScript challenges, specifically targeting “Cloud Flare”, a popular DDoS protection service. The challenge is JavaScript code which makes a certain calculation and sends back the result. If the result is correct, the server will issue an authorization cookie and all the following requests contacting that cookie will be considered legitimate. Instead of trying to simulate a browser, “Madness” author chooses to use a real browser. Once the attacker issues the “cfa” (apparently “Cloud Flare Attack”) command from the C&C, the victim machine runs an Internet Explorer in minimized window, browse the targeted website, performs the JavaScript challenge calculation, as it is a legitimate browser, and gets the authorization cookie. Once the cookie is saved in the browser, the attacker executes one of the “high-level” HTTP floods, specifically the one that uses the “Urlmon” library which is also used by Internet Explorer’s core, automatically appending the authorization cookie to each attacking request. Summary As layer 7 DDoS attacks are being effective, “Madness” provides different flavors of GET/POST floods with a high level of flexibility while integrating more advanced capabilities to bypass security solutions. We expect this bot to be seen more in the wild with upgraded capabilities. One of the lessons we learn from this analysis while protecting our servers is that it is not enough relying on clients simply answering the challenge, as complex as it might be. It also requires a proactive bot defense which has more integrity checks and implements more sophisticated logic around those challenges, as well as other prevention means such as rate limiting, CAPTCHA and behavioral anomaly detection.
Threat Analysis: perlb0t
This ancient bot, also known as the “Mambo” bot (due to an old vulnerability in the Mambo CMS it tried to exploit) has been around for a very long time, and many variations of it has been seen. However, from our observations, it is still being actively used in recent exploitations. After successfully exploiting an existing vulnerability on an unpatched webserver, a malicious Perl-based script is executed and turns the webserver into a member of a botnet. The names of the variables and functions in the code reveal that the bot author is likely a Portuguese speaker. Examples are words such as “servidor” (server), “conectar” (connect) and “pacotes” (packets). Like every “good” bot, perlb0t supports several functionality, such as port scanning, using Google search to find other vulnerable servers (also known as “Google Dorking”), running shell commands on the server and more. However, it seems that the main business model of this bot is a DDoS service. The bot supports HTTP and TCP floods, by sending “GET” requests or just opening (3-way handshake) and closing TCP connections respectively. But the most interesting DDoS functionality in this bot is the “UDP flood”, as its author calls it. At first glance it seems like the author is trying to create specific floods (ICMP, UDP, IGMP, TCP), however when further analyzing, this functionality is no more than just sending malformed packets of different protocols. Let’s look at this one… The C&C (Command&Control) instructs its bots to perform a “UDP flood” with 3 parameters: 1. Target (IP/Domain) 2. Packet size (in Kbytes) 3. Duration (in seconds) As we see from the source code, the bot uses raw sockets for the three types of packets, with different protocol numbers as the third argument, and one datagram socket for simple UDP. Using a raw socket enables the attacker to control more fields in the packet itself, however the bot writer needs to manually construct all the protocol headers. By looking at the table of supported IP protocols, we see that the bot creates raw packets of IGMP, ICMP and TCP protocols. Those packets are just being marked with those protocol numbers, however other fields and headers are not actually set. The packet is filled with “A” characters according to the size specified by the C&C command, making the packet a malformed one. However, even more interesting is the distinction the bot writer makes between the above protocols and other protocols the writer uses afterward. After sending malformed IGMP, UDP, ICMP and TCP packets, the bot will send 252 additional malformed packets of all other protocols (running from 3 to 255 protocol numbers, skipping previously sent protocols). The above screenshot displays a single loop in the attack, while each loop uses a different source port sequentially (running from 1 to 65000). Note the inaccuracy; the bot writer must have meant to run over all the 65k ports, which is 65,536. As we see from the bot’s traffic, a sequence of malformed packets is sent (the only well-formed is UDP), while the protocol number is sequentially incremented. (In the screenshot, this is shown as: 0xc, 0xd, 0xe, 0xf, 0x10…) It is important to note, that creating raw sockets needs administrative privileges, so if the infected webserver does not run as the root user, the attack will be a simple UDP flood. Note the destination port sequence. To sum up, a lot of attackers are lazy. They will do the minimum required to make their money suggesting DDoS services. As we learn from this example, an ancient bot first detected back around 2005 is still in the wild. Having the same basic structure, with edited nuances and sometimes functionality, it still spreads by exploiting recently discovered web vulnerabilities, making your web server part of a botnet.