1. MIRAI

2. In September 2016, a spree of massive distributed denial-of-service (DDoS) attacks temporarily crippled Krebs on Security, OVH, and Dyn.
attack on Krebs exceeded 600 Gbps in volume -> 105 compromised devices
Success factors:
efficient spreading based on Internet-wide scanning,
rampant use of insecure default passwords in IoT products, and
keeping the botnet’s behavior simple would allow it to infect many heterogeneous devices
the botnet infected nearly 65,000 IoT devices in its first 20 hours before reaching a steady state population of 200,000–300,000 infections
These bots fell into a narrow band of geographic regions and autonomous systems, with Brazil, Columbia, and Vietnam disproportionately accounting for 41.5% of infections.

3. MIRAI timeline

4. MIRAI operation
Rapid scanning: TCP SYN probes to pseudorandom IPv4 addresses, excluding those in a hard-coded IP blacklist, on Telnet TCP ports 23 and (hereafter denoted TCP/23 and TCP/2323)
brute-force login: try to establish a Telnet connection using 10 username and password pairs selected randomly from a pre-configured list of 62 credentials.
first successful login: Mirai sent the victim IP and associated credentials to a hardcoded report server (­).

5. MIRAI operation
A separate loader program asynchronously infected these vulnerable devices by logging in, determining the underlying system environment, and finally, downloading and executing architecture-specific malware.
Mirai attempted to conceal its presence by deleting the downloaded binary and obfuscating its process name in a pseudorandom alphanumeric string
Mirai infections did not persist across system reboots
to fortify itself the malware additionally killed other processes bound to TCP/22 or TCP/23, as well as processes associated with competing infections, including other Mirai variants, anime, and Qbot.
listened for attack commands from the command and control server (C2) while simultaneously scanning for new victims.

6. wget or tftp to install binaries
logged 80K connection attempts from 54K IP addresses between November 2, 2016 and February 28, 2017, collecting a total 151 unique binaries.
collected 1,028 unique Mirai samples
identified 67 C2 domains and 48 distinct username/password dictionaries (containing a total 371 unique passwords).
collected approximately 209 million resource records (RRs)—queried domain name, and associated RDATA— and their lookup volumes aggregated on a daily basis.
obtained 290 million RRs per day from Thales, an active DNS monitoring system. Both datasets cover the period of August 1, 2016 to February 28, 2017.
Observed 64K attack commands issued by 484 unique C2 servers (by IP address)
individual C2 servers often repeat the same attack command in rapid succession, and multiple distinct C2 servers frequently issued the same command.

8. Bootstrap scan lasted approximately two hours (01:42–03:59 UTC), and about 40 minutes later (04:37 UTC) the Mirai botnet emerged. Within the first minute, 834 devices began scanning, and 11K hosts were infected within the first 10 minutes.
Within 20 hours, Mirai infected 64,500 devices.
Mirai’s initial 75-minute doubling time is outstripped by other worms such as Code Red (37-minute doubling time) and Blaster (9-minute doubling time).
Mirai’s comparatively modest initial growth may be due to the low bandwidth and computational resources of infected devices, a consequence of the low-accuracy, brute-force login using a small number of credentials, or simply attributable to a bottleneck in loader infrastructure.

10. observed a total 371 unique passwords, and through manual inspection, we identified 84 devices and/or vendors associated with these passwords

12. the majority of bots scanned at an estimated rate below 250 bytes per second.
this is a strict underestimate, as Mirai may have interrupted scanning to process C2 commands and to conduct brute force login attempts.
In contrast, SQL Slammer scanned at 1.5 megabytes/second, about times faster, and the Witty worm scanned even faster at 3 megabytes/second.
This additionally hints that Mirai was primarily powered by devices with limited computational capacity and/or located in regions with low bandwidth.

14. Purposes of MIRAI
Locate and compromise IoT devices to further grow the botnet.
Launch DDoS attacks based on instructions received from a remote C&C.
Mirai uses a brute force technique for guessing passwords a.k.a. dictionary attacks based on the following list:
Code/blob/master/mirai/bot/scanner.c

