Dissecting Payload Injection Using LLama Process Snapshots

In our last blog-post on process snapshotting, we showed how process snapshots (or “dumps”) allow bridging the gap between dynamic and static analysis. In this post, we want to continue along this line and describe a related problem security analysts face: Analyzing code injections in analysis tools such as IDA Pro.

Injected code is particularly tedious to analyze when working on traditional program dumps. The reasons for this are manifold: The injected code is not part of the process image and thus hard to locate, parts of the memory used by the payload might no longer be resident in memory at the time of the snapshot, recognizing addresses of API functions is painful and error-prone, just to name a few.

Not when using LLama process dumps!

As we will show in this post, the high-resolution dynamic analysis engine automatically finds all code-regions related to injected code. It keeps track of memory blocks allocated by the untrusted code running in the target process, and includes them in the process dump for later analysis. Last, unrelated code-areas (for example unmodified, trusted code of the process that the malware injected into) are removed from the process dump, making it small and straight-forward to analyze.

LLama versus Shiz

Just like our previous post, we show how our process snapshots guide the analysis by looking at a concrete malware family:

Malware Family: Trojan.Win32.Shiz
md5: 09c98a1ecd554e2f8cec98b314335e3d
VT link: https://www.virustotal.com/en/file/377f6d302fbe45823b3e8c88319a31b8128ab23c74c691b59d33f13fbf98a225/analysis/
Full analysis result link: https://user.lastline.com/malscape#/task/f48cefc3253c40e6abd6e3da86aed508
(accessible to Lastline customers only, sign-up now)

Let’s start with an overview of the behavior extracted during dynamic analysis:

High-resolution analysis report overview

What is particularly interesting is the code injection into the Explorer.exe process as shown in the analysis report details:

The analyzed program injects code into Explorer.exe process

From the context of Explorer.exe, the injected code then propagates itself to a number of other processes running on the system as can be seen in the analysis subject overview:

Propagating payload from Explorer.exe into all running processes

Clearly, the injected data is very interesting for further analysis, since it could contain a lot of valuable information such as C&C endpoints or URLs, malware configuration files, password lists used for brute forcing, and much more. So let’s have a look at the process dumps provided by the dynamic analysis run:

Process Dumps generated during analysis of Trojan.Win32.Shiz

Dissecting Shiz

Let’s continue our analysis by looking into one of the process dump for the second analysis subject - the Explorer.exe process with injected code. More precisely, let’s dive into the snapshot taken on invocation of an API function from an untrusted memory region.

Upon opening and processing the snapshot (see last blog-post for details), IDA display the list of interesting code locations exposed by the processing script:

IDA showing code locations of interest

Now let’s look into these points of interest a bit more closely:

• 0x03cc1360 is the originally injected, position-independent code. What’s interesting about this code is that it uses hashed names (highlighted in orange) of API functions to call system APIs
  
  

• 0x03cc2000 points to a PE image embedded in the target process. Although the malware did not load this memory as library, it can still be used by the injected code, which makes it very interesting for analysis and is thus exported.

• 0x03e921c0 is the entry point to a PE image loaded by the position-independent shellcode. Unlike in the previous entry, the injected code uses the Windows API for loading the code.
  
  
  If we jump to the definition of function sub_3e92500 we find the logic for injecting code into the remaining processes running on the system (as described above).
  
  A quick analysis using the Hex-Rays decompiler (often integrated in IDA Pro)  immediately reveals very interesting behavior, such as the processes targeted (including Chrome, Opera, and Internet Explorer browsers):
  
  

• 0x03e8671b and 0x03e8f3a5 are return addresses from system call invocations showing C&C related functionality of the malware sample. The sample uses a domain-generation algorithm (DGA) to contact the attackers server and then posts data via HTTP
  
  

  
  

  Network traffic generated by the injected code
  
  

  :
  
  
  

Conclusion

This blog post shows how to use process snapshots generated during dynamic analysis to get detailed information about the internals of malware making use of code-injection using a couple of easy-to-follow steps. Even without any debugging, it is possible to do in-depth analysis of the even complex malware variants.