DEV Community

Cover image for Lab 03-01: When Malware Fights Back — Analyzing Poison Ivy's Anti-VM Evasion
Ramadhan Adam
Ramadhan Adam

Posted on

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

#malwareanalysis #reverseengineering #infosec #security

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:

  1. DNS query for www.practicalmalwareanalysis.com
  2. HTTP/1.0 connection to resolved IP on port 80
  3. Registry modifications for persistence
  4. 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

Process Monitor window showing system activity log for WerFault.exe with registry operations, file reads, and thread events. One row is highlighted showing a ReadFile operation with 'NAME NOT FOUND' result

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
Enter fullscreen mode Exit fullscreen mode

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*)))
}
Enter fullscreen mode Exit fullscreen mode

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:

Top comments (0)