Minaki Scan

Threat wiki / Kinsing

Kinsing

Also known as NSPPS.

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 loader with an ld.so.preload userland rootkit
Goes afterLinux servers and container hosts, notably misconfigured Docker daemon API endpoints
Our verdictBack up and rebuild
Last reviewed2026-10-15

What it is

Kinsing takes over Linux servers and container hosts to mine cryptocurrency, using your server's processor and electricity for the attacker's profit. It also installs a hidden library that loads into other programs and hides its files and processes from the normal tools you would use to look for them. That hiding is why a server with Kinsing can't be trusted to check itself.

How it gets in

In the campaigns researchers documented, through Docker's management interface left open to the internet with no login. Later reports also describe it breaking in through server software with known security holes.

Close the door: Never expose the Docker daemon API on a network without TLS client-certificate authentication or SSH; prefer the local Unix socket. Run containers and services without root where possible, which the cited report notes removes the family's preload persistence.

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/etc/libsystem.so
File location/etc/ld.so.preload
File namekdevtmpfsi
File namekinsing
File namelib_system.so
Process namekdevtmpfsi
Process namekinsing
Startup entrybot

These commands only look. They change nothing.

Look for the known file locations:

sudo ls -la /etc/ld.so.preload /etc/libsystem.so 2>/dev/null

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

sudo find / -xdev \( -name 'kdevtmpfsi' -o -name 'kinsing' -o -name 'lib_system.so' \) 2>/dev/null

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

for p in $(pgrep -f 'kdevtmpfsi|kinsing'); 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 'bot'; sudo ls -la /etc/init.d/bot 2>/dev/null

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.

4ce4f3ea11d62518c3c6248fb827e72628a0750ad4c4bd7e69d62c444f5fdb04 d5f089ea1b007ae0796d7d44b5a282c20195b074feebc113d7a1fd0d61c8c496 000bef7b8b56bdb86606a03c6ec3887ec0f1eb5dc507f60144656c8046d89b2e 7f44fe4766aeb78b65ee014864e49a76d2e61b2198a356f23060f48a5f057411 c38c21120d8c17688f9aeb2af5bdafb6b75e1d2673b025b720e50232f888808a ccfda7239b2ac474e42ad324519f805171e7c69d37ad29265c0a8ba54096033d d247687e9bdb8c4189ac54d10efd29aee12ca2af78b94a693113f382619a175b

How sure these signs are: Kinsing hides itself, so a check run on the infected server can miss it, and finding nothing does not prove the server is clean. The most useful sign is a line you didn't add in /etc/ld.so.preload: the file itself is normal, an unexpected entry in it is not. kdevtmpfsi is named to look like part of the system and bot is a generic name, so neither proves anything alone. Researchers spell the hidden library both /etc/libsystem.so and lib_system.so. These signs come from 2020 to 2021 reports; newer builds may differ.

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: /etc/ld.so.preload, the library it names, your startup entries and scheduled tasks. If you can, collect them from a rescue disk, because the infected system hides things from you.
  3. Copy off your data: databases, website files and documents. Don't copy programs, startup entries, scheduled tasks 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 container registry and cloud keys, and cancel the old ones.
  6. Before you reconnect, make sure Docker's management interface can't be reached from the internet without a login. Keep checking for the signs above.
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.