Eli

The first step is to determine if this infection is coming from another internal file on your site or from another site. Check the timestamps on the latest infected file to see exactly when it was infected (before you clean the file). If you have already cleaned the infection with my plugin then you can find the exact infection time in the Anti-Malware Quarantine (times are recorded as GMT). Then cross-reference that time with any activity in your access_log file at the same exact time (keep in mind that your log file times might be adjusted for your server’s local time).

If there is nothing in your access_log for the times of your last infection then you will know that this infection is spreading from another site to yours (probably another site on your server). Typically, shared hosting accounts are not protected from cross-contamination, so infections from one vulnerable site can easily spread to other sites on the same server (even if they are on another account).

If you find a suspect in you log files please send it to me for further examination. If not then you should move your site to another (more secure) server.

I don’t see any redirects on your site. Are you sure it’s not just cached on your side or somehow caused by your browser?

Can you link to any outside reference to this redirect so that I can see what evidence of malware that you are reacting to?

Those two JS files were found to be safe in other cases but the read errors were caused by the memory_limit being set too low in the php.ini file on your server.

What malware is still persistent on your site?

What is your site or what URL is still infected?

Sorry for the confusion but there are actually two fields on that line of the registration form. If you cannot see the borders of each field that separates the left side of the name field from the right side then just try entering your last name into the right side of that field (or after entering your first name on the far left just hit the Tab key on your keyboard and then enter your last name ; – )

Thanks for sending me that log file. I can see that the code that was found as malicious in your log files was “eval($_REQUEST[1])”, which is very certainly malicious code. Of course it is unlikely that this code in your log file could be a direct threat but it is an indication of a malicious attack on your site.

It is also unusual that those access_log files would be in a directory that is inside your site_root, thus being in the scan results at all. However, seeing these malicious injection attempts in your logs does shed some light on the nature of the attacks. It would seem that they were intending to infect a Joomla site so I don’t think anything they attempted was successful.

You might want to confirm that your log files are placed outside your site_root so that they are not publicly accessible though.

That’s a great question. my plugin scans the contents of any files in the scan path, looking for patterns that match Known Threats. I cannot say why your access_log files were flagged as a threat without see the contents for myself.

If you want to send me one of these files I can give you a better answer. You can email those files directly to me:
eli AT gotmls DOT net

To be honest I am quite curious myself as to why those logs would have matching threat patterns in them so I look forward to your email.

It’s hard to say where that output buffer handler is being called from or even if it is even a problem.

First, does the Complete Scan work, does it finish, and how long does it take?

If you can run the scan, does it find any Known Threats?

If not then you might want to go through and disable each of your plugins one ata time, checking to see if that message goes away.

Please let me know what you find and if you need more help you can also email me directly:
eli AT gotmls DOT net

Looks like the same stuff on that other site.

Lit me know if it doesn’t come clean after the scan (be sure to clear the cache after the auto-fix).