Whoa! The Sample Refuses to Run!

A lot of these dependencies, frameworks, environments needed by a sample to run can be figured out from the static analysis phase. Once we figure out these missing dependencies and install and set them up, the sample runs as expected.

Keep in mind is that when PE Executable samples fail to run, the easiest way to figure out the issue is to run the sample using a debugger like OllyDbg. Using a debugger helps you figure out the issue very quickly and efficiently, saving your precious time. You don’t have to be a super reverse engineer to use OllyDbg or any other debugger. You learn more about using OllyDbg and the reverse engineering process in Part 4 of this book.

Run as Administrator or Not

By default, if you double-click any sample on the system, it runs as a non-administrator, with fewer privileges, functionalities, features available for the running process. Some malware requires administrator privileges to perform certain operations that require special privileges. For example, if malware wants to copy a file into the protected OS system folder C:WindowsSystem32, it needs administrator privileges.

While running any malware sample, you want to test it by running both with and without administrator privileges. Start by running it without administrator privileges, which is easy to do, since all you need to do is double click.

Reset your VM and run the sample as an administrator, which you can by right-clicking the sample and selecting Run as an Administrator.

Each of the scenarios might provide different sets of events and behaviors for the running malware process, which you may not see with the other, and the difference might be crucial in your figuring out if the sample is malicious or not.

Now let’s play with some hands-on exercises that involve real malware samples and see how having a casual eye on the execution of the sample is all that we need most of the time to conclude enough about a sample.

Case Study 1

Let’s start with Sample-13-1 from the samples repository, to which you can add the .exe file extension. In the samples repository, it is named Sample-13-1.txt because it is a text file that holds the instructions that you need to follow to download the real malware sample. Don’t run the sample yet. Start Process Hacker and open the folder that holds the sample file, which should look similar to the left side of Figure 13-1.

Now that you have that in place, run the sample. A new process called svchost.exe opens, as you can see on the right side of Figure 13-1. This is suspicious, and from what we have covered so far in this book, it points to malware-related behavior, where malware uses system programs like svchost.exe for stealth (see Chapter 11) using code injection/process hollowing (see Chapter 9).

Our new svchost.exe in Figure 13-1 doesn’t have services.exe as its parent, as confirmed from the left side of Figure 13-2. Combine all the things we observed visually, and they all point to Sample-13-1 being malware. Now reset your VM, re-run the sample as an administrator, and observe how it behaves to see if there is a difference.

Case Study 2

Let’s now play with Sample-13-2, to which you can add the .exe file extension. In the samples repo, it is named Sample-13-2.txt because it is a text file that holds instructions that you need to download the real malware sample. Don’t run the sample yet. Start Process Hacker and open the folder that holds the sample file, which should look similar to the left side of Figure 13-2.

Now that you have that in place, run the sample as an administrator by right-clicking it and selecting Run as an Administrator. A new process called SVOHOST.EXE pops up, as seen on the right side of Figure 13-3. Sample-13-2.exe is deleted from the disk.

Both symptoms are suspicious. The name of the new process SVOHOST.EXE is suspiciously similar to the OS process svchost.exe, which is like the psycholinguistic technique, a stealth technique explained in Chapter 11. The deletion of the executable file on the disk is also a classic technique used by a lot of malware, which we explain later in the chapter.

Now let’s check the properties and see if we notice anything. In the properties seen in Figure 13-4, we notice that the executable file from which the new process SVOHOST.EXE is created is located at C:WindowsSystem32SVOHOST.EXE. You can go back to a pristine system, or use your own experience, but there is no system program located in C:WindowsSystem32 that is called SVOHOST.EXE.

All the observations made so far—both visually or through some minor inspection—all but point that the sample is malicious.

Case Study 3

Let’s now play with Sample-13-3, to which you can add the .exe file extension. In the samples repository, it is named Sample-13-3.txt because it is a text file that holds the instructions that you need to follow to download the real malware sample. Start Process Hacker and open the folder that holds the sample file, which should look similar to the left side of Figure 13-5. Notice that we have some dummy PDF (.pdf) and Excel (.xlsx) files in that folder. This is part of the process where we want our analysis VM setup to look and mimic a regular victim’s machine, also explained in Chapter 2.

