Minaki Scan

Threat wiki / PumaBot

PumaBot

Back up and rebuild

This threat hides itself inside the system, so a server that has it can't be trusted after a cleanup. The honest fix is to save your data and reinstall.

What it isGo-based Linux IoT botnet with a cryptominer component and a PAM credential-stealing module
Goes afterEmbedded Linux IoT devices, notably traffic-camera and surveillance systems
Our verdictBack up and rebuild
Last reviewed2026-10-15

What it is

PumaBot is a botnet program written in Go that takes over internet-connected Linux devices, notably traffic cameras and surveillance systems. It installs a cryptocurrency miner and swaps pam_unix.so, the part of Linux that checks passwords when you log in, for a copy that saves the password of everyone who logs in successfully. It keeps itself running with system services disguised as Redis and MySQL. Because the login check itself has been replaced, a device with PumaBot can't be trusted to check itself.

How it gets in

By guessing weak SSH passwords on devices reachable from the internet.

Close the door: Audit /etc/systemd/system regularly for misspelled or duplicate services and for binaries in non-standard locations such as /lib/redis; review authorized_keys files for unknown keys; monitor for atypical SSH logins and restrict exposure of port 22.

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.

KindSign
File location/lib/redis
File location/etc/systemd/system/redis.service
File location/etc/systemd/system/mysqI.service
File location/etc/systemd/system/networkxm.service
File location/usr/src/bao/networkxm
File location/usr/bin/con.txt
File namejierui
File nameddaemon
File namenetworkxm
File namepam_unix.so_v131
File namecon.txt
Process nameredis
Process namexmrig
Process namenetworkxm
Startup entryredis.service
Startup entrymysqI.service
Startup entrynetworkxm.service
Startup entrymy_daemon.service
SSH keyssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0tH30Li6Gduh0Jq5A5dO5rkWTsQlFttoWzPFnGnuGmuF+fwIfYvQN1z+WymKQmX0ogZdy/CEkki3swrkq29K/xsyQQclNm8+xgI8BJdEgTVDHqcvDyJv5D97cU7Bg1OL5ZsGLBwPjTo9huPE8TAkxCwOGBvWIKUE3SLZW3ap4ciR9m4ueQc7EmijPHy5qds/Fls+XN8uZWuz1e7mzTs0Pv1x2CtjWMR/NF7lQhdi4ek4ZAzj9t/2aRvLuNFlH+BQx+1kw+xzf2q74oBlGEoWVZP55bBicQ8tbBKSN03CZ/QF+JU81Ifb9hy2irBxZOkyLN20oSmWaMJIpBIsh4Pe9 @root

These commands only look. They change nothing.

Look for the known file locations:

sudo ls -la /etc/systemd/system/mysqI.service /etc/systemd/system/networkxm.service /etc/systemd/system/redis.service /lib/redis /usr/bin/con.txt /usr/src/bao/networkxm 2>/dev/null

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

sudo find / -xdev \( -name 'jierui' -o -name 'ddaemon' -o -name 'networkxm' -o -name 'pam_unix.so_v131' -o -name 'con.txt' \) 2>/dev/null

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

for p in $(pgrep -f 'redis|xmrig|networkxm'); 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)/'

Check the known startup entries, wherever they are installed:

systemctl list-unit-files --no-pager 2>/dev/null | grep -F -e 'redis' -e 'mysqI' -e 'networkxm' -e 'my_daemon'; sudo ls -la /etc/init.d/redis /etc/init.d/mysqI /etc/init.d/networkxm /etc/init.d/my_daemon 2>/dev/null

How sure these signs are: The swapped login file keeps the real name pam_unix.so, so a check on the device can't prove it clean. Several names copy real software: redis.service may belong to a real Redis install (the sign is a service that runs /lib/redis), mysqI.service uses a capital I in place of the l in mysql, and redis, xmrig and con.txt are common names. /usr/bin/con.txt is where the captured passwords are written, and it is deleted afterwards, so not finding it proves nothing. The attacker's SSH key listed above is a strong sign in any authorized_keys file. No SHA-256 fingerprints have been published. All these signs come from one 2025 report.

How to deal with it

Removing it in place isn't safe. Here is what to do instead, in order:

  1. Don't try to clean it in place. Plan to rebuild the device from a fresh install.
  2. Cut the device off from the internet, but keep a way to reach it locally. Save evidence: /lib/redis, the redis.service, mysqI.service, networkxm.service and my_daemon.service files in /etc/systemd/system, /usr/src/bao/networkxm, your authorized_keys files and the installed pam_unix.so. If you can, collect them from a rescue disk.
  3. Copy off your data. Don't copy programs, systemd services, authorized_keys files or login files such as pam_unix.so; any of those could bring it back.
  4. Reinstall from a fresh, known-good image, install all updates, then restore only the data you copied and checked.
  5. From a clean computer, treat every password used on the device as stolen, both local and SSH: change them and cancel the old ones. Remove the attacker's SSH key from any other machine that trusted it.
  6. Before you reconnect, don't leave SSH (port 22) open to the internet, and use strong passwords. Regularly check /etc/systemd/system for misspelled or duplicate services and authorized_keys files for keys you don't know, and watch for unusual SSH logins.
These steps are provided as-is, without warranty. Run them at your own risk, and back up first. If you're unsure, rebuild from a known-good install.

What Minaki Scan does about it

Minaki Scan looks for this threat and reports it only when at least two signs agree. It never tries to remove it: it tells you to back up your data and rebuild.

Minaki Scan checks your server every day for this and the other threats in this wiki. $1 per server a month. Downloads open soon.

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.