Security Incident Report: XMRig Cryptominer

A persistent Monero miner that kept coming back — even after deleting its files, killing its process, and changing the root password. The culprit turned out to be a malicious kernel module.

1. Executive Summary

On 2026-08-29 I detected and fully eradicated a persistent XMRig cryptocurrency miner from my Proxmox VE 8 host (kernel 7.0.14-8-pve). The infection was more sophisticated than a typical miner: it used an unsigned, out-of-tree kernel module (nf_conntrack_kernel) as a self-healing re-dropper that re-created the miner binary and relaunched it from kernel space every ~18 minutes — surviving process kills, file deletion, password rotation, and every userspace-level cleanup.

Root cause was a WAN-exposed Proxmox management interface (pveproxy, port 8006) combined with a weak root password, which granted the attacker full root access.

Every component of the infection was mapped and removed. This report documents the technical details, indicators of compromise (IOCs), and the remediation steps taken.

2. Incident Timeline

3. Root Cause

The host’s Proxmox web management interface (pveproxy, port 8006) was exposed to the WAN, and the root account used a weak password. The attacker obtained root credentials, then gained a root shell via the Proxmox root@pam authentication path.

This single point of failure let the attacker install a kernel-level rootkit — which is why the infection proved so resilient to conventional cleanup.

4. Infection Chain

4.1 Payloads

The attack dropped four distinct components:

4.2 Persistence

The miner persisted through two layers:

1. /etc/profile.d/bash_completion.sh had an injected export LD_PRELOAD="/usr/local/lib/kthreadd32.so" — loading the hider library into new shells to conceal the miner process from ps/ls.
2. /etc/modules contained the line nf_conntrack_kernel (prefixed by a fake # AUTO GENERATED BY KERNEL SYSTEM MODULE comment). At boot, systemd-modules-load loaded the kernel module, which used call_usermodehelper() to periodically re-drop the miner binary and relaunch it.

The second layer is what made the infection self-healing: because the miner was re-created and executed from the kernel, it was invisible to process-list and file-level cleanup. It also lived in the root cgroup (0::/) with a near-empty environment — the classic signature of call_usermodehelper().

4.3 Mining Configuration

The miner connected to two pools with the command line:

/sbin/kthreadd64 --cpu-priority=5 --donate-level=0 \
  -o 89.117.109.224:143 \
  -u 4B7vsy8ccUwQufiyMN9jgoDphPUDzGUvBhE4f19U5z3WMPZqx2gjHrv2PxpuBSZRHAdD5qfEnPiApdFk4fhHZGVwU1YG1L2.worker86/[email protected] \
  --coin=monero -k

5. Indicators of Compromise (IOCs)

Files

Network & Identity

6. Remediation

The following actions fully neutralized the infection:

1. Unloaded the kernel module — rmmod nf_conntrack_kernel.
2. Removed boot persistence — deleted the module entry from /etc/modules.
3. Deleted the .ko file and rebuilt the module index (depmod -a).
4. Blacklisted the module in /etc/modprobe.d/ (blacklist + install … /bin/false) so it cannot be loaded again.
5. Killed the miner and deleted /sbin/kthreadd64 and /usr/sbin/kthreadd64.
6. Removed the LD_PRELOAD hider (kthreadd32.so) and stripped the injection from bash_completion.sh.
7. Removed the staging directory /var/tmp/xmrig/.
8. Blocked the C2 IPs via a persistent systemd unit (block-mining-ips.service), using iptables on both INPUT and OUTPUT.
9. Rotated the root password.

7. Lessons Learned & Recommendations

1. Never expose the Proxmox management interface (port 8006) to the WAN. Access it over a VPN or SSH tunnel instead.
2. Use strong, unique passwords — or better, key-based authentication and 2FA — for any internet-facing service.
3. A root compromise cannot be trusted away. A kernel-level rootkit means the attacker had full control of the host; the only way to be truly certain is a clean reinstall from known-good media.
4. Rotate all secrets that lived on the compromised host — API tokens, credentials, and keys stored on disk should all be considered exposed.
5. Defense in depth: even a strong password is no substitute for network-layer access control.

• Previous
  学期总结