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):

<code>mv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl
</code>

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.