theme-compat/404.php

Steve,

Thank you for the samples. I will send 404.php on to the developers and find out about why it is not found while in a WP core directory.

Can you tell me what theme and plugins you are using, and if all of them were up to date (along with WordPress itself) before this happened?

If you don’t want to post them here, you can email the list to me at mattr (at) wordfence.com (please also include a link to this post, if you send an email.)

We also have a guide on cleaning hacked sites, which may help you find additional files and/or the original source:
How do I clean my hacked site using Wordfence

-Matt R

Hi,

I use the following plugins on the site in question:

– Admin Post Navigation
– Advanced Custom Fields
– Advanced Custom Fields Viewer (disabled)
– Akismet
– Custom Post Type UI
– Enhanced Media Library
– Ewww Image Optimizer (disabled)
– Far Future Expiration Plugin (disabled)
– Hello Dolly
– Infinite WP – Client
– Maintenance Mode
– TinyMCE Advanced
– Toggle wpautop
– Wordfence Security
– WordPress Importer
– WP SuperCache
– WPFront User Role Editor

All of them were up2date. I migrated the site on the 31st of august and since then I think nothing released updates as far as I can remember. If one of the plugins did I must have installed it pretty quickly though ^^

Regarding Themes I only have the default ones as well as a theme I developed myself based on the WordPress Bootstrap Boilerplate. There isn’t really anything fancy going on in the theme as well. Nothing special other thana few custom templates.

Thanks for your tips regarding site cleanup but as of right now it seems that the problem is contained with the 3 files mentioned removed. We still see requests from france and belgium to the wp.php file but they all return with 404 so the file doesn’t come back at least.

Thanks!
Best,
steve

Ok I’ve just done another scan since another file (..php) made it to the root of my wordpress install and I am still not sure how it even got there.

Besides that that is again a spam file with a redirect in it.
I’ve uploaded an updated version of the ZIP File with all the files I “received” at https://dl.dropboxusercontent.com/u/7938470/WP-Hack.zip

The new file ..php also wasn’t found during the scan. I am scanning with all the scanning options turned on (even the false positive option) still not found.

What am I supposed to do here? I am getting the feeling, that I shouldn’t rely on the scan output at all since it simply doesn’t find shit. ..php is again definitly not a wordpress core file but resides in the root of the install? I thought that is one of the things that you say you cover (Comparing wordpress installs with vanilla wordpress installs on your server to find compromised stuff and all)

Please tell me why nothing is found with this scan.

Sorry to hear this is still causing trouble on your site. I’ve sent this to the team for additional help, and it may take a little longer to answer since this is not a typical issue.

Right now I’m just glad that one of the team working on this plugin actually reads this forum. Hope your devs can come up with a solution soon.

I am working closely with my webhoster as he found now, that a lot of wordpress installs on his server are infected.

There are always the same files involved (like the ones i’ve provided you)

This line bothers me almost the most in this whole situation.. ^^
“//password: enzo”….
f-ing enzo..

Best,

steve

Hi Steve,

We have the higher sensitivity scan options because they often yield false positives. It’s a compromise between reducing false positives and improving scan sensitivity.

I think at this point Wordfence has done it’s job and identified that you’ve been hacked somehow. You need to figure out how they got into your site, because it appears that you’re continually being reinfected.

Suggestions:

Your WP installation may be up-to-date, but check all other applications, especially old versions of WP lying around and anything else like phpmyadmin. Make sure they’re up-to-date. Change all passwords. Work with your hosting provider to try and identify the source of the infection and close that hole. Then the rest of the job is easy – you just need to remove the malicious files.

Thanks for sharing those samples with us. As Matt mentioned, we’re going to use them to improve our detection.

Regards,

Mark.

Hi,

thanks for the help so far.
It seems, that we found the culprit. It was a Joomla (no pun intended – lol) installation from 2012 which is neither maintained nor updated which opened up the way for enzo (i just call him that)

But I would just suggest, that these foreign files which aren’t part of a standard wordpress install at least show up as a warning or something like that.

In fact wordfence didn’t do its job for me since I only installed it after the fact to scan my wordpress install for any more malicious files only to go look for them myself after finding one so blatantly residing in the root of my install without wordfence even noticing. So this would be really nice if this feature really works as advertised.

Hope you can figure it out.

Best,
Steve

It’s good to hear that you tracked down the problem, with the older Joomla site. We will check out the options to see what can be done without making false-positives for other users who have more software than just WordPress installed for a single site (e.g., non-WP forum software, chat systems, custom code, etc.) Thanks for the feedback!

-Matt R