Static Analysis

Static analysis involves investigating a file without actually executing it.

Analysts observe properties like file headers, metadata, libraries that are imported, strings, and more to build an idea of the actual function of the malware without it running.

Static analysis offers us a pretty limited risk of infection, since we're not actually triggering any malicious code. It also gives us a preliminary set of Indicators of Compromise (IOCs) like IP addresses, domain names/information, registry keys, or file paths.

However, static analysis may not necessarily reveal hidden or obfuscated functionalities, like things that only happen at runtime, and packers and crypters can significantly complicate/hide the real logic within the malware from static analysis.

Common tools & Procedures

Grabbing Hashes

Before any sort of malware manipulation, it is a good practice to grab your SHA256 and MD5 hashes of the malware so you can conduct some preliminary research.

Start by computing the MD5, SHA1, or SHA256 of the sample (e.g., using Linux sha256sum or a tool like hashcalc on Windows). This helps with:

• Preliminary Research: Check online malware databases (e.g., VirusTotal) using the hash instead of uploading the file.

• Tracking Samples: Each unique binary can be referenced by its hash.

File Identification and Classification

It's a good idea to stay organized.

Check the file type through its header and magic number, file extensions can be intentionally misleading, especially when dealing with malware.

• Linux: The file command displays whether a file is a PE, ELF, Mach-O (Windows, Linux, and macOS binaries respectively), or something else.

• Windows: There are a handful of tools out there that you can use on the Windows side of the house, including Exeinfo PE or PEStudio, which identifies PE structure, potential packers, compression, or encryption.

• Many other options exist!

As mentioned in the previous section, checking hash repositories like VirusTotal to quickly gauge detection rates, known families, and crowd-source your intelligence is common.

Capa

Mandiant's Capa tool. -- Automated capability identification.

Capa is an open-source tool developed by Mandiant’s FLARE team that inspects executable files, primarily Windows PE files, and detects known capabilities or behaviors. Capa uses a structured rule set to match patterns in the binary’s code or data segments, effectively revealing high-level functionality (e.g., file manipulation, process injection, persistence methods) without needing to run the malware.

Key Features

1. Rule-Based Approach

   • Capa uses YARA-like rules, each describing specific behaviors.

   • Capabilities range from simple (deleting files, creating registry keys) to advanced (process hollowing, anti-debugging tricks).

2. Static Analysis Focus

   • Unlike dynamic analysis, Capa does not require execution of the binary.

   • It parses disassembled code to find function signatures, API calls, and instruction patterns.

3. Extensive Rule Library

   • Contains numerous community-contributed rules that map to MITRE ATT&CK techniques, known threat actor behaviors, or common malware TTPs.

   • You can add custom rules to detect new or targeted functionalities.

4. Cross-Tool Integration

   • Works well with IDA, Ghidra, and radare2.

   • Capa scripts can be integrated into your normal reverse-engineering workflow, or run from the command line on standalone files.

Basic Metadata Extraction

Strings

An array of characters!

Looking for strings in a binary is a quick way to reveal some information without actually executing the malware. Many samples have hard-coded text, function names, registry keys, or other human-readable data, and can be reviewed for:

• Malicious indicators: C2C communications, domain names, file paths

• Functionality: Names of system APIs, libraries used by the malware

• IOCs: Registry keys or file names

• Suggest obfuscation: Lack of strings could lead us to believe the malware has been obfuscated or encrypted

We have a few ways to look for strings, some more intensive than others.

Some command line tools include:

• strings on Linux/macOS that searches for printable characters and returns them.

• Sysinternals Strings for Windows that behaves similarly, optimized for Windows binaries.

• FLOSS: FLARE Obfuscated String Solver currently maintained by the Mandiant team extracts and attempts to automatically deobfuscate strings in malware binaries.

Reverse-engineering suites like:

• IDA Pro/Ghidra: Disassemblers, but have strings functions within.

• Radare2: An open-source reverse-engineering framework that also includes a strings feature with advanced search capabilities.

• See our Reverse Engineering page for more information on this topic.

Some more specific-to-malware options:

• PE-bear: Examines Windows PE file structure parsing, can enumerate imported functions/extract strings.

• Binwalk for Linux: More often used for firmware or multi-layered binaries (packed, compressed) to search for know file signatures/readable strings.

