11

So, I clicked on a reasonably-looking LinkedIn invite, not thinking about hovering overing the link first, since usually the e-mail client warns me about such things.

Once I realized I landed on an exploit page, I quickly copied the source (containing some obviously guilty JavaScript), closed the window, and deobfuscated the attack code proper (homebrew-encoded wrapped in an eval).

EDIT: here's the pastebin of the deobfuscated code, followed by the actual HTML attack page.

Fortunately, it looks like the payload wasn't deployed in my case - the attack targets PDF and Java browser plugins, of which I had none (I do have Java installed sans plugin, but the version looks to be too recent for the attack anyway).

However, as I'm no JS expert (and much less a JS exploit expert by inference), I tried to search for the attack code to make sure I'm not affected. No results so far.

Of course, this makes sense - public-viewable code like that would attract skiddies and anyone else wishing to use it for malicious purposes.

Nevertheless, given the JavaScript attack code, how can I find information about the exploit?

mikołak
  • 163
  • 1
  • 11

4 Answers4

10

This looks like a pretty good example of this malware being reversed (and a step-by-step how-to) by someone else. I just searched the following on google.

Basically it looks like you got attacked with the some new variant of the infamous blackhole exploit kit.

If you do a search throughout the pastebin that you linked for 'java' 'flash' and 'pdf' you'll see references throughout which essentially translate to 'download and open this' in the hope that one of the many exploits present in the kit will work. The first link I've posted shows a good break down of this is done.

If no analysis had been done by the above authors however, i'd suggest going the route that Michael suggested and loading up a VM image. That being said, it still has its own risks. I'd recommend, if you want to do this on a regular basis, having an old laptop or desktop machine dedicated to doing this kind of investigation. This question might also help you in future.

Community
  • 1
NULLZ
  • 11,446
  • 18
  • 80
  • 111
  • Heh, Blackhole turned up in a number of searches, but without a connection to code. Oddly enough, it never occurred to me to search for the metadata as you did. – mikołak Sep 12 '13 at 21:39
  • 1
    @TheTerribleSwiftTomato glad it helped, sometimes all you need is an extra set of eyes looking things over :) – NULLZ Sep 13 '13 at 06:40
5

Apart from the using the VM, if you think the javascript itself is malicious, you could use tools like jsunpack for analyzing your code. Also, if you capture the packets using Wireshark and recreate the scenario, you could extract the payload/malicious binary, upload it to VirusTotal, Anubis and/or Malwr for further analysis. (Quick note: Malwr also gives you the result from the cuckoo sandbox by running the binary on VM)

TheRookierLearner
  • 4,242
  • 8
  • 25
  • 28
3

If searching doesn't reveal anything useful, one standard option is to try it.

Run up a VM with relatively old versions of Adobe and Java plugins (if you suspect it is targeting PDF and/or Java), take a snapshot of the VM before you visit the infected site, log all the traffic going in/out the VM as you visit the site (and shortly thereafter).

