Nothing makes my weekend like having to deal with a sh*t ton of phishing emails, so after receiving about 30 of these babies this weekend, I figured I'd check it out.

The particular file we're going to look at is:

SHA256: 404cc1674fa3ca493652c22e92c0d6182dda59b0

This file was sent as an encrypted email attachment with the password in the email body. After extracting the rar, we're left with:

Filename: (96)criminalcaseagainst_you.fax.wsf
SHA256: 060121ec65ca58af7bebe6e85074e3493cf4578d99da4350d28c679a87c7c45d

Neato, there's a .wsf file in there. Let's pop this open in Chrome (Yes, Chrome.), fire up developer tools and jump straight in!

Figure 1: Ick.

This is pretty ugly to look at - not exactly the most inviting looking code. They could have at least commented it amirite? Let's take a deep breath and analyze this thing together piece by piece.

After analyzing a bunch of obfuscated JavaScript, you'll begin to notice methods/patterns commonly used. The most important thing to remember with JavaScript is that the code MUST deobfuscate before running. With just this bit of knowledge, we notice a few things here. This code must deobfuscate and build itself out, so, I'm willing to bet that the function builds out the code using that enormous variable (var v8cdd). Let's throw var v8cdd into the console and test that theory.

Scrolling down, we see some code that manipulates the data stored in v8cdd. In the console, let's input the newly declared var v8cdd and var v4fdb.

Figure 2: Code at the bottom of the file after the monster that is v8cdd

Finally, let's input the for loop into the console. This should build out some encoded data and store it in var v4fdb.

Figure 3: Data prepared for decode function

Excellent! Err - sort of. We still can't really read that. Fortunately for us, we know this is going to deobfuscate before it runs. After the for loop, it calls v1de8(va4ac, v4fdb). What's going on here? Going back to Figure 1, we said that v1de8 looks like a decode function. We also see va4ac [string] being declared. Remember, our newly prepared data that was in v8cdd is now stored in v4fdb. So the decode function takes 2 arguments - one argument is our data and the other is the string stored in va4ac, which is going to be the key.

Let's input function v1de8 into the console. Once we input v1de8, it should run the function. If we were correct in our assumptions of how the code works, it should spit out a string of code (that is stored in v4fdb).

Figure 4: After calling v1de8(va4ac, v4fdb) we get this beautiful, ALMOST decoded blob.

Hey! I know some of those words! But we still have an array of hex values stored in var _0xbb55. This likely contains a bunch of values that are used in the code. Let's get this thing into a Snippet and pretty print it so we can actually focus!

Figure 5: Putting this code into a snippet and then pretty printing it makes it SO much easier to read.

MUCH better. As we predicted earlier, values inside the array are being used in the code below it. Let's go ahead and convert the hex values in the array _0xbb55. JavaScript is super nice and does this for us. First, input var _0xbb55 into the console. Then, just simply eval(_0xbb55)...

Figure 6: If reading hex isn't your forte, our array values are now nice, readable values.

and we're given a beautiful array of readable values. Now let's console.log _0xbb55 and replace our nasty array with hex values with our nice array of readable values. From this point, we can simply substitute values where they are called. For example, anywhere we see _0xbb55[0] we'll sub in "\Microsoft\Crypto". See you in ~30 minutes... (Seriously, it takes forever)

Once the substitutions are finished, we're left with some nice, readable JavaScript/JScript/WScript code. Your code should resemble something like this:

Figure 7: Looks like the authors were nice enough to leave function names alone, so it's pretty easy to understand the underlying capabilities.

To dive a little bit deeper and truly understand what's going on here, we could rename variable names to make it even easier to read. I recommend doing this, especially for beginners as it is very important to understand how the code itself works. I'll leave this part to you!

Dropper Code Summary

Nothing groundbreaking here - the dropper deobfuscates itself, creates persistence using autorun, requests the malware from the C2s, runs the executable that is downloaded and reports back if it was successful or not.

The code itself is still pretty neat though. It's not too hard to deobfuscate in that you're not really going to be banging your head against the wall to figure it out, but not too easy to the point where it isn't satisfying to take apart (err, build in this case).

I hope you've enjoyed the JavaScript series! We're just getting started though. Knowing how to deobfuscate JavaScript is an essential skill when doing document analysis. I'm currently developing the document series, so until then, keep practicing!