A new malware campaign targets Redis servers to deploy the mining crypto miner Migo on compromised Linux hosts.
Caro Security researchers have observed a new malware campaign targeting Redis servers with a crypto miner dubbed Migo. The campaign stands out for the use of several novel system weakening techniques against the data store itself.
Migo is a Golang ELF binary with compile-time obfuscation, it is also able to maintain persistence on Linux hosts.
The researchers also observed the malware using a new version of a popular user mode rootkit to evade detection by hiding processes and on-disk artifacts.
The researchers initially discovered that new ‘Redis system weakening commands’ have been used in attacks in the wild, and then they noticed that these commands were used in a recent malware campaign aimed at Redis systems.
One of the honeypots used by Cado was targeted by an attack originating from the IP 103[.]79[.]118[.]221 which disabled the following configuration options using the Redis command line interface’s (CLI) config set feature:
- set protected-mode;
- replica-read-only;
- aof-rewrite-incremental-fsync;
- rdb-save-incremental-fsync;
The attackers disabled these options to send additional commands to the Redis server and allow future intrusion evading defense.
“After disabling these configuration parameters, the attacker uses the set command to set the values of two separate Redis keys.” reads the report published by Cado Security. “One key is assigned a string value corresponding to a malicious attacker-controlled SSH key, and the other to a Cron job that retrieves the malicious primary payload from Transfer.sh (a relatively uncommon distribution mechanism previously covered by Cado) via Pastebin.”
The main Migo payload (/tmp/.migo) is distributed as an ELF file packed with UPX, statically linked and stripped. This ELF file can target x86_64 architecture. The sample employs standard UPX packing, preserving the UPX header, and can be easily unpacked using the command upx -d.
Upon execution, the Migo binary checks the presence of a file at /tmp/.migo_running. If this file doesn’t exist, the malicious code creates it, determines its own process ID and writes it out the file. The file is a sort of infection market for the attacker.
Then the binary downloads an XMRig installer hosted on GitHub, terminates competing miners and establishes persistence, then it launches the miner.
Below a series of actions performed by the binary:
In summary, they perform the following actions:
- Make the copied version of the binary executable, to be executed via a persistence mechanism
- Disable SELinux and search for uninstallation scripts for monitoring agents bundled in compute instances from cloud providers such as Qcloud and Alibaba Cloud
- Execute the miner and pass the dropped configuration into it
- Configure
iptablesto drop outbound traffic to specific IPs - Kill competing miners and payloads from similar campaigns
- Register persistence via the systemd timer
system-kernel.timer
Migo demonstrates the interest of threat actors in targeting cloud infrastructure for mining purposes. The attackers continue to improve their capability to exploit web-facing services.
Researchers believe that the Migo developers possess knowledge of the malware analysis process, implementing extra measures to obscure symbols and strings within the pclntab structure, thereby complicating reverse engineering.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – ransomware, miner)