Inspect the traffic using e.g. Wireshark and compare the contents of the filesystem before and after visiting (you might find some useful resources at http://www.honeynet.org/).

Michael
  • 2,118
  • 17
  • 26
  • That's what I've been thinking about as well. Are there any recommended Linux VM images made for this purpose? – mikołak Sep 10 '13 at 17:00
  • Added a couple of links, but I'm not an expert. – Michael Sep 10 '13 at 18:00
  • They're still a help, thanks. I'll hold up a bit before accepting the answer 'though. – mikołak Sep 10 '13 at 20:32
  • Also, try using the VM with Cuckoo (http://www.cuckoosandbox.org/) which helps to get the file system changes and other useful info. – TheRookierLearner Sep 10 '13 at 20:40
  • This exploit pack (BHEK) might not actually execute as you'd *like* in a non-windows VM as it does extensive testing of browser, plugin (and from what i can gather OS) variables to ensure that exploits will run on the target system. I believe **most** exploits are targeted towards windows so if it detects linux i'd expect it to not work. – NULLZ Sep 12 '13 at 03:35
2

The JS that you posted is basically the first stage of deploying an attack to a victim. It is enumerating on what all you have installed through javascript.

One such check is

  if ((c.isIE && (c.verIE < 9 || !c.ActiveXEnabled))
                                                || (c.verGecko && 0 > c.compareNums(c.verGecko, c
                                                                .formatNum("2")))
                                                || (c.isSafari && (!c.verSafari || 0 > c.compareNums(
                                                                c.verSafari, c.formatNum("4"))))
                                                || (c.verOpera && c.verOpera < 10)) {
                                        b = [ 1, 1, 1 ]
                                }

Here it is checking for the version of your browser, whether you have IE < version 9, Firefox, Safari or Opera.

Another such check is

if (((javaver >= 500) && (javaver < 633))
                || ((javaver >= 700) && (javaver < 710))) {
        java1();
} else {
        if ((javaver > 709) && (javaver <= 717)) {
                java2();

Here your java version is being checked. And based on your java version i.e. if it is between 5.0.0 and 6.3.3 or 7.0.0 and 7.1.0 it will deploy a function java1. Now, in the pastebin output there is no java1 function. Which indicates that there was some other .js file referenced somewhere which is missing. Basically the java1 function is where the exploitation part actually starts. Similar case for the java2 function and many others. The plugin checks are basically to determine if it is possible to load that particular plugin in your browser.

So, this script was just the 1st stage of the actual exploitation. The reason why so many checks are performed is because exploitation has become very difficult and each version of a software requires a different set of payload. Not just the software version, but the OS version as well. A Windows XP SP2 exploit need not be the same as a Windows XP SP3 one, let alone Mac vs Linux vs Windows. And you usually have one chance, to exploit someone that has clicked a link. (A failed exploit will result in crash of the browser in this case) Hence the attackers have to choose the exploit that they have to deploy on a client wisely :/

By looking at the versions, if you were running any outdated application like browser, java, flash or adobe reader you should scan your system for intrusion.

Omair .
  • 331
  • 1
  • 2
  • I realize all that. My question was, given the code, how can I verify that my diagnosis based on analyzing it is correct. – mikołak Sep 12 '13 at 08:05
  • Well that's what I have been trying to explain. Out of the numerous bugs out there, it could be any exploit. You don't have the JS which carries out the exploit. So, you'll never know. – Omair . Sep 12 '13 at 09:11
  • Sorry, but if you're saying that you can't ever know what the attack can do on your machine if you don't know have all the code, then I disagree. Looking at the code you have, you can check whether it does anything suspicious, including calling unknown functions. My question is not about the worst case in general, it's about having access to at least the "top level" part of the code and being able to discover what kind of known threat you were targeted with, to verify your analysis. – mikołak Sep 12 '13 at 21:17
  • Like I have been saying, the JS you posted just checks for versions, os, plugins etc. installed on the system. The actual exploit is the next stage like functions java1(), java2() etc. for which you don't have the JS. So again, you'll never know. – Omair . Sep 13 '13 at 23:00
  • Even when I now what the "versions, os, plugins etc. installed in the system" are? – mikołak Sep 14 '13 at 00:33
  • Obviously, there were almost 100 Java security patches issued last year. It could be any one of those. – Omair . Sep 14 '13 at 06:19
  • Sorry, "know", typo there. And no, it **couldn't** be "any one of those", we're talking about generally solving a problem, but given specific code and a specific machine. You yourself say "if you were running any outdated application like browser, java, flash" - **why** do **you** say that if you assert that we can **never** know? – mikołak Sep 14 '13 at 08:27
  • Say two particular bugs effect 7.x.x version of Java, A and B. But the attacker found it easier to write an exploit for A. So, he will be using that. But another attacker found that writing B was easier. So, you see you'll never know. – Omair . Sep 14 '13 at 08:34
  • Sure, but if I have version "7.x.**y**", and no logic branch leads to executing an exploit, that gives me some knowledge, right? Get my point? If not, can we just agree to disagree? – mikołak Sep 15 '13 at 12:17