Magnet Weekly CTF Challenge Week 10 Writeup

There were 5 parts in the week 10 challenge of the ongoing Magnet Weekly CTF. I managed to solve 4 parts out of 5 and the following would cover my walkthrough for this challenges:
Notice the wording "established connection" was used in the challenge description. Therefore, the term "ESTABLISHED" was searched inside the the Volatility netscan plugin output:
There were 4 known established connections at the time of RAM collection. According to whois output, the 1st IP address (151.101.116.106) belongs to fastly. However, the 2nd IP address (172.253.63.188) belongs to Google. Thus, the answer should be 172.253.63.188:443.

Part 2 of the question immediately asked for the local IP address and the port number. From the Part 1 netscan screenshot, the answer should be 192.168.10.146:54282.
The browsed URL should be lurking somewhere inside the Chrome History SQLite database, which could be dumped with the following Volatility command:
python vol.py -f ../memdump.mem --profile=Win7SP1x64 dumpfiles -Q 0x000000013e9ccb30 --dump-dir Chrome/
The Chrome History file physical offset could be found from Volatility filescan plugin output:
The last visited URL, which was "https://www.google.com", is the answer for this part of the challenge:

As discussed in week 9 write-up, Warren should be the only active user on the system. 

Part 5 was the real pain of this week and I did squander the time on some of the following:
  • submitting the visit_duration value (437292) of "https://www.google.com" as the answer
  • finding when the Google Chrome was last updated and calculate the time difference
  • searching "Volatility" and "focus" on Google and found tons of stock-related material instead (which was clearly not related to the 5-point "FOCUS" hint)
At the end, it was about the "Time Focused" field from Volatility UserAssist plugin output and 3:36:47.30100 was the intended answer.

For the uninitiated, the following text excerpted from this Opentext page illustrated how the "Time Focused" mechanism works:

"In addition to this, two additional variables are stored. These are a focus-counter and a focus-timer. The significance of the remaining bytes is unknown.

When an application is executed the run-counter is incremented by one. The system then tracks the time that the application has the focus. If the application is closed or looses focus then the focus-timer, which appears to be stored in milliseconds, will be incremented by the time tracked by the system.

Every time the application is out of focus but then receives the focus, the focus-counter is increased by one and the system starts tracking the focus time again. Note that the focus-counter is not incremented at the time the application is started, only when it has lost the focus and re-gains it."

Lessons Learnt

  • Leave no stones unturned. The answer that you have been desperately looking for might very well just beneath that unturned stone.
  • KNOW YOUR ARTIFACTS! KNOW YOUR TOOLS!

Comments

Post a Comment

Popular posts from this blog

Dumpster Diving in Google Photos Android App: "local_trash.db"

Image
  This article will explore the Trash within the Google Photos Android App. If you delete any media file from Google Photos on your mobile device, the deleted media file would then be relocated to the Trash within Google Photos. All items inside Trash will be permanently deleted after 60 days in Trash. In fact, the information of the Google Photos Trash items will be stored inside the " local_trash.db " under " /data/com.google.android.apps.photos/databases/ ": The " local " table of  " local_trash.db " contains most of the useful information, including " local_path " ( the original path of the deleted media file ), " trash_file_name " ( a UUID value that becomes the new name of the deleted media file ), " deleted_time " ( a Unix timestamp in milliseconds that recorded the delete time ), " is_video " ( where "0" = "no", "1" = "yes" ), etc. As soon as a media file was
Read more

An Android Casting (Device) Story: "cast.db"

Image
  This article will briefly document a SQLite database (" cast.db ") found from Android devices, which would store the information of detected casting devices on the Wi-Fi network. The said " cast.db " can be recovered at " /data/com.google.android.gms/databases/cast.db ".  Using Joshua Hickman's Android 10 image as an example, " DeviceInfo " table from  " cast.db "  would store the casting device ID (SSDP UDN), device friendly name, device model name, device IP address and port number, hotspot BSSID , etc. Apart from the basic information of the casting devices, some interesting Epoch timestamps in milliseconds like " last_published_timestamp_millis ", " last_discovered_timestamp_millis " and " last_discovered_by_ble_timestamp_millis " could be discovered as well.  There were some other intriguing tables such as " NetworkInfo ", which probably records the last connected time to a Wi-Fi networ
Read more

Magnet Weekly CTF Challenge Week 12 Writeup - Last But Not Least

Image
Time flies and finally we have made it into the last week of Magnet Weekly CTF. This week was still a two-parter. The 1st part of the challenge asked of a PID: Using HxD to search the key phrase " how hackers hack, and how to stop them " inside the memory dump, a hit could be found quickly:  After that, the Volatility yarascan plugin was used to find the PID that related to  " how hackers hack, and how to stop them ".  The Hex value corresponding to the " How Hackers Hack, and How To Stop Them " string value discovered from HxD could be reused as the search criterion for yarascan , the  " python vol.py -f ../memdump.mem --profile=Win7SP0x64 yarascan -Y "{48 6F 77 20 48 61 63 6B 65 72 73 20 48 61 63 6B 2C 20 61 6E 64 20 48 6F 77 20 54 6F 20 53 74 6F 70 20 54 68 65 6D} " command was issued in terminal: From the yarascan output, all hits came from the " iexplore.exe " process with PID 4480 . Therefore, the answer for the part 1 chal
Read more