Sorry to hear that. Did you find anything fishy in the web server log?

Just looked and I don't see anything strange. I saved what appears to be the main file that was used. It's about 1500 lines of what appears to someone taking advantage of a plugin weakness. I can't tell which plugin though. It appears to set up an upload of a file which I'm guessing does some of the nasty stuff. I'm not a PHP programmer so I don't know the details of how it works.

Rich

What's your server? Are you using shared hosting?

Might want to let them know.

I'm on Hostgator. I'll let them know.

Hi Danni,

I don't have TAC on this particular site. I have an Artisteer theme on it so it never occurred to me to use it for this one. Now that I think about it, I had another site last year with an Artisteer theme on it that was Pharma hacked. That's how I sorta knew where to look for the problem. Coincidence...maybe...I don't know. Not sure how the theme would allow for injecting code into the database. Really seems more related to some plugin based on looking at the code.

- Rich

Couldn't sleep last night so I jumped into GWT only to find out that the original site wasn't the only one hacked. Spent the next 6 hours cleaning them out. I think I got it covered this time. Ran an sql query for base64_decode and deleted them. Ran an exploit scanner and found several files containing base64. All named differently but upon closer examination, they all had the same code.

I even found the file that was uploaded into the Uploads folder that probably started the whole thing. Deleted that puppy out of there as well.


- Rich

It is a good idea to have empty index file in the uploads folders to keep it's content hidden.

Otherwise it is just to easy to see all the uploads and plugins you have in there.

I don't understand why WP dont have it secured by default..

I even keep wp-config.php file away from from public_html so it's not publicly accessible, on top of that permissions should be set to400 or at least 600.
There are free plugins around that will hide your WP version etc
Here is a good post about protecting WP from malicious URL requests

My experience from hackers through a WordPress issue was with a client who didn't update his WordPress. We started notices odd files appearing in random locations. These files were PHP scripts BUT they were disguised as IMAGE files (JPG, GIF, PNG). It completely baffled me (as a programmer), but the server showed them as images, but if you loaded it in a browser - WHAM! - a dump from the database.

Basically it had all they needed to know about the setup of WordPress and allowed them to come right in and change whatever they wanted.

Feels very dirty though, doesn't it? My client and I both felt violated! Our hacking was repetitive too, so - my advice is to keep an eye on it. There was a solid 3 days where we would wipe it and pull from backups just to have it go down again within an hour

I actually found all of our info posted on an Arabic web forum that appeared (from Google translation) to be a forum for people to "test" or "learn" hacking skills.

Good luck - keep us updated!

Thanks BlueLayerHost for the suggestion. I installed that one as part of my cleaning out the sites. It was recommended somewhere when I was trying to figure out where to begin. It found several of the rogue files. I used an sql query for the ones in the database. I've been checking them daily to see if it comes back and so for so good. GWT is starting to reflect the correct keywords now.

Also, I installed the Bullet Proof plugin to protect the .htaccess file.

- Rich

I use Drupal for my CMS and one of the things I can do is filter the 404 entries in a log file it creates which gives me the IP address of crackers trying to find the loop holes. You can tell it is a cracker because the same IP address is in 4 or 5 entries in the same second. A log of the 404 hits are trying to find WP loopholes and the other are trying to find phpMyAdmin loopholes. I monitor it daily just to get an idea. I then can block the IP address from the system and when I block it in one site I block it in all. The server log file for http daemon should contain the 404 entries as well.