IrisCTF 2025

IrisCTF 2025!

I participated in IrisCTF 2025, organized by IrisSec, as a member of the InfoSecIITR team. Our team secured an impressive 9th place globally. These writeups detail all the OSINT and Forensics challenges that I personally solved during the competition.

OSINT

OSINT Disclaimer

Challenge Description

OSINT DISCLAIMER 50 points // 786 solves

Tags: freebie

The challenges this year does not require you to contact anyone. There will be no social media accounts needed to solve these challenges. Please refrain from reaching out to individuals on social media or contacting restaurants to inquire about further details. Such actions are unnecessary and will result in consequences leading to disqualification. Solving this challenge will unlock the rest of the Open-Source Intelligence category

By: Lychi

Solution

The flag for this challenge was included in the challenge description.

This time, the OSINT challenges were purely based on the website blog and some images. Thanks to Lychi and Bobby for creating these amazing OSINT challenges. I managed to solve all of them.

Flag:

irisctf{sp01l_f00d_1s_b4d_mk4y}

Checking Out Of Winter

Challenge Description

Blog’s Link: https://osint-food-blog-web.chal.irisc.tf/

Message

For beginners, I would say that doing OSINT challenges is really fun and makes you feel like an investigator. You just have to narrow down the useful data from all the information available to you. Always check for keywords, regional distinctions, special marks, or buildings, as the victim often leaves minor traces by mistake, which can help you identify them.

I created this writeup in detail, especially for first-time solvers. 😉

Solution

In the challenge description, keywords like Baja California Sur, Beach, Golf, and Hotel’s location farther from the main city are traces left by the victim that can help us move forward.

Exploring the Clues

Let’s visit the website:

On the website, we find many blogs and stories by Adam about the places he visited and the food he ate.

By matching the description, we identify that the Pizza by The Water blog is the most relevant one for this challenge.

In the blog’s image, we notice the hotel’s architecture in the background, along with a pool. Since we have an image related to the location, we can perform a Reverse Image Search using Google Lens.

Note: If the location is based in Russia, Yandex is preferable for reverse image searches. Similarly, if a country has its own powerful search engine, use that for better results.

Initially, when I searched using the full image (including the pizza and the hotel), most results were about pizzas, related sites, and posts.

To refine the search, we need to narrow down the content we are focusing on. For the next search, I used only the hotel’s image and included the location Baja California Sur. This helped narrow down the results significantly.

In the refined search results, as seen above, the AI and other sites directly suggested the hotel’s name, unlike the first search. This demonstrates the importance of crafting an effective search prompt, as search engines have vast amounts of data to process.

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Flag:

irisctf{Hilton_Los_Cabos_Beach_and_Golf_Resort}

Hurray!!!

Sleuths and Sweets

Challenge Description

Blog’s Link: https://osint-food-blog-web.chal.irisc.tf/

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

So again, let’s search for the keywords. I got these: Japan, Crepes, Foot Traffic—traces left by the victim that can help us move forward.

Let’s visit the website for this blog:

This time, we had 3 images. When I did a Reverse Image Search for the 1st and the 3rd images, I didn’t get much exact information because they looked very common across Japan.

When I did a Reverse Image Search for the 2nd image, I got these results:

Suggesting Marion Crepe Ueno Ameyoko Store, which was not the correct address for the flag.

Exploring other way

So this time, I tried another method. As the description mentioned Foot Traffic, I searched for the place with the highest foot traffic in Japan.

The place with the highest foot traffic in Japan is Shibuya Crossing in Tokyo, which is widely considered the busiest pedestrian crossing in the world, with thousands of people crossing at once during rush hour. 

I then refined my search for crepe shops near Shibuya Crossing on Google Maps. After checking several stores, I finally found the correct one, as shown below:

Location: Marion Crepes Shibuya Modi

It had similar images to those given in the blog.

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Flag:

irisctf{1_Chome_21_3_Jinnan_Shibuya}

Another one solved! 🥳

Not Eelaborate

Challenge Description

Blog’s Link: https://osint-food-blog-web.chal.irisc.tf/

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

So again, let’s search for the keywords. I got these: Title - Eel, Deer Park, Japenese Food, Quiet Restaurant- traces left by the victim that can help us move forward.

Let’s visit the website for this blog:

So, I started searching for Deer Parks in Japan and found one famous Deer Park, Nara Park, which helped me narrow down my search.

The food dishes mentioned in the blog hinted at the Unagi Dish. I then did a Reverse Image Search for the given image using the prompt Unagi Dish Restaurant near Nara Park. This search suggested some restaurants, and the first restaurant had a similar dish plate, as shown below:

Finally, search for the restaurant on Google Maps, and you will get the correct name, which is located near Nara Park.

Location: Edogawa Kintetsu Nara

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Flag:

irisctf{Edogawa_Kintetsu_Nara}

One more solved!

Late Night Bite

Challenge Description

Blog’s Link: https://osint-food-blog-web.chal.irisc.tf/

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

This challenge was a little tricky. Let’s start.

According to the description, Adam hid his favorite hangout spot, which he had recorded in the past.

At first, I thought he didn’t directly mention the Late Night Bite blog, so I explored the other uncovered blogs but didn’t find anything useful related to the challenge.

