Static Malware Analysis

Before touching a malware sample, the analyst must prepare a safe, isolated workspace. The two fundamental requirements are isolation and integrity. Isolation means the analysis machine cannot route traffic to production networks, preventing accidental command-and-control callbacks and limiting any inadvertent execution damage. Integrity means the original sample is never modified, and every tool output can be traced back to a specific, hash-verified copy of the file.

In practice, static analysis is typically performed on a dedicated forensic workstation or inside a virtual machine with networking disabled or restricted to a controlled analysis VLAN. A VM snapshot taken before any sample is introduced allows the analyst to roll back to a clean state between cases. The host machine should run endpoint-detection software that is either disabled for the analysis session or configured to alert without blocking, to avoid the analysis tool being quarantined mid-examination.

The analyst should establish a case folder before beginning, recording the date and time of receipt, the source of the sample (incident ticket, email attachment hash, network capture extraction), the chain-of-custody information, and the hash of the original file. Every tool run should be logged with the command used and the timestamp. This documentation is what allows another analyst to reproduce the findings exactly, and what supports admissibility if the case reaches a court.

The first substantive step is confirming what the file actually is. File extensions are controlled by the attacker and are routinely spoofed; a file named invoice.pdf may be a Windows PE executable or a JavaScript dropper. The reliable method is to read the file's magic bytes: the first few bytes of any file contain a signature that identifies its format. The Unix file command and the Windows equivalent CFF Explorer or TrID read these bytes and report the actual format regardless of the extension. A PE executable always begins with the ASCII bytes MZ (0x4D5A). A PDF begins with %PDF. A ZIP archive begins with PK (0x504B).

Once the file type is confirmed, compute cryptographic hashes before doing anything else. The MD5, SHA-1, and SHA-256 hashes serve two purposes. First, they provide a permanent fingerprint of the file in its current state; any tool that modifies the file bytes will change the hash and reveal that tampering. Second, the hashes are the primary identifier for querying threat-intelligence platforms. Submitting a SHA-256 hash to VirusTotal returns the detection verdicts from over 70 antivirus engines plus any contextual reports linked to that hash, all without uploading the sample itself.

Fuzzy hashing tools such as ssdeep produce a hash that remains similar even when a file is slightly modified. This is useful for grouping malware variants that share a common code base despite different exact bytes. A malware author may change a single byte to defeat exact-hash detection; ssdeep will still show a high similarity score to the original sample.

Most binaries contain sequences of printable ASCII or Unicode characters embedded in the file bytes: URLs for command-and-control servers, file paths that the malware creates or modifies, registry key names it reads or writes, error messages used for debugging during development, and the names of Windows API functions it imports. The strings command (available on Linux and as a Sysinternals tool on Windows) scans a file for sequences of printable characters above a minimum length threshold (typically four characters) and prints them. FLOSS (FireEye Labyratory Obfuscated String Solver) extends this by also extracting stack strings and encoded strings that the binary would construct at runtime.

A raw string dump from a malware sample may contain thousands of entries, most of them artefacts of the compiler or runtime library. The analyst filters for strings that reveal intent: any string that matches a URL pattern (http://, .onion, or an IP address in dotted-decimal notation); any string that matches a Windows registry path (HKCU\Software\..., HKLM\System\...); any string naming a sensitive file or directory; any string that appears to be a command or shell invocation; and any string in an unusual character set that might indicate an international target or a payload encoded in Base64.

For Windows malware, the Portable Executable header is among the richest sources of static intelligence. Tools such as PEview, CFF Explorer, pestudio, and the Python library pefile parse the header into human-readable fields. The key fields to examine are: the compilation timestamp (can reveal when the binary was built, though it is easily forged), the section table (names, sizes, and entropy of each code and data section), and the import directory.

The Import Address Table lists every DLL the executable links to at load time and the specific functions it calls from each. This is extremely revealing: a binary that imports CreateRemoteThread, VirtualAllocEx, and WriteProcessMemory is almost certainly performing process injection. A binary importing CryptEncrypt or BCryptEncrypt alongside FindFirstFile and FindNextFile is searching the filesystem and encrypting files, the signature behaviour of ransomware. A binary importing WSAStartup, socket, connect, and send is establishing a network connection. The analyst builds a capability profile from this list before reading a single line of code.

Section entropy is a measure of randomness in the bytes of each section. Normal code sections have entropy in the range of 5.0 to 6.5. Packed or encrypted sections typically have entropy above 7.0, approaching the theoretical maximum of 8.0 for truly random data. High-entropy sections that are also marked as executable are a strong indicator of a packed payload. The tool pestudio flags high-entropy sections automatically and is a standard first-pass tool in many static analysis workflows.

Disassembly converts the raw binary bytes into assembly language instructions. The dominant tool for professional static analysis is IDA Pro, which produces an interactive disassembly graph, reconstructs function boundaries, and allows the analyst to annotate the code. Ghidra, developed and released by the US National Security Agency, is a free alternative with comparable capabilities and an integrated decompiler that produces C-like pseudocode. Radare2 is a command-line framework with scripting support, preferred in automated analysis pipelines.

The analyst begins at the entry point, the address recorded in the PE header where execution starts, and follows the control flow. In a packed binary, the entry point typically leads to a short stub that decrypts or decompresses the real code into memory and then jumps to it. Recognising the unpacking stub pattern (a loop that writes to a newly allocated memory region, ending with a computed jump) tells the analyst where the real analysis begins. In an unpacked binary, the entry point leads to the main payload logic relatively quickly.

Code analysis at this level requires understanding of x86 or x86-64 assembly, Windows calling conventions (the Microsoft x64 ABI for 64-bit binaries, cdecl or stdcall for 32-bit), and common patterns in malware code. A call to GetProcAddress immediately after LoadLibraryA, with the library name and function name passed as string arguments, is how malware resolves imports at runtime to hide them from the static import table. Recognising this pattern allows the analyst to annotate what the call is actually loading.

Static analysis concludes with a structured report that documents every finding in a reproducible form. The report records: the file hash (SHA-256 as the primary identifier, with MD5 and SHA-1 for legacy compatibility), the file type, size, and compilation timestamp; a capability profile derived from the import table; all meaningful strings grouped by category (network indicators, filesystem targets, registry paths, encoded strings); and any assembly-level findings from disassembly, including identified functions and obfuscation techniques.

IoCs extracted from static analysis are published in a structured format so that detection tools can consume them automatically. STIX (Structured Threat Information eXpression) is the current standard for expressing threat intelligence, including file hashes, IP addresses, domain names, and URL patterns. YARA rules are used to express code-level signatures: a YARA rule can specify that a file must contain a particular string pattern, have a particular hash, or satisfy conditions on PE header fields. YARA rules run against file systems and memory captures to detect the same malware or variants.

For investigations involving malware used in cybercrime, the findings from static analysis feed into the broader investigation workflow described in the cyber investigation process. Network-based IoCs such as command-and-control domains are passed to network investigators for traffic correlation. Attribution artefacts such as compilation metadata, language settings in string tables, and code reuse patterns are forwarded to threat-intelligence analysts. The static analysis report is not an endpoint; it is an input to the wider case.