elshon walcha lannan
Millard Winnin
OtterCTF dates from December 2018 and includes reverse engineering, steganography, network traffic, and more traditional forensics challenges. This write-up only covers the memory forensics portion, but the whole CTF is available to play as of the publication of this post.
The question asks for the user password, not the password hash, so we can either try to crack this using tools like John the Ripper or Hashcat (or Google), or we can try extracting the plaintext password from the LSA secrets using the lsadump plugin.
We are given a sequence of bytes and told that the data we want will follow. We already have a dump of the LunarMS process memory from Question 4 so this is all about searching. For simplicity I only used the last eight bytes in the sequence in my search, employing xxd to display the bytes and grep to search for the end of our target pattern.
The Zone Identifier file we extracted by mistake in the last question indicates the torrent was downloaded from the internet. The number of chrome.exe processes observed in our pstree output suggests that Google Chrome is the primary browser. As with Question 8 we can use the filescan and dumpfiles plugins to find and extract the Chrome history database.
Sure enough, there is a hit on VirusTotal, referencing an alternative executable name (VapeHacksLoader.exe) which is associated with the $ucyLocker ransomware referenced in the graphic we extracted in Question 11. $ucyLocker is a variant of the open-source Hidden Tear ransomware, and with a few Google searches I was able to find a pre-compiled decrypter.
After specifying the file extension and supplying the password we extracted in Question 12, the tool ran and output a plaintext file named flag (the file extension having been stripped during decryption).
My first interaction with memory forensics was in a CTF hosted by CSAW in 2020. Later I noticed most CTF events award high scores for memory forensics challenges. It was challenging initially to set up the Volatility 2 tool back then for me. After trying it out several times, I found a conclusive way to establish it. In this post, I'll share my knowledge of memory forensics from my CTF experiences.
?Note: Many incident response professionals and malware analysts use memory forensics. There is a fantastic talk by Monnappa K A regarding Investigating Malware Using Memory Forensics. That was the first video I watched about memory forensics, and I relished it.
Memory Forensics is a method in which volatile data (RAM) is collected and stored as a file using tools like Magnet Forensics RAM Capture, AVML, FTK Imager, etc. These tools allow us to conduct forensics off the victim machine. As we dive into memory dumps, we notice that most processes running are in the memory dump. We could use this memory dump to analyze the initial point of compromise and follow the trail to analyze the behavior.
I'm a fan of volatility 3 for its speed. But unfortunately, Volatility 3 doesn't have many plugins as of yet. It's still under development at the time of writing this blog. Because time is of the essence in CTFs, having them installed is not a bad idea.
Now that we have the workstation ready. You should know concepts from the operating system to understand how the volatile memory works and how processes are loaded/executed. This concept differs for both Windows and *Nix. Some Linux distributions (such as Ubuntu) have an excellent segmentation mechanism that stores files in memory, which can be handy when extracting them.
We will look at some plugins utilized in CTF and Malware analysts who investigate them forensically. I will be using various memory dumps to demonstrate. Here are a couple of repositories from GitHub that have memory dump samples: MemoryForensicSamples and MemLabs.
I have a Memory dump image ready for the demonstration from a CTF. You can use any memory dump to learn what I'm demonstrating. The first thing to do when you get a memory dump is to identify the operating system and its kernel (for Linux images). To identify them, we can use Volatility 3.
We can tell from the image above that it is CentOS 7.7-1908 as it is the only version that had the kernel version 3.10.0.-1062. It is now up to us to choose whether we want to work with Volatility 2 or Volatility 3. Volatility 3 requires symbols for the image to function. When it comes to Volatility 2, we need profiles.
A Linux Profile is essentially a zip file with information on the kernel's data structures and debugs symbols. This is what Volatility uses to locate critical information and how to parse it once found. If a pre-built profile does not exist, you'll need to build your own.
When we revisit the bash history, we can see that a repository from GitHub was cloned, and a python file is being run. I was going through all the files on GitHub, and at last, I found one file different from another. snapshot.py file had a line that line pushed to the right. I found a Pastebin link from the file, which pulls and executes the content.
I think we can extract the password, from the editbox which popped up for getting user credentials i.e., the textboxes generated by Windows Common Controls. For this purpose, we have a plugin called editbox.
We have a Russian text, which translates to the above. The above credentials are for connecting Team Viewer. The rest of the output looked like session credentials for TeamViewer. The string P59fS93m looks like TeamViewer credentials.
We are aware that the host has Outlook installed. I'll look for .PST and .OST files related to Outlook. To learn more about those files, visit Microsoft's website. Let's start by listing the files with those extensions and then extracting them to read the message and figure out how to retrieve attachments.
We will use pffexport. If it's not installed, you can install it with a package manager. And then, run the command in the following manner. pffexport -m all and mention each of the exported files using dumpfiles. You must see several directories created in the process. Now we can use the find command to look for popular files used as attack vectors, such as docx, xlsx, etc.
Here in the same directory, there is a folder named attachments. Here is the reference relative path to the directory where you can find the Attachments directory pst_files/file.2692.0xfffffa80042dcf10.dat.export/Top of Outlook data file/Inbox/Message00011/.
Tejendra Saradhi has over four years of cybersecurity experience and has been a Hack The Box user for over three years. He has taken part in several CTFs, recently placing 1st in Prometo CTF'23 held by IIT Jodhpur. He is an avid learner (with a passion for exploring Blue and Red teaming content) and likes to learn new concepts and produce music.
[Volatility]( ) is a great tool for memory forensics, it has many modules and commands to explore a memory dump. You should experiment with it if you're just starting in forensics territory. The `imageinfo` command, which spits out the probable OS of the memory dump, gave us info that this is a Windows 7 64-bit. So we're using `Win7SP1x64` profile from now on.
I was kind of dreading this challenge when I first read it. I wouldn't have taken on this case as an ex-cyber forensics analyst. Forensic cases usually have a trigger point where analysis can start, a suspicious executable running on a workstation, a large data upload at a certain time... Finding anything malicious is not forensics, it is a treasure hunt. Are you referring to the adware running on the machine, or do I have to dig much much deeper to get to the UEFI rootkit.
Anyway, to start analysing the memory image, we normally run the volatility imageinfo plugin to determine the OS version. If multiple profiles are returned, the general rule of thumb is to select the most specific profile, the one with release version. It is likely to be a better fit and plugins will have a higher chance of working correctly.
After unsucessfully looking through various forensic artefacts (i.e. event logs, registry...), I decided to look at IE history using the volatility tool. We can see that the user is using IE to download Chrome. We finally have a lead to follow.
Unfortunately, the chromehistory plugin did not work for me. This is quite common as memory structures and locations may change with every chrome version update. I decided to manually dump the memory of the chrome process and parse the strings from there. The first step is to use the pstree plugin to get the pid of the process and then use the vaddump plugin to dump the memory. We cannot use procdump as it will only dump the process's executable image. The URLs and web page contents are likely in the heap memory. One benefit of using this generic memory dump method is that such methods work across different applications. It will work even if the user uses opera or other obscure browser or application without dedicated plugins.
Once the memory has been dumped, I used strings to parse both ASCII and unicode strings from the memory and piped it to a file. Searching for http revealed a mediafire URL that didn't really belong, as the rest of the URLs were related to cybersecurity or govtech.
Upon downloading the png file, I found that it was a tiny 1 row high PNG file and a color picker eventually revealed that the flag was encoded in the individual RGB values of the image. The flag was indeed hidden in a colourful lane!
In a recent raid on a suspected COViD hideout, we found this video in a thumbdrive on-site. We are not sure what this video signifies but we suspect COViD's henchmen might be surveying a potential target site for a biological bomb. We believe that the attack may happen soon. We need your help to identify the water body in this video! This will be a starting point for us to do an area sweep of the vicinity!
The second clue involved listening to the sounds of freedom, the fighter jets roaring overhead. This suggests that the location is somewhere near the edge of Singapore's airspace, or near one of the airbases.
c01484d022