JJEncode Script Leads to Drive-By
The use of JJEncode in a drive-by download has been around for a couple of years but has been popping up a lot recently. A couple of readers have asked how to deobfuscate this so here's a walkthrough with a live script.
Here's an automobile forum that's been compromised:
Viewing the source code, this link kicks off the infection:
There's a few ways to deobfuscate this script. I'll show you two ways. Here's the slow way but this is how you can understand a little of what's happening.
First make sure you have "<!DOCTYPE>" at the beginning since this only works with HTML 4.0 and above (with IE anyway). If you're going to use Firefox or other browser then you don't have to do this. Now search for semi-colons and add a new line in between. Look carefully for the semi-colons in between quotes as you need to leave those alone. What you will likely end up with will look something like this (the bottom portion won't have any semi-colons to separate on).
Since I'm working on a malicious script, I want to do this carefully so I'm commenting out everything below what I'm working on. There's an equal sign near the beginning of each line. This indicates that the characters before it is a variable and the characters after is the value. So all I'm doing is "alerting" on the variable so I can see what each line does. Here's the first one:
Here is the result:
And the second. Notice that I left the first line uncommented. The reason is that it defines the variable "_" so if I comment the first line, nothing will happen on subsequent lines.
Keep going until you reach the line just before the large block of symbols:
The result tells us that this is a function call and if you look closely you at the end of the script, you'll realize that the major portion of the script is a self-executing function.
So we can just replace "_.$(" with "alert(":
And we can see the result:
If you want to see how the original code looks like, we can make a change to the very end of the line. From this:
And then we get this result:
Here's the second way you can deobfuscate this script. It's fast and easy but may not work 100% of the time. Just add this to the top like so:
And the final result appears:
Let's take a look now at the malicious script and applet. The values of the parameters are base64-encoded. The top URL refers to the payload file. The bottom part loads a single Java applet from another URL and a parameter contains a link to the same payload but with a slightly different URL.
This is a new exploit pack that the industry named "DotCacheF" but it looks like they changed the URL format.
The Java applet is not heavily obfuscated but has a low detection rate. Here's an excerpt of the code that exploiting CVE-2013-2423.
The payload appears to be ZeroAccess.
VT: 3 / 46
VT: 3 / 47