Mirai: A Botnet of Things
In mid-September the journalist Brian Krebs, of krebsonsecurity.com fame, had his website taken down by one of the largest DDoS attacks ever observed. The attack clocked in at over 600Gbps, removing the website from the Internet for multiple days. Krebs, who is famous for shining a light in some of the darker areas of the Internet, had his pro-bono DDoS protection canceled by Akamai, and quickly moved over to Google for hosting protection. In the subsequent weeks, the details of the DDoS attack emerged, confirming many predictions that have been made during the last few years: poor security practices in “Internet of Things” (IoT) devices are making them easy targets for hackers to leverage for a variety of uses.
The botnet that took down Krebs’ site has been attributed to the Mirai botnet. A couple indicators provide confirmation that this is most likely the case: A spike in telnet scanning days before, the source code of Mirai getting deliberately leaked, and attacks options within that botnet that match the experiences described by Brian Krebs (notably getting attacked with a crafted GRE flood). It seems that Mirai is probably here to stay, even if most of the original CnC servers have been taken offline. Its mechanism of spreading is simply to scan the Internet at large, brute force any telnet connection it finds, and then force the target to load a crafted binary to maintain control. On execution, the process deletes itself from disk, renames itself in memory, and then connects to the hardcoded CnC server via hostname lookup. It then repeats itself all over again, turning the victim into a newly minted attacker, scanning the Internet for more telnet ports and waiting for DDoS commands to launch.
At ATI, our interest is in replicating the DDoS attacks and the CnC intercommunication protocol. Today I’ll take you through the CnC protocol, but first a word of caution: While the code does compile cleanly and doesn’t appear to have any booby traps, it is built for speed of compromise and can easily flood your network and start re-infecting machines. If you are going to run it in your own lab, first make sure that it’s dead ended in your network or you might find yourself as an unwilling member of someone’s Threat Intelligence Feed.
We found Mirai uses a simple protocol used for launching attacks and tracking bots under control. The CnC server is written in Go, which provides easy multi-threading, C-like syntax, and built-in memory management. Considering that the botnet author stated that Mirai regularly collected 300,000 peers, these features of Go are understandably welcome. The Bot code itself is simple ANSI C, and cross-compiles across 18 different architectures without problem, including MIPS, ARM, and x86.
The server listens on two ports: 23 and 101. Port 23 does double duty as both a botnet control channel as well as an interactive operator administration console using telnet. Port 101 supports an API for management.
When a bot connects to the CnC, it sends the sequence \x00\x00\x00\x01. The first 3 bytes are a basic preamble; the fourth byte indicates the presence of a name (which is passed as a command-line argument to the bot when initially executed). The bot then sends another packet to the CnC specifying the length of the name followed by the bot’s name. While the server seems capable of handling the case of no name present, the bot will always specify that a name is present and then pass a null byte. Thus, if no name is specified on the CLI calling the bot, the bot sends the sequence in frame1: \x00\x00\x00\x01 and in frame2: \x00.
The bot and CnC then send heartbeat packets back and forth to each other every sixty seconds, beginning 10 seconds after establishing a connection. The heartbeat is simply the byte sequence \x00\x00 from bot to server followed by \x00\x00 from server to bot. Both parties wait like this until an attack command is sent down.
When an attack instruction is sent down to the bot, it uses a basic TLV structure to describe the commands that are needed. The attacks are hardcoded with a lookup table on both the CnC and bot code. The first section describes duration, type, and target listing:
Followed by an options list of parameters to send the specific DDoS Attack:
Below is an example of sending some of those commands. We’ve color-coded the messaging so you can see how it lines up. What is puzzling is the decision to binary pack some data and use string values for others. An example capture showing these commands is located on our github account. Don’t worry, we didn’t actually target Krebs’ site.
Armed with this knowledge, ATI has produced a new application flow and Superflow to represent this command and control traffic. Hopefully, using that knowledge and what we’ve presented here, you’ll be able to either import or create some of your own IPS signatures to detect this activity on your network, as well as test your security devices’ signatures. Next blog post we’ll also look at some of the DDoS attacks that can be generated, and what might flag the traffic as potentially originating from a botnet.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.