New Redis attack campaign weakens systems before deploying cryptominer
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.”
