Working in infosec and supporting clients and SOCs has always exposed me to a huge number of alerts and incidents. Some of these are more interesting than others. Recently we stumbled across a particular sample of Smoke Loader malware. Smoke Loader has been in-the-wild since circa 2013 and is often used to distribute additional malicious components or artifacts. While the sample is not new, it did prove to be a good opportunity to revisit this threat and walk through some of the internals. This alert was raised against a suspicious file, classified as a trojan, that was killed and quarantined. What raised my curiosity was the number of detections over only a few hours, always from the same workstation, and only from the same user. Knowing that the threat was killed without doing any harm, I decided to dig into it a bit more. Just looking at the SentinelOne console, I was able to see : The full path where the detection was made. The associated risk level is High: this implies that it’s a positive detection. File unique hash that can be tested for any public Indicators of Compromise (IoC). In order to do a walk-through of malware reverse engineering steps, I downloaded the threat file and started the analysis. First Layer: A Packed VB Win32 Program With the downloaded file in my pocket, I quickly fired up an isolated analysis machine equipped with the Flare tools and started to investigate. At first glance, the sample appears to be a Visual Basic program leveraging Win32 APIs. Let’s see what else we can get from its headers. Looks like pretty standard information, confirming a Visual Basic program due to its import table. We can spot some rude and folkloristic words inside the binary strings, some of which make me think of a regional dialect of southern Italy. With a bit of experience, we can safely assume that the file is packed with an external layer of Visual Basic that tries to stop, or at least slow down, static analysis. But what about its runtime behavior? Observing the sample during runtime, we can observe the process injection: this behaviour is common for VB packers and luckily for us, is often trivial to defeat. Defeating Visual Basic Packer We won’t spend too much time on this: there are plenty of resources on how to unpack such packers and I highly recommend the OALabs Youtube video tutorials . It’s necessary and enough to put a breakpoint at CreateProcessInternalW API inside the debugger to stop the execution at the right time. At this point, somewhere in memory, there is a PE file ready to be run. We only need to find it. To do so, we can search the entire memory map for a clue: I decided to search for the “ DOS ” substring that can usually be found as part of the “ This program cannot be run in DOS mode ” string within the PE. We got plenty of results for the string, whose hex is 44 4F 53. However, we are particularly interested in just a few locations. Usually the executable is loaded at 0x00400000 address, so the result we had at 0x0040006C looks like our executable itself. Things become particularly interesting at 0x002F0094, which we can follow in the memory dump. A memory region with a PE file inside, mapped as Executable, Read, Write. This is definitely our injected file. We can simply dump out this memory region to file, clean the junk before the MZ header and analyze its headers. It seems like a legitimate executable, but something is going on: no imports at all. This is interesting! Second layer: Static Analysis When we load this new executable in IDA Pro, this was the only chunk of code that was disassembled. Here we recognize that it’s a XOR loop that will decode, from address 0x00401567, a blob of code with the size of 0xCD bytes with a XOR key equal to 0xCB. At the end of the loop, the same starting address 0x00401567 is pushed onto the stack and with the RET instruction the program flow will be branched over there. Decoding the Buffer With a little bit of IDA scripting, we can XOR the encrypted buffer and move forward in the analysis. After de-xoring the buffer we are met with a mixture of anti-disassembly and anti-debug techniques. It is now possible to map the purpose of the code blocks. Inside this code, we can observe plenty of tricks that try to fool the disassembly flow. A few examples: Abusing CALL and RET instruction to mess up function boundaries. The CALL instruction will push the return address onto the stack. The RET instruction will then pop off this address into the EIP register, which effectively makes these two instructions useless. However, these few opcodes make IDA think that the function ends there and that the next instruction is the end of another function. Abusing branch instructions that do nothing: CALL

and at

: POP . It’s the easiest way to get an address inside the EIP register and so to control the program’s flow. Abusing JMP instructions: simply putting a lot of JMP instructions that will jump back and forth only to make the life of the analyst miserable. Obfuscated with these techniques, the malware checks if it’s being debugged. The code that implements this check is nothing complicated: it queries certain flags of the PEB in order to spot the debugger, IsDebuggerPresent. mov eax, fs:[30h] ; Process Environment Blockcmp b [eax+2], 0 ; check BeingDebuggedjne being_debugged As said, this code is heavily obfuscated with junk jumps and a lot of instructions with the only purpose of increasing complexity of analysis. As an example, this little chunk of code is the final part of a dozen lines of code used to put value 0x30 inside the EAX register with the purpose of locating the PEB. At the end of this function, we spot another XOR stub decoding routine that will decode another blob of code and, after that, redirect the execution flow. Decoding will start at address 0x004014E8, with a buffer size of 0x7F and the same XOR key 0xCB. As before, we can proceed in the static analysis, manually decoding this buffer with the same script. But wait! Here we go again, another anti-debugging trick, NtGlobalFlag check: mov eax, fs:[30h] ; Process Environment Blockmov al, [eax+68h] ; NtGlobalFlagand al, 70hcmp al, 70hjebeing_debugged This chunk of code checks if the process is attached to a debugger and, if it goes well, another XOR decoding stub starts from address 0x00401000, with buffer size 0x4E8 and XOR key 0xCB. After decoding the new buffer, we need to face another anti-disassembly trick; namely, JMP instructions with a constant value. This is the most common trick used by malware to fool static analysis. Basically, it creates jumps into a new location plus one or a few bytes. It results in an erroneous interpretation of the opcode by the disassembler. It’s trivial to defeat…

Mario Ciccarelli

Blog posts by Mario Ciccarelli

Smoke Loader Malware - An Easy Guide 101