Skip to main content

Basic Dynamic Analysis - PE

As mentioned in my prior post (Medium / StillzTech), malware analysis can be grouped into four categories:

  • Basic Static 
  • Basic Dynamic - PE File (what this post will cover)
  • Advanced Static
  • Advanced Dynamic

As stated in my prior post, we perform basic static analysis first to understand the executable’s “potential” capabilities and structure. Some questions we aim to answer during basic static analysis:
  1. What libraries does the PE file import, including functions / ordinals?
    • Why? This may indicate the file has the “capability” to log to a text file and read credit card track data from memory, indicating you’re dealing with some point of sale malware.
  2. What unique strings stand out?
    • Why? Some malware may contain the PDB file (debugger symbols) or original code file path, which can be used to find related malware or identify the malware itself.
  3. What language was the PE file written in?
    • Why? Depending on the language the executable was written in, you might be able to reassemble the source. Languages like AutoIT and Py2Exe for example have tools openly available to aid in these efforts, making analysis significantly easier.
  4. Is the executable packed?
    • One of the most commonly used packers, “UPX”, is normally easy to identify and unpack, while other packers and crypters can make both static and dynamic analysis much harder. Knowing what packer you’re dealing with and how to defeat it will lead to better static/dynamic analysis results.

For this post, we’re going to cover some basic dynamic analysis tools and techniques. If you need a recap on setting up a lab VM, check out my posts below before continuing:
When performing dynamic analysis, we execute the binary in a monitored environment and observe the executable’s behavior, including but not limited too:
  • Registry operations
  • File operations
  • Network activity
  • Process operations
    • Cross process (e.g potential injection or reading the memory of another process)
    • Children processes
  • API calls (if possible)
  • Module loads

As a side note, we’re using “Host Only“ networking, meaning the sample will have no internet connection. The environment can only communicate to other systems in the “Host Only” network. While this is a safer setup, you will encounter malware that needs either simulated (FakeNet), unattributed (TOR or related proxies) or direct internet access (dedicated dirty internet line or mobile network). Case in point, some samples check for internet connectivity by attempting to connect to sites such as “canhazip”. 

For this scenario, we’re going to use the monitoring tools below to aid in logging some core aspects of a binaries behavior during execution:

Process Explorer:

Process Explorer is a process monitoring utility that is similar to Windows Task Manager. Using this tool will allow us to visually watch the malware execute, observe process parent / child hierarchy, and inspect additional properties of the process such as loaded DLLs, mutants, and file handles. I also recommend familiarizing yourself with the SANS poster below if you’re unfamiliar with common Windows process and their attributes. This is important to understand, as a lot of malware families will disguise themselves as legitimate Windows processes, inject into legitimate Windows processes, or get called/loaded by legitimate Windows processes such as Windows services or WMI. 

To begin using Process Explorer, right click on the application and select “Run as administrator”. When running Process Explorer, I normally configure two additional settings:
  1. Set Difference Highlighting Duration to 9 seconds. We set this to 9 seconds so we can slow things down a bit in the UI for processes that may start/stop rapidly. By default, the highlight duration is 3 seconds, which means if the process stops/starts quickly, Process Explorer will likely not show the process at all in the UI.
    • “Options” > “Difference Highlighting Duration...” > 9

  1. Set lower pane to viewing “Handles”. I usually select this option to casually look for what files a process may have open or any unique looking mutants and semaphores.
    • “View” > “Lower Pane View” > “Handles”

With Process Explorer running, let’s check out some other features we may use when inspecting live malware: the first feature is “strings”, found by double clicking any process. This action will result in a popup window with the title of “ Properties”. In this Window, you’ll see many tabs, including “Strings”. Assuming you’re running Process Explorer as administrator and have rights to view the process, you should see something similar to the image below:

You will see two radio buttons on the Strings tab. The Image radio button means the strings are shown as the file exists on disk, while the Memory radio button show strings as they exist in the processes memory. 

When dealing with malware that is compressed, obfuscated or encrypted, you may be able to simply run the malware and view its strings in memory to gain further insight into its capabilities. Depending on the malware, you might be able to “suspend” it during runtime to view some contents in cleartext. While you can randomly suspend the process at runtime, the best way to determine when to suspend a process is to attach a debugger to it and add breakpoints when API calls such as “VirtualAllocEx” or “WriteProcessMemory” are called. We will dig into this more in the next post “Advanced Dynamic Analysis”. To suspend a process with Process Explorer, right click on the process in Process Explorer and select “Suspend”.

