Following our first article on how to set up an IoT security honeypot, this second article gives insights into the data that our honeypot captured as well as a focus on the different malware loaders that we encountered.
We will go over :
- Why changing default password is a must
- Understanding the Nature of Attacks on Honeypots: The Dropper Mechanis, Analysis of different loaders uploaded to our VPS
To sum up where we left last time, our honeypot has a fixed public IP address and is listening on numerous ports, tricking attackers and other infected bots into targeting us. For instance, our TPOT solution is listening on TCP 445 (SMB) and 3398 (RDP) both being used by Windows OS. It explains why, among all the binaries uploaded on our server we identified the WannaCry ransomware. It’s rather interesting to point out that seven years after its first observation it is still proliferating, and continues to exploit the infamous zero-day vulnerability, EternalBlue.
Why changing default password is a must
Since we are conducting research on IoT based malwares, we choose to focus on ports commonly used by these devices and leave aside the rest. Cowrie supports SSH and Telnet. Remote administration of IoT objects is primarily done via these protocols and most of the time with poor/default credentials. Malwares such as Mirai target these specific protocols, thus it’s particularly interesting to monitor.
Figure 1 : Kibana cowrie dashboard after 10 days (ssh / telnet honeypot)
In less than 10 days, more than 200K malicious requests targeted the ssh / telnet services of our server ! The requests are coming from all around the world, with a notable peak in Asia (China, Vietnam, Korea) and South America (Brazil, Mexico).
Figure 2 : Attackers IP geolocation
In the presented screenshot of our kibana dashboard, showcasing the attacks captured by cowrie, we note that these 225K requests are coming from less than three thousands unique src IPs. Meaning on an average each malicious IP has made 75 requests to our honeypot. This amount of requests, especially targeting telnet or ssh, is characteristic of a bruteforce attack.
The following screenshot, showcasing the top credentials attempted while trying to login, increases our confidence in this assumption :
Figure 3 : top attempted credentials on both ssh and telnet
It is evident that default or poor credentials are a prevalent target for attackers…
IoT devices are often supplied with generic, widely known usernames and passwords, making them vulnerable to unauthorized access. Lacking time, ressources, or even because of laziness, administrators tend to keep the default credentials after installing these devices, greatly simplifying the monitoring of the devices.
Changing these default credentials is extremely important as it significantly enhances the security of your objects. Malwares like Mirai and its variants exploit the prevalence of default credentials as a primary attack vector. By attempting to gain unauthorized access using common username-password combinations, these malicious entities compromise the integrity and functionality of IoT devices.
Monitoring and analyzing the attempted credentials not only highlights the severity of the potential threat but also empowers us to take proactive measures in strengthening our security posture.
By identifying the common credentials targeted by attackers, we can compile a watchlist of credentials to avoid. This watchlist serves as a reference for avoiding generic or default username-password combinations that are frequently exploited. Creating and regularly updating such a watchlist helps to fortify defenses against known attack vectors and minimizing the risk of unauthorized access and therefore enhancing the security by design.
Figure 4 : uploads of our server (along with hash of the malicious binaries)
The picture above is a screenshot of various uploads on our honeypot, revealing the IP addresses of malicious servers / C2 (Command and Control servers) and the files they
uploaded (we didn’t anonymise the ip addresses since the samples are not being hosted on them anymore). Analyzing these binaries is crucial for comprehensive threat intelligence. Reverse engineering these files allows us to understand their mechanisms, identify potential vulnerabilities, and enhance our defenses.
In the UK, the government has already introduced an IoT security bill, the PSTI, which requires a ban on using default or “easy to guess” passwords. The aim is to reduce the risk associated with these basic attacks, which, as the study shows, are still extremely present in the current threat landscape. After April 29th, 2024, if a connected device does not meet this PSTI’s security control, it cannot be sold on the UK market. Forthcoming European regulations (Cybersecurity for RED and Cyber Resilience Act) also impose security controls against these issues on pain of losing access to the European market.
Understanding the Nature of Attacks on Honeypots:
It's important to recognize that the majority of attacks observed on honeypots are not orchestrated by individual hackers but rather by malware-infected devices. These devices have been compromised by malware that autonomously scans the internet or local networks for vulnerable systems to infect. As a result, the attacks captured by honeypots are typically the result of automated processes initiated by malware rather than deliberate actions by human attackers (this explains how we can receive more than 200K attacks on our honeypot in less than 10 days).
IoT malwares operate by exploiting known vulnerabilities (CVE) or leveraging weak credentials to gain initial access to vulnerable devices. Once inside, they deploy a mechanism known as a "loader” to deliver the malware payload onto the compromised device. This loader (aka dropper) is typically a bash script that orchestrates the entire infection process.
The Dropper Mechanism:
The main role of dropper script is to gain information on the device and download the real malware onto the device. It typically starts by trying to obtain information regarding the architecture of the processor (uname -a, cat /proc/cpuinfo, lscpu …) and tries to detect whether the device is running in a virtual environment or on real hardware.
Showcased in the following screenshot are the top bash command typed in our honeypot :
Figure 5 : most attempted bash commands upon login
Most of these commands are an attempt to gather information on the device they just gained access to and probably take decisions based on predetermined criteria.
The malware payload is then downloaded from a remote server using tools like curl, wget or busybox. This phase is crucial as it involves retrieving the malicious payload from a predetermined location, frequently hosted on an HTTP server accessible over the internet.
The choice of using these specific tools is strategic for attackers due to several reasons. Firstly, web servers are easy and quick to deploy, providing attackers with a convenient means of hosting malware payloads. Additionally, web traffic is less likely to be filtered by firewalls compared to other communication protocols, making it an attractive vector for delivering malicious payloads. Moreover, the Linux distributions installed on IoT devices are often lightweight and may lack certain utilities commonly found in traditional environments. As a result, the dropper attempts multiple methods of installation to ensure successful execution of the malware.
In the context of IoT, busybox holds particular significance. It is a software suite that combines several common Unix utilities into a single executable, designed specifically for resource-constrained environments like IoT devices. Busybox is often used by the dropper to install the malware payload on the compromised device due to the fact that it is very likely to be installed on the compromised devices.
One noteworthy aspect of IoT malwares is their adaptability to various IoT architectures. The malware payload often comes in different versions tailored to different architectures, such as MIPS, MIPSEL, or ARM. The dropper script may attempt to download multiple versions of the malware to ensure compatibility with the target device's architecture. Alternatively, it may use the information gathered (processor architecture, is it running on real hardware or virtual) to choose which sample to drop onto the device or to not do anything and deletes itself (rm “$0” in bash).
Analysis of different loaders uploaded to our VPS :
Figure 6 : loader sample capture by our honeypot
The image presented above is an example of a dropper uploaded to our honeypot.First line of the script defines an array containing strings referring to several processor architectures. Then another variable is defined as “server_ip” which is pretty self explanatory.Then it iterates through the array and for each architecture, attempts to download malware from the server_ip using both the wget / curl / tftp utilities and outputs it into a file named binout. Last step of the script is changing the permission of the file, trying to execute it and removing it.
When manually connecting to this web server, we are granted with the default apache page and have access to all the binaries :
Figure 7 : screenshot of the a web server hosting malware samples
In an effort to investigate those who targeted our server, we tried enumerating the other directories and files present on this webserver, without any success. This, and the lack of attention (default apache banners, versions, lack of authentication mechanism and free access to the binaries), led us to think it only serves this purpose.
Another example that has been uploaded to our honeypot is presented in the picture below. This script follows the same principle as the previous one, it downloads a sample for several architectures, changes permissions on the file and finally tries to execute it.
Figure 8 : loader sample capture by our honeypot
When manually connecting and changing the url to http://"server_ip"/"architecture_of_compromised_device" (e.g. 192.151.243.157/arm), we were able to access the binaries.
Performing a whois search informs us that this IP is located in Hong Kong :
Figure 9 : result of whois search on this malicious server
In the following screenshot is another script, doing practically the same things :
Figure 10 : loader sample capture by our honeypot
Here is once again another example of a script, the name of the binary being explicitly offensive and racist, this screenshot is a censored version of the original script. One interesting aspect of this loader is the fact that it also includes less known architecture types such as PPC and SPARC. Another very similar script has been uploaded to our server and we believe them to be part of the same infection campaign (C2 IPs are different but are both located in London, and the scripts have similar architectures and malware name)
Searching for the url on VirusTotal also shows that the IP is flagged as malicious and hosting Mirai variant (Gafgyt)
Figure 11 : virus total url search of the malicious server
In this second chapter, we provided an analysis of the data generated by the honeypot set up in chapter 1. We went through the profile of the attackers, most of them located around Asia,
performing brute force attacks and using a very primitive dictionary wordlist.. These attackers are not individuals in their basement wearing black hoodies, but rather other infected devices that are being used to make the botnet larger. Then, we analyzed the actions of these infected bots once they managed to successfully connect via ssh or telnet to our server. We studied the footprinting techniques and malware downloading procedures via simple yet efficient bash scripts (loaders). The malwares are being downloaded via web servers (ease of set up and less likely to be filtered by firewalls). The IPs being hardcoded directly in the scripts allowed us to gather samples and investigate around these servers. This chapter highlights the importance of banning default passwords in order to stem this type of attack. This countermeasure is also carried by the various regulations being put in place in Europe. If you are interested in knowing a bit more about these new regulations and how to prove compliance to these emerging challenges, take a look at our CyberPass solution and do not hesitate to contact us.
Thank you for reading our article and stay tuned for the third chapter, where we will provide an analysis of the collected malware samples, both from a static and a dynamic perspective, shedding light on the goals of the attackers !
