Reverse Malware Engineering Lab: BlackEnergy 2 Analysis

Overview

This project documents my reverse malware engineering investigation of a BlackEnergy 2 themed lab from Blue Team Labs Online. The scenario involved analyzing a memory image to identify injected code, locate malicious driver activity, review SSDT hooks, dump a suspicious kernel module, and generate a hash for threat intelligence enrichment.

The investigation focused on using Volatility 2, malfind, file analysis, strings, SSDT review, modscan, and moddump to understand how the malware operated inside memory.

Video Walkthrough

Watch my Reverse Malware Engineering Lab walkthrough on YouTube

Scenario Summary

Shadowbrook’s digital infrastructure was suspected of being infected with BlackEnergy 2 malware. The goal of the investigation was to reverse engineer the malware behavior from a memory image and identify evidence of code injection, hooked system functions, suspicious drivers, and command and control related activity.

The scenario focused on:

• Memory forensics
• Injected code analysis
• BlackEnergy 2 behavior
• Rootkit style activity
• SSDT hook review
• Suspicious driver identification
• Module dumping
• Hash generation
• Threat intelligence enrichment

Objective

The objective of this investigation was to:

• Analyze a Windows memory image with Volatility 2
• Identify the process containing injected code
• Dump the injected memory section
• Review strings from the dumped memory section
• Identify suspicious driver paths
• Analyze SSDT hooks
• Identify the module responsible for the hooks
• Locate the base address of the suspicious module
• Dump the malicious driver from memory
• Generate a SHA256 hash for enrichment
• Connect the findings to BlackEnergy 2 behavior

Key Investigation Data

Skills Demonstrated

• Memory forensics
• Malware reverse engineering fundamentals
• Volatility 2 analysis
• Injected code detection
• Malfind analysis
• Suspicious memory region dumping
• Strings analysis
• File type analysis
• SSDT hook review
• Rootkit behavior analysis
• Kernel module review
• Driver dumping
• SHA256 hash generation
• Threat intelligence enrichment
• Incident documentation

Tools and Evidence Used

• Volatility 2
• malfind
• ssdt
• modscan
• moddump
• strings
• file
• sha256sum
• VirusTotal
• Windows memory image
• BlackEnergy 2 related artifacts
• MITRE ATT&CK

Investigation Methodology

1. Memory Image Review

The investigation began with the provided memory image.

Memory image:

BlackEnergy.vmem

The lab note provided the Volatility profile to use:

WinXPSP2x86

This profile was required so Volatility could properly parse the Windows XP memory image.

2. Injected Code Identification

I used the malfind plugin to search for suspicious memory regions that could indicate injected code.

Command used:

python vol.py -f ../BlackEnergy.vmem --profile=WinXPSP2x86 malfind

The purpose of this step was to identify processes with suspicious executable memory regions, such as memory containing PE headers or injected shellcode.

Injected process details:

Process name: svchost.exe
PID: 856
Injected memory address: 0xc30000

This process was the most likely candidate for injected malicious code.

3. Dumping the Injected Memory Section

After identifying the suspicious process and memory address, I dumped the memory section for deeper analysis.

Command pattern:

python vol.py -f ../BlackEnergy.vmem --profile=WinXPSP2x86 malfind --dump --pid 856 -D ../

Dump file identified:

process.0x80ff88d8.0xc30000.dmp

Dumping the memory section allowed the suspicious content to be reviewed with additional tools.

4. File Type Review

I used the file command to determine whether the dumped memory section contained an executable format.

Example command:

file process.0x80ff88d8.0xc30000.dmp

This helped determine whether the dumped memory region contained a PE file, shellcode, or another suspicious artifact.

5. Strings Analysis

I used strings against the dumped memory section to identify readable indicators.

Example command:

strings process.0x80ff88d8.0xc30000.dmp

The strings output revealed a suspicious driver path connected to the malware activity.

Suspicious full filename path:

C:\WINDOWS\system32\drivers\str.sys

This artifact stood out because BlackEnergy malware is known for rootkit style behavior and driver loading.

6. SSDT Hook Analysis

Next, I used the ssdt plugin to review System Service Descriptor Table hooks.

Command used:

python vol.py -f ../BlackEnergy.vmem --profile=WinXPSP2x86 ssdt | egrep -v '(ntoskrnl|win32k)'

