Anatomy of a Malware Dropper: Static and Dynamic Analysis Walkthrough

What Is a Dropper?

A dropper is a purpose-built binary whose sole job is to deliver and execute a second-stage payload. It doesn't steal credentials, exfiltrate data, or encrypt files - it just gets the real malware onto disk and running. Droppers are the first link in nearly every infection chain, from commodity trojans to nation-state implants.

Understanding how droppers work is foundational for both defenders writing detection rules and analysts triaging alerts. In this walkthrough, we'll take a representative sample through a full analysis pipeline: static analysis, dynamic sandbox execution, IOC extraction, MITRE ATT&CK mapping, and YARA rule creation.

Phase 1: Static Analysis

Static analysis examines the binary without executing it. The goal is to form a hypothesis about what the sample does before we let it run.

Triaging the Sample

Start with the basics - file type, hashes, and metadata:

file sample.exe
	# PE32 executable (GUI) Intel 80386, for MS Windows

	sha256sum sample.exe
	# a3f2b8c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1

	exiftool sample.exe | grep -E 'File Size|Compile|Product|Original'
	# File Size: 184 KB
	# Time Stamp: 2025:11:14 03:22:18+00:00
	# Product Name: Windows Update Helper
	# Original File Name: wuhelper.exe

The small file size (184 KB) and the masquerading product name ("Windows Update Helper") are immediate red flags. Legitimate Windows Update binaries are signed by Microsoft and live in C:\Windows\System32.

String Extraction

Strings give us a quick view of embedded URLs, file paths, registry keys, and API names:

strings -n 8 sample.exe | head -40

Key findings from strings:

This string profile tells us the dropper likely downloads a second stage from cdn-update[.]cloud, drops it into %APPDATA%, and establishes persistence through a registry Run key.

Import Table Analysis

The import table reveals which Windows APIs the binary calls:

python3 -c "
	import pefile
	pe = pefile.PE('sample.exe')
	for entry in pe.DIRECTORY_ENTRY_IMPORT:
	    print(entry.dll.decode())
	    for imp in entry.imports:
	        print(f'  {imp.name.decode() if imp.name else hex(imp.ordinal)}')
	"

Critical imports:

• kernel32.dll: VirtualAlloc, CreateProcessW, WriteFile, CreateDirectoryA
• urlmon.dll: URLDownloadToFileA
• advapi32.dll: RegSetValueExA, RegOpenKeyExA
• wininet.dll: InternetOpenA, InternetOpenUrlA

The combination of URLDownloadToFileA + VirtualAlloc + CreateProcessW + registry APIs confirms our hypothesis: download, drop, persist, execute.

PE Section Analysis

python3 -c "
	import pefile
	pe = pefile.PE('sample.exe')
	for s in pe.sections:
	    print(f'{s.Name.decode().strip(chr(0)):8s}  VSize:{s.Misc_VirtualSize:8d}  RSize:{s.SizeOfRawData:8d}  Entropy:{s.get_entropy():.2f}')
	"

.text     VSize:   45056  RSize:   44544  Entropy: 6.42
	.rdata    VSize:   12288  RSize:   12288  Entropy: 5.18
	.data     VSize:    8192  RSize:    4096  Entropy: 4.91
	.rsrc     VSize:   98304  RSize:   97792  Entropy: 7.89

The .rsrc section has entropy of 7.89 - close to the theoretical maximum of 8.0. This indicates encrypted or compressed data embedded as a resource. Many droppers carry their payload in the resource section, decrypting it at runtime before writing to disk.

Phase 2: Dynamic Analysis

Static analysis gave us a hypothesis. Dynamic analysis confirms it by observing actual behavior in a controlled sandbox.

Sandbox Setup

We use an isolated Windows 10 VM with:

• Network traffic captured via inetsim + Wireshark
• Process monitoring with Process Monitor (ProcMon)
• API call logging via API Monitor
• File system monitoring with Noriben

Observed Behavior

Execution timeline:

