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

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.