Windows File Properties

For Windows .exe, .dll, .sys, etc., the Portable Executable (PE) format contains a rich set of metadata in headers and sections.

1. PE Header Fields

   • Signature: MZ at the start, followed by PE\0\0 further in the file.

   • Machine Type: Identifies if it’s x86 (0x14C), x64 (0x8664), or other architectures.

   • Timestamp: Sometimes indicates the compile or build time, but can be forged.

2. Imports & Exports

   • Import Table: Lists external DLLs and APIs the file calls at load time (e.g., kernel32.dll, user32.dll).

   • Export Table: For DLLs, indicates which functions are exposed to other processes.

3. Resources

   • Located in the .rsrc section. Can contain icons, version info, or embedded files (including potential malicious data).

   • Tools like Resource Hacker or XN Resource Editor can parse these for clues.

4. Tools:

   • PE-bear, PEview or CFF Explorer: Graphical explorers for the PE format.

   • Exeinfo PE: Overviews PE properties, signatures, possible packing.

   • Sysinternals Sigcheck: Checks for digital certificates, version info.

Linux File Properties

On Linux (and many Unix-like systems), native executables follow the ELF (Executable and Linkable Format) structure.

1. ELF Header

   • Starts with magic bytes 0x7F 45 4C 46 (“ELF”).

   • Contains fields indicating the CPU architecture (e.g., x86_64), endianness, and ELF class (32-bit vs. 64-bit).

2. Program & Section Headers

   • Program Header Table (PHT): Describes how to create a process image in memory (segments).

   • Section Header Table (SHT): Lists sections (e.g., .text, .data, .rodata). Tools like readelf or objdump can display these.

3. Dynamic Linking & Symbols

   • Dynamic Symbol Table: References external libraries (.so files).

   • ldd filename: Quickly shows which shared objects the binary depends on.

4. Popular Tools

   • readelf: Inspects ELF headers and sections.

   • objdump: Disassembles code, prints headers, and symbol information.

   • binutils (nm, strings): Additional commands to list symbols or examine constants.

5. Resource-Like Data?

   • ELF doesn’t have a dedicated “resources” section like PE. However, malicious code may embed data in custom sections or hide it within conventional sections (e.g., .rodata).

   • Use hex editors or strings searches to find suspicious embedded data.

macOS File Properties

On macOS, native executables typically use the Mach-O (Mach Object) format.

1. Mach-O Header

   • Magic values can be 0xFEEDFACE (32-bit) or 0xFEEDFACF (64-bit).

   • Contains CPU type, CPU subtype, file type (e.g., executable, dynamic library, object file).

2. Load Commands

   • Equivalent to “program headers” in ELF. Each load command describes how to map segments (e.g., __TEXT, __DATA) into memory, link libraries, etc.

3. Dyld Info & Libraries

   • Dynamically linked libraries are loaded by dyld.

   • Tools such as otool -L <filename> or otool -hv <filename> reveal linked libraries, header info, and more.

4. Code Signing (macOS Gatekeeper)

   • macOS can enforce code-signing checks. Attackers sometimes use stolen or self-signed certificates to bypass basic Gatekeeper checks.

   • codesign -dv --verbose=4 filename to see the signing info.

5. Popular Tools

   • otool: CLI for Mach-O inspection (headers, disassembly).

   • MachOView: GUI application for analyzing Mach-O binaries.

   • class-dump: If dealing with Objective-C code, can provide insights into classes, methods, and property names.

What Next?

When extracting basic metadata from any suspicious file—be it a Windows PE, Linux ELF, or macOS Mach-O—the overarching goals are:

1. Gather Quick Indicators

   • Strings, suspicious section names, known library calls.

2. Confirm Platform & Architecture

   • Helps tailor further steps (e.g., picking the right debugger or reverse-engineering approach).

3. Spot Potential Obfuscation

   • Minimal imports or unusual file structure suggests a packer/crypter.

4. Check for Authenticity

   • Digital signatures (if present) and file version info can provide context.

Armed with this metadata, you’ll have a clearer idea of how to proceed—whether that involves deeper static analysis (e.g., disassembly, decompilation) or pivoting to dynamic/sandbox analysis to see the malware’s runtime behavior.