The Three "M's" of Mirai: Money, Multiplication, and Mitigation

Image

21 October 2016 is a date that will live in infamy. At 11:10 UTC, internet performance management company Dyn began monitoring a distributed denial-of-service (DDoS) attack against its Domain Name System (DNS) infrastructure. It took Dyn approximately two hours to mitigate the attack. In that span of time, the DDoS campaign took down the websites for Twitter, Spotify, and several other of the company's customers. Dyn spent the next week working with security firms to investigate the attack. Among other things, it learned that 100,000 compromised Internet of Things (IoT) devices used masked TCP and UDP traffic over port 53 to attack Dyn's DNS infrastructure. Much of those requests originated from a Mirai botnet, the same malware behind a powerful DDoS attack which struck Brian Krebs website in late September. Mirai is not an altered sample of another malicious program. It's its own malware family, meaning it comes in many different variants. One version, known as "Peter Parker," emerged in late-November 2016. Unlike the variant that attacked Dyn, Peter Parker's Mirai targeted vulnerable implementations of TR-064/TR-069, a protocol used by ISPs to remotely manage customers' broadband routers. The malware variant didn't amass a large botnet of infected devices, but it did succeed in disconnecting 900,000 customers of the German ISP Telekom. Given the ongoing evolution of Mirai, service providers need to take steps to protect their customers against botnet-based attacks. They can do so by learning a little more about Mirai. Towards that end, let's examine the malware's three "m's": money, multiplication, and mitigation.

Money

The botnet based on the Peter Parker Mirai variant is a DDoS-for-hire service through which customers can rent portions of the botnet to launch their own DDoS attacks. It basically operates like a mobile virtual network operator (MVNO), or a wireless communications services provider that doesn't own wireless network infrastructure but instead works with a mobile network operator to provide customers with network access. Kirk Soluk and Roland Dobbins of Arbor Networks' ASERT team elaborate in a blog post on that analogy with respect to Mirai:

"…[T]he threat actors building and maintaining this Mirai botnet are the mobile network operators – they own the botnet infrastructure and provide other threat actors (the MVNOs in this analogy) with managed access to it. The 2nd-tier threat actors (MVNOs in this analogy), in turn, provide the DDoS-for-Hire service to end customers, setting their own rate structures and marketing it however they choose. In some cases they may refer to Mirai, in other cases they simply peddle what appears to be their own botnet."

Multiplication

Some readers might recall that the October Mirai variant, the source code of which is available online, propagated by performing brute force attacks using default login credentials over Telnet. It did so to compromise poorly secured IoT devices like DVRs and webcams. Peter's Parker Mirai doesn't follow that same mode to multiply across devices. Instead it abuses vulnerable implementations of the TR-064/TR-069 protocol, otherwise known as the CPE WAN Management Protocol (CWMP), to execute arbitrary code on routers. It does this by passing the code as a configuration parameter in a SOAP message over HTTP to port 7547. Once it's delivered to a router, the code executes Mirai's payload and downloads the malware, thereby enlisting the device into a botnet. Mirai can then command those bots to launch DDoS attacks against whichever target it chooses.

Mitigation

Organizations can take several steps to mitigate Peter Parker's Mirai. First, ISPs should scan their customers' networks for vulnerable routers. If they come across an affected device, they should either warn their customers about and/or replace them. Second, ISPs and cable modem network operators should implement best current practices to prevent malicious actors from gaining remote access to vulnerable devices. Finally, ISPs should rate-limit ARP and other relevant control-plane traffic to prevent vulnerable routers from disrupting service for their customers.