Hi There, welcome to this WriteUp of BlackEnergy, a challenge on Cyberdefenders.org.
In this challenge, we are tasked with analyzing a memory dump of a machine that has been infected with a never-before-seen variant of the notorious BlackEnergy v2 malware. Our goal is to uncover the scope and impact of the attack that was carried out against a multinational corporation, which resulted in the theft of sensitive data.
(BlackEnergy is an actual malware strain, Although I didn’t leverage this information for this challenge, there are various blogs on the internet that might give you a hint or two)
We’re presented with a .raw file, and according to the questions, we probably need some volatility. I use the volatility2 standalone exe, obtained from here. I also like to use this cheatsheet and the official command reference.
Let’s dive in!
1. Which volatility profile would be best for this machine?
One of the initial steps in analyzing a memory dump with Volatility2 is to determine the profile of the system from which the memory dump was obtained. This step is crucial because it enables Volatility2 to accurately interpret the data in the memory dump.
This can be done with the command
$ volatility_2.6_win64_standalone.exe -f CYBERDEF-567078-20230213-171333.raw imageinfo INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : <Answer>, WinXPSP3x86 (Instantiated with WinXPSP2x86) AS Layer1 : IA32PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (C:\Users\johndoe\Desktop\c79-BE\CYBERDEF-567078-20230213-171333.raw) PAE type : No PAE DTB : 0x39000L KDBG : 0x8054cde0L Number of Processors : 1 Image Type (Service Pack) : 3 KPCR for CPU 0 : 0xffdff000L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2023-02-13 18:29:11 UTC+0000 Image local date and time : 2023-02-13 10:29:11 -0800
After running the profile plugin in Volatility2, the tool will typically suggest a list of possible profiles based on the characteristics of the memory dump. The first profile in the list is usually the most likely one, but it’s important to note that the other profiles can be useful if a command returns incorrect data.
In such cases, you can try switching to a different profile and rerunning the command to see if it yields more accurate results. This can be especially useful if the target system has been customized or uses an unusual configuration that is not covered by the default profiles provided by Volatility2.
However, it’s worth noting that selecting the correct profile can be a bit of a trial-and-error process, and it may take some experimentation to determine which profile works best for your particular memory dump. That said, once you have identified the correct profile, you can use Volatility2 to extract a wealth of information from the memory dump and gain valuable insights into the target system and any malware that may have been present.
2. How many processes were running when the image was acquired?
To determine how many processes were running when the memory dump was acquired, we can use the Volatility2 plugin,
psxview. This plugin lists all the processes in the memory dump and provides information about their parent process, process ID, and other attributes.
Make sure to use the profile found in question one. Also read the question again, if you’re not getting an acceptable answer.
$ volatility_2.6_win64_standalone.exe -f CYBERDEF-567078-20230213-171333.raw --profile <Profile> pslist Volatility Foundation Volatility Framework 2.6 Offset(P) Name PID pslist psscan thrdproc pspcid csrss session deskthrd ExitTime ---------- -------------------- ------ ------ ------ -------- ------ ----- ------- -------- -------- 0x09a88da0 winlogon.exe 616 True True True True True True True 0x09aa0020 lsass.exe 672 True True True True True True True 0x0994a020 msmsgs.exe 636 True True True True True True True 0x097289a8 svchost.exe 1108 True True True True True True True 0x09982da0 VBoxTray.exe 376 True True True True True True True <snip> 0x099adda0 svchost.exe 1156 True True True True True True True 0x09938998 services.exe 660 True True True True True True True 0x0969d2a0 alg.exe 540 True True True True True True True 0x09a0fda0 DumpIt.exe 276 True True True True True True True 0x09733938 explorer.exe 1484 True True True True True True True 0x09a0d180 notepad.exe 1432 True True False True False False False 2023-02-13 18:28:40 UTC+0000 0x09a18da0 cmd.exe <snip> True True False True False False False 2023-02-13 18:25:26 UTC+0000 0x099e6da0 notepad.exe 1444 True True False True False False False 2023-02-13 18:28:47 UTC+0000 0x096c5020 notepad.exe 528 True True False True False False False 2023-02-13 18:27:46 UTC+0000 0x099dd740 rootkit.exe 964 True True False True False False False 2023-02-13 18:25:26 UTC+0000 0x09c037f8 System 4 True True True True False False False 0x09a98da0 csrss.exe 592 True True True True False True True 0x09a0b2f0 taskmgr.exe 1880 True True False True False False False 2023-02-13 18:26:21 UTC+0000 0x09965020 smss.exe 368 True True True True False False False
3. What is the process ID of cmd.exe?
To find the PID of cmd.exe at the time of the memory dump, we can look at the PID column in the output of the
psxview command from the previous question.
4. What is the name of the most suspicious process?
Back in the list, we find a very obvious malicious name. There are no more hints to give here 🙂
5. Which process shows the highest likelihood of code injection?
malfind plugin in Volatility2 can help identify any suspicious behavior in the memory dump. By examining this command’s output, we can locate an executable that appears more obviously malicious than the others.
6. There is an odd file referenced in the recent process. Provide the full path of that file.
To identify the recent process and investigate its behavior, we can use Volatility2’s
handles plugin. By appending
-t file to the command, we can filter for files associated with the process. We can assume that the recent process corresponds to the one identified in question 5.
The following command can be used to retrieve the handles for the recent process:
volatility_2.6_win64_standalone.exe -f CYBERDEF-567078-20230213-171333.raw --profile WinXPSP2x86 handles -p <pid_from_question_5> -t file
There is a certain file in there that’s placed in a folder which can drive you mad 😉
7. What is the name of the injected DLLfile loaded from the recent process?
One command that’s not included in the previously mentioned cheatsheet is
ldrmodules, which can be used to list dynamic link libraries (DLLs) in a Wow64 process. By running this command, we may be able to identify any suspicious DLLs.
Upon examining the output, we notice a DLL that stood out from the rest and is our answer.
volatility_2.6_win64_standalone.exe -f CYBERDEF-567078-20230213-171333.raw --profile WinXPSP2x86 -p 880 ldrmodules Volatility Foundation Volatility Framework 2.6 Pid Process Base InLoad InInit InMem MappedPath -------- -------------------- ---------- ------ ------ ----- ---------- 880 svchost.exe 0x6f880000 True True True \WINDOWS\AppPatch\AcGenral.dll 880 svchost.exe 0x01000000 True False True \WINDOWS\system32\svchost.exe <snip> 880 svchost.exe 0x77120000 True True True \WINDOWS\system32\oleaut32.dll 880 svchost.exe 0x5cb70000 True True True \WINDOWS\system32\shimeng.dll 880 svchost.exe 0x74980000 True True True \WINDOWS\system32\msxml3.dll 880 svchost.exe 0x009a0000 False False False <answer> <snip>
8. What is the base address of the injected DLL?
It would be too easy if the
Base value from the previous question was the answer right?
Let’s circle back, the DLL is malicious, and we’ve run
malfind before, maybe this contains the address for the injected DLL?
Process: <malicious process>.exe Pid: <other answer> Address: <answer> Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
PAGE_EXECUTE_READWRITE indicates possible execution of code from the address, there is much more to it, but for this challenge all we need. The Address answer to the final question.
Thank you for reading this write-up of the BlackEnergy challenge on Cyberdefenders.org. Though the challenge wasn’t particularly difficult, it was still enjoyable to explore the memory dump and uncover clues using Volatility. We covered several commands, including
ldrmodules, and learned how to analyze processes and identify suspicious code. I hope this write-up was helpful and informative.
See ya at the next one!