The image below shows how viewing a processes strings in memory during runtime may yield more strings when compared to the strings of the executable on disk. You can quickly tell our sample is packed with UPX (, a common packer used for both legitimate and malicious purposes. Packing an executable is used by developers to compress an executable, keeping its size small for deployments. However, UPX is also used by malware authors as a way to conceal strings and other attributes about its payload.

Let’s take a look at how UPX impacts the strings of a sample before and during execution. The image below shows the strings of a UPX packed sample on disk (not running). We can see our DOS header string `!This program cannot be run in DOS mode.” followed by our PE section names “UPX0” and “UPX1”.

As you scroll through the strings on the “image” radio button, you’ll notice very few, if any human readable strings. A second thing we can do is load our executable into another tool called CFF Explorer and inspect the executables import table.

We can see from the image above, the PE file only imports two libraries, one of which is kernel32.dll and two of its functions: LoadLibrary and GetProcAddress. These functions are used to dynamically load new modules into memory. To confirm this, let's look at the loaded libraries AFTER execution and compare them to the image on disk. Two quick ways to do this are:

Option1: View the DLL’s in Process Explorer (View -> Lower Pane > DLLs): Once the executable runs, we can see all of the loaded DLLs in the lower pane.

Option2: View the loaded DLLs in a debugger
While this step is a bit more complex, we can attach a debugger to an already running executable and inspect its loaded DLLs. We can do this by running the debugger OllyDbg and going to File > Attach in the toolbar and selecting our running process from the list. Once loaded, goto View > Executable Modules from the toolbar or use the hotkey (Alt + E). this will bring up the list of executable modules. We will get into more OllyDbg in the next post (Advanced Dynamic Analysis).

In summary, what's happening is the packer (UPX in our case) is decompressing the actual malware in memory and resolving its dependencies so the malware can execute properly. Many other packers exist in the wild and many perform checks such as:
The common goal of these checks is to confirm the target being infected is a legitimate target or to make analysis difficult for malware analysts. 

Process Monitor:

Process monitor or Procmon, is another tool from SysInternals that captures activity such as registry, file, network and other process/thread related data points during process execution. To begin, open the application and go to “Filter > Filter…” (CTRL + L). This will open up the filter window. From here, we need to configure procmon to limit data capturing to only the name of our executable (evil.exe). The image below outlines the fields to set for targeted process capture. 
Now that our filter is set, we can execute our malware and watch the events populate in procmon. After filtering down the events to only file system activity, we can see our malware creates the file “autobat.exe”  on the root directory of “C:\”. The image below outlines the filtered events associated with this file create.

Another method to view file system activity is using “File Summary”, found at “Tools > File Summary…”, shown in the image below:

We can see in the file summary pane how many bytes this executable is (49 bytes to be exact).

This is only one example of how we can use procmon to extract process activity during execution. The same pivot we did with file system activity can also be done with registry, network and other process metadata. 

API Monitor:

Since we’re on the topic of viewing a file creation, let’s take a deeper look into how the file “autobat.exe” was created using “API Monitor”. API Monitor is similar to Process Monitor, but allows more visibility into API calls and filters. The key point here is to understand, at a Windows API level, which WinAPI’s are called to create the file “autobat.exe”. Using a tool like API Monitor allows us to view all the WinAPI calls made during the malware execution and inspect the API parameters. Once you have API Monitor running (as Administrator), you will see an “API Filter” pane in the top left of the application window. To limit the level of noise collected, we will configure our API monitoring to Kernel32.dll and select all categories. Since we’re not sure what API will be used to create the file, we will start by casting a wider net of API calls to monitor within Kernel32.dll, with a goal of filtering down the noise once we find the API call we’re interested in. The image below shows our current API filter.

Next, we need to run the malware to view the API calls captured. We do this by clicking on “File > Monitor New Process” (Ctrl + M). When the “Monitor Process” window is shown, we place the full path of the executable in the “process” field and click “Ok” to run the malware. Once running, you should see the following image below in the “Monitored Process” pane: 

We click on the main thread and inspect the summary pane for any file creation events. 
 Processes can have many threads or child processes. You should explore each thread and its children processes when analyzing a sample to understand each object’s purpose. In some cases, one thread could be responsible for keylogging while another thread is responsible for beaconing to the attacker’s C2 server. 

Furthermore, we can inspect the details of these parameters by clicking on the row and viewing the “Parameters” pane, as shown below.

It’s important to note that “CreateFileA” in this API call isn’t responsible for writing the bytes to disk. It’s only attempting to obtain a handle to a file. You may have noticed from the image above that the “Return” value is “INVAILD_HANDLE_VALUE”. This is because the file doesn’t exist on disk yet, so no handle can be obtained. The malware does this as a check before creating the file. We can see immediately after the failed call, the malware calls “CreateFileA” again, this time with the “dwDesiredAccess” set to “GENERIC_WRITE“ versus “GENERIC_READ” we previously observed:

Now that we have a valid handle to the file “0x000000fc” (virtual memory address), the malware should write data to it. Upon further review of the “Summary” pane, we see immediately after obtaining a handle, a call to “WriteFile”. Again, we can repeat the same process we did above to inspect the parameters of this API call. Hovering over the call will show the overview and clicking on the API call will allow us to inspect the parameters:

We can see the parameter “hFile” is set to our file handle obtained by the API call “CreateFileA” (0x000000fc), the total number of bytes (49) and the “LpBuffer” value shown below in hex:

While the file is called “autobat.exe”, we can confirm this binary is not a true windows executable, as the first two bytes are “68 74”. The magic header of a PE file begins with “4D 5A” (MZ). In fact, if we inspect the hex, we see the first few bytes “68 74 74 70” translate to “http”.

While we only focused on small aspect monitoring windows API calls, understanding common Windows APIs used by malware can be very useful to uncover a malwares objective. The best advice here is to practice by gathering recent samples from some of the sites listed here ( 

In the next blog post, we will build upon our API monitoring example here and dig into more advanced dynamic analysis topics such as breakpoints, tracing, process memory and other techniques performed by malware analysts in the field. 

Check out more of my blog posts here: or drop me a note if you would like to recommend a topic.

Samples used in this post are found in: I also recommend checking out the book “Practical Malware Analysis” here:


Popular posts from this blog

Analyzing and detecting web shells

Of the various pieces of malware i’ve analyzed, I still find web shells to be the most fascinating. While this not a new topic, i've been asked by others to do a write up on web shells, so here it is ;).  For those new to web shells, think of this type of malware as code designed to be executed by the web server - instead of writing a backdoor in C, for example, an attacker can write malicious PHP and upload the code directly to a vulnerable web server. Web shells span across many different languages and server types. Let's take a looks at some common servers and some web extensions: Operating System Service Binary Name Extensions Windows IIS (Internet Information Services) w3wp.exe .asp/.aspx Windows/Linux apache/ apache2/nginx httpd/httpd.exe/nginx .php Windows/Linux Apache Tomcat* tomcat*.exe/tomcat* .jsp/.jspx Web shells 101 To better understand web shells, let’s take a look at a simple eval web shell below: <?php

Web shell hunting: Meet the web shell analyzer

 In continuation of my prior work on web shells ( Medium / Blog ), I wanted to take my work a step further and introduce a new tool that goes beyond my legacy webshell-scan tool. The “webshell-scan” tool was written in GoLang and provided threat hunters and analysts alike with the ability to quickly scan a target system for web shells in a cross platform fashion. That said, I found it was lacking in many other areas. Allow me to elaborate below… Requirements of web shell analysis In order to perform proper web shell analysis, we need to define some of the key requirements that a web shell analyzer would need to include. This isn’t a definitive list but more of a guide on key requirements based on my experience working on the front lines: Static executable: Tooling must include all dependencies when being deployed. This ensures the execution is consistent and expected. Simple and easy to use: A tool must be simple and straightforward to deploy and execute. Nothing is more frustrating

Apache log analysis with Sublime Text 3

Analyzing log files is generally a tedious task, especially when you are hunting for anomalies without an initial lead or indication of evil. Trying to remove all the legitimate entries while leaving the malicious entries requires not only knowledge of common attacker techniques and understanding patterns but a flexible tool. In this post, we’re going to cover analysis of Apache Tomcat access logs and Catalina logs using a text editor called “Sublime Text 3” ( ). The Scenario To make things semi-realistic, i’ve deployed Apache Tomcat on top of Windows Server 2012 with ports 80,443 and 8080 exposed. For now, we’re not going to deploy any apps such as WordPress, Drupal or Jenkins. In our scenario, the customer (who owns this Tomcat server) has tasked our team with analyzing both the Apache and Catalina logs to help identify some suspicious activity. In many real world cases, web applications are usually in a DMZ on their own, behind a load balancer,