Home > IT Perspectives > WordPress Malware Cleanup on isle Kamagra

WordPress Malware Cleanup on isle Kamagra

February 21st, 2010 Leave a comment Go to comments

I managed to loose half of my day yesterday, thanks to a malware infection on the One Lap blog.  It was more like an irritating rash really, but one that scarred our front page with a link to some off branded male enhancement drug.  I wish you could just buy the little blue pills like Advil, as it would eliminate 90% of SPAM, malware and exploits on the Internet.  It almost pains me to put the name of the site in this post, as I know they win by propagating their name once again.

After backing everything up and changing all of the account logins, I had the not-so pleasant task of finding the infection. Following the path of most repair work, I started with Google.  I also found a lot of dead ends and blanket fixes.

I figured I would dump some of the more useful links I could find up here, to help the next soul looking to get rid of the annoying link on the top of their website for kamagra.  Most of the first searches out there, have you hacking away at unknown base64 files, eventually resulting in a complete lobotomy of your site functionality before it is rebuilt with new files.

Run through some best practices first and reset your account passwords for the site, including your FTP accounts.  Realistically the attacker used an SQL injection, allowing them to write straight to the database.  These holes are common during the flexible days before the patches are released.  If you were lucky, the only thing that was added was an annoying link.  So far, that is the only thing I have found.

The code was found in the WP_OPTIONS table in the database, which is where the plugins and other toys get to write to for WordPress. Search through the table for some key words and you will find the inputted entry.  Delete the entire entry and the text goes away. It sounds much easier, now that I know where to look.

Here is the discussion again, between a site owner who knows more than the people offering advice. http://wordpress.org/support/topic/304847

There were a couple useful tools to help parse through this crap.  The Exploit Scanner Plugin, helped draw out some of the code that didn’t look right.  Use with caution and don’t just delete everything it says.


That helped me pull out the code that was not supposed to be there, allowing me to find the first post of where it was hiding. Their example didn’t have the little pill as the problem, so I didn’t see it initially as I was searching for our miracle drug.

var _0xd22c=[“function seeThat(elem) { eval(x22elem.x22+stl+x22.display=x27blockx27;x22); }”];
_0xd22c[0x0] = _0xd22c[0x0].replace(/block/i,”none”);
2c[0x0] = _0xd22c[0x0].replace(/block/i,”none”);
var str = ‘seeThat(document.getElementById(“link”));’;
r = ‘seeThat(document.getElementById(“link”));’;

Here is the output of the plugin, which the most useful piece of information was the credit_text2 information.  That is the name of the field in the database.
Most hosting sites come with a database admin tool like  mySQLAdmin, or something similar.  If  you don’t know what  you are doing in the database from a shell, then resort to clicking on the icons and digging through it there.
Good luck.

The Morning After

Having a small celebration after getting the malware off of your WordPress site, only to find the next morning the code is right back on the top of your site?  Well we only removed the entry in the database on the first round. Now we need to get rid of the code setup to run to put it back in place on a scheduled basis.

Now we need to dig into where this is being initiated from.  If you search through your files for credit_text2, you won’t find anything.  That is because they have encoded the text itself inside of a function file you don’t actually need.

Inside of the header.php file, there was a call to a start_template() function, directly after the body.  If you open up the

start_template.php file, you find a pile of encoded garbled junk.

Take the meat of that junk, and use one of the freely available Base 64 Decoders online to decode the file.


In this particular case, the code was coded twice.  So take the output of the first round of decoding, and run it through the decoder again.

That presents us with the following code. If you notice the time reference, you now see why this annoyance comes back around.

Now our second round of cleanup to see if we can last 24 hours without getting a return of the exploit.

  • Delete the function call out of the header.php & remove the call to the require_once line that names the license file.  There are valid calls to these files in my theme, which tells me the entire theme may have been exploited.
  • If you delete the start_template.php file and it breaks the site, it is probably being called as required once some place else.  Start by removing everything from the file, or leaving only the PHP call in the file.
Categories: IT Perspectives Tags: