The first sign was my AI agent going quiet. OpenClaw — the thing that runs most of my infrastructure — just stopped responding. When I got a terminal, top showed a process named /tmp/mysql burning 381% CPU and 2.4 GB of RAM.
It wasn’t MySQL. It was a crypto miner, dropped onto my VPS through a brute-forced SSH login.
How it got in
I’d left three doors open: PermitRootLogin yes, password authentication enabled, and no brute-force protection. The logs showed 30+ failed SSH logins per hour from a rotating set of IPs. Eventually one guessed a weak credential, and the miner came with it.
The fix, step by step
- Kill the miner —
kill -9the process, delete the/tmp/mysqlbinary. - Lock SSH to keys —
PermitRootLogin prohibit-passwordandPasswordAuthentication no. No password = nothing to brute-force. - fail2ban — 24-hour bans (up from 1 hour) plus a recidive jail that bans repeat offenders for a week.
- rkhunter — a rootkit scan to confirm nothing else was hiding (498 rootkits in its database, 0 found).
- Unattended upgrades — so the next SSH or kernel CVE patches itself instead of waiting for me to notice.
The numbers before and after
- CPU idle: 0% → 79%
- Load average: 6.06 → 1.54
- Free RAM: 1.5 GB → 3.9 GB
Within a week fail2ban had blocked 44 IPs and 15,678 failed SSH attempts. The brute-force noise never stopped — it just stopped mattering.
The lesson
A $6 VPS exposed to the internet is a target the moment it boots. The whole incident — from “why is everything slow” to “clean and hardened” — took about two hours, and every fix was something I should have had on day one. If you’re self-hosting, do this before the miner finds you, not after.
Guides & explainers
Filed under: Cybersecurity