Published Date: 13 August 2024 ___ ### Introduction Welcome to the fifth part of my [MemLabs](https://github.com/stuxnet999/MemLabs?tab=readme-ov-file)series which means we're nearing the end. If you haven't already, feel free to take a look at the previous parts which cover the other labs. As always, I will be using [Volatility](https://github.com/volatilityfoundation/volatility)for this lab. > [!Info] CTF Description > We received this memory dump from our client recently. Someone accessed his system when he was not there and he found some rather strange files being accessed. Find those files and they might be useful. I quote his exact statement, > > The names were not readable. They were composed of alphabets and numbers but I wasn't able to make out what exactly it was. > Also, he noticed his most loved application that he always used crashed every time he ran it. Was it a virus? > **Note-1**: This challenge is composed of 3 flags. If you think 2nd flag is the end, it isn't!! :P **Note-3**: You'll get the stage 2 flag only when you have the stage 1 flag. ### Challenge This first command haunts my dreams. As you probably know by now if you've been following along and/or are familiar with `Volatility`, `imageinfo` simply suggests what profile to use. ```shell vol.py -f MemoryDump_Lab5.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/gremlin/memlabs/MemLabs-Lab5/MemoryDump_Lab5.raw) PAE type : No PAE DTB : 0x187000L KDBG : 0xf800028460a0L Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff80002847d00L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2019-12-20 03:47:57 UTC+0000 Image local date and time : 2019-12-20 09:17:57 +0530 ``` The `Win7SP1x64` profile will be our profile of choice for this lab. We'll follow this up with a standard process listing. For the sake of readability, I have excluded most of the irrelevant output which is indicated by the `snip(s)`. ```shell vol.py -f MemoryDump_Lab5.raw --profile=Win7SP1x64 pslist Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit ------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------ [...snip...] 0xfffffa8000f97a20 WinRAR.exe 2924 1580 6 210 2 0 2019-12-20 03:47:13 UTC+0000 0xfffffa80010b8060 notepad.exe 2744 1580 1 57 2 0 2019-12-20 03:47:21 UTC+0000 [...snip...] 0xfffffa800108cb30 NOTEPAD.EXE 2724 1580 1 39 2 1 2019-12-20 03:47:53 UTC+0000 0xfffffa800109f060 svchost.exe 2632 484 7 82 0 0 2019-12-20 03:47:54 UTC+0000 0xfffffa8000ee8060 WerFault.exe 2716 2632 8 161 2 1 2019-12-20 03:47:54 UTC+0000 0xfffffa800221ab30 NOTEPAD.EXE 1388 1580 1 39 2 1 2019-12-20 03:48:00 UTC+0000 0xfffffa8000efbb30 WerFault.exe 780 2632 7 160 2 1 2019-12-20 03:48:01 UTC+0000 0xfffffa8000f02b30 NOTEPAD.EXE 2056 1580 1 226 1 1 2019-12-20 03:48:01 UTC+0000 [...snip...] ``` I’m particularly interested in the `WinRAR.exe` and multiple `NOTEPAD.EXE` processes. As with previous labs, I let the lab description guide my approach to avoid falling down unnecessary rabbit holes. In this case, the description highlights: - Unusual file access - File names that are a jumbled mix of letters and numbers, suggesting possible base64 encoding - Frequent crashes of an application the user was running I'll start by investigating the unusual files. When it comes to examining files and their activity with `Volatility`, there are several plugins for the job. In this circumstance, chose to use the `timeliner` plugin. The `timeliner` plugin creates a chronological timeline of events captured in a memory dump. It aggregates and correlates data from various sources like the Master File Table (MFT), registry hives, and user activities, providing a view of system events over time. This includes file creation, modification, access, process execution, and network activity. I’m hoping this approach will shed light on the 'strange' file access. ```shell vol.py -f MemoryDump_Lab5.raw --profile=Win7SP1x64 timeliner | tee timeliner.out ``` The output of this command is obviously gigantic but as soon as it started to spit out information, something at the top caught my eye. ```shell cat timeliner.out | head -n 150 ``` ![[Pasted image 20240813140640.png]] I understand that this may be hard to read but I will include the specific line of interest in the code block below. ```shell explorer.exe->Visited: Alissa Simpson@file:///C:/Windows/AppPatch/ZmxhZ3shIV93M0xMX2QwbjNfU3Q0ZzMtMV8wZl9MNEJfNV9EMG4zXyEhfQ.bmp ``` It can also be observed in the first line of the screenshot that an `Important.rar` file was accessed. This explains the `WinRAR.exe` process listing we saw earlier. It's clear that this file is what I assumed could be base64 encoding. So we can decode it using CyberChef. ![[Pasted image 20240813141152.png]] > [!check] Flag #1 > flag{!!\_w3LL_d0n3_St4g3-1\_0f\_L4B\_5_D0n3\_!!} The next logical step for me is to look into that `Important.rar` file we saw. > [!error] oops! > I couldn't actually find any reference to a file called `Important.rar`. When I checked back at previous outputs, I saw that there was another `.rar` file accessed called `SW1wb3J0YW50.rar` so I looked for this instead. I gather that some of the labs were created at the same time so there may be references to previous flag paths. We can confirm the existence of `SW1wb3J0YW50.rar` and find its offset. We can use the offset to dump it out using `dumpfiles` as per usual. ![[Pasted image 20240813142037.png]] ```shell vol.py -f MemoryDump_Lab5.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003eed56f0 --dump-dir=dumpedrar ``` We're met with a password prompt upon extraction of the archive. ![[Pasted image 20240813142721.png]] Recall that the description said "*You'll get the stage 2 flag only when you have the stage 1 flag.*" which hints at using the flag as the password like we saw in [[MemLabs Part 2 - A New World]]. Using the first flag as the password unlocks the archive and reveals our second flag. ![[Pasted image 20240813143049.png]] > [!check] Flag #2 > flag{W1th\_th1s\_$taGe\_2\_1s\_c0mPL3T3\_!!} The only other process of interest was `NOTEPAD.EXE`, or one of the `NOTEPAD.EXE` processes at least. Because there were a few, it was simply a process of elimination to find the correct one. So... I racked my brains on this last flag for far too long. I don't really understand why this final flag was even added because it seems really random. I used `procdump` with the PID we obtained from the `pslist` command earlier and was trying several things. With nothing seemingly working, I realised that because `procdump` dumps a Portable Executable of the process, I could just look at it in a disassembler. ```shell vol.py -f MemoryDump_Lab5.raw --profile=Win7SP1x64 procdump -p 2724 --dump-dir . ``` ![[Pasted image 20240813164332.png]] Here you can see the final flag which for some reason uses a different format. It appears like this because it is a stack string. > [!Info] Stack Strings > Stack strings are fragments of data created dynamically during the execution of a program, specifically stored on the call stack. Unlike static strings that are directly embedded in the binary's data sections, stack strings are constructed at runtime through operations such as concatenation or decoding. In this circumstance, `floss` wasn't able to find the stack string. I'm not too familiar with `floss` so I can't say for sure why this is but if you know, please let me know! > [!check] Flag #3 > bios{M3m\_l4B5\_OVeR\_\!} ### Conclusion I'll see you in [[MemLabs Part 6 - The Reckoning]] which is the final part of this series! Thanks for reading—peace.