Sysrv

What it is

Sysrv, also seen as Sysrv-hello, is a botnet written in the Go language that takes over Linux and Windows servers to mine the cryptocurrency Monero, using a built-in copy of the XMRig miner. Researchers report it changes the server's scheduled tasks and adds an SSH key so the attackers keep access, but they didn't publish the exact lines. One 2021 version also left a Windows program, BrowserUpdate.exe, and a Python script, /tmp/a.py, that edits website files. A report from December 2024 shows it still in use, apparently by several rival groups.

How it gets in

Through weak passwords on web, database and application services, and through internet-facing software that hasn't been updated.

Close the door: Use strong, unique passwords (ideally key-based or single sign-on) on every database, application admin and CI service, keep internet-facing software patched, and do not expose management or database ports to the internet; restrict them with a firewall or VPN.

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 /tmp/BrowserUpdate.exe /tmp/a.py /tmp/network01 2>/dev/null

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

sudo find / -xdev \( -name 'ldr.sh' -o -name 'sysrv' -o -name 'network01' -o -name 'xmr64' -o -name 'xmr32' -o -name 'kthreaddi' \) 2>/dev/null

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

for p in $(pgrep -f 'network01|kthreaddi|sysrv'); 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 for programs using the known ports

sudo ss -tunap | grep -E ':(52013|52014|52015|52016|52017|52018|52020|52021)\b'

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: Most of these signs come from reports in 2020 and 2021; a 2024 report shows the botnet still running, but newer builds use random names, so not finding these names doesn't clear a server. Names such as network01, ldr.sh, sysrv and xmr64 are generic, and kthreaddi is made to look like the real kernel task kthreadd: a real kernel task has no program file behind it, this one does. A copy holds a local network port open in the range 52013 to 52021 as a marker, but a listener on a high port proves little until you check which program owns it. The fingerprints identify packed samples from those early reports only. No exact scheduled task line or SSH key was published, so those have to be checked by hand.

How to remove it by hand

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

1. Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence first: the process list with where each process runs from, listening ports (sudo ss -ltnp), the crontabs of root and every user, every ~/.ssh/authorized_keys file, shell history, and copies of suspect files with their SHA-256 fingerprints.
2. Find its processes by where they run from, not by name. For each suspect process number, run sudo readlink /proc/NUMBER/exe and fingerprint that file with sudo sha256sum. For a listener on a port from 52013 to 52021, sudo ss -ltnp shows which process owns it. Stop confirmed processes with sudo kill NUMBER, and use kill -9 only if that doesn't work.
3. Move confirmed files, such as /tmp/network01, /tmp/a.py, /tmp/BrowserUpdate.exe and any file that matches a fingerprint above, into a folder only root can read. Delete the originals once you've finished collecting evidence.
4. Go through every crontab and every authorized_keys file line by line. Because the exact lines were never published, ask the owner of each account about anything unfamiliar, and remove only lines confirmed not to be theirs. Never delete a whole crontab or key file.
5. Check your website folders and application files for changes you didn't make and for stray copies of BrowserUpdate.exe. Put back changed files from a backup or your source code.
6. Treat any account or service the attacker could reach as compromised. If they had full control (root), or you can't confirm what changed, rebuild from a fresh install and restore only data you've checked.
7. From a clean computer, change the database and service passwords, SSH keys and application secrets that were on the server, and cancel the old ones.
8. Before you reconnect: use strong, unique passwords (or key or single sign-on logins) on every service, install all updates, and keep database and management ports off the internet with a firewall or VPN. Run the checks above again, restart, and check once more.

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: New update from Sysrv-hello, now infecting victims' webpages to push malicious exe to end users, 360 Netlab (2021-04-29)
• The Sysrv Botnet and How It Evolved, CUJO AI (2021-09-22)
• SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
• Early Bird Catches the Worm: New Golang Worm Drops XMRig Miner on Servers, Intezer (2020-12-29)
• Sysrv cryptomining botnet is still alive (and kicking out the competition), ThreatDown (Malwarebytes) (2024-12-23)