IoT: a malware story

Since 2008, cyber-criminals have been creating malware to attack IoT-devices, such as routers and other types of network equipment. You will find a lot of statistics on this on Securelist, most notably, here and here. The main problem with these IoT/embedded devices is that one simply cannot install any kind of security software. How do we deal with that?

The best option for tracking attacks, catching malware and getting an overview of attacks in this area is to use honeypots.

About honeypots

There are three common types of honeypot:

• Low-interaction honeypots. These simulate services such as Telnet, SSH and web servers. The attacker or attacking system is tricked into thinking it is a real vulnerable system and running its malicious commands and payload.
• High-interaction honeypots. These are real systems that require additional steps to restrict malicious activities and avoid compromising further systems, but it has the advantage of actually running a fully POSIX-capable system. This means that any future attempts to identify the hosts using techniques not already emulated by low-interaction honeypots will fail, thus making the attacking scripts believe it is a real device.
• Medium-interaction honeypots. These are combinations of the two that offer more functionality than low-interaction honeypots but less than high-interaction honeypots.

Ideally, it is best to operate only high-Interaction honeypots. Unfortunately, due to the high volume of attacks, these types of honeypots cannot scale, and the environment needs to be reset for every new connection. As such, medium-interaction honeypots are the type most commonly used, and the most popular open-source projects are Cowrie and Dionaea.

We work with all three types of honeypots, and we have even created a different type, the sensor honeypot, which we will cover below.

Honeypot deployment

Working with honeypots implies taking security into consideration at every step. A system vulnerable to attack or a system under attack can put you and others at risk.

A major step when running honeypots is planning a network layout before getting the honeypots running. This includes defining what activities should be monitored, and how data is collected and processed. Over the past years, we have created a honeypot infrastructure, extending and improving it continuously. We created our own modular approach to this, to deal with system management, updates and data processing. The main idea is to be able to deploy multiple honeypots with ease to try to keep maintenance costs as low as possible.

Residential vs. “Corporate” IP addresses

Our telemetry data suggests that smart botnet operators check the network AS name and tend to target only IP addresses belonging to internet service providers supplying Internet connection to home users. The reason is simple: if there is a router showing up on an Amazon/DigitalOcean-owned IP, this might be a sign that the machine could be a VPS (virtual private server), rather than a SoHo Router sitting inside somebody’s home.

Using the same IP address for a long time

Cycling through IP addresses is quite important. Botnet owners try to monitor honeypots on their own, so after some time, public IP addresses may get flagged by cybercriminals, which results in fewer attacks. Furthermore, we believe there are lists of “honeypot IPs” traded in darknet markets.

Fingerprinting honeypots

Multiple malware families use specific valid commands that are not fully emulated by some honeypots, in order to detect them. Attackers constantly change their fingerprinting methods to bypass the anti-anti-VM techniques. These techniques are implemented in order to check if attackers are trying to probe the honeypot and will return fake data to make the honeypot look real. For example, one malware family reads the contents of /proc/cpuinfo in order to find out the processor type and family. Most Cowrie deployments use the same CPU architecture.

Handling heavy loads

Exposing a popular port (for example, 21. 22. 23. 80) to the Internet will almost immediately attract connection attempts from various hosts, and the longer that port stays open, the more bots will try to “infect” the service. For a static IP address running the same service for more than twelve months, the “infection rate” (the number of sessions trying to infect our honeypot host with malware) was around 4,000 every 15 minutes. The offending IPs are not unique and, from our experience, one attacker attempts to infect a machine multiple times.

A large number of connections generates a lot of stress on both the network and the honeypot emulation stacks. From our experience, we noticed that Cowrie can handle around 10,000 simultaneous sessions per instance. For heavily-loaded honeypots, the solution would be to load-balance the attacking connections at the kernel layer into multiple Docker instances, which can be easily implemented using the kernel’s netfilter module.

Results

So far, we have collected results in our production environment for more than one year. We have deployed more than 50 honeypots around the world, with 20,000 infected sessions every 15 minutes. Below are our results, based on the aggregated data.

