Smoke and Mirrors

[Fi8sVrs]

Exploit kits are constantly serving up a variety of exploits and payloads to systems across the Internet on a daily basis.  In order to prevent their payloads from being easily mitigated, they typically contain many layers of obfuscation and anti-analysis checks.  The authors understand that many eyes will have access to their malware and they often put a shell around the final payload to defend against malware analysis, sandbox analysis, and antivirus protection.  Smoke Loader is one such shell that uses a Nullsoft script installer package to deploy the initial malware payload.  Below are the details of how Smoke Loader infects the system, attempts to evade analysis, and persist on the system.

 

Executive Summary

Exploit kits authors make their money by being able to sell the use of their system to many different buyers. In order to do that, they need to be able to protect their final payloads from being easily reversed and defended against. Smoke Loader is a shell that protects the final payload by using multiple layers of injection and hollowing to make analysis difficult. In addition to these layers, they also have active defenses that look for indications that they are running in a virtual machine or being actively analyzed by known security tools. If any of these tools are found they will terminate them to prevent their secrets from being discovered. Once fully installed on the system, Smoke Loader will contact the Command and Control (C2) server to download the arbitrary payload for the exploit kit subscriber. This diagram represents how Smoke loader goes from initial execution to full presence on the system.

Figure 1: Process Overview

 

Technical Analysis

Delivery

Nullsoft is an open source script-based tool for building installers on windows. It is easy to use this wrapper to quickly setup the first stage of the Smoke Loader malware.  For this version of Smoke Loader the installer essentially just dropped and executed the first stage of the malware in the %TEMP% folder, which comes in the form of a malicious DLL called fiberboards.dll and a packed file called Lexigraphy.cab.  The fiberboards.dll binary will then unpack Lexigraphy.cab, load the necessary libraries and APIs, and launch another copy of the original malware suspended in memory.  The now unpacked stage two is mapped into the memory of the new process and is ready to be executed.  The fiberboards.dll file then passes execution onto stage two and exits.

 

Injection Junction

Stage two is where the fun begins for this sample. This portion of the code contains heavily obfuscated code flow that self-modifies as it is executing. This type of anti-analysis technique can make it very difficult to perform static analysis on the binary.  Function calls often go several levels deep and then a new address is pushed onto the stack just before the return in order to re-direct the flow of the code to an entirely different function, never to return. Since this is done dynamically, tools such as IDA are unable to follow the code flow forcing the analyst to step through each function call. Bypassing these type of packers can be time consuming and problematic, especially if there are any kind of anti-debugging tricks that make finding the end of the unpacker difficult. Stepping over a function that seemed unimportant can often result in the malware executing beyond what you expected. Working through this packer, we determined where the next stage was unpacked in memory. This allowed us to set a breakpoint on that location and dump the unpacked malicious code.  Once the packer has been bypassed we are now able to more clearly see what the malware is going to do.

 

Crossroads

Once the code is unpacked, the final version of the malware is visible to us. There are two paths available depending on the current status of the execution flow. Both paths also share code used to set up required library functions and anti-analysis defenses. Smoke Loader uses a custom hashing algorithm in order to compare various process, libraries, and window names through the program. Here is the algorithm used by this version of Smoke Loader:

Figure 2: Hashing Algorithm

 

This allows for hardcoded values to be used by the malware without revealing what names they are actually looking for.  

Figure 3: Loading Libraries

 

These two hardcoded values (0x421E4440 and 0x44194744) are the hashed representation of the file names ntdll.dll and kernel32.dll respectively.  Each loaded library name is hashed until the values match and the address of that library is recorded.  Smoke Loader also dynamically loads each API call using this same hashing algorithm.  All of this obfuscation further increases the time to statically analyze functions and determine functionality.  

 

Once the API calls addresses are stored, Smoke Loader executes two threads that protect the malicious process from active analysis.  These threads hash process names running on the system and the names of active windows and compare them against a hardcoded list of hashes that should be terminated.  Using the hashing algorithm makes it difficult to determine exactly which analysis tools will be terminated.  In order to attempt to determine which tools will be terminated, we reproduced the hashing algorithm in C++ to be able to run different names through the algorithm.  Here is a link to the code, which can take a file and hash all the names.  While it is difficult to have a full list of window and process names for all things the authors might have wished to detect, the following list are some of the values we were able to determine the binary was looking for and would terminate:

• Ollydbg
• Process Hacker
• Procmon

 

Utilizing the implemented algorithm also made it easier to determine which libraries were going to be loaded, making static analysis of functions quicker.  The threads run in a constant loop looking for any of the hardcoded hashes and window class names to be terminated.  The final bit of anti-analysis is checking to see if the malware is running on a virtual machine.  This is performed by querying the following registry key:

