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:
This file was sent as an encrypted email attachment with the password in the email body. After extracting the rar, we're left with:
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.
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
Figure 2: Code at the bottom of the file after the monster that is
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
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
var _0xbb55 into the console. Then, just simply
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 we'll sub in
"\Microsoft\Crypto". See you in ~30 minutes... (Seriously, it takes forever)
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).