Filtering out legitimate entries helped highlight suspicious hooks that were not associated with normal Windows kernel modules.

The output showed:

Hooked functions: 14
Hooking module: 00004A2A

This was significant because SSDT hooks are commonly associated with rootkits that intercept system calls to hide files, processes, registry keys, or network activity.

7. Hooking Module Identification

After identifying the suspicious module from SSDT output, I used modscan to locate the module in memory.

Command used:

python vol.py -f ../BlackEnergy.vmem --profile=WinXPSP2x86 modscan | grep "00004A2A"

Module base address:

0xff0d1000

This base address was needed to dump the suspicious driver module from memory.

8. Malicious Driver Dumping

After identifying the base address, I used moddump to extract the suspicious driver from memory.

Command used:

python vol.py -f ../BlackEnergy.vmem --profile=WinXPSP2x86 moddump -b 0xff0d1000 -D ../

This created a driver dump that could be hashed and submitted to threat intelligence sources.

9. SHA256 Hash Generation

I generated a SHA256 hash of the dumped driver.

Command used:

sha256sum driver.ff0d1000.sys

SHA256 hash:

12b0407d9298e1a7154f5196db4a716052ca3acc70becfd25489efd35f6c6ec8

This hash could then be searched in VirusTotal or other threat intelligence platforms to confirm the malware family.

10. Malware Family Confirmation

After hashing the dumped driver, the artifact was enriched through threat intelligence.

The suspicious module was confirmed as related to:

BlackEnergy 2

This aligned with the lab scenario and the rootkit style behavior observed through injected code and SSDT hooks.

MITRE ATT&CK Mapping

Attack Timeline

Key Findings

The investigation found that:

• The memory image contained evidence of injected code
• malfind identified injected code in svchost.exe
• The suspicious process had PID 856
• The injected memory address was 0xc30000
• The dumped memory section was process.0x80ff88d8.0xc30000.dmp
• Strings analysis revealed C:\WINDOWS\system32\drivers\str.sys
• SSDT analysis showed 14 hooked functions
• The hooks were associated with module 00004A2A
• The module base address was 0xff0d1000
• moddump was used to extract the suspicious driver
• The malicious driver hash was 12b0407d9298e1a7154f5196db4a716052ca3acc70becfd25489efd35f6c6ec8
• The malware activity was consistent with BlackEnergy 2 behavior

Defensive Lessons Learned

This lab reinforced several important defensive lessons:

• Memory analysis can reveal malware that may not be obvious on disk
• Injected memory regions are strong indicators of malicious activity
• malfind is useful for identifying suspicious process memory
• Strings analysis can reveal paths, drivers, and configuration clues
• SSDT hooks can indicate rootkit behavior
• Kernel module analysis is important during advanced malware investigations
• Dumped artifacts should be hashed and enriched through threat intelligence
• Rootkit style malware may attempt to hide or intercept system behavior
• Defensive analysts need to understand both user mode and kernel mode evidence

Recommended Defensive Actions

Based on this investigation, recommended actions would include:

• Isolate the affected host
• Preserve memory and disk evidence
• Search endpoints for C:\WINDOWS\system32\drivers\str.sys
• Hunt for SHA256 hash 12b0407d9298e1a7154f5196db4a716052ca3acc70becfd25489efd35f6c6ec8
• Review EDR telemetry for suspicious driver loading
• Alert on unexpected SSDT hooks where possible
• Review kernel module loading events
• Search for BlackEnergy 2 related indicators
• Block known command and control infrastructure if identified
• Reimage the affected host if kernel compromise is confirmed
• Review privileged access and service accounts on the affected system
• Improve malware detection coverage for rootkit style behavior

What This Project Demonstrates

This project demonstrates my ability to:

• Analyze a memory image with Volatility 2
• Identify injected code using malfind
• Dump suspicious memory regions
• Review dumped artifacts with file and strings
• Analyze SSDT hooks for rootkit behavior
• Use modscan to identify suspicious kernel modules
• Use moddump to extract drivers from memory
• Generate SHA256 hashes for malware enrichment
• Connect forensic artifacts to BlackEnergy 2 behavior
• Translate reverse malware engineering findings into defensive recommendations

Disclosure Notice

This writeup is based on an authorized Blue Team Labs Online training environment. It is intended to document the investigation process, lab indicators, and defensive concepts learned.

This page does not include private customer data, employer data, production system information, or unauthorized activity.