Question

Droplet Compromised? www-data processes

Have a new droplet running Ubuntu 20.04 with LAMP stack, and 3 wordpress installs that I created last week, with two of them being used with very low volume, really just testing at this point and setting up the wordpress sites.

Have installed wordpress themes (Hestia) and some plugins (MonsterInsights, RankMath, WPForms, WPMail, OrbitFox) and have been doing initial site development, in many ways re-teaching myself Wordpress.

Woke up this morning to the CPU Pegged, unable to access any of my sites. I went in and got this from top using my console, with the www-data one being suspicious.

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                              127 root      20   0       0      0      0 R  35.8   0.0  35:59.69 kswapd0                                                          105286 www-data  20   0  300532 264724      0 R  34.4  26.3  48:40.36 gko8llwqjf5jkus                            110224 mysql     20   0 1254396 339052      0 R  14.2  33.7   0:03.00 mysqld                                                               733 do-agent  20   0  559692   6356      0 S   8.9   0.6   1:52.68 do-agent                                                             386 root      19  -1   76188   5000   3720 R   2.6   0.5   3:20.57 systemd-journal

I restarted the site, and subsequently made sure SSH key login was enabled and password login disabled.

Have also found a couple cron entries that look suspicious to me. The first wordpress site has not been activated or used at all. Directory was created and populated for future use.

root@MY-DROPLET:/var/tmp# crontab -u www-data -l

          • /var/www/mysite.com/wordpress/wp-content/themes/twentynineteen/pty8 > /dev/null 2>&1 &
          • /dev/shm/pty8 > /dev/null 2>&1 &
          • /var/tmp/pty8 > /dev/null 2>&1 &
          • /var/lock/pty8 > /dev/null 2>&1 &

If I have to start over, it’s not the end of the world. But, I’d rather not. My questions:

How do I confirm whether these cron jobs and this behavior was malicious?

Can I clean it up, or start with a new droplet?

How do I identify how it happened and prevent it in the future?

Thank you, been years since I’ve done this daily, so appreciate the help.

Show comments
Submit an answer
Answer a question...

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!

Sign In or Sign Up to Answer

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.

Bobby Iliev
Site Moderator
Site Moderator badge
• May 7, 2020
Accepted Answer

Hi there @BCMulx,

This is quite common with Wordpress, especially if you do not install the updates regularly. I used to work for a web hosting company hosting thousands of WordPress websites and I’ve seen similar problems every day in the past.

In this case, I am fairly certain that the site was compromised due to the twentynineteen theme as this is where the malicious file has been deployed to.

As a good security practice, you should never have more than 1 theme installed on your site even if the other themes are not active, as they would get outdated and attackers could still use them to infect your site.

I would strongly recommend going through this answer here on how to keep your Wordpress website secure:

https://www.digitalocean.com/community/questions/how-to-secure-wordpress-without-a-security-plugin

The malware which you see is most likely a crypto miner.

The fastest solution would be to spinning up a new Droplet and installing a fresh Wordpress installation, then export your database from old your website and import it to the new Droplet, then just install the same plugins and themes to your site. This should bring your website almost up to the same state as it was on your old Droplet.

Another approach would be to keep the Droplet and scan it very well for any other malicious files or hidden backdoors. You could use a tool like maldet but you would need to do some manual search as well.

In order to prevent this from happening in the future, I would recommend just following the steps from the answer that I’ve shared above and maybe adding a security plugin like Wordfence.

You could also consider adding mod security for your Apache service:

https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu

Let me know how it goes! Regards, Bobby