Minaki Scan

Threat wiki / PwnRig

PwnRig

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 isCryptominer (modified XMRig build) deployed with a loader script and an IRC bot
Goes afterInternet-facing Linux servers and cloud workloads
Our verdictBack up and rebuild
Last reviewed2026-10-15

What it is

PwnRig is a cryptocurrency miner, a modified build of the XMRig mining program, used by the group researchers call the 8220 Gang. It arrives with a loader script and a bot controlled over a chat channel, based on Tsunami. Security monitoring of this group's attacks flagged changes to /etc/ld.so.preload more than once; that file makes a library load into every program, a common way to hide things. No report describes that library, so we can't say exactly what it hides, and we advise rebuilding to be safe rather than trusting the server to check itself.

How it gets in

Through internet-facing services that are unpatched or badly set up, such as Redis, Apache and Oracle WebLogic.

Close the door: Patch and restrict public access to exposed services such as Redis, Apache and WebLogic, and do not expose management ports to the internet. Monitor for cron modification, execution from /tmp and writes to /etc/ld.so.preload, which the cited Falco coverage flags.

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/tmp/.python
File namexms
File namepwnrig
File nameinitdr
File namesysdown
File name.ntpdate
File name.tmpest
Process namedbused
Process nameJava (Update)

These commands only look. They change nothing.

Look for the known file locations:

sudo ls -la /tmp/.python 2>/dev/null

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

sudo find / -xdev \( -name 'xms' -o -name 'pwnrig' -o -name 'initdr' -o -name 'sysdown' -o -name '.ntpdate' -o -name '.tmpest' \) 2>/dev/null

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

for p in $(pgrep -f 'dbused'); 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.

d646f450ec5b2e1e04c962350fa430b9651fbcb33a8c39571126e49d6edb5cf1 558c12a703cac54a1a1206d80b12203d323b869e486a18c4340a09ff0a482570 5f34168868107b31a3d31b071b71c6a7ffbf2ef48e0dac27c53115bc180dd029

How sure these signs are: We advise rebuilding as a precaution: reports flag /etc/ld.so.preload being changed but don't describe what was hidden, so a check run on the infected server may miss things, and finding nothing does not prove it is clean. The attackers choose their own file and process names. dbused looks like the real dbus service and Java (Update) looks like a real updater, so check where the process runs from. .ntpdate imitates a time tool. xms, initdr and .tmpest are weak signs alone: they are short or shared names, and researchers saw the same name with different fingerprints, or the same fingerprint under another name. /tmp/.python belongs to the companion bot, not the miner. One report carries no date (likely 2021); the other is from 2023.

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 server from a fresh install.
  2. Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence: your scheduled tasks, init.d scripts and services, /etc/ld.so.preload, the contents of /tmp, and the SHA-256 fingerprint of each suspect file. If you can, collect them from a rescue disk.
  3. Copy off your data: databases, website files and documents. Don't copy programs, scripts, scheduled tasks, init.d entries or /etc/ld.so.preload; any of those could bring it back.
  4. Reinstall from a fresh image, install all updates, then restore only the data you copied and checked.
  5. From a clean computer, change every password, key and token that was on the server, including SSH private keys and cloud keys, and cancel the old ones. The loader looks for private keys on the server.
  6. Before you reconnect, patch the service that was exposed, such as Redis, Apache or WebLogic, and make sure it can't be reached from the internet without a login. Don't leave management ports open to the internet. Keep watching for changes to scheduled tasks, programs running from /tmp and changes to /etc/ld.so.preload.
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.