Static Malware Analysis Lab

Static Malware Analysis is the process of examining malicious files or programs without running them. It focuses on analyzing the malware’s structure, code, and metadata to understand its functionality in a safe environment. Analysts inspect attributes such as file headers, hashes, strings, and imported libraries to identify indicators of compromise, detect obfuscation, and infer what the malware is designed to do. Tools like strings, PEiD, Ghidra, and IDA Pro are commonly used to extract readable text, view assembly code, and analyze binary structures for signs of malicious intent.

Unlike dynamic analysis, static analysis does not reveal real-time behavior but provides a fast and risk-free way to study the malware’s potential actions. It helps analysts classify threats, develop detection signatures, and determine whether the file belongs to a known malware family. However, it has limitations packed, encrypted, or obfuscated samples can hide their true purpose, requiring deeper reverse engineering. Despite these challenges, static analysis remains a critical first step in understanding and defending against malware.

Demo

In this demo I will walk through a simplified static malware analysis using fundamental Linux tools that provide actionable insights without executing the sample. The goal is to understand the file’s structure, capabilities, and any embedded indicators that point to malicious behavior. I’ll start by identifying and fingerprinting the file, then inspect its internal structure and human-readable content, and finally use online research as the last step to correlate findings with known threats.

I started my analysis by checking three fundamental details about the sample to establish a basic profile before diving deeper. First, I looked at the file extension, which turned out to be .exe, indicating that it’s a Windows Portable Executable (PE) file. We can already tell that this malware was made to run on windows system. We can also assume that this file is interacting with windows API calls, system processes and services. 

I examined the file size to get an idea of its complexity and structure. Which here we have a 76 bytes file size. Malware with unusually small sizes can sometimes be droppers or stubs that download larger payloads, while large files may contain packed, obfuscated, or multi-functional code.

I ran the file command against it, which confirmed the exact file type and architecture, PE32 executable(GUI) Intel 80386, for MS Windows .

This step can help me ensure, verify and understand what kind of file I’m dealing with and sets the direction for the next stages of static analysis methodology.

Cat-ing it out is not the best way to see the instructions inside of it, but a quick observation can tell us there is some software licenses, there is a webserver name with its version, the protocol used and its version aswell, which is probably how the malware was delivered. 

To better understand what is going on here, we are going to make use of the tool Strings.

We will also need to cleanup the output to something more human-readable. 

Using the " -n " switch by the strings utility it can help us to choose the minimum length of characters of each line in the output. 

 

A part of the output here can tell us the API calls that this malware is using, the DLL libraries included as well. This is very common in PE malware, you are free to look them up on google to see each one of them what it is about and what is the use case of each in a PE malware. 

As an example we can see WSOCK32.dll which is a Windows Winsock networking library that exposes TCP/IP/Sockets APIs to Windows programs. and it has many functions that defines how a TCP connections are opened.

Therefore, this can inform us that this malware is using networking capability and possibly connecting to a C2 server, maybe its going to download additional payloads, exfiltrate data...etc 

To go off from here we will need to look for URLs, IPs, the rest of the imported functions related to it, look for evasion techniques like using LoadLibrary/GetProcAddress and strings like "ws2_32" to avoid detection, which is outside the scope of this demo. 

At the end of it, we can see a window path to a pdb(program database) file which is a debug file from when it was compiled. Some refer it to "Protein Data Bank". However, including this path in the PE malware is unusual.

Looking it up, a simple osint technique of just searching the path itself and google is already telling us that this coming from msf. In this case, with all the things uncovered we can safely assume that it's a staged reverse shell.

A staged reverse shell is a two-part approach where a small initial component (the stager) connects back to the attacker and then downloads or injects a larger payload (the stage), which provides full interactive access. The stager is minimal to evade detection and avoid leaving files on disk, while the stage carries out commands, file transfers, and other malicious actions. Staged shells are commonly used in frameworks like Metasploit to deliver flexible, modular, and stealthy remote access. Detection focuses on unusual outbound connections, in-memory payloads, and unexpected network activity.