SmokeBuster: Keeping Systems SmokeLoader Free

In our previous blogs, we analyzed SmokeLoader's evolutionover the past decade. In addition, we presented technical information about Operation Endgamethat targeted SmokeLoader infrastructure and remotely cleaned infections. As we previously documented, SmokeLoader primarily consists of two components: a stager and a main module. The stager's purpose is to decrypt, decompress, and inject the main module into an process. The main module performs the core functionality of the malware including establishing persistence, communicating with the C2 infrastructure, and processing commands.

While developing SmokeBuster, we discovered that SmokeLoader contains numerous bugs. In versions 2018 through 2022, several of these bugs lead to a condition that will cause SmokeLoader to considerably slow down an infected system's performance. This is due to a combination of coding errors from the persistence implementation, the checks for the presence of running infections, and failures to adequately clean up threads and process memory.

The following figure illustrates the process in which SmokeLoader is executed every 10 minutes via a scheduled task after installation.

Figure 2: SmokeLoader execution process control flow (versions 2018-2022).

After the main module of SmokeLoader is injected into , the malware resolves Windows API dependency names by hash. SmokeLoader then creates two threads to check for the presence of malware analyst tools. If detected, these processes are terminated. These threads run in an infinite loop until a flag is set that indicates that they should terminate.

If a system has already been infected with SmokeLoader, the code checks whether a mutex name exists. If the mutex name exists, SmokeLoader closes the handle to this mutex and terminates the main thread. However, there are several issues that are problematic with this implementation.

First, the anti-analysis threads are always created before the mutex name check, and are not terminated even when the mutex name exists. Furthermore, the stager code does not itself perform any mutex checks. Compounding the issue, is the persistence mechanism schedules a task that executes the SmokeLoader stager executable every 10 minutes, so the main module will be injected into repeatedly. This causes SmokeLoader to create three new threads and allocate about 90 KB of space (for the main module) in the process every 10 minutes. The main thread will exit if the mutex name exists; however, the two anti-analysis threads continue to run.

SmokeLoader version 2018 has yet another potential issue in that there is a connectivity test performed before the mutex check. Therefore, if the infected system does not have internet connectivity, the main thread will continue to execute in an infinite loop, thereby leaving a third running thread per execution. Over time, the lack of a mutex check by the stager, and the lack of a mutex check prior to creating the two anti-analysis threads will significantly degrade an infected system's performance.

The figure below shows a screenshot of SmokeBuster running shortly after a system is infected with SmokeLoader version 2022. Note that there are three SmokeLoader threads and the main module has been injected into in the memory region .

Figure 3: SmokeLoader infection within a minute after execution.

If we run SmokeBuster 10 minutes later, the scheduled task will have executed the SmokeLoader stager. This causes SmokeLoader to inject the main module once again in at the region as shown in the figure below. In addition, two new anti-analysis threads (thread IDs and ) will have been created. The new main thread will terminate shortly afterwards since the expected mutex name exists. However, this new main thread does not terminate the anti-analysis threads or free the newly created memory section.

Figure 4: SmokeLoader infection after 10 minutes.

After only an hour SmokeLoader will have been injected six times and created 13 (1 main thread + 12 anti-analysis) threads. Thus, an infected system that has been running continuously for 24 hours will have been injected 144 times with 289 (1 main thread + 288 anti-analysis) threads running in explorer.exe.

Public link

Please use the above public link if you want to share this noodl on another website.