Now that you have that in place, run the sample. What do you see? From the right side of Figure 13-5, we see that suddenly all the files have been modified and a .doc file extension added to them. We also see a new file created in the same folder called Read___ME.html. Both indicators point to the Sample-13-3 being ransomware.

The newly created Read___ME.html is an HTML file. Opening it confirms that we have ransomware, as seen in Figure 13-6.

These exercises taught that by casually running a sample and viewing its behavior and properties from a high level without using complex analysis tools, you can typically conclude whether a sample is malware or not, and in some cases, classify the type of malware.

Classify the Malware Family

Let’s take this mutex name and search for it on the web via Google. In Figure 13-9, there are analysis reports for other malware samples belonging to the same family that creates the same mutant, and it identifies the malware family as kuluoz and the category as Botnet. Voila! We were not only able to conclude that it is malware, but we also determined its family and type.

As an exercise, go through the API logs of various other malware samples, including Sample-13-2 and Sample-13-3. Note that we mention the most basic Win32 APIs used by malware throughout various chapters in this book. But the APIs that we listed are not extensive. As you analyze new categories of malware that carry out their dirty work through various sets of Win32 APIs that have never used before by other malware you have seen before, make a note of these API sequences so that you can use them to detect and classify other malware in the future.

File Type

Checking the file type of Sample-13-4 reveals it to be a .NET file type, as seen in Figure 13-10. A .NET sample requires the .NET Framework to be installed to successfully run the sample. But just any framework won’t do. Specific .NET versions require their corresponding .NET frameworks or greater in some cases. If you don’t have the requisite framework installed, the sample may not run.

In our Windows 7 analysis VM, it is fully updated. It installs the latest .NET Framework, which proves to be enough to run the sample, as you see later on. But if you are unable to run the sample, verify if you have the .NET Framework installed and, if so, check if it is the right version.

Version Information/Details

Let’s check this sample’s properties and details. Refer to Chapter 12 for more information on what we can infer from it. In Figure 13-11, the various fields hold values that look like junk, unlike clean programs that hold legible values for their Product name, Copyright, Original Filename, and File description. This points to show that the sample is suspicious and warrants further investigation.

Packed or Unpacked?

The first step in the string analysis is to figure out if it is packed or not. We covered this in Chapter 7, where we had three main methods to identify if a sample is packed: entropy, static observation of strings in the file, and dynamic observation of strings in memory.

Entropy Check with PEiD

PEiD is a great tool that can provide you the entropy of the static file using which you can figure out if the sample is packed or not. Refer to Figure 7-8 from Chapter 7 on how to use PEiD to extract the entropy of a file. In Figure 13-12, the PEiD reports that the entropy is 7.62 and packed. Job done!

Static Observation of Strings in File

Using entropy, we established that the sample is packed. Going through the strings statically using BinText shows us that the sample is indeed packed, as seen through the various junk strings in Figure 13-13. We were hoping that some stray strings in there are still unpacked and reveal something about this sample. But we are out of luck here, and we must rely on dynamic string analysis.

Dynamic Observation of Strings in Memory

Now that we have established that the sample is packed, let’s see if the sample unpacks in memory and if so, the memory holds any deobfuscated strings that can reveal to us more information about this sample. We have established that the sample is suspicious. Run the sample by double-clicking it. Using Process Hacker, it creates a new process called coherence.exe, as seen in Figure 13-14.

Using Process Explorer, open the Properties for this process coherence.exe and click the Strings tab. You can also refer to Figure 7-12 from Chapter 7 on how to use Process Explorer for this. In Figure 13-15, which compares the image/memory strings, you can see new deobfuscated strings, which you previously couldn’t see statically, indicating that it is indeed unpacked in memory.

Let’s dig through these strings in memory and see if we can conclude anything from it. Now let’s continue to observe the strings in Process Hacker instead, although we can also do the same using Process Explorer. Refer to Figure 7-14 and 7-15 from Chapter 7 on how to use Process Hacker to view the strings. In Figure 13-16, you can see various strings that hint at the kind of malware we are dealing with.

What do you think we can infer from these strings? Go through the strings slowly, taking your time. Do you notice a lot of strings referring to Username and Password, in combination with various protocols, like SMTP and POP, and various tools, like Filezilla and Internet Explorer? This refers to a category of malware called InfoStealers that tries to steal credentials from various tools that the users use.