1. T+0s - Process starts, allocates 96 KB via VirtualAlloc with PAGE_EXECUTE_READWRITE
2. T+0.2s - Reads and decrypts data from its own .rsrc section using XOR with key 0x4A
3. T+0.5s - Creates directory %APPDATA%\Microsoft\ if it doesn't exist
4. T+0.7s - HTTP GET to http://cdn-update[.]cloud/stage2.bin (User-Agent: Mozilla/5.0)
5. T+1.2s - Writes downloaded payload to %APPDATA%\Microsoft\wuhelper.exe (312 KB)
6. T+1.4s - Sets registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\WUHelper pointing to dropped file
7. T+1.6s - Calls CreateProcessW to execute the dropped payload
8. T+1.8s - Dropper exits

Network Indicators

GET /stage2.bin HTTP/1.1
	Host: cdn-update.cloud
	User-Agent: Mozilla/5.0
	Accept: */*

DNS resolution: cdn-update[.]cloud → 185.234.72[.]19

File System Artifacts

Phase 3: IOC Extraction

From the analysis, we extract actionable Indicators of Compromise:

Network IOCs

indicators:
	  - type: domain
	    value: cdn-update[.]cloud
	    context: C2/payload delivery domain

	  - type: ipv4
	    value: 185.234.72[.]19
	    context: Resolved IP for payload delivery

	  - type: url
	    value: http://cdn-update[.]cloud/stage2.bin
	    context: Second-stage payload download URL

Host IOCs

indicators:
	  - type: file_path
	    value: '%APPDATA%\Microsoft\wuhelper.exe'
	    context: Dropped payload location

	  - type: registry_key
	    value: 'HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\WUHelper'
	    context: Persistence mechanism

	  - type: sha256
	    value: 'a3f2b8c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1'
	    context: Dropper binary hash

Phase 4: MITRE ATT&CK Mapping

Phase 5: Writing a YARA Detection Rule

Based on our findings, we write a YARA rule that catches this dropper and similar variants:

rule MalwareDropper_WUHelper
	{
	    meta:
	        author      = "Palavi Tech"
	        description = "Detects dropper masquerading as Windows Update Helper"
	        date        = "2026-03-28"
	        reference   = "https://bytescop.com/blog/anatomy-of-a-malware-dropper"
	        severity    = "high"

	    strings:
	        $url1    = "cdn-update" ascii wide nocase
	        $url2    = "stage2.bin" ascii wide
	        $path1   = "wuhelper.exe" ascii wide nocase
	        $reg1    = "CurrentVersion\\Run" ascii wide
	        $api1    = "URLDownloadToFileA" ascii
	        $api2    = "VirtualAlloc" ascii
	        $api3    = "CreateProcessW" ascii
	        $prodname = "Windows Update Helper" ascii wide

	    condition:
	        uint16(0) == 0x5A4D and
	        filesize < 500KB and
	        (
	            ($url1 and $url2) or
	            ($path1 and $reg1 and $api1) or
	            ($prodname and $api2 and $api3) or
	            (3 of ($api*) and $reg1)
	        )
	}

Rule logic:

• Must be a PE file (MZ header) under 500 KB
• Fires on the specific C2 domain + payload name
• Also catches variants using the same drop path + persistence + download pattern
• The product name + API combination catches re-compilations with different URLs

Key Takeaways

1. Droppers are simple by design. Their job is delivery - the complexity lives in the second stage. Don't underestimate them just because the code is small.

2. String analysis reveals intent faster than disassembly. Before opening IDA, always run strings. URLs, file paths, and registry keys tell you 80% of the story.

3. High-entropy resource sections are a red flag. Legitimate software rarely ships with encrypted resource data. An entropy score above 7.0 in .rsrc warrants investigation.

4. YARA rules should catch families, not just samples. Write conditions that match behavioral patterns (API combinations, persistence paths) rather than just specific hashes or URLs.

5. MITRE ATT&CK mapping turns analysis into defense. Mapping techniques gives your SOC team specific detection opportunities and helps prioritize which telemetry sources to invest in.

Malware analysis is a craft you learn by doing. More hands-on security walkthroughs on the BytesCop blog.