Forem: Ramadhan Adam

Lab 03-01: When Malware Fights Back — Analyzing Poison Ivy's Anti-VM Evasion

Ramadhan Adam — Tue, 06 Jan 2026 11:51:45 +0000

Part 2 of the Practical Malware Analysis Labs Series

Introduction

In my previous article on Lab 01, we successfully analyzed basic malware behavior using standard static analysis techniques. Everything worked smoothly — we examined PE structures, extracted IOCs, and understood malicious functionality without even executing the samples.

Lab 03-01 would prove to be a completely different challenge.

This article analyzes Lab03-01.exe from the book Practical Malware Analysis by Michael Sikorski and Andrew Honig — a foundational text in malware analysis education. This particular sample is a Poison Ivy trojan variant that refused to cooperate.

Within 33 milliseconds of execution, it detected my analysis environment and terminated itself. No network traffic. No malicious behavior. Just a crash report to Microsoft.

A Note on Safety

All analysis was performed on isolated systems with no network connectivity to production environments. 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 Lab

For this analysis, I prepared a comprehensive monitoring setup in a VMware Windows 10 environment:

Dynamic Analysis Tools:

FakeNet 3.5 — Network simulation and traffic interception
Wireshark — Deep packet inspection
ApateDNS — DNS query interception
Procmon (Process Monitor) — System call and registry monitoring
Process Explorer — Real-time process analysis

Static Analysis Tools:

PEview — PE structure examination
PEStudio — Automated PE analysis
Dependency Walker — Import/export analysis
HxD — Hex editor
Strings — String extraction

I configured FakeNet to redirect all network traffic to a fake IP (192.0.2.123) and set up ApateDNS to intercept DNS queries, returning 127.0.0.1 for all domains.

This would allow me to capture the malware's command and control communication without it actually reaching the target.

Or so I thought...

Note: In this case, a fake server (Linux preferably), set up in the same Host-Only network adapter would have worked better using INetSim and ApateDNS.

What the Sample Should Do

Before executing the sample, I performed basic static analysis to understand what I should expect to see. I uploaded the .exe file to VirusTotal and got the following results:

File Identification:

Filename: Lab03-01.exe
MD5: d537acb8f56a1ce206bc35cf8ff959c0
SHA-256: eb84360ca4e33b8bb60df47ab5ce962501ef3420bc7aab90655fd507d2ffcedd
VirusTotal: 68/72 detections
Classification: Trojan.Poison/PoisonIvy

PE Structure Analysis

The binary showed clear signs of being packed:

.data section entropy: 6.400 (high entropy indicates encryption/compression)
File ratio: 85.711%
Minimal exports (typical of packed executables)

String Analysis

Several interesting strings were immediately visible:

Network Indicators:

www.practicalmalwareanalysis.com
Connect %s %d http/1.0
ws2_32
admin

The C2 domain was hardcoded, and the connection string format indicated HTTP/1.0 communication.

Persistence Mechanisms:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run
SOFTWARE\Classes\http\shell\open\commandV

Multiple registry keys suggested the malware would attempt to establish persistence.

Anti-VM Artifacts:

WinVMXX32-
vmx32to64.exe
VideoDriver

And here was the first red flag. These strings are classic VMware detection indicators.

Expected Behavior

Based on static analysis, I expected to observe:

DNS query for www.practicalmalwareanalysis.com
HTTP/1.0 connection to resolved IP on port 80
Registry modifications for persistence
Potential system information exfiltration

Time to see if reality matched expectations.

The Execution: 33 Milliseconds of Nothing

I started all monitoring tools, took a clean VM snapshot, and ran Lab03-01.exe through the terminal.

What Happened

Execution Timeline:

T+0ms: Lab03-01.exe launched
T+33ms: Process terminated
T+50ms: WerFault.exe (Windows Error Reporting) appeared in Process Explorer

That's it. The malware executed for exactly 33 milliseconds before crashing.

Finding the Smoking Gun

Looking at Process Monitor logs, I found what happened:

Successful Registry Access:

HKLM\System\CurrentControlSet\Control\Session Manager\kernel32 — SUCCESS
HKLM\Software\Microsoft\Wow64\x86 — SUCCESS
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run — SUCCESS

Failed Registry Access (Anti-VM Checks):

HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot — NAME NOT FOUND
HKLM\SOFTWARE\Policies\Microsoft\Windows — NAME NOT FOUND

The malware was actively probing the registry for specific keys. Several returned "NAME NOT FOUND" — likely part of its VM detection logic.

The Critical Finding:

In my system directory, I found what it was looking for:

C:\Windows\System32\vmx32to64.exe

This VMware-specific executable gave away the virtualized environment.

The Network That Never Was

Despite comprehensive network monitoring, Lab03-01.exe generated zero network traffic.

What Was Captured:

Windows Error Reporting (watson.events.data.microsoft.com)
Standard system traffic (WPAD, Windows Update)

What Was Missing:

No DNS query for www.practicalmalwareanalysis.com
No HTTP/1.0 connection attempts
No TCP traffic on port 80 from the malware process

FakeNet logged activity from six processes — none of them Lab03-01.exe. The malware terminated before initiating any network communication, confirming successful evasion.

How the Anti-VM Detection Works

So why did the malware terminate? Let's break down the techniques it employed.

Detection Method 1: File System Artifacts

The malware checked for VMware-specific files:

vmx32to64.exe — VMware executable in System32

VMware installs various utilities and drivers. Checking these files is a quick way to detect virtualization.

Detection Method 2: Mutex/String Checks

The string WinVMXX32- suggests mutex or process name checking. VMware processes often contain "vmx" in their names.

