Magnet Weekly CTF, Week 12 Solution Walk Through

The final challenge (#12) – Part 1:

What is the PID of the application where you might learn “how hackers hack, and how to stop them”?

Format: #### Warning: Only 1 attempt allowed!

The first thing I did was open the memdump file in HxD Hex Editor. A quick search found several hits.

I considered mapping the Offset back to the process memory but before going down that road (anticipating it to be math heavy) I decided to drop the individual process memory instead. Looking at the text surrounding “How Hackers Hack…” it appears to be html code. Looking even closer I’d say that it was in response to a search request for “how to stop getting hacked over and over.” Based on that I knew I’d be looking for a browser process.

Running pslist in Volatility we see that there’s multiple browser processes running for both Chrome and Internet Explorer.

I decided to focus on the iexplore.exe processes for Internet Explorer first – for 2 reasons. 1 – there were less running than Chrome so it was a smaller set to work through first. 2 – I did happen to find a Parsed Search Query in Axiom for “how to stop getting hacked over and over.”

The URL indicates a search from Bing.com. Only a sociopath would use Bing to search within Chrome so Internet Explorer it is.

I used the memdump Volatility plugin to dump the process memory for both IE processes.

Next I ran strings against each dump file to see if there was a hit.

We see that in the second file 4480.dmp (associated with PID 4480) contains the content we’re looking for. What is the PID of the application where you might learn “how hackers hack, and how to stop them”? 4480 [Flag 1]


The final challenge (#12) – Part 2:

What is the product version of the application from Part 1?

Format: XX.XX.XXXX.XXXXX

OK, so we need to know what version of Internet Explorer was used for the Bing search. Off to the Google to find that the IE version information is stored in the registry in HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer in the svcVersion value.

From here I mount the full memory image using MemprocFS.

Using the file structure to navigate to the registry key I open svcVersion.txt and verify that the IE version running is 11.0.9600.18860. Back to the scoreboard to submit the bittersweet ending to a very fun challenge and ….. WRONG.

Hmm, so everything I knew (which was limited to be honest) told me that I had the version right, but that wasn’t the right answer. Over on the Discord channel I saw I wasn’t the only one to have the same quandry.

I waited and lurked, waited and lurked – but wasn’t seeing any update to the question. The following day while meditating on the matter in the shower I was thinking about what other means existed to identify details like this.

I used the procdump Volatility plugin to dump the process executable for PID 4480.

Once I had executable.4480.exe I uploaded the file to Virus Total.

Scrolling down on the details tab we see that the exe is correctly identified as Internet Explorer and shows a File Version of 11.00.9600.18858. This is very similar to what we identified earlier (…58 vs …60).

Answer: 11.00.9600.18858 [Flag 2] CORRECT!

I’ll be very interested to learn how others who got the flag identified the correct version information. I suspect there’s additional artifacts that I didn’t explore that hold those clues but for the time being – it’s a mystery to me.

Who am I kidding? It’s gonna be killing me til I know the answer.

Magnet Weekly CTF, Week 11 Solution Walk Through

Challenge 11, Part 1: What is the IPv4 address that myaccount.google.com resolves to?

I was able to find this pretty quick going back to last week’s artifacts. In week 10, I used bulk_extractor to carve a PCAP out of the memory image.

Opening the same PCAP file I applied a String filter for ‘myaccount’.

Wireshark viewing PCAP carved from Memory

In the highlighted row we can see a DNS resolution for myaccount.google.com coming back as 172.217.10.238. [Flag 1]

Challenge 11, Part 2: What is the canonical name (cname) associated with Part 1?

Scrolling further to the right on the same entry, we see that the CNAME for myacccount.google.com was www3.l.google.com. [Flag 2]

Magnet Weekly CTF: Week 10 Solution Walk Through

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

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.