Recovering a Server Hijacked by a Crypto‑Mining Virus: My Step‑by‑Step Fix

Introduction

My server was suddenly infected by a crypto‑mining virus. The 1‑CPU, 2 GB machine could no longer be accessed via SSH because the public key was missing, and password login had been disabled for security.

Accessing the Server via VNC

Using the Tencent Cloud console, I logged in through VNC, bypassing SSH restrictions, and confirmed the server was still reachable.

Discovering the Issue

While checking the system, I noticed two suspicious processes: sysupdate (CPU 51.2%) and networkservice (CPU 47.8%). A quick web search revealed they are typical of mining malware.

Step‑by‑Step Remediation

1. Identify the virus location

Run systemctl status {process_id} to view the status of the malicious process (e.g., sysupdate with PID 16142). The process started around 21:00 the previous night.

Use ls -l /proc/{process_id}/exe to locate the executable, which resides in /etc.

Copy the five files to a safe directory ( /root/test/) and inspect update.sh, which reveals disabled SELinux, altered wget / curl binaries, and a malicious network URL.

2. Remove scheduled tasks

Check /var/spool/cron/ and crontab -l for any cron jobs. None were found, but if present, delete the files or run crontab -r to clear the schedule.

3. Kill the processes and delete virus files

Execute kill -9 {process_id} for both malicious processes, then remove the five files from /etc. Because the files are immutable, first run chattr -i {filename} before using rm -rf.

4. Clean the authorized_keys file

Edit ~/.ssh/authorized_keys with vi and remove the two unknown public keys added by the attacker, keeping only your own keys.

5. Restore wget and curl

Rename the binaries back to their original names. Example commands (only the first two lines are needed):

mv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl

6. Re‑enable SELinux

Check the status with getenforce. The malware had set SELinux to disabled. Edit /etc/selinux/config to change SELINUX=disabled to SELINUX=enforcing and reboot the server.

Root Cause

The infection stemmed from an unauthenticated Redis instance. Redis runs on port 6379 without a password by default; when started as root, an attacker can write an SSH public key into ~/.ssh/authorized_keys and gain persistent access.

I had opened port 6379 for a test of delayed queues, which allowed the attacker to exploit the vulnerability overnight.

Final Thoughts

Beyond fixing the immediate compromise, the incident highlighted the importance of securing auxiliary services like Redis, using firewalls, and applying strong passwords. For production servers, dedicated ops teams typically handle such hardening.