Smoke Loader, also known as Dofoil, has been advertised on dark web forums since at least mid 2011. Since initial release, this modular loader has continued to evolve with the addition of more complex anti-analysis techniques. Modular loaders such as this work by communicating with the command and control infrastructures to receive secondary execution instructions and/or to download additional functional modules, providing multiple stages of infection. Currently, Smoke Loader’s primary delivery method is via exploit kits, primarily Rig EK. Smoke Loader is commonly used to load the Trickbot banking Trojan and Globe Imposter ransomware.
Many malware families often make attempts to protect their original code base by utilizing packers and/or encrypters to implement layers of encryption, compression, and obfuscation into the actual binary sample eliminating heuristic function detection. We have seen new methods being used by Smoke Loader and have provided detailed analysis below.
Execution and Installation
There are two main paths of execution in Smoke Loader, the installer and the loader. The installer path runs prior to spawning and injects into a new instance of a Windows Explorer process. Post injection, the loader runs and executes the core functionality of the module. Before injection occurs, Smoke Loader performs several checks to determine information about the system on which it is running.
Figure 1: The gs register is used to determine the system architecture
The general segment (gs) register which is identified in Figure 1, usually goes unused on 32bit Windows systems. However, it is used by Smoke Loader to determine the system’s architecture. On 64bit Windows machines, the gs register is used to point to the Thread Environment Block.
Figure 2: The main execution paths within Smoke Loader
Before injection occurs, the installer will spawn two additional threads to help determine if the loader is being analyzed. This execution path has been represented in Figure 2.
Figure 3: Creation of anti-analysis threads
The “EnumTools” thread, which is shown in Figure 3, is created at this point to help detect and evade analysis tools. The loader then uses the CreateToolhelp32Snapshot API to enumerate the heap or module states of all processes and then return their snapshots. This API call is often coupled with Process32First/Process32Next to enumerate processes for injection. However, Smoke Loader uses these API calls to enumerate running analysis tools.
Figure 4: Terminate analysis process
If one of the twelve analysis processes Smoke Loader checks for is running, then the analysis process is terminated as shown in figure 4. The check for these processes is done via a hash-based method. Lastly, before the installer begins injection, the name and the volume information of the infected machine are queried. These are done as part of an anti-VM check along with querying the following registry key to see if it contains ‘vmware’ or ‘qemu’ strings: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\Enum\
Malware families often make an attempt to protect the core of their code base from analysis, through the use of packers/crypters which utilize layers of obfuscation to protect the malicious functionality at the heart of the sample. To examine and remove the protective layering surrounding Smoke Loader, the initial sample was loaded in a debugger and the first breakpoint was set on VirtualProtect.
Smoke Loader uses the VirtualProtect API call to change the protection of the allocated memory region. At this point we set the next API call to break on LoadLibraryA, it is in this section that the imports of the binary are dynamically resolved and the import address table (IAT) is populated. After the imports have been dynamically resolved, the module has the PE headers removed as an anti-dumping technique. The PE header must be rebuilt manually to successfully dump the file.
Figure 5: Packer removed MZ header
Here we can compare and contrast some of the changes necessary to rebuild the PE header, Figure 5 shows that the packer deleted the header to keep researchers from further analyzing the unpacked code. Figure 6 depicts the start of the manually-reconstructed file header necessary for dumping the unpacked code.
Figure 6: Manually reconstructed file header
The next step in successfully dumping the unpacked code includes modifying the ImageBaseAddress in the process environment block. First, we need the address at which the PEB is located. In x64DBG, you can use the peb() command to locate the address and navigate to the address in one of the dump panels.
Figure 7: Finding the address of the PEB in x64DBG
Once at the PEB, we can see that the third DWORD (00400000) is the ImageBaseAddress. This value needs to be modified to our current base address in order to successfully dump and rebuild the file.
Figure 8: Old ImageBaseAddress DWORD 00400000
Figure 9: New ImagebaseAddress DWORD 003A0000
To finish the unpacking process, we can use the Scylla plugin to dump the code. We have to put in our new ImageBase and also modify the size of the code. The next step is to get the imports and delete the invalid ones, the PE is now ready to be dumped.
Figure 10: Scylla dump
We provide Scylla tool with the original execution point (OEP), Image Base, and the size of the code section in order for it to to dump the repaired PE file. Next, we get the imports, delete the invalid ones, and dump the file. We must then open the dump with Scylla and rebuild the dump to successfully analyze the unpacked malicious core of Smoke Loader.
Towards the end of the loader execution path, seen in Figure 2, a comparison takes place to determine whether the injection needs to occur. If injection has not yet occurred, then the installer continues execution. The injection method has not changed since Malwarebytes analyzed the loader a year ago. The API calls used to create a new section in the target process and copy the malicious code there are as follows:
Once the new instance of explorer has been spawned and injected into, the initial process is terminated and the loader path of execution will begin.
Figure 11: Resume newly injected process injection and terminate the original process
Once injection has taken place, the loader execution flow followed in explorer is used to ensure that the loader persists on the infected machine and carries out its purpose of loading a second-stage payload.
After Smoke Loader performs injection, it opens a file mapping that was previously created in the installer execution path. The file mapping is used to support a form of inter-process communication which allows one process to share information with another process. In this case, some data is copied when the mapping is created such as the SellerID and file path.
To ensure survival upon reboot, Smoke Loader will drop a copy of itself in the %APPDATA%\Microsoft\[random folder name]\[random file name] with an EXE extension. The loader will then create an undocumented autostart registry key for explorer and monitor the key for changes. This is a common persistence mechanism used by many malware families.
After performing the anti-analysis checks and process injection, Smoke Loader will contact the command and control infrastructure. New to the latest version of the loader is the addition of a table which we have labeled “get config”. This procedure is structured so that it takes a one integer argument which acts as an index into the table.
Figure 12: Get config table used to determine what network traffic will be generated
For example, when the table index is 0x01, the sample will contact https://bing.com, this is used as a networking check to ensure the loader has Internet access. Smoke Loader contains the functionality to generate fake traffic to check for internet connectivity.
Figure 13: Use randomly generated fake domains for internet connectivity checks
If the check succeeds, then the sample will post to the command and control server as shown below.
Figure 14: POST sent to the command and control infrastructure
Other Notable Changes to Smoke Loader:
In earlier versions of Smoke Loader, the strings were not encoded. The latest version of Smoke Loader uses a custom XOR-based algorithm to decode strings within the sample.
Figure 15: Custom XOR string decoding algorithm
While Smoke Loader’s distribution is not as wide spread as other malware families, it is under continued development and very effective at what it does. The loader’s longevity indicates that the developers are committed to persistence and protection of their loader from the latest analysis techniques. Even though it dates back to 2011, the loader has undergone several transformations that allow it to continue to be a potent malware delivery mechanism in 2017.
This is a Security Bloggers Network syndicated blog post authored by Jason Davison, Threat Analyst. Read the original post at: The PhishLabs Blog