Category: CTF

Magnet Weekly CTF: Week 10 Solution Walk Through

CTF, DFIR

This weeks challenge was another round of memory forensics. As with the previous weeks challenge most* of my solves were done using a REMnux VM. REMnux includes both Volatility 2.61 (SSL support deprecated) and the beta of Volatility 3.

Challenge 10, Part 1: At the time of the RAM collection (20-Apr-20 23:23:26- Imageinfo) there was an established connection to a Google Server. What was the Remote IP address and port number? format: “xxx.xxx.xx.xxx:xxx”

Using the netscan plugin for Volatility and then filtering for “established” we see 4 open connections. A whois lookup on the addresses indicates that 172.253.188 is affiliated with Google. The communications were traversing port 443.

Flag 1: 172.253.63.188:443

Challenge 10, Part 2: What was the Local IP address and port number? same format as part 1

Looking at our earlier output from netscan we see the source address was 192.168.10.146:54282

Flag 2: 192.168.10.146:54282

Challenge 10, Part 3: What was the URL?

So we know we’ve got an open connection to a remote host going on at the time the memory was captured. Looking at Passive DNS for the Google IP address I could see that it’s principally been associated with Google Chat related assets.

I ran the memory sample through Bulk Extractor to carve out a PCAP of any of the networking artifacts that were present in the image.

bulk_extractor to pcap

Once the pcap was carved I opened it with Wireshark.

Looking through the pcap we see that the client computer had received a DNS response for mtalk.google.com at 172.253.63.188

The question was looking for a URL so… https://mtalk.google.com – yes! [Flag 3]. Originally this answer wasn’t accepted. I later received an email that it was accepted as an alternate solution and to resubmit.

Challenge 10, Part 4: What user was responsible for this activity based on the profile?

The getsids Volatility plugin quickly yields the active user account.

Flag 4: Warren

Challenge 10, Part 5: How long was this user looking at this browser with this version of Chrome? *format: X:XX:XX.XXXXX * Hint: down to the last second

This one had me stumped for a while. I first tried calculating the delta between when the chrome process was started to the time the image was acquired. (Nope)

Eventually I succumbed and took the hint which had to do with “FOCUS”. Another clue that I’d heard on Discord was that this was ‘VERY easy to solve in Axiom.’

Sure enough, stacking filters for Chrome and Focus and restricting the search to the Memory evidence yields a Registy artifact indicating that the focus time for Chrome was 3:36:47.301000. Oh but don’t just copy paste here without checking the question for the flag format. There’s only 5 places after the last decimal. So for Flag 5 the answer is 3:36:47.30100.

I was victorious in getting all 5 flags, but this has been just as much about learning as it has been about the friendly competition. So now that I knew the answer and where relatively it could be found in the evidence, I wanted to see if I could solve it just with REMnux as I had the other challenge elements.

I ran the timeliner Volatility plugin and exported the output file to .xlsx. format.

This took a few minutes to process. Once complete, I opened timeliner.xlsx.

Flag 5 (alternate) 3:36:47.30100

If we filter the Item column for Chrome and the Details column for Focus – there again the same result – 3:36:47.30100. Don’t forget to drop the last zero for the Flag.

Magnet Weekly CTF: Question 9 Solution Walk Through

CTF, DFIR

This weeks challenge was the first of the challenges to deal with Memory forensics. The ‘question’ provided by Aaron Sparling (@OSINTlabworks) was a 7 parter!

For most of the challenges so far I’ve been using Magnet Axiom and supplementing with other tools as needed. For this weeks solution you’ll see that all is being done via Volatility using the REMnux platform.

Part 1: The user had a conversation with themselves about changing their password. What was the password they were contemplating changing too. Provide the answer as a text string.

Originally the clue of “conversation” had me looking at Slack as it’s a communications tool. With no luck there I began to investigate WINWORD.exe (MS Word). First off, we dump the process memory:

Next we can use strings against the process dump and use grep to filter for ‘password.’

Apparently the ‘coversation’ the user was having with themselves was in a Word document. Within the document the user says: “Hmmm mmaybe I should change my password to: wow_this_is_an_uncrackable_password. ” [Flag 1]

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

The dumpfiles Volatility plugin can be used to dump out any files that were opened in relation to the particular memory process. There are 2 tmp (temp) files associated with Word. We can md5sum the exported files to get their hashes. Bonus if you spot where it shows I spend more time in Powershell.

The `WRD0000.tmp.dat has the MD5 has of af1c3038dca8c7387e47226b88ea6e23. [Flag 2]

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

We use the mftparser Volatility plugin to dump the MFT (Master File Table) to a text file.

Here we can see that the temp file which is holding the Autorecovery information for the open word document has the Birth Object ID: 31013058-7f31-01c8-6b08-210191061101. [Flag 3]

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

Using the getsids plugin againts the PID for Word (3180), we see the the WINWORD.EXE process was executed under the context of 1000 (Warren). [Flag 4]

Part 5: What is the version of software used to create the file containing the password? Format ## (Whole version number, don’t worry about decimals)

Using the filescan Volatility plugin to locate “Word” we see that WINWORD.EXE is being called from \Program Files\Microsoft Office\Office15. [Flag 5]

Some basic google searching informed me this directory corresponds with the installation of Office 2013, which includes Word 2013.

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

This one had me struggling for bit. During the week I heard that Aaron was presenting a webcast on Friday, When your forensic tool only tells part of the story; finding code injection using memory analysis Webcast, and that if you watched closely there may be helpful workflow.

Sure enough there was a segment where Aaron is utilizing yara rules to find the virtual offset for a string in memory, which I applied to our identified password string.

In this case the offset we are looking for is 0x2180a2d. [Flag 6]

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

Unfortunately, I wasn’t able to get the flag for the last part of the challenge before time ran out. For certain I’ll be reviewing the other walk-throughs published this week. I’m looking forward the upcoming memory challenges as well.