15. For network layer assaults, Mirai is capable of launching GRE IP and GRE ETH floods, as well as SYN and ACK floods, STOMP (Simple Text Oriented Message Protocol) floods, DNS floods and UDP flood attacks.

16. GRE: Generic Routing Encapsulation
a tunelling protocol developed by CISCO System that can encapsulate a variety of network layer protocols
Providing workarounds for networks with limited hops
Being less resource demanding than its alternatives (Ipsec, VPN)
GRE IP/ETH flood utilizes GRE tunnel messages to flood the victim site

17. Mirai also seems to possess some bypass capabilities, which allows it to circumvent security solutions:
#define TABLE_ATK_DOSARREST // "server: dosarrest"
#define TABLE_ATK_CLOUDFLARE_NGINX // "server: cloudflare-nginx"
if (util_stristr(generic_memes, ret, table_retrieve_val(TABLE_ATK_CLOUDFLARE_NGINX, NULL)) != -1)
conn->protection_type = HTTP_PROT_CLOUDFLARE;
if (util_stristr(generic_memes, ret, table_retrieve_val(TABLE_ATK_DOSARREST, NULL)) != - 1)
conn->protection_type = HTTP_PROT_DOSARREST;

18. Mirai’s “Don’t Mess With” List
One of the most interesting things revealed by the code was a hardcoded list of IPs Mirai bots are programmed to avoid when performing their IP scans.
This list, which you can find below, includes the US Postal Service, the Department of Defense, the Internet Assigned Numbers Authority (IANA) and IP ranges belonging to Hewlett-Packard and General Electric.

19. Territorial Predator
Another interesting thing about Mirai is its “territorial” nature. The malware holds several killer scripts meant to eradicate other worms and Trojans, as well as prohibiting remote connection attempts of the hijacked device.
For example, the following scripts close all processes that use SSH, Telnet and HTTP ports:
killer_kill_by_port(htons(23)) // Kill telnet service
killer_kill_by_port(htons(22)) // Kill SSH service
killer_kill_by_port(htons(80)) // Kill HTTP service

20. and this function searches and destroys the Anime malware—a “competing” piece of software, which is also used to compromise IoT devices:
searching for .anime process
table_unlock_val(TABLE_KILLER_ANIME);
// If path contains ".anime" kill.
if (util_stristr(realpath, rp_len - 1, table_retrieve_val(TABLE_KILLER_ANIME, NULL)) != -1) {
unlink(realpath);
kill(pid, 9); }
table_lock_val(TABLE_KILLER_ANIME);

21. The purpose of this aggressive behavior is to:
Help Mirai maximize the attack potential of the botnet devices.
Prevent similar removal attempts from other malware.

22. Lastly, it’s worth noting that Mirai code holds traces of Russian-language strings despite its English C&C interface. Here, for instance, Russian is used to describe the “username” and “password” login fields:
// Get username
this.conn.SetDeadline(time.Now().Add(60 * time.Second))
this.conn.Write([]byte("\033[34;1mпользователь\033[33;3m: \033[0m"))
// Get password
this.conn.Write([]byte("\033[34;1mпароль\033[33;3m: \033[0m"))
This opens the door for speculation about the code’s origin, serving as a clue that Mirai was developed by Russian hackers or—at least—a group of hackers, some of whom were of Russian origin.
Other bits of code, which contain Rick Rolls’ jokes next to Russian strings saying “я люблю куриные наггетсы” which translates to “I love chicken nuggets” provide yet more evidence of the Russian heritage of the code authors, as well as their age demographic.

