Keypoints
- Three extraction methods demonstrated: pe-sieve (automated), Process Hacker memory dump (requires header fixing), and Process Hacker + x32dbg (thread-based dump).
- The sample executed and injected into aspnet_compiler.exe; Process Hacker showed a suspicious “vik” module and a memory region at 0x400000/0x40000 with RWX permissions.
- pe-sieve can scan a running PID (example: pe-sieve /pid 5876) and output an implanted PE file inside a process_xxx folder (e.g., 40000.aspnet_compiler.exe).
- Memory dumps taken directly from process memory will have sections mapped to virtual addresses; tools expect raw addresses, so section headers must be fixed before analysis.
- pe-bear is used to edit section Raw Addresses to match Virtual Addresses, producing a fixed file (e.g., phacker_fixed.bin) that loads correctly in dnspy.
- Using Process Hacker’s Threads tab to identify a suspicious thread start address and attaching with x32dbg lets you jump to that address, find the memory region, and dump it for the same header-fix workflow.
MITRE Techniques
- [T1055] Process Injection – The malware injected into and executed inside a legitimate process (‘aspnet_compiler.exe (This is the file which the malware has injected itself into)’)
- [T1574] Hijack Execution Flow – The original aspnet_compiler.exe content was overwritten in memory to execute attacker code (‘overwritten the original aspnet_compiler.exe’)
- [T1027] Obfuscated Files or Information – The payload was packed/unpacked in memory, requiring runtime extraction to obtain the unpacked sample (‘implanted PE’ was identified)
- [T1005] Data from Local System – The analysis involved dumping process memory regions to files to extract the payload (‘Dump Memory To File’)
- [T1036] Masquerading – The malicious code executed under a legitimate Windows component name to blend in (‘aspnet_compiler.exe’ used as the process name)
Indicators of Compromise
- [SHA256] sample hash – 05c2195aa671d62b3b47ff42630db25f39453375de9cffa92fc4a67fa5b6493b (provided in article)
- [Process name / module] injected/overwritten target – aspnet_compiler.exe (overwritten in-memory by the ‘vik’ module)
- [PID] runtime identifier – example PID 5876 (used when running pe-sieve /pid 5876)
- [Memory region / addresses] suspicious mapping – 0x400000 / 0x40000 (RWX memory region where payload resided)
- [Dumped filenames] extracted files – 40000.aspnet_compiler.exe, phacker_0x40000.bin, phacker_fixed.bin, x32dbg_dump.bin (and other dumped artifacts)
Pe-sieve: run pe-sieve against the running aspnet_compiler.exe process (example: pe-sieve /pid 5876). pe-sieve scans loaded modules, identifies implanted PEs, and saves them into a process_5876 folder (e.g., 40000.aspnet_compiler.exe), providing a fast, automated way to retrieve an in-memory unpacked payload.
Process Hacker memory dump + pe-bear: use Process Hacker to find the target module base (aspnet_compiler.exe) and the memory region (e.g., 0x40000/0x400000). Right-click the memory region and save it (phacker_0x40000.bin). Because memory-saved PE sections are aligned to virtual addresses, open the dump in pe-bear, adjust each section’s Raw Address to match its Virtual Address (redirect raw → virtual), then save the corrected file (phacker_fixed.bin). The fixed PE will load properly in dnspy, revealing the unpacked module (the “vik” payload).
Process Hacker + x32dbg (thread inspection): inspect the Threads tab in Process Hacker to locate threads executing from the suspect memory space and copy the thread start address. Attach x32dbg to aspnet_compiler.exe, jump to the thread start address, locate the corresponding memory region (0x40000), and use “Dump Memory To File” to export (x32dbg_dump.bin). As with the Process Hacker dump, re-align section headers with pe-bear and re-open in dnspy to analyze the unpacked payload.
Read more: https://embee-research.ghost.io/unpacking-malware-using-process-hacker-and-memory-inspection/