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.

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 2

Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. A while back , I blogged about some of the sandbox evasion techniques used by malwares. In this part , I'll walk through some of the most recent and efficient evasions used by malicious code to identify sandboxes.

Today, Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code. Since automated malware analysis frameworks process millions of samples per day, human interaction is bare minimal and malwares does not replicate and as a result, does not show complete behavior. Underlying hardware used to replicate the malwares also expose several artifacts about the environment which isn't too hard to notice.

Another flavour of DeviceIoControl ( )

In my previous post on this topic , I talked about the technique of using DeviceIoControl ( ) API to fingerprint the hard disk properties. This technique was yet again observerd in Win32/Phorpiex family of malware with the different IO control code. Win32/Phorpiex uses the IoControl Code 0x2D1400 (IOCTL_STORAGE_QUERY_PROPERTY) to check the returned device properties for virtual hard drives.













With this method , notice the output on Vmware and Qemu . It exposes the underlying hard drive properties on both the virtualized environment.

Windows Management Instrumentation

Windows Management Instrumentation is the Microsoft’s implementation of Web-Based Enterprise Management (WBEM) which is the industry initiative to develop standard technology for accessing management information .WMI is the default windows service that can execute the WMI scripts which is typically used to automate the administrative tasks. Above that, it provides common interface and object model to extract the management information about the OS, processor, hardware devices, applications and services.

Malwares can abuse this windows interface in multiple ways. One of the method is using WMI Query Language (WQL) to issue the SQL type queries to extract the hardware information. For instance, following queries can be issued by the malware to retrieve the Hard Drive / Processor information and match the keyword QEMU / VMware / Xen in the values returned.

SELECT *FROM Win32_Processor
SELECT *FROM Win32_BIOS
SELECT *FROM Win32_DiskDrive
SELECT *FROM Win32_SCSIController
SELECT *FROM Win32_ComputerSystem




















Checking the time acceleration using GetTickCount ( )

Traditional ways to detect the userland hooks had been to check if the function code does not start with the JMP or CALL instruction. One of the variant of Win32 / Kovter malware family was found to be using slightly different way of checking for the user mode hooks using time acceleration. It calls the API GetTickCount, then sleeps for 500 milliseconds and then calls the GetTickCount again to take the difference of the elapsed time. Sandbox systems historically have been patching sleep ( ) calls to force the stalling code execute faster. This technique performs the difference the time and checks if the code has stalled enough before executing the malicious code. It will terminate the execution if it determines that enough time has not elapsed between these instructions.












No of CPU cores on the virtual machine

Checking the number of CPU cores on the machine executing the malware is yet another elementary way of detecting the sandboxes environment. Analysis machines used by sandboxing environment are customarily configured with the single core while physical machines are predominantly multi core machines. Malwares can get the number of CPU cores by just calling the GetSystemInfo ( ) API taking the pointer to the SYSTEM_INFO structure, which returns the system data.SYSTEM_INFO structure contains the attribute dwNumberOfProcessors field which can be checked to see if the system is a single core machine.











Similar check can also be done by accessing the Process Environment Block of the running process. Offset 0x64 in the PEB defines the NumberOfProcessors on the system.













Foreground Windows check using GetForegroundWindow API ( )

One of the very predictable behavior of sandboxes is that they do not change or switch between the windows when the malware is being executed. Typically, this window would be the one from where the malware is executed and could be most likely desktop window. Recent variant of Win32 / Gataka banking malware was found to be taking the advantage of this behavior by calling GetForegroundWindow () API to get the handle of the current foreground window. Malware ceaselessly calls this API in the loop until the current window handle is changed after which it starts executing the malicious payload, thereby checking if the human is interacting with the execution environment.














Waiting for mouse clicks using SetWindowsHookEx ( ) API

Variants of Win32 / Banechant malwares employs more stealthier mechanism to evade the sandboxes. It installs the hook procedure using SetWindowsHookEx with the hookId 0x0E into the hook chain to monitor low level mouse events. This API defines the HOOKPROC specifying the callback function to execute when the windows receives mouse events. Earlier variants of Win32 / Banechant checked for a single left mouse click in the callback function before the malicious code is executed while the later variants came with the improved technique of checking for the more than three left mouse clicks before the activation of the payload.













