Magnet Weekly CTF Challenge Week 9 Writeup

This week's Magnet Weekly CTF challenge was broken into 7 parts and I learnt a lot from it. Without further ado, let's jump right into the challenge questions. 

The 1st challenge question was:

To be honest, I did spend a lot of time on the 1st challenge question as I did not catch the full context in the first place. Eventually it took me roughly 1 day to see through it. 

As there were some slack.exe processes found from the Volatility pslist plugin output and the fact that "The user had a conversation with themselves about changing their password.", the first thought that came to my mind was the slack.exe processes might very well had something to do with the answer. However, it turned out to be a wrong rabbit hole.

Clueless, I resorted to using the GNU strings utility to capture all printable character sequences that are at least 4 characters long:

strings memdump.mem > memdump_strings.txt

Then the term password was searched within the memdump_strings.txt file and the lines "Hmmm mmaybe I should change my password to: " and "wow_this_is_an_uncrackable_password" could be found:

From the above captured strings, the user Warren was planning to change his password to "wow_this_is_an_uncrackable_password" and this new password was the correct answer to the 1st challenge question. In addition, the complete conversation could be found from a Hex editor as seen in the screenshot below. 

The 2nd challenge question was:

Since a md5 hash was requested as the flag, it appeared that the recovery of the original file that contained the password was a must at this stage. From Warren's conversation contents alone, it was insufficient to determine where did the password file come from. The vaddump plugin of Volatility would come in handy, as it extracts the entire memory region for a particular process and writes them to a separate output per region. (Source)

Therefore the following commands were issued in a Linux terminal:

python vol.py -f ../memdump.mem --profile=Win7SP1x64 vaddump -D vads

grep -r "wow_this_is_an_uncrackable_password" vads/

The vaddump plugin would take some time to run and the grep command should be able to locate the process(es) that were related to the password file.

So it appeared that the WINWORD.EXE was related to Warren's password file. From the pslist Volatility plugin output, the PID for WINWORD.EXE was 3180.

Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          

------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------

<redacted>

0xfffffa803177bb00 WINWORD.EXE            3180   2672     15      698      1      0 2020-04-20 23:17:06 UTC+0000 

<redacted>

After that, the dumpfiles Volatility plugin could be used to dump all files related to the PID 3180 WINWORD.EXE process:

python vol.py -f ../memdump.mem --profile=Win7SP1x64 dumpfiles -p 3180 -D word

All files related to PID 3180 WINWORD.EXE process would be dumped to the word directory and grep would be once more used on them:

grep "wow_this_is_an_uncrackable_password" *

One file file.3180.0xfffffa803316f710.dat contained the Warren's planned new password and it should be also a Word Document. Therefore, it should be the file that contained the password:

Using the md5sum utility, the md5 hash of file.3180.0xfffffa803316f710.dat (af1c3038dca8c7387e47226b88ea6e23) could be obtained successfully, which was also the correct answer for the 2nd challenge.

The 3rd challenge question was:

So it appeared that it would be necessary to look for NTFS birth object ID for the password file. The original dumpfiles Volatility plugin output also parsed the original filename of the dumped files. 

As the file.3180.0xfffffa803316f710.dat file should be a CDFV2 Microsoft Word file, which indicated that the file would probably had a ".doc" file extension. However, no dumpfiles output had an original file extension of ".doc". 

Meanwhile, an interesting called "AutoRecovery save of Document1.asd" could be found from the dumpfiles output. Turned out the original filename for file.3180.0xfffffa803316f710.dat was "AutoRecovery save of Document1.asd".

Following that the mftparser Volatility plugin was used to analyze the NTFS Master File Table (MFT)

python vol.py -f ../memdump.mem --profile=Win7SP1x64 mftparser --output-file=mft_parser.txt

After the mftparser finished runninntg, the output file mft_parser.txt should be inspected to see the MFT entry of "AutoRecovery save of Document1.asd". The Birth Object ID (31013058-7f31-01c8-6b08-21019106110) could be found from there as expected.

The 4th challenge question was:

From the contents of the password document, it should be written by Warren. In addition to that, by using RegRipper to parse the SAM registry hive (which could be extracted with Volatility dumpregistry plugin using the command python vol.py ../memdump.mem --profile=Win7SP1x64 dumpregistry -D output or by MemProcFS), the only active user should be Warren only. Thus, the correct answer should be 1000(Warren).

The 5th challenge question was:

As the password document name was  "AutoRecovery save of Document1.asd", it was very likely that the password documeny was created on the machine using the installed Microsoft Word. From the RegRipper results from Warren's NTUSER.DAT, the Microsoft Word running on the machine should be of a "OFFICE15" (a.k.a. Office 2013) and 15 is the Word software version number.

The 6th challenge question was:

For this question I used the Volatility vaddump plugin to dump the whole VAD structure of the WINWORD.EXE process and then look for the offset manually:

python vol.py -f ../memdump.mem --profile=Win7SP1x64 vaddump -p 3180 -D vads 

Afterwards, with the good old grep technique, the password string could be located inside "WINWORD.EXE.13f77bb00.0x0000000002180000-0x00000000021fffff.dmp". Using a Hex editor, the virtual memory address offset (0x02180A2D) could be found easily with a bit of calculation:

The 7th challenge question was:

What if I told you that you have already seen the answer for this question at the beginning of this write-up? That's right, the physical memory address offset of the password string was exactly the Hex offset of the password string (0xAF12A2D) inside the memory dump file.

Conclusion

Memory is fun and it would definitely interest everybody :D