Captured Memories
We found some unusual activity coming from an employee's Windows 10 workstation at De Monne Financial. Our IT guy saved the memory dump to the file provided below. What was the PID of the program used
For this challenge, you get given a mem.raw
file. So initially this along with the title screams memory forensics and so the main program that comes to mind is Volatility, if unfamiliar with this tool, it can be best described as a memory forensics tool to help you look at memory captures of RAM. This tool should be automatically installed on Kali, but other distros should follow install instructions found on the GitHub page (linked above).
It is worth noting I used Volatility 2
in this writeup, the syntax for Volatility 3
is similar, just replace volatility
with vol3
it could also be worth noting that depending on your install, you might need to run it as volatility.py
So to start with you run the following command with a memdump/raw format, the imageinfo
plugin will provide basic information on the memory capture:
volatility -f mem.raw imageinfo > raw_imageinfo.txt
Breaking this command down we have the name of the program volatility
followed by -f
which tells volatility to take in the file mem.raw
, then as outlined above the imageinfo
plugin gives us basic information on the image. I then personally followed it with > raw_imageinfo.txt
just so I have it saved in a text file should i need it earlier. This is not essential, however i reccomend it, especially for when Volatility can have a lot of input, it also gives you the power of tools like grep
and awk
.
Volatility Foundation Volatility Framework 2.6.1
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win10x64_17134, Win10x64_14393, Win10x64_10586, Win10x64_16299, Win2016x64_14393, Win10x64_17763, Win10x64_15063 (Instantiated with Win10x64_15063)
AS Layer1 : SkipDuplicatesAMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/home/REDACTED/Downloads/mem.raw)
PAE type : No PAE
DTB : 0x1aa000L
KDBG : 0xf8001e43d520L
Number of Processors : 2
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0xfffff8001d4e2000L
KPCR for CPU 1 : 0xffffd40032268000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2020-06-26 15:51:36 UTC+0000
Image local date and time : 2020-06-26 08:51:36 -0700
Then we take the profile, normally we take the first however it won't always work, luckily ,in this case, it was the first profile which is Win10x64_1734
.
We then run the following command as we were told we needed the PID
so automatically i decided to look at the processes, now this can be done with either the pstree
plugin or the pslist
plugin, the difference is mainly that pstree
gives us a more visual representation of which process was launched by which, whereas pslist
lists them all. I chose pstree
, the command is shown below:
volatility -f raw.mem --profile=Win10x64_1734 pstree > raw_pstree.txt
Breaking this down, we have the volatility -f raw.mem
as I mentioned before which initialises Volatility along with specifying the file. The big difference here is that we now specify a profile as shown by the --profile=Win10x64_1734
part of our command, when we ran imageinfo
we took the profile and now we need to specify it to Volatility to run further plugins. The next part of our command is pstree
which as outlined above creates a tree of all processes on the system. I then also save this in a file again with > raw_pstree.txt
which helps me with things like grep but also means I only need to run this command once. Below is a shortened output for the sake of the writeup:
Name Pid PPid Thds Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
0xffff87868e88d440:System 4 0 111 0 2020-06-26 15:07:32 UTC+0000
. 0xffff878690147040:smss.exe 348 4 2 0 2020-06-26 15:07:32 UTC+0000
. 0xffff87868e975040:Registry 88 4 3 0 2020-06-26 15:07:23 UTC+0000
. 0xffff878690ccc040:MemCompression 1168 4 50 0 2020-06-26 15:07:58 UTC+0000
0xffff878690495080:wininit.exe 528 424 1 0 2020-06-26 15:07:45 UTC+0000
. 0xffff8786904cd080:services.exe 648 528 6 0 2020-06-26 15:07:46 UTC+0000
.. 0xffff8786914d2580:TrustedInstall 2572 648 5 0 2020-06-26 15:43:20 UTC+0000
.. 0xffff878690c8d580:svchost.exe 1052 648 18 0 2020-06-26 15:07:58 UTC+0000
.. 0xffff878690c2d580:svchost.exe 60 648 64 0 2020-06-26 15:07:56 UTC+0000
... 0xffff8786909b0580:sihost.exe 2672 60 15 0 2020-06-26 15:08:51 UTC+0000
... 0xffff87868fa02580:wuauclt.exe 5288 60 7 0 2020-06-26 15:43:18 UTC+0000
... 0xffff8786909e1580:taskhostw.exe 2764 60 10 0 2020-06-26 15:08:52 UTC+0000
Now if we scroll down we see the below process:
.... 0xffff87868f2e1080:winpmem_v3.3.r 3348 784 5 0 2020-06-26 15:51:36 UTC+0000
I assumed this was the process as we know it was a Windows system from the challenge description. So for the flag, we simply took the PID
which was 3348
, which we then submitted as the flag in the form specified which was: flag{3348}
.
Writeup created by Chris Harris (cjharris).
Last updated
Was this helpful?