Wild Wild West – 05/2017

Another update to the exploit kit scene. There’s been some changes but nothing very exciting. We can’t put our guards down however since this could change very easily.

If anyone cares to share the source for anything in the most wanted category, I would love to study it. And yes that includes Eris / Solar / Neptune.

Big thanks to Kafeine for his input as I couldn’t have done this without him!

Posted in Exploit Packs | Comments Off on Wild Wild West – 05/2017

Static vs Dynamic Analysis and the Amusing Outcome

It all started with a malicious RTF document attached to an email and a request from reader Chris (thanks for your request and help!) to locate the embedded SWF object since it was believed to contain a hidden PE file.

The RTF document contained a 2012 exploit which is described here. The difference between the two documents is that this one contained a SWF file.

I proceeded to use oletools to search for SWF files using pyxswf.py. Nothing. I then used rtfobj.py to dump all the objects.

I looked through the files and no SWF header. I also used OfficeMalScanner’s rtfscan and got the exact same objects and no SWF. I went back to each of the objects using a hex editor and I find the header…kind of.

The “FWS” header can be translated into hex as 0x465753 but in the file it shows up as “0x04657532”. It’s off by half-a-byte. I wrote a quick program that shifts the file by converting everything to hex, removing the first hex character at the beginning, padding the end with a null, then converting everything back into bytes.

Now I get the Flash file.

Chris suggested I use Didier Steven’s rtfdump.py (with the latest fix — version 0.5) which gets the job done.

Using JPEXS you can see the deobfuscation routine of the embedded binary data.

I created another program to do some ad hoc XOR’ing and I find that the binary blob is another Flash file. You can read this TrustWave article on Sundown EK and use their Python script.

This embedded SWF file is reusing an exploit from Magnitude EK. You can read about that exploit here btw. No sign of a PE file.

Let me go back to the large object I dumped earlier and try to find the PE file using static analysis. At the top, I notice that this is the same marker as the one identified in the SecureList blog post. Looks like the PE file is here but it’s obfuscated.

I compare this file with the malware that gets dropped by the malicious RTF file and I can see that it lines up exactly and that the null bytes are left intact. Since nulls are present, I can rule out compression and modern encryption. That leaves shift and XOR as a possibility but since they ignored nulls, I can’t easily get the key.

What I need to find is a large contiguous blob without any nulls. Near the bottom of the PE file I come across padding strings. There’s other parts of the file I could use but this makes it quicker.

All I need to do is XOR the plaintext with the obfuscated portion and I can get the key. I use Converter’s Key Search/Convert and paste the values in and I get the result.

Here’s what the result looks like. It looks random but I’m hoping there’s a repeating pattern here. That pattern would represent the XOR key.

Here’s a trick I do to find a pattern. I simply change the dimensions of the Notepad window and watch the pattern emerge. There it is!

So the repeating value appears to be 256 bytes long and looks like this:


Let me test this out with Converter. Ugh, so close!

After analyzing the results, I noticed that if a null character is present then it doesn’t rotate the key for the next loop. So I add a new option to Converter…and it works! It works on the decoy document embedded in this object file as well.

Now I wanted to find the shellcode and verify this using dynamic analysis.

One way is to open the document with Word, dump the memory, then look for that marker. Here’s the shellcode.

And here it is in the RTF document.

If you dissemble this, you find that the first part of the shellcode deobfuscates the second part. XOR’ing the second part with a value of 0xA6 reveals the PE decoding routine. I went ahead and XOR’d it then put everything together in IDA. But let me use a debugger instead…

Ah, it’s not a 256-byte XOR key! You can see that the shellcode deobfuscates the PE file using XOR with a starting value of 0xA8 then incrementing it by 0x07. If there’s a null byte then it skips that byte (and doesn’t increment the value). How simple.

So at the end of all this, it turns out that the 256-byte XOR key found during static analysis is the same result I got dynamically albeit the long way to the solution. Very amusing!

Note: If you look at the XOR key above, you’ll see that 0xAF + 7 = 0xB6 + 7 = 0xBD …etc. And when you get to the end, 0xA8 + 7 = 0xAF.

Update 03/01/2017 – To those who where asking, here’s the PE results from VirusTotal.

Posted in Malicious Email, Malscript | Tagged , , , , | Comments Off on Static vs Dynamic Analysis and the Amusing Outcome

Wild Wild West – 11/2016

It’s been awhile since I updated this; my apologies for the delay to those who have been asking.

Many thanks to Kafeine for his expertise and invaluable feedback!


Posted in Exploit Packs | Comments Off on Wild Wild West – 11/2016

Deobfuscating the Nemucod Downloader Script

Matt Decker from hybrid-cloudblog.com sent me this script he received via email and asked for help deobfuscating this so here we go…

Here’s the WSF file he sent me:


About half-way down the script, I come across this. Two variables should have caught your eye.


Doing a search for the first variable name, I end up at the variable “vista” which references that blob and then the function is immediately called.


To view the value of “vista”, I do this. I don’t want the script to run any further so I do a quit right after the popup.


And this is what I get. It shows several functions like reading and writing to a file and three conversion functions. This decrypts the download file which I’ll get to in a bit.


Searching for the other variable, brings us here. It’s inside of a for-loop and the variable “efioppocsonny5HORDA6” appears to be building up URLs then calling a function named “efioppocsonny5_a2”. Notice that the URLs are being passed in the first argument.