Then, I went to the About section of Adam’s site.

In the About section, I noticed that Adam is a food blogger based in Southern California and that on Wednesdays, he stops by the farmer’s market before work.

I speculated that the farmer’s market might be the nearest location around his house. When I did a Reverse Image Search on the image provided in the About section, I realized the location was Santa Monica Pier.

I then did another Reverse Image Search with the prompt:

I believed Adam was talking about the Downtown Farmers Market because of the Wednesday mention.

But I still didn’t have any clue about the restaurant’s name, so I started searching through the blog on his site again. Since I have some foundational knowledge of web dev/exp, I began by viewing the Page Source. In the source, Adam mentioned this line:

<!-- MY SUPER SECRET POST: "late night bite" -->

Then, I tried the robots.txt endpoint – https://osint-food-blog-web.chal.irisc.tf/robots.txt.

There, I found a mention of: Sitemap: /sitemap.xml.

I went to this endpoint and discovered every endpoint related to his blogs. After scrolling, I found a mention of the Late Night Bite blog as:

<url>
<loc>/late-night-bite/</loc>
<lastmod>2025-01-02T00:00:00-08:00</lastmod>
</url>

So, finally, I found the blog that was hidden by Adam.

So, I quickly searched for a Modern Local Izakaya Restaurant with those features near Santa Monica on Google.

I found this helpful site:

The first restaurant, Shirubē, was near the Downtown Farmers Market, and it also had the features mentioned by Adam.

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Flag:

irisctf{Shirube}

This marks the last challenge based on the Food Blog website. Thanks to lychi for creating this amazing challenge; I really enjoyed it.

Fuel Deal

Challenge Description

Source File: fuel-deal.tar.gz

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

So again, let’s search for the keywords. I got this: Good Fuel Deal.

I did a Reverse Image Search but didn’t get much of a lead. Then, I tried one of the cool tools, GeoSpy AI, which showed me this result:

Not every time does this AI give you the correct location, but since there were mentions of Australia in my Google Image Search, I decided to try the suggested location, Melbourne, Australia.

I then searched on Google with the query: Where were the cheap fuels (with the rate price mentioned in the provided image) in Melbourne? and got some of these results:

The cheapest diesel available in Victoria costs 183.9 cents per litre.

Then found this helpful site : https://www.carexpert.com.au/car-news/the-cheapest-petrol-and-diesel-around-australia-this-week\

The above site had these rates :

Victoria-

The cheapest unleaded petrol in Victoria today costs 169.9 cents per litre. You can find it at Liberty Pakenham.

The cheapest diesel available in Victoria costs 183.9 cents per litre. You can find it at SE Fuel in Mount Waverley.

Metro – Melbourne	                                Statewide
Unleaded 91	183.9 (Metro Petroleum Maribynong)	169.9 (Liberty Pakenham)
Premium Unleaded 95	187.9 (APCO Hoppers Crossing)	191.5 (APCO Bendigo)
Premium Unleaded 98	204 (Liberty Baxter)	        197.9 (Shell Heywood)
Diesel 183.9 (SE Fuel Mount Waverley)	                189.1 (Independent Morwell)

I started searching with all the locations mentioned above from the beginning. Finally, when I was searching for the SE Fuel Mount Waverly location on Google Maps, I found some of these fuel stations:

After scrolling down, I identified that the Shell station was the desired fuel station. If you check the photos or the 360-degree view of that location, it was identifiable with the provided image.

Location : Shell

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Flag:

irisctf{203_Gallaghers_Road_Glen_Waverley_Victoria_Australia}

Woah!!!

Where’s Bobby

Challenge Description

Source File: files

Hints releasd on Discord Announcements:

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

So again, let’s search for the keywords. I got these: Road Trip, Water Body, Not much populated areas - traces left by the author.

Provided Image:

I like the view of the image. This image was taken from a car on a road that appears to be in the middle of the mountains.

When we zoom in on the image, we can see something written in Chinese on the board. I checked it using Google Translator:

Translated Text in the above image:

Smooth traffic from Xishatun Bridge to Louzizhuang Bridge.

The board was showing the traffic conditions of the upcoming bridges, which means the author was about to enter this bridge via the connected roads from where they were coming.

The possible routes near these two bridges are:
G7, G6, G4501, S216, S321, S3801.

As the author mentioned the surroundings of the route as Water Body, Not much populated areas, the road in the provided image was surrounded by mountains.

With these specifications, I started matching the description with the route numbers found earlier:

• I couldn’t find a water body around G7.
• G6 was heavily populated.
• G4501 was not deep into the mountains.
• S216 and S321 were primarily in city regions.
• Lastly, S3801 had water bodies and very sparsely populated areas around it, which led me to consider it for flag verification.

Creating the Flag

With the gathered information, let’s construct the flag using the defined format.

Hooray! It was the correct flag!!!

Flag:

irisctf{S3801_CN}

Where’s Bobby 2

Challenge Description

Source File: files

Hints released on Discord Announcements:

Youtube Video Link: https://www.youtube.com/watch?v=L9Di-UVC-_4

Solution

If you came directly to this challenge’s writeup, I will recommend you first read my Checking Out Of Winter writeup because I have made it in detail, specifying some important notes.

Provided Image:

I did a Reverse Image Search using Google Lens and found these helpful sites:

- https://ameblo.jp/yorinoto/entry-12733913890.html
- https://m.sohu.com/a/545522713_99946287/?pvid=000115_3w_a

After exploring these sites, I discovered that the location name is Bai Zi Wan Subway Station, and the wall art is "Hundred Ziwan Kissho" / "The Hundred Children Playing in Baizi Bay" painting.

The Challenge with Finding the Coordinates

Finding the exact coordinates was tough for non-Chinese users because all locations on Google Maps for China are shifted by a few units. You can learn more about this issue from the provided YouTube video.

Although it was mentioned not to use Chinese maps or software, I took a look on the Baidu Map.

As shown, the main station and the exit buildings are located at the bottom part of the image.

When I checked Google Maps, I got this result:

The coordinates were shifted, and submitting them didn’t yield the correct result.

I also tried the English version of Wikipedia, which had the coordinates for the station, but again, they were incorrect. Wikipedia then directed me to Bing Maps:

However, the coordinates from Bing Maps were also inaccurate.

Exploring Other Sources

Next, I started searching for documented articles that might include the exact coordinates for the station. I looked at the Baidu Encyclopedia site:

Unfortunately, it didn’t mention any coordinates.

Finally, after more extensive searching 😵‍💫, I found the Chinese-language version of Wikipedia, specifically tailored for Simplified Chinese characters (used in Mainland China and Singapore).

Link: https://zh.wikipedia.org/zh-cn/%E7%99%BE%E5%AD%90%E6%B9%BE%E7%AB%99_(%E5%9C%B0%E9%93%81)

This page included the coordinates.

Verifying the Coordinates

I quickly entered the coordinates on Google Maps. Although the result was still shifted from the exact building, I refined the search as shown below:

Coordinates: 39.891389, 116.491667

I rounded off the coordinates to 3 decimal points: 39.891, 116.492.

After submitting these refined coordinates, I confirmed that they were the desired ones for this challenge. 😮‍💨

Flag:

irisctf{39.891_116.492}

This marks the last challenge based on the files. Thanks to bobby for creating this amazing challenge; I really enjoyed it.

Forensics

Deldeldel

Challenge Description

Source File: deldeldel.tar.gz

Solution

$ file klogger.pcapng 
klogger.pcapng: pcapng capture file - version 1.0

We received a .pcapng file for this challenge. When I opened it in Wireshark, the packets were exclusively based on the USB protocol.

The mention of “keys” and the file name klogger (key logger) hinted that this was likely a USB Keyboard/Keypad challenge.

USB Protocol challenges are a standard type in the Forensics category of CTFs and often repeat with slight modifications. The goal is to extract the USB HID data or CAP data available at the bottom of the packets, which contains useful information about the user’s activity on the USB device.

Sources:

http://www.usb.org/developers/hidpage/ 

See section 10 Keyboard/Keypad Page (0x07) of document USB HID Usage Tables Version 1.12.

Definition of these 3 bytes can be found in section B.1 Protocol 1 (Keyboard) of document Device Class Definition for HID Version 1.11.

To analyze the user’s activity, we check the flow of USB IN packets (packets sent from the device to the host). These are typically user activities.

Filtering the USB IN Packets

To narrow down the USB IN packets, I applied the following filter in Wireshark:

usb.transfer_type == 1 && usb.endpoint_address.direction == 1

Here, we can see source IPs such as 1.3.2, 1.7.1, 1.5.1, and 1.5.2.

Extracting USB CAP Data

The USB HID data/CAP data is usually 8 bytes. I started by analyzing the packets from 1.3.2, as they had 8-byte CAP data.

To extract the USB capture data, I used the tshark CLI.

$ tshark -r klogger.pcapng -Y "usb.transfer_type == 1 && usb.endpoint_address.direction == 1 && usb.src==1.3.2" -T fields -e usb.capdata > data_1.3.2.txt

Parsing USB CAP Data

For parsing the USB capture data into readable data, I used the following script:

import sys

# USB HID Keymap for decoding key codes
KEY_CODES = {
    0x04: ['a', 'A'], 0x05: ['b', 'B'], 0x06: ['c', 'C'], 0x07: ['d', 'D'],
    0x08: ['e', 'E'], 0x09: ['f', 'F'], 0x0A: ['g', 'G'], 0x0B: ['h', 'H'],
    0x0C: ['i', 'I'], 0x0D: ['j', 'J'], 0x0E: ['k', 'K'], 0x0F: ['l', 'L'],
    0x10: ['m', 'M'], 0x11: ['n', 'N'], 0x12: ['o', 'O'], 0x13: ['p', 'P'],
    0x14: ['q', 'Q'], 0x15: ['r', 'R'], 0x16: ['s', 'S'], 0x17: ['t', 'T'],
    0x18: ['u', 'U'], 0x19: ['v', 'V'], 0x1A: ['w', 'W'], 0x1B: ['x', 'X'],
    0x1C: ['y', 'Y'], 0x1D: ['z', 'Z'], 0x1E: ['1', '!'], 0x1F: ['2', '@'],
    0x20: ['3', '#'], 0x21: ['4', '$'], 0x22: ['5', '%'], 0x23: ['6', '^'],
    0x24: ['7', '&'], 0x25: ['8', '*'], 0x26: ['9', '('], 0x27: ['0', ')'],
    0x28: ['\n', '\n'], 0x2A: ['[BACKSPACE]', '[BACKSPACE]'], 0x2B: ['\t', '\t'],
    0x2C: [' ', ' '], 0x2D: ['-', '_'], 0x2E: ['=', '+'], 0x2F: ['[', '{'],
    0x30: [']', '}'], 0x33: [';', ':'], 0x34: ["'", '"'], 0x36: [',', '<'],
    0x37: ['.', '>'], 0x38: ['/', '?'], 0x39: ['[CAPSLOCK]', '[CAPSLOCK]'],
    0x4F: [u'→', u'→'], 0x50: [u'←', u'←'], 0x51: [u'↓', u'↓'], 0x52: [u'↑', u'↑']
}

