\n\nThis page has been machine-translated from the original page.
\n
In this post, using the Hero CTF 2023 forensic challenge “Windows Stands for Loser” as a case study, I’ll share what I learned about analyzing Windows memory dumps with Volatility.
\nThe writeups for the other challenges are below.
\nReference: Hero CTF 2023 Writeup - Frog’s Secret Base
\n\n\n\nThis time, no realistic context, we just need you to find the commands that were executed and the time. (we don’t talk about windows commands here :p) (time to find : UTC+2)\nFormat: Hero{secret:dd/mm/YYYY-hh:mm:ss}\nAuthor: Malon
\n
If you inspect the provided challenge file memdump.mem with the strings command, you can tell that it appears to be a memory dump from a Windows machine.
However, it was not a crash dump file that could be opened with WinDbg. (Maybe it was acquired with FTK Imager?)
\nFor now, I decided to solve the challenge while trying a few Volatility3 options to see what kind of information it contains.
\n\nRunning Volatility3 Commands (Windows)
\nFirst, let’s run a few basic commands and inspect the memory information.
\nAll of the commands used here are for analyzing Windows memory dumps.
\nWhen collecting information from memory on Linux and similar systems, use dedicated commands like those in the Linux Tutorial.
\nYou can inspect OS information with the following command.
\nvol3 -f memdump.mem windows.info.InfoThe output looked like this.
\nYou can get a list of processes from memory with the following commands.
\n# You can also filter like --filters \"ImageFileName,chrome.exe\"\nvol3 -f memdump.mem windows.pslist.PsList\nvol3 -f memdump.mem windows.psscan.PsScanThe output looked like this.
\nWhen I looked for anything other than default programs or any unfamiliar processes, I found the following.
\n5768 1464 ubuntu2204.exe\n8888 5128 bash\n5464 8020 FTK Imager.exeFTK Imager is fine, but this tells us the environment is running WSL.
PsScan can also produce equivalent output.
There also appears to be a PsTree plugin that can display process information in tree form.
vol3 -f memdump.mem windows.pstree.PsTreeThat gave the following information.
\nFurthermore, you can collect command-line information for processes running in the system from memory.
\nYou can enumerate command lines with the following command.
\nvol3 -f memdump.mem windows.cmdline.CmdLineThe output is also quite readable.
\nAlso, the following command lets you dump an entire process’s memory.
\nDepending on the size of the memory image, output may take a little while.
\n# vol3 -o <output path> -f memdump.mem windows.memmap --dump --pid <PID>\nvol3 -o /tmp -f memdump.mem windows.memmap --dump --pid 1000With the PsList plugin, you can not only enumerate processes but also retrieve a process image file.
# vol3 -o <output directory> -f memdump.mem windows.pslist.PsList --pid <process PID> --dump\nvol3 -o /tmp -f memdump.mem windows.pslist.PsList --pid 6724 --dumpWhen you run the above command, the specified process can be dumped as shown below.
\nAlthough the extension is shown as .dmp, it is actually dumped as a PE file.
With the following command, you can obtain the addresses and full paths of file objects from memory.
\nThe output is very large.
\nvol3 -f memdump.mem windows.filescan.FileScanFor this challenge memory image, you can identify paths for files inside WSL under the jane user folder.
You can also use the address identified here to retrieve the file from memory.
\nIn the command example below, the .bashrc file inside WSL located at 0xa38f15daa4d0 is saved to a tmp directory.
# vol3 -o <output directory> -f memdump.mem windows.dumpfiles.DumpFiles --virtaddr <virtual address of the file object>\nvol3 -o /tmp -f memdump.mem windows.dumpfiles.DumpFiles --virtaddr 0xa38f15daa4d0When retrieval succeeds, it is displayed as follows.
\nWhen I inspected the retrieved file, I confirmed that .bashrc had indeed been extracted from the memory dump.
You can enumerate object handles with the following command.
\nvol3 -f memdump.mem windows.handles.HandlesVolshell3 works as an interactive interface for analyzing memory dumps, and can be operated much like a Python interpreter.
\nReference: Volshell - A CLI tool for working with memory — Volatility 3 2.4.2 documentation
\nTo analyze a Windows memory dump with Volshell3, run the following command.
\nvolshell3 -f memdump.mem -wThe -w option is important because it tells Volshell3 to use known symbols; without it, you won’t be able to inspect most information.
When Volshell3 starts, you see a screen like this.
\nAfter using Volatility to understand the system’s basic information, I started solving the challenge. In this challenge, the flag appears to consist of some command found in memory and the time it was executed. However, nothing that looked like a flag appeared in the information enumerated by the So I focused on the WSL process running in the system. According to the page cited in the writeup below, even for a WSL bash process, it seems possible to search in-memory information using the same commands as on normal Linux. Reference: Memory forensics and the Windows Subsystem for Linux - ScienceDirect Also, Volatility’s Reference: Volatility Labs: MoVP II - 3.3 - Automated Linux/Android Bash History Scanning Reference: Linux Tutorial — Volatility 3 2.4.2 documentation In other words, if we can run the As confirmed with the As described in Volume 1 of Windows Internals, WSL1 uses interfaces provided by the PICO providers Processes running under a Pico provider are managed as Pico processes. Memory for processes provided under WSL’s Pico provider contains structures similar to Linux’s Reference: I Took a Quick Look at the Implementation of VDSO(arm) - Qiita As shown in the image below, WSL Source: Windows Internals, 7th Edition (Part 1) The Pico provider has functions to create and terminate Pico processes and threads, and it receives callbacks when Pico threads make syscalls or raise exceptions. As a result, Pico processes running under a Pico provider are encapsulated and wrapped as shown below. Source: Windows Internals, 7th Edition (Part 1) For example, you can enumerate the However, as mentioned above, this bash process is a Pico process encapsulated by a Pico provider, so it does not have PEB information. Honestly, from here it became completely impossible for me to proceed on my own, so I followed along with the writeup’s explanation. Reference: HeroCTFv5/README.md at main · HeroCTF/HeroCTFv5 · GitHub First, dump the memory space of the bash process running as PID When I ran the As mentioned earlier, Volatility’s However, since what I extracted this time was only the bash process’s memory space, I couldn’t simply use that plugin as-is. Here, the following page explains how Reference: Volatility Labs: MoVP II - 3.3 - Automated Linux/Android Bash History Scanning To obtain command history from a bash process, it first scans the entire bash process, then finds The Reference: history(3): GNU History Library - Linux man page Next, subtracting 8 bytes from those timestamp addresses gives the base address of the Finally, you enumerate all After that, I manually followed the above procedure against the dumped bash process memory. First, search the entire process for the When I ran the script above, there was a lot of noise, but I found the following three timestamps and their offsets. Next, after determining the virtual addresses corresponding to these timestamp offsets, I found pointers referencing those addresses and used them to identify the base addresses of the The mapping between offsets in the extracted memory dump and loaded virtual addresses can be referenced from the output of This let me identify the addresses that hold pointers to the timestamps. In other words, I could determine that the address written in the preceding 8 bytes is a pointer to the command-line string contained in the Finally, I used the identified virtual addresses of the First, I changed the context to the bash process with the This allowed me to identify the executed command line and the timestamp, and I obtained the flag. For some reason, however, the Reference: Command Reference · volatilityfoundation/volatility Wiki Reference: Volatility 3 CheatSheet - onfvpBlog [Ashley Pearson] The challenge I used as the theme this time was quite difficult, and only 3 teams solved it. I think it was a great challenge that broadened the ways I can use Volatility and taught me a lot. I want to become a forensic investigator.Analyzing the Challenge File
\nCmdLine plugin.linux_bash can apparently scan a bash process heap to easily search execution history.linux_bash plugin against a bash process running under WSL, we should be able to identify the executed commands.Investigating the WSL Process
\nInfo plugin at the beginning, this system’s build is 20H1, so we know the running WSL version is 1.Lxss.sys and Lxcore.sys (kernel drivers that obtain access to kernel interfaces using the PsRegisterPicoProvider API).vDSO (Virtual Dynamic Shared Object)./bin/bash runs as a Pico process managed by a Pico provider.EPROCESS structure information for the bash process with either of the following commands.# 8888 5128 bash 0xa38f11b8a080\nproc = ps()\nfor p in proc:\nif p.UniqueProcessId == 8888:\nprint(dt(p))\n\n# 8888 5128 bash 0xa38f11b8a080ｆ\ndt(\"_EPROCESS\",0xa38f11b8a080)Manually Analyzing the bash Process Memory
\n8888 with the following command.vol3 -o /tmp -f memdump.mem windows.memmap --dump --pid 8888 file command on the dumped file, it was recognized as glibc locale file LC_CTYPE.linux_bash plugin can extract command execution history from Linux memory dumps.linux_bash works:\n
\n\n
\n# characters in heap segments, and from there identifies the timestamps in _hist_entry structures._hist_entry structure contains the entered command-line string, the execution timestamp, and other data._hist_entry structure._hist_entry structures in memory in timestamp order to collect the command execution history from memory.# character, then look for UNIX timestamps in memory.import os\ni = 0\nmemdump = \"./pid.8888.dmp\"\nwith open(memdump, \"rb\") as f:\n# Read the file one byte at a time and check whether # exists\n while i < os.path.getsize(memdump):\n diese = f.read(1)\n if not diese:\n break\n# Advance until the # character is found\n if diese == b\"\\x23\":\n one = f.read(1) \n \n# Since the target is a UNIX timestamp, the first digit must always be 1\n if one == b\"\\x31\": # \"1\"\n# Once a timestamp is found, read the next 9 bytes and write them to a file\n next_data = f.read(9) \n with open(\"./8888_extracted_info.txt\", \"a\") as f2:\n f2.write(f\"offset: {hex(i)} - #1\")\n for byte in next_data:\n f2.write(f\"{chr(byte)}\")\n f2.write(f\"\\n\")\n i+=9\n i+=1\n i += 1offset: 0x30a100 - #1683741543\noffset: 0x362d30 - #1683741570\noffset: 0x376d10 - #1683741539_hist_entry structures.vol3 -o /tmp -f memdump.mem windows.memmap --dump --pid 8888 shown earlier._hist_entry structure.Retrieving Values from Virtual Addresses with Volshell
\n_hist_entry structures to dump raw data from memory and obtain the command-line information.cc command, then used db to retrieve information at the virtual address.# cc(offset=None, pid=None, name=None) : Change current shell context.\ncc(pid=8888)\n\n# >>> db(0x00007fffecabc4c0) /!\\ you can ask to display more bits\n>>> db(0x00007fffecabc4c0,200)\n0x7fffecabc4c0 65 63 68 6f 20 4b 48 42 73 5a 57 46 7a 5a 53 42 echo.KHBsZWFzZSB\n0x7fffecabc4d0 6b 62 32 34 6e 64 43 42 6d 61 57 35 6b 49 47 31 kb24ndCBmaW5kIG1\n0x7fffecabc4e0 6c 49 48 64 70 64 47 67 67 64 47 68 6c 49 43 4a lIHdpdGggdGhlICJ\n0x7fffecabc4f0 7a 64 48 4a 70 62 6d 64 7a 49 69 42 6a 62 32 31 zdHJpbmdzIiBjb21\n0x7fffecabc500 74 59 57 35 6b 4c 43 42 30 61 47 56 79 5a 53 42 tYW5kLCB0aGVyZSB\n0x7fffecabc510 70 63 79 42 68 49 47 5a 31 62 6d 35 70 5a 58 49 pcyBhIGZ1bm5pZXI\n0x7fffecabc520 67 62 57 56 30 61 47 39 6b 4b 53 35 55 61 47 55 gbWV0aG9kKS5UaGU\n0x7fffecabc530 67 63 32 56 6a 63 6d 56 30 49 47 6c 7a 49 44 6f gc2VjcmV0IGlzIDo\n0x7fffecabc540 67 64 7a 56 73 58 7a 42 75 4d 77 3d 3d 20 7c 20 gdzVsXzBuMw==.|.\n0x7fffecabc550 62 61 73 65 36 34 20 2d 64 00 ab ec ff 7f 00 00 base64.-d.......\n\n>>> db(0x00007fffecabed30)\n0x7fffecabed30 23 31 36 38 33 37 34 31 35 37 30 00 00 00 00 00 #1683741570.....cc command raises an error in Volshell3, so I used Volatility 2 only for this part.Summary
\n