Related

Problem 'Installation failed: Destination folder already exists.' with Wordpress Plugin Question Question
Issue with ubuntu 16.04 after migration Question Question

Question

Droplet Compromised? www-data processes

Posted May 7, 2020 506 views
WordPressLAMP StackUbuntu 20.04

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.

Add a comment
BCMulx
By:
BCMulx
Add a comment
1 comment

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.

×
1 answer
bobbyiliev May 7, 2020

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

How To Set Up mod_security with Apache on Debian/Ubuntu
by Jesin A
Here's how to set up mod_security with Apache on Debian/Ubuntu.
Reply Report
  • BCMulx May 7, 2020

    Bobby, Thanks for the reply. I think I’m going to try a manual cleanse before starting a new droplet to see if it works, but will be taking backups of my wp databases just in case. So far what I’ve done is below - anything else you’d recommend, or red flags you see? So far, everything seems to be running fine with no errors, but will need to monitor.

    SSH Key access only, password access disabled

    Removed all unused themes and plugins

    Updated all themes and plugins within Wordpress Admin (Would surprise me if this was the issue - everything was current version as of last week)

    Installed all pending system upgrades

    Removed cron jobs for www-data listed in initial post

    Removed pty8 files listed in cron jobs in initial post

    Installed latest version and ran “maldet -a /” as root to scan the whole system - nothing found

    Made all of the .htaccess mods in the “securing wordpress without a plugin” link

    What I’m still investigating - setting up mod_security (do you think the core ruleset is helpful / sufficient?), using a security plugin like wordfence

    Reply Report
    • bobbyiliev May 13, 2020

      Hi there @BCMulx,

      Well done so far!

      One more thing that I could suggest is using the wp-cli tool to run a checksum of your core files, it is a great way of detecting if there have been any unwanted changes to the Wordpress core files.

      Regarding mod_securtiy, I’ve used the OWASP ModSecurity Core Rule Set in the past. One thing to keep in mind is that sometimes specific plugins might not be compatible with some of the rules, so you need to test the site fully and disable certain rules.

      Also you could try using this site scanner here. It runs remote scans for your site and it is good at detecting some malicious JavaScript code if there is any.

      Regards,
      Bobby

      Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help