In this report, I will demonstrate the methods to unpack a SmokeLoader executable manually. While this can be automated with UnPacMe tool, I still found it helpful to unpack manually to understand what is happening. This analysis will not be going over the actual SmokeLoader payload, instead how I went about extracting it for future reference and technique practice.
SmokeLoader Summary
SmokeLoader is a bot that has been used to distribute malware such as Vidar. SmokeLoader has also been around since 2011, one of the samples I have seen when browsing malware repository sites such as MalwareBazar.
Stage 1 Analysis:
Sha256Sum: 0098901d9b40d0d1e34f820347bd7af6d39da582115aab1918a5a71dd03bf7b2
Tactics and Techniques
Junk Code and Anti Anti-Sandbox
The first stage of Smokeloader has a smokescreen, plagued by a large amount of garbage API calls, all of which do nothing to progress the code. While running the program through a debugger, I noticed it took a significant amount of time to get to my first breakpoint. In addition to slowing down the static analysis work on this sample, the time it would take to carry out the intended purpose of the code could be used as an anti-sandbox technique which is comparable to having a large sleep time.
Decryption
Amidst this junk code, is the decryption routine which is shellcode that is later executed.
Stage 2 – Shellcode Analysis
The analysis of this shellcode can be done in two separate ways. The first and least preferred method is loading up the shellcode as an additional binary within IDA pro. Using this method as a standard practice undercuts the advantage of the Windows types that IDA automatically provides for the original stage 1 payload. While it is an easier method, I found that looking for the entry point and scrolling through with this method was difficult and tedious. The preferred method is converting the shellcode into an executable and then loading it into IDA pro.
Tactics and Techniques:
API Hashing and API Resolution
The Shellcode uses API-Hashing and LDR structure to load and search for Windows APIs to resolve. The two APIs used are LoadLibraryA and GetProcAddress, which are then being used to resolve more APIs dynamically. The API hashing algorithm can be found here on my Github.
The shellcode then creates a structure to store all the dynamically resolved APIs across the program.
Decryption
The shellcode uses the same decryption routine to decrypt the next stage;like the second stage, this is also shellcode.
Stage 3 Analysis
The third stage was incredibly hard to analyze statically, and it proved to be more efficient to set breakpoints on VirtualAlloc and see what was being stored in the buffer. Finally, what came out from this was the final payload, a MZ executable which I have identified as SmokeLoader.
Conclusion:
The usage of junk code and API Hashing, along with using the LDR structure to load modules, are techniques I see more often in my analysis. While I took the time to analyze this sample statically, the unpacking process for this sample is straightforward, and putting breakpoints on the VirtualAlloc function to see what is written to their buffers is sufficient. This note will aid in my future analysis for other variants of this sample.
What has been learned from this analysis are better techniques for recognizing API hashing and methods of analyzing shellcode effectively and promptly.
💬 Comment: