In the security community, when people talk about honeypots, the standard assumption is that it’s a toolkit to lure in malicious actors. But recently, we at Netlab360 came across a botnet using a honeypot to harvest other infected devices.
We hadn’t seen a botnet like this before so it warranted some analysis.
ELF makes mischief
From 28 February 2021, our BotMon system started to see one IP (107.189.30.190) continuously spreading a batch of unknown Executable and Linkable Format (ELF) samples. After analysis, we confirmed that these samples belonged to a new botnet family. We named it ZHtrap, and it has the following characteristics:
- ZHtrap’s propagation uses four Nday vulnerabilities; the main function is DDoS and scanning, and it integrates some backdoor features
- Zhtrap sets up a honeypot on the infected device
- Zhtrap takes snapshots of the victim devices, and disables the running of new commands based on the snapshot, thus achieving exclusivity over the device
- For C2 communication, ZHtrap takes a cue from the Matryosh botnet we previously reported, using Tor and cloud-based configuration
A closer look at ZHtrap
ZHtrap’s code is based on Mirai and supports x86, ARM, MIPS and other major CPU architectures. However, compared to Mirai, ZHtrap has evolved some sneaky new features:
- Instructions: A checksum mechanism has been added
- Scanning propagation: The distinction between real devices and honeypots has been added
- Encryption algorithm: A set of multiple XOR encryption algorithms has been redesigned
- Host behaviour: It can turn the compromised device into a simple honeypot and implement a set of process control mechanisms
- Network Architecture: It borrows some implementations of our previously exposed Matryosh botnet
The basic process used by ZHtrap is shown below in Figure 1.
In addition to DDoS attacks and scanning, ZHtrap also has backdoor functionality, making it even more dangerous. Specific functions of ZHtrap include:
- Process control
- Reversing shell
- DDoS attacks
- Telnet scanning
- Exploit propagation
- Turning infected devices into honeypots
- Downloading and executing the payload
Varieties of ZHtrap
The ZHtrap samples we have captured so far can be divided into three versions according to their functions: v1, v2 and v3:
- v2 is based on v1 with the addition of vulnerability exploitation
- v3 is based on v2 with the deletion of the network infrastructure
Their relationship is shown in the figure below, and we primarily analyse the most fully functional version, v2.
Compared to other botnets we have analysed, the most interesting part of ZHtrap is its ability to turn infected devices into honeypots. Honeypots are usually used by security researchers as a tool to capture attacks, such as collecting scans, exploits, and samples. ZHtrap uses similar techniques by integrating a scanning IP collection module, and the collected IPs are used as targets in its own scanning module, as shown in Figure 3 below.
ZHtrap listens to 23 designated ports, as shown in Figure 3 above, and upon finding an IP connecting to these ports, records it as a scanner IP. All the recorded IPs are scanned in its own scanning module.
Read: Skidmap and malicious DNS data mining
Target addresses used in the ZHtrap scanning process come from two sources —randomly generated IPs or scanner IPs captured by the ZHtrap module.
After ZHtrap successfully infects the device, it creates a single instance by binding the local port, then decrypts the encrypted resource information and renames the process /bin/ZoneSec. ZHtrap then prints out the following message in the Console:
ZH infected your shit, message me on discord to compare assets ($reiko#0095), researchers hmu twitter[.] com/ZoneHax
Next, a network request is made to get the address of the resource server for the scanning and propagation phase. ZHtrap then listens to the 23 predefined ports to turn the device into a honeypot, waiting for other compromised devices to hit the port. It uses the four Nday vulnerabilities to achieve worm-like propagation. Finally, it communicates with the TOR C2 and waits for the execution of the commands issued by the C2.
How ZHtrap seizes the device
ZHtrap controls processes on the device through the whitelist and snapshot mechanism to achieve exclusive control. A process whose executable path contains the following path is considered a whitelisted process:
/bin
/sbin
/user/bin
/user/sbinAfter ZHtrap starts, it first obtains the current process list, and then terminates the non-whitelisted processes through kill-9.
It is clear that ZHtrap does not want to halt all normal operations of the system.
Next, a snapshot of the processes is created for the system, after which the newly created processes are compared with the snapshot, and those that do not meet the requirements are removed. In this way, the whole system remains under ZHtrap’s control. Even if the administrator finds a problem with the device, many system management tools will no longer function properly, making maintenance a difficult task.
How ZHtrap removes non-whitelisted processes
When ZHtrap runs, it iterates through the current processes on the system and reads the value of starttime, item 22 in /proc/pid/stat. This value is divided by _SC_CLK_TCK to determine how long the process was started after the kernel started. The value of _SC_CLK_TCK is usually equal to 100, 10000/_SC_CLK_TCK results in 100 seconds. So all processes that started after 100 seconds of kernel startup will be checked, and if the process path is not in the whitelist, the process will be killed.
Getting the address of the resource server
ZHtrap uses the following code snippet to get the address of the resource server (ResServ), this process can be divided into two steps. The first step is to establish communication with the Tor domain, the second step sends the GET /sfkjdkfdj.txt request.
It also needs to establish communication with the Tor domain.
ZHtrap takes a cue from the Matryosh botnet, first requesting a DNS TXT record from the remote host 0xdeadbeef.tw to get the list of Tor proxies in the figure below.
It will pick one proxy and send domain:port; if the proxy returns 05 00 00 01 00 00 00 00 00 00 00, that means that communication has been successfully established. ZHtrap then sends a subsequent GET request to get the resource server address (107.189.30.190).
Read: Using DASH to identify economies by suspicious traffic
The resource server has two functions. It acts as the reporter server, providing information upload services for the Telnet scanning process. It also acts as the downloader server, to provide download services for vulnerability propagation.
Why use a honeypot?
We believe that ZHtrap’s creators had something specific in mind.
Many botnets implement a worm-like scan propagation method, and when ZHtrap’s honeypot port is accessed, its source is most likely a device that has been infected by another botnet.
Therefore, it would seem most likely that if the device can be infected, it must have some flaws that can be exploited. The botnet uses its scanning mechanism to scan again, as it may be an opportunity to implant the bot samples and gain total control via the process control function.
Alex Turing is a malware researcher at NetLab 360.
This post was adapted from the original at Netlab 360 Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.