Published Date: 7 Aug 2024 ___ ### Introduction This is the second instalment in a six-part series documenting my attempts at the popular memory forensics CTF, [MemLabs](https://github.com/stuxnet999/MemLabs?tab=readme-ov-file). While MemLabs has been around for a while, it remains a fun resource for practicing memory forensics. As in the first part of this series, [[MemLabs Part 1 - Beginner's Luck]], I will be using [Volatility](https://github.com/volatilityfoundation/volatility). > [!info] CTF Description > One of the clients of our company lost the access to his system due to an unknown error. He is supposedly a very popular "environmental" activist. As a part of the investigation, he told us that his go to applications are browsers, his password managers etc. We hope that you can dig into this memory dump and find his important stuff and give it back to us. ### Challenge We previously discussed the importance of selecting the correct operating system profile for Volatility to properly interpret the memory image. It needs to know *where* to look. Once again, the `imageinfo` module is the best way to determine this. ```shell vol.py -f MemoryDump_Lab2.raw imageinfo INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418 AS Layer1 : WindowsAMD64PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/home/remnux/memlabs/memlabs-2/MemoryDump_Lab2.raw) PAE type : No PAE DTB : 0x187000L KDBG : 0xf800027f20a0L Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff800027f3d00L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2019-12-14 10:38:46 UTC+0000 Image local date and time : 2019-12-14 16:08:46 +0530 ``` From the results, we will use the first profile listed under `Suggested Profile(s)` for subsequent commands. In this lab, the description contains the word _environmental_, which led me to consider environment variables. I checked for Volatility modules related to this and found that the `envars` module is suited for the task. ```shell vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 envars [...] 320 csrss.exe 0x0000000000481320 NEW_TMP C:\Windows\ZmxhZ3t3M2xjMG0zX1QwXyRUNGczXyFfT2ZfTDRCXzJ9 [...] 368 csrss.exe 0x0000000000371320 NEW_TMP C:\Windows\ZmxhZ3t3M2xjMG0zX1QwXyRUNGczXyFfT2ZfTDRCXzJ9 [...] 376 psxss.exe 0x0000000000311320 NEW_TMP C:\Windows\ZmxhZ3t3M2xjMG0zX1QwXyRUNGczXyFfT2ZfTDRCXzJ9 [...] 416 winlogon.exe 0x000000000028d890 NEW_TMP C:\Windows\ZmxhZ3t3M2xjMG0zX1QwXyRUNGczXyFfT2ZfTDRCXzJ9 ``` For everyone's sake, I won’t detail every process here, but one particular environment variable stood out. As expected, it was Base64 encoded. > [!done] Flag #1 >flag{w3lc0m3\_T0\_$T4g3\_!\_Of\_L4B\_2} Next, we will examine the processes. Generally, I look for any clues that align with the description provided. ```shell vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 pslist Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit ------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------ [...snip...] 0xfffffa80022e5950 cmd.exe 2096 2664 1 19 2 0 2019-12-14 10:36:35 UTC+0000 0xfffffa8000e63060 conhost.exe 2068 2308 2 50 2 0 2019-12-14 10:36:35 UTC+0000 0xfffffa8002109b30 chrome.exe 2296 2664 27 658 2 0 2019-12-14 10:36:45 UTC+0000 0xfffffa8001cc7a90 chrome.exe 2304 2296 8 71 2 0 2019-12-14 10:36:45 UTC+0000 0xfffffa8000eea7a0 chrome.exe 2476 2296 2 55 2 0 2019-12-14 10:36:46 UTC+0000 0xfffffa8000ea2b30 chrome.exe 2964 2296 13 295 2 0 2019-12-14 10:36:47 UTC+0000 0xfffffa8000fae6a0 chrome.exe 2572 2296 8 177 2 0 2019-12-14 10:36:56 UTC+0000 [...snip...] 0xfffffa800230eb30 chrome.exe 1632 2296 14 219 2 0 2019-12-14 10:37:12 UTC+0000 0xfffffa800101e640 dllhost.exe 2376 588 9 250 1 0 2019-12-14 10:37:40 UTC+0000 0xfffffa800224a8c0 KeePass.exe 3008 1064 12 316 1 0 [...snip...] 0xfffffa80011956a0 notepad.exe 3260 3180 1 61 1 0 2019-12-14 10:38:20 UTC+0000 0xfffffa80011aa060 DumpIt.exe 3844 1064 2 45 1 1 [...snip...] ``` Immediately, we notice several `chrome.exe` processes, which aligns with the information that browsers are one of his main applications. There's also a `notepad.exe` process that might be worth investigating later. However, `KeePass.exe` stands out as something definitely worth examining. Additionally, `cmd.exe` is another process that merits further investigation. > [!info] What is KeePass? > KeePass is a free, open-source password manager that helps users securely store and manage their passwords. It stores passwords in an encrypted database, which can be unlocked with a master password, key file, or both, ensuring all stored passwords are protected from unauthorised access. I had a look for any files related to KeePass using the `filescan` module, but it wasn't very fruitful. The only file of interest was a `.config` file, which, after examination, yielded no useful information. I found a [discussion thread](https://sourceforge.net/p/keepass/discussion/329220/thread/1399ffdf) about KeePass database files. These files are essentially encrypted password stores, meaning that even if someone has access to the database file, they still cannot access the passwords without proper decryption. According to *wellread1* , KeePass database files are typically stored with the `.kdbx` extension for KeePass version 2.x or `.kdb` for KeePass version 1.x. I will assume in our case, the file is of the `.kdbx` format. ```shell vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 filescan | grep .kdbx 0x000000003fb112a0 16 0 R--r-- \Device\HarddiskVolume2\Users\SmartNet\Secrets\Hidden.kdbx ``` This looks promising. We can proceed by dumping the file using the offset as before. ```shell vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fb112a0 --dump-dir keepass_database/ ``` Rename for clarity and so that we can open with KeePass. ![[Pasted image 20240807150044.png]] We already know the file will be encrypted and likely won’t be accessible without a password. Nevertheless, I double-checked to be sure. ![[Pasted image 20240807150256.png]] It was worth a try. Now, we need to find the password. In CTF challenges, searching for terms like `username` or `password` often yields results about 50% of the time. ![[Pasted image 20240807150520.png]] Great, `Password.png` looks promising. As always, use the `dumpfiles` command with the appropriate offset to extract it. ```shell vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fce1c70 --dump-dir keepass_database/ ``` Use `file` to confirm the `.png` filetype. ![[Pasted image 20240807150940.png]] ![[Pasted image 20240807151039.png]] Honestly, this is like something straight out of Scooby-Doo episode. I also have no idea why the image width is unusually... wide. Anyway, there's a password is in the bottom right corner that grants us access to the KeePass database. As you can see, there are several passwords in the `General` tab and also in the `Recycle Bin`. Spoiler alert: none of these are what we're looking for, but since I'm easily amused I checked them all anyway. ![[Pasted image 20240807151831.png]] The second flag is among these. ```shell nothing here bro not here bro :) your princess is in another castle boom boom :) Password 12345 flag{w0w_th1s_1s_Th3_SeC0nD_ST4g3_!!} ``` > [!done] Flag #2 >flag{w0w\_th1s\_1s\_Th3\_SeC0nD\_ST4g3\_!!} For the final flag, the `chrome.exe` process is our next focus. I couldn’t find a built-in Volatility module that would be useful for this, so I looked online for any relevant plugins. I came across a GitHub [repository](https://github.com/superponible/volatility-plugins) with a plugin called `chromehistory`, which seemed to be what I needed. I decided to give it a try. > [!tip] > It is necessary to specify the location of the plugin once downloaded. I believe you can just dump it into the directory that the default plugins are stored in but I haven't checked this. ```shell vol.py --plugins=../../vol_plugins/ -f MemoryDump_Lab2.raw --profile=Win7SP1x64 chromehistory ``` The output is shown below. ![[Pasted image 20240807152913.png]] The third URL from the top stands out. Navigating to it, we can download an `Important.zip`. Trusting the creator of this CTF, I went ahead and downloaded it. I proceeded to attempt extraction and saw this. ```shell remnux@remnux:~/Downloads/MemLabs_Lab2_Stage3$ unzip Important.zip Archive: Important.zip Password is SHA1(stage-3-FLAG) from Lab-1. Password is in lowercase. skipping: Important.png unsupported compression method 99 ``` The flag it's referring to is: `flag{w3ll_3rd_stage_was_easy}`. We just need to calculate the `SHA1` hash for it and then pass it into the archive. I tried extracting with `unzip` by providing the password as an argument but it wasn't working so I tried other tools and eventually got `7zip` to work. ```shell 7z -p6045dd90029719a039fd2d2ebcca718439dd100a e Important.zip ``` Extraction drops an image which reveals the final flag. ![[Pasted image 20240807154139.png]] > [!done] Flag #3 >flag{oK\_So\_Now\_St4g3\_3\_is\_DoNE!!} ### Conclusion I'll see you in [[MemLabs Part 3 - The Evil's Den]]. Thanks for reading—peace.