Get Off Those Maliciously Loaded Scripts!
Download this free Anti-Malware Plugin for WordPress.

So this Core File is being repeatedly modified by some unknown hack, and after it is modified there is a syntax error that crashes your site until you manually fix it, is that right?

First and foremost when tracking down the source of an intrusion is to gather all the evidence you can before fixing anything that was tampered with. You need to stat the file the was hacked before you fix it so that you can tell exactly what time the hacker modified/changed that file (make sure to get both, the modified time, and the changed time). Once you have fixed this hacked file you have effectively wiped out any trace of the original modifications by the hacker. It’s like washing and putting away a knife at the scene of a crime, sure the kitchen is cleaner now but you can’t get any fingerprints or DNA samples from the weapon.

If you use the Automatic Fix feature in my plugin then a backup of the infected script is stored in the Anti-Malware Quarantine with the original infection timestamps preserved for future review. If you modify or delete these infected files manually then that info is lost.

Once you know the exact time of the infection then you can search your raw access_log files for any activity on your sites at the exact time of that latest infection. This may lead you to other malicious scripts (possibly even on another site on your server if you are on a shared hosting plan). Those newly discovered files will also need to be handled with the same care to get the stat info from them and look up those times in the logs, etc., etc.

If you come across any new malicious files that are not being identified as a Known Threat by my plugin then please email those files to me before you fix them so that I can add them to my definition updates. reading and understanding the malicious code inside those files can also help track down the source of the infection.

I have just released a new plugin update (version 4.21.95) that should solve this issue for you. Please try the new update and let me know if you still have any issues.

That first folder that could not be scanned should not even exist:
…/httpdocs/wp-admin/css/colors/blue/blue
There should not be another blue folder inside wp-admin/css/colors/blue/
My guess is that it was skipped because it is a recursive symlink to the parent folder so it would be a needless infinite deep dir to go exploring that path. So You can look on your server to see what is in there but I would advise that you just delete it.

Also, a lot of the files you are listing should not even be scanned in the first place. I assume that you have modified the default list of extensions in the “Skip files with the following extensions” field on the settings page. This is not recommended, as those file types are skipped for a reason. There is no need to scan large binary files that cannot be executed on the server anyway. It is true that you could hide some PHP code in some of those files but it could not be executed without an include statement run from within a PHP file, that why my plugin will look for those malicious include statements.

So my plugin generally does a good job of finding the threat without wasting time and server resources searching non-executable code in large binary files, and you will find that the scans are much faster if you restore the default settings there.

There is a recovery link on the results page when the files are fixed and your site is tested, otherwise You can restore this code by going to the Anti-Malware Quarantine page in your wp-admin and selecting those files with the checkbox on the left, and then click the “Restore selected files from quarantine records” button.
Please also send me a copy of those files so that I can review the code in them and correct the detection if the definitions need to be update.

P.S. I see that your site is working now, so maybe you have already solved this issue, but I would still like to see the files that might have been misidentified or fixed incorrectly.

A blank white screen usually indicate either a 500 Error or else something has blocked the form POST, maybe because of some other security setting or overzealous firewall.

Check the Console tab in your browser’s Inspector for any Errors or Warnings that might explain the blank screen. Also look in the error_log files on your server to see if any PHP errors were logged when loading those pages.

No, my plugin does not require jquery at all.

I am curious as to what would have prompted you to ask such a question though. Would you mind letting me know why you are asking?

I believe that this lb_postrender_handler is a malicious ob_handler that was injected into the code on your site through a eval’d code that is most likely included within a hidden .MO file. The include(‘.hidden_xyz.mo’); is usually inserted into one of your core files, but it could have any name and it could be in any core file. The best way to find it is with the core file definitions included with the automatic update that you get with a premium donation. But I can also help you further if that is not an option for you. You can email me your site details directly if you need more help.

eli AT gotmls DOT net