According to AT&T Alien Labs, BotenaGo malware has been deployed with over 30 exploit functions, putting millions of IoT devices at risk of potential cyberattacks. BotenaGo is written in “Go”, which is a Google open-source programming language. While the use of open-source programming languages has its benefits, attackers have equally taken advantage, using Go to code malicious malware.
Our research highlights Nozomi Networks Labs’ discovery of a new variant of the BotenaGo malware that specifically targets Lilin security camera DVR devices. We have named this sample “Lillin scanner” because of the name the developers used for it in the source code: /root/lillin.go. Let’s dive deeper into the functionality of this sample to show step-by-step how these kinds of scanners work.
The source code of the BotenaGo malware (Figure 1) was leaked in October 2021, which led to the creation of new variants based on the original. We decided to monitor samples that could have been generated utilizing parts of the BotenaGo source code. In doing so, we discovered a sample that contained certain similarities of BotenaGo.
At the time of this research, the sample had not been detected by any malware detection engine in VirusTotal (Figure 2). Although the sample is quite large (2.8 MB), due to being written in Go, the portion of the actual malicious code is quite small and focuses on a single task. Its authors removed almost all of the the 30+ exploits present in BotenaGo’s original source code and reused some parts to exploit a different vulnerability that was over two years old. This may be why the sample hasn’t been detected until now.
Lillin Scanner Functionality
In order to run, the scanner/exploiter needs a parameter to be passed in the command line. That will be the port being used to connect to each of the IP addresses that the program targets. Lillin scanner differs from BotenaGo in that it doesn’t check the banner for the given IPs. It is possible that this tool is chained with another program that builds lists of Lilin devices using services like Shodan or other mass scanning tools.
Next, the sample will iterate over the IP addresses that it receives from the standard input. This portion of the code can easily be spotted in the original BotenaGo source code. These instructions will create one Goroutine (a sort of thread used in Go) per IP address executing the infectFunctionLilinDvr function, which follows the same naming convention as in BotenaGo.
The presence of strings with the names of the functions and the absence of any protection (many malware families use at least the modified version of UPX) means that it isn’t actually trying to protect itself against security products and reverse engineers. It reinforces the theory that this executable might mainly be intended to be used by attackers in manual mode.
Device Access and Vulnerability Exploitation
When the infectFunctionLilinDvr function receives the IP address to scan, it first checks if the device behind that IP can be accessed. The Lillin scanner contains 11 pairs of user-password credentials in its code. This is a difference from previous malware samples that, reportedly, abused only the credentials root/icatch99 and report/8Jg0SR8K50. These credentials are Base64-encoded to be used in the basic authentication needed to exploit the vulnerability that allows the Remote Code Execution (RCE).
Lillin scanner will loop over the 11 encoded credentials and will sequentially try to access the root directory, changing the Base64 string in the Authorization field. When the server response contains the string HTTP/1.1 200 or HTTP/1.0 200 it will consider the authentication to be successful and will attempt the exploitation of the Network Time Protocol (NTP) configuration vulnerability.
This vulnerability, part of a set of security vulnerabilities affecting Lilin DVRs, was discovered in 2020 and was assigned a CVSS v3.1 score of 10.0 (Critical) by the vendor.
The scanner will send particularly crafted HTTP POST requests to the URL paths /dvr/cmd and /cn/cmd in order to exploit a command injection vulnerability in the web interface.
First, the scanner attempts to inject some code by submitting a POST request to the URL path /dvr/cmd. If successful, this request then modifies the NTP configuration of the camera. The modified configuration contains a command that, because of the vulnerability, will attempt to download a file named wget.sh from the IP address 136.144.41[.]169 and then immediately execute its content. If the command injection to /dvr/cmd is not successful, the scanner attempts the same attack to the endpoint /cn/cmd.
Once the attack is complete, another request to the same endpoint restores the original NTP configuration.
The file wget.sh recursively downloads multiple executables for multiple architectures from 136.144.41[.]169. The targeted architectures are ARM, Motorola 68000, MIPS, PowerPC, SPARC, SuperH, x86.
The Mirai Malware Family
In the third stage of this attack, multiple malicious samples for each architecture attempt to execute on the camera. These samples belong to the Mirai malware family, which is a widely known threat to IoT devices. All these samples have recently been submitted to VirusTotal (at the beginning of March 2022). For example, for the MIPS architecture, two samples have been identified as the third stage connected to the Mirai family:
- ae0185189e463c6abddf8865972dac72630b6e515e79d3f7566f0983a0eae295
- 28f50f24c930b595f88257748f62d985436ecce1330ff52f09cdd13642591450
For x86 architecture, the file 62ef086111b6816d332e298d00ac946c11fac0ed8708fa2668ad3c91ceb96dbf is downloaded and executed. An analysis of this sample reveals some typical behaviors of the Mirai malware. For example, while scanning new devices, Mirai typically bruteforces the authentication using a list of hardcoded credentials. In Figure 9, there is a non-exhaustive list of credentials used for the bruteforce. This list comes from the Mirai source code.
From the static analysis of the downloaded sample, we retrieved a list of credentials used in the scanning module, many of which are the same as the ones hardcoded in the Mirai source code.
Another behavior associated with the Mirai botnet is the exclusion of IP ranges belonging to the internal networks of the U.S. Department of Defense (DoD), U.S. Postal Service (USPS), General Electric (GE), Hewlett-Packard (HP), and others. Some of them are visible in Figure 11, which is taken from Mirai’s source code.
The same IP ranges are excluded from the scanning procedure in the sample we are analyzing. Moreover, we see that the verification of a randomly generated IP follows the same algorithm as the one implemented in Mirai’s source code.
It seems that this tool has been quickly built using the code base of the BotenaGo malware. It shouldn’t be confused with a worm as its main goal is to infect its victims with Mirai executables with a list of IP addresses provided as input; it can’t automatically propagate itself.
Conclusion
Apart from working on completely new projects, attackers also commonly re-use already available code to build new malware. Monitoring the evolution of these projects helps create more robust and generic detections that remain proactive for a longer time, thus providing better protections against modern cyberthreats.
