When opened in the sandbox the decoy document opens, which the attacker did not bother to customize ;)

During the dynamic analysis we can see the winword process spawning multiple child processes, including "vmsk.exe", some registry changes and cmd.exe which spawns a child winword.exe (the decoy document)

The registry changes as seen in the procmon

We can see a lot of cryptography related modules being loaded by the winword process, indicating that there could be encrypted data

We see some threads being created from within the winword process

Some registry keys with seemingly encrypted values

Below we can see some registry values being manipulated and internet zone settings and proxy settings being changed:

Here we see that a file is written/dropped in the temp folder

Process is started by running the file

We can see the decoy document being written on disk

Some more registry manipulations:

Here we see the decoy document being opened

Some interesting registry keys..RASAPI32 is an API for remote access while the research I did on the tracing keys only lead me to links about malwares and specifically malwares which encrypts aka ransomware

At this stage I am guessing that the threat actor has used a skeletal word document to exploit word, run some shellcode and decrypt and drop the vmsk.exe. This vmsk.exe is possibly opening a backdoor and could either act as a ransomware or download next stage binary which will turn out to be a ransomware. However it is worth moving ahead with the investigation.

We see the malware querying the ras phonebook entries

The two artefacts lay calmly in the temp folder

Details tab for the vmsk.exe properties shows LogicalSell as the product name..This is most probably to make it seem as a genuine file

We see that the sample is communicating to the above the three IP Addresses on port 1743

Researching on these ips we find that they are linked to DRIDEX banking trojan C2 servers

Indication of Dridex C2 infrastructure

Interesting..Zbot communicates to the same ip address but on a different port (8080). Could it be that both malware families share the C2 infrastructure?

This confirms that the threat actors behind this sample are the handlers of Dridex

The IP addresses are located in Ukraine

Researching on Virustotal for the ip addresses, we find that some malwares communicate to 91.239.232.145 on port 8448 as well beside the 1743 port

"In general, Dridex campaigns have been using
macros almost exclusively to deliver their payloads as in the example below:
Figure 6: Email with an attached Excel file with a malicious macro that
downloads Dridex The document exploit looks similar but requires no user
intervention other than opening the attached document on a vulnerable system.
This, like the Javascript vector, is quite unusual for Dridex" - See more at: https://www.proofpoint.com/tw/threat-insight/post/Dridex-JavaScript-and-Porta-Johns#sthash.mSuo9HgX.dpuf

The article goes on to say that:

"The final payload is Dridex botnet ID 220 and this campaign is targeting the UK users (with injects for UK, AU and FR banks). While the targeting and botnet are nothing new, the combined vectors are. The messages sent in this campaign include:

Both Microsoft Word and Excel attachments with malicious macros

Document-based exploits that automatically download Dridex when the documents are opened on vulnerable systems (CVE-2015-1641 and possibly CVE-2012-0158)

Zipped JavaScript attachments disguised as PDF documents. This is a new approach for Dridex, although the JavaScript functions identically to the documents, attempting to download Dridex when executed by user"

I decided to have a deeper look at the word file to determine what vulnerability is being exploited and what is the nature of the shellcode being used:

It turns out that the weaponised document is actually an RTF file

So I did an RTFScan and found some embedded OLE objects

Using TrID..one of the OLE object is identified as an MP3 Audio object

Other OLE objects were .skc objects etc

Extracted ole objects

Using hex editor to open the RTF object, we can see the rtf header and the \object \objocx sections. We can also see an embedded Word file

I decided to extract the word file from so that I could use OfficeMalScanner to analyze the embedded word file

Extracted word file in hex editor

Used the File converter tool from Kahu Security to convert the hex to binary doc file

Running OfficeMalScanner with "scan" option
Now the file which has been carved out is an MS word file..so I ran OfficeMalScanner and Voila! We see multiple shellcode related signatures being discovered at various offsets within the file..On top of that two more OLE objects are also found. At this stage I am pretty sure that the sample is trying to trigger an exploit on a MS Office vulnerability using some embedded objects aka OLE objects

Running OfficeMalScanner with "scan brute" options
The signatures include the infamous FS(30h) which is the pointer to the Process Environment Block (PEB) data structure in the memory. The malware starts by reading the PEB from pointer from the TIB, locates the LDR_MODULE structure of kernel32.dll, parses its PE structure and finally retrieves the IMAGE_EXPORT_DIRECTORY. This is then used to traverse to find offsets for certain APIs within the module like kernel32.Loadlibrary etc.

API Hashing signatures indicates the possibility of the shellcode hiding the name of the APIs (exported names), it wants to use for its malicious purpose, by encoding/hashing them. Then when the shellcode executes and while iterating through the exported names, it tries to match the hash against the passed hash values to find the ones it is looking for.