Now let’s search for this function. It’s going back up to here. Based on what’s in the function, it looks like it’s preparing and making AJAX calls.


So our goal is to see the URLs and block the HTTP request for now. Here’s the changes I make.


When I run it, I get the URLs one at a time.


If you want to pull down the payload then search for “.Run” and comment out that line so the payload won’t execute and interrupt our analysis.


Based on the script, it will download and save a file into the Temp folder, read it in, decode it, write it out to a DLL file, then execute it. However, this particular script doesn’t seem to have domains that answer so I have to find another script with live domains.

Here’s another one I got from VirusTotal Intelligence:


And make the same change.


This time I get the payload, the script decodes it then writes it out to a DLL file which turns out to be Locky/Odin.


Let’s have a look at the original downloaded file and the DLL file from the Temp folder. I wrote this program to analyze the files. I load up the binary files into each input box (only the first 1,024 bytes are read to save time).


Then I choose the “XOR” method as my first guess.


I get this result. Do you see a pattern in the output box?


How about now?


I can use Converter to XOR the original file using the same XOR pattern (converted to hex).


And get the same result as the original.


Now let’s see if we can find this in the script. Near the bottom there’s a long string that gets sent to the function VGRA3 (that function is from the blob we deobfuscated earlier). Then later when the payload is downloaded, the variable holding this key is used to XOR the file. It’s the same string.


We’re done!

But I did want to show you another related script I found. It’s basically the same as the one above, however, the JScript is inside of an HTML file. This is an important distinction because we have to deobfuscate this differently.


At the bottom of the script, we see that it’s functionally similar to the script we just looked at. Do you see that function call at the “if” statement? Let’s search for that. By the way, the blue arrow is pointing to the XOR key.


Here’s the function that takes in some arguments passed from the call at the bottom. The first argument is the URLs just like the previous script.


If I search for the variable name, we see that there’s two other variables prepending it.


Let’s see what these three variables are by adding the following line then have it stop running the rest of the script. Notice I have to use “alert” and “stop” instead of “WScript.Echo” and “WScript.Quit”.


Now I can execute the script by running it in IE. You can’t use another browser because this script uses an ActiveX control.


You can continue to alert on variables to better understand what it’s doing but you’ll find that it’s doing the same thing as the WSF script from above.

Good luck!

Posted in Malscript, Tools | Tagged , , , , , , | Comments Off on Deobfuscating the Nemucod Downloader Script

Deobfuscating a Malicious PHP Downloader

A PHP script was sent to me by reader Nuno who got this from a hacked Joomla website and wanted to know what this was. He said this script was prepended to several legitimate PHP files. Looking into this a bit, I found that this is related to WordPress hacks via MailPoet back in 2014 according to Sucuri (here and here).

The original script from 2014 is pretty much the same as this one after you deobfuscate it so it appears that its creator updated the obfuscation layer since then. Here’s what the 2014 script looks like:


And then it was modified some time later.


This is what the PHP script looks like today.


At the bottom is the code that deobfuscates the above. I make the following change as you can see.


And I get the deobfuscated result.


However, the result gets truncated. It’s probably because there’s HTML-looking tags in there so I have to modify my change to this:


Now I can get the entire script.


After I unescape it, I can see at the bottom a call to the deobfuscation function. I repeat the same step as above.


To get this:


I keep doing this for two more rounds and I end up with this. The for-loop at the bottom deobfuscates the last remaining blobs by passing it to the “oo1” and “oo2” functions above.


I grab functions from the previous rounds and put them all here. Finally you can see what this does.


The script gets some HTTP info, randomly selects a domain (33db9538 .com, 9507c4e8 .com, e5b57288 .com, or 54dfa1cb .com), and makes a request to its C&C using one of five methods until one works. The HTTP GET requests look something like this:

hxxp://54dfa1cb .com/743373?nBcDCJtttnWOB7AFwE6JSD2%252 B9FWohBE48s54engkXvlo7MmPmabcMTRfK5tqJyYRYA4xsNOviBQDEFq2uGAIfWs%253 D.vxcX.60JI.vXyZAJNtdCnP.%252FkaXEZd1

hxxp://33db9538 .com/941577?cqzyJtttwfqjfH%252FwfN8k7f%252 FSpz9SnXR016abcKoeOzkdP9zUs2oUlKyoGy6DqbbxOPukqZ5y%252FDEFLjNyQU2GGmY%253 D.Uazm.Bfm5.UXyZLzR9z6bi.EPWaPjBl

None of the sites were responding with anything useful at the time of this writing so I don’t know what the payload is but if it’s the same as it was back in 2014 then backdoors are created on the site and overwrites legitimate files in the process.

This is what all of the C&C websites look like:


If you get hit by this then you would probably need to do a fair amount of cleanup, restore from backups, or rebuild your site to ensure no backdoors are left behind.

File: 1.php
MD5: 3ED6699CE373F6BEED22F490B1D93219
VT: 2 / 54

File: 2.php
MD5: 69A1CDF5E389D6388ABB3E6DA198D998
VT: 8 / 54

File: 3.php
MD5: 733C0DD3099C514A7D067D0A20657650
VT: 4 / 54

Posted in Malscript | Tagged , , , | Comments Off on Deobfuscating a Malicious PHP Downloader