MIRAI In September 2016 a spree of massive
MIRAI
• In September 2016, a spree of massive distributed denial of service (DDo. S) 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 Io. T products, and • keeping the botnet’s behavior simple would allow it to infect many heterogeneous devices • the botnet infected nearly 65, 000 Io. T 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.
MIRAI timeline
MIRAI operation • Rapid scanning: TCP SYN probes to pseudorandom IPv 4 addresses, excluding those in a hard coded IP blacklist, on Telnet TCP ports 23 and 2323 (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 ( ).
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 control server (C 2) while simultaneously scanning for new victims.
• wget or tftp to install binaries • logged 80 K connection attempts from 54 K IP addresses between November 2, 2016 and February 28, 2017, collecting a total 151 unique binaries. • collected 1, 028 unique Mirai samples • identified 67 C 2 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 64 K attack commands issued by 484 unique C 2 servers (by IP address) • individual C 2 servers often repeat the same attack command in rapid succession, and multiple distinct C 2 servers frequently issued the same command.
• 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 11 K 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.
• observed a total 371 unique passwords, and through manual inspection, we identified 84 devices and/or vendors associated with these passwords
• 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 C 2 commands and to conduct brute force login attempts. • In contrast, SQL Slammer scanned at 1. 5 megabytes/second, about 6000 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.
Purposes of MIRAI 1. Locate and compromise Io. T devices to further grow the botnet. 2. Launch DDo. S 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: • https: //github. com/jgamblin/Mirai Source Code/blob/master/mirai/bot/scanner. c
• 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.
• 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
• Mirai also seems to possess some bypass capabilities, which allows it to circumvent security solutions: #define TABLE_ATK_DOSARREST #define TABLE_ATK_CLOUDFLARE_NGINX 45 // "server: dosarrest" 46 // "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;
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.
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
• and this function searches and destroys the Anime malware—a “competing” piece of software, which is also used to compromise Io. T 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);
• 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.
• 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. Set. Deadline(time. Now(). Add(60 * time. Second)) this. conn. Write([]byte("