Overview
In early July 2023, we captured a previously unknown sample of a DDoS Botnet family, which borrows many basic functions from the Mirai source code but has undergone significant modifications in host behavior and network control protocols. Multiple core functions in the sample are prefixed with "ripper_," leading us to name this family "Ripper."
Through our analysis of the sample and its Command and Control (C&C) associations, we discovered that this family has been spreading for several months, with substantial changes between earlier and current samples. After careful review, we temporarily classify Ripper into three versions: V0, V1, and the latest V2.
Ripper's propagation mechanism is reminiscent of Mirai: the sample contains a built-in Telnet weak password scanning module, which reports scan results to the Report Server. Attackers use these results to control the Loader and implant Ripper's Trojan files into compromised hosts. In the latest Ripper V2, the C&C also updates the weak password dictionary used in sample scanning dynamically based on specific instructions. From our threat monitoring system, we observed an active propagation wave of Ripper V2 from 7.4 to 7.6.
Analysis of Sample Key Behavior
Using the following Ripper V2 sample as an example, we conducted an analysis of its key characteristics:
| - | - | - | - |
|---|---|---|---|
| File Name | File Type | File Size | MD5 |
| loki.arm6 | ELF 32-bit LSB executable, ARM | 105760 bytes | c244f9422006848e3893d0b8b8fc6b8f |
Initialization and Preparation
Initially, the sample attempts to reset iptables rules using the following command:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t NAT -F
iptables -t mangle -F
iptables -t NAT -F
iptables -F
iptable -X
Next, Ripper V2 outputs "exec\r\n" to the console, initializing the random function with rand_init() ported from Mirai. It then sets the C&C server address and port required for sample operation using the init_load_address() function. Finally, it starts a local Socks5 service on port 63254, which can be used as a Socks5 proxy node. Upon successful startup of the Socks5 service, it outputs "START-S5\n" to the console.
Ripper V2 sets up three groups of working C&C servers, with the addresses being the same but the ports different:
- util_srv_addr: A self-established domain resolution service address used for resolving target domain names in the attack instruction parsing and Socks5 proxy service, port 15757.
- cnc_srv_addr: C&C controlled server address, port 15636.
- report_srv_addr: Server address for reporting scan results, port 20216.
Ripper V2's C&C address strings are transformed through custom encoding logic and need to be decoded via the lets_encrypt() function. For the built-in C&C "15.217.144.198," decoding it involves swapping the first and last characters, resulting in "85.217.144.191" as its C&C IP.
C&C Communication
The first step is to establish communication with the C&C server, and Ripper V2 uses the UDP protocol for this purpose:
Online
The data packets sent by Ripper V2 Bot to the C&C come in three types:
| - | - |
|---|---|
| Instruction | Code Description |
| 0x55 | Online status |
| 0x29 | Report Socks5 service port |
| 0x36 | Pong |
Once successfully connected to the C&C, the sample immediately sends an online packet. The first byte of the online packet is the instruction code 0x55, followed by the sample's startup parameter (bot_tag). After concatenating them, the data is sent using the cnc_send() function:
The cnc_send() function adds a prefix and suffix to the data to serve as markers for the data's start and end:
- Prefix: "\x00\x01\x02"
- Suffix: "\x02\x01\x00"
As a result, if the sample's startup path is "/tmp/loki", the final data sent in the online packet will be as follows:
00000000 00 01 02 55 2f 74 6d 70 2f 6c 6f 6b 69 02 01 00 |...U/tmp/loki...|
00000010
If the Socks5 service was successfully started, Ripper V2 will also report the Socks5 service port (63254) to the C&C server. The instruction code for reporting the Socks5 service is 0x29, and it is also sent as a report using the cnc_send() function, with the data packet as follows:
Instruction Parsing
Ripper V2's current samples support the following control instructions:
| - | - | - |
|---|---|---|
| Instruction Code | Description | Remarks |
| 0x33 | Start Scan Task | If recv data length>2, it means a weak password dictionary is simultaneously distributed. |
| 0xde | Resend Online Packet | |
| 0xdf | Kill Bot | |
| 0xed | Stop DDoS Attack | |
| 0xef | Initiate DDoS Attack | |
| Ping | Ping No instruction code（"\x00\x01\x02\PING\x02\x01\x00\x00"） |
C&C sends instructions to the Bot, and each instruction is accompanied by a prefix and suffix byte sequence. Unlike the data sent by the Bot to C&C, the prefix used here is "\x00\x01\x02", and the suffix is "\x02\x01\x00\x00". When the Bot sample receives data from the C&C, it detects the prefix and suffix to determine a complete instruction data packet. It removes the prefix and suffix byte sequences and then parses the instruction content.
After the successful online status of the sample, C&C generally issues an instruction to start a scanning task and includes a set of weak passwords for scanning. The data packet structure is as follows:
Note the data of the weak password list; each pair of weak passwords is separated by "0xFF", and a util_tokenize() function is called to parse these multiple groups of weak passwords separated by "0xFF"：
When the cmd_code is 0xef, Ripper V2's Bot initiates a DDoS attack. The pseudo-code structure of the instruction data packet is as follows:
struct cmd_pkt {
uint8[3] prefix; // "\x00\x01\x02"
uint8 cmd_code;
uint32 target_ip;
uint16 target_port;
uint32 duration;
uint8 atk_code;
uint8 atk_flag_cnt;
atk_flag[atk_flag_cnt] flags;
uint8[4] subffix; // "\x02\x01\x00\x00"
}
struct atk_flag {
uint8 flag_type;
uint8 flag_len; // flag data length (bytes)
char[flag_len] flag_data; // flag data, up to 64 bytes
}
Ripper V2 supports 7 types of DDoS attack methods:
| - | - |
|---|---|
| attack code | attack method |
| 0 | UDP Flood |
| 1 | UDP Plain Flood |
| 2 | UDP Raw Flood |
| 3 | TCP Plain Flood |
| 4 | TCP RAW Flood |
| 5 | MIX Flood |
| 6 | HTTP Flood |
Ripper V2's Attack Flag data structure design is derived from Mirai but with significant differences in the specific supported Attack Flags. Ripper V2 supports 6 custom Flags:
| - | - |
|---|---|
| flag code | flag description |
| 1 | Domain name |
| 2 | Attack payload size |
| 3 | TCP Flag ([a |
| 4 | Socket Option(non_block |
| 5 | Number of attack rounds |
| 6 | Number of attacks per round |
Ripper V2's attack instruction parsing logic is quite complex. It breaks down all the instruction parsing and attack functions in Mirai and writes them in an inline form within a function. The function's size is significant and can provide some resistance to reverse analysis. The function structure is as follows:
If the attack instructions received by the Bot include attacks against domain name targets, Ripper V2 first calls a custom domain resolution function, resolve_address(), to resolve the domain name by accessing its own service:
As shown in the diagram above, the Bot accesses its own service (util_srv, which has the same address as the C&C, port 15757) using the UDP protocol. The payload sent has the first byte as a fixed "\x01", the second byte as the length of the domain name to be resolved, and the domain name string attached. The payload structure pseudo-code is as follows:
struct domain_resolv_payload {
_uint8 code; // "\x01"
_uint8 domain_len;
char[domain_len] domain_str;
}
Then, the Bot reads data from the server, and if the length of the read data is 4, it indicates that the domain name resolution was successful, and it returned a 4-byte IP address.
Sample-level Version Evolution
We discovered three versions of the Ripper family samples, which have significant differences in functional details, but also share evident common features, making it possible to classify them into the same family:
- Key functions all start with "ripper_ " and there are many other similar functions with the same functionality and names.
- Both V0 and V1 versions have the file name "boat.{CPU_ARCH}".
- They share the same util_tokenize() function, which performs specific parsing and splitting based on certain delimiters, and prefers to use 0xFF as the delimiter.
- Network packets are designed with specific prefix and suffix byte sequences.
We will now perform a detailed analysis of these features.
Ripper V0 Sample
| - | - | - | - |
|---|---|---|---|
| File Name | File Type | File Size | MD5 |
| boat.arm7 | ELF 32-bit LSB executable, ARM | 94644 bytes | b73116306de407394bee825ff4d95091 |
Continuous output of the following three strings in the terminal:
"Komorebi\r\n"
"Domorebi\r\n"
"Xomorebi\r\n"
C&C hard-coded in plaintext in the sample:
Ripper V0 Instruction Features:
- All instructions end with the 4-byte sequence "\r\n\n\r".
- Each field in the instructions is separated by "0xFF" as a delimiter.
Summary of Instructions:
| - | - | - |
|---|---|---|
| Direction | cmd code | Function |
| Bot->C2 | 0x00 | Online |
| C2->Bot | 0x01 | Stop DDoS attack |
| C2->Bot | 0x00 | Initiate DDoS attack |
Ripper V0 supports the following DDoS attack methods and their corresponding Attack Codes:
Online package: The first byte is 0x00, the second character is the delimiter character 0xFF, the third part is the first command-line startup parameter, and finally, the data package is marked with "\r\n\n\r".
Instruction packets also end with "\r\n\n\r". The sample removes the last 4 characters before parsing and executing the instructions.
In the function cmd_handle(), the sample calls the util_tokenize() function to split and reassemble the data received from C&C using "0xFF" as a delimiter, and then executes the corresponding action based on the parsed instructions.
The decompiled result of the util_tokenize() function is as follows:
Ripper V1 Sample
| - | - | - | - |
|---|---|---|---|
| File Name | File Type | File Size | MD5 |
| boat.arm7 | ELF 32-bit LSB executable, ARM | 136411 bytes | e9c5048652f4263d9daf4a3af5c3709d |
Output string in the terminal: "EXECUTED\r\n"
C&C is still hardcoded in the sample, but the same C&C IP has two server ports:
- 5900, the regular C&C server port used to control Bot behavior.
- 5901, the API Server port used to provide Bot with data used during operation, such as Scanner passwords, Table Entry related data, etc.
The online package of Ripper V1 contains more information than Ripper V0, and the explanation of each field is as follows:
| - | - | - | - |
|---|---|---|---|
| field | offset | length(bytes) | default value |
| cmd_code | 0 | 1 | 0x0 |
| bot_version | 0 | 4 | "\x00\x00\x00\x40" |
| bot_id(argv[0]) | 4 | len(bot_id) | |
| bot_edianess | len(bot_id)+4 | 1 | |
| bot_cpu_arch | len(bot_id)+5 | 1 | |
| bot_cpu_cores | len(bot_id)+6 | 1 | |
| bot_mem_mb | len(bot_id)+7 | 4 |
The first byte is a fixed "0x00," representing the online package. Next is the 4-byte bot_version, with a fixed value of "\x00\x00\x00\x40", and each field after that is separated by "0xFF".
The data received by the sample from C&C's API Server is also separated by "0xFF" as a field delimiter, and it is parsed and reassembled using the same util_tokenize() function as Ripper V0.
The structure of Ripper V1 attack instruction packets is significantly different from that of Ripper V0. In Ripper V0's attack instruction data, each field is separated by "0xFF" and ends with "\r\n\n\r". However, in Ripper V1's instruction packet, a fixed-length structure is used, and there are no separators between the fields. The structure is as follows:
| - | - | - |
|---|---|---|
| field | offset | length |
| UNKOWN | 0 | 1 |
| attack code | 1 | 1 |
| target host | 2 | 4 |
| target port | 6 | 2 |
| duration | 8 | 4 |
The first byte is directly discarded：
The rest of the data is then parsed to extract the fields and reassemble the structure used for DDoS attacks：
Ripper V1 supports the following DDoS attack methods and their corresponding instruction codes:
| - | - |
|---|---|
| attack code | attack type |
| 0 | ICMP Flood |
| 1 | UDP Plain Flood |
| 2 | TCP Plain Flood |
| 3 | TCP Flood |
| 4 | HTTP Flood |
Summary
Currently, we have captured dozens of attacks initiated by Ripper V2, targeting various entities, including the cryptocurrency exchange 1million.exchange, WarnerMedia's DNS server 74.74.74.74, and the UK Independent's official website www.independent.co.uk.
Due to the frequent changes and continuous upgrades of Ripper at the sample level, as well as its gradual expansion into DDoS attacks, we will continue to monitor the activities of the Ripper family.
IoC
MD5
b73116306de407394bee825ff4d95091
364a1676d638e5069ab88cb98288bef2
4a1fb73a6f09468b8ab0fc7478fe715a
4d3312115eb5694a7e7769867fcf227a
53fa2ebff19861c6a381d802a8bef9ba
79ee10eb0c48c8bf4fa6deb342db1a99
8845e1c8daf7545bfde3ddf6729664a4
908ab5382ee42c0ab034820730d6ba09
99ab1760db8fe89b556a943afdd105ee
bc87628437819895c031ecb72a70659a
c55cbde42ff1cbf09ed07ca98ca1f017
e9c5048652f4263d9daf4a3af5c3709d
015e73f206790663b1efba854d9888ee
087b071253958042dd74d53475666d78
78f1155bc7a9c0a89a3d30992e0efb5f
1387c774b707ab1c379acc3ef882b214
c244f9422006848e3893d0b8b8fc6b8f
C2
85.217.144.191:15636
85.217.144.191:15757
85.217.144.191:20216
194.55.224.126:1738
194.55.224.182:5900
194.55.224.182:5901