Nonyx: Reverse Engineering Malware Code

Lab Scenario

Exorcise Black Energy 2 from Shadowbrook’s digital infrastructure by reverse-engineering the malware’s code. You must dismantle its hooks, identify its payload, and stop its command-and-control mechanisms to restore peace to the town’s network before the Haunted Festival reaches its darkest hour.

Tools: Volatility 2, Malfind, Strings, File

Objective

We will investigate a suspicious file named BlackEnergy.vnem located on the desktop using the Volatility framework. The goal is to analyze the file for potential malicious behavior.

Question 1: Which process most likely contains injected code, providing its name, PID, and memory address? (Format: Name, PID, Address)

We can see the hint provided to us in the Readme.txt file.

I began by running the malfind plugin on the BlackEnergy.vnem file to investigate potential hidden or injected code. Using the command:

 

python vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 malfind

During the analysis, it became evident that code had been injected into the process. The process in question is:

• Process Name: svchost.exe
• Process ID (PID): 856
• Injected Memory Address: 0xc30000

To confirm this, the next logical step involves dumping the injected memory to a file for detailed examination. By submitting this dumped file to platforms like VirusTotal, we can verify its nature and determine whether it is indeed malicious.

This initial discovery strongly suggests malicious activity, as svchost.exe is a common target for code injection due to its prevalence and trusted nature in Windows environments. Further investigation will focus on isolating the injected code, analyzing its behavior, and uncovering the attacker’s objectives.

Question 2: What dump file in the malfind output directory corresponds to the memory address identified for code injection? (Format: Output File Name)

To confirm the presence of malicious code, I used the following command to dump the memory regions flagged by the malfind plugin:

python vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 malfind --dump-dir output

This command not only scans for injected code but also extracts the suspicious memory regions to the specified output directory (output). By doing so, I now have access to the raw data associated with the injected code.  The dumped files can now be analyzed using tools like VirusTotal, sandbox environments, or static/dynamic analysis to determine the intent and behavior of the suspected malicious code. This step is crucial to confirm the malicious nature of the injected code and to gather indicators of compromise (IOCs) for further investigation.

Question 3: Which full filename path is referenced in the strings output of the memory section identified by malfind as containing a portable executable (PE32/MZ header)? (Format: Filename Path)

After dumping the suspicious memory regions using the malfind plugin, I proceeded to analyze the dumped files with the strings command. This helps extract readable text or ASCII/Unicode strings from the binary content of the dumped memory regions.  By running:

strings process.0x80ff88d8.0xc30000.dmp | less

and scrolling through the output, I observed a critical piece of evidence: the full path associated with the injected code. This path provides a direct clue about the origin or intended location of the injected code, which is often used to uncover malicious activity or artifacts left behind by the attacker. The presence of the full path in the memory dump adds context to the injection and may lead to further investigative opportunities, such as locating the original malicious file on disk or identifying related artifacts in the system. This finding strengthens the case for a targeted malware injection in the system.

Question 4: How many functions were hooked and by which module after running the ssdt plugin and filtering out legitimate SSDT entries using egrep -v ‘(ntoskrnl|win32k)’? (Format: XX, Module)

We use command:

vol.py -f BlackEnergy.vnem ssdt | egrep -v '(ntoskrnl|win32k)'

Analysis Summary

• Purpose of the Command:
  This command inspects the System Service Descriptor Table (SSDT), a critical data structure in Windows that links system calls from user-mode to their respective kernel-mode handlers. It specifically filters out results associated with ntoskrnl and win32k, which are typically legitimate system modules, to focus on potential anomalies.

• Why Analyze SSDT?
  The SSDT is often targeted by attackers to redirect system calls (via hooking) to malicious routines. By modifying SSDT entries, attackers can:

  • Intercept or alter system behavior.
  • Hide malicious processes, files, or network activities.
  • Gain deeper control over the compromised system.

• Key Observations:
  Any entries pointing to unknown or suspicious drivers (i.e., not part of standard Windows operations) would indicate possible kernel-level tampering, such as rootkits or advanced malware.

This command helps narrow down suspicious activity in the kernel, highlighting potential unauthorized modifications to system behavior, which is characteristic of sophisticated malware like BlackEnergy. The findings here would guide further investigations into the identified suspicious drivers or kernel hooks.

So here we can see 14 hooked functions that are owned by the module 00004A2A.

Question 5: Using the modules (or modscan) plugin to identify the hooking driver from the ssdt output, what is the base address for the module found in Q4? (Format: Base Address)

Using the command:

python vol.py -f BlackEnergy.vnem modscan | grep 00004A2A

Summary of Findings

• Purpose:
  The modscan plugin identifies LDR_DATA_TABLE_ENTRY structures in memory, which are used to manage information about loaded kernel modules (drivers). By filtering for a specific address (00004A2A), we pinpoint the base address of a relevant module.

• Significance:
  This approach helps uncover:

  • Unlinked or hidden drivers: Rootkits and other advanced malware often attempt to hide by unlinking themselves from the normal driver lists.
  • Previously unloaded drivers: Drivers that may have been unloaded but left traces in memory.

• Key Result:
  The base address (00004A2A) provides a starting point for further analysis of the module in memory. It can be used to:

  • Investigate the driver’s metadata (name, path, timestamp).
  • Analyze its behavior and determine whether it is malicious or legitimate.

This method is particularly effective for detecting stealthy kernel-mode malware like rootkits that tamper with system internals.

Question 6: What is the hash for the malicious driver from the virtual memory image?

To extract the suspicious driver file and analyze its integrity, I ran the following command to dump the driver file based on its base address:

python vol.py -f BlackEnergy.vnem moddump --dump-dir output/ --base 0xff0d1000

Summary of the Process

• Purpose of the Command:
  The moddump plugin is used to dump a driver module from memory based on its base address (0xff0d1000). This allows further analysis of the driver outside the memory environment.

• Next Step:
  After successfully dumping the driver file to the specified directory (output/), I calculated the SHA256 hash of the dumped file using the sha256sum command:

  

• Why the SHA256 Hash?
  The SHA256 hash provides a unique fingerprint of the dumped driver file. This is critical for:

  • Verifying the file’s integrity.
  • Cross-referencing the hash with threat intelligence platforms (e.g., VirusTotal) to identify known malware.

The dumped file and its hash are now ready for submission to analysis platforms to determine its nature and behavior, confirming whether it is part of a legitimate system module or malicious software.