Now that we have established the type of malware as InfoStealer, let’s see if we can figure out the exact family/name the malware belongs to. Go through the strings slowly again and search for some weird names that look different and yet have some meaning to it (you need a lot of patience for this). Among all these strings, there is a string YUIPWDFILE0YUIPKDFILE0YUICRYPTED0YUI1.0, which is very weird looking but at the same time has a structure with words like CRYPTED and FILE0. Searching for this string on Google points to many analysis reports for other malware samples belonging to the same family as our sample, such as Pony Loader or Fareit, as seen in Figure 13-17.

AutoRuns

Since the malware sample creates a RUN persistence entry, let’s verify with the AutoRuns tool if this persistence RUN entry still exists. As you can see in Figure 13-20, it does pick it up—double confirmation. Yay!

Continuing with our analysis process, now let’s search for some process events. Figure 13-21 shows that Sample-13-2.exe creates a new process for the file it created earlier, C:WindowsSystem32SVOHOST.EXE.

Combined, there are enough indicators to conclude that Sample-13-2.exe is malware. We can continue with our event analysis by going through the events of SVOHOST.EXE, which is a child process of Sample-13-2.exe. We leave that as an exercise for you.

We have covered the various basic dynamic analysis power tools. In the next set of sections, let’s go through other tools and other malware properties and dynamic events that we can extract in combination with the basic dynamic analysis tools to draw a conclusion on the sample we are analyzing.

GMER and Ring3 API Hook Scanner

At this stage, let’s assume you have figured that the malware sample carries out code injection. Not every code injection technique indicates that the malware intends to do API hooking or is trying to use rootkit functionality. But it is a high possibility at this point that one of the intentions of the malware might be API hooking or rootkits. At this stage, it is best to run tools like GMER and Ring3 API Hook Scanner, both of which can easily tell you if any APIs have been hooked and if a rootkit has been detected. For more on this, you can refer to Chapter 10 and Chapter 11 for rootkits.

Stealing System File Names for Stealth

We covered stealing system file names for stealth in Chapter 11. In this technique, the malware uses the names of various OS system programs to name their malware files and processes in a bid to fool users into thinking they are clean OS programs and processes.

This mechanism of the malware can easily be noted by casually observing its behavior, the path of the process’s program file on disk, and other process properties by using tools like Process Hacker and Process Explorer.

Weird File and Process Names

We covered weird file names and process names in Chapter 11. With these techniques, malware uses enticing and misleading names to fool the user into clicking its files or ignoring process names in Task Manager.

This mechanism of the malware can easily be noted—first, by a good dose of common sense, and second, by having good knowledge of what normal programs and processes are named on your clean system. If you know how most OS system programs and processes are actually named, this will help you catch anomalous files and process names that look similar to the real ones.

ProcMon, APIMiner, Process Hacker, and casual observing file and process properties using a file browser are easy ways to obtain malware-event information, on top of which you can apply your common sense to catch anomalous behavior.

Disappearing Executable

A very common mechanism used by most malware is to copy itself to another location and then delete its program file on disk. You saw an example of this in Figure 13-3.

This malware technique easily pops up in the file browser if you casually observe its behavior when you run it. Similarly, ProcMon catches the event when the file is deleted. APIMiner catches the same events through CopyFile() and DeleteFile()Win32 API calls.

Number of Process Instances

Malware has a habit of using OS program/process names for its programs/processes. But we can catch this malware technique by exploiting the fact that there are only a certain fixed number of OS system processes that run at an instance of time. We see more processes than the fixed number for that OS system process name, and we can conclude we have something malicious going on.

We talked about this in Chapter 5. This technique can be easily caught by a tool like Process Hacker by casually observing the name of every process created when you run your analysis sample. If the newly created processes have a system program/process name, manually counting the number of instances with that process name.

Process Session IDs

Malware often names its programs/processes after OS system programs/processes. But most OS system programs run under session 0, as you learned in Chapter 5.

We can easily catch this malware behavior using Process Hacker by casually observing the name of every process created when you run your analysis sample. If it has a system program/process name, and verify if its session ID is 0 or not.