PUSH DWORD[] / CALL[] also indicates that some level of maliciousness exists as this means that some embedded parameters are being pushed to stack and then some function being called

We also see some ROR encryption of the OLE objects with key 0x08

Running OfficeMalScanner with "scan brute debug" options ..see below the assembly of shellcode found at various offsets:

We see that both decrypted OLE objects have the MS word signature as d0 cf 11 ...

File fingerprinting using Trid tells us that these are Generic OLE2 /Multistream compound files..MS word files.. Could one of this be the decoy document we seen above?

Next I thought of running the carved document file through BinText to see what kind of embedded strings I can find.. I am hoping to get some hints on the embedded OLE objects if any used to exploit the MS Office vulnerability and hurray..I see an ActiveX control calls MSComctlLib.Toolbar, Microsoft Toolbar Control 6.0, ListViewCtrl2 etc up there

I also notice image1.wmf and some ActiveX related strings

Now we are pretty clear that the RTF file is a weaponized container:

What? A weaponized container?
"A weaponized container as a specialized file that exploits an application level vulnerability to gain control of the EIP register on the CPU in order to carry out the intruders code on the target machine. Generally speaking, after the exploit occurs shellcode is executed on the compromised machine. Typically the shellcode follows an execution flow similar to:

When all is said and done the weaponized container is simply a means to an end. That end is generally a way in which the attacker gains a foothold into a target environment to carry out their objectives"

Some more interesting research I was doing along the way to see which vulnerability are we talking about here:

MS12-027 MSCOMCTL ActiveX Buffer Overflow
This module exploits a stack buffer overflow in MSCOMCTL.OCX. It uses a malicious RTF to embed the specially crafted MSComctlLib.ListViewCtrl.2 Control as exploited in the wild on April 2012. This module targets Office 2007 and Office 2010 targets. The DEP/ASLR bypass on Office 2010 is done with the Ikazuchi ROP chain proposed by Abysssec. This chain uses "msgr3en.dll", which will load after office got load, so the malicious file must be loaded through "File / Open" to achieve exploitationhttp://traceevidence.blogspot.com/2014/03/analyzing-and-detecting-weaponized-rtf.html

The first thing I tried.. I extracted the shellcode block indicated by the OfficeMalScanner and placed it in a file and then I used MalHost-setup to put a PE skeleton around it, hoping to disassemble and analyze it as a binary in IDA Pro. But then I did not find it fulfilling..so I thought of a more difficult way to reach to shellcode execution in a debugger by debugging the WINWORD.EXE process itself.

After sever iterations..F8s, breapoints, I could see some slight indication of the approaching shellcode..I could see refrence to the MS Listview Control version 6.0

I had tried earlier extracting objects out of the decrypted OLE objects using foremost..hoping to extract something interesting like embedded binary etc..but did not found much.. However I got some references to the license of the ListView ActiveX control

Found this interesting string embedded in one of the extracted OLE objects

Did some research and found this article on PA blog, where MSVCR71.DLL is loaded to bypass ASLR and it talks about the same text which I found above

I found details of another exploit which also uses the TreeView and ListView ActiveX controls related vulnerability

Back to debugging the winword.exe process..not being fruitful..still did not reach anywhere where the exploit is taking place..Looking for indications of stack smashing..where pivot to shellcode is taking place

Then I thought of taking a different route to reach to the shellcode, which is the EB FE technique. Basically the shellcode signature I found using OfficeMalScanner, I searched for that byte pattern in the original RTF file and once I found it I patched it with the EB FE bytes. The EB FE technique basically creates an instruction which jumps to itself, practically creating an infinite loop. The idea I had was that if I do that then I could open the word file which will get stuck at this loop and then I can attach Ollydbg to the stuck process and ultimately land at the beginning of the shellcode. I can then repatch the changed bytes to the original bytes and start step by step debugging from there onwards:

Patching the shellcode signatures in the file using hex editor

We can see that the winword process now is stuck at opening the file at 5%

And great! I was able to attach the debugger and pause it to reach the ifinite loop

I patch back to the original bytes

Patched to original bytes and we can also see that the shellcode is running in the context of MSCOMCTL.OCX. This indicates that some function of MSCOMCTL.OCX was used to perform exploitation

We can see that the shellcode is running within the .text
area of MSCOMCTL_OCX, indicating that the exploit must have caused some kind of
overflow for a vulnerable MSCOMCTL_OCX function:

We see the shellcode is trying to get pointer to
kernel32.dll using the FS[30h] technique as described above.

The code below is the standard method for identifying the location of
the PEB. This instruction will store the pointer to PEB in EAX. This is always
located at fs:[30h]
in the TEB (Thread Environment Block). The next important instruction will load
the pointer to the loader data structure - PEB_LDR_DATA, which is present at the 0x0c offset in PEB.
Further into this PEB_LDR_DATA struct, the code can then use the offset 0x1c to identify
InitializationOrderModuleList.

