A few weeks ago, I started receiving tweets and emails from people who claimed that search results for my site were looking more like a pharmacy than a helpful Web resource. Of course, upon hearing such blasphemy, I immediately opened a new browser tab, looked around to make sure no one was watching, and then started Googling myself…and if you think that is some NC-17 material, wait til you see what my search results looked like:
Figure 1. The three red arrows highlight <title> tags that were cloaked by the WordPress pharma hack. Helpful Web guy or reckless pill-slinger? You decide 
What you don’t see in the picture above is a hacked <title> tag for my home page, but that’s only because I fixed it before realizing I was going to write an article about these shenanigans. Suffice it to say that, before I caught the hack, my site looked more like the best damn antidepressant resource than the best damn blog on the planet. Enough of that, though—let’s dig a little deeper into the WordPress pharma hack and see what it’s all about.
What Does the WordPress Pharma Hack Do?
There are three facets of the pharma hack that I find particularly interesting. First, the results of the hack are only visible to search engines, and if your site is hacked, the public-facing portion of it will remain visibly unaffected. In other words, you won’t be able to spot the hack just by viewing the HTML source. The goal of any hack like this is to gain valuable links from high-ranking pages, and these hackers have wisely chosen to disturb the water as little as possible while going about their dirty business.
Second, like other hacks, the pharma hack must place malicious files in your WordPress folders in order to work its evil. However, unlike other hacks that I’ve encountered, the pharma hack disguises a majority of its code and saves it in the WordPress database, thereby making it more difficult to find and eliminate.
The third remarkable aspect of the pharma hack was that it didn’t affect every page of my site. Further, it only targeted the pages of my site that receive the most search traffic. For example, in Figure 1 above, the three hacked titles correspond with the following posts:
- 2 Sure-fire Ways to Make Money Online
- Deal or No Deal: A Statistical Deal
- How Much Should a Web Design Cost?
Interestingly, these three pages contain the most potent and high-ranking keywords on my site. Also, back when I ran AdSense, two of those three pages were the highest earners on the entire site (as far as PPC is concerned, anyway1).
With these key points in mind, let’s answer the original question here: What does this hack do?
The WordPress pharma hack quietly exploits your highest-ranking and most valuable pages by overriding the title tag and by inserting spammy links into the page content. Interestingly, the modified title tag and spammy links are only visible to search engines.
How Does the WordPress Pharma Hack Work?
We know what the pharma hack does, but in order to eliminate it and to prevent attacks like this in the future, we need to know how it does what it does.
Basically, the hack consists of two parts—malicious files in the WordPress plugins folder coupled with encrypted code in the WordPress database. The files in the plugins folder contain code that runs the encrypted code stored in the database. Because of this, the pharma hack is dependent upon these rogue files in the plugins folder.
Typically, hack files contain easily-identifiable PHP functions like eval() and base64_decode(), and although the pharma hack is no exception, there’s one major difference. With the pharma hack, these functions are stored in the WordPress database as strings, and they’re encoded backwards! At runtime, a hack file in the plugins folder pulls these strings from the database, flips ‘em, and then runs ‘em as functions, and that’s how the deed gets done.
Oh, and remember how I said this hack only targeted my most potent and high-ranking pages? Cleverly, the hack pings Google Blog Search with queries like this one to see how many links a particular page has, and then it stores the results in the database. At runtime, the hack uses the number of links to determine which pages to target…
Sneaky bastards
How to Remove the WordPress Pharma Hack
Even if you don’t see any symptoms of the pharma hack (like cloaked title tags in search results), your site may still be hacked and therefore completely vulnerable. To know for sure, you’ll have to dig through the two places where the hack is known to romp—your WordPress plugins folder and your WordPress database.
Oh, and before we go any further, let’s get one thing straight—you are running the latest version of WordPress, aren’t you? Good, I knew you were the sensible type
Step 1: Remove Hack Files from Your Plugins Directory
Let’s start by examining the WordPress plugins folder for hack files. Using an FTP client, navigate to the /wp-content/plugins directory, and then locate your Akismet folder. I’ve recommended this particular folder as a starting point because I found malicious files stored here on three different sites; however, based on what I’ve learned about the pharma hack, these malicious files could be in the directory of any active plugin. Therefore, in order to do a thorough diagnosis, you should check any plugin that was active at the time your site was hacked.
Using your FTP client, make sure your viewing options are set to show hidden files, and then check to see if any of the following malicious files are located in your Akismet plugin folder:
.akismet.cache.php.akismet.bak.php.akismet.old.phpclass-akismet.phpdb-akismet.php
Ultimately, the important thing to note here is not the filenames themselves, but rather the patterns these names follow.
Items 1–3 are hidden files, and they all exhibit a characteristic naming structure with .cache, .bak, .old, or a similar pseudo-extension in the middle of the filename. Generally, you’ll find two out of three of these files together—one will look like this, and the other will look like this.
Items 4 and 5 share a naming convention, too—they are simply the plugin name (or a truncated version of the full plugin name) prefixed by either class- or db-. If you find a file that matches this convention, its contents should look like this.
Now, when you check other folders, you’ll know what naming patterns to look for when attempting to spot hack files, you sleuth you!
Here’s what one of my infected Akismet folders looked like; note that an uninfected Akismet folder only contains three files (akismet.gif, akismet.php, and readme.txt) and no hidden files:
Figure 2. Two hidden files inside the Akismet plugin folder that were planted by the WordPress pharma hack.
If you find infected files, delete them! Doing this will effectively end the pharma hack symptoms and restore your search results, but it’s important to note that your site will still be vulnerable at this point. In order to completely remove all traces of the hack and restore the integrity of your site, you’ll need to dig into your WordPress database to remove some lingering offensive code.
Step 2: Remove Malicious Code from Your WordPress Database
Because this step involves database interaction, it’s crucial that you pay close attention to the instructions outlined here. Also, it’s always a good idea to make a database backup before manually editing anything, so don’t say I didn’t warn ya!
To begin, you’ll need to access phpMyAdmin, which is a program on your server that allows you to view the databases associated with your hosting account. If you’ve never heard of phpMyAdmin and don’t know how to access it, don’t worry—simply contact your Web host, and they’ll be able to help you out here2.
Figure 3. Select the wp_options table in your WordPress database.
Once you’re inside phpMyAdmin, select your active WordPress database from the left side of the page. If you’ve selected the correct database, you’ll notice a new set of links on the left—a collection of tables that look like those shown in Figure 3. From here, click on the wp_options table, and this will allow you to browse the table contents.
Your goal here is simple—you need to delete database entries that contain malicious code. Fortunately, finding the entries you need to delete is a simple job if you use the phpMyAdmin search function, which you can access by clicking the Search tab at the top of the page, as shown in Figure 4:
Figure 4. Click on the Search tab to search the wp_options table inside phpMyAdmin.
On the search screen, you’re going to need to search the option_name field (see Figure 5 below) for the following rogue database entries:
wp_check_hashclass_generic_supportwidget_generic_supportftp_credentialsfwprss_%— Attention! In this case, you should delete all matches exceptrss_language,rss_use_excerpt, andrss_excerpt_length(these are legit WordPress database entries).
Figure 5. Search the option_name field for malicious database entries from the list above. If you find any of these entries, delete them!
What Next? (And Some Helpful Prevention Tips!)
Now that you’ve successfully removed the WordPress pharma hack, you’re probably wondering what you can do to prevent stuff like this from happening in the future. On that note, I’ve got some good news, and I’ve got some bad news. First up, the bad news…
At this time, there is still one huge unanswered question about the WordPress pharma hack: How in the hell did the hackers manage to get into your server in the first place? I’ve received reports of the pharma hack on a variety of different Web hosts and server configurations, so it’s clear that the main vulnerability extends beyond a single host/server platform. So far, the only common denominator between the sites I’ve examined is that they’re all running WordPress, but even this fact doesn’t mean that WordPress itself is the problem.
Alright, with the bad news out of the way, it’s time for the good news: You can prevent hacks like this in the future. Rather than rehash the information here, I’m going to point you to a fantastic resource on WordPress security tips. From the perspective of someone whose site just got dropped from Google’s index because of the pharma hack (that’s me), you would be wise to follow these simple security suggestions
1 For the record, I think AdSense and PPC advertising are terrible ways to make money online for two reasons. First, they sodomize the visual flow of your site by taking up valuable real estate, and second, they simply aren’t as genuine and helpful to mankind as other methods of monetization. For more, read up on the two methods I recommend for making money online. ↩
2 If you’re unhappy with your current host or not getting the answers you need, check out what I have to say on the topic of Web hosting—my guys will help you out for sure. ↩
189 comments… read them below or add one
Thanks for this post, it will really help a lot of us out! I haven’t been hacked yet but I will definitely follow through on your steps for security and making sure no rogue files/entries are lurking within my files and database.
I noticed that the hacked files in your screenshot had older timestamps on them. Did you by chance notice if the pharma hack was using the linux ‘touch’ command to change the mtime?
Lew
Excellent question. I did not notice the ‘touch’ command, probably because this is the first I’ve heard of it
It’s possible that the touch command exists in the encrypted hack files that I linked in Step 1 or in the encrypted code in the WordPress database; to know for sure, one would have to decode all that garbage and then inspect it.
Also, I didn’t mention it in the post, but this site was moved to a new server on March 14. Right around that time is when I first noticed the strange timestamps, and since I never came to any explanation as to why the timestamps were all reverted back to 9/5/07, it’s quite possible that the hack did indeed play a role here.
I’ll be interested to see if other people whose sites were infected noticed similar results while working with these files via FTP.
If the hacker was using touch to set a timestamp in the past, you’ve got big problems because that requires elevated privileges (typically root access or file ownership) so I’d check the ownership of those files too.
More likely is that the hacker uploaded a zip or tar file and unpacked it on your server preserving the timestamps from when the zip was created. I wonder if Wordpress’s plugin update mechanism got compromised?
Great investigation and write up, Chris. Let’s hope you can keep the scumbags out.
Great post Chris. It ALMOST makes all the hell we went through (mostly you) worth while…
I’m so glad you got this figured out! Thanks for all the hard work, I know we all appreciate it.
Also, great question by Lew.
So, I’m guessing that if I’m not using Askimet I’ll be ok? That’s a wicked hack dude. Some people need to use their brilliance for good causes instead of this nonsense. Good job in finding a solution though. That’s masterful coding work dude.
Brendan, unfortunately, you cannot make that assumption here. In fact, on this site, one of the hack files was located in the
/search-and-replaceplugin directory (from the Search and Replace plugin), and it took me a long time to get rid of the hack because I simply wasn’t looking in this location.Also, the pharma hack contains a ton of dynamic code that allows it to “chameleon” its way into any available WordPress plugin folder. For instance, the hack file that I found in the
/search-and-replacefolder was calledclass-replace.php. By contrast, the hack file that I found in an Akismet folder on another server was calledclass-akismet.php, but it was the exact same file.Ultimately, I think Akismet is a convenient entry point for this hack because:
ok, thanks dude for the quick answer.
@brendan
I don’t think that there is evidence to say definitively that akismet is the problem. Chris even says “these malicious files could be in the directory of any active plugin.”
Still scary, though!
I checked and I don’t have that issue, but the cleanup and security tips are things that we should all take more seriously. A few sites I run were recently defaced and this post made me take a look even closer. Glad I have you on RSS. Looks like a fun weekend for security!
The pharma hack is seriously clever in the way it focuses on the highest rated pages in google and that it only offers up the hack to the search engines.
Fortunately, I was not affected by the hack perhaps due to solid hosting on a VPS on Liquidweb, and the lack of PPC on my site. I follow your recommendation of making and selling my own products as well as making affiliate sales of products I use and can recommend.
Many thanks Chris for the extensive forensic work on this and the excellent documented recovery process. Your vigilance is appreciated. No doubt the next attack will be even cleverer and Wordpress 3.0 may open a few new holes so it it is good to know you eye is on the ball.
Chris, I don’t think it just attacks your ranking pages. For example, I doubt this page is kicking butt in the rankings but it’s still been hit.
Of course, that site’s also running 2.7 so who knows what kinds of hacks it’s been exposed to.
Great analysis of the hack though it always bothers me when the exact “how” of the hack remains unknown. Seems you’ve been very thorough so hopefully you caught it all.
I guess if you check your rankings and main keywords on a reasonable frequency you might also notice this?
Absolutely. As a website owner, it just makes sense to know the pulse of your site in as many places as possible—sales, traffic, search, CTR, etc.
Fabulous post Chris!
I haven’t been hit by the pharma hack, but in the last week people have reported malware warnings (sometimes) when visiting my WP blog. I found a piece of base64_decode() PHP that was in my footer.php file. Hopefully that was the culprit.
When I search my DB using the terms you have above, rss_excerpt_length also comes up in the rss_% search. Is it safe to assume that is legit also?
Yeah, that one’s safe if the value field is short and sweet.
I was hit by this one a couple months ago and I wrote numerous notes as I went through the painful process of removing this one. At least from my experience, there are far more steps involved to fully remove it. I hate to say it but I’d bet you’ve still got the bug lurking in other files and it’ll rear its head again. The infected code gets planted in many more files than those you mentioned and leaves multiple backdoors. The hacker simply returns a week later and enters one of his backdoors you didn’t find and replaces the database code.
I’ll gather my notes and send them to you privately.
Tony Spencer – Can you send me your notes as well? Our whole blog network (40+ sites) got compromised by this hack, and we’re STILL having issues.
The latest issue was some base64 encode code in our wp-includes/general-template.php file. What doesn’t make sense is that we upgraded Wordpress after the initial incident, which means everything in the wp-includes directory should have been replaced with fresh files.
It’s scary how complex and thorough this hack has been!
I’ve also been hit and have been trying very hard to clean up the mess. My husband reinstalled Wordpress and reloaded the database, but some images got broken which I’ve been gradually fixing.
A few days later, though, I discovered that the search I have on the site redirects users to a pharmacy site, so obviously there’s still bad code around.
I followed the instructions above, but wasn’t able to find any of the “rogue databse entries” mentioned in my SQL databsae.
I’m pretty desperate at this point and would be grateful for any pointers.
Fingers crossed,
Debbie
Solved it. The hacker had placed two innocent-looking files in wp-content. One was tweetmeme.tmp and one was akismet.tmp. Both files were 0 size.
I only knew to look for them after reading your tips, Chris (re: innocent-looking files). THANK YOU.
So, to be clear, being 0K, they didn’t have anything in them and were truly empty? I’d really like to understand more about the 0K as we can add that kind of search to MalWatch which would be helpful. . .
My “fix” only worked for one day, so obviously there’s still malicious code hanging around. I can’t find it and I’m tired of spending so much time doing Wordpress admin/fixes for all my blogs.
I’ve decided to convert all blogs out of Wordpress to a paid hosting service. I’ve been using Wordpress for years, but I’m just one person without any staff and also without technical expertise…think I’ll be better off paying someone to take care of the back-end stuff so I can focus on the content.
Do you use the www-data user and group on your server?
As far as I know, no.
Wouldn’t it be best to:
1. Backup your database.
2. Search and remove the offending entries.
3. Install a fresh copy of WordPress and your theme
4. Follow the security tips
Seems like that is the only way to have peace of mind.
Brad, the theme doesn’t really matter here. This particular hack targets the plugins folder, so if you truly want to be secure, you should nuke all your plugins and start over fresh from there.
I guess my point is if the hack found a way into your site, who knows where he has been and hidden code. It’s much like trying to diagnose operating system problems. Sometimes it’s better to do a fresh install of everything as it can actually save time and ensure nothing else has been compromised.
Thats a very good idea. All the necessary things what we have in the plugin folder in future comes with the thesis theme. Great idea.
I don’t believe ftp_credentials is a rogue db entry.
I only found this entry on sites that had been running WordPress for a long time (with versions prior to 2.8), and since it doesn’t exist on new installations, it’s safest to just delete this entry.
In my case, sensitive information was available in this db entry, so I chose to nuke it.
Great write up Chris and luckily (yes I believe it is simply that with so many high profile sites have got ownd) we have not had any of ours or clients WordPress sites compromised so far. Hopefully this will remain true with the well known security measures we have in place but like others I would really like an update as to how this has occurred if you find out anything more.
As soon as I find out the root cause of the pharma hack, I’ll definitely post it here.
Great post man.. I went through this nightmare yesterday, but mine was slightly different. I don’t think our hacker had DB access, so he was limited to hiding code in our theme files and such. It was really slick how he was able to make the code look innocent enough that I wouldn’t give it a second look. Took me the entire day to fix everything!
Totally. That’s actually an “old-school” hack at this point—I’ve suffered no fewer than ten such bouts of theme file hacking. Although I don’t know for sure, I believe these hackers are able to embed links in your theme files because they access the file editor from within your WordPress admin panel (which is why they don’t need FTP access to do this deed).
That’s what I thought at first, but the code in the theme files called other files that they dropped on my server.. Basically, they used a require(…) statement to call an external file that contained the base64 code.
A slick way to get past the Exploit Scanner plugin, and avoid immediate detection when we edited the theme files.
I am always amazed by the ingenuity of hackers and that of the ones the prevent hacks.
Thank you for the informative post. I will definitely keep an eye on this attack for my blog as well as those of my customers.
What a nightmare! Thanks for posting this detailed description of what happens and how to fix it. Yikes – I hope I don’t have to deal with it. But it’s so good to know there is a resource if I need it.
Best, Wendy
Wendy, I don’t know if you checked your database for any of the rogue entries outlined in Step 2, but doing so is certainly in your best interest. Don’t wait for the symptoms of the hack to show up; instead, check out your database to make sure the hackers don’t have a convenient way of exploiting your site.
good post, can we now go frag noobs?
Yes, n00b-fragging is imminent. Finally.
About time.
Buy the stimulus package.
Oh shiz, I haven’t even checked that out yet!
noob.
Chris, thank you so much for the details on this. Based on the pattern approach, we are going to add pattern extension searches (blog owner’s choice) and hidden file lists to the next rev of WP-MalWatch . We were going to add a list of “decode” call references but based on the trick this hack used, we would be chasing the wrong thing. Any thoughts on systematically looking for patterns that the hook used to drop the decode call?
Derick, Brian showed me your plugin last night, and after checking it out, I really think adding pattern extension searches and some db scrubbing (for known malicious entries and/or pattern matching) would be fantastic.
To answer your question about decoding specifically, the pharma hack placed
edoced_46esabinside a database entry. In my case, this call was inside one of therss_%fields, but I can’t say with certainty that all calls of this nature would occur insiderss_%fields (which only exist if people ran WP 2.7 or older at one time on a particular site).Chris,
My bad for missing the reply. yeah, we just released the 2.0 version to WordPress.org this morning and it has file extension pattern searches. Database searches are the next level which we will get to.
I hate to say this but I love when smart people get pissed off (e.g. YOU) as it produces great insight on problems that need to be solved.
You can see features and download here. Nick Ohrn is the dev brains behind this.
Thanks for a specific and thorough post, Chris. I spent fifteen or twenty hours and two failed fixes rooting out a pharma hack from our EndGame site. Although the symptoms of the hack were the same for our site, the causes were totally different. I’ve gone through your suggestions just to double-check.
In brief, the hacker installed a phpshell in our theme directory with the unassuming title “403.php”. The phpshell then granted access to pretty much everything else. A simple “require ABSPATH” line in wp-includes/general-template.php and a few files in the cgi-bin later, we were in the pharma business. I’m happy to email more details upon your request.
Still don’t know how the initial hack happened – we have multiple admins so I suspect a bad password. Seems like that’s the big mystery to everyone though.
We’re running a couple of plugins that finally helped me identify the issue: Theme Authenticity Checker (found the phpshell), Audit Trail (ID’d the time and IP address of the hack), and WordPress File Monitor (alerted me to change in general-template).
Hope that helps.
You guys just set up your own ip access to your wp-admin and hosting only so that you are the only person who can access them.
usually the IP changes for DSL/dial in, so this does not work.
What FTP client do you use? I use Filezilla — I don’t think there is a way to display hidden files.
Yael, In FileZilla go to: Server -> Force showing hidden files
Lew
it might be useful to check if people have and use WP-Supercache — when deployed, there is a warning screen that a single folder is writeable publicly and this could be the loophole that hackers are using to deploy files to a wordpress installation … just a hypothesis… thanks for the informative and thorough blog post.
I have been wondering this same thing, Augustine…
Really nice post on how to identify and remove the wordPress Pharma Hack. I have just been looking though the plugin folders and everything seem ok. Hope you are safe now.
Martin
Chris,
No where else to ask this…
I see you are using Gotham as your title font…
I am using your excellent Thesis Theme and I note it is not available there. How do ya do it?
Best,
Dave
Dave, the only place you’ll find Gotham on this site anymore is in the sidebar headers. These headers are served as graphics and not as actual text, so you’re actually seeing something that I produced in Photoshop rather than something generated by your browser.
Gotham is a commercial font that is only available from my favorite type foundry, Hoefler & Frere-Jones.
Great, thorough and very useful post. After I’ve checked my clients’ sites (and my own) I’ll save this in case something crops up in the future.
@randy_duermyer
Hi Chris. Sorry to bother you here but there is no email support on DIYThemes. My agency would like to purchase dev option Thesis however our corporate card is linked to another inaccessible paypal account. Do you have any other credit card payment options that don’t require signing up for paypal? Thanks much,
Allen
Allen, you don’t have to be a PayPal account holder to purchase Thesis with a credit card. On the first checkout screen, there is a link on the left that allows you to purchase with a credit card, and from this point on, the transaction will seem like any other online where you pay with a credit card.
Thanks for this post, Chris. I was attacked by some kind of pharma hack on one of my wordpress blogs, and have yet to find the culprit. The hunt continues!
Chris…I need help. Someone has created a fraudulent blog, web hosted by you, claiming to be me. How can I get this removed? It is false and defaming. (Sorry to contact you here, but I could not find any other way to get to you.) Please contact me at my email address. Please, this is very hurtful to me and my family. lightspace101@yahoo.com
Joe, whatever site you’re on says nothing about being hosted by me. It says the design is by me, and that’s because this offending person is using a free theme I created on WordPress.com. If you’ll instead direct your energy to the support team over there, you should be able to find some answers.
Thanks Chris- Thank you for documenting this and sharing it with the world.
OMG, that’s a complicated tips for me. Any body can explain a simpler way?
If this is too complicated, hire someone. That’s the simpler way you’re looking for.
Sometimes stuff is hard.
Thanks for the reply Chris. I’ve made some screenshots to prove that users are really forced to sign up for a paypal account to use a credit card in your DIY checkout.
Here is the link: http://afftraffic.com/checkout-diy/
Please advise. Thx
Allen, you are being thrown off by the verbiage on that page. Although it says “Create an account or login,” you won’t actually be creating a full-scale PayPal account. Full accounts require bank information (routing number, account number, and verification), but the screen you’ve encountered does not put you through any of that. Simply go through with the transaction, and you’ll see what I mean.
Geez…another thing we have to look for. Hopefully the next update will look this down. Thanks man.
I was hacked too. I find this file ‘abspath.php’ in the /wp-content/plugins/cforms/
Removed the file.
Folks… Although ’shaking your tallywacker’ at this stuff sounds like fun, why not just give yourself time for other ‘funner’ activities, and protect yourself in the first place?!?
We developed the WP-Secure-by-Sitesecuritymon WordPress security plugin for our customers – and released it free to the community.
This plugin will protect you from this ’sneaky’ – but really weak ‘hack’ – and will also give you a malware and vulnerability scan – for free.
Check it out directly here or at our site.
Cheers and Enjoy yourself – safely
I discovered the problem on a blog to – and I found it in various plugin folders – even in plugins subfolders, like a /js folder that should only have contained .js files.
Sociable was actually one of the too…
But I can’t seem to be able to clean out everything in the database. I deleted everything inside the /plugin folder, and started cleaning the database.
I get a lot of rows like these:
rss_3e0f35d9b97106aaefb4341e67c31adf
I clean them out, but they keep regenerate it self and keep coming back.. Are they generated from something else than the malicious file in /plugin folder ?
Anyone had the same problem ?
Brian, any plugin that pulls an RSS feed could potentially be creating the database entries you’ve described.
When WordPress opted to go with a new type of RSS parser in version 2.8, they did away with MagpieRSS-style database entries that follow the pattern
rss_%. However, I’m certain that not all plugin developers updated their RSS parsers, and that’s why some plugins still place this kind of entry in the WordPress database.Personally, I would remove any plugins that output data in this manner, simply because they’re outdated. Also, now that you know database entries associated with these plugins are being exploited, what reason do you really have to keep them?
I removed all the plugins – so it can’t be a plugin thats causing the rows to appear…
Or at least I don’t think its a plugin – could it be a “leftover” from a plugin ?
There did’nt seem to be any RSS parser in the plugins – just some translation plugins and SEO stuff.
It was almost certainly left over from a plugin.
Sorry to keep replying
, but why do the rss_xxx rows keep coming, if I have deactivated and deleted them from the plugin folder.. ?
If you’re running a version of WordPress prior to 2.8, then that’s the reason why. Make sure your installation is completely up to date.
It is running the latest version – 2.9.2….
It keeps adding the cloaked title tags even with the plugin folder deleted..
Would a re-install of WP do any good ?
I finally got it cleaned – that was rather a nasty round.
I found malicious code in the /wp-content/index.php file.
I found malicious code in some of the core-files – even in the wp-config.php file, but that was a reference to another malicious file.
I did a re-install of all the files – deleted wp core files and re-uploadet them. Then cleaned the database – all the malicous rows was for me the RSS_xxx rows.
Hope this helps a bit for other people too…
and Chris, thank you very much for the support and this great article..
You’ve clearly got malicious files somewhere on your server. Check your root folder for these rogue files, and also be sure to check the content of your theme files (especially
header.phpandfooter.php) for malicious code.Have you heard of this hack being exploited on any other CMS systems like Joomla?
Bryan, I haven’t read any reports of other CMS platforms being affected. The pharma hack is extremely “WordPress-intelligent”—essentially, it looks like it was built to exploit WordPress installations and WordPress databases. Ultimately, WordPress is a good target for a hack like this because so many strong, high-ranking sites run it.
Excellent info, Chris. Thanks.
It really is amazing how many miscreants there are out there trying to hack sites. I never realized how bad it was until I switched from a shared hosting plan to a VPS.
I’ve resorted to blocking entire countries since some of them account for an alarming number of attacks. If you have a site or blog you care about, it’s well-worth paying attention to stuff like this.
Ryan, I also think that is one of the ways that a site would get hacked, many people simply set their directory permissions to 777 and forget about it.
Chris, did this happen to you while on a shared plan?
Christ, no. This happened while I was on an $800/mo. dedicated box, and then the hacked files mistakenly got transferred over to my new box at VPS.net as well.
Hi there Chris,
This is the first time I’ve come across such news of blogs being hacked. I will try the precautionary measures that you mentioned to make sure that everything is fine.
Thanks,
Eddie
Thanks for detailed article and solution (even making time to write (knowing how ‘challenged’ you are
).
Makes you wonder how secure plugins are… If you install them via the Codex, are they guaranteed safe? Do they scan/check those files?
I guess you’re on your own when downloading from the author’s site (either because of his mal-intent or his files might be compromised, unknowingly, as his host’s server-security is not be up to date, so they replace the download with tampered files).
It also calls for better security within WP or as a a plugin – either from Automattic or 3rd party. In that light, I feel the Security Scan would be a good starting point: it tells you which holes you need to plumb (even better would be the plug-in plumbing them for you).
My impression is, there are no structural security solutions yet – there are plug-ins, instructions to add/change stuff manually etc., but it is all scattered – not a one-fix-for-all.
I’m no programmer, but it would be great if some code-wizards would look into this…
Uh well… they must be reading your blog – and extremely fast coders, as Matt’s gang is working on this: http://vaultpress.com/signup/ – not free, though – but if you don’t make $30 a month on a few blogs combined, it might be time to look at ‘monetization’… Or just charge your clients $5/pm extra for peace of mind.
yak! Horrid! And security scanning would be great – but surely google notices?
Your explanation was thorough but as a newby website owner and blogger, it was over my head. I’ll have my son’s friend who built my site help me with this – THANKS!!
I was hit by this on my blog and couldn’t figure out a fix. Thanks – I’ll work on this over the weekend and hopefully I can send the Pharma Hack to the dark place it deserves…
Well…super heads up on that one. Glad you caught it and fixed it and I’ve made a note about it…just in case I get popular enough that someone tries to take ME down
Hey Chris, thanks for the helpful post — you led me in the right direction and I eventually cleaned out all of the offending files. But I wanted to offer a helpful tip that you didn’t mention. If you’re like me and have a bazillion Wordpress installations on a single domain (don’t ask, I didn’t do it), looking through them all for plugins with wonky file extensions is more than a little daunting. Instead, you can look in the active_plugins option in the wp_options table — that will tell you which plugins are being run, and if you’ve got the pharma hack, you can easily pick out the .bak.php, etc. files there and go right to them.
thanx
This is the first time I’ve come across such news of blogs being hacked. I will try the precautionary measures that you mentioned to make sure that everything is fine
Great security tip! I’ll definitely take preventive action to avoid this on my site!
Chris – great post – this helped a lot while troubleshooting some sites in the wake of similar attacks of late. Thanks!
Can someone please help? I have been hacked by this same thing, but I can’t find anything located in my Askimet files. Everything looks good there…Please any help is much appreciated.
Greg
sorry, my website is http://www.pixartalk.com so please take a look and let me know your thoughts.
Greg: read the post more carefully. The malicious code can be in ANY plugin. As I said, check the the active_plugins option in the wp_options table for clues — in my case, the hack appended the malicious code to this field’s value.
Aaron..I suck at this..I’ve looked through all the plugins and don’t see anything weird with middle extensions such as old, bak or cache…
I’m using the file manager (with hidden files option selected) with my host provide (bluehost.com). Is that sufficient to find these or do I need a proper ftp? If so, what do you recommend?
What if I just deleted all my plugins? would that remove it as well?
would love any additional help you can provide.
Greg,
We have a new beta of our plugin WP-MalWatch that we are testing right now that does file scans for patterns and will turn up anything in your install. Contact me directly and I’ll get you a drop of it. The current version in the WordPress.Org site does not do the file extension pattern scans. derick [[at]] orangecaster DOT com.
Derick
Hey Chris, thanks so much for putting together this detailed post. I’ve been struggling to find the root cause of this hack on my site for a couple of weeks. Looks like I may have finally killed it. Thanks again.
Great post Chris. It ALMOST makes all the hell we went through (mostly you) worth while…
Well from what I have researched it seems like they only infiltrated certain hosting companies.
I noticed some hackers put a small link on header of blog as well. This is horrible to fix sometime. I had such problem when i updated main wordpress software and not plugins.
I just noticed this hack also effects bing search results.
So I did the db cleanup, fixed permissions, reinstalled all wp files, changed every password, ran security plugins, installed versions of all plugins, added extra .htaccess files based on ip, yet the malicious db entries keep returning every few hours. Any idea why?
Everything else is locked down.
Evan, I can’t say with certainty why your db entries are returning, but one of two things is the case here:
I went through a similar experience, and it turned out that I just had to scour my files a little more closely to locate all the offending garbage
Were the problematic files wp files or outside?
I’ve found malicious files in the WordPress plugins folder and also in the root directory, which could technically be considered outside WP files.
Yeah, I saw a few bad files in the plugins folders and removed them. Most were hidden file, and came in pairs. However, I noticed other files being created that match the naming structure, but look like legit wp files (like the “safe” sample file you have above). These files start with db- or ext-, yet when the plugins panel within wp is loaded up, wordpress will throw an error. Usually saying these files have been deactivated due to bad headers. I can’t seem to find much documentation on these files on the web.
They all seem to be widget-related files of some sort.
The search continues…
I’ve been battling this hack for a week with no luck. It comes back. Today, I found this in the schema db:
FROM `information_schema`.`PROCESSLIST`
WHERE (
`ID` LIKE ‘%(edoced_46esab(lave%’
OR `USER` LIKE ‘%(edoced_46esab(lave%’
OR `HOST` LIKE ‘%(edoced_46esab(lave%’
OR `DB` LIKE ‘%(edoced_46esab(lave%’
OR `COMMAND` LIKE ‘%(edoced_46esab(lave%’
OR `TIME` LIKE ‘%(edoced_46esab(lave%’
OR `STATE` LIKE ‘%(edoced_46esab(lave%’
OR `INFO` LIKE ‘%(edoced_46esab(lave%’
)
LIMIT 0 , 30
Is this a backdoor to all of my DBs?
eyebeat, that certainly looks like a backdoor—the backwards
base64_decodestrings are clearly a hacker’s footprint, and the code in question does appear to allow them to access whatever part of the site and db they want.Out of curiosity, which host are you with? I have a schema database, too, but it doesn’t contain a
PROCESSLISTtable like the one shown in your sample code.I’m on dreamhost and I just found this hidden file in one of the plugin files:
.fckplugin.cache
Is this the rest of the backdoor???
I’m exhausted trying to fix this.
There’s a WYSIWYG text editor called FCKeditor.
Did you have that installed at one point?
I just did a db search for %(edoced_46esab(lave% as well and found an entry in the options table disguised as an rss/magpie entry.
So, can I delete those things in the process list? I contacted Dreamhost Support but I haven’t heard anything from them.
I would wait on a reply from them to be certain that you won’t mess up anything else by doing this, but I do expect that you’ll be deleting those db entries.
I have no idea if I had that installed. This file was in the wpg2 folder. I thought since it began with “.” that it was suspicious.
I’m an idiot and I’ll take all the pity and help I can get.
Dreamhost says what I found isn’t real that it was generated by my search request. Could that be right?
That sounds like hogwash to me. I think you should just delete those entries (but only the ones containing the backwards
base64_decodecode).Well, another part of the DH response was total hogwash. I didn’t share that. I responed to them by providing a detailed description of how I performed the search and what I saw at each point. We’ll see what they say next.
I did the search for this particular string after seeing a post about it on wordpress.org. In that post, they describe exactly what we have been seeing on our plugin management page. It made sense to search for it.
Following on this, I googled this type of hack and found youtube videos telling people how to do it.
I’m so glad I found this post. I was trying to figure if converting my website to Wordpress was worthy. Now I know that I don’t want to deal with such nightmares like the one you had. I rather have an old looking html site that is more secure. Thanks
Chris, do you know who I could hire to help me with this?
I followed the instructions and it’s still there.
Andrew, I’d be happy to have a look through your server and databases for free; if I can’t help you out personally, I’ll find someone you can pay to take your server through the wringer. I’ll shoot you an email about this.
Is there any reason “xmlrpc.php” should change after wordpress has been running for a while? If not, I think I just stumbled upon something.
Evan, I don’t know a whole lot about that protocol, but that definitely seems like strange behavior to me. If you’re able to dig any deeper into that, I’ll be curious to know what you find
Yeah, I can’t seem to get rid of this hack at all. Now I’m forced to block IPs from China and elsewhere in hopes that stops it. I did notice this though. When re-uploading wp core files, I noticed that file had a slight difference. On line 27, this got replaced:
$HTTP_RAW_POST_DATA = trim($HTTP_RAW_POST_DATA);
with this:
$HTTP_RAW_POST_DATA = mysql_escape_string(trim($HTTP_RAW_POST_DATA));
I’ve also noticed a lot of hits to my admin files from my log files from the same ip. The ip appears to be a googlebot, but when tracing it seems like someone trying to spoof it.
I’d be happy to email you an example if you’d like to take a closer look.
Evan, I blocked something like 180 different IP addresses while I was trying to remove the hack. Someone was pinging my server and running a trackback script that crippled this site’s performance, and this may have been how the perpetrator was getting in the door, too.
I’d definitely recommend you institute .htaccess-level IP blocking to help you solve this problem.
One great solution we found for a highly targeted blog was http://www.securelive.net ’s WordPress plugin which does real time detection of an extensive list of known attacks and shares the IP address amongst all users of the product.
Here’s the down side. First, if the attack comes from a shared address (e.g. a university) you will loose traffic and filtering degrades performance. If you have less than 100 concurrent users at any given time, this is a great solution. We have one blog that saw a 2200 concurrent user spike this weekend and we have to run an NGINX front end to handle the load. We also disable .htaccess and pull into the apache conf as htaccess is super inefficient under high loads. Thus, there is now way to scale and block known bad ipaddrs.
Performance and security is a fine balance and unfortunately sometimes you just have to run the risk.
Chris,
Have you heard about any cases where a new administrator account was added to the system, with the username ‘amin’?
Came across this post, and we noticed the same thing happen for a cluster of sites we have hosted on one specific server. Wasn’t sure if it was Pharma related or not.
I’ve seen some username weirdness in previous hacks (there was a big one in 2009 that involved rogue admin accounts), but I can’t say whether or not this kind of thing is related to the Pharma hack.
Well, it turns out that this was an issue with our host (The Rackspace Cloud), and that THOUSANDS of sites were affected in this mess.
We’re still waiting to get an official explanation and everything from them, but they have confirmed that the issue lies with them. Talk about a nightmare!
I’ve got some really odd symptoms on this one.
First of all, I can’t find ANY rogue files whatsoever, nor any unexplained database entries. But for a Google search using the SITE: parameter and some well-chosen drug names, this hack doesn’t apper to infect my site at all.
But here’s the weirdest part: I go into Google Webmater tools, and view my site as Googlebot… and nothing. No spam, no hacks, nada. And I’m hitting the same pages that a Google search tells me ARE infected. I THINK Google’s re-indexed these pages already, although I can’t be sure.
So what now?
Mike, I bet Google is showing you cached versions of those pages but not telling you that the page is actually cached. As long as your home page and sitelinks are not infected, I think you’re probably fine.
Mike,
I have seen this before. Here are a couple of things to do. First, go to http://www.submitexpress.com/analyzer and see what the various “bots” it simulate say. This will tell you whether it is simply Google’s cache or whether the hack is diverting crawlers only. If it comes up with your regular title, then you should be fine. If not, here are two things you can look at.
1) locale.php is a file used for languages and locales. I’ve seen where they drop in an encode64 (long ugly string) or simply spam links. Replace that file with an original from your version of wordpress or search through it and look for ugly stuff.
2) if you have SSH access, you can use the “cd” command to go into your worpdress install and use find /wp-content -name ‘*.*’ -exec grep -l ‘viagra’ {} \; (where viagra can be replaced with the spam words you are seeing). This will list the file. Another search would be – grep “base64_decode” *.php which will pull any files with encode 64’s in them. wp-app.php should be the only one pulled and it has two instances.
Let me know what you find.
p.s. – Chris, sorry for putting the word ‘viagra’ in your blog! LOL
Hi Derek, thanks for posting this. It helped me find the problem.
Three things to note – none of my infected files were in /wp-content, so this only worked for me when I searched for base64_decode in the root. Also, I’m a noob, so I didn’t realize that when I copied from the comments, I pulled the fancy quotes with it, breaking the ssh command. Changing all the single and double quotes to their plaintext versions worked perfectly.
And last, I also found instances of base64_decode in the class-simplepie and class-IXR, which seem legit.
Thought I’d note my changes since they seem to have helped and since others might run into similar problems.
Thanks again!
Nissa, I am glad to hear this. The attacks are nasty! Yes, stumbling around in a SSH is not the funnest thing even for those who used to play a UNIX admin on an 80’s sitcom (meaning, forgot more than I’ve learned in past 15 years).
The beauty of blogs and communities is that people share and with all of this info we all find our way. Let us know what else you find and I will take a look at the files you mention and see how we encorporate into future revs of malwatch.
Chris,
That’s what I’ve got my fingers crossed for – a lagging Google cache. I’m just trying to figure out if I’m infected or not, and it’s not easy.
Derick, Thanks for the link. I’m off to try that next. I’ve already grepped every file in my directory – including hidden files – and have found nothing so far.
The first thing you should do before cleaning up the db entries and rogue files is to start blocking bad IPs. Check your logs for IP addresses cloaking themselves as google bot. Trace the IPs and if they don’t come back google, block them.
I saw the same IP address come through and hit all of my domains at the same time. After blocking that IP, I was able to clean out the hack. I have been going back everyday and checking logs to make sure they don’t start using a new address.
Thanks for this post and thread. None of the solutions in the post itself helped me, but one of the comments really did.
One thing I wanted to point out about my situation that I haven’t noticed mentioned elsewhere was that since I was verifying Google Webmaster Tools with a meta tag in the header, my site became unverified. That was my first clue about what the problem was, and it’s also how I know that I’ve (hopefully) successfully fixed it.
I didn’t have any of the obvious hallmarks – no files with funny names, no markers in my database, nothing. However, when I SSH’d in to my root directory and used this command:
find . -name ‘*.*’ -exec grep -l ‘base64_decode’ {} \;
(make sure the single quotes aren’t fancy quotes if anyone tries to repeat my success)
I found a handful of files that included that phrase.
One was in root, and had a line of gibberish code (main.php). A line was in wp-load.php – with another line of encoded code. And a third was in a file in wp-includes called script-runner.php (easily confused for the existing script-loader.php) and it had a heck of a mess that appears to have been doing much of the heavy lifting.
There were a few other positives as well, but they seemed okay – I killed any plugins and extra themes that showed up, and replaced any WP files with clean originals.
So deleting main.php, script-runner.php and killing that line in wp-load.php seems to have fixed it. My site verifies again, which means Google is pulling the correct headers, which means hopefully the search results will correct soon. Fingers crossed.
Thanks a ton for your hard work, Chris, and to Derick Schaefer for posting the command that helped me find the source. Hopefully it’ll stay dead. Terrifying not to know how they got in in the first place, though. I’ve swapped the passwords I can swap.
this post just helped me today. damn that phrama hack! thanks chris!
Great Post! Just got rid of my mine!! Seems it was new variant of the pharma hack.. Gave up eventually and had to get the help of a coder that gladly did it for 25$ (best money spent in a while).
Here is a list of the files that were infected in my case:
* in the root was a malicious file called “core” with no extension.
* wp-blog-header.php was infected
* a lot in wp-content/plugins/translator
* as well as in wp-content/uploads/2008/03/thumbs.php
Regards,
Vincent
I got caught already twice with this garbage. Anyhow, I got this solved as soon as I started installing wordpress not with the default configuration. Just name the table – when installing wordpress – other than wp_ call it wp_342_xyz_ or so, this way they can not guess the tables. The second thing I do is to rename the user “admin”, helps too.
Glad you brought your website back. The tips are awesome.
My site’s been infected for a little while now, but unfortunately none of the tips mentioned here have helped. However, I did find some suspicious-looking entries in my database:
None of the searches suggested by Chris yielded any results, but those files do look kind of suspicious. I don’t want to go deleting entries in my MySQL database without knowing what I’m doing, though.
Thank you SO much for this post, it’s been a huge help! I’m trying to fix 2 wordpress blogs that have been hit. I went through one and found a bunch of the files listed here and deleted them. I then went to the submitexpress.com/analyzer that Derick above recommended and it’s coming back clean, where as the 2nd blog I haven’t touched yet still shows all the drug names and titles. So therefore I’m hopeful I’ve found the problem.
Searching on Google still shows the hacked results….typically how long does it take Google to re-cache results so I will know? Anything I can do to speed up the process?
Rhonda, that is great to hear. In my experience with this, a) you will not loose anything with the search engines or be penalized and b) it will take Google anywhere from 5 to 20 days to recrawl this. How can we help get Google’s attention? Twitter is a good start. Tweet out a “I got my blog back”. Keep it short and put the long link to your URL. include @orangecast in the Tweet and we’ll re-tweet from a few accounts to get as many of those search engine crawlers on it as we can. No guarantees but that will definitely get bots on your site.
Wow, Derick, thanks for the super speedy response! I’ll begin the anxious waiting game.
Chris, with the advent of Wordpress 3.0, will it be vulnerable to this attack or have they added new security precautions? Do we need to modify new installations (table prefixes etc) to help prevent this? Thank you so much for your help here. This thing has been a nightmare.
I just had to drop you a message to say thanks! I’ve spent the entire day trying to figure out what had happened to my site and this fix (at 2am) finally nailed it.
THANK YOU VERY MUCH!
Good luck you found out so early. I had a site totally smashed with injected code so every time someone visited, they where getting malware on there computers and coz I was away on holiday for a month, when I came back home, my site was delisted in both google, bing and yahoo. Took me quite while getting it back up running and wrote to google for please include my site again. But good luck today is no worry and I learnt the hard way. Never leave your site unattended for a month, no matter what rock you might stay under, it can suffer your buisness bigtime
Thank you SO much for your clear and concise directions. I have spent the last day and a half trying to clear this up.
Wow. Thank-you again.
I should also mention that my particular crank file was called ext-akismet.php …
thanks, this is of great help.
beware malicious hacks can appear with *any* plugin!!
So I’m back.
After following the instructions above I was able to clean the two hacked WP blogs I was trying to fix. However, they both got hacked again within just a few days; but WP 3.0 had been released the day I ‘fixed’ them, so they had been fixed on the old version of WP. I had also installed a few new plugins (a backup and a security plugin) and (stupidly) forgot to tighten down permissions.
So I run through the steps again, upgrade to WP 3.0, delete hacked files and make sure all plugin permissions are tightened. Running them through the metatag analyzer comes back clean. After a few days the Google search results are really clearing up; things look great, I think I’ve solved it.
A full week goes by and just for kicks I check the sites on the analyzer again, and one of the sites had been hacked again. I think I caught it early b/c the search results were still appearing normal. This time ironically enough it was the WP Security-Scan plugin I installed that got hacked. I’m really confused how, since it had the recommended 755 permissions, as did the entire plugins folder . The only thing I can think of is that that plugin hadn’t been tested/upgraded to work with WP 3.0.
I was able to again run through the steps, find and delete the files (I ended up deleting the security plugin, just in case of the version compatibility), and again things appear normal. Question is, have my fixes only been temporary b/c of the new WP version and incompatible plugins, or could there more malicious code hidden that is causing this to keep happening, in spaced out intervals? I’d really prefer to not to have to run this fix every week.
Nobody still has any idea how this happens in the first place?
Rhonda,
I am sorry to hear you are having so many problems. I have seen this before. Generally, the scenario such as yours is the result of the hacker getting in at the hosting level and if the hosting is shared it might not be on your vhost but they find their way in there. Not to belabor on this comment but we have a bunch of research we did and definitive proof that when you keep on getting hacked, hosting is the issue. We also switched up hosting and have a great solution working right now. Unfortunately, it is built on MT’s VE server which requires UNIX skills to make work.
Talk to your hosting company and/or consider shifting things up there.
Wow, once again thank you Derick for such a quick response! Well I guess it would make sense that there is a hosting issue. These aren’t my sites, but I know the owner has had some issues in the past with Media Temple (current host). We’d talked about trying out a new company but I wanted to see if I could fix things before having to switch everything over to a new place. Looks like it might be the next logical step. Thanks again!
I’m on MT GS and the only way I got the hacks to stop was to block bad IPs seen in the server logs. Only after that, I was able to clean out the hacks and stop them for good. Look for IPs trying to spoof googlebot.
Grrr….got hacked AGAIN. Good news is I can ‘fix’ it very quickly now, but I don’t want to have to babysit this so much.
Any tips on how to spot and block bad IPs? I’ve never done anything like that or with service logs, but am very good at following directions.
Ironically, the grid service was one of the ones we found problematic. I really like MT and think the world of their VE offering but the general population grid was flagged on several fronts from our security analysis.
We’ve had zero issues from a security perspective and hit a high watermark of 2,600 concurrent users on their $100 a month offering. The $30 offering is good for 500 concurrent users which is plenty for most blogs. As I said, after over 3,000 different vulnerabilities where scanned for, we came back with 1 low priority issue that we knowingly introduced for performance.
If I can be of any help on the config, reach out to me on Twitter @orangecast
We would be very interested to find out a little more about your security analysis of our (gs) Grid-Service. Would you be open to sharing your testing proceedures and results with us? Obviously we don’t want to expose any of our customers to security breaches and we take every step necessary to close up any security holes in our system. If you’re finding something that we are not, this is something that we would be very interested in working to fix. Please reach out: travis at mediatemple dot net. I look forward to hearing from you.
Travis,
Sorry for not responding to this. I literally didn’t see it. I can connect you with the company that did the scans for us. They know their stuff and it is very affordable. Contact Mike Robinson in your own company as he has my contact info and can put you in touch with me.
I do want to re-emphasize your statement that you guys are committed to customer service and wouldn’t knowingly leave an issue out there. I’m definitely an MT fan!!!
I’m on MediaTemple GS and I found some of the malicious database files (and deleted them), but I’m not seeing any weird stuff in the plugins folders. I also checked my “uploads” folder for .giff and .pngg files as suggested by a 3rd party Wordpress tech help outfit. Any advice on where this other nasty stuff is hiding?
Thank you, Chris and to everyone who is trying to help.
I discovered the problem on a blog to – and I found it in various plugin folders – even in plugins subfolders, like a /js folder that should only have contained .js files.
Sociable was actually one of the too…
But I can’t seem to be able to clean out everything in the database. I deleted everything inside the /plugin folder, and started cleaning the database. I get a lot of rows like these:
I clean them out, but they keep regenerate it self and keep coming back.. Are they generated from something else than the malicious file in /plugin folder ? Anyone had the same problem ?
One of our WP3.0 blog was getting hacked again and again inspite we reinstalled with version3.0
Today i found the hackers code in option# wp_check_hash and # class_generic_support in database like you stated in your post.
I have deleted them and hope that our blog won’t get hacked again
BTW these hackers are getting smarter day by day.
One of our WP3.0 blog was getting hacked again and again inspite we reinstalled with version3.0
Today i found the hackers code in option# wp_check_hash and # class_generic_support in database like you stated in your post.
I have deleted them and hope that our blog won’t get hacked again
BTW these hackers are getting smarter day by day.
How are they getting into the database, do they have access to your server?
We just released WP-MalWatch 2.1.2 this morning. This includes a keyword scan for header, footer, and index.php files as well as a scan for general “monkey business” in the locale.php. If you configure the keywords for words like “cheap software” and “viagra” it will scan every night at 4AM and if they drop these in there, you’ll get a notice in the WP Dashboard and can go get them out.
Our next release will come crawl your blog like SubmitExpress and give you that info in your Dashboard so you don’t have to go visit that site. Probably a month out on that one…life is busy.
This pharma hack is very common nowadays and in addition to the tips provided, you should also look at other places for these spamming keywords.
-general-templates.php
-footer.php inside your themes.
-Inside any plugins, they are now “patching” valid files.
Also, as far as detection goes, we offer a web-site monitoring solution that detects those spams (along with malware, etc) and alert and fixes for you if your site gets hacked.
This was SO helpful! I got one of my sites hacked and another site only mentioned the SQL command looking for rss_% but not the other commands or anything about the hidden files.
You’ve just earned yourself a return visitor in me
I had a very similar problem to the one you described, and I didn’t find any suspicious files but did have a swath of malicious MySQL entries. Thanks very much for this post. I removed everything, and used Cloaking Detector to establish that google is now seeing the correct info.
I have been getting a few reports, though, from users who say visiting the site has been and is still activating their virus protection; Google hasn’t unlisted us, and at least on my Mac, nothing virusy or otherwise abnormal happens when I visit the site (link in my name). It definitely corresponds timing-wise with the Pharma hack, but even though the google results are now fixed this still seems to be happening for some people.
Any idea what this could be? I’m a complete novice at internet security and have been doing my best to bone up. But it’s very demoralizing; I was so relieved to have finally solved the google problem, and now more e-mails that we’re triggering virus scans and trojan warnings. I feel overwhelmed!
Silly question, but once I’m gone through all the steps – do I need to do anything to the posts for google to re-index them properly?
I’m guessing if I’ve successfully removed the hack, the slugs/urls of the posts will return to normal?
Thanks for all the help by the way.
Hi Rich,
No, you don’t need to do anything except be patient to have google re-index your site. In my experience in dealing with this, the more traffic you have to your site, the faster the search results will clean up. If you haven’t, I’d recommend going to the meta-tag analyzer to make sure your site is clean and the correct information is being displayed. Then just wait for results to show on google.
Thanks for the tutorial. Im constantly being attacked by the same guy over and over. Ive secure the .htaccess file and now i’ll keep this tutorial for a just in case, thanks chris
Thanks for the post – just finished cleaning up a site of the same problem. Looks like the hack has changed somewhat. Here’s some notes:
- The hacked plugin was feedburner_feedsmith_plugin_2.3
- The extra file added was “ext-feedburner_feedsmith_plugin_23.php”. Note the extension “ext”
Finding the hacked file was rather difficult.
The first challenge was reproducing the hack so I could confirm that it was fixed. I tried changing my user agent (in Safari, via Developer tools) but that didn’t work. The best way I found was to use the “Fetch as Googlebot” Google Webmaster Tools. Using this tool I could enter a URL that I knew was hacked and it would fetch it as the google bot. I could then confirm that it had the spam inserted so I could be sure that whatever fixed the problem actually fixed it.
I then disabled all the plugins to try re-enabling them one by one to find out the hacked plugin. This didn’t actually do anything. In order to determine the hacked plugin, I moved all of them out of the plugins folder, confirmed via Google Webmaster tools that the problem went away, and then I started adding plugins back in one by one until I found the one causing the problem. I then redownloaded the plugin, and everything is back up and running again.
F***ing spammers!
Well, that solves the hacking problem, and that’s why you should build your own blogging platform, if you have the expertise!
I am really thinking of making some tutorials on this!
Wow, I didn’t realize this was a global attack. I had my site hacked back in the beginning of May, and quickly fixed things. And my webhost had no information to offer on the matter. Shows how “in-the-know” they are. Interesting thing I should note – my blog is setup as a sub-domain of my main website address, and yet somehow the hacker injected the pharma crap search results into my main website address (but nothing actually resided in the folder it was showing in search results). I ended up having to do a removal of about 500 URL’s from Google Webmasters tools. Keep your sites secure people!
We’ve struggled with this mightily a number of times this year. Thank you so much for the post. One question, though. A number of people describe how the hacked files are named. But what do the files actually look like inside?
Benjamin, I hate to say this but it really depends. I’ve seen anything from encode64 contents that do nasty things to flat out PHP instructions. One thing you generally see in the code is some sort of redirect, placement of links, or title tag changes. They usually looking to clip page rank or traffic for their online marketing efforts.
If you have been constantly struggling with this, you likely have a hosting problem. We’ve just finished backing out a vps build of Ubuntu that passes a scan test of over 3,000 vulnerabilities. On the server we got hacked on repeatedly, we had over 250 “vulnerability issues”. Once we got away from it, the world got better.
Thank you, Derick. I wouldn’t call it a constant struggle, but it sure feels like it today (and yesterday)! We’re still cleaning up this one, but looking at my database backups today as well as seeing your comment about servers has me wondering something. Do you think my SQL backups of the database which are stored on the server might be a great place for the bad guys to store executable code? Do you think I should store the backups elsewhere, or is this the paranoia that’s setting in?
I don’t know that they’d be tinkering in the backups but you want to backup up that entire WP install to somewhere with some 9’s of reliability. Amazon S3 is dirt cheap and with this nifty plugin it will take everything from plugins to themes and uploads plus the database and keep it safe. At .15 per GB per month, daily or weekly backups are a no brainer.
http://www.webdesigncompany.net/automatic-wordpress-backup/
One thing you can do is open the DB backup file and make a scan through it to see if they have messed it up. It is a text file so you can go through and remove things and then restore.
Here’s another link I ran across describing an instance of the pharma hack on Expression Engine. Worth reading.
I have one of the hacks for the second time. I found it easily the first time, but can’t find the bad code this time. Any help of a code that can help would be appreciated.
I think I found the entry point of the bastard. Before you start the cleanup you need to identify how the system got infected. After much struggle, I think I have found something very strange (see below). I will report my further findings.
http://maffulli.net/2010/08/06/getting-busy-on-the-blog-for-the-wrong-reasons/
Hey Chris,
Thanks for the well-written post on the pharma hack. I had several blogs that were rocked by this cleverly disguised malware. I’m still working through some of the repercussions 3 days later.
Better yet, I already had the security tips you referenced in place, with the exception of the .htaccess file and I still suffered loss.
My advice for Wordpress users is to download Wordpress File Monitor. It tells you when any of your files (like Javacript files) are modified.
Josh
Thanks for this tutorial, it save my butt on another site.
Great post! Very informational for WordPress users like me, luckily i haven’t encountered “this” yet. The part about sneaking into your site to enjoy a hitch in highest-ranking page really gives me the creeps. Well thanks for this and I’ve got a counter measures.
Thanks A LOT!
You will not be surprised I fi said that I had one of my sites hacked in a similar way. I found arabic characters or something similar at the footer of one of my websites. After extensive analysis, I figured out that one of the plugins that I used was hacked and it kept adding the text to the footer inspite of me deleting it many times.