Hell Spawn 2
What is the MD5 hash of the malicious
explorer.exefile from Evil Twin?
Use the file from Captured Memories.
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,
Leave a comment