Comparative analysis between Bindiff and Diaphora - Patched Smokeloader Study Case

This article presents a comparative study case of diffing binaries using two technologies: Bindiff [1] and Diaphora [2]. We approached this topic in a Malware Analysis perspective by analyzing a (guess which malware family?) Smokeloader (! :D) campaign.

In August 2019, I spotted this campaign using patched samples of Smokeloader 2018 samples. This specific actor patched binaries to add new controllers URLs without needing to pay extra money (Smokeloader's seller charges extra-fee for C2 URL updates). This campaign was described in more detail in this previous article [3].

More details about the original samples [4][5] analyzed in this article can be found in the following tables:

Filename:	smokeloader_2018_unpatched.bin
Size:	33792 Bytes
File type:	PE32 executable (GUI) Intel 80386, for Microsoft Windows
md5:	76d9c9d7a779005f6caeaa72dbdde445
sha1:	34efc6312c7bff374563b1e429e2e29b5da119c2
sha256:	b61991e6b19229de40323d7e15e1b710a9e7f5fafe5d0ebdfc08918e373967d3

Filename:	smokeloader_2018_patched.bin
Size:	1202732 Bytes
File type:	PE32 executable (GUI) Intel 80386, for Microsoft Windows
md5:	7ba7a0d8d3e09be16291d5e7f37dcadb
sha1:	933d532332c9d3c2e41f8871768e0b1c08aaed0c
sha256:	6632e26a6970d8269a9d36594c07bc87d266d898bc7f99198ed081d9ff183b3f

The following tables hold details about the unpacked code dumped from "explorer.exe" used in this article [6][7]. 

Filename:	explorer.exe.7e8e32c0.0x02ee0000-0x02ef3fff.dmp
Size:	81920 Bytes
File type:	data
md5:	711c02bec678b9dace09bed151d4cedd
sha1:	84d6b468fed7dd7a40a1eeba8bdc025e05538f3c
sha256:	865c18d1dd13eaa77fabf2e03610e8eb405e2baa39bf68906d856af946e5ffe1

Filename:	explorer.exe.7e8df030.0x00be0000-0x00bf3fff_patched.dmp
Size:	81920 Bytes (yes, same size)
File type:	data
md5:	d8f23c399f8de9490e808d71d00763ef
sha1:	e1daad6cb696966c5ced8b7d6a2425ff249bf227
sha256:	421482d292700639c27025db06a858aafee24d89737410571faf40d8dcb53288

Summarizing the main changes implemented by this patch are: 

• wipes out the code for decrypting C2 URLs;
• replaces it with NOPs and hardcoded C2 URL string; and
• preserves the original size of decryption function to not disrupt offsets;

Figure 01 and 02 presents the graph of the original code. Figure 01 is the code used for indexing a table of encrypted C2 URLs payloads. Figure 02 lists the code used for decrypting the C2 URLs. This function is called in other parts of the code (not only by the function shown in Figure 01) - this is why they are not merged in one function. We labeled functions (e.g. "__decrypt_C2_url" and "__decrypt_c2_algorithm") in this assembly code to make it easier to read. 

Figure 01 - Original code used for decrypting C2 URLs.

Unpacking Smokeloader and Reconstructing PE Programatically using LIEF

This article holds notes on my experience unpacking a Smokeloader 2020 sample. The unpacked payload is further used for composing a valid PE file. The outcome is a PE32 executable containing clean code ready for reversing. 

First things first, here is the sample used in this research:

Size	308.17 KB (315568 bytes)
Type	PE32 executable for MS Windows (GUI) Intel 80386 32-bit
First seen	2020-03-06 21:45:11
md5	c067e0a2d7fc6092bb77abc7f7156b60
sha1	52f68073caec0fd424c7cbaaed5f5221d7103d20
sha256	25959cfe4619126ab554d3111b875218f1dbfadd79eed1ed0f6a8c1900fa36e0

You can find it in VirusTotal [1]. 

This sample does regular already documented Smokeloader checks before unpacking the main payload, such as: 

• checks if the process is running in the context of a debugger using "kernel32.isDebuggerPresent" function [2];
• makes a copy of ntdll.dll, loads it and uses it instead. This technique helps to evade some sandboxes and has been described already in this article here [3];
• looks for specific patterns in registry keys to check if the sample is running under a virtualised environment.

It also performs a small profiling of the hosting machine in order to decide which payload to inject. Smokeloader has specific code for both main architectures x86 and x64. In this article, we gonna unpack the x86 payload of the above mentioned sample. 

Smokeloader has been using various techniques to inject its final payload into the user file management process "explorer.exe". The sample analysed uses RtlCreateUserThread approach in order to copy the final payload to the targeted process. This injection method is better described in this Endgame/Elastic article [4].

So our game plan is: 

1. pause execution before the unpacked payload is executed by "explorer.exe";
2. transplant this code to a dummy PE shell;
3. fix PE header values and section boundaries;
4. patching Smokeloader code preamble;
5. test unpacked Smokeloader PE;
6. how to do all this programatically using LIEF [5].

1.0 - FETCHING MAIN PAYLOAD

Smokeloader 1st stage decompresses its payload using ntdll.RtlDecompressBuffer [6] after few anti-analysis checks described above. It does not call this function from the initially loaded ntdll.dll but from a copy of it loaded afterwards. So breakpoints should be set after the binary loads the copy of ntdll.dll. Figure 01 presents a screenshot of this specific code IDA.

Figure 01: Smokeloader first stage decompression code