Detection Method 3: Registry Queries

The failed registry queries weren't accidents. Certain registry keys exist only in physical machines or have different values in VMs.

Detection Method 4: Behavioral Analysis

The 33-millisecond execution time wasn't random:

Load → Check environment → Detect VM → Exit cleanly

Modern malware performs environment checks before unpacking or executing its main payload.

What I Still Learned

Despite the malware refusing to fully execute, the analysis provided valuable intelligence.

IOC — Indicators of Compromise

Network Indicators:

C2 Domain: www.practicalmalwareanalysis.com
Protocol: HTTP/1.0
Port: 80 (inferred)

Host Indicators:

Registry Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Mutex: WinVMXX32
File Check: C:\Windows\System32\vmx32to64.exe

YARA Detection Rule

rule Lab03_01_PoisonIvy {
    meta:
        description = "Detects Lab03-01 Poison Ivy variant"
        author = "Ramadhan Adam Zome"

    strings:
        $c2 = "www.practicalmalwareanalysis.com" ascii
        $http = "Connect %s %d http/1.0" ascii
        $vm1 = "WinVMXX32-" ascii
        $vm2 = "vmx32to64.exe" ascii

    condition:
        uint16(0) == 0x5A4D and
        filesize < 500KB and
        ($c2 or ($http and 2 of ($vm*)))
}

Lessons Learned

This analysis taught me several valuable lessons:

1. Anti-Analysis is the Norm

Modern threats actively check for virtual machines, sandboxes, debuggers, and analysis tools.

2. Static Analysis is Critical

When dynamic analysis fails, static analysis becomes your primary source of intelligence.

3. "Failure" is Intelligence

The malware refusing to execute tells us it has sophisticated anti-analysis capabilities and prioritizes evasion over execution.

4. Multiple Attempts Required

A single analysis run isn't sufficient. I should have attempted VM artifact removal, bare-metal execution, or binary patching.

Next Steps: Bypassing the Protection

For complete analysis, several approaches could work:

Option 1: VM Artifact Removal

Edit the VMX configuration file and remove VMware-specific files.

Option 2: Binary Patching

Use a debugger to patch the VM check routine and force execution.

Option 3: Bare-Metal Execution

Run on a physical machine with network isolation and complete monitoring.

Option 4: Advanced Sandboxing

Use sophisticated sandboxes designed to hide their presence.

Conclusion

Lab 03-01 demonstrated that malware analysis isn't always straightforward. Sometimes, the most interesting finding is what the malware doesn't do.

This Poison Ivy variant successfully detected my VMware environment and refused to execute its malicious payload. While frustrating, it's a realistic scenario that analysts frequently encounter.

Key Takeaways:

Anti-VM techniques are sophisticated and multilayered
Static analysis remains valuable even when dynamic analysis fails
Environment preparation is critical
"Failure" provides intelligence about adversary capabilities

In my next article, I'll attempt to bypass these protections and observe this malware's complete behavior.

Resources

Full Analysis: GitHub Repository

Sample Source: Practical Malware Analysis Book Labs

Tools Used:

FakeNet-NG
Sysinternals Suite
Wireshark
PEStudio
PEview

This is Part 2 of my Practical Malware Analysis Labs series, where I'm documenting my journey learning malware analysis techniques. Read Part 1: Static Analysis of 4 Malware Samples if you haven't already.

Connect with me:

GitHub: RamadhanAdam
BlueSky: @0x_zome
Twitter: @RamadhanZome
Medium: RamadhanZome

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

Ramadhan Adam — Tue, 06 Jan 2026 11:45:34 +0000

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

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.

How Lab 01-01 Works

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

Lab01-01.exe (installer) executes first
Searches C:\ drive for executables using FindFirstFileA / FindNextFileA
Uses CreateFileMappingA and MapViewOfFile to patch executable import tables
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)
Drops Lab01-01.dll into System32 as kerne132.dll
Lab01-01.dll gets loaded by infected programs (thinking it's the real kernel32.dll)
DLL establishes connection to 127.26.152.13
Sends beacon string "hello"
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:

Size reduction — Smaller files transfer faster
Obfuscation — Hides real code and strings from static analysis
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

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

Unpacks itself in memory using UPX stub
Creates Windows service named MalService via CreateServiceA
Configures auto-start for persistence
Creates mutex HGL345 to prevent multiple instances
Connects to C2 at www.malwareanalysisbook.com
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:

Minimal IAT: Only LoadLibraryA and GetProcAddress (classic packer signature)
Section anomalies:
- Section [0] Raw Size: 0 bytes
- Section [0] Virtual Size: 12,288 bytes
High entropy: Section [1] entropy = 7.362 (indicates encryption/compression)
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

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:

Lab01-04.exe executes
Locates resource #101 using FindResourceA
Extracts embedded PE from .rsrc section
Escalates privileges via AdjustTokenPrivileges
Writes payload to C:\Windows\System32\ as winup.exe
Replaces legitimate wupdmgr.exe (Windows Update Manager)
Executes dropped payload using WinExec
Dropped component downloads secondary payload from http://www.practicalmalwareanalysis.com/updater.exe
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.

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:

Hash the sample — Establish unique identifier (MD5/SHA-256)
VirusTotal check — Confirm malicious nature, identify packer
Check for packing — Entropy analysis, section names, virtual/raw size discrepancies
Examine PE structure — Headers, sections, resources
Analyze imports — Understand capabilities before execution
Extract strings — Find C2 indicators, configuration data
Resource inspection — Check for embedded payloads
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:

GitHub: RamadhanAdam
BlueSky: @0x_zome
Twitter : @RamadhanZome
Medium : RamadhanZome

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