Cloud attackers are stepping up their game in a new cryptojacking campaign that targets exposed Redis deployments, researchers warn. Compared to previous attacks against the in-memory data store, the perpetrators make use of certain system weakening commands before installing their cryptocurrency mining malware.
Researchers from Cado Security have dubbed the new miner Migo and note that it’s being deployed together with a user mode rootkit whose goal is to hide processes and on-disk artifacts. The malware also comes with a persistence mechanism to ensure its survival across reboots.
Why Redis is a popular attack vector
Redis is a versatile in-memory storage system that can be used both as a database and as a cache store due to its low-latency read and write operations. This makes it a very popular choice for building a large variety of cloud-based applications with its users including large technology companies such as Twitter, Airbnb, Tinder, Adobe, Hulu, Amazon, and OpenAI. Redis, together with other popular cloud-native technologies like Kubernetes, Docker, Jupyter Notebook, and Hadoop have become main targets for botnets that scan the internet for unprotected or vulnerable instances to compromise Linux servers that can then be hijacked for DDoS attacks or cryptomining.
Examples of such botnets include the Silentbob worm reported in July 2023, which is suspected to be the creation of a gang called TeamTNT, or the Rust-based P2PInfect worm that compromised Redis instances by exploiting a Lua sandbox exploit vulnerability (CVE-2022-0543). Redis allows its users to upload and execute Lua scripts on the server to extend its functionality.
How the Migo attackers weaken systems
If they manage to connect to an unprotected Redis instance, the attackers behind the new Migo campaign use the Redis command line interface (CLI) to change important configuration options from their default values. These commands have not been seen in other Redis attacks, the Cado researchers said.
The first command is “config set protected-mode no” and aims to disable the Protected Mode feature that is enabled on Redis by default starting with version 3.2.0 when the instance is bound to all network interfaces and doesn’t have authentication enabled. This is a common insecure configuration that would allow anyone to access the Redis instance, so Protected Mode was added to block any connection attempts except for those coming from the local loopback interface — essentially the same system.
If the attackers gain access to a server using some other method — for example SSH — and that server runs a Redis instance in Protected Mode, they can connect to it locally to disable the protection and then be able to send other commands over the internet.
Another command disables the replica-read-only configuration option. This is another protective feature that makes a Redis instance configured as a replica to reject all incoming write commands. Redis supports replication where an instance can act as a master and others as replicas of that master, but since the replication only happens from master to replica, sending write commands directly to a replica can cause it to become out of sync. On the other hand, attackers would want this feature disabled so they can execute their commands on the Redis instance.
Two other commands disable the aof-rewrite-incremental-fsync and rdb-save-incremental-fsync settings. These options make the Redis contents persistent across reboots instead of volatile like all RAM-stored data. The first will save a log of all write operations and will execute them again when the instance starts to rebuild the data store, and the second creates snapshots of the dataset at specified intervals.
The attackers likely disable these features to hide their tracks because they then follow up with two set commands that write an attacker-controlled SSH key and a cron job to download and execute the Migo binary. “The attackers will then follow-up with a series of commands to change the working directory of Redis itself, before saving the contents of the database,” the researchers said. “If the working directory is one of the Cron directories, the file will be parsed by crond and executed as a normal Cron job. This is a common attack pattern against Redis servers and has been previously documented by Cado and others.”
Migo malware written in Go
The Migo binary is saved on disk as /tmp/.migo and is written and compiled as an executable with Go, a cross-platform programming language. The malware is packed and has its symbols obfuscated to prevent them from showing up in stack traces or to be easily recovered by analysts. The malware then creates a file that serves as a marker for attackers in the future that the system has already been compromised and will then proceed to download the XMRig open-source miner from GitHub.
The XMRig binary is saved as .migo_worker and a persistence mechanism is created for it by creating a systemd timer called system-kernel.timer. The malware loader also takes other actions on the system: It configures the resource limits for XMRig based on how many users the system has, disables the SELinux defense mechanism, attempts to uninstall common monitoring agents from cloud providers, uses iptables to configure the local firewall to block outbound connects to certain IP addresses, and searches for and kills competing miners if the system has been infected by other groups. The malware also edits the /etc/hosts file to block resolution for domains associated with certain cloud providers to prevent any updates from them.
Process and file hiding
The Migo loader also drops a file called libsystemd.so, which is a user mode rootkit based on the open source libprocesshider project. This tool is commonly used in cryptojacking campaigns to hide certain files from file and process listing commands like ls, ps, or top. In this case the tool is used to hide mentions of /tmp/.migo_worker and /tmp/.migo from command outputs.
“The malware updates /etc/ld.so.preload to point at a Linux shared object file located at /usr/local/lib/libsystemd.so, effectively conducting Dynamic Linker hijacking on the Redis host,” the researchers said. “This shared object is embedded within the Migo primary payload and is extracted at runtime.”
The Cado report contains indicators of compromise such as file names, hashes and IP addresses used by this attack that can be used to create detection rules.