Hacked by XMRig: A Real-World Server Cleanup Log

Recently, one of my servers was infected by the XMRig cryptocurrency mining malware. This post documents the entire journey of how I discovered it, analyzed the cause, removed the malicious processes, and hardened the server afterward — all with a lot of help from AI tools like ChatGPT.

What you'll learn:

1. How I detected the XMRig miner and a fake apache2 process
2. How I investigated suspicious processes and tracked down their source
3. How I discovered my server was attacking others via SSH
4. Steps I took to clean up the malware and secure the server

---

This post documents my experience of discovering and removing the XMRig mining malware from my Linux server, with a lot of help from AI along the way. Here's how it unfolded:

1. Initial Warning: Stratum Detected

On July 11, I received a warning from my hosting provider:

Suspicious files were detected on your system disk. Please verify and clean up. Typically, attackers install mining programs after breaching a server. These programs consume CPU resources and may harm normal business operations.

The alert mentioned detection of Stratum protocol traffic — a common sign of mining software.

I immediately tried logging in via SSH. Fortunately, access was still available. I ran htop and saw two suspicious processes:

• xmrig (CPU usage 99%)
• apache2 (also maxing CPU)

2. Investigating the XMRig Process

I focused on xmrig first — definitely malicious.

PID: 2955486
Command: ./xmrig --url pool.hashvault.pro:443 --user 8Zp...
CPU: 99%

I killed the process:

sudo kill -9 2955486

It didn’t restart immediately. Good sign.

Then I searched for its location:

sudo find / -iname '*xmrig*'
# Found at /var/tmp/m/xmrig

GPT suggested deleting the directory:

sudo rm -rf /var/tmp/m

Before doing that, I checked the contents:

ls -alt /var/tmp/m
cat /var/tmp/m/config.json

config.json pointed to a Monero pool, along with a wallet address. GPT even found that the May 27 timestamp in the folder matched a known mining campaign called RedisRaider: https://thehackernews.com/2025/05/go-based-malware-deploys-xmrig-miner-on.html

This campaign exploited misconfigured Redis servers to write cron jobs that downloaded the payload (XMRig disguised as apache2).

I realized: I had Redis running with public access mistakenly enabled. I shut that down.

3. The Fake apache2

htop showed another high-CPU process: apache2. But I use Caddy, not Apache.

Attempts to stop it failed:

sudo systemctl stop apache2  # Not found
sudo service apache2 stop    # Not found

The process showed as:

/usr/sbin/apache2 -k start

But:

ls -l /usr/sbin/apache2
# No such file or directory

Suspicious.

Using ps auxfww, I found:

PID 2510277 /usr/sbin/apache2 -k start (started July 1, CPU 91%)

I killed it:

sudo kill -9 2510277

Again, it didn’t restart. But I couldn’t trace its real origin.

4. Second Warning: Outbound SSH Attacks

Just as I thought I was done, on July 16 I got a second warning:

Your server was detected attacking other servers via TCP port 22. Traffic has been blocked until further notice.

I checked outbound SSH connections:

sudo netstat -anp | grep ':22'

Found many suspicious outbound SSH attempts by a process named Acronis:

tcp [my_ip]:34014 [target_ip]:22 SYN_SENT 3309431/./Acronis

I killed the process:

sudo kill -9 3309431

Located the file:

sudo find / -name Acronis -type f
# /tmp/.mvwwttudfg/k/Acronis

Deleted the whole folder:

sudo rm -rf /tmp/.mvwwttudfg

5. Final Cleanup

After dealing with XMRig, apache2, and Acronis, I did some final maintenance:

sudo apt update && sudo apt upgrade -y
sudo passwd root  # Reset root password
sudo reboot

Confirmed nothing suspicious was running:

ps aux | grep -E 'xmrig|Acronis|apache2'
sudo netstat -anp | grep ':22'

---

Key Takeaways

• Never expose Redis directly to the internet.
• Check /var/tmp/ and cron jobs regularly.
• Malware often mimics system binaries (like apache2).
• AI tools like ChatGPT can be surprisingly effective for incident response.

If you're dealing with a similar issue, I hope this helps you detect and clean up your server more confidently.