Published Date: 12 August 2024 ___ ### Introduction Welcome to the fourth part of my [MemLabs](https://github.com/stuxnet999/MemLabs?tab=readme-ov-file) series. If you haven't already been following along, I recommend taking a look at the previous parts as I may skip over any command explanations. As always, I will be using [Volatility](https://github.com/volatilityfoundation/volatility)for this lab. Without further ado, lets get started. > [!Info] CTF Description > My system was recently compromised. The Hacker stole a lot of information but he also deleted a very important file of mine. I have no idea on how to recover it. The only evidence we have, at this point of time is this memory dump. Please help me. Similar to [[MemLabs Part 3 - The Evil's Den]], this lab only contains one flag. ### Challenge Immediately, we'll read the provided description and take note of anything that may be a hint or a clue. It says that a *"very important file"* was deleted and the user has no idea how to recover it. Based on this, I will assume that the flag is located inside this file. In this case, recovering the *"very important file"* will be our primary objective. This first command will be second nature by now. ```shell vol.py -f MemoryDump_Lab4.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-Lab4/MemoryDump_Lab4.raw) PAE type : No PAE DTB : 0x187000L KDBG : 0xf800027f60a0L Number of Processors : 1 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff800027f7d00L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2019-06-29 07:30:00 UTC+0000 Image local date and time : 2019-06-29 13:00:00 +0530 ``` We know to use the `Win7SPX64` profile throughout. In the previous labs, my approach was to check for curious processes by using `pslist`. However, in this case I decided not to bother after doing some research about the [[#Master File Table]]. I came across an article after googling for *"recover deleted files volatility"* and what I took away from reading is discussed in the next sections. ### Master File Table The Master File Table (MFT) is a component of the NTFS (New Technology File System) used by Windows operating systems to manage files on a disk. Acting as the system's central directory, the MFT stores detailed information about every file and folder, including metadata like file name, size, creation date, and file permissions. Each file on the NTFS volume has an entry in the MFT, which helps the system quickly locate and access files, improving efficiency and performance. Essentially, the MFT acts like a map that keeps NTFS running smoothly and ensures that data is organised and retrievable. In the case of NTFS, when a file is deleted, the data isn't immediately erased from the disk; instead, the file's entry in the MFT is marked as available for overwriting, while the actual data remains intact on the disk until it is overwritten by new data. In this case, we can assume the provided memory image was taken shortly after the file was deleted and therefore the data shouldn't have been overwritten yet. For detailed information, please see the following [article](https://www.sciencedirect.com/topics/computer-science/master-file-table). ### Extracting Files When dealing with files on an NTFS system, the size of the file determines how its data is stored and how we extract it using Volatility. For files smaller than 1024 bytes, the file data is often stored directly within the Master File Table (MFT) entry itself. This is possible because the MFT entry typically has enough space (1024 bytes) to contain both the file's metadata and its actual data. In such cases, using the `mftparser` plugin in Volatility will extract the file directly from the MFT. For files larger than 1024 bytes, the MFT entry doesn't hold the file data directly. Instead, it contains pointers to the disk clusters where the file's data is stored. Even though we would also use the `mftparser` plugin, Volatility will automatically handle these larger files by using the pointers in the MFT to locate and retrieve the data from the disk. In these cases, we would specify an output directory too. Let's run a `filescan` first to see if we can find the *"very important file"*. ```shell vol.py -f MemoryDump_Lab4.raw --profile=Win7SP1x64 filescan > filescan.out ``` As seen by the screenshot below, I grepped for `important` because of the hint provided in the description. I also used `-i` to ignore case. There is reference to an `Important.txt` file which I'm assuming will contain the flag. ![[Pasted image 20240813121139.png]] However, we know that we won't be able to use the typical `dumpfiles` command for this as it's a deleted file. This is where I'll try the approach I just learned by using `mftparser`, as discussed above. The following command also assumes that `Important.txt` is less than 1024 bytes. ```shell vol.py -f MemoryDump_Lab4.raw --profile=Win7SP1x64 mftparser | tee mftparser.out ``` I piped the output into a file so that it can be easily combed through after with `grep`. ![[Pasted image 20240813122036.png]] > [!tip] > Use `--after-context=NUM` or `-A NUM` to include a specific number of lines after the chosen keyword has been hit. We need to do it in this context to see the full output. Short and sweet, we got the flag. > [!check] Flag #1 > inctf{1_is_n0t_EQu4l_7o_2_bUt_this_d0s3nt_m4ke_s3ns3} ### Conclusion I'll see you in [[MemLabs Part 5 - Black Tuesday]]. Thanks for reading—peace.