Eli

That code that you keep finding is already in my latest definitions so my plugin is removing it whenever you run the Complete Scan. The problem you are still facing is that this infection keeps coming back no matter how many times you remove it, is that about right?

I see that you have taken some very thorough steps to secure your site, but one area that you have not covered here is your hosting environment. I am guessing that this site is on a shared hosting account and the biggest security vulnerability on any shared hosting server is cross-contamination from other infected sites. No matter how good a job you do locking down the security on your site it only take one back-door on any other site on that server to leave you wide open to another infection. Once a malicious script has been planted on any site that has access to the same file-system that your site is hosted on then that script can copy itself to your site and all the other sites on that server. In actual practice they usually don’t infect every single site on the server because then the hosting provider would have to take responsibility for the breech and clean it all up with some enterprise malware solution so these kind of scripts usually just focus on a smaller subset of the site that they feel they can get away with, and we may never know why they have selected your site as one of the site that they are picking on.

It is also likely that they have planted other back-doors on your site so that they can get back into the server through you if the other security hole gets plugged up. For this reason it is important to review your access_log files after each scan that reveals more infected files. You can get the exact infection time of each of the files that you clean using my plugin by reviewing the Anti-Malware Quarantine after the automatic fix is performed. The Quarantine log times are in GMT and your access_log files might be in the server’s local time-zone so make sure to correct for that when you are looking up those time in your logs. If you find any suspicious URLs being call up on your site at the exact time of the latest infections then you my be able find more scripts that are responsible for spreading this threat around.

If you cannot find anything else on your site and these infection keep coming back despite all your work to secure your site then you might need to look into moving your site to a more secure hosting environment.

Please let me know if you find anything new or if you need any more help.

Aloha, Eli

If you are working to prevent or contain an active threat then I would say: the more security, the wetter. While many firewall are very similar in function and might overlap on some of the same protection there is enough variance that it can sometimes be helpful to double up on your protection. The only thing you have to watch out for is overzealous firewalls that might end up locking you out of your own site 😉

Some firewall plugin might also block the operation of other security plugins. I think we all try not to step on each others toes but it’s a delicate balance when your job is to scrutinize suspicious activity on the site.

Don’t be afraid to try out other plugins but look at the reviews and look for plugins that are well supported so that you can get help if you get in over your head.

As for tacking down the source of this recurring threat, your biggest forensic clues are the timestamps on the maliciously modified files. Look in the Anti-Malware Quarantine for the Infection Times of the latest infections (these are represented in GMT) and then cross-reference these times with the activity in your access_log files.

• This reply was modified 5 years, 7 months ago by Eli.

The default location for the access_log files for Apache is in /var/log/httpd/ but every server is different and you may not have access to that directory on a shared server so your host may have put them somewhere in your user directory structure. If you have access to a control panel then you might see an option to view log files there. Ask your hosting provider if you can’t find them.

Hi Dave,
This key was successfully registered about an hour before you posted this support topic, and I see from your screenshot that you have the latest definition updates installed. So I suspect that this is just a caching issue on your end.

Try clearing you cache and refreshing your wp-admin and it will probably update that message to show that your site is actually already registered.

If not then you can also check the Console tab in your browser’s Inspector to see if there are any Javascript errors on that page that might explain why the registration check is being blocked.

No the quarantine is just a record in the database of the infections that were found, they will not be release if you remove the plugin.

Also, I agree that it’s always good to remove any unused plugins and you can deactivate and non-essential plugins for troubleshooting too, but I would suggest that you reactivate any plugin like mine that might help you find and fix the infections that you are trying to clean up.

I don’t think that warning about wp_version_check has anything to do with my plugin. I get that warning on a lot of sites that don’t even have my plugin.

Can you please check it again with all of the firewall rules disabled in my plugin and make sure that you don’t get that warning anyway?

I sorry but this is not currently possible with the way the scan engine runs. I am working on an feature that will make this possible in a future release but it’s complicated and I don’t have it ready even for BETA testing yet. I can post another followup here when I hove something like this ready for testing if you would like to know when it’s ready.

• This reply was modified 5 years, 8 months ago by Eli.

Hi @brandostick,
Twice I have given you this guidance to look in your access_log files for the clues to what is causing this.

A better lead might be to try and figure out what PHP script was responsible for writing those IP addressed to that class-wp-http-netfilter.php file. There is nothing inherently malicious about having IPs logged in a file but it is suspicious and it could be the forensic evidence we need to find the malicious code as long as you haven’t deleted or tampered with that file since it was created. What you need to do is look in the access_log files on your server for any activity on the site at the exact time that this file was created. Then we should have a good lead on how and why these IPs were written to that file. Please send me any files of scripts that you find that might be part of this new threat for my definition updates so that my plugin will be able to remove then automatically in future scans.

You said that the file wp-includes/class-wp-http-netfilter.php has been modified on 21 August 2020 12:05 PM so you just need to see what happened at that exact time in your access_log file.

Die you try getting a hold of your access_log file? I think that might be the key to finding out what script wrote those IP addresses to that class-wp-http-netfilter.php file.

If there is anything that you don’t want to post here you can send any sensitive details directly to me:
eli AT gotmls DOT net