.htaccess file resets itself to default WP one and file permissions 444?

Thanks for the advice. I can’t find these words in my current WP config file.

As for a new wordpress test site, I have repeated several times in this ticket that I did that already and to my surprise BPS worked fine, despite known-to-conflict plugins like ithemes installed. Of course I also tried a test install with nothing but BPS on it, and it worked fine.

That would bring us to the conclusion that there must be a plugin conflict. But that doesn’t make sense since the problem still happens with all plugins except BPS deactivated. It’s quite paradox.

Nope, not a paradox at all. One of these things is true: either your host is automatically changing the root htaccess file or your website/hosting account is hacked. This is a very simple issue so you just need to find out which of the 2 possibilites above is true – nothing more and nothing less.

Well I’m 99% sure that none of the sites are hacked. What would a hacker have to gain by simply taking my ability to change the htaccess file? Because that is the only out-of-order thing with my sites.

Also, because I’m very concerned with getting hacked (as it cost me a bunch of money, time and nerves in the past), I followed the principle of “more is better than less”, so I not only installed BPS, I also installed ithemes, spyderspanker and spynot for multiple layers of protection. Together with very strong passwords/users, hiding username from author-archives and other tricks etc. it should be quite unlikely that a hacker gets through all of this.

Now one could assume that with so many tools there would be overlap and thus conflict but I don’t think that’s the case because the issue is still there when deactivating everything except BPS. Spyderspanker and spynot block bad bots via 404 error detection, IP and similar, but they don’t play with the htaccess. ithemes is known for conflicts, but on my test site I installed BPS + ithemes and BPS was working totally fine, so that shouldn’t be it.

Waiting for my host now, hopefully they can help. Because this problem occured overnight, i.e. 2 days ago, BPS was working fine on all sites, since yesterday I get the wizard warning message on all sites. So like you said, either host changed something or got hacked, which is unlikely.

So the most likely result is the host changed something that flushes the htaccess. But then why does it work fine on the WP test installation? That’s what I mean with paradoxon.

Well I am only telling you what I think is going on based on logic. It is simply just smart to eliminate that your host is doing whatever is occurring. So let me know what they say when they get back to you.

Thanks, I do appreciate that. This has been the best support so far for a (free!) wordpress plugin, so big kudos to you!

It just doesn’t want to get into my head that if the host is causing this, then why does the plugin work fine on a fresh test install. We can pretty much exclude hacking and plugin conflicts (unless there is some really deep problem that got cloned to new site installs – still doesn’t make sense since old sites were affected overnight just like the newer ones) – so only the host is left, but then logic would dictate that on a new install it shouldn’t work either?

I asked for an update in my ticket again but still haven’t heard back from the host. Will post here as soon as I do. Thanks again.

Yeah I agree with all of your findings and logic, but still things change all the time in the coding world and with web hosts so basically just getting some kind of answer from your host is the most logical next step to do. They may not be able to give you any kind of answer, but it is something you need to check out next and then you can start looking at other things.

Wow, I can’t believe it…and I’m getting scared again of what lies ahead of me. This is the reply of my host:

“A scan of the files shows a hack/exploit is in fact causing the problem.

I’ve attached a list of the files, which contain malicious code. This code is rewriting the .htaccess file appears to be using a variation of the exploit called “DarkLeech”.
Looking in the files listed you can see it as:
$path = $dir . ‘/.htaccess’;
$content = base64_decode(‘Long string of encoded text’);”

I checked out the attached list of files, and it’s always the same one for each of the sites: [domain.com]/wp-includes/nav-menu.php

Have you heard of this before? Would you advise just deleting the code part in question?

Ok stay calm as hard as that may be. If you are not calm then you are going to make bad decisions. A hacked website is just a pain in the neck that you have to work through. Just don’t make this any bigger problem than just what it is. If you have backups of all files and your database then take your website offline and restore everything.

And yes i have seen this exact very common hack before.

If you do not have backups of everything then this forum topic has all the general steps that you need to do: https://forum.ait-pro.com/forums/topic/wordpress-hacked-wordpress-hack-cleanup-wordpress-hack-repair/

Yeah well my host said they keep daily automated backups, so I asked them to restore those of last Sunday (as I believe that was the last day before BPS suddenly started to throw up that alert message). However, since then I put like 15 new sites on the server that are now all affected, because they were built with a clone-archive that contains the malicious code T_T

I asked them for a quote, but it’s not going to be funny for 15 sites. Any suggestions on how to remove this code for good (because I know some hacks just re-download themselves in a couple hours again) and how to keep it away in the future? Does BPS Pro help against this on future sites?

I don’t get if this is a “very common” hack, how the combination of BPS + ithemes still wasn’t able to keep it at bay.

1. You do not need to pay anyone to fix this.
2. You have to assume the worst and that is your entire hosting account is compromised – all websites under your hosting account.
3. Look at the link I posted. Worst case scenario you will have to do a salvage mission.

Nothing is going to protect your sites if for example you have an unsecure/insecure upload form somewhere. Example: all security plugins are designed to stop attacks against your website, but if you have an unsecure/insecure upload form somewhere then no security plugin is going to be able to stop a hack. Why? because if that upload form looks like a normal feature in another plugin or theme than blocking that normal functionality/form would mean a security plugin would have to block everything. Or in other words, nothing would be allowed to work normally on your website. ??

I like to use an unsecured/insecured upload form as the base example because 99% of all hacks are done by exploiting an unsecured/insecured upload form.

Well 15 sites is quite a lot, and that is assuming that the backups of the other 35 sites are actually clean. If not I could be sitting here several weeks just getting everything in order. My host is currently doing a database scan of all sites, as well as scanning the old backups to see if we’re good at least on that side of things.

Thanks, I checked out the link you posted. Like I mentioned, this is a heck of work and time, but obviously necessary. You gave an example POE, but how do you actually find one? I have comments disabled on all sites, the only upload would be via contact form (which is contact form 7, of course latest version), so how do I figure out how these people got in there in the first place?

“…how do I figure out how these people got in there in the first place”

You don’t waste your time with that at all. For the non-expericenced person you will only end up wasting your time trying to figure it all out. Just fix the problem. Then look at any plugins or themes you have installed that have upload forms.