Muhstik

What it is

Muhstik is a botnet controlled through a chat channel (IRC), descended from the older Tsunami bot. It takes over Linux servers, routers and other connected devices to flood other sites with traffic and to mine cryptocurrency. In a 2024 campaign it put copies of itself named pty3 in several temporary folders and added a line to /etc/inittab so the system starts it again. A 2021 version also added the attacker's own SSH key.

How it gets in

Through internet-facing server software that hasn't been updated (in 2024, Apache RocketMQ), and in earlier campaigns through weakly set-up routers.

Close the door: Apply vendor patches for internet-facing server software (the 2024 campaign used a RocketMQ flaw fixed in a later release), do not expose message-queue or management ports to the internet, change default credentials on routers, and run services without root.

How to tell if you have it

Signs published for this threat. One sign alone proves little: names get reused, and newer versions change them. Look for several together.

These commands only look. They change nothing.

Look for the known file locations

sudo ls -la /dev/shm/pty3 /etc/inittab /run/lock/pty3 /run/pty3 /var/tmp/pty3 2>/dev/null

Search for the known file names (slow on big disks)

sudo find / -xdev \( -name 'pty3' -o -name 'daymon' -o -name 'ldm' \) 2>/dev/null

Look for the known process names, and where each one runs from

for p in $(pgrep -f 'f0sfwjsfj51tc5h|pty3'); do echo "$p $(sudo readlink /proc/$p/exe)"; done

List running programs that live in a temporary folder (real software almost never does)

sudo ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/(tmp|var/tmp|dev/shm)/'

Fingerprint a suspect file and compare it with the list below

sudo sha256sum /path/to/suspect-file

Known file fingerprints (SHA-256). A match identifies that exact file; newer builds differ.

How sure these signs are: These signs come from reports between 2019 and 2024, not proof of what it does today. pty3 looks like the name of a normal terminal device, and other reports show pty1 to pty6, so check where a file sits and its fingerprint, not its name. The random-looking process name was seen in one campaign and may change. /etc/inittab is a normal file on older Linux systems; only a line in it that keeps restarting pty3 from the folders above is a sign, and the report named only inittab, so the full path is our reading of it. Judge the SSH key by the long key text, not the label at the end. The fingerprints identify specific samples across several years and processor types.

How to remove it by hand

Work through these in order. Don't skip the first two.

1. Don't restart the server yet. Its copies in /dev/shm, /run and /run/lock live in memory and vanish on a restart, taking your evidence with them. Cut the server off from the internet, keep a way to log in such as your hosting provider's web console, and save /etc/inittab, the pty3 copies in /dev/shm, /var/tmp, /run/lock and /run, the process list with where each process runs from, the files' SHA-256 fingerprints and every ~/.ssh/authorized_keys file.
2. Keep a backup copy of /etc/inittab, then delete only the lines that keep restarting pty3. Don't delete the file itself.
3. Find its processes by where they run from, not by name: for each suspect process number, run sudo readlink /proc/NUMBER/exe. A program in /dev/shm, /var/tmp, /run/lock or /run that matches a fingerprint above is confirmed. Stop it with sudo kill NUMBER, and use kill -9 only if that doesn't work.
4. Move the confirmed pty3 copies into a folder only root can read rather than deleting them straight away.
5. In /root/.ssh/authorized_keys and in each user's ~/.ssh/authorized_keys, delete the line whose key text matches the attacker's key shown above in full. Remove any other key you don't recognise only after its owner confirms it isn't theirs. Never delete the whole file.
6. If you can't confirm the server is intact, rebuild from a fresh install and restore only data you've checked. It runs with the rights of the program that was broken into, and one version adds SSH keys, so full control is possible.
7. From a clean computer, change the passwords and SSH keys that were on the server. Install the updates for the server software it came in through, keep message-queue and management ports off the internet, change default router passwords, and don't run services as root. Then check again: no matching processes, files, inittab lines or unknown keys should remain.

What Minaki Scan does about it

Related threats

Sources

This page is written by MinakiLabs in our own words. The facts above come from this published research; credit and thanks to its authors.

• Threat Alert: Log4j Vulnerability Has Been adopted by two Linux Botnets, Netlab 360 (2021-12-11)
• SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
• Muhstik Botnet Attacks Tomato Routers to Harvest New IoT Devices, Palo Alto Networks Unit 42 (2020-01-21)
• Muhstik Malware Targets Message Queuing Services Applications, Aqua Security (Aqua Nautilus) (2024-06-04)