A few days ago Jindrich Kubec (Avast) pinged me that the RunForestRun malware changed the domain generating algorithm (DGA) and now uses waw.pl subdomains (instead of .ru) in malicious URLs.

I decided to take a look at the new scripts and found quite a few very interesting changes. This post will be about those changes.

RunForestRun recap

Just a quick recap of the RunForestRun attack: It began in mid-June and infected many servers with Plesk Panel since then. Hackers used Plesk’s File Manager to inject malicious code (mainly) at the bottom of .js files. That malicious code used a Black Hole obfuscator and was always surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments, which made it very easy to clean up whole servers using just a single regexp.

Another interesting feature of the original RunForestRun attack was the domain name generating algorithm built into its malicious scripts. It generated two new unreadable .ru domains every day and used them for iframe injection. Although the algorithm called itself “pseudo-random“, it actually lacked any randomness at all, thus all the domain names it could ever generate (today, tomorrow, next month, in a hundred years, etc.) were easily predicted.

New version of RunForestRun scripts

However everything changes and now we can see a significantly improved version of the RunForestRun attack – they definitely learn from they own mistakes.

Infected and encrypted .js files

As previously, the attack targets .js files on Plesk-pоwered servers. However, instead of appending legitimate files with an easily identifiable line of the malicious code, this time they replace the whole content of the legitimate .js files.

As you can see, the comment signature is gone and the legitimate code is no longer there. Moreover, the code is different in every infected .js file even on the same site. This means that server admins:

can’t easily identify infected files — there’s no signature

can’t use a simple regexp to find and remove the malicious code from all infected files — the code is varies from file to file and the only common part is the packer code used by many legitimate .js libraries, e.g. jQuery)

Site-dependent JS encryption

It contains two long encrypted strings. The code decrypts and executes them. Apparently the first string is the encrypted legitimate content of the infected .js file (that’s why even with replaced content of .js files hacked websites still work) and the second string is the encrypted copy of the malicious code.

To make things more interesting, both strings are encrypted using the domain name of the hacked site as an encryption key. This means that if you only have a copy of the malicious code but don’t know the domain name of the site it was found on, then you won’t be able to (easily) decode it.

That also answers why every infected .js file has different malicious code in it. The final code depends on the combination of two factors: site domain name and content of the .js file — apparently this combination is unique (unless someone has two identical .js files on the same site — why?)

By the way, the encryption code is still buggy as I saw sites where the legitimate code won’t decrypt.

Updated domain generating algorithm

Now let’s take a look at the decoded malicious part of the script (full version here). It’s basically the same code that generates domain names and injects iframes as we saw in the original RunForestRun attack. However there are a few significant changes:

1. At the very top of the code we can see the following two comment lines:

//Congratulations! you have successfully extracted the gootkit payload
//this means i must work hardly :(

The malware author left a message to us. Apparently he has sense of humor and desire to improve the script obfuscation techniques. Well, this new version is much more interesting to decode. I liked the “domain name as an encryption key” trick, I didn’t see it before. Nonetheless for tools that use JavaScript engines and can decode all script directly on infected sites the same way that web browsers do, this new layer of obfuscation is hardly noticeable.

2. Instead of .ru domains, this new algorithm generates subdomains on waw.pl. This version also uses the botnet_api sid parameter.

Still easily predictable

So how the attackers know what domains to registers so that the injected iframes really load some malicious payload from their servers? The answer is the generated domain names are not completely random. As you might notice, they actually consist of two parts: the third-level domain name and the forth-level domain name (e.g. nzseokfggewrwplmuph.hvguqfmfqgerbdro .waw .pl). The forth-level domain name (in this example nzseokfggewrwplmuph) is really random and can’t be predicted. But the third-level domain name (in this example hvguqfmfqgerbdro) is not random at all and thus can be as easily predicted the same way as domain names in the previous versions of RunForestRun DGA.

This “predictable third-level domain name plus any random fourth-level domain name” scheme works because of the DNS settings that map all forth-level domains to the same server as the third-level domain name. By the way, right now this attack uses the 78 .46 .11 .101 server (Hetzner Online Ag, Germany).

This scheme allows us to predict the third-level domains only and ignore any forth-level domains. For this algorithm, the significant domain names change 5 times a day. At this point I can see that domain names for the period of July 21, 2012 through August 5, 2012 are already registered via the Domain Silver Inc. (registered in the Seychelles, with the .pl support email) And by the way, waw.pl subdomains are not free to register — this adds some barrier to preregistering the predicted domain names.

Here is a list of the domains that are already registered. A more long list of the predicted domains can be found here (I know, they’ll eventually change the algo.)

Roundup

This new version of the RunForestRun attack:

Still infects sites on Plesk-powered servers

Instead of simply adding easily detectable and removable line of code into legitimate .js files it now encrypts whole .js files adding some malicious extra to them, which makes it troublesome to automatically find infected files and clean them up. If you don’t have a backup, recovering legitimate .js files will be a problem too.

Encrypted code is unique in every infected .js file. The domain name of the hacked site is used as an encryption key.

The DGA now generates really random domain names, but the random part can be easily ignored. And the really significant part of the domain names is still easily predictable.

Unlike most of the rest massive website infections where hackers use more or less the same tricks for quite a long time (exploitation kits unify a lot of stuff), the RunForestRun guys are trying to invent something new. And although their solutions are not always efficient, I can see how they learn on their own mistakes and improve their code with every iteration. I wish they worked on something more constructive though.

To Webmasters

Make sure you have a backup of your site. You have a backup, don’t you? You’ll need it to recover your .js files.

Make sure there in nothing suspicious is added to your site.

Important: Change all site passwords: FTP, Control Panel, etc. Don’t revert your old passwords if you hosting provider resets them.

Very important: Contact you hosting provider and show them this article and the article about the original RunForestRun attack. The attack uses server level security issues of the Plesk Panel and only your hosting provider can really stop reinfections.

Questions to readers

Can you confirm that this new waw.pl malicious code only affects .js files? If you see it in other types of files, does it encrypt legitimate content there too?

To encrypt legitimate files, the attackers need to download them first. Do you see those download requests in access or Plesk logs? Just curious. Do they use multiple IPs for such requests?

Did you come across websites infected with this version of the malicious code on servers that applied all the Plesk security patches and changed all passwords before July 20, 2012?

Reader's Comments (8)

this damn virus on my website. I can not find and codes. I wonder could you help on where can I find?this damn virus on my website. I can not find and codes. I wonder could you help on where can I find?

I’ve been tracking this (SutraTDS) from a network forensics perspective for almost a month. What I’m seeing is that it only infects .js files…and it infects all of them. The last site I was checking out was throwing the bundled malicious JS files for everything on the server. I copied the text from the packets for 3 different samples, and they all generate the same deobfuscated code. I ran in to one site last night where I didn’t notice that it was a Plesk site.
I’m curious as to why they haven’t moved the exploit site IP. It’s blocked in our network. I’m waiting for them to change it. The latest URL is hxxp://king-profit[dot]ru/in.cgi?7. DNS A record points to 178.168.7.68. If the pattern changes, I’ll post back. This is supposed to be BHEK related, but I haven’t found a machine in our network that has been infected yet.

I think the JS they are using is pretty creative, but once you see the pattern, it is easy to spot. From a web server perspective, I’m sure it can be annoying. It appears that once the valid website is compromised, it is being cleaned rather quickly. From an intrusion detection perspective, it’s easy to track…it all depends on what IPs they are using.