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.
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:
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.
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 '[email protected]' | grep -i 'casino'
There we go! That looks enough like a password that it is worth submitting, and it turns out to be correct.
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.
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