def decode_keylogger(file):
    with open(file, 'r') as f:
        lines = f.read().splitlines()

    decoded_output = ""
    for line in lines:
        if len(line) != 16:
            continue

        # Parse the 8-bytes payload
        modifier = int(line[0:2], 16)
        key_code = int(line[4:6], 16)

        # Ignore empty key codes
        if key_code == 0:
            continue

        # Decode keypress
        is_shift = (modifier & 0x02) != 0  # Check if Shift is active
        char = KEY_CODES.get(key_code, [''])[is_shift]  # Select shifted/unshifted char

        if char == '[BACKSPACE]':  # Handle backspace
            decoded_output = decoded_output[:-1]
        else:
            decoded_output += char

    return decoded_output

if __name__ == '__main__':
    if len(sys.argv) < 2:
        print('Usage: python3 script.py <data.txt>')
        sys.exit(1)

    file_path = sys.argv[1]
    result = decode_keylogger(file_path)
    print(result)

$ python3 usbkeyboard.py data_1.3.2.txt 
gabaacbacaabbbbabbabcbbcccdcdcdcccbccbbcbaaaaaaaaabcabadadcacacbacaaabbbacbacbcbb

However, the data retrieved from 1.3.2 was garbage. I then moved on to another source IP (1.5.1), which also had 8-byte CAP data, and repeated the tshark steps.

$ python3 usbkeyboard.py data_1.5.1.txt 
Hheey   AAalicce! Ii  tthink  Ii''m  ssupppooseed  too  giivee yoou   tiss fllaag:

