Mirai is a piece of malware designed to hijack busybox systems (commonly used on IoT devices) in order to perform DDoS attacks, it’s also the bot used in the 620 Gbps DDoS attack on Brian Kreb’s blog and the 1.1 Tbps attack on OVH a few days later. Although Mirai isn’t even close to the biggest botnet ever, it is said to be responsible for the largest DDoS attack recorded, so we’ll have a look into the hows and whys.

What is IoT?

IoT stands for Internet of Things, essentially it’s a phrase used to describe the new generation of “smart” internet connected devices (fridges, toasters, CCTV). Although a lot of IoT devices don’t need to, and most definitely shouldn’t, be connected to the internet, user insist on putting them online without changing the default password provided by the manufacture making them easy pickings for hacker.

IoT in all its glory – Source @InternetOfShit

Mirai Mirai on the Wall, who’s the least secure of them all?

Mirai propagates by bruteforcing telnet servers with a list of 62 horribly insecure default passwords, starting with the infamous admin:admin. Although Mirai could technically infect any box upon successful login, it uses a busybox specific command which causes the infection to fail if busybox is not present. Once inside a box, the malware will attempt to kill and block anything running on ports 22, 23, and 80, essentially locking out the user from their own device and preventing infection by other malware. Despite Mirai killing most control panels, it is possibly to use Shodan to see which services the box was exposing prior to infection, giving us an idea of the type of boxes infected (we’ll get to that later).

How is Mirai Responsible for the Largest Ever DDoS?

Although this question can’t be answered with complete certainty, there are two very likely reasons for this, i’ll go into each reason in depth.

Conventional Botnets

Conventional botnets are made by leveraging methods such as malicious spam, exploits, executable infection, and social engineering to infect desktop computers with specially crafted software which gives the attacker control, but they’re very expensive to run. Although “Antivirus is dead” is the phrase all the cool kids are using these days, it’s a fact that the AV industry has put a significant dent in botnets and general malware propagation over the past decade. Nowadays hackers have to spend large amounts of time and money constantly modify their malware to evade AV detection, and although botnets still exist (spoiler: they always will), the number of notable botnets and their individual size has shrunk.

Despite there still being several botnets significantly larger that Mirai, with active infection numbers in the multi-millions, we’ve never seen DDoS attacks from them for a multitude of reason:

• Profitability – At current the maintenance cost of desktop botnets has exceeded the revenue from DDoS attacks for most. Cheap anti-DDoS services make DDoS protection more affordable that paying ransoms to attackers, resulting in DDoS for hire or DDoS ransom based botnets slowly dying out. Although you’ve probably seen a lot of “stresser” services advertised, these are different from normal botnets in the sense they’re mostly run by scriptkiddies purchasing cheap Linux servers and executing DoS scripts on them (the small pool of unique addresses makes the attacks easy to block for most DDoS mitigation services and even your average sysadmin).
• Noise – As we saw with Mirai, DDoS attacks are noisy and draw a lot of attention. Mirai, which was mostly ignored due to its unsophisticated telnet bruteforcing attacks, in the course of a week became the subject of worldwide media attention and multiple law enforcement investigation backed by multinational companies; nobody looking to make money wants that kind of attention.
• Overblown Statistics – The few large desktop botnets which do perform DDoS usually end up being sinkholed; however, sinkholes often measure botnets by unique IPs over a few month period (keep in mind lots of infections will have dynamic IPs which change daily), resulting in infection numbers being hugely over-inflated. The largest Mariposa (butterfly) botnet consisted of around 400,000 infections but due to the authorities sinkholing multiple botnets run by different actors and then counted unique IPs over a 10 month period, the resulting estimate was a ridiculous 10 – 15 million.

IoT Botnets

IoT botnets don’t face some of the problems conventional botnets do: they’re cheap, easy to infect, and aren’t useful for much else other than DDoS (most sane people probably aren’t doing online banking from their IoT toaster), which is why we’re seeing larger and larger DDoS attacks despite the overall declining size of botnets.

