Not Your Typical Ransomware Infection

An analysis of an infected PC revealed that an attacker used several NSA tools just four days after the Shadow Brokers’ dump then it burned the PC with ransomware when they were done with it. This blog post by Secdo may be related to this one but I can’t be sure.

I was asked to assist with an infected PC that had already been turned off. The ransomware encrypted the usual file extensions as well as .exe, .dll, .sqlite, .log, .xml, .dat, etc making it extremely difficult to piece together the activity that had taken place earlier.

On 4/18/17, a remote user logged into the computer via RDP and proceeded to execute a program called “key.exe” which dropped files in “C:\ProgramData\MicrosoftHostDLL\” including synchosted.exe (which is turned out to be NSSM – The non-sucking service manager). A new remote admin account called “backup1” was created and the password written to the info.ini file (and c:\info.txt).

The attacker downloaded several tools to the downloads folder and disabled anti-virus and added an exclusion for c:\users\backup1 in Windows Defender.

Other tools were installed as well such as UniversalTermsrvPatch-x64 and Advanced IP Scanner.

Based on the evidence, the following NSA tools were used by the attacker:

+ FuzzBunch (exploit framework)
+ Architouch (SMB recon)
+ EternalBlue (SMB exploit)
+ DoublePulsar (backdoor)
+ DanderSpritz (event log deleter, password stealer, screengrabber, keylogger)
+ PeddleCheap (shellcode/DLL injector)

When FuzzBunch is run, log files are created which provide a history of the operator’s activities. However, the ransomware program encrypted these files.

There were some files left untouched for some reason and I was able to collect details that show whether an attempt was successful or not.

One successful compromise prompted the attacker to download and install OWASP-ZSC to compile shellcode and use PeddleCheap to push that onto the machine. Each attempt caused the PC to crash. Digging into the crash dumps yielded the shellcode source.

When this failed, other attempts were made to install malware.

I tried to get the payload from the above site but it was no longer available. I found something in Google’s cache that seemed to match the file names.

The attacker then downloaded executables onto the desktop and tried to push them onto the other PC which failed. Having given up, the attacker trashed the PC by executing ransomware known as “Global Imposter”.

It appears that this attacker was figuring out how to use the NSA tools and eventually with enough practice s/he is going to get good at it. Others will too so we will probably start seeing a higher level of attacks — attacks using military-grade implants that don’t leave a whole lot of traces behind. Good luck to all of us.


Filename: key.exe
MD5: EECD77E9D522F3BA9022AC55487D98F1
Size: 1.19MB

Filename: synchosted.exe
MD5: E1D51EAE61D112CB00F8F9CED4D7294C
Size: 331KB

Filename: genpwd.exe
MD5: 0569047CAD5FFE8C40290960FFDCFDA1
Size: 808KB

Filename: local.exe
MD5: B1BA95F7F943E424D562AA5BB255ADC5
Size: 530KB

Filename: 1.exe
MD5: 227837783DFC1C2B3575746478CC133E
Date: 7KB

Filename: 2.exe
MD5: 1AB7415C4A38F45085857FB9E6BD2069
Size: 72KB

Filename: 3.exe
MD5: 6D1029FABF4D314065E3B33AC02ACEA6
Size: 1.14MB

Filename: 4.exe
MD5: 9B79D2C612E4EAFB9034FD652F5A20EA
Size: 1.14MB

Filename: Aifc0CC.exe
MD5: E967102AA181290B3A2BB68AD36E285A
Size: 72KB

Filename: GFDXaoPXi.exe
MD5: 81B9EA03264EA0A2B65B36EACB05B465
Size: 72KB

IPs/Domains – – – – – –

Posted in Malware | Tagged , , | Comments Off on Not Your Typical Ransomware Infection

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 Nothing. I then used 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 (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 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