Windows PE Malware Analysis Part I

Introduction

In this article I will be examining a Windows executable malware specimen. Based on a couple reports from automated malware sandboxes, the specimen drops multiple files to disk and calls out to multiple domains and IP addresses.

The purpose of this article is to give readers a look into malware reverse engineering using static analysis, behavioral analysis, and code analysis. This is Part 1 of several more articles to come.

The specimen in question is a Windows PE (Portable Executable) named setup.exe. You can find it's hashes below.

MD5: d1b2c8ddca2f8dd02e2c132153055084

SHA-1: 21c011ac7406eef048c175f5887e4eb885c050d6

SHA256: 506c2f513d64242fcb20ccff8c26c0ed1755fe9120b984c29ba224b311d635c3

I pulled this malware from Any.Run which contains nearly 75,000 malware samples at the time of this article. This particular specimen was uploaded on October 29th, 2021; however, the earliest upload was on October 21st, 2021.

VirusTotal shows 47 out of 68 vendors have flagged this as malware and the last analysis ran was October 28th, 2021. You can see some of the features that VirusTotal identified such as detect-debug-environment, direct-cpu-clock-access and long-sleeps.

VirusTotal also displays that the creation time of this malware was October 18th, 2021.

Over the course of this series, rather than simply relying on automated sandbox analysis, let’s take a deeper look at what this malware does and try to identify some characteristics such as:

• Obfuscation
• Anti-reverse engineering
• Command and Control
• Encryption

…and more.

Environment

I will be using two virtual machines to complete my analysis. The first is a REMnux Linux virtual machine and the other is the Windows based FlareVM by FireEye.

REMnux is an Ubuntu Linux machine that is pre-loaded with tons of malware analysis tools. It can also be installed through a script on any compatible version of Ubuntu.

FlareVM comes as a PowerShell script that utilizes the Chocolatey package manager for Windows to download all the necessary tools for malware analysis, incident response and penetration testing. This will require your own Windows virtual machine for installation.

Static Analysis

Usually, I like to begin with static analysis because it gives me a preliminary look at what to expect from the specimen. It is the easiest step of the reverse engineering process in my opinion since it requires very little setup.

Static analysis includes using tools like file, strings, pedump and disassemblers like IDA Pro by Hex-Rays or Ghidra by the NSA. For this step, I will be using the REMnux VM.

File command

First, I will run the file command to determine the architecture and confirm that the file is a Windows PE.

The results show that it is indeed a Windows PE, and it is of the x86 Intel architecture or a 32 bit program.

NOTE: Most malware is 32 bit to ensure it can run on both 32 and 64 bit systems.

PEdump

Next, I will run pedump to get a breakdown of the specimen's headers, imports, sections and more. Below is the output with some truncated lines.

Looking at the SECTIONS portion of the binary, we see that each section appears to be intact or normal looking, meaning there are no signs that this malware is packed. Typically, if malware is packed or compressed, the section names will be renamed to something different. For example, UPX, a common software packer, renames the headers to UPX0, UPX1, UPX2, etc.

If the malware were packed with UPX, it would look something like below…

The RESOURCES portion of the binary typically holds things like images and icons. In this binary, we see that there appears to be a DLL (Dynamic Link Library) at offset 0x37430. This is highly suspicious and typical of dropper malware.

The IMPORTS section of the output shows all the dynamically loaded Windows APIs or function calls that this binary uses. At first glance, it looks as if it only uses functions from kernel32.dll. There may be other function calls used that are statically linked. We can verify this later using another tool.

If we scroll down a bit on the imports list, we notice that this binary uses the API IsDebuggerPresent. This can be indicative of an anti-reverse engineering technique used by malware authors to prevent the specimen from being debugged. We can confirm this through disassembly and code analysis later.

There are many file manipulation APIs such as ReadFile, CreateFileA, and WriteFile which are potential indicators of dropper malware as well.

The last observation made from the pedump output is the PACKER / COMPILER subsection indicating that the specimen was compiled with MS Visual C++ v8.0. This version of MS Visual C++ came out in 2005 which makes it old.

If the malware were packed with UPX, this section would look something like below…

Strings

Running the strings command on the binary will output just over 4500 lines. We can confirm this with the command string Setup.bin | wc -l which will pipe the strings output into the wc (word count) command and filter based on the line count alone.

While it may be helpful to scroll through all the string output, having a targeted approach can help identify some more potential features of this malware.

For example, we can pipe our strings output into grep and filter out everything but our desired string. Below I have grepped for the string .dll to locate other potential DLLs in use.

The string ole32.dll seems interesting as this DLL is used for embedding hyperlinks and documents in programs. Other interesting DLL strings are user32.dll, gdi32.dll and gdiplus.dll which contain graphics and windowing APIs.

One hypothesis is that this malware masquerades as a legitimate program providing some form of a GUI (graphical user interface). We will be able to validate this during behavioral analysis.

Grepping for the string This program yields two DOS stubs which is not typical for a Windows PE. This could mean that there is another executable embedded in the original PE file that will be extracted and dropped to the filesystem upon execution. This also strengthens our hypothesis of the DLL found in the .rsrc section.

If we grep for the string http to find potential Command and Control nodes, we find a few URLs. One URL that stands out is https://github.com/ControlzEx/ControlzEx which is a GitHub repository for Controlz. Based on the README, it appears to be a .NET framework supporting UI (user interface) features.

If we look back at the strings output for DLLs, we notice that there is a ControlzEx.dll listed as well.

Some other strings we could search for would be domain names, anything related to encryption, and anything related to downloading.

PEsec

We can use the tool pesec to check the security features of this PE. This would be more useful for exploit development, but I like to check and see if ASLR (Address Space Layout Randomization) is enabled so I am better prepared when performing code analysis alongside a disassembler. If ASLR is enabled, I will rebase the binary's address in IDA Pro to match that of the running process. Based on the output of pescan, ASLR is enabled. We will save this info for later.

Part I Conclusion

In this article, we began our analysis with some initial recon of automated sandbox reports and then moved on to our own static analysis by identifying various header fields, sections, and imports. We discovered that the specimen is not packed, potentially uses various GUI DLLs, potentially tries to perform anti-debugging, and appears to contain a DLL in its .rsrc section which is highly suspicious. This is not an exhaustive approach to static analysis but it's a good start and introduction.

This concludes Part 1 of this series. Stayed tuned for Part II where we will disassemble the binary and perform analysis using IDA Pro.

Originally published at https://x0rb3l.github.io on October 29, 2021.