Hell Spawn 2

Challenge:

What is the MD5 hash of the malicious explorer.exe file from Evil Twin?

Use the file from Captured Memories.

Solution:

Note: During the CTF I was using Volatility2 to complete the memory challenges but I switched to Volatility3 while re-solving them for my write-up's as I wanted to practice with the new interface. While working on this write-up I discovered that I would have been unable to solve this challenge (nor the Public Service challenge) had I used v3 during the CTF. Further details are in the write-up.

From the earlier challenge, Evil Twin, I knew there were two suspicious explorer.exe processes, PIDS 5448 and 3100. I used the –dump option with Volatility3's PsList plugin to dump each of the processes:

$ ~/Tools/volatility3/vol.py -qf mem.raw windows.pslist.PsList --pid 3100 --dump

PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	Dumped
3100	4424	explorer.exe	0x87868f773080	5	-	0	True	2020-06-26 15:48:21.000000 	N/A	True


$ ~/Tools/volatility3/vol.py -qf mem.raw windows.pslist.PsList --pid 5448 --dump

PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	Dumped
5448	3944	explorer.exe	0x878691762080	1	-	0	True	2020-06-26 15:43:14.000000 	N/A	True

I then calculated an MD5 for both process dumps:

$ md5sum pid.*
6b6a1d8695cb6eed9dd0cee629612ff5  pid.3100.0x400000.dmp
767513f77f02ae7949a3c4e27391a2aa  pid.5448.0x400000.dmp

This is where the issue arises that I noted at the beginning of the write-up. Neither of those MD5 hashes matched the hash that I submitted as the flag during the CTF. Below is a quick comparison of the results from procdump from both versions of Volatility.

vol2.py = Volatility Foundation Volatility Framework 2.6.1 vol3.py = Volatility 3 Framework 1.2.1-beta.1

$ vol2.py -f mem.raw --profile=Win10x64_17134 procdump -D . -p 3100
$ vol2.py -f mem.raw --profile=Win10x64_17134 procdump -D . -p 5448

$ md5sum executable.*
  87c76e62bfb56facb510f7808fba8bb2 executable.3100.exe
  360b48f831d9beb41544b45d0aa66b8a executable.5448.exe

$ vol3.py -qf mem.raw windows.pslist.PsList --pid 3100 --dump
$ pid.3100.0x400000.dmp
  6b6a1d8695cb6eed9dd0cee629612ff5  pid.3100.0x400000.dmp
  767513f77f02ae7949a3c4e27391a2aa  pid.5448.0x400000.dmp

During my research on the discrepancy between the dumped processes I found a thread on GitHub specifically for the procdump behavior I was observing. A Volatility developer posted a reply to the thread that shed some light on the issue:

…this is because the volatility3 procdump plugin currently outputs files as if they had been dumped by volatility2 with –memory (ie, it's dumping the memory image, not the reconstructed PE file). I'm not sure what the game plan is for adding support for dumping as the on-disk format rather than the memory format, but I imagine we'll be adding it at some point…

Something to keep in mind during future CTF's as well as forensics for the $DayJob.

Now getting back to the challenge, the completed flag was, flag{360b48f831d9beb41544b45d0aa66b8a}.