SafeServerSetup
All case studies · Sample engagement · representative numbers

Rescued a compromised Vultr VPS from a cryptominer and rebuilt it clean

CPU pegged at 100%, outbound traffic spiking. Forensics, then a clean rebuild.

Customer
Discord bot operator
Team size
Solo admin
Provider
Vultr
OS
Ubuntu 22.04 → 24.04
Plan · Duration
Premium · 46 hours
Engagement summary

A solo operator running a popular Discord bot noticed the box's CPU pinned at 100% and outbound traffic to addresses they didn't recognize. We took the box offline for forensics, identified the entry point, and rebuilt clean from a fresh image — preserving only verified-good data.

Why they came to us

They'd already tried killing the suspicious process — it came back five minutes later. They didn't know how to figure out what else had been touched, and they were nervous about wiping the box without understanding the entry point in case the same thing happened again.

Audit findings

What we found on the box.

First pass before changing anything. Severity ranges from critical (act immediately) to low (worth knowing).

  • Cryptominer running as www-data, persisted via three independent mechanisms

    critical
  • Compromise vector: outdated Node.js with a known RCE in a custom file-upload endpoint

    critical
  • ~/.ssh/authorized_keys contained three keys the operator did not place there

    critical
  • Outbound connections to two known mining-pool endpoints

    critical
  • ~/.bash_history showed reconnaissance commands attempting lateral movement

    high
  • www-data crontab had three persistence entries restoring the miner

    high
  • 47 days of unapplied security patches

    high
Hardening applied

What we changed, in order.

Each change is reversible and documented in the handover doc. Commands shown are illustrative.

  1. 1

    Snapshotted the live box for offline forensics, then rebuilt from a fresh Vultr Ubuntu 24.04 image.

  2. 2

    Restored only customer data after a ClamAV scan plus manual review of recent uploads.

  3. 3

    Generated entirely new SSH key material; revoked all prior keys including the operator's old laptop key.

  4. 4

    New non-root ops user with sudo; passwd -l root to lock the root account.

  5. 5

    Layered defense: Vultr cloud firewall + UFW + fail2ban, all configured in agreement.

  6. 6

    Rebuilt the file-upload endpoint with strict MIME validation, max-size limits, and off-box object storage.

  7. 7

    Egress monitoring: outbound connections to non-allowlisted hosts now logged to syslog.

  8. 8

    Daily off-box backups with a monthly restore-drill scheduled in the operator's calendar.

  9. 9

    Wrote a detailed forensic write-up of the original compromise so the operator understood the chain of events.

Before / after

The numbers that moved.

Representative figures from this engagement. Real, named-customer studies will publish actual numbers with a link to verify.

Suspicious outbound connections / min
Before
240
After
0
CPU baseline
Before
100%
After
4–6%
Persistence mechanisms removed
Before
3
After
0
Patch lag
Before
47 days
After
0 days
Audit log retention
Before
0 days
After
90 days off-box
Ready to be the next one

Hand us your VPS, get an engagement like this one.

Pick a plan, send the credentials through the encrypted form, and we'll come back with the same kind of audit + hardening + handover the studies above describe.