Win32/Furtim : Malware With Galore Of Stealth And Evasions..

Recently around a mid May 2016 , a sophisticated malware nicknamed Win32/Furtim was uncovered and since then , lot of noise has been made about the attribution of the malware and the suspected targets. One of its dropped components was believed to target European energy company while others believed it to be a credential stealer. However , while the purpose of the malware and the potential targets are still unclear and perhaps under investigation , this piece of code sounded extremely interesting to me because of the fact that , it goes an extra mile to implement heterogeneous techniques to hide its behavior. This methods are wide ranged from detecting installed Anti-Virus products, virtualization ,sandboxes, monitoring tools and plenty of stuff.

I wanted to take a in-depth look at the malware to see evasion techniques used.This code also has been obfuscated by using indirect calls to the huge extent to prevent static analysis . Apparently , it must also have several anti-debugging techniques to hide itself from debuggers. It uses ZwQueryInformationProcess with ProcessDebugPort to check if the process is running under the context of the debugger.

Bypassing user-space hooks

Win32/Furtim bypasses user space hooks by directly calling ntdll APIs. Several AV products and sandboxes implement user space hooks to monitor the API calls of the process. This malware uses lower level calls to avoid being monitored by traditional hooks. Some of the ntdll APIs that it tries to resolve:
























Blacklisted processor architectures

It executes CPUID instruction after loading the registers with the appropriate values to get the processor brand string and compares with the blacklisted processor architectures. If found, it will terminate :


















Apart from these , CPUID instruction also reveals the hypervisor details. Below is the check performed if the malware is running under hypervisor environment.






Blacklisted hostnames

Next it tries to detect the analysis system by checking the hostname . Process will terminate if it finds the hostname matching any of the ones in the blacklist.







These hostnames should apparently correspond to known sandboxes. Below are couple of instances found:













File paths containing the known strings

Many of the automated analysis systems including commercial sandboxes tend to use the "malware" , "sample" , "virus" etc in the file name or the path. Here is the check that is performed to match the path against the known path names or string after calling GetModuleFileNameW.


















VxStream sandbox

It calls GetDriveTypeW to check if Z:\ drive exists on the system as a DRIVE_FIXED and then checks for Z:\\VxStream to see if it is running inside the VxStream sandbox.









Known hooking DLLs used by AV products for behavior monitoring

Antivirus products and sandboxes attempt to monitor the behavior of the processes by injecting the DLLs into its address space. These monitoring DLLs patch the API calls in the kernel32.dll redirecting to its own stub to log the behavior or to modify the stack before the call is made. It is very unlikely that ntdll will be hooked by commercial sandboxes unless unavoidable , since it interface is not consistent and changes between OS. Win32/Furtim calls the ntdll API GetLdrDllHandle to check if any of the below monitoring DLLs is loaded in the process . If it finds one , it will terminate.






















Known sandbox / monitoring tools artifacts

As another addition to the implemented evasion techniques,it calls NtQueryAttributesFile to check if the infected machine has any of the blacklisted files . This list includes the check for Cuckoo sandbox,Cwsandbox, presence of debugger , Sysanalyzer monitoring tools,Gfisandbox , malware decoders and several others . It will perhaps refuse to run or alter its behavior if any of the file is existing on the machine .























Mismatch in the number of CPU cores reported

This is yet another clever check performed by the malware. It calls NtQuerySystemInformation to populate the buffer with SYSTEM_BASIC_INFORMATION. At the offset into the structure, it will access the SYSTEM_BASIC_INFORMATION.NumberOfProcessors to see if the Number of Processors reported is 1 . It the check is successful , it matches the brand string extracted using CPUID instruction with the known CPU brand strings to validate the number of CPU cores . If this check if successful , the process will prematurely terminate .





















Dynamic anlaysis apparently reveals this fact :







Blacklist of processes related to known sandboxes / monitoring tools / Virtualization environment / Honeypots 