HKLMSystemCurrentControlSetServicesDiskEnum

Four strings are decoded and checked to see if they are contained in the result.  If  and of the following strings are detected the malware continuously calls the sleep function:

• qemu
• virtual
• vmware
• xen
• ffffcce24

In order to prepare for the next stage, a hash is generated from hardcoded data within the sample and used as the name of a file mapping created with the API CreateFileMappingA:

63CA4449C7E27B984F81F498FCDFC938

This file mapping contains the full path to where the malware is residing on the system.  At this point, the malware is ready to move to its final destination: explorer.exe.  A new explorer.exe is launched in a suspended state, the code is hollowed out, and the malware copies itself into its new home.   Execution is then resumed and transferred to the new process.

 

Let’s Explore

Much of the same setup functionality discussed above is re-executed in the new explorer process, ensuring that all the libraries are loaded and the anti-analysis threads are executing.  A check is performed to see if the parent process is explorer and if it is, the next phase of the malware executes.  The same hash is created as above and the file mapping opened so this stage of the malware can retrieve the location of the original malware.  The previous stage will wait until this handle is closed before exiting.  Next, Smoke Loader obtains the user agent string for the current version of Internet Explorer installed on the system.  In order to verify that the system has a connection to the Internet, it will attempt to contact hxxp://www.bing.com and will continue attempting to connect to this address every sixty seconds until it gets a response.

 

Before moving the original malicious executable to its new location, the computer name and the volume information are retrieved from the system and hashed to serve as a mutex on the infected system. This ensures that there aren’t multiple infections on the current machine while it is being moved to the new location.

 

Smoke Loader then searches through the following registry key looking for any subkeys that have the values HelpLink and URLInfoAbout:

HKLMSoftwareMicrosoftWindowsCurrentVersionUninstall

Some of this information will be used to look less suspicious when installing persistence on the system further down.  

 

An eight character name is generated based on the last eight characters of the unique ID generated above and is used as the future name of the malware.  The first 8 characters of the ID are used to generate the random folder name it will be contained in.  Here is a visual demonstration of this process:

Figure 4: Name Generation

 

Now that the folder and malware name have been generated, the new path for malware is put together:

%APPDATA%Microsoftbteurgsdugivagdt.exe

 

The directory is created according to the above location, the malware is copied from its original dropped location to the new malware path, and the original copy is deleted.  It will also attempt to delete ugivagdt.exe:Zone.Identifier in the newly created folder.  In order to further blend in with the system the folder and the malware file have their attributes changed to system and hidden and both are timestomped using the timestamps from advapi32.dll in the system folder.  

 

In order to set up persistence, Smoke Loader uses information taken from the uninstall registry key above and uses it to create a value in the following key:

SoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun

In the case of my analysis machine, Process Hacker 2 was chosen as the target to hide on the system.  

Figure 5: Persistence

 

This essentially uses policy settings to specify startup programs for the user.  Once the persistence is in place, a thread is created that repeatedly checks for the existence of this key.  If the key is deleted it will re-create the key to maintain persistence.  With the malware fully installed on the system, a thread is launched that performs the remainder of the tasks for Smoke Loader.

 

Are we there yet?

This thread contains the functionality for handling whatever type of payload the exploit kit is currently serving up.  At the time of this writing, the C2 server was no longer active.   Fake traffic is also generated in this thread using the URL taken from the Uninstall key above (hxxp://sourceforge.net/projects/processhacker/support for example on my analysis system).  This is done on a random timer and several times in order to look legitimate on the system.  Finally, once it has done its best to look legitimate, the C2 server is contacted.  From here, additional payloads can be downloaded and executed or injected directly into the process.  Additional C2 servers can also be added to the list in order to maintain the ability of Smoke Loader to contact its controllers.

 

Conclusion

Exploit kits can deliver potentially thousands of samples across the Internet on a daily basis.  Because of the sheer number of eyes that may see their samples, they are often very difficult to analyze.  Heavy code obfuscation, anti-analysis, anti-virtualization, and multiple layers of injection and hollowing are common fare for this type of malware.  This class of malware can often have new and interesting ways of evading detection in order to retrieve the final payload from another location, which make them worth analyzing in detail.  By listing IOC’s and detailing the tactics and techniques used, networks can be better protected from these malicious threats.

 

Indicators

Indicator	Type	Context
http://hellobro.bit	Domain	Command and Control Server
4082bf938715c3d4ca639e47313f991b	MD5	Smoke Loader
88048f15b3206de1efd6147bac585be17c84caafd9ac2a0392d4886ce5a148f5	SHA256	Smoke Loader
63CA4449C7E27B984F81F498FCDFC938	File Mapping

 

Source:  https://www.cybrary.it/channelcontent/smoke-and-mirrors/