23. Admin
There is an administrative login and supported functionality via admin.go This is the primary admin interface for issues controls to execute against the botnet (e.g. create an admin user, initiate an attack, etc.).
From here the user must provide the appropriate credentials (username & password), which are validated against a MySQL DBMS via database.go
Once successfully authenticated the server gives the allusion that it hides the hijacked connection from netstat and remove any traces of access on the machine (e.g. environment variables previously set). It prints to STDOUT that it’s executing such trace removal, but in reality it does nothing.
Next the admin panel will provide an updated count of the total number of bots connected and wait for command input such as attack type, duration length and number of bots. This is the primary interface for issuing attack commands to the botnet.

24. The clientList.go contains all associated data to execute an attack including a map/hashtable of all the bots allocated for this given attack. The code is responsible for maintaining multiple queues depending on the bot’s state of execution (e.g. ready for attack, attacking, delete/finished current attack.
attack.go is responsible for handling the attack request initiated by the CNC server. It parses the shell command provided via the Admin interface, formats & builds the command(s), parses the target(s), which can be comma delimited list of targets, and sends the command down to the appropriate bots via api.go
Interesting point is that the allowed threshold duration that a per attack per bot can execute on (minimum of 1 second to maximum of 60 minutes).

25. The api.go is responsible for sending the command(s) to an individual bot from the CNC server.
It does enforce some rules/bounds checking. For example, CNC users are allocated N number of maximum bots they can utilized in a given attack. Unless you’re an administrator you’re bound to a limit on the number of bots you are allocated.
Additionally, it will check whether or not the given target has been whitelisted within the database.
Lastly, the logic will verify the bots state. If the bot is already in use it will be removed/ignored from the attack request.

26. main. go is the entry point into the CNC server’s binary
main.go is the entry point into the CNC server’s binary. It listens for incoming TCP connections on port 23 (telnet) and 101 (api bot responses). If a connection is received on the API port it is handled accordingly within api.go.
Meanwhile if a telnet connection is established the source/incoming IP address is acquired added as a newly compromised machine to the botnet (clientList).

27. The bots support a few different forms of attack over the User Datagram Protocol (UDP). The source code attack_udp.c implements the following attacks to be carried out by an unsuspected IoT (bot) device:
Generic Routing Encapsulation (GRE) Attack
TSource Query — Reflective Denial of Service (bandwidth amplification)
DNS Flood via Query of type A record (map hostname to IP address)
Flooding of random bytes via plain packets

28. As with UDP there are several attack types supported via the Transmission Control Protocol (TCP) within attack_tcp.c
SYN Flood
ACK Flood
PSH Flood

29. In addition to the malformed and/or UDP or TCP packet floods, Mirai bots also support DoS over HTTP within the attack_app.c
Once a connection is successfully established (keep-alive is supported) the bot will send an HTTP GET or POST consisting of numerous cookies and random payload data when applicable (e.g. POST). Numerous valid user-agents are utilized to masquerade the requests as valid clients. As long as the connection is held (receives valid response) the target endpoint is continually flooded with HTTP requests originated from the bot.

30. In addition to the attacks the bots will also do brute force scanning of IP addresses via scanner.c in search of other devices to acquire within the botnet. The bot looks for any available IP address (brute force via select set of IP ranges) and apply a port scan (SYN scan) against it.
If the bot is able to successfully connect to an IP and open port then it will attempt to authenticate by running through a dictionary of known credentials (brute force authN) or check if it’s able to connect directly via telnet. If authentication or telnet session negotiation succeeds the bot will then attempt to enable the system’s shell/sh and drop into the shell (if needed and not already in shell).
Once the shell access is established the bot will verify its login to the recently acquired device. If it is verified and working telnet session the information is reported back (victim IP address, port, and authentication credentials) to the command and control server. The CNC server’s domain defaults to cnc.chageme.com The CNC server has a corpus of available machines that it can now successfully control as it sees fit by pushing down the bot binary and executing the appropriate attack command.

31. The killer.c provides functionality to kill various processes running on the bot (e.g. telnet, ssh, etc.).
main.c is the entry point into the bot’s executable. It is responsible for establishing a connection back to the CNC server, initiating attacks, killing procs, and scanning for additional devices in hopes of commandeering them within the botnet.