Here is one more check for running processes to see if monitoring / debuggging / static analysis tools , sandbox processes , traffic capture tools, Honeypot processes are found in the infected system.























Kernel drivers associated with AV products / Monitoring tools / Virtualization 

Another extensive blacklist of loaded kernel drivers. It calls NtQuerySystemInformation with SYSTEM_MODULE_INFORMATION to get the list of loaded kernel drivers and checks is performed against the below list:























Virtul NIC cards

Following virtual NIC cards are checked as well . It any of these virtual NICs are found , it will terminate the execution.





















Before this code gets executed , it also checks for system with the NIC card named "Realtek RTL8139 Family PCI Fast Ethernet NIC" , username "Antony" or Antonie" and existance of C:\\Downloads directory. This doesn't sound like a sandbox specific configuration . Perhaps it doesn't want to run on a system owned by "Antony"













Hypervisor registry keys

As if these aren't enough, it also has the checks for the Hypervisor specific known registry keys. Below is the code that checks for it .











Next to this , it accesses the registry key:\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\ and verifies if it has following values :

• SystemBiosVersion has following data
• BOSCH - 1
• VBOX - 1
• PRLS - 1
• VideoBiosVersion has following data
• Virtualbox

DLLs associated with analysis tools and sandboxes

Below list of DLLs are usually loaded by the tools used to analyse the malware samples (SysAnalyzer etc .) . Some of these are loaded by known sandboxes ( Sandboxie , Sunbelt , Buster)













Presence of  "Vmware Tools" directory under C:\

Calls GetDriveTypeW to check if the C:\ is present on the system and checks for the existance of following directories:

• C:\\Program Files\\VMware\\VMware Tools
• C:\\Program Files (x86)\\VMware\\VMware Tool ( 64 bit systems)

Presence of Virtual HD

Below two registry keys are accessed and the value extracted is checked against the known Virtual HDs . A successful match with result into termination of process.

\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\IDE
\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\SCSI

• QEMU_
• VMware
• Ven_Red_Hat&Prod_VirtIO
• DiskVBOX
• DiskVirtual

Presence of BioMetrics / Fingerprint software by ZkTeco

It is hard to believe that any malware would check for this . But it was interesting to know that it checks if ZkTeco software is installed on the system . Googling for this , apparently it is a provider of Biometrics / Fingerprint sensors . I can certainly say at this point that this malware has came out to be too restrictive. These nature of softwares wouldn't run on any automated analysis systems. Along with this, it also has the checks if the Path Names contains "Oracle" . Not sure if the author really intended to check for sandbox.



















Registry check for installed traffic analyzers / analysis tools / virtual environment

Yet another list of software installations to check for in the registry.






Window class names / Window Title Names

Eventually , it also runs a check for the known window class and window title names used by sysinternals monitoring tools and sandboxes . Below is the exhaustive blacklist for that as well .



















Malwares have become extremely evasive in nature to avoid running in the automated analysis systems. Authors employ variety of techniques to make static analysis time consuming and complex for the researchers as well. However , none of the techniques used in this malware is new or is something which we haven't seen before. Its just that its a comprehensive list of almost all the evasions that we would have probably came across in other malwares in the past.

Microsoft Office RTF Exploit : CVE 2015-1641 Dissecting the Shellcode

Few days back , I came across interesting RTF exploit floating around, eventually concluded as CVE -2015-1641 vulnerability. I was particularly interested in knowing about the DEP / ASLR bypass mechanisms and shellcode used in this exploit . I decided to dig little deeper into this exploit to figure out how it overcomes the windows mitigation mechanisms.

First step for me to start with analysing any MS Office exploit is to run it through my own developed static analysis framework for Office exploits , which can precisely extract the embedded streams, locate the shellcode and can do bunch of other analysis stuff. Notice that 4 embedded binary objects has been extracted out of the RTF exploit.





Looking at the log file , we'll observe few stuff which is worth further investigation.
















