A look a the Linux/CoinMiner.BC malware

I recently had the “pleasure” of helping a friend with his GNU/Linux box which was acting up. Random system processes like initctl, dbus-daemon,ssh-agent, ibus-x11, icc-daemon or even a simple sleep would suddenly consume all the CPU resources in the background, often the graphical user interface would also lag. But he couldn’t find out why – every time he tried to debug the issue, e.g. by running top, the processes at fault suddenly disappeared.

Turns out he had infected his machine with the Linux/CoinMiner.BC malware, probably by installing an unofficial Kodi plugin. Luckily all the malware seems to do is to mine some cryptocurrency in the background (hence the name “CoinMiner”). But it takes quite a few steps to avoid detection and ensure it isn’t easily removed.

Infection

There are various infection vectors, among them installing unofficial Kodi plugins (that’s how my friend most likely got infected) and known security vulnerabilities in other applications. Once the malware makes it onto the machine somehow, it drops a long list of files into the users home directory. I’m not including hashes here since these seem to change after every update.

./.ssh/service/.ssh-agent.sys
./.ssh/service/.ssh-agent.bin
./.local/share/icc/icc-daemon
./.local/share/icc/.icc-daemon.sys
./.local/share/icc/.icc-daemon.bin
./.local/share/icc/zeitgeist-fts
./.local/share/icc/.zeitgeist-fts.sys
./.local/share/ibus-table/.sleep.sys
./.local/share/accounts/services/dbus-daemon
./.local/share/accounts/services/.dbus-daemon.sys
./.local/share/accounts/services/.dbus-daemon.bin
./.cache/totem/service/totem-daemon
./.cache/totem/service/.totem-daemon.sys
./.cache/totem/service/.totem-daemon.bin

There are multiple copies of the same three binaries, named after different system processes which are usually installed and running in most GNU/Linux installations. As far as I can tell, the file without an extension is the updater/launcher, the .*.bin file seems to hold some kind of key, and the .*.sys file seems to be some encrypted payload. To make sure the launcher is started, an Autostart file called ~/.config/autostart/dbus-daemon.desktop with the following content is created:

[Desktop Entry]
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
StartupNotify=false
Name=dbus-daemon
GenericName=dbus-daemon
Exec=/var/lib/kodi/.local/share/accounts/services/dbus-daemon

(The /var/lib/kodi/ path pretty much gives away that a Kodi plugin was the infection vector.)

In case the user doesn’t use one of the Linux desktop environments which support Autostart entries, the following lines are dumped into various other files to make sure the malware is started as soon as the user logs into an interactive terminal session. It doesn’t matter if it’s a local or remote session, e.g. via SSH.

~/.bash_profile

linux_bash="$HOME/.local/share/icc/icc-daemon"
if [ -e "$linux_bash" ];then
setsid "$linux_bash" 2>&1 & disown
fi

~/.bashrc

linux_bash="$HOME/.ssh/service/ssh-agent"
if [ -e "$linux_bash" ];then
setsid "$linux_bash" 2>&1 & disown
fi

~/.profile

linux_bash="$HOME/.cache/totem/service/totem-daemon"
if [ -e "$linux_bash" ];then
setsid "$linux_bash" 2>&1 & disown
fi

Updating, launching and avoiding detection

When one of the copies of the launcher/update binary is executed via one of the launching methods, it first waits for 30 seconds. Then it tries to create the file /tmp/.printer.dat as a lockfile. If this succeeds it contacts one of several HTTP servers to download updates. Then it launches the miner. The copy I looked at seemed to be linked against libCL. So if the machine has an OpenCL-compatible GPU and runtime, it will run on the GPU instead of the CPU. Which is harder to detect and can cause the GUI to lag. If you are using the proprietary NVIDIA driver or AMDGPU-PRO, your system has an OpenCL runtime.

There seem to be some mitigations for avoiding detection. One of them is to simply check if the user is running top and quickly pausing the mining process in case. The logic doesn’t seem to be very clever, though, since it doesn’t seem to detect the GNOME and KDE task managers. If the miner process is killed, it will be restarted with a delay.

Removal

In theory you could log out of all user sessions, log in as root (NOT via sudo!), kill all remaining user processes and then clean/remove the listed files. Creating a new user profile, migrating all the data you actually need and then deleting the old profile is theoretically much better.

In practice your machine was compromised and you don’t know if the attackers did more than just infect it with a cryptominer. They could have used any number of security exploits to install a rootkit or something like that. Just backup your data and reinstall the whole machine.