It is this list that is used to identify each loaded module and assists the
shellcode in locating the base addresses of kernel32.dll and other API
functions that may be required to infect the system.

Here we see iteration through the exported names

We see the shellcode found the offset for Kernel32.VirtualAlloc

Calling VirtualAlloc to allocate space in the process:

Iterating through the current handles and finding itself using the
GetFileSize

Shellcode usually tries to find the file within which it resides by iterating through handles and comparing the size of the object with the file size it knows..Why does it require handle to its container file (the malicious RTF file in this case), because it wants to then parse the file and reach to an offset where either second stage shellcode resides or some encrypted binary is residing, which it would want to drop in the filesystem and run it.

Trying to iterate through file handles to find a file with
size equaling 0A000

Finally found the handle to itself

Createfilemapping for self

Calling MapViewofFile

We can see the rtf headers at the EAX registe, which contains the pointer to the map view of the file

We can see the mapped view of file in the memory map

Egg Hunting:

Now the first stage shell code started the egg hunting
process whereby it will search for the second stage shellcode using the mapped
view memory section:

Verifying the rtf header

Iterating 4 bytes at a time searching for the binary string
“FEFEFEFE” within the file - Egg hunting

Found it

Another small loop to iterate until the byte FE is not
found

We see the bytes starting from 90 31 C9 shown above… being
copied from the file mapping buffer to the new location

In the above figure we saw a JMP EAX, whereby the shellcode
is jumping to the second stage shellcode after performing the egg-hunt for it
as seen before. The second stage shellcode is comprised of the bytes copied to
the location above.

Second Stage
Shellcode

The JMP brings us to a NOP instruction and the rest of the second
stage shellcode. Let us analyze the second stage:

After NOP we see some junk code and then we see a small XOR
routine where some decryption is happening on the same buffer. Remember this is
a LOOP instruction so it will loop until the ECX register is 0, which means
that the loop will run “0FD” number of times as seen above in the MOV ECX,0FD
instruction.

We see accessing the PEB again in the second stage shellcode

We see a small routine where by the iteration through the export list is happening

GetModuleHandleA function is used to get handle to specified module which is passed as the parameter.

We can see binary representation of kernel32 PUSHED to the
stack And calling kernelbase.getmodulehandlea(kernel32) to get handle
to kernel32

Finding and storing the API functions of kernel32.dll into
the heap

Pointers to some other functions which are searched and
saved in the heap:

Again trying to find the file using GetFileSize and
iterating through handles

We can see the handle points to our file

We see the filepointer is changed to 181782 bytes distance
from the beginning of the file

Next the file is read only 8 bytes and placed in the buffer
which is the stack

Then the shellcode checks whether the 8 bytes copied from
the file to the stack are equal to 48C77817

Next we see call to GlobalAlloc to allocate some heap

Next we see again setting file pointer to the beginning of
the file

And then copying 522803 bytes to the newly allocated heap

Pointer set back to the beginning of the file

Within the allocated heap starting from backwards the bytes
are zeroed out using a logic and then temppath is acquired

Next
we see the following at an offset of 2C62A bytes from the starting of the heap.
We see the name of a binary called vmsk.exe which we saw earlier during the
dynamic analysis. This is the binary file name which will be decrypted and
dropped by the shellcode in the temp folder. We can also see some indications
highlighted in yellow of the encrypted binary header

Next we see creation of the filename along with the path:

We see that kernel32._lcreat is called to create the file,
which in turns calls the kernelbase.createfileA

File created

A loop for decryption of the binary headers

We
see the fixed magic number and headers

The
file is written

Closing
file handle

WinExec is called with commandline to run and hidden window
“0”

CreateProcess
is called and process spawned

We see another filename string being created and heap being
allocated

Next
are some instructions to go to the first byte of the rtf file and then locate
the embedded OLE document file. This is going to be the decoy document

Instructions to copy the bytes of the decoy doc in the
following location

Creating
the decoy doc

Deleting the registry key (word 14.0)

More deletion of reg keys (word 12.0, 15.0):

We see the preparation to open the decoy documen

The process exits after

So what we have seen is a MS12-0158 exploit being executed and the EIP jumping to the beginning of a multi stage shellcode. This shellcode decrypts and drops malicious binary called vmsk.exe in the temp folder and executes it. It also finds and drops the embedded OLE object which is the decoy document in the temp folder and opens it. The vmsk.exe is the payload of the attack which communicates out to the ip addresses mentioned above which belong to the Dridex C2 Infrastructure.

When we run the vmsk.exe hash through VirusTotal we see that the detection ratio is very low and none of them identifies it as Dridex Trojan.

In my next blog entry I will be analyzing the vmsk.exe to analyze the capabilities of the payload.