Magnet Weekly CTF — Week 9

Well, this was a rather lengthy one, so we’ll just get started.

This month the CTF is focused on a Windows Memory image.

Part 1

Question: The user had a conversation with themselves about changing their password. What was the password they were contemplating changing too.

I found this one in a way I don’t think the challenge author intended, but I ended up following the intended process for part two. In this question, I simply grepped for “password “. Yep, that’s a space at the end, I sort of figured that if he was having a conversation it would either say “password” as part of a phrase or “password:” or “password=” or something of that nature.

Using some grep flags we get the whole conversation:

grep -A 10 "change my password "

Answer: wow_this_is_an_uncrackable_password

Part 2

Question: What is the md5 hash of the file which you recovered the password from?

This one threw me for a loop. Well, it’s the memory file itself, so do I just hash the memdump.mem file? No, that can’t be it. Well I knew Volatility would be my friend so I got started with it. As always, get the profile first:

volatility -f memdump.mem imageinfo
> Win7SP1x64

Volatility has a plugin that will list the files it knows about in memory and another that can dump the files.

volatility -f memory.dmp --profile Win7SP1x64 filescan > files.out

Using the list files.out, I searched for user files, .txt files, .doc files. Nothing really stood out except for an auto-save Word document. Not sure why I ignored it as it ended up being what I wanted. But to arrive at that conclusion I went the wide net casting route. I dumped all files, grepped for the password string and then hashed the file that matched.

volatility -f memdump.mem --profile Win7SP1x64 dumpfiles --dump-dir dumps
grep wow_this dumps/*
Binary file file.3180.0xfffffa803316f710.AutoRecovery save of Document1.asd.dat matches
md5sum 'file.3180.0xfffffa803316f710.AutoRecovery save of Document1.asd.dat'

Answer: af1c3038dca8c7387e47226b88ea6e23

Part 3

Question: What is the birth object ID for the file which contained the password?

I immediately knew this question would be related to MFT parsing as that’s typically where you find birth object IDs:

vol -f memdump.mem --profile Win7SP1x64 mftparser --output-file mft.out

Grepping in the mft.out file for the .asd file:

Answer: 005a0000–0000–0000–0056–000000000000

Part 4

Question: What is the name of the user and their unique identifier which you can attribute the creation of the file document to? Format: #### (Name)

My first thought on this one was SIDs, turns out my hunch was right:

vol -f memdump.mem --profile Win7SP1x64 getsids

Since the file was created by Microsoft Word, I went searching for the WINWORD.EXE process.

I wasn’t 100% sure I was on the right track, but then I saw the “Format” portion of the question and knew I had it.

Answer: 1000 (Warren)

Part 5

Question: What is the version of software used to create the file containing the password? Format ##

I had already seen something in the Program Files in the files.out output from the filescan plugin, so I did a simple grep for WINWORD:

Again, wasn’t sure about “15”, seemed too obvious, but the ## format gave it away again.

Answer: 15

Part 6

Question: What is the virtual memory address offset where the password string is located in the memory image? Format: 0x########

Aaaaaaand this is where it got tough. I don’t really want to admit how much time I spend in the output from the memmap and memdump plugins, but it was a lot. Eventually I came to my senses and went the VAD route. Turns out “Virtual Address Descriptors” should have been a pretty obvious place to start, but I digress.

First I got the process ID for the WINWORD.EXE process since that was the process which seemed to have created the auto-save file:

vol -f memdump.mem --profile Win7SP1x64 pslist

OK, so the PID is 3180. Now let’s get the VADs for that process:

volatility -f memdump.mem --profile Win7SP1x64 vaddump --dump-dir vads -p 3180

In the vads folder, I grepped for the string “wow_this” and found the file that contained it. Then getting the byte offset of the password in that specific file:

grep --byte-offset -bao wow_this *
WINWORD.EXE.13f77bb00.0x0000000002180000-0x00000000021fffff.dmp

The offset for the string was 2605 which in hex is a2d. The vaddump plugin outputs files with names that contain the start and end virtual addresses, so the start address is 0x0000000002180000, adding a2d yields 0x0000000002180a2d. I tried this answer at first but was rejected. Of course I had forgotten AGAIN about the format from the question.

Answer: 0x02180a2d

Part 7

Question: What is the physical memory address offset where the password string is located in the memory image? Format: 0x#######

Taking my queue from the previous question, I figured I would get the byte offset of the string in the original memdump.mem file:

grep --byte-offset -bao wow_this memdump.mem

The offset is 183577133 which in hex is af12a2d.

Answer: 0xaf12a2d

Thoughts

This was a nice set of questions with an easy start but some ramp-up at the end which built on the previous questions. I was not as familiar with VADs and virtual/physical address spaces, so I did learn a few things. Although I’m not really sure how I would use this in a practical sense, so I’d love to see more more applications of this information, obviously it’s in volatility for a reason, but I’ve yet to come across it in a case.