As almost all of our regular readers are aware, browser exploits are lately delivered heavily obfuscated. The main reason for this is, of course, to evade AV or IDS detection.

As the Anti Virus industry moved a step forward and improved detection of obfuscated exploits, the attackers started a trend of creating obfuscated exploits on the fly. I wrote about this before when I encountered dynamic JavaScript obfuscation (see http://isc.sans.org/diary.html?storyid=3219) – every time a client requested the web page containing exploits, the server side PHP script picked random variable names that, in this case, caused the whole function to be different since it was using the infamous arguments.callee() method so it depended on the function body.

This time I stumbled upon dynamic VBScript obfuscation. The exploit wasn’t interesting at all (it was the old MS06-014 Internet Explorer (MDAC) Remote Code Execution exploit), but the server side script that was generating the VBScript code was indeed interesting.

The server side script basically did two things:

• Randomly change all variable names
• Randomly split strings into multiple concatenated smaller strings

Below you can see two results of this obfuscation:

      rub="Mic"+"r"+"o"+"s"+"oft"
      jleptfo="XML"+"H"+"TTP"
      set ugdd = CreateObject(rub & "." & jleptfo)
      gljxbkx = "G" & "E" & "T"
      dsoswt = ugdd.Open(gljxbkx,nmqqa,0)
      ugdd.Send()
      On Error Resume Next
      lpuvkay = ugdd.responseBody

--

            lwyfqe="Mi"+"cr"+"osof"+"t"
      pnqf="XM"+"L"+"H"+"TTP"
      set jbg = CreateObject(lwyfqe & "." & pnqf)
      qcr = "G" & "E" & "T"
      rjtp = jbg.Open(qcr,osjypz,0)
      jbg.Send()
      On Error Resume Next
      gwwtvo = jbg.responseBody

--

As this caught my attention, I decided to spend more time on this and see how AV programs are doing against this simple obfuscation.

First of all, detection of such exploits still seems to be only in the early phases. Only 5 out of 32 AV programs represented on VirusTotal were able to detect this file as malicious (and of those 5 some share scanning engines so the number is even lower!).

To be fair to the AV vendors, properly detecting VBScript and JavaScript obfuscated exploits is not a trivial thing. Since there are multiple obfuscation ways they can rely on signatures only for basic detection. So, to detect things like string splitting they would have to implement some kind of an interpreter (or optimizer) that will detect things like this and create proper strings. This is one of the reasons why I was interested in how good they will cope with this obfuscation so I did a little test.

I retrieved 100 samples of the same script (directly from the compromised server so this is how it happens in the wild) and confirmed that all of them are functionally same, but have different variable names and that string obfuscation was used. And I was pleasantly surprised – all 5 programs detected 99 samples (only 1 was missed by 2 products that share the same scanning engine).

From this little test it seemed like the AV vendors have good interpreters or found a reliable signature. Unfortunately, my pleasant surprise didn’t last long. About 5 minutes later I found out that the signature wasn’t that reliable at all (except for this particular exploit) – by modifying the exploit slightly (and I really mean slightly – the details will be sent only to the AV vendors if they request them) I was able to easily evade all 5 AV programs while the exploit functionality remained the same.

So, the conclusion after this test (which is really small and not representative of any AV program’s abilities) is that the cat and the mouse game will continue for quite some time. As we are seeing more client side exploits I hope that the AV vendors are working on improving their detection in the background and that we’ll see some progress there soon.

--

Bojan