As and when sandboxing technology becomes more popular and its adoption grows , malware authors will employ increasing level of sophistication in detecting sandboxes. It is extremely crucial for automated malware analysis systems to keep abreast of all such methods and patch it to keep the environment hidden.

Operation Mangal - Win32 / Syndicasec Used In Targeted Attacks Against Indian Government Organizations - Part-2 : Demystifying The Malware And Its Network Communications

In the previous blog on this campaign , I walked through the exploit , the timeline and the possible attack targets . Out here , I'll take a more deeper look into the malware family dropped and its communication to the command and control servers.

Dropped Malware family : Win32 / Syndicasec :

dw20.exe, 1st stage dropper executable dropped by all  the RTF exploits involved in this a attack, is a malware family dubbed as Win32/Syndicasec by ESET. This malware was identified back in March 2013 during which it was used in the cyber espionage attempt against the Tibetian activist and was also used in multiple other targeted campaigns. Previous versions of this threat was also discovered way back in July 2010 during which it was active in Nepal and China, as I indicated earlier.However, the payload and the mechanism of this malware has evolved since then.

I have uncovered that this threat is now also being currently used in the espionage attempt against the Indian government organizations. We can very well confirm the threat similarity based on the behavioural pattern on the system during the execution. 

It tries to determine the presence of sysprep.exe in the system32 and sysnative directory and then it goes to extract the embedded executable from the resource section , drops it in the %Temp% directory with the name gupdate.exe

Subsequently , it reads the Cabinet file embedded in the resource section , into the memory , extracts it into the /sysprep directory with the name cryptbase.dll , using the Windows Update Standalone Agent ( wusa.exe ).The technique used here to load the custom cryptbase.dll is what we call as DLL Load Order Hijacking . Sysprep.exe usually loads the cryptbase.dll, which is directly under the system32 and is not in the OS’s  Known_DLLs list . If the malware drops the DLL with the same name in the system32/sysprep/ directory , then the dropped dll would be loaded instead of the one directly under the system32 , because of the DLL search order. Further, it exploits the vulnerability in the Microsoft UAC whitelist process allowing it to run the arbitrary command with the elevated privileges.

Below are all the hashes of the 1st stage dropper along with the compile time which would give the fair enough idea of the timeline of the attack.

MD5s Compile time 1B83B315B7A729CB685270496AE68802 August 12, 2014 68BFA1B82DC0E2DE10D0CF8551938DEA August 12, 2014 C249CB532699E15B3CB6E9DEB6264240 August 12, 2014 5A80F6F6D75FD8D95D7EC830DC669129 August 12, 2014 2881F3EA27802FD9C1ED08C767083D12 Feb 27, 2014 391552FB8DE3F45FB7DD9EF7B9CAA4BB Septr 5, 2014 13C4D1CA7256B1FBEEEE9DE532097A94 August 12, 2014 7F5F57DE1734CC20D915AF68CC2821F2 Feb 27, 2014 0E7DB6B6A6E4993A01A01DF578D65BF0 Sept 5, 2014

The second-stage dropped file, gupdate.exe, connects to the command and control server. This communication is done in stages as well and uses the uncommon Windows Management Instrumentation system to register the JavaScript that connects to the first-stage URLs. The XOR routine for JavaScript follows:

Looking at the previous versions of this threat, JavaScript versions have changed every time this malware was used.

Command and Control communications :

The JavaScript is primarily responsible for connecting to the first- and second-stage URLs, which leads to the control server. Examining the multiple variants of the RTF exploits and the dropped binaries, we’ve found the following fake blogs with which variants of gupdate.exe communicate. All of the URLs point to the blogs’ RSS feeds, from which the encoded Stage 2 (control server) URL is fetched.

Stage 1 URL pointing to the RSS feeds of the fake blogs:

hxxp://kumar807.blogspot.com/feeds/posts/default

hxxp://kumar807.wordpress.com/feed/

hxxp://kumar807.livejournal.com/data/rss

hxxp://blogs.rediff.com/kumar807/feed/

hxxp://kumar807.thoughts.com/feed

hxxp://kumar807.tumblr.com/rss

hxxp://www.blogster.com/kapoorsunil09/profile/rss

hxxp://kumarsingh1976.wordpress.com/feed/

