The Magnet Virtual Summit ran throughout May 2020 and included a CTF created in association with the Champlain College Digital Forensics Association. The CTF included Android, Apple iOS, Windows host, and Windows memory analysis challenges. Unfortunately I didn’t have as much time to spend on the CTF as I had hoped while the challenge was live so this write-up only covers the Windows memory analysis, as this is an area I have been focusing on recently.

The MVS is over and the CTF is no-longer available to the public, but the presentation videos are available to watch via the Magnet Forensics site.

Let’s get on with the analysis.

MD5: 224f93209cbea29e862890f30dfa762d
SHA1: 55f0d288c91296621e9d9f50a9d8ecf81d4e3148

01 – How’s Your Memory?

Which memory profile best fits the system?

This is generally the first thing you will need to work out when given a memory image to examine. We can use Volatility’s imageinfo or kdbgscan plugins to determine which profile best fits our image, I tend to use imageinfo.

vol.py -f memdump.mem imageinfo

The imageinfo plugin gives us a number of suggestions, but the profile Win7SP1x64 seems a sensible choice.

Flag: Win7SP1x64

02 – Hash Slinging

What is the LM hash of the user’s account?

Now that we have determined which profile to use we can get on with the rest of the analysis. Volatility has a hashdump module which, unsurprisingly, dumps hashes from the SAM registry hive.

vol.py -f memdump.mem --profile=Win7SP1x64 hashdump

The question doesn’t actually specify the username, but as there is only one user account other than the default Administrator and Guest accounts, we can be pretty sure the Warren account is the one we are after. NTLM hashes are stored in the format:

<username>:<rid>:<LM hash>:<NT hash>

As the question asks specifically for the LM hash, our flag is:

Flag: aad3b435b51404eeaad3b435b51404ee

03 – Cache Money

What is Warren’s Ignition Casino password? (Case Sensitive!!!!)

I found this question the hardest one in the section and undoubtedly spent the most time on it. I started by running the pstree plugin to get an overview of what processes were running when the memory image was captured.

vol.py -f memdump.mem --profile=Win7SP1x64 pstree

The first process I looked into was WINWORD.EXE (PID: 3180) in the hope that the user had typed the password into a document, but unfortunately this was a red-herring. Next I moved on to the web browsers, starting with Chrome.

If allowed by the user, Chrome will store login details for websites so that they can be auto-filled on subsequent visits. The passwords themselves are encrypted, but even if we can’t decrypt them we might get something useful from the database. The first thing to do is use the filescan plugin to output a list of files and their offsets within the memory image. I expected to use this output a lot for later questions, so I redirected the Volatility output to a file to speed up searching later on.

vol.py -f memdump.mem --profile=Win7SP1x64 filescan > filescan.txt

Chrome stores the login data in a SQLite database called Login Data under the user’s local profile. Using grep to filter the filescan output we can quickly find the database offset and extract it using the dumpfiles plugin.

grep -i '\\Device\\HarddiskVolume1\\Users\\Warren\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Login Data' filescan.txt
vol.py -f memdump.mem --profile=Win7SP1x64 dumpfiles -Q 0x000000013fa8cf20 -D .

Now that we have extracted the Login Data database we can open it up in a SQLite browser and take a look.

Record 3 contains the data for the Ignition Casino website. We can clearly see the stored email address (warrenhamiltonfinance[@]gmail[.]com) but, as expected, the password is encrypted.

763130335e48e70e4dcc9512f02f3e25e174dace6ef49afa1ca6103326faf4cd624e4579647548d40f04

Having done some digging into Chrome’s password storage mechanism it is likely that they can be decrypted using data we have in the memory dump, however as I had limited time available I opted for the less elegant approach of running strings over the memory image and heavily relying on grep! We were able to confirm the email address that Warren used, giving us our first filter. Searching these lines for casino seems reasonable.

strings memdump.mem | grep -i 'warrenhamiltonfinance@gmail.com' | grep -i 'casino'

There we go! That looks enough like a password that it is worth submitting, and it turns out to be correct.

Flag: WHbigboy123

04 – Never Tell Me The Odds…

It seems like Warren may have let his addictions slip into his work life… Find the program in question, recover it from memory, and give the SHA1 hash

We need to find the Ignition Casino executable and calculate its SHA1 hash. There is nothing obviously related to Ignition Casino in the pstree output, but we can check the filescan output for clues.

grep -i 'casino' filescan.txt
vol.py -f memdump.mem --profile=Win7SP1x64 dumpfiles -Q 0x000000013d5f4070 -D .
sha1sum file.None.0xfffffa80339f4650.img

Our grep search only gives us one hit, but it looks like a plausible location for the application to have been installed. Again, we can use the dumpfiles plugin to extract the executable, then calculate the SHA1 hash.

Flag: 3b7ca3bb8d4fb2b6c287d6a247efd7c457937a3e

05 – Compilation Station

When was IgnitionCasino.exe compiled? YYYY-MM-DD HH:MM:SS

Now that we have the executable, we move away from memory analysis for a little bit to examine the executable itself. There are number of different tools to examine PE files, but I have pev installed on my SIFT VM, and that is enough for what we need to find here. I used grep to clean-up the output.

pev file.None.0xfffffa80339f4650.img | grep 'Date/time stamp:'

We can see the compilation date and time. Converting it to the YY-MM-DD HH:MM:SS format required by the question, we get our final flag.

Flag: 2020-02-12 12:01:35