Report this

What is the reason for this report?

Post-Incident Security Validation: Rebuild or Trust the Existing Droplet

Posted on June 23, 2026

Hello DigitalOcean Community,

I’m posting here following a recommendation from DigitalOcean Support after a recent security incident on a couple of Ubuntu Droplets.

We discovered an active XMRig cryptocurrency miner running under the web server user account, along with cron-based persistence mechanisms that automatically restarted the miner. We have since:

  • Removed the malware and associated persistence scripts
  • Deleted suspicious cron jobs
  • Reviewed running processes and active network connections
  • Rotated credentials where appropriate
  • Added Cloudflare protections in front of the affected sites
  • Performed an initial review of the systems for additional signs of compromise

At this point, my main concern is determining whether the servers can be considered trustworthy again, or whether a full rebuild is the only reasonable option.

I would appreciate advice from anyone with experience handling similar incidents:

  1. What steps would you take to verify that a Droplet is truly clean after removing a miner and its persistence mechanisms?
  2. Which tools have you found most useful for detecting rootkits, backdoors, modified binaries, or other signs of compromise (e.g., rkhunter, chkrootkit, ClamAV, Lynis, AIDE, etc.)?
  3. Are there specific logs, indicators, or forensic techniques you would review to identify the original entry point?
  4. Under what circumstances would you consider rebuilding the server mandatory rather than continuing with remediation?
  5. If you have successfully recovered from a similar incident, what validation steps gave you confidence that the system was secure again?

Any recommendations, lessons learned, or incident-response checklists would be greatly appreciated.

Thank you.



This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Hi there,

Straight answer to your main question: rebuild. Once a system has been compromised to the point of running a miner with cron persistence, you cannot fully trust it. The attacker had enough access to install software and modify cron, which means you cannot rule out a rootkit, a backdoor, or modified binaries that survive your cleanup.

The tools you mentioned like rkhunter, chkrootkit, and AIDE are useful for detection but they have limits. An attacker might still be able to modify those tools too, and if the compromise happened before you had a baseline for AIDE, it cannot tell you what changed.

For finding the entry point, start here:

grep -r "wget\|curl\|bash -i\|/dev/tcp" /var/log/
last -F
lastb -F
grep "Failed\|Accepted" /var/log/auth.log | tail -100

Also check for webshells if you are running a web server:

find /var/www -name "*.php" -newer /etc/passwd

Common entry points for miners are outdated CMS plugins, exposed admin panels, weak SSH passwords, or publicly accessible services with known CVEs.

That said, the confidence you get from rebuilding a clean Droplet from a known good snapshot or from scratch is worth far more than any amount of post-incident scanning. Take a snapshot of the current state for forensic reference, then rebuild, restore only your data and config, and harden before going live again.

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Start building today

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.