Statistics: Telnet

In the first half of 2019, our Telnet honeypots detected a total of more than 105 million attacks that originated with 276,000 unique IP addresses. Compare that with 12 million attacks, originating with 69,000 IP addresses, detected year-on-year in 2018. We are looking at a steady trend for an increase in repeat attacks from attackers’ IP addresses, suggesting increasingly persistent attempts at infecting devices previously known to the attackers.

While Brazil and China remained the leaders in terms of unique IP addresses that served as the origin of Telnet password brute-forcing attacks in the first half of 2019, China took the lead when compared with 2018 year-on-year, with around 30 percent, whereas Brazil was second with 19 percent. Egypt, Russia and the United States were third, fourth and fifth, respectively.

Countries that were the sources of Telnet attacks on Kaspersky Laboratory honeypots

Top 10 IoT threat verdicts

It should come as no surprise that most of the positions are occupied by various Mirai modifications: these use exploits, targeting devices that have Telnet turned off. Consider, too, that the malware has been publicly available for a long time, and its code is versatile enough for compiling bots of any level of complexity, for any hardware configuration.

TOP 10 IoT threat verdicts, first half of 2018

TOP 10 IoT threat verdicts, first half of 2019

The statistics were collected from a specially designated group of honeypots that was not touched by the infrastructure changes (no new devices were added), so the statistics relied on the activity of infected devices only. A session stands for a successful password brute-forcing attempt.

An analysis of logs from an isolated group of honeypots points to a steady trend for a year-on-year decrease in attacker IP addresses but an increase in the number of attacks. The number of active infected devices remains high: tens of thousands of devices attempt to spread malware by both brute-forcing passwords and exploiting various vulnerabilities every month.

Unique IP addressed detected as the origin of attacks on the isolated honeypot group, January through June 2018

Statistics: credentials

Especially in the IoT area, Telnet, SSH and web servers are the most common services available and, therefore, the most-attacked ones. For Telnet and SSH, we store not only malicious payloads but also initial login credentials. This data enables us to identify targeted devices due to the default username/password combinations mainly used by the attackers.

We collected the most widely used username and password combinations for Q3 and Q4 2018, and Q1-Q3 2019; you can find them all in the Appendix. The most common combination by far is “support/support”, followed by “admin/admin”, “default/default” and “root/vizxv”. The first three entries are self-explanatory, but the fourth one is quite interesting: it is the default password for a vulnerable IP camera, as described in Kreb’s blog.

New cameras are probed every quarter as exploits are released into the wild. For example, in Q1 2019, we observed bots trying to infect specific Gpon routers using a specific hard-coded password. Our colleagues at TrendMicro wrote about this at the end of 2018.

Identifying collected credentials for Q3 2018 (left), Q4 2018 (center) and Q1 2019 (right)

Statistics: malware

While common computers usually run on Intel or AMD CPUs (little-endian x86 or x86_64), embedded IoT devices use a broader range of CPU architectures supplied by multiple vendors.

While classifying our samples, we noticed that we had files using both endianness types, designed to be executed on multiple CPU architectures, such as ARM, Intel x86 and MIPS.

Below is a table with all types of samples we collected.

A well-known method used by attackers, once they get access to a device, is to try and deploy their malware for all architectures without any checks. This approach works because only one binary will be executed correctly. Luckily for us, this allows us to grab all the links and download all the samples.

Below is an example of such a script.

Besides username/password combinations, the type of architecture being targeted is an additional characteristic that helps us to identify other potentially targeted devices.

Attacking countries and networks

The top three countries probing our honeypots were China and Brazil, followed by Egypt and Russia, the latter two 0.1 percent apart. The trend seems to be consistent throughout 2018 and 2019, with slight changes in country rankings.

Below are the top 20 most active attackers and their ASNs, based on attacker IP analysis.

Infected sessions

