Weaponized Container exploiting MS Office Vulnerability CVE 2012-0158 - Communicating to Dridex C2 Infra

The delivery mechanism

 The Email headers:

X-MSK: 2BIG

Received: from xxxxx by

 Wed, 3 Feb 2016 19:07:45 +0400

Anti-Spam-Filtered: true

Anti-Spam-Result: A0AlJQBQF7JWTkTd8V+CbAUBxmACAgE1Bg

AV: E=ssdsdss;i="sdsdsd";

   d="doc'212?scan'212,208,212";a="202086"

Received: from host68-221-static.241-95-b.business.telecomitalia.it

 ([95.241.221.68])  by xxxxxxxxxxxxx  with ESMTP; 03 Feb 2016

 18:51:06 +0400

From: "yvonne@direct-electrical.com" <yvonne@direct-electrical.com>

To: xxxxxxxxx

Subject: ****SPAM**** Spam

Emailed Invoice - 101970:1

Date: Wed, 3 Feb 2016 15:50:57 +0200

Message-ID: <56a74b1c.d7bc1c0a.c68bd.ffffb6a7@mx.google.com>

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="----=_NxtPrt_ftshd_1454512065"

X-Mailer: Microsoft Outlook 16.0

Thread-Index: AQFWN1DoL0ELw7e2BKf2LERCeWAK4A==

X-SpamInfo: UTM-AntiSpam ase,

X-ASE-REPORT: 125aa4f28e8ff5bfcdc53c1d5b665b9dd                Threshold 80                       Verdict score                       100

                                                Engine version                     1.00001.117                        Rule version                         1001              Rule:               100                 R_BLACK_CHECKS

                        UM                                         Sig3:                1                      BE601E638D4790864E1A472B8D1D6BFD:6:522803

Return-Path: yvonne@direct-electrical.com

X-MS-Exchange-Organization-AuthSource: xxxxxxxxxxxx

X-MS-Exchange-Organization-AuthAs: Anonymous

X-NAI-Spam-Flag: YES

X-NAI-Spam-Level: ******

X-NAI-Spam-Threshold: 5

X-NAI-Spam-Score: 6.5

X-NAI-Spam-Rules: 6 Rules triggered

                        HDR_PHRASES_SUBJ=5, URI_END_ID_LNG_CAMEL=1, PHP_SHTTP_NTHTG=0.2,

                        SNW_GEN_220=0.2, SHT_CLCK_HRE=0.1, RV5570=0

X-NAI-Spam-Version: 2.2.0.9309 : core <5570> : inlines <4268> : streams

<1581604> : uri <2132399>

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

 Some interesting links

Interesting Analysis by proofpoint: https://www.proofpoint.com/tw/threat-insight/post/Dridex-JavaScript-and-Porta-Johns

"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?

Some more interesting read:

https://www.blackhat.com/docs/us-15/materials/us-15-Li-Attacking-Interoperability-An-OLE-Edition.pdf

Ø CVE-2014-4114/6352 (a.k.a. “Sandworm” zero day) Ø Reported in October 2014. Logic fault, really serious Ø 2 OLE objects found in the original sample Ø Microsoft failed to fix it in the initial patch

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:

1. Locate / resolve operating system API calls
2. Decode and execute stages of shellcode
3. Locate / download, decode and execute a binary which drops additional malware, sets up persistence mechanisms, display a decoy document, etc.

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 exploitation
http://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 could also see some reference to the license for TreeView control

http://researchcenter.paloaltonetworks.com/2015/08/rtf-exploit-installs-italian-rat-uwarrior/

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  

Some more interesting research:

https://threatpost.com/espionage-malware-watering-hole-attacks-target-diplomats/116600/?utm_content=buffer8f661&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

https://www.proofpoint.com/sites/default/files/proofpoint-operation-transparent-tribe-threat-insight-en.pdf

https://securelist.com/analysis/publications/37158/the-curious-case-of-a-cve-2012-0158-exploit/

https://blogs.mcafee.com/mcafee-labs/cve-2012-0158-exploit-in-the-wild/

https://www.sophos.com/en-us/medialibrary/PDFs/technical%20papers/Baccas-VB2013.pdf?la=en.pdf

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.

struct PEB_LDR_DATA{
...
struct LIST_ENTRY InLoadOrderModuleList;
struct LIST_ENTRY InMemoryOrderModuleList;
struct LIST_ENTRY InInitializationOrderModuleList;
};

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:

TErminateProcess, GlobalFree, GetCommandLineA, WinExec, _hwrite, _lcreat, GetTempPathA, CloseHandle, GlobalAlloc, ReadFile, SetFilePointer, GetFileSize

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.