Hi everyone! We got a special piece of malware on the docket. Mila over @ contagiodump and Trusteer reported a new type of malware called Shylock. They were mum on the details aside from some threat report which was very sparse on information. So I requested a sample and proceeded to do some RE on it. So we’ll look into it together to combine traditional Reverse Engineering for the goal of finding artifacts to verify infection in Volatility. (Download the Shylock infected memory sample here)

The dropper can be downloaded from here (the pw is “infected”) and does some basic decryption of itself then proceeds to create a few files. One is a copy of itself in a random path as well as a .bat file that is ran from cmd.exe with the \c to change attributes on the dropped files then erase them after malicious code is injected into explorer.exe. The dropper spawns this command shell to process the .bat file. The bat file is pasted below.



:repeat

if not exist "C:\re\shylock\4FDA5E7E8E682870E993F97AD26BA6B2" goto exit

attrib -R -S -H "C:\re\shylock\4FDA5E7E8E682870E993F97AD26BA6B2"

erase "C:\re\shylock\4FDA5E7E8E682870E993F97AD26BA6B2"

goto repeat

:exit

attrib -R -S -H "C:\Documents and Settings\vmuser1\Application Data\Adobe\Flash Player\D.tmp.bat"

erase "C:\Documents and Settings\vmuser1\Application Data\Adobe\Flash Player\D.tmp.bat"



A file is also copied in windows\system32 and a subsequent unique id is generated that will be in the. After that it terminates itself and removes the dropper off the disk leaving all control up to the recently injected code into explorer.exe.

3 sections are allocated into explorer.exe and a dll is decrypted and loaded by these 3 sections. After this the injected code replicates itself into other processes by injecting them and hooking API’s. I’m going to be showing code snippets that are from the injected code using the technique I posted on previously about Debugging Injected code with IDA Pro.

Well other artifacts that we can use to aid in analysis or diagnosis of a particular sample are Mutexes and Files. Reversing the dropper (as well as recently published here, here, here) we can see that the malware creates an autorun key as it’s persistence mechanism with a unique key.

This function is copying a string of “MTX_” to the heap that will be parsed together with our unique ID. Then fed into our call to CreateMutex. You can see the pointer returned by the above screen shot is de-referenced then passed to a CreateMutex wrapper function that takes one argument.

Notice the function call is actually Create_Mutex_Arg0 which I’ve had to RE, rename as this function is actually a wrapper call to CreateMutex. The wrapper code is displayed below. If you wanted to find out exactly where this is in your injected code. You’ll have to set a break point on kernel32_CreateMutex and see where it was referenced in your hijackdll as it could be loaded in a completely different spot than what’s in my IDB.

This final function actually calls the system API call to create this mutex. Now let’s verify this artifact holds for us in our memory dump. The way we can do this is to use the mutscan command and pipe this output to a file. Doing this and we search for “MTX_” we get a few results that look like this.

MTX_919863BFD426AA00979BDF55477F92A7

You’ll notice a few of these in the mutscan as there is another value that is added which I haven’t yet reversed yet. (I decided to publish this early due to Evilcry’s webpost.) So that’s our first artifact and we’ll look into a file artifact next. This just illustrates that you can do a rough once over debug/RE to find artifacts for a piece of malware that may not be published in a formal threat analysis from AV, researcher, someone else.

Next up we’re going to investigate a file artifact. Shylock uses named pipes to communicate but also it uses this unique id that was referenced above. The following screenshot shows the routine in which it is created.

So you can see here that the injected dll uses the CreateNamedPipeA command to setup the named pipe that it subsequently reads/writes from. Now leveraging this information from our debugging/RE process we can use this to create another fingerprint from a Shylock infection. We can verify this in Volatility with the filescan program using “python vol.py -f img.mem filescan > output.txt” and look for a named pipe that is a hexadecimal number 32 bytes in length. Sure enough we find one for our infection here.

0x01b42340 0x819b8730 3 1 —— ‘\\919863BFD426AA00979BDF55477F92A7’

Now for extra credit you can attribute this to a specific process and you can see that it’s parent will be explorer.exe. To do this you can use Volatility 1.3 and Andreas Schusters file plugins. More artifacts may be coming soon what else can you find?

References:

[1] –ContagioDump of Shylock

[2] – Evilcry’s Shylock Volatility Analysis

[3] – Symantec Shylock Report

Share this: Twitter

Facebook

Like this: Like Loading... Related

Posted in incident response, Malware

Tags: artifacts, debugging, malware, re, reverse engineering, shylock