Starting in 2018, we have present two metrics in our data: “all sessions” and “infected sessions”. An infected session is one where there was at least one malware file requested, or dropped, from the Internet. A non-infected session might be one initiated by mistake by a legitimate user, via a mistyped IP address, or by a robot scanning the Internet. We have seen a steady increase in all sessions (Telnet, SSH, web, etc.) opened on our honeypots, and the more honeypots we add to our network, the more traffic we observe, which means that attackers are constantly scanning the Internet in order to infect new devices. In most cases, infected devices are the ones scanning for new hosts on the Internet.

Malware families: 2018 vs. 2019

In terms of detected hashes, we have seen a few changes in top samples trying to attack our honeypots. Overall, in 2018 as well as 2019, Mirai remained the most popular malware family with over 30,000 samples detected in 2018 and almost 25,000 samples detected in the first half of 2019. While the Hajime malware, thoroughly researched by Kaspersky and by Symantec in 2017, was quite active during its prime years, it is almost non-existent on our 2019 charts.

Instead, we have seen an increase from well-known malware families, NyaDrop and Gafgy, trying to infect newer devices.

Below are our Top 10 samples detected in Q1 2018 and Q1 2019.

Uberpot

Besides the common honeypots that listen on specific ports, we have also created a multi-port honeypot, named “uberpot”. The idea is simple: the honeypot listens on all TCP and UDP ports and accepts connections, and logs data received and meta information. The main objective is to identify new attack vectors, and attacks on other services and ports, e.g. due to new devices or vendor-specific port configurations.

TCP is clearly king in terms of attacker services, even though we still see some UDP/ICMP traffic directed to our uberpot instances.

In terms of infected sessions, we get hit by around 6,000 daily, but in January 2019, we noticed a spike in traffic with more than 7,500 daily sessions hitting random TCP ports.

In terms of other protocols, UDP and ICMP traffic is quite insignificant compared to TCP. We do not monitor other “exotic” protocols, such as DCCP, SST or ATP.

Attacked protocols on Uberpot

So far, mostly TCP-services have been attacked. Remote Administration Services such as SSH, Telnet, VNC and RDP have been a popular target, in addition to databases and web servers.

Attacked protocols on Uberpot

We continue to improve our systems and sensors, and expand our infrastructure to monitor threats and help protect against these.

Honeypots-as-a-Service

A constant issue for security researchers is new sources of malware, data and infections. As a company or security team, you want to have full visibility into what hosts are attacking you and what kind of services attackers are going after. Apart from traditional defense mechanisms, log monitoring and training, deploying honeypots in key parts of your public or private infrastructure can also help in identifying ongoing probes into your network.

The main issues when running a large network of honeypots is maintenance, aggregation and processing of logs and bug fixing. We solve these problems by moving all honeypots into a dockerized infrastructure. This means that the front-facing hosts require very low resources: a node can run on a Raspberry PI.

Our solution is simple: we offer Docker image/install scripts that forward malicious traffic aimed at “vulnerable” ports back to our infrastructure through a Wireguard UDP tunnel. We call these machines “nodes” and, as mentioned before, a node can even run on a Raspberry PI. Once you install a machine like that, all you need to do is redirect the ports you want to monitor towards it. You can directly assign public IPs, as some of our partners do, or even do DNAT (port forwarding) only for the ports you are interested in.

Once traffic hits your node, it is sent to our aggregator, where a Docker machine handles it and responds. We then generate statistics and all required data on the aggregator.

For more information about our infrastructure, please check out our SAS 2019 video.

Conclusion

While the trend for IoT-specific malware is growing as the IoT landscape expands into more and more areas, we will continue to extend our detection and research capabilities. Awareness is a key element along with defense technologies based on analysis and following trends.

One way to stay on top of attackers is to ingest dedicated feeds for IoT threats. For example, we offer such feeds on our Threat Intelligence platform.

If you are interested in starting a research partnership with Kaspersky and running honeypots on your unused IP addresses, please get in touch with us at honeypots@kaspersky.com. We are happy to partner with you to deploy our Honeypot-as-a-Service prototype.

As explained in the “Honeypots-as-a-Service” section, we aggregate, correlate and cluster all incoming connections and all processed data is made available to you almost in real time.

Appendix

List of passwords for recent quarters: