DEV Community

Cover image for Lab 01: Where It All Begins — Static Analysis of 4 Malware Samples
Ramadhan Adam
Ramadhan Adam

Posted on

Lab 01: Where It All Begins — Static Analysis of 4 Malware Samples

#cybersecurity #tutorial #security #malware

Part 1 of the Practical Malware Analysis Labs Series

Introduction

Static analysis means examining malware without executing it. No virtual machines spinning up. No network traffic to capture. Just you, the binary, and a set of forensic tools trying to extract intelligence before the malware even knows you're looking.

These four samples would teach me how to read the language malware speaks: Portable Executable structures, import tables, suspicious strings, and the telltale signs of packing and obfuscation.

I didn't know it then, but the patterns I learned here would later help me identify when malware was actively fighting back — like the Poison Ivy sample in Lab 03-01 that detected my VM and vanished in 33 milliseconds.

But that's getting ahead of the story. Let's start at the beginning.

A Note on Safety

All analysis was performed on isolated systems with no network connectivity. The samples discussed are training materials from Practical Malware Analysis and should only be analyzed in controlled environments.

Never execute malware on production systems or networks.

Setting Up the Analysis Environment

Before diving into the samples, I assembled my static analysis toolkit:

Analysis Tools:

  • PEStudio — PE structure examination and automated behavioral analysis
  • PEview — Detailed PE header inspection
  • Strings — Extract readable text from binaries
  • Dependency Walker — Import/export analysis
  • HxD — Hex editor for raw binary examination
  • UPX — Unpacking utility

The beauty of static analysis lies in its safety. These tools examine the file structure and metadata without executing any code. Even the most sophisticated malware can't hurt you if you never run it.

Lab 01-01: The Foundation — File Infection & Import Redirection

Initial Triage

I started with the basics: file identification and hashing.

# Generate file hashes
md5sum Lab01-01.exe Lab01-01.dll
sha256sum Lab01-01.exe Lab01-01.dll
Enter fullscreen mode Exit fullscreen mode

Lab01-01.exe:

  • MD5: bb7425b82141a1c0f7d60e5106676bb1
  • SHA-256: 58898bd42c5bd3bf9b1389f0eee5b39cd59180e8370eb9ea838a0b327bd6fe47

Lab01-01.dll:

  • MD5: 290934c61de9176ad682ffdd65f0a669
  • SHA-256: f50e42c8dfaab649bde0398867e930b86c2a599e8db83b8260393082268f2dba

Two files. An executable and a DLL. Immediately suspicious.

VirusTotal Confirmation

Before diving deeper, I uploaded both samples to VirusTotal to see what the antivirus community already knew about them.

Lab01-01.exe:

  • Detection rate: Multiple engines flagged it as malicious
  • Common classifications: Generic trojan, backdoor variants
  • First submission: Years ago (training sample)

Lab01-01.dll:

  • Detection rate: Similar multi-engine detection
  • Classifications: Trojan downloader, backdoor component

The high detection rate confirmed these weren't false positives. The hashes from VirusTotal matched my generated MD5 and SHA256 hashes.

Compile Timestamps

Loading both files into PEStudio revealed something interesting:

  • Lab01-01.exe compiled: 2010/12/19 16:16:19 UTC
  • Lab01-01.dll compiled: 2010/12/19 16:16:38 UTC

19 seconds apart.

These files were built together, packaged together, designed to work together. The .exe likely loads the .dll to perform its malicious operations — a common technique to separate detection surfaces and make analysis harder.

PE Structure Analysis

Neither file was packed — a relief for a first analysis.

Key Indicators:

  • Entropy: ~1.9 in the .text section (normal compiled code, not packed)
  • Section alignment: Virtual sizes slightly smaller than raw sizes (normal compiler padding)
  • Import table: Fully visible and not obfuscated

The low entropy immediately told me these weren't encrypted or compressed.

Import Analysis: What Does It Want To Do?

The import table tells you what capabilities malware has before you ever run it.

Lab01-01.exe imports (The Installer/Infector):

  • FindFirstFileA / FindNextFileA - File enumeration (searching for targets)
  • CopyFileA - File manipulation
  • CreateFileMappingA / MapViewOfFile - Memory mapping to modify executable headers

Lab01-01.dll imports (The Backdoor):

  • ws2_32.dll - Network socket operations (socket, connect, send, recv)
  • CreateProcessA - Remote command execution
  • Sleep - Wait for instructions

The Typosquatting Technique

Examining the strings revealed something clever:

Key Strings Found:

  • C:\windows\system32\kerne132.dll (note the digit '1' instead of letter 'l')
  • kerne132.dll
  • C2 IP Address: 127.26.152.13
  • Beacon String: "hello"
  • Mutex: SADFHUHF

The malware uses DLL typosquatting — replacing kernel32.dll with kerne132.dll in import tables.

Comparison table showing normal program using kernel32.dll versus infected program using typo-squatted kerne132.dll, demonstrating DLL hijacking technique

How Lab 01-01 Works

Based on static analysis, here's the complete infection chain:

  1. Lab01-01.exe (installer) executes first
  2. Searches C:\ drive for executables using FindFirstFileA / FindNextFileA
  3. Uses CreateFileMappingA and MapViewOfFile to patch executable import tables
  4. Replaces legitimate kernel32.dll string with typo-squatted kerne132.dll (hex: 6B 65 72 6E 65 31 33 32 instead of 6B 65 72 6E 65 6C 33 32)
  5. Drops Lab01-01.dll into System32 as kerne132.dll
  6. Lab01-01.dll gets loaded by infected programs (thinking it's the real kernel32.dll)
  7. DLL establishes connection to 127.26.152.13
  8. Sends beacon string "hello"
  9. Awaits commands from C2 server

Malware Type: Multi-component backdoor with file infection capabilities and network-based C2 communication.

IOC Summary — Lab 01-01

File Indicators:

  • MD5: bb7425b82141a1c0f7d60e5106676bb1 (.exe)
  • MD5: 290934c61de9176ad682ffdd65f0a669 (.dll)
  • File: C:\Windows\System32\kerne132.dll (typo-squatted DLL)

Network Indicators:

  • C2 IP: 127.26.152.13
  • Beacon: "hello"

Behavioral Indicators:

  • Import table modification in executables
  • DLL typosquatting technique
  • Mutex: SADFHUHF

Lab 01-02: Malicious Services & The UPX Packer

First Signs of Obfuscation

Lab 01-02 looked different from the start.

File Hash:

  • MD5: 8363436878404da0ae3e46991e355b83
  • SHA-256: c876a332d7dd8da331cb8eee7ab7bf32752834d4b2b54eaa362674a2a48f64a6

VirusTotal Results:

  • Detection: Trojan.Ulise / Trojan.Clicker
  • Multiple engines flagged it as packed/obfuscated malware
  • UPX packer specifically identified

Detecting the Packer

Loading it into PEStudio immediately revealed packing indicators:

UPX Packer Signatures:

  • Section names: UPX0, UPX1, .txt
  • Section flags: Writable, Executable, Self-Modifying
  • Virtual Size anomaly: .txt section has 16,384 bytes virtual size but 0 bytes raw size
  • Entropy: N/A (can't calculate entropy for empty section on disk)

This discrepancy confirms the file is a compressed shell that expands upon execution.

Why Pack Malware?

Packing serves multiple purposes:

  1. Size reduction — Smaller files transfer faster
  2. Obfuscation — Hides real code and strings from static analysis
  3. Anti-analysis — Forces analysts to unpack before examining behavior

The Unpacking Process

UPX is one of the easiest packers to reverse:

upx -d Lab01-02.exe -o Lab01-02_unpacked.exe
Enter fullscreen mode Exit fullscreen mode

One command. The file decompresses instantly.

Post-Unpacking Analysis

After unpacking, two sets of imports became visible:

Packer Imports (KERNEL32.dll):

  • LoadLibraryA / GetProcAddress - Dynamic API loading
  • VirtualProtect - Memory permission modification

Malicious Functionality:

ADVAPI32.dll:

  • CreateServiceA - Service installation for persistence
  • CreateMutexA - Instance control

WININET.dll:

  • InternetOpenA / InternetOpenUrlA - Network communication

Key Strings Extracted

Post-unpacking strings revealed:

  • Service Name: MalService
  • Mutex: HGL345
  • C2 URL: http://www.malwareanalysisbook.com

How Lab 01-02 Works

  1. Unpacks itself in memory using UPX stub
  2. Creates Windows service named MalService via CreateServiceA
  3. Configures auto-start for persistence
  4. Creates mutex HGL345 to prevent multiple instances
  5. Connects to C2 at www.malwareanalysisbook.com
  6. Downloads/executes secondary payloads

Malware Type: Service-based persistent backdoor with UPX obfuscation.

IOC Summary — Lab 01-02

File Indicators:

  • MD5: 8363436878404da0ae3e46991e355b83 (packed)
  • Packer: UPX

Host Indicators:

  • Service: MalService
  • Mutex: HGL345

Network Indicators:

  • URL: http://www.malwareanalysisbook.com

Lab 01-03: Advanced Obfuscation — The FSG Packer

If UPX was a speed bump, FSG was a brick wall.

A Different Kind of Packer

File Hash:

  • MD5: 9c5c27494c28ed0b14853b346b113145
  • SHA-256: 7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec

VirusTotal Results:

  • Detection ratio: 64/72
  • Common signatures: Trojan.Graftor, Genome, Tegan
  • Identified packer: FSG 1.0

Detecting FSG Packing

PEStudio analysis revealed advanced obfuscation:

FSG Packer Indicators:

  1. Minimal IAT: Only LoadLibraryA and GetProcAddress (classic packer signature)
  2. Section anomalies:
    • Section [0] Raw Size: 0 bytes
    • Section [0] Virtual Size: 12,288 bytes
  3. High entropy: Section [1] entropy = 7.362 (indicates encryption/compression)
  4. Section name: .fsgrub (FSG signature)

Why FSG Is Harder

Unlike UPX, FSG uses:

  • Custom compression algorithms
  • Anti-debugging checks during unpacking
  • Encrypted import tables
  • Polymorphic decompression stubs 
# Attempted unpacking
upx -d Lab01-03.exe
# Result: NotPackedException
Enter fullscreen mode Exit fullscreen mode

FSG requires specialized tools or manual memory dumping.

Static Analysis Limitations

With Lab 01-03, I hit a wall.

What I could determine:

  • File packed with FSG 1.0
  • Original entry point hidden
  • Import table encrypted
  • Minimal strings available

What I couldn't determine:

  • Actual malicious functionality
  • Network indicators
  • C2 infrastructure
  • Behavioral patterns

The Lesson

Not all malware yields its secrets to static analysis alone. FSG-packed samples require:

  • Dynamic execution monitoring
  • Debugger-assisted manual unpacking
  • Memory dumps of unpacked code

This sample served as a humbling reminder that malware authors actively work to make analysis harder.

IOC Summary — Lab 01-03

File Indicators:

  • MD5: 9c5c27494c28ed0b14853b346b113145
  • Packer: FSG 1.0
  • Entropy: 7.362 (highly compressed/encrypted)

Analysis Status:

  • Static analysis: Limited intelligence
  • Requires: Dynamic analysis and memory inspection

Lab 01-04: Resource Manipulation & Dropper Tactics

The final sample introduced resource-based payload delivery.

Initial Analysis

File Hash:

  • MD5: 625ac05fd47adc3c63700c3b30de79ab
  • SHA-256: 0fa1498340fca6c562cfa389ad3e93395f44c72fd128d7ba08579a69aaf3b126

VirusTotal Results:

  • Detection ratio: 63/72
  • Classifications: TrojanDownloader:Win32, Trojan.cerbu/gofot, Dropper
  • Widely recognized as downloader/dropper malware

The Suspicious Resource Section

PE Structure Analysis:

  • Entropy: 3.123 (.text section - normal, not packed)
  • Anomaly: .rsrc section = 55.56% of total file size

This unusually large resource section suggested embedded payload.

Resource Extraction

Using PEStudio, I examined the .rsrc section:

Resource Details:

  • Type: DUMP/BINARY
  • Name: #101
  • Finding: Fully functional malicious PE executable embedded

Extracted Resource Analysis:

  • VirusTotal score: 63/73 (trojan.jtgz/gofot)
  • Functionality: Contains URLDownloadToFileA
  • Target URL: http://www.practicalmalwareanalysis.com/updater.exe
  • File references: \winup.exe, wupdmgr.exe

Import Analysis

Resource Manipulation (The Dropper):

  • FindResourceA / LoadResource / SizeofResource - Locate and extract embedded payload
  • WriteFile - Write payload to disk
  • WinExec - Execute dropped payload

Execution & Persistence:

  • GetWindowsDirectoryA / GetTempPathA - Determine drop location
  • MoveFileA - Rename/move files (replace legitimate wupdmgr.exe)

Privilege Escalation:

  • AdjustTokenPrivileges - Enable security privileges
  • LookupPrivilegeValueA - Query privilege values
  • OpenProcessToken - Access process tokens

These functions allow the malware to bypass Windows File Protection and modify system-level files.

Additional Capabilities:

  • sfc_os.dll (System File Checker) - Disable file protection
  • psapi.dll - Monitor running processes

How Lab 01-04 Works

Complete infection chain:

  1. Lab01-04.exe executes
  2. Locates resource #101 using FindResourceA
  3. Extracts embedded PE from .rsrc section
  4. Escalates privileges via AdjustTokenPrivileges
  5. Writes payload to C:\Windows\System32\ as winup.exe
  6. Replaces legitimate wupdmgr.exe (Windows Update Manager)
  7. Executes dropped payload using WinExec
  8. Dropped component downloads secondary payload from http://www.practicalmalwareanalysis.com/updater.exe
  9. Malware runs with system privileges under "trusted" filename

Malware Type: Sophisticated dropper with privilege escalation and remote download capabilities.

IOC Summary — Lab 01-04

File Indicators:

  • MD5: 625ac05fd47adc3c63700c3b30de79ab
  • Modified file: C:\Windows\System32\wupdmgr.exe
  • Malicious process: winup.exe

Network Indicators:

  • C2 URL: http://www.practicalmalwareanalysis.com/updater.exe

Behavioral Indicators:

  • Resource-based payload delivery
  • Windows File Protection bypass
  • System file replacement
  • Privilege escalation

Comparative Analysis: What I Learned

Analyzing these four samples in sequence was intentional — each one built on lessons from the previous.

Comparative analysis table of Lab 01 samples showing techniques (DLL typosquatting, UPX packer, FSG obfuscation, resource dropper), host indicators, network indicators, and analysis difficulty levels

Key Takeaways

1. Import Tables Are Intelligence Gold

Before executing malware, imports reveal:

  • Network capabilities (ws2_32.dll, wininet.dll)
  • File manipulation (kernel32.dll file functions)
  • Persistence mechanisms (CreateServiceA, registry functions)
  • Privilege escalation (AdjustTokenPrivileges)

2. Packing Is Common, But Not Uniform

  • Simple packers (UPX) are trivial to reverse with one command
  • Advanced packers (FSG) require dynamic analysis and memory dumps
  • Always check entropy and section names first
  • High entropy (6.0+) + minimal imports = likely packed

3. Static Analysis Has Limits

Some malware won't reveal secrets without execution:

  • Advanced packers encrypt everything
  • Droppers hide payloads until runtime
  • Polymorphic code changes with each sample

4. Multi-Stage Malware Is The Norm

Modern threats rarely execute everything in one file:

  • .exe + .dll components (Lab 01-01)
  • Dropper extracts payload from resources (Lab 01-04)
  • Service downloads Stage 2 from C2 (Lab 01-02)

Each stage makes detection incrementally harder.

5. Typosquatting and Social Engineering

Lab 01-01's kerne132.dll technique demonstrates that malware doesn't always rely on technical exploits — sometimes simple deception works:

  • Users see "kernel" and assume it's legitimate
  • Applications load it thinking it's kernel32.dll
  • Malware gets system-level access through misdirection

Tools & Techniques Summary

Essential Static Analysis Tools:

  • PEStudio — Automated PE analysis, indicator flagging, entropy calculation
  • PEview — Manual PE header inspection
  • Strings — Extract human-readable text
  • Dependency Walker — Import/export relationships
  • HxD — Hex-level examination
  • UPX — Unpacking utility

Analysis Workflow:

  1. Hash the sample — Establish unique identifier (MD5/SHA-256)
  2. VirusTotal check — Confirm malicious nature, identify packer
  3. Check for packing — Entropy analysis, section names, virtual/raw size discrepancies
  4. Examine PE structure — Headers, sections, resources
  5. Analyze imports — Understand capabilities before execution
  6. Extract strings — Find C2 indicators, configuration data
  7. Resource inspection — Check for embedded payloads
  8. Document IOCs — Hashes, domains, file paths, mutexes

What's Next: When Malware Fights Back

These four samples were cooperative. They sat still while I examined them. They revealed their secrets (or at least tried to) through static analysis alone.

But sophisticated malware doesn't cooperate.

In my next analysis, I encountered a very different challenge: a Poison Ivy trojan that detected my VMware environment and terminated itself in 33 milliseconds.

No network traffic. No malicious behavior. Just a crash report to Microsoft.

That sample taught me that malware analysis isn't always about finding answers — sometimes it's about understanding why the malware refuses to give them.

Resources

Full Technical Report: GitHub Repository

Sample Source: Practical Malware Analysis Book Labs

Tools Used:

  • PEStudio
  • PEview
  • Strings
  • Dependency Walker
  • HxD Hex Editor
  • UPX

This is Part 1 of my Practical Malware Analysis Labs series, where I'm documenting my journey learning malware analysis techniques. Follow along as I progress from basic static analysis to advanced dynamic analysis and anti-debugging techniques.

Connect with me:

Continue to Part 2: Lab 03–01: When Malware Fights Back — Analyzing Poison Ivy's Anti-VM Evasion

Top comments (0)