It has also extracted 2 Open Office XML document embedded within the RTF exploit. Static analysis framework further has the ability to re-analyse extracted OOXML files. If we take a look at the anlaysis.log file for the extracted_ooxml_1, it has detected a shellcode in the embedded object activeX1.bin












and similar for the extracted_ooxml_2










Below graphical representation of the shellcode apparently indicates the API address resolving code , parisng the export table as you'd normally see in most of the exploits.
















Lets take a look at the interesting embedded binary objects.

ASLR Bypass - object_00000020.bin






otkloadr.WRAssembly.1 is the ProgID that loads otkloadr.dll. This DLL is linked to another MS Office component MSVCR71.dll , that will get loaded once the exploit is executed and the one which is used to bypass ASLR. MSVCR71.dll is shipped along with the MS Office and it is not compiled with /DYNAMICBASE which makes possible to hardcode the addresses for ROP chain.











object_000000E6.bin

This object contains the embedded OpenOffice XML document which includes activex1.bin that is used to perform the heap spray before the vulnerability is triggered. This technique is similar to the one used in CVE-2013-3906.








Following structure of the activex1.bin used for Heap Spray clearly reveals the shellcode. This structure of RET sledge + ROP chain + NOP + Shellcode is repeated every 0x20000 bytes

















object_000187A1.bin is responsible for triggering the vulnerability. I wont't be digging much into the vunerability details since it has already been covered in greater depth in the blog over here

object_0002802c.bin also has OOXML document embedded and activex1.bin inside it leads to believe that EIP will be overwritten with 0x08080808 after the vulnerability is exploited. It is yet unidentified at what point this happens but the structure of the binary object is apparent. This can be confirmed by launching the exploit in the debugger as exposed in the next section.


















One of the fact to note about this exploit is that it crashes several times when the execution is transferred to the heap at address 0x08080808, where the shellcode doesn't exist. Once we launch the exploit in the debugger , we can check out the non-aslr module MSVCR71.dll loaded by otkloadr.dll







After the exploit is launched , it performs the heap spray and subsequently,vulnerability is triggered to redirect the execution control to the heap , overwriting EIP with 0x08080808.

Shellcode Analysis - 1st Stage

1. Beginning of the 1st stage shellcode, as we would usually see in most of the exploits, parses the Process Environment Block ( PEB ) and deternines the base address of kernel32.dll. It then parses the export table of kernel32.dll to resolve the address of VirtualAlloc( ) API.












2 . Calls VirtualAlloc ( ) to allocate the buffer and copies the hashes of the APIs to be resolved further, and then again returns to the export table parsing routine to resolve address of GetFileSize ( ) , CreateFileMapping ( ) and MapViewofFile ( )











3 . Next, the shellcode tries to locate itself in the memory by incrementally passing the file handles to the GetFileSize in the looped code. If the file size is greater than 40KB and less than 2MB, it calls CreateFileMapping and MapViewofFile ( ) to map the file into the address space of the calling process and matches the first 4 bytes of the file to check the RTF header.










4 . Subsequently, it adds the offset 0x10000h to the beginning of the file and searches for the 2nd stage shellcode marker 0xFEFEFEFE and 0xFFFFFFFF and eventually jumps to execute it.










Shellcode Analysis - 2nd Stage

1 . At an offset 0x2E from the start of the 2nd stage shellcode , it XORes 0x3CC bytes of the shellcode with the single byte XOR key 0xFC.











2 . Calls NtQueryVirtualMemory( ) API to retrieve the original name of the exploit document , converts the filename to ASCII using WideChartoMultibyte ( ) and then calls GetLogicalDriveStringsA ( ) to append the current logical drive to the document name



3 . Searches for the marker 0xBABABABA, subsequently decodes the XORed encoded executable with 4 byte XOR key 0xCAFEBABE , calls GetTempPathA ( ) and writes the decoded executable to the %temp% directory with the name svchost.exe















4. Next part of the shellcode searches for the marker 0xBCBCBCBC , XOR decodes the decoy document with the 4 byte XOR key 0xBAADF00D and then calls previously resolved API UnmapViewOfFile ( ) to unmap the original exploit file from the process's address space,writes the decoy file to the original exploit document and eventually executes it using WinExec ( )
















