nonyx investigation
Investigation
A memory dump (SHA256: 50d9866adc908508c85517d2d1f55847ec52080b7244c13960a3ef9f4aa98c2a
) of the infected system is available for analysis. As this is a public available dump from the Malware Analysts Cookbook, it can be downloaded to a dedicated workstation too - without working in the constrained btlo lab. When working in the lab, volatility is installed with the note that the profile WinXPSP2x86
is the profile you must use. This can be verified using the imageinfo command.
python volatility/vol.py -f BlackEnergy.vnem imageinfo
Volatility Foundation Volatility Framework 2.
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/home/ubuntu/Desktop/BlackEnergy.vnem)
PAE type : PAE
DTB : 0x31
KDBG : 0x80544ce0L
Number of Processors : 1
Image Type (Service Pack) : 2
KPCR for CPU 0 : 0xffdff000L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2010-08-15 19:22:11 UTC+0000
Image local date and time : 2010-08-15 15:22:11 -0400
Question Q1
Question: Which process most likely contains injected code, providing its name, PID, and memory address?
To check the memory dump for possible injected code in processes, volatility2 offers the malfind command.
python volatility/vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 malfind --output-file vol2.malfind && cat vol2.malfind
[...SNIP...]
Process: svchost.exe Pid: 856 Address: 0xc30000
Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 9, MemCommit: 1, PrivateMemory: 1, Protection: 6
One of the results stands out — the svchost
process with PID 856 has a memory region that is both writable and executable, and it also begins with the MZ
(4d 5a) header of a Windows executable. This was detected because the executable is not listed in the PEB’s module lists.
0x0000000000c30000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0x0000000000c30010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
0x0000000000c30030 00 00 00 00 00 00 00 00 00 00 00 00 f8 00 00 00 ................
Question Q2
Question: What dump file in the malfind output directory corresponds to the memory address identified for code injection?
To further investigate this injected executable, the -D
flag of the malfind command can be used to dump the identified memory segments into a folder.
python volatility/vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 malfind -D . && ls
process.0x80ff88d8.0xc30000.dmp
process.0xff1ec978.0x33470000.dmp
process.0xff1ec978.0x71ee0000.dmp
process.0xff1ec978.0x793e0000.dmp
process.0xff1ec978.0x2c930000.dmp
process.0xff1ec978.0x37ec0000.dmp
process.0xff1ec978.0x78850000.dmp
process.0xff1ecda0.0x7f6f0000.dmp
From the info shown in Q1 of the malfind command, the address 0xc30000
for the suspicious region can be derived, along with the filename process.0x80ff88d8.0xc30000.dmp
for further investigation.
Question Q3
Question: 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)?
Limited by the installed tools and capabilities of the lab environment, a simple extraction of strings from the PE file from Q2 is performed, using grep to search for a Windows file path (identified by :\
following the drive letter).
strings process.0x80ff88d8.0xc30000.dmp | grep ':\\'
C:\WINDOWS\system32\drivers\str.sys
Question Q4
Question: 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)’?
To list the functions in the Native and GUI SSDTs, the ssdt command can be used to display the index, function name, and owning driver for each entry in the SSDTs. The result of the command is temporarily saved using the --output-file vol2.ssdt
flag and can subsequently be filtered using the mentioned regex and egrep. This command excludes any entries whose owning driver is ntoskrnl (kernel) or win32k (graphics device interface). What remains are entries hooked or replaced by third-party drivers, potentially malicious rootkits.
python volatility/vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 ssdt --output-file vol2.ssdt
egrep -v '(ntoskrnl|win32k)' vol2.ssdt
SSDT[0] at ff3aab90 with 284 entries
Entry 0x0041: 0xff0d2487 (NtDeleteValueKey) owned by 00004A2A
Entry 0x0047: 0xff0d216b (NtEnumerateKey) owned by 00004A2A
Entry 0x0049: 0xff0d2267 (NtEnumerateValueKey) owned by 00004A2A
Entry 0x0077: 0xff0d20c3 (NtOpenKey) owned by 00004A2A
Entry 0x007a: 0xff0d1e93 (NtOpenProcess) owned by 00004A2A
Entry 0x0080: 0xff0d1f0b (NtOpenThread) owned by 00004A2A
Entry 0x0089: 0xff0d2617 (NtProtectVirtualMemory) owned by 00004A2A
Entry 0x00ad: 0xff0d1da0 (NtQuerySystemInformation) owned by 00004A2A
Entry 0x00ba: 0xff0d256b (NtReadVirtualMemory) owned by 00004A2A
Entry 0x00d5: 0xff0d2070 (NtSetContextThread) owned by 00004A2A
Entry 0x00f7: 0xff0d2397 (NtSetValueKey) owned by 00004A2A
Entry 0x00fe: 0xff0d201d (NtSuspendThread) owned by 00004A2A
Entry 0x0102: 0xff0d1fca (NtTerminateThread) owned by 00004A2A
Entry 0x0115: 0xff0d25c1 (NtWriteVirtualMemory) owned by 00004A2A
SSDT[0] at 80f162d0 with 284 entries
Entry 0x0041: 0xff0d2487 (NtDeleteValueKey) owned by 00004A2A
...
Question Q5
Question: 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?
To map the name above to a driver volatility has a command (modules) to list kernel drivers loaded on the system. The output can be saved to a file for further investigaion with the --output-file vol2.modules
flag and subsequently the output can be searched for the known 00004A2A
name.
python volatility/vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 modules --output-file vol2.modules
sed -n '1,2p;3,$p' vol2.modules | { head -n 2; tail -n +3 | grep "00004A2A"; }
Offset(V) Name Base Size File
---------- -------------------- ---------- ------ ----
0xff375b08 00004A2A 0xff0d1000 0x8361 00004A2A
Question Q6
Question: What is the hash for the malicious driver from the virtual memory image?
With the previously identified address, the driver in question can be carved out of the memory dump. The required checksum can then be generated using the sha256sum command.
python volatility/vol.py -f BlackEnergy.vnem --profile=WinXPSP2x86 moddump -b 0xff0d1000 --dump-dir .
sha256sum driver.ff0d1000.sys
12b0407d9298e1a7154f5196db4a716052ca3acc70becf2d5489efd35f6c6ec8 dump/driver.ff0d1000.sys
TL;DR
svchost.exe, 856, 0xc30000
process.0x80ff88d8.0xc30000.dmp
C:\WINDOWS\system32\drivers\str.sys
14, 00004A2A
0xff0d1000
12b0407d9298e1a7154f5196db4a716052ca3acc70becf2d5489efd35f6c6ec8