hxxp://musictelevision.blogspot.com/feeds/posts/default

Next we see the format of the encoded Stage 2 URL found on the fake blog. Note that the URL is within the the "title" tag with the “@” delimiter:

 

Encoded stage 2 URLs ( Command and Control servers ) found on the fake blog sites.

Once the response is received, the "title" tag is parsed out of the response and the decoding function in the JavaScript is applied to expose the control servers. Decoding algorithm has remained same in the previous versions of the javascript as well.

Below are the stage 2 URLs found to be connected by the variants of the gupdate.exe

www.asiasky.tk
kumarsingh.tk
zz13572.0023.jxwb2.com
hidimovie.tk
www.pattanasettyraju.org

The parameters sent in the POST request are formed by executing the WMI queries from the JavaScript. This image shows the functions of this operation:

While the malware executes, all of the control servers are live but with an empty command array. Examining the JavaScript, we see the command decoding is done with the eval() function, which leads us to believe there could be another JavaScript embedded:

Hashes for the RTF exploits involved in this attack:

598d9b335cec4e3ae6bd87d2c9734a1a
82440b92ddfccbd9645227c71df04db6
6b3700048ef7224f1d0efe1b33bab957
84cef2b4e9cc92533717919aefb55e3e
57679deaf8b39bbee00ac001c7eede81
cc3d7699838bcd434a2c3a804c4a196c
0a81badaf590ad6a9c6bd2f6edbb5f37
bd95cd9a058a267486ee8dbf44c3a757
6122d3fb69e9d3d7f93116eb8fbbf1ef
7772021f3883fd9f0b470387d46ae775
719db97a61e24b2619759ed054c06308
b908156a3fed1db5593c2ea730158f91
c10ffafcc7f44265c7f40d00bdbf5f73
2ed5a096825b7f7a147441d35ec28f10
e73ea3c88a89ef3ed2f4f8acacd048eb
077eaae040cbe7b35e4d2064cb75efe1
b2dfb6007c385414b6dcbb7a69c1ca2c
43c872c4b31c9e6de976e198639a390f
d8ef8fbb9689127b30229659fc091738

I've been tracking this threat since quite some time now . I'll keep posting any interesting updates and details on this campaign as and when I discover ..stay tuned !!..

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 1

As I demonstrated in my last blog , malwares have now started to submerge much deeper into the system to detect the sandbox environment. Besides the file system , process and known registry artifacts which can be very easily spotted by the researchers , there are several other methods researched to evade the automated analysis systems and needless to say , actively being used today. This two part blog series is primarily intented to provide a complete walkthrough of the most common sandbox evasion techniques prevalent today.

Latent execution:

Automated malware analysis systems are designed to process several thousand samples within a short period of time . Because of that fact, the proportion of time allocated for its execution is usually very limited , ranging from somewhere between 3 to 5 mins for one sample. Malware authors tend to take the advantage of this configuration aspect by introducing the Sleep ( ) calls in the middle of the code to pause the execution for several minutes before the execution of actual malicious payload. Under the Sandbox configured to execute the malware for shorter period , none of the malwares' actual behaviour would be captured. This is very common technique used today to bypass sandboxes . One such family of malwares using this was Win32/Kuluoz . 

One of the disadvantage of using Sleep / SleepEx calls is that they are easily noticeable and Sandboxes are now protected against this trick. Since they use the API Hooking to trace the calls , the moment it notices the Sleep ( ) calls , it will patch the argument to the API, effectively resulting into the faster sample execution.

Malwares as always , continues to look out for more elegant methods. One of the way to evade this protection mechanism is to use the alternate APIs some of them which are undocumented . For Instance below APIs can still be used to achieve the same functionality:

NtDelayExecution ( ) [ Undocumented ]

WaitForSingleObject ()
WaitForMultipleObject ( )
CreateWaitableTimer ( )
SetWaitableTimer ( )

More polished method to introduce latency was observed in the Win32/Cutwail ( MD5 : b4f310f5cc7b9cd68d919d50a8415974 ). It loaded the ECX register with the huge value and kept calling the API in the loop resulting into single API call > 78 Lac times. Below is the snippet of the code:

This can still be noticed by some of the intelligent sandbox systems out there . Way to go one step beyond this is not to call the API , instead place the junk instuctions in the loop . This can virtually defeat every sandbox technology. We could do something like this : 

