In Harry Potter and the Chamber of Secrets, Mr. Weasley gives the advice, “Never trust anything that can think for itself if you can’t see where it keeps its brain."1 That is ever so true when it comes to Internet of Things (IoT) computers, a topic into which we will delve deeply in this second article of volume 6 of the Hunt for IoT research series. In this article, we focus on IoT botnets themselves—how these “thingbots” are made, who makes them, and the thingbots that have been discovered since Volume 5 of our Hunt for IoT Report in October 2018.
The answer to this question is both simple and disturbing: children, sophisticated nation-states, and every type of threat actor in between.
Building IoT botnets is a popular activity both in the young script kiddie world and within nation-state cyber groups. The conversation about young people hacking isn’t new. The United Nations Interregional Crime and Justice Research1 said in 2012 that 61% of hackers begin hacking before the age of 16. Per NCCU, in 2017, the average age of a cyber-crime suspect was 17 years old—in comparison to 37 for drugs, and 39 for fraud.2 Early interest in hacking isn’t novel, but what has changed is the rise in IoT devices deployed in a way that makes them easy to compromise, thereby presenting a unique new opportunity for teens and young adults. This opportunity is marketed to them through online games and shady game modding forums—it is not a coincidence that most thingbots are named after anime and gaming characters.
The authors of the most infamous thingbot, the Mirai botnet, were college students,3 first exposed to DDoS attacks through Minecraft,4 and their motive was not monetary. The DDoS attacks they launched against their University, Rutgers, were launched to delay upperclassmen from registering for a computer science class they wanted to take, and later to delay a calculus exam.5 Eventually, hacker celebrity played a part, which we can only assume motivated at least some of the copycat Mirai thingbots that have followed. With so many Mirai variants showing only minimal modification of the leaked code, we can only assume a lot of the threat actors building Mirai clones are likely young script kiddies. Sophisticated threat actors would write their own code, or at least modify existing code so it wouldn’t behave like a bot that has been fingerprinted by every security provider on the planet (as Mirai has).
Below is a tweet from a hacker who pwned a bunch of smart TVs stating he needed to go on hiatus until finals were over.
Figure 2 is a price list for various hacking and attacking services offered by the Dark Overlord. Given changing school grades is the highest valued service, we assume the use of IoT bots is popular with young adults, as well.1
Poor security is another clue that young novices are operating botnets. The Owari authors left their command and control (C&C) MySQL database wide open (port 3306), “protected” with both the username and password of “root.”1 Control of IoT devices is a highly competitive market, where rivals commonly DDoS each other. In one case, a competing attacker took over 29 IoT bots that were offering DDoS-for-hire services by brute forcing weak usernames and passwords—the very same method attackers use to compromise IoT devices from which they launch the DDoS attacks. It’s a novice mistake not to protect yourself from the very attacks you launch.2
One 13-year-old bragged about building several IoT bots, expressing little concern about prosecution. He’s right; it’s unlikely he’ll get caught, and if he did, the resulting hacker celebrity almost guarantees a high paying cybersecurity job down the road.3 Even if the risk of indictment were high, the types of sentences handed out to cyber criminals (over the age of 18) is so laughable, it’s not a deterrent. The Mirai authors were prosecuted in both Alaska and New Jersey. In both cases, they were handed out 2,500 hours of “community service,” defined in the sentencing memorandum as “continued work with the FBI on cybercrime and cybersecurity matters.”4 In Alaska, they received no jail time, 5 years’ probation, and $127,000 in fines. In New Jersey, they were sentenced to 6 months house arrest, and $8.6 million in fines (based on Rutgers incident response costs from their DDoS attacks).5 The prosecutors in the Alaska case actually argued favorably for one of the defendants, stating that jail would “disrupt a remarkable transformation,” considering he had turned over a new leaf, was attending school again, and had landed a new job at a cybersecurity company.
On the other hand, it is clear that some sophisticated and well-resourced threat actors and nation-states are building IoT thingbots, as well.6 There is ample motive for it; why not control a bunch of IP cameras, surveillance systems, and wearables that give you visibility and access to targets of interest? This has also created a niche business opportunity for companies that specialize in crafting zero-day exploits, as government spy agencies have now added the compromise of IoT to their offerings. In the case of Jamal Khashoggi, the top advisor to Saudi Arabia’s Crown Prince contracted with an Israeli company called the NSO Group to use its surveillance tools throughout the Middle East and Europe. It was through this relationship that they were able to determine Mr. Khashoggi’s whereabouts, which led to his assassination.7 This same group is allegedly behind the WhatsApp remote spyware that is being used by governments to track journalists, activists, and human rights workers around the world.8
China has widely deployed surveillance systems to control their population. They are tracking their Muslim population,9 sending jaywalking tickets in the mail,10 and feeding a social scoring system that impacts credit scores and a citizen’s ability to travel.11 One could argue this entire system is a nation-state spy-bot.
How easy is it? Well if 13-year-olds can do it,12 the bar is set too low!
Getting some open-source thingbot code is really, really, easy. A simple Google, Pastebin, or Github search will do it. We found 178 references to Mirai source code while searching in Pastebin, which led to many tutorials with step-by-step instructions and chat servers offering technical support.
IoT devices commonly use SSH or Telnet for remote administration, protected by vendor default credentials. It’s very easy to find vendor default credentials. Not only are there lots of published lists (we’ve been publishing the top 100 attacked SSH credentials for the past 2.5 years), but Google searches of a vendors’ name and “port forward” typically leads you to deployment guides that provide the vendors’ default credentials, and which port to find them on. The screenshot below is from Dahua, a popular NVR manufacturers’ wiki13 describing how to set up remote access.
Below is a screenshot from a third-party website sharing default credentials for Swann IP cameras.1
In the case of fleet vehicles being tracked via GPS, VICE News recently covered a hacker discovery. The hackers could brute-force the username, already knew the default password, and then, like magic, they had access to the GPS system, giving them the ability to remotely shut off the car.1
However, attackers don’t need to research default credentials when brute forcing the devices works just as well. The term “brute force” is used loosely in this case—the reality is that attackers have narrowed down a short list of possible credentials likely to work on their targeted devices. This makes the attack process closer to credential stuffing then brute forcing.
There are many CVEs and exploits that are being targeted by IoT bots (see list of CVEs in the thingbot discovery section). Some CVEs make it incredibly easy to compromise the vulnerable system; for example, CVE-2016-104011 gives the superuser (su) password, and the corresponding exploit 43105 closes the loop with additional details.
CVE-2018-7900 makes it easy to discover Huawei routers that disclose whether or not the router still has default credentials enabled.1 Similarly, CVE-2019-112192 impacts IoT systems using iLinkP2P software, which are vulnerable to a predictability flaw that allows attackers to discover and establish connections to the devices, followed by authentication flaw CVE-2019-112203 that allows attackers to intercept traffic in clear text.
Like the OWASP Top 10 for web application security risks, OWASP recently released an IoT Top 10 list.4 It’s important to keep in mind that IoT devices are mini computers with software vulnerabilities just like your laptop, desktop or server; they just haven’t been around long enough to get the vulnerability detection they deserve. However, as IoT targeting increases in popularity and IoT vulnerability research improves, we’re going to see the number of new vulnerabilities discovered in IoT devices increasing exponentially for years to come. Right now, we’re in a catch-up game where attackers are exploiting IoT devices through zero-day vulnerabilities that haven’t been documented or remediated yet.
If the ease of exploitation wasn’t bad enough, there are many search engines to help anyone (researchers and attackers alike) find devices exposed to the Internet. Shodan, ZoomEye, Censys.io, and Wigle are the most popular when looking for IoT. Using these search engines, you can find anything from a list of routers, to a list of hot tubs, to attack.5
Not only is it easy to find default credentials, ports, vulnerabilities, and exploits for IoT devices with some simple Google searches, the ease with which these attacks can be carried out has been widely publicized. As we mentioned previously, publicity became a motive for the threat actors behind Mirai, and the current tracking and reporting on IoT botnets is fueling attacker interest now.
The IoT bot scene has exploded since the Mirai attacks both because of the popularity of the thingbot (driven by publicity), and the release of its source code. This popularity can be seen in the increase in the number of thingbots since the Mirai attacks: 88% of the thingbots we know about were discovered since Mirai, and, of those, 46% are variants of Mirai.
The following thingbots have been discovered and/or reported on since our last report in October 2018 through January 2019.
|IoT Malware Name
|Service / CVE Attacked
|Infected IoT Device Type
|Attack Types Launched
|SOHO Routers, SDKs
|Telnet, HNAP, ThinkPHP, CVE-2015-2051, CVE-2014-8361, and CVE-2017-17215
|SOHO Routers, SDKs
|Gafgyt / Qbot, and Mirai
|Saikin / Akiru
|HTTP, UPnP, HNAP
|CCTV, SOHO Routers, SDKs
|IP Cameras, DVRs, NVRs
|Burner bot, DDoS
|Telnet - weak creds
|IoT devices running MIPS, ARM, x86, x64, PowerPC, and SuperH architectures
|Information collection, fetches and executes commands, encrypts communication
|Gafgyt / Qbot
|CVE-2017–17215, CVE-2014–8361, CVE-2018–10561 & CVE-2018–10562
|SOHO Routers, SDKs
|DDoS for Hire
|500 Gbps DDoS, L4 àL7
|ThinkPHP RCE Exploit ID: 45978
|DADDYL33T created, variant
|Telnet, SSH, CVE-2017-17215, ThinkPHP RCE Exploit ID: 45978
|DDoS (for sale on Instagram)
|Telnet, CVE-2017-17215, ThinkPHP RCE Exploit ID: 45978
|Telnet, CVE-2017-17215, ThinkPHP RCE Exploit ID: 45978, CVE-2017-17215, ADB attacks
|Telnet & Exploit ID: 45978
|IoT devices using PHP, Linux
|Monero mining, cybercrime, takeover host
|ThinkPHP RCE Exploit ID: 45978, CVE-2014-8361, Linksys RCE, CVE-2018-10561, CCTV-DVR RCE
|SOHO Routers, CCTV-DVRs
Table 1: Recent thingbot discoveries
The discoveries of new thingbots targeting IoT devices over exposed services, beyond telnet, proves that the shift we anticipated in the Hunt for IoT volume 3, happened. Thingbots are targeting IoT devices using HTTP, and publicly exposed UPnP, HNAP and SSH (these services should not be exposed publicly). Additionally, 30% of the new thingbots discoveries are targeting IoT devices through CVEs. In episode 3 of the Hunt for IoT volume 6 report series, we will examine attacks against dozens of services using over 150 different ports.
Small office/home office (SOHO) routers, IP cameras, DVR, NVR, and CCTVs are still the primary types of IoT devices that get infected by thingbots. IP cameras, DVRs, NVRs and CCTVs are all components of surveillance systems widely deployed around the world by governments, private business and residences as discussed in Episode 1 of this series. (The DVRs can include those in residences that record TV.) At this point, we still consider these infections use-case based rather than attackers targeting specific types of IoT devices for specific attack purposes. They are the most widely deployed types IoT devices, and they require remote administration by either the service provider or surveillance operator. The sheer number of them that are publicly accessible makes them the most common types of IoT devices exploited. This also makes them a target of researchers looking for IoT vulnerabilities—the bigger the deployment, the bigger the find or researcher notoriety, which then leads to threat actors targeting the vulnerabilities with their botnets. See the conclusion section of the Hunt for IoT volume 5 for a list of targeting opportunities with specific types of IoT devices.
Once malware is installed on the IoT device, the bot will contact the C&C server and download its orders. Those orders can include any attack of the bot authors’ choosing, however, in most cases the attack method of choice is DDoS, including the following types:
- HTTP GET/POST L7
- Syn flood
- Ack flood
- PSH flood
- Generic Routing Encapsulation (GRE) flood
- TSource Query Reflection
- DNS Query flood
- Random packet byte flood
Outside of DDoS attacks, these thingbots are deploying proxy servers to use for launching attacks, collecting information from the traffic that traverses the device, encrypting their traffic, mining cryptocurrency, and launching web application attacks. The sale of botnet services has come above-ground from darkweb forums to Instagram,1 a move in line with the script-kiddie gamer persona that’s building and selling IoT botnets now. And the market is flooded, which drives prices down. Subscription plans for botnet services are going for as little as $5 a month. The screenshot in Figure 11 (discovered in one of the Pastebin links after searching “Mirai source code”) shows the price for a 40+ Gbps DDoS attack by Santana or Yakou is $10 for 500 seconds.
Digital Ocean accounts are also being sold. This hosting network often comes up in our top attacking ASN reporting, indicating threat actors use this network from which to launch attacks.
In Table 1 above, there’s a lot we don’t know about some of these bots (how each bot is discovering and infecting IoT devices, what kinds of devices they are infecting, what types of attacks they launch). The reasons for this are both positive and negative. The good news is that the security community is discovering bots before they attack. In the past, the majority of thingbots were discovered through investigating attack traffic, which not only uncovered the bot but the attack types and infected devices. The fact that we’re discovering bots before they launch attacks and before we have all this information is a good thing. The negative is that the security community is always 10 steps behind attackers because we abide by laws prohibiting us from obtaining unauthorized access to a system. If we want to understand what attackers are really up to, we would need to get on the devices they infect, access their C&Cs, etc. This is the daily dilemma of a threat researcher, and one that law enforcement has been facing in the physical world since the beginning of time. Legislation has been proposed for ethical researchers to get a “hall pass,” meanwhile ethical researchers have been charged with computer intrusion crimes.
Because most thingbots we know about derive from the Mirai botnet, it is helpful to be aware of its primary features, and that the continued emergence of new Mirai variants is ensuring that this bot family is alive, as well.
Between December 30, 2018 and June 30, 2019, our data partner Baffin Bay Networks saw very little reduction in Mirai infections, despite Mirai being the most infamous thingbot on the Internet—a position that typically results in the demise of a malware family. Of course, the survival of Mirai is aided by the challenges associated with remediating infections on IoT devices.
Mirai’s distributed scanning model provides it the ability to self-reproduce. The “scanners” (the red dots) responsible for seeking out new IoT devices to infect have remained prominent throughout the US, Europe, and Asia since June 2017 (see page 23 of The Hunt for IoT volume 4). The maps shown in Figures 11 and 12 reflect the current state of Mirai infections on December 30, 2018, and June 30, 2019 respectively. Infections in Latin America and Africa have remained consistent since June of 2018 (see the The Hunt for IoT volume 5). Other notable changes include the reduction of scanner nodes across the US between December 2018 and June 2019. If you are an Internet service provider cleaning up Mirai infections, we would love to speak with you!
The yellow dots (in Figure 12 above) indicate infected IoT devices being used as “malware” hosting systems from which the scanner nodes can retrieve the latest Mirai malware code. Growth of Mirai malware nodes has increased over the past two years as new variants of Mirai have been released, most notably in the US and Europe. There was a noticeable growth of malware systems in the Middle East, specifically Iran, and across Europe in December 2018, but these systems were not active by June 30, 2019.
If Gartner—the most conservative analyst firm when it comes to IoT projections—is correct, and we’re approaching 20 billion1 devices deployed, and, per our testing, 62% are vulnerable, that’s a potential threat surface of 12 billion IoT devices that could be compromised and used for attacks. These threats will only be compounded with the growth of 5G router deployments amplifying attack sizes and increasing the complexities of mitigating attacks from IPv6 devices.
This number will continue to rise until customers demand more secure development strategies for IoT manufacturing. From the time of that adoption, there will still be significant lag before secure IoT systems are purchased, installed, and displace older insecure devices. This process hasn’t yet begun. It will be at least several years before we see a noticeable impact from new, secure IoT devices reducing the threat surface. In the meantime, everyone from script kiddies to nation-states will continue to compromise IoT devices.
Waiting on IoT manufacturers to offer secure IoT products or trusting implementers to effectively deploy security controls on IoT devices is a waste of time. Why think IoT would be any different than standard IT, which already struggles? Businesses getting hit by IoT bot attacks must buckle up and defend themselves.
How to defend against this? Start with the most common attacks launched by thingbots: DDoS and web application attacks. When it comes to DDoS attacks, a cloud scrubbing provider is the way to go, simply because attack sizes beyond the capacity of most networks (outside service providers and large banks) cost only $20 to launch. When it comes to defending against web application attacks, look for web application firewalls with behavior-based bot detection and traffic blocking. Traditional IP block lists aren’t scalable—particularly when the denylisted IPs are the residences of your customers, whom you still want to allow to access your app.
Do your homework on the IoT products you want to buy. Don’t buy products with known vulnerabilities, products that are actively exploited, or products that don’t offer proper security. Quarantine or retire any devices you already have that can’t be secured.
Protect yourself from the most common IoT exploit paths:
- Disable remote management, restrict to a management network, or place behind a firewall. Leverage NAT at a minimum if the devices will be used in a residence.
- Change the vendor default creds and disable the default admin account if you can.
- Continually update the devices with the latest firmware as it is released.
For a longer list of IoT system hardening suggestions, see the conclusion of the Hunt for IoT volume 4.
The following article in this research series focuses on the growing list of ports used by IoT devices that we are monitoring attacks on, and the attacks against them from July 1, 2018 through December 31, 2018.