This question already has an answer here:

I am running Plesk 9.5 on Ubuntu 8.04 LTS and have about 15 websites infected with some malicious code appended to the end of java files. I have installed Clamav and it has managed to pickup the infected files which have a pattern of starting with either /*km0ae9gr6m*/ or /*gootkitstart*/ and ending with /*qhk6sa6g1c*/ or /*gootkitend*/

My Plesk panel is up to date and security patches were installed. How can I isolate the security vulnerability on the server?

marked as duplicate by HopelessN00b Jan 14 '15 at 6:55

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I am still experiencing the issue with reinfections still occurring even after password changes. Here is a good command to pick up infected files #find /var/www/vhosts/ -exec grep -q "km0ae9gr6m" '{}' \; -print With all patches installed I am going to do a mass password change for every account on the servers both FTP and Plesk control panel access. – Paddington Jul 13 '12 at 6:55

First, if there's a rootkit, you're probably fighting a neverending fight. Take the server offline and reinstall and restore backups that are pre-infection. That's the "best" method of fixing.

Second, were you up to date on patches and such before the infection or did you patch after?

Third, what custom code is running on the server outside Plesk? How do you know that was even the infection vector?

Without auditing and sandboxing, you're going to have a hard time telling what happened. If there's a database running on it, someone could have faulty code on the system. If someone else has access to the server, maybe they did something to infect it. Are the websites running with different file permissions to silo possible damage? Or are the sites pretty much sharing all the resources? Are other users involved and able to run scripts? Do they have different widgets and whatnots installed? Were the files timestamped, so you could go back into the logs to try to glean what happened?

If the logs are on the same server that was compromised, the logs could have been altered as well.

In the end, the best thing to do is take the server offline and fix it by reinstalling from backups. Otherwise you can't fully trust it. And if you have any "personal" data (user passwords?) they need to be informed that their information may have been stolen. Then start setting up some kind of auditing on the system, and send logfiles to a secondary server over a safe channel of communication so logs can't be erased by an intruder. And run some kind of file checking utility like Stealth on another server to monitor your file integrity and warn you of changes.

Without knowing what else your server runs, there's little other people can do to tell you how it was compromised.


There is no generic approach - it's all hands-on. You typically would need to have configured extensive logging, preferably not only from the system you are inspecting but also from an independent IDS, which you are periodically archiving. Also, a good bunch of experience with computer security and forensics is required, otherwise you don't stand a chance.

But as Malware today typically is doing mass-infections, chances are good that the work has already be done for you:


Obviously, attackers do not infect hundreds of web pages by hand, they use a script or a botnet to do the work for them. [...] One other such bot is known as GootKit. [...] We are unsure exactly how the control server obtained all of the FTP credentials, but most often these are stolen via keyloggers and information stealing malware installed on a website administrators PC.


We have seen this on plesk 9.5 servers despite having Parallel's security patches installed from February.

Basically they are POSTing to the login page and getting in without auth, then going straight for the WYSIWYG file manager and appending the code to js files. Plesk are refusing to acknowledge this and the only option is to firewall plesk off and allow to specific IPs.

You will find the POSTs in the httpsd_access log in plesks admin/log directory.

A global sed will remove the code as fortunately they all start with the same string.

  • Hi can you please help me with a typical sed script than I can run. I will then customise it for the environment. – Paddington Jun 29 '12 at 8:44
  • find /path/to/your/dirs | grep "\.js" | xargs sed -i 's/\/*km0ae9gr6m.*$//g' will delete everything after the km0ae9gr6m string (it's usually appended). use -e rather than -i to test. – Alan Ogden Jul 2 '12 at 9:00
  • The code is now appearing in the middle of some files. How can I modify the SED script to delete data between and including the start of the malicious code /*km0ae9gr6m*/ and the end of the code /*qhk6sa6g1c*/ – Paddington Jul 18 '12 at 9:09

This sounds like your passwords have been leaked out some time ago and now are being used to install trojan dropper scripts. See following this and this for more detail.


After a couple of horror weeks loosing clients and being re-infected we received this reply from technical support at Parallels:

Please note that all of the vulnerability issues reported over the Internet or our forums actually trace back to an old vulnerability in Plesk, which is fully described in the following KB article:


Article #114379 also mentions this information. Please thoroughly check article #113321 and the related articles in order to verify the issue's presence, install all the necessary microupdates and ensure that the server is protected via mass password reset:

http://kb.parallels.com/en/113424 http://kb.parallels.com/en/9294 http://kb.parallels.com/en/113391

What's rather interesting though with reference to the first statement is that on the 15th of July Parallels brought another "security" patch.


I manage a Plesk 9.5.4 server which was infected with the /km0ae9gr6m/ malware. FYI - on my server, the malicious code was added to Javascript, PHP, and HTML/HTM files. I'm posting to let the community know that I was using Plesk's IP address restriction feature at the time of the infection. To be clear - within the Plesk control panel, I had denied Plesk login access to all but two IP addresses (my own studio, and the office IP address of one of my clients). Despite this restriction, log files show logins for the admin user from IP addresses that should not have been allowed by the Plesk firewall. I have since implemented identical address restrictions on port 8443 with IP tables, and to date (approximately 48 hours) have had no further issues. Based on my experience, I say do not trust your security to Plesk's IP address restrictions. If anyone is interested, I would be happy to share my log files.

If you need to get a list of affected files, and have SSH access, you can use the following: grep -rl km0ae9gr6m /var/www/vhosts/

This will pull a list of all files in your vhosts directory containing the malware signature. I found it easiest to edit the affected files with Plesk file manager. In my case, all malicious code was appended to the bottom of the infected files.

Hopefully more info will come to light on how this attack was able to circumvent both the Plesk login and IP address restrictions.

  • I am still experiencing the issue with reinfections still occurring even after password changes. Here is a good command to pick up infected files #find /var/www/vhosts/ -exec grep -q "km0ae9gr6m" '{}' \; -print With all patches installed I am going to do a mass password change for every account on the servers both FTP and Plesk control panel access. – Paddington Jul 13 '12 at 6:54
  • @Paddington see the coment on Eugene's answer. – styu Jul 27 '12 at 0:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.