If we take pretty much any conventional botnet and plot the number of bots online in any 1 hour time frame on a graph, it will form natural waves throughout the week with smaller ones during the weekend: these waves peak during the day and trough during the night for whichever timezone is most dominant. The difference in number of online bots throughout the day is because to normal people (or so I’m told) don’t leave their computers running all day, but do you know what they probably don’t turn off? Their fridge, CCTV or router.

The Sality3 Botnet (each point is an hour).

If you’re doing just about any kind of botnet operation it doesn’t really matter how many bots you have online at a single time or when they’re online, but for DDoS you’re going to want as many bots online during the attack as possible. Again going back to conventional botnets, we will see that even with botnets consisting of hundreds of thousands of infections very few bots are online at any one time, which really isn’t good for launching large scale DDoS attacks. ZeroAccess3 makes a good example due to the very short C&C check-in delay we can see exactly how many bots are online at any one time, whereas bots on larger botnets tend to only be programmed to check in every 20 minutes or more. Graphing out the number of online ZeroAccess3 bots over a 48h period, we can see numbers generally range from 75 to 350 bots (between 4% and 20% of the total infections).

ZeroAccess3 online count over a 48h period

For reference we deploy around 500 custom telnet servers designed to emulate vulnerable IoT devices; our code will simulate a real telnet server and await a command specific to the Mirai malware before passing the IP address to our database. Due to the fact Mirai self-propagates by scanning the entire internet (with the exception of a few reserved ranges), we are able to see every scanning bot as soon as it hits one of our 500 IP addresses. Unfortunately, scanning the entire internet takes quite a while when you’re using an IoT device with the processing power of a pocket calculator, which is why we made the decision to deploy hundreds of telnet servers to increase the rate of mapping, rather than just running a few for a couple of months.

We graphed the total number of Mirai hits on our sensors and as you can see the numbers remain stable through the day (until dropping to 0 for an unknown reason), lending credit to our theory that most IoT devices are online 24/7; however, it’s important to note that due to the time taken for each bot to scan the internet, we are not seeing the total number of bots online at any time, rather just a large enough sample set to compare the number of hits throughout the day.

Total Number of Mirai Infections

The number of hits against our sensor began sharply dropping after about 14 hours, which could be due to any number of reasons (though we think it was because the scan only scans each IP once). We were able to count a total of 72,000 unique IP addresses over a 12 hour period: with our sensors finding ~4,000 new IPs per hour: which would put the total 24h estimate at 120,000, which is fairly close to OVH’s numbers.

Some sources have been claiming numbers in the 1 – 1.5 million range, but according to motherboard Akamai disagrees: “McKeay, who declined to go into the details of the attacks citing company policies toward customers, said that “nothing” Akamai saw suggests those numbers are “possible.””. Although I do believe that 1.5 million is certainly possible, it doesn’t appear that anywhere near that number of devices were involved in the Krebs or OVH attack.

Other estimates I’ve seen were based on Shodan search for devices listening on port 48101, though there are a couple of issues with this:

• The search doesn’t account for dynamic IPs in which case the same device could show up multiple times under different IPs.
• Although the bot does listen on port 48101, it is bound to localhost; meaning it should only accept local connections from other processes running on the device, not boxes scanning the internet.
• Other services use port 48101, including a brand of printer I found.

Furthermore, most of the IPs we logged were checked against Shodan and most were not shown as listening on port 48101 (as should be expected); however, a few did which could be explained by iptables forwarding, or the fact that the C&C server does listen for external connections on port 48101 and can be used to bruteforce boxes.

Infected Devices

From fingerprinting some of the devices we were able to determine what type of software they were running and came to the same conclusion as everyone else: that the botnet is made up mostly of CCTV cameras running Dahua firmware or a generic management interface called “NETSurveillance”. In a lot of cases the camera login panels or RTSP (Real Time Streaming Protocol) feeds were exposed to the internet and could likely be remotely viewed using the same default passwords as were used by Mirai to infect the device.

Conclusion

It’s likely that significant DDoS attacks will become more common as hackers find more and new vulnerable IoT devices, or was to infect those vulnerable devices hidden behind NAT. It’s definitely time that manufactures stopped shipping devices with global default passwords and switch to randomly generated passwords displayed on the bottom of the device.

Shoutout to @2sec4u for his collaboration on this research.

Of course it wouldn’t be real research without a pew pew map: