New Threat: ZHtrap botnet implements honeypot to facilitate finding more victims
Overview
In the security community, when people talk about honeypot, by default we would assume this is one of the most used toolkits for security researchers to lure the bad guys
. But recently we came across a botnet uses honeypot to harvest other infected devices, which is quite interesting.
From February 28, 2021, our BotMon system started to see one IP (107.189.30.190
) continuously spreading a batch of unknown ELF samples. After analysis, we confirmed that these samples belonged to a new botnet family, we named it ZHtrap
, and it has the following characters.
- ZHtrap's propagation uses 4 Nday vulnerabilities, the main function is DDoS and scanning, while integrating some backdoor features.
- Zhtrap sets up honeypot on the infected device.
- Zhtrap takes snapshots for 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 previous reported, using Tor and cloud-based configuration.
ZHtrap Full Introduction
ZHtrap's code is based on Mirai and supports x86, ARM, MIPS and other major CPU architectures. However, compared to Mirai, ZHtrap has changed a lot, which is reflected in the following aspects.
- In terms of instructions, a checksum mechanism has been added
- In terms of scanning propagation,
the distinction between real devices and honeypots has been added
. - In terms of encryption algorithm, a set of multiple XOR encryption algorithm has been redesigned.
- In terms of host behavior, it can turn the compromised device into a simple honeypot and implement a set of process control mechanisms
- In terms of network architecture, it borrows some implementations of our previously exposed Matryosh botnet
The basic process is shown in the following diagram.
In terms of functionality, in addition to DDoS attacks and scanning, ZHtrap also implements backdoor functionality, which increases the harmfulness of the family. specific functions of ZHtrap include
- Process control
- Reversing Shell
- DDoS attacks
- Telnet scanning
- Exploit propagation
- Turn infected devices into honeypot
- Download and execute Payload
The ZHtrap samples we have captured so far can be divided into 3 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 the analysis in this paper is based on the most fully functional v2 version.
Compared to other botnets we have analyzed before, the most interesting part of ZHtrap is its ability to turn infected devices into honeypot. Honeypots are usually used by security researchers as a tool to capture attacks, such as collecting scans, exploits, and samples. But this time around, we found that ZHtrap uses a similar technique by integrating a scanning IP collection module, and the collected IPs are used as targets in its own scanning module, with the basic process shown below.
ZHtrap will listen to 23 designated ports (as shown in the above figure), and if it finds an IP connecting to these ports it will record it as a scanner IP, and all the recorded IPs will be scanned in its own scanningmodule, so that the target addresses used in the ZHtrap scanning process will have 2 sources.
- Randomly generated IPs.
- Scanner IPs captured by the above module.
More details on this can be found in the sample analysis section below.
Sample Reverse Analysis
Here we pick ZHtrap v2's X86 CPU architecture sample for analysis, with the following basic information.
MD5:5370e0b9484cb25fb3d5a4b648b5c203
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Packer:None
After ZHtrap successfully infects the device, it creates a single instanceby binding local port, then decrypts the encrypted resource information and renames the process to /bin/ZoneSec
, and then prints out the following message in the ConsoleZH 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 & propagation phase. Then listen to 23 pre-de-fined ports to turn the device into a "honeypot", waiting for other compromised devices to hit the port.It uses 4 Nday vulnerability to achieve worm-like propagation. Fi-nally, it communicates with the TOR C2 and waits for the execution of the commands issued by the C2.
0x0 Encryption algorithm
ZHtrap uses a relatively rare multiple xor encryption algorithm to hide resource information.
The equivalent python implementation is shown below.
xor_key_lst = [0x51, 0x6A, 0x66, 0x6A, 0x78, 0x53, 0x52, 0x44, 0x46, 0x47, 0x53, 0x46, 0x44, 0x64, 0x66] #QjfjxSRDFGSFDdf
xor_key = 0xD00DBAAF
def decode(content):
desc_lst = []
plaintext=""
xor_key_lst_idx = 1
for idx in range(0, len(content)):
desc_lst.append(chr(content[idx] ^ (xor_key % 0xFF) ^ xor_key_lst[xor_key_lst_idx - 1] ^ (xor_key_lst_idx + idx)))
xor_key_lst_idx += 1
if xor_key_lst_idx >= len(xor_key_lst):
xor_key_lst_idx = 0
else:
print("".join(desc_lst))
Take the following ciphertext as an example
cipher =[
0x42, 0x69, 0x0B, 0x4C, 0x57, 0x76, 0x72, 0x60, 0x6B, 0x79,
0x6A, 0x39, 0x6C, 0x58, 0x55, 0x7B, 0x10, 0x49, 0x5C, 0x41,
0x75, 0x2A, 0x32, 0x43, 0x48, 0x4C, 0x5B, 0x45, 0x61, 0x56,
0x26, 0x6E, 0x68, 0x27, 0x78, 0x5C, 0x11, 0x45, 0x48, 0x4D,
0x4B, 0x54, 0x49, 0x71, 0x22, 0x43, 0x7D, 0x3C, 0x75, 0x69,
0x4E, 0x50, 0x51, 0x42, 0x2A, 0x79, 0x2B, 0x39, 0x17, 0x70,
0x50, 0x6E, 0x4F, 0x49, 0x51, 0x2E, 0x36, 0x2E, 0x28, 0x2F,
0x69, 0x6D, 0x69, 0x42, 0x51, 0x7C, 0x40, 0x5E, 0x02, 0x01,
0x3E, 0x27, 0x37, 0x20, 0x32, 0x13, 0x09, 0x1A, 0x39, 0x57,
0x2A, 0x12, 0x04, 0x63, 0x27, 0x09, 0x14, 0x11, 0x11, 0x07,
0x06, 0x51, 0x1C, 0x36, 0x2B, 0x5C, 0x14, 0x2F, 0x3C, 0x27,
0x27, 0x0D, 0x0C
]
After decryption, we get the following plaintext, which is exactly the in the Console prompt
ZH infected your shit, message me on discord to compare assets ($reiko#0095), researchers hmu twitter[.]com/ZoneHax
There are 3 encrypted messages in the current sample, and the decrypted message is shown below, where /proc/
and /stat
are used in the next section on process control.
index | plaintext |
---|---|
2 | /stat |
1 | /proc/ |
0 | ZH infected your shit..... |
0x1 Process Control
ZHtrap realizes process control through the whitelist and snapshot mechanism to aceive the exclusivity of the device. A process whose executable path contains the following path is considered a whitelisted process. After ZHtrap is started, it will first obtain the current process list, and then terminate the non-whitelisted processes through kill -9. So it is clear that ZHtrap does not want to destroy the normal operation of the system.
/bin
/sbin
/user/bin
/user/sbin
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, and even if the administrator finds a problem with the device, many system management tools are no longer working properly, making maintenance a difficult task.
Clean up 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 get 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 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.
Create a snapshot of the processes and clean up any new processes that aren't on the mark.
After cleaning the non-whitelisted processes, ZHtrap considers the sys-tem to be in a "pure state" and creates a process snapshot for the system first.
After that, all newly created processes will be compared with the process snapshot, and any processes that do not meet the requirements will be directly killed.
0x2 Get 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, thefirst step is to establish communication with the Tor domain, the sec-ond step sends "GET /sfkjdkfdj.txt" request.
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 returns05 00 00 01 00 00 00 00 00 00 00
, that means the communication has been successfully established. Then send a subsequent GET request to get the resource server address (107.189.30.190), and the network traffic in the following figure clearly reflects this process.
The role of Resource server
As can be seen by the IDA cross-reference in the above figure, the ResServ has two functions.- Acting as Reporter Server, providing information upload service for the Telnet scanning process
- Acting as Downloader Server, to provide sample download services for the process of vulnerability propagation
0x3 Honeypot
ZHtrap first creates two pipes for information transfer, and then implements a simple honeypot listening on the following 23 ports
The actual effect is as follows.
Why does it do this?
We speculate that ZHtrap's authors had this in mind.
Many botnets implement worm-like scan propagation, and when ZHtrap's honeypot port is accessed, its source is most likely a device that has been infected by another botnet. This device can be infected, there must be flaws, I can use my scanning mechanism to scan again.This could be a good chance that I can implant my bot samples, and then with the process control function, I can have total control, is’t that awesome?
0x4 Telnet scan
ZHtrap uses Telnet scanning to collect devices that use weak passwords. The sources of the scanned objects are of the following 2 types.
- Randomly generated IPs
- Passively received IPs delivered by the above mentioned honeypot
And these two group of IPs get to treat differently.
For category 1
IPs, SYN port probing is used.
For category 2
IPs, use the connect
function directly.
When the target's port 23 is found to be open, try to log in using the hardcoded credentials list, and pass the following code back to the resource server for the IP, port, account, password, etc. that can successfully log in.
During the login attempt, ZHtrap will ask the scanned device to execute the following command:
enable
linuxshell
system
bash
ls /home
ps aux
/bin/busybox ZONESEC
The device type is then determined based on the returned information,and the device will be regarded as a honeypot when it contains the following string.
string | honeypot |
---|---|
Jun22 | cowrie |
Jun23 | cowrie |
phil | cowrie |
sshd: | cowrie |
richard | cowrie |
@LocalHost:] | cowrie |
Welcome to EmbyLinux 3.13.0-24-generic | telnet-iot-honeypot |
If it is a honeypot, the device information will be reported to the resource server via port 2231. | |
If it is a real device, the device information will be reported to the resource server on port 1282
0x5 Vulnerability scanning & propagation
ZHtrap uses the following 4 samples of Nday vulnerability propagation
First construct a SYN packet to probe whether the device's port is open, and the list of supported ports (exp_port) is shown below
80 | 8080 | 8081 | 8083 | 5500 |
---|---|---|---|---|
60001 | 52869 | 8089 | 8090 | 8000 |
81 | 82 | 83 | 84 | 85 |
8888 | 8181 | 8443 | 5555 | |
Then a "GET /" request is sent to obtain information about the service running on the port. | ||||
The following code snippet is then used to determine whether the banner information returned by the service is the target device. | ||||
Finally, according to the banner information, select the corresponding vulnerability, and ResServ to assemble a valid payload to try to implant.
As with the telnet scanning process, the sources of the scanned objectsare of the following two types.
- Active randomly generated IP
- Passively receive IPs delivered by the honeypot
For the first category of IPs, an exp_port is randomly selected for probing, and the relationship between IPs and exp_ports is 1 to 1.
For the second category of IPs, all exp_ports are probed, and the relationship between IPs and exp_ports is 1 to N. The network traffic in the following figure illustrates this situation visually.
0x6 C2 communication
ZHtrap uses Tor C2 and therefore has to communicate with C2 with the help of a proxy. This process is described in section above and will not be repeated here. The network traffic shown in the figure below indicates that the connection with C2 has been successfully established.
Next, the following code snippet is used to send a registration message to C2
The actual network traffic generated is as follows.
The command packet of ZHtrap consists of two packets, the first packet is the header and the second packet is the body, where the format of the header is
//5 bytes ,big endian
struct header
{
uint16 body_len;
uint8 cmd_type;
uint16 checksum;
}
Take the above registration packet traffic as an example, the meaning of each field is as follows.
header:
00 07 -- length of body
e5 -- hardcode,cmd type,"e5",
1a fa -- tcp/ip checksum of ("00 07 e5 00 00")
body:
5a 6f 6e 65 53 65 53 -- body string,"ZoneSec"
After sending the registration packet, bot starts to wait for C2 to send the command, and when the header of the command packet successfully passes the check, it selects the corresponding processing flow based on the command type specified by the third byte in the header.
It can be seen that a total of five kinds of commands are supported at present, and the correspondence between command codes and functions is shown in the following table.
Value | Function |
---|---|
0x22 | heartbeat |
0x45 | exit |
0x89 | download&exec payload |
0xF5 | reverse shell |
0xFE | DDoS |
Taking heartbeat as an example, the heartbeat packet network flow in the following figure verifies our analysis. | |
Contact us
Readers are always welcomed to reach us on twitter, or email to netlabat 360dot cn.
IOC
Sample MD5
5370e0b9484cb25fb3d5a4b648b5c203
6c7cfbe0277e2ca0cbe7157cad7c663e
f1f70dc1274112ae5287ceb06f096d0e
9dded61f7de47409bc00e74c0a12210e
7b593fbbd6f81a3e9a2043a46949879d
ba17282481acca9636c5d01f5c2dd069
URL
0xdeadbeef.tw
h5vwy6o32sdcsa5xurde35dqw5sf3cdsoeewqqxmhoyzsvar4u6ooead.onion:8080
C2
oemojwe5loscudytzfo273nkdvalf7mumctwcm42zyutoo6tpfjsphyd.onion:3000
Reporter
107.189.30.190:1282
107.189.30.190:2231
Proxy Ip
51.178.54.234:9095
51.79.157.89:9095
167.114.185.33:9095
147.135.208.44:9095
198.245.53.58:9095
142.93.247.244:9050
66.70.188.235:9095
139.99.134.95:9095
144.217.243.21:9095
46.101.61.9:9050
Downloader
x86 arm5 arm6 arm7 mips
hxxp://107.189.30.190/bins/z.{CPU_ARCH}
oemojwe5loscudytzfo273nkdvalf7mumctwcm42zyutoo6tpfjsphyd.onion:8080/z.{CPU_ARCH}