Eli

Yeah, delete those rogue admin users if they are not users that you added.

Also, the Complete Scan should not be going that slow. On a decent server you should be able to scan 400 folders in about 4 minutes (100 folders per minute), and on a slow server you should still get those 400 folder done in no more than 8 minutes (50 FPM). Your server looks to be scanning only around 23 FPM, which is extremely slow even for a bad server, so something else must be wrong which is making it take so long. Also, 10,000 folders is a lot for one site, is it possible that you have other websites installed into sub-directories within the root folder of this main website?

Can you send me a screenshot of your scan settings and maybe check your error_log files to see if there are any PHP errors that might be causing the scan to run so slow?

If that user is an administrator and you didn’t create them, then it might have been a rogue admin user injection, I would definitely delete that user and also change the passwords for all the other admin users that you want to keep (in case those have been compromised too).

The quick scan is whole different type of scan that requires your server to have enough memory and processor time allocated to PHP so that the scan can finish in one go. It’s not like the Complete Scan that takes longer because it breaks up the scan job into smaller processes that are easier for servers with low resources to run.

It would help the WP Core scan go a whole lot faster if you had the Core File definition that are downloaded when the Automatic Update feature is enabled. Without that option, and when your memory_limit or time_limit are set too low in the php.ini file on your server, then you should just stick with the Complete Scan.

It looks like it is getting stuck in your cache directory. As a general rule it is bets to disable caching and delete all your cache files if you think you might have a malware infection on your site because the cache files could preserve some of the infection even after the main threat has been removed. You will want to restart caching with an empty cache folder only after you are sure that all malicious threats have been removed so that they are not cached anew. Deleting the cache also helps speed up the malware scan since there will be a great deal less files to scan, and as you have found out the hard way, actively writing cache into a directory that is being scanned can sometimes cause a perpetual loop that gets the scanner stuck.

If you are unable or unwilling to disable your caching software then you could choose to just skip the cache directory on the Anti-Malware Settings page, but that is not the best solution as it can potentially allow malware to remain if there are any malicious scripts hiding in that cache folder.

I am currently testing a stand-alone scanner that I plan to open for BETA testers early next year. After it is stable and secure enough to be used in the wild I will license it and start working on fully integrating this feature into this plugin. I can let you know when the BETA program is ready for testing if you want to be one of the testers.

Thanks for reporting this. I have removed this matching pattern from the definitions of Known Threat. Please download the latest definition updates and run the Complete Scan again to confirm that this file is no longer identified as a Known Threat.

Thanks for the feedback. I am currently working on a new release that will have these two records stored with the autoload values set to false.

This new update should be released very soon.

You can send me a sample of the payload plugin if you want but I have likely seen it before and it’s code is not likely to point to the source of the infection.

What will be your best clue to the source of the infection was the timestamps on those files as they were when you fist found them installed on your server. The most important evidence you can collect on an infected file is to stat the file BEFORE you remove, clean, delete, or modify those files in any way. You will wan to note the modified time and the changed time of those files that were added before you remove them. Then you can look in the raw access_log files on your server to see what activity on your websites was taking place at that exact time, and this will usually lead you right back to the source of this infection.

Thank you for the feedback. This is not a bug and there are some very good reasons to not delete the files:

In many cases the infected file is included or required by other files on the site. If the file is deleted before the references to it are removed from all other files then it could cause an error on your website that might break the site or even prevent the rest of the repair from completing successfully. So I decided that removing the malicious contents from the file is the safest way to complete the repair and also prevents the website from crashing.

Some malicious files are pinged regularly by bot or checked by the hacker’s automated scripts. Deleting those files would cause your WordPress install to handle all those malicious pings and return your 404 page, which will needlessly burden your server with all that unnecessary overhead and send up red flags to your hacker that you need to be hacked again. By leaving the files empty those pings will return a 200 response (indicating that all is well) even though they will run no code and take no resources from your server.

There are also some types of infections that are embedded somewhere else on the server and are frequently scanning the filesystem to see if all the planted malware files are still present and immediately replacing them if they are gone, so it can sometime help to prevent reinfections from a cross-contaminated site to leave the empty files there as placeholders so that they don’t get rewritten.

All of these conditions are only relevant some of the time and in many cases these files can be deleted without ill affects, but there is also no threat no danger and no problems caused by leaving these empty files on the system. I know that it may look scary or ugly to see files with weird name in directory where you know those files should not be, but I choose to err on the side of safety and leave the empty files in place. Most WordPress admins and content creators will never even know that the files are still there, but for those sysadmins and developers who look at the files on the server and have a personal issue with the clutter or the eyesore of leaving those empty files on the system, they generally also have the skills to remove them if they feel that the reasons form deleting them outweigh the reasons for leaving them.

There is a nice little command that will clean up all the empty files in one go if you want an easy way to clean up after an infection is dealt with:

find /path/to/public_html -type f -size 0 -name “*.php” -delete

My first reply was automatically held for moderation because I used the “V” word (you’ll see when a moderator has time to review it and allow it to be posted). Until then…

I see that you have posted an update with a link to the infected content in your DB. I am familiar with that particular script and that variant has been in my definition updates since the 7th of last month, so I am not sure why it was not detected by my plugin on your site. Are you sure that specific code was in the DB of a site that you scanned with my Anti-Malware plugin, and you had the latest definition updates installed?

Thanks for reporting this new threat. I have seen similar threats use this same technique of installing the WPCode Lite plugin and then creating code snippets in the DB to hide it from view in the wp-admin. I all the infection of this type that I have seen the sites were all compromised in different ways. Some were brute force while others were exploited using various un-patched plugin vulnerabilities.

I would like to see the details of all the code you found but that link to the file you shared on file[.]io was already deleted. Can you please send me any files you have directly to my email?

eli AT gotmls DOT net

It looks like some kind of JSON log of IP address that might to have something to do with the WPBakery JavaScript at the bottom, but I don’t see any relevance to the hack.

You have had no new malware on the site since you restored the backup?

I can’t tell from just a screenshot if that particular web shell is already in my definitions yet or not, I would need to see the code to know for sure. If you had run the scan after the infection was put on there then maybe it would have found it and we would know, but if you have already erased the code by restoring a backup of your site then I is probably too late to tell.

If it happens again then it would be better to run the scan to see what it finds. Also, it would be most important to record the infection times as the timestamps of those infected files could be instrumental in determining how the site was hacked, thereby helping us find the weak point in your security that is letting in the exploit in the first place.

Please feel free to contact me again if you find your site infected so that I can help you find the cause.

Sounds great! I made you a contributor and updated the code with the PHP8 fix that you added.

You can now make any changes you need to keep the plugin updated and fully functional in the future.

Thanks again for your contribution and commitment to this plugin!!!

That’s great! Would you have any interest in taking over this plugin on the WP Plugin Repository? I don’t see myself having time to keep up with it and if you want to make it yours I would be happy to turn it over to someone with interest in it.