5. Invokes cmd.exe to delete the registry key "HKCU\Software\Microsoft\Office\12.0\Word\Resiliency" with /F switch to force delete and suppress the error messages from Winword.exe














Decoy document :









At the time of writing this analysis, dropped executable connected to the C&C server login.loginto.me resolving to 58.158.177.102. Based on the passive DNS records this domain also resolved to 23.249.225.140

Espionage Attacks On Indian Organizations Continues In 2015 With More Politically Themed Exploits..!!

In November last year, I blogged about Operation Mangal , an ongoing targeted attack campaign against several Indian domestic and overseas organizations. I was actively tracking the campaign since last year. In my previous analysis of this attack I uncovered several exploits that were politically themed and closely connected to India’s developmental agenda. The exploits lured victims into opening malicious documents that compromised their machines and stole confidential data. We found that this campaign has been going on since 2010 with periodic variations in the malware families.

Since January this year, we have seen a steady flow of similar exploits as part of this campaign. These exploits continue to be politically themed and closely follow national events. The following are some recent exploit filenames or themes:

• Indian Diplomacy At Work — UNSC Reforms.doc (MD5: faa97d7c792e3d8e7fffa9ea755c8efb; first seen: Oct 31, 2014).
• Vibrant Gujarat Summit 2015.doc (MD5: b44a0ebddabee48c1d18f1e24780084b; first seen: Jan  6).
• U.S.,_India_to_formulate_smart_city_action_plans_in_three_months.doc (MD5: b0ae36bcf725d53ed73126ed56e55951; first seen: Jan 28).

During late 2014 and early 2015, the attackers modified the shellcode and the dropped malware family, continuously changing their tools and techniques. Some of the recent exploits involved in this campaign has been found to be dropping PlugX malware . The following images show how the shellcode has been modified between exploits observed on January 6 (at left) and January 28 (at right).

While researching this campaign , I was able to gain access to one interim control server, which appears to be the short-term registration server that the compromised host communicates with after decoding the first-stage URL. The directory structure of the control server is:

/cms: 

This directory holds all the client data in JavaScript Object Notation from compromised machines connected to this server. The following image shows the directory structure and the information stored in the file:

Filename: h_HOST-NAME_TIMEVAR_t. All the machine information (IP, MAC, OS type, hostname, OS version, infection time stamp, etc.) was recorded on the remote server with this filename.

Next we see how the machine information looks on the control server, highlighting the infection time stamp from late last year:

Filename: r_off_PCNAME_TIME_TIME_t. This holds base-64 encoded data for command-line outputs that ran on the compromised host.

Decoding this data reveals the command that was executed on the compromised host and also exposes the list of documents and files on the machine that could have been stolen.

Filename: c_HOSTNAME_TIME_t. This file holds an encoded WMI script or script variables in the following form:

which turns out to be a readable WMI script when decoded:

Filename: d_rdown_HOSTNAME_TIME_t. This file is uploaded from the compromised host to the control server.

Filename: rdown_HOSTNAME_TIME_t. This file is downloaded from the control server to the compromised machine. It could contain post-exploitation tools to run on the host.

/tools:

The tools directory hosts several post-exploitation tools and malware to be downloaded from the control server to run on compromised machines. We found malicious DLLs, rootkits, encoded JavaScript malware, and cab files. One of the WMI scripts is an installer for other malware:

I have been able to track down the location of many of this campaign’s control servers, primarily in the United States and China. More than 60% of the servers were hosted in the United States and more than 20% were hosted in China.

Attackers are continuously on the lookout for social engineering opportunities. Influencing targeted users to open malicious documents following national events is one the most effective and effortless ways of performing these espionage attacks. Users need to exercise extreme caution when opening documents from unknown sources and use patched software.

I would like to thank my fellow researcher Brad Arndt for assistance in researching and tracking this campaign.