Self Name Checks

One of the other common and observed way of sensing the sandbox environment is to perform the self check. Sandboxes, while executing the malwares are inclined to rename the file either to sample.exe / malware.exe / virus.exe etc. Malwares have found to be taking advantage of this naming convention. Similar technique was found in one recent malware (MD5:9404955681a5828b5ab9ab2a5c5547ce) named Win32/Comrerop.

And don't be surprised to see that Comodo sandbox helps this malware. Look at the analysis report here . Prevalent sandboxes like ThreatExpert can also  be traced using this simple mechanism. 

Loaded modules and monitoring tools

Sandboxes have their own monitoring DLLs that are used and loaded while processing the samples. Several malwares have been observed to check for these loaded DLLs specifc to respective sandboxes. It can also check for the installed monitoring tools used to capture the end to end behaviour of the malwares. Here is the code snippet from Win32/Comrerop performing similar checks:

More checks from the same malware searching for open windows of sysinternal tools / debugger :

Checking Hard Disk size

This technique is very well documented and has been observed in several recent malwares. The idea behind this logic is to obtain the handle to the physical drive using CreateFileA ( ) API and then use this handle to pass it to the device driver using DeviceIoControl ( ) API to perform the operation specified by IoControlCode. Malware using this mechanism with IoControlCode of 0x7045c is most likely performing the HD size check . If the Hard Disk size is < 10 GB , malware presumes that it is running under the sandbox.

IoControlCode 0x7045c stands for IOCTL_DISK_GET_LENGTH_INFO , which retrieves the length of the specified disk, volume or partition. Below is the HD size check in the malware code:

This actually makes sense because it is rare to have the sandbox machines with the larger HD size . 

Tracing mouse movements

Tracing the mouse movements is one of most effective way of differentiating the sandbox and easier to implement as well. Mouse movement check basically involves checking for the cursor position and then substracting the coordinates to check if the mouse has moved. GetCursorPos ( ) API is called twice to check for the cursor movement . Since there is no input device connected to the sandbox machines, it can trace almost all the sandboxes. 

Sandboxes can be protected against this technique by intercepting the call and randomizing the coordinate values. 

Ring 3 hook detection

Sandboxes significantly rely on the API hooks to be able to trace the activity of the malware. Ring 3 hooks are the user space hooks that can be easily implemented via modifying the initial instructions of the API code within the mapped DLL and pointing it to the hooked code. Several available sandboxing technology including Cuckoo , employs the similar techniques to log the APIs called by malware . Malware authors are very well aware of this and take the advantage of this implementation by detecting them. One of the simplest detection method is to get the virtual address of the API and check if that does not start with the standard prologue. If code starts with Jump/Call instruction , then it indicates that API has been hooked which leads to the conclusion that code is being executed in the sandbox . Here is the example code that attempts to detect the user mode inline hooks.

One of the way malwares tend subvert the user space hooks is to implement the custom loader and map the desired DLL in the process address space perhaps using a different name, and then get API address using the standard GetprocAddress mechanism . More sophisticated approach for the malwares could be to drop the kernel drivers which implements the required code using the lower level APIs and then user space components calling them , which will essentially bypass the sandbox hooking framework .

Sandbox detection using known product IDs

This is the another popular and easy to implement sandbox detection technique used by several recent malwares including Win32/Gamarue,Win32/Comrerop etc . Every commercial sandbox has its own associated Windows product ID that can be fetched from the registry key and matched against the blacklisted product IDs. Calliing the API RegQueryValueEx ( ) on the following registry keys will extract the respective product IDs :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\\ProductID
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\\ProductID

API trace for one of the sample trying to access the product ID:

Following is the list of some of the known product IDs and associated with their respective sandboxes:

Anubis :
product ID :76487-337-8429955-22614

CWsandbox :
Product ID :76487-644-3177037-23510

JoeBox :
Product ID :55274-640-2673064-23950

However, more focused commercial sandboxes are now well conscious about the product IDs being used against them and either deny the access to the registry key or respond with the randomized value.

I'll keep rest of the techniques of evading sandboxes to my next blog.We'll walk though few of them used in the recent targeted attacks. Stay tuned !!..