iriisctfF{[tthis_akeyloggeer_iisS_too_hard_to_use}

Creating the Flag

After extracting the data, I cleaned up the received flag and formatted it properly as per the challenge’s defined format.

Flag:

irisctf{this_keylogger_is_too_hard_to_use}

Windy Day

Challenge Description

Solution

We received a memory dump for this challenge. The title, Windy Day, hints towards Windows OS, and the description, lost track of an important note..., suggests we may need to retrieve some crucial information from the memory.

Initial Analysis

I started analyzing the memory dump using Volatility3.

$ python3 vol.py -f memdump.mem windows.info
Volatility 3 Framework 2.12.0
Progress:  100.00		PDB scanning finished                        
Variable	Value

Kernel Base	0xf80365200000
DTB	0x1ab000
Symbols	file:///home/ubuntu/volatility3/volatility3/symbols/windows/ntkrnlmp.pdb/D5E3E35C1C2D48E9906F43C7C05FA3F0-1.json.xz
Is64Bit	True
IsPAE	False
layer_name	0 WindowsIntel32e
memory_layer	1 FileLayer
KdVersionBlock	0xf803654f4df8
Major/Minor	15.14393
MachineType	34404
KeNumberProcessors	1
SystemTime	2025-01-03 17:11:15+00:00
NtSystemRoot	C:\Windows
NtProductType	NtProductServer
NtMajorVersion	10
NtMinorVersion	0
PE MajorOperatingSystemVersion	10
PE MinorOperatingSystemVersion	0
PE Machine	34404
PE TimeDateStamp	Tue Oct 22 04:58:19 2024

As usual, I first listed all the processes.

$ python3 vol.py -f memdump.mem windows.pslist
Volatility 3 Framework 2.12.0
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	File output

4	0	System	0xe38cb727f6c0	98	-	N/A	False	2025-01-03 16:50:11.000000 UTC	N/A	Disabled
.
.
3036	4060	firefox.exe	0xe38cb818b500	89	-	1	True	2025-01-03 16:55:40.000000 UTC	N/A	Disabled
3968	3036	firefox.exe	0xe38cb75b9080	22	-	1	True	2025-01-03 16:55:41.000000 UTC	N/A	Disabled
3624	3036	firefox.exe	0xe38cbb380080	5	-	1	True	2025-01-03 16:55:41.000000 UTC	N/A	Disabled
3828	3036	firefox.exe	0xe38cbb539800	17	-	1	True	2025-01-03 16:55:43.000000 UTC	N/A	Disabled
2420	3036	firefox.exe	0xe38cbb711800	5	-	1	True	2025-01-03 16:55:44.000000 UTC	N/A	Disabled
4076	3036	firefox.exe	0xe38cbb116080	17	-	1	True	2025-01-03 16:55:45.000000 UTC	N/A	Disabled
3132	3036	firefox.exe	0xe38cbb1e1080	5	-	1	True	2025-01-03 16:55:47.000000 UTC	N/A	Disabled
712	 628	ApplicationFra 0xe38cbb573080	1	-	1	False	2025-01-03 16:56:02.000000 UTC	N/A	Disabled
5044	3036	firefox.exe	0xe38cbb7c8800	5	-	1	True	2025-01-03 16:56:43.000000 UTC	N/A	Disabled
4772	3036	firefox.exe	0xe38cbb0d6300	18	-	1	True	2025-01-03 16:57:38.000000 UTC	N/A	Disabled
1380	2856	FTK Imager.exe 0xe38cbb82e800	20	-	1	False	2025-01-03 17:02:19.000000 UTC	N/A	Disabled
5324	3036	firefox.exe	0xe38cbba94080	19	-	1	True	2025-01-03 17:09:52.000000 UTC	N/A	Disabled
5804	3036	firefox.exe	0xe38cbb261080	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
2308	3036	firefox.exe	0xe38cbbb44080	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
2712	3036	firefox.exe	0xe38cbba16080	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
3328	3036	firefox.exe	0xe38cbb8c6800	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
6256	3036	firefox.exe	0xe38cbb884800	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
5288	3036	firefox.exe	0xe38cbb8a9800	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
5664	3036	firefox.exe	0xe38cbb7c9080	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
5196	3036	firefox.exe	0xe38cbb8c0800	19	-	1	True	2025-01-03 17:09:56.000000 UTC	N/A	Disabled
4508	3036	firefox.exe	0xe38cbbbe8800	19	-	1	True	2025-01-03 17:09:59.000000 UTC	N/A	Disabled
4344	3036	firefox.exe	0xe38cbbbb8080	19	-	1	True	2025-01-03 17:10:00.000000 UTC	N/A	Disabled
928     3036	firefox.exe	0xe38cbbc8c080	19	-	1	True	2025-01-03 17:10:00.000000 UTC	N/A	Disabled
740	3036	firefox.exe	0xe38cbb89e400	19	-	1	True	2025-01-03 17:10:01.000000 UTC	N/A	Disabled
2252	3036	firefox.exe	0xe38cb7e25080	19	-	1	True	2025-01-03 17:10:01.000000 UTC	N/A	Disabled
2920	3036	firefox.exe	0xe38cbbc9e080	19	-	1	True	2025-01-03 17:10:01.000000 UTC	N/A	Disabled
3124	3036	firefox.exe	0xe38cbbca0080	19	-	1	True	2025-01-03 17:10:01.000000 UTC	N/A	Disabled
7116	3036	firefox.exe	0xe38cb7e32680	19	-	1	True	2025-01-03 17:10:01.000000 UTC	N/A	Disabled

Among them, I noticed multiple firefox.exe processes running. I decided to dump all the files of the Firefox process with PID 3036:

$ python3 vol.py -f memdump.mem windows.dumpfiles --pid 3036

This command yielded some DLLs and database files such as .db and .sqlite.

permissions.sqlite  favicons.sqlite  cookies.sqlite  places.sqlite  formhistory.sqlite  storage.sqlite  cert9.db  key4.db 
domain_to_categories.sqlite  protections.sqlite  content-prefs.sqlite  bounce-tracking-protection.sqlite  data.sqlite

Exploring the Databases

I analyzed these database files using DB Browser.

The places.sqlite and cookies.sqlite files contained search history data. Below is a snapshot of the data from places.sqlite:

Initially, I suspected that the flag might have been uploaded to a file-sharing site like file.io. I explored the file.io site links but found no useful results.

Further Investigation

Next, I dumped the memory of the firefox.exe process for deeper analysis:

$ python3 vol.py -f memdump.mem windows.memmap --pid 3036 --dump

This generated a pid.3036.dmp file. I ran strings on this file and noticed several links, which led me to Google Sites.

$ strings pid.3036.dmp | grep "https://www.google.com/search?"
{"1":{"0":"https://www.google.com/search?client=firefox-b-d&q=ftk+imager+portable"}}
https://www.google.com/search?client=firefox-b-d&q=ftk+imager+portable ftk imager portable - Google Search
https://www.google.com/search?client=firefox-b-d&q=
https://www.google.com/search?client=firefox-b-d&q=ftk+imager+portable
https://www.google.com/search?client=firefox-b-d&q=
https://www.google.com/search?client=firefox-b-d&q=aXJpc2N0ZntpX2FtX2
.
.
https://www.google.com/search?client=firefox-b-d&q=aXJpc2N0ZntpX2FtX2FuX2lkaW90X3dpdGhfYmFkX21lbW9yeX0%3D
.

Among the search queries, one appeared to be encoded in Base64.

Decoding the Base64 String

I decoded the Base64 string using the following command:

$ echo "aXJpc2N0ZntpX2FtX2FuX2lkaW90X3dpdGhfYmFkX21lbW9yeX0=" | base64 -d
irisctf{i_am_an_idiot_with_bad_memory}

Boom! We got our flag!!!

Flag:

irisctf{i_am_an_idiot_with_bad_memory}

Alternate Approach

Later, I realized the same result could have been achieved by directly running strings with base64 of “irisctf{“ on the main memdump.mem file, which would have saved some effort. 😛

Tracem1

Challenge Description

Source File: tracem-1.tar.gz

Solution

For this challenge, we need to identify the culprit. We were provided with a logs.json file packed with DHCP, DNS, Active Directory, and syslog logs.

• The DHCP Logs show the assignment of IP addresses.
• The DNS Logs contain records of IP address resolutions for websites.
• The Active Directory Logs include the names of the employees within the company.
• The Syslog Logs are primarily focused on authentication and also contain the names of the employees.

Let’s analyze the file:

{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:30:39.50", "data": {"timestamp": "2024-12-04 06:30:38.816111", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.49.0.2", "src_port": 53, "dest_ip": "10.49.81.65", "dest_port": 2561, "transaction_id": 54938, "answers": [{"type": "AAAA", "class": "IN", "name": "dropbox.com", "addr": "2620:100:6040:18::a27d:f812"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:30:39.69", "data": {"timestamp": "2024-12-04 06:30:38.819396", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.0.2", "src_port": 53, "dest_ip": "10.33.81.223", "dest_port": 10338, "transaction_id": 8697, "answers": [{"type": "AAAA", "class": "IN", "name": "hr.evil-insurance.corp", "addr": null}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:30:39.40", "data": {"timestamp": "2024-12-04 06:30:38.959049", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.51.247.145", "src_port": 9037, "dest_ip": "10.51.0.2", "dest_port": 53, "transaction_id": 689, "queries": [{"type": "AAAA", "class": "IN", "name": "gitlab.evil-insurance.corp"}]}}

We can see references to many links accessed by different employees, along with their IP addresses and MAC addresses.

Since the challenge was related to computer networks, I started by checking all the URLs accessed by the employees.

$ grep -o '"name": *"[^"]*"' logs.json | sed -E 's/"name": *"([^"]*)"/\1/'

So these were the urls:

connectivitycheck.gstatic.com
www.msftconnecttest.com
time.windows.com
.
it.evil-insurance.corp
evil-insurance.corp
chat.evil-insurance.corp
service.evil-insurance.corp
hr.evil-insurance.corp
gitlab.evil-insurance.corp
files.evil-insurance.corp
meetings.evil-insurance.corp
guestportal.evil-insurance.corp
sso.evil-insurance.corp
.
aftermarket.pl
bp0.blogger.com
copious-amounts-of-illicit-substances-marketplace.com
breachforums.st
smith-wesson.com
bmj.com
thedailybeast.com
welt.de

There were some safe sites, as well as sites related to the evil-insurance (EI) Corp Company.

Out of all the sites, I found the following to be very suspicious:

copious-amounts-of-illicit-substances-marketplace.com
breachforums.st

Since these sites were also matching the keywords mentioned in the description, I proceeded to check who accessed both of these sites.

$strings logs.json | grep -E "copious-amounts-of-illicit-substances-marketplace.com|breachforums.st"
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:30:18.99", "data": {"timestamp": "2024-12-04 06:30:18.347812", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.18.209", "src_port": 7419, "dest_ip": "10.33.0.2", "dest_port": 53, "transaction_id": 45042, "queries": [{"type": "A", "class": "IN", "name": "copious-amounts-of-illicit-substances-marketplace.com"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:30:19.21", "data": {"timestamp": "2024-12-04 06:30:18.572830", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.0.2", "src_port": 53, "dest_ip": "10.33.18.209", "dest_port": 7419, "transaction_id": 45042, "answers": [{"type": "A", "class": "IN", "name": "copious-amounts-of-illicit-substances-marketplace.com", "addr": "104.16.148.244"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:33:36.80", "data": {"timestamp": "2024-12-04 06:33:36.803488", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.18.209", "src_port": 52836, "dest_ip": "10.33.0.2", "dest_port": 53, "transaction_id": 50295, "queries": [{"type": "A", "class": "IN", "name": "breachforums.st"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:33:37.18", "data": {"timestamp": "2024-12-04 06:33:37.175597", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.0.2", "src_port": 53, "dest_ip": "10.33.18.209", "dest_port": 52836, "transaction_id": 50295, "answers": [{"type": "A", "class": "IN", "name": "breachforums.st", "addr": "185.129.102.136"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:50:51.87", "data": {"timestamp": "2024-12-04 06:50:51.748497", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.18.209", "src_port": 22966, "dest_ip": "10.33.0.2", "dest_port": 53, "transaction_id": 33048, "queries": [{"type": "A", "class": "IN", "name": "breachforums.st"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 06:50:52.14", "data": {"timestamp": "2024-12-04 06:50:52.021816", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.33.0.2", "src_port": 53, "dest_ip": "10.33.18.209", "dest_port": 22966, "transaction_id": 33048, "answers": [{"type": "A", "class": "IN", "name": "breachforums.st", "addr": "185.129.102.136"}]}}

As expected, the same IP address (10.33.18.209) accessed both of these sites.

Let’s analyze the syslog:

{"host": "primary", "source": "udp:514", "sourcetype": "syslog", "_time": "2024-12-04 04:58:36.95", "data": {"_raw": "2024-12-04 04:58:35.622504||https://sso.evil-insurance.corp/idp/profile/SAML2/Redirect/SSO|/idp/profile/SAML2/Redirect/SSO|5b52053ac1ab1f4935a3d7d6c6aa4ff0|authn/MFA|10.33.18.209|Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3 Edge/16.16299|https://sso.evil-insurance.corp/ns/profiles/saml2/sso/browser|llloyd||uid|service.evil-insurance.corp|https://sso.evil-insurance.corp/idp/sso|url:oasis:names:tc:SAML:2.0:protocol|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|kzYQV+Jk2w3KkwmRjR+HK4QWVQ3qzLPLgA5klV2b8bQT+NLYLeqCZw5xUGKbx1U1158jlnUYRrILtVTtMkMdbA==|urn:oasis:names:tc:SAML:2.0:nameid-format:transient|_60b0fd4b0ed5bba3474faeb85b3944e|2024-12-04 04:58:35.622504|_c4b56d58-625b-49aa-b859-4a2068422979||||urn:oasis:names:tc:SAML:2.0:status:Success|||false|false|true", "timestamp": "2024-12-04 04:58:35.622504", "NLYLeqCZw5xUGKbx1U1158jlnUYRrILtVTtMkMdbA": "=|urn:oasis:names:tc:SAML:2.0:nameid-format:transient|_60b0fd4b0ed5bba3474faeb85b3944e|2024-12-04"}}

I then checked the syslog for this IP address and found the name of the employee associated with it: llloyd.

Creating the Flag

With the gathered information, I constructed the flag using the defined format, and boom, that was the correct flag.

Flag:

irisctf{llloyd}

Tracem2

Challenge Description

Source File: tracem-2.tar.gz

Yeah some of the teams had 600+ and 1300+ attempts.😂

Solution

This challenge is a continuation of the Tracem1 challenge. For better context, you can refer to my Tracem1 write-up. Unfortunately, I was only able to solve this challenge partially during the CTF duration 🥹. I delved too deeply into analysis and missed a critical clue. However, I’ll share all the data and steps I took while solving it.

Challenge Overview

We received a logs.json file for this challenge. Similar to Tracem1, I began analyzing the logs.

Here are some notable sites accessed in the logs.json file:

detectportal.firefox.com
www.msftconnecttest.com
.
3.fedora.pool.ntp.org
0.arch.pool.ntp.org
globo.com
reg.ru
1.ubuntu.pool.ntp.org
politico.com
enable-javascript.com
mozilla.com
fb.me
20minutos.es
last.fm
xda-developers.com
unicef.org
nypost.com
target.com
kickstarter.com
2.arch.pool.ntp.org
.
gitlab.evil-insurance.corp
hr.evil-insurance.corp
files.evil-insurance.corp
meetings.evil-insurance.corp
it.evil-insurance.corp
evil-insurance.corp
chat.evil-insurance.corp
service.evil-insurance.corp
guestportal.evil-insurance.corp
sso.evil-insurance.corp
evil-insurance.corp
.
ubuntu.com
thepiratebay.org
generic-illicit-activities-hub.org
deloitte.com
bp0.blogger.com

These two sites seemed suspicious:

• thepiratebay.org
• generic-illicit-activities-hub.org

I then identified the user who accessed both sites:

$ strings logs.json | grep -E "thepiratebay.org|generic-illicit-activities-hub.org"
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 08:51:51.12", "data": {"timestamp": "2024-12-04 08:51:51.092921", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.21.121", "src_port": 48851, "dest_ip": "10.18.0.2", "dest_port": 53, "transaction_id": 119, "queries": [{"type": "A", "class": "IN", "name": "thepiratebay.org"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 08:51:51.13", "data": {"timestamp": "2024-12-04 08:51:51.102210", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.21.121", "src_port": 2975, "dest_ip": "10.18.0.2", "dest_port": 53, "transaction_id": 13007, "queries": [{"type": "AAAA", "class": "IN", "name": "thepiratebay.org"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 08:51:53.22", "data": {"timestamp": "2024-12-04 08:51:52.449001", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.0.2", "src_port": 53, "dest_ip": "10.18.21.121", "dest_port": 48851, "transaction_id": 119, "answers": [{"type": "A", "class": "IN", "name": "thepiratebay.org", "addr": "104.16.148.244"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 08:51:53.22", "data": {"timestamp": "2024-12-04 08:51:52.450021", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.0.2", "src_port": 53, "dest_ip": "10.18.21.121", "dest_port": 2975, "transaction_id": 13007, "answers": [{"type": "AAAA", "class": "IN", "name": "thepiratebay.org", "addr": null}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 09:05:01.12", "data": {"timestamp": "2024-12-04 09:05:00.400067", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.21.121", "src_port": 22066, "dest_ip": "10.18.0.2", "dest_port": 53, "transaction_id": 2835, "queries": [{"type": "A", "class": "IN", "name": "generic-illicit-activities-hub.org"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 09:05:00.70", "data": {"timestamp": "2024-12-04 09:05:00.520979", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.21.121", "src_port": 64559, "dest_ip": "10.18.0.2", "dest_port": 53, "transaction_id": 3019, "queries": [{"type": "AAAA", "class": "IN", "name": "generic-illicit-activities-hub.org"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 09:05:01.76", "data": {"timestamp": "2024-12-04 09:05:01.197568", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.0.2", "src_port": 53, "dest_ip": "10.18.21.121", "dest_port": 22066, "transaction_id": 2835, "answers": [{"type": "A", "class": "IN", "name": "generic-illicit-activities-hub.org", "addr": "96.16.243.221"}]}}
{"host": "primary", "source": "stream:dns", "sourcetype": "stream:dns", "_time": "2024-12-04 09:05:01.72", "data": {"timestamp": "2024-12-04 09:05:01.201187", "protocol_stack": "ip:udp:dns", "transport": "udp", "src_ip": "10.18.0.2", "src_port": 53, "dest_ip": "10.18.21.121", "dest_port": 64559, "transaction_id": 3019, "answers": [{"type": "AAAA", "class": "IN", "name": "generic-illicit-activities-hub.org", "addr": null}]}}

Suspicious User Identification

The suspicious user had the following attributes:

IP Address: 10.18.21.121
MAC Address: de:ad:be:ef:ca:fe (a spoofed address)

Activity Timeline of the Suspicious User

Event	Time of the event
Req for the addr 10.18.21.121	2024-12-04 08:49:20.52
Get assigned that addr	2024-12-04 08:49:21.00
Access www.google.com	2024-12-04 08:49:34.58
Access 2.arch.pool.ntp.org	2024-12-04 08:51:18.72
Access thepiratebay.org	2024-12-04 08:51:51.12
Access generic-illicit-activities-hub.org	2024-12-04 09:05:01.12
Releases the IP addr	2024-12-04 09:22:01.12

This was another challenge in the Tracem series, so it wasn’t going to be straightforward to solve via syslog logs. Additionally, the suspicious IP (10.18.21.121) didn’t have any corresponding syslog logs, making direct identification of the user more difficult.

Since I had already established that the suspicious IP (10.18.21.121) was the only one to access the two suspicious sites (thepiratebay.org and generic-illicit-activities-hub.org), I decided to investigate further.

To narrow down potential leads, I began analyzing who else accessed 2.arch.pool.ntp.org.

I got these result:

10.50.103.29
10.66.91.95
10.66.68.75
10.17.161.10
10.34.192.28
10.65.26.90
10.65.68.160
10.51.64.145
10.66.156.255
10.35.126.228
10.67.252.116
10.17.6.47
10.50.184.143
10.18.21.121
10.49.220.32
10.49.79.62
10.49.65.21
10.17.90.14
10.17.26.247
10.17.171.253
10.65.228.127

Initial Misstep

At this point, I noticed that the user accessed 2.arch.pool.ntp.org, a relatively common URL. I assumed it wasn’t suspicious and did not cross-reference other IPs that accessed this site during the same timeframe. This was my critical oversight.

Feel free to skip the rest if you’d like—I’ll now share what I explored after this step.

Investigation Details

Extraction and Analysis

1. MAC Addresses:

I extracted all MAC addresses to look for other spoofed addresses but found no results.

2. IP Segmentation:

I identified recurring IP ranges in the logs:

10.17.X.X
10.18.X.X
10.19.X.X
10.33.X.X
10.34.X.X
10.35.X.X
10.49.X.X
10.50.X.X
10.51.X.X
10.65.X.X
10.66.X.X
10.67.X.X

3. Syslog SSO Logs:

Only the following IP ranges appeared in syslog SSO logs:

10.17.X.X
10.19.X.X
10.33.X.X
10.35.X.X
10.49.X.X
10.51.X.X
10.65.X.X
10.67.X.X

So it was certain that I would get the username from this set of IPs.

Looking at these IPs, I thought this challenge might be based on Network Segmentation. It appeared that there were four buildings and three subnets, which Skat later confirmed on Discord.

4. Network Proximity Assumptions:

I hypothesized that the suspicious user might have moved laterally to a new subnet, maintaining the same host/octet structure.

From 10.17.X.X and 10.19.X.X:

• Likely Subnets: 10.17.21.xxx, 10.17.121.xxx, etc.
• Likely Hosts: 10.17.x.121.

Despite exploring these, I found no leads.

Then I moved on to checking the full logs.json file around the timeline of the IP guy. By this time, this challenge was my last one left, and I was very tired, so I couldn’t search properly.

Aftermath

After the CTF Competition, Jakob (discord) mentioned that I should have checked the IPs accessing 2.arch.pool.ntp.org around the timeline of the suspicious user (10.18.21.121).😿

Jakob’s Tracem2 Writeup

Key Table (from Jakob’s Write-Up):

Timestamp	Events	Notes
2024-12-04 08:45:33.555166	10.17.161.10 ( mhammond ) disconnects from network	releases 10.17.161.10 + pause in traffic from 10.17.161.10
2024-12-04 09:42:00.907257	IP assignment to 10.17.161.10 ( mhammond )	traffic from 10.17.161.10 continues

This IP (10.17.161.10) was the closest to the suspicious user’s timeline. The username associated with this IP was mhammond, making them the culprit.

Flag:

irisctf{mhammond}

Reflection

This challenge reinforced the importance of checking all data points and avoiding assumptions during investigations. Despite missing the critical clue during the competition, I gained valuable insights and improved my analysis techniques.
Thanks skat for the cool challenges.