SOURCE — CAT CTF 26 OSINT Challenge Official Write-up

Introduction

Hello guys, hope you are doing well!

First of all, thanks to all the participants this year. It was a pleasure to have you all around.

This year, I created a single OSINT challenge, SOURCE. The challenge focused on threat intelligence and was actually inspired by a real case scenario.

Sadly, I forgot to take a screenshot from the platform, but the challenge had only 1 solve during the whole CTF (even after releasing some hints :( ).

here is how the challenge looked like in platform btw (fr😶) ( sorry for removing your name db1M :” )

So, let’s walk through the chain and see how we can go from one leaked credential to the log it came from.

Challenge Description

TREAT ALL INFO RELATED TO THIS CHALLENGE AS CONFIDENTIAL

Under a private retainership agreement, your Threat Intelligence unit provides continuous dark-web and surface-web exposure monitoring for high-net-worth clients.

During this morning’s telemetry sweeps, an exposure detection alert fired: critical credentials belonging to the client surfaced in an indexed leak. Initial triage suggests this wasn’t a standard database dump—it bears the signature exfiltration fingerprints of an active infostealer operation.

Your objective is to trace this exposure back to ground zero, reconstruct the attacker’s exfiltration pathway, and determine the exact blast radius.

Target Lead

nayaf███@gmail.com:xxxxxx          //redacted the email since we are publishing this public XD

Incident Response Deliverables

1. Victim Origin: Client’s public IP address at time of compromise.
2. Breach Timestamp: Exact time the endpoint was infected [YYYY-MM-DD hh:mm UTC].
3. Exfiltration Timestamp: Exact time the archive was first uploaded to a file hosting service [YYYY-MM-DD hh:mm:ss].
4. Attribution: Specific malware family responsible for harvesting the credential.
5. C2 Infrastructure: All primary Telegram channel/bot handles associated with the log drop [@TGCHANNEL1:@tgchannel2].

Flag Construction

CATF{<IP>_<BREACH_TIME>_<UPLOAD_TIME>_<MALWARE>_<TELEGRAM_HANDLES>}

Example: CATF{192.0.2.1_2015-05-10 14:32_2015-02-10 11:45:02_redline_@dumpchannel:@stealerbot}

Solution Walkthrough

1. What Are We Actually Looking For?

Let’s start by carefully reading the description and breaking down what we know, what we have, and where we should look.

The description mentions an infostealer operation, and our starting point is an email address. That narrows our investigation to a stealer log from the victim’s machine.

An infostealer collects information from an infected endpoint. Its output can include saved browser credentials, autofill data, and details about the device. That explains why the challenge asks for things like the victim’s IP and infection time: those details may be recorded alongside the stolen data.

A credential appearing in a leak tells us that it was exposed. We still need to work out which record it belongs to and how that record ended up being published.

2. Starting with IntelX

Taking the email as our starting point, let’s look at the results from Intelligence X (IntelX).

From this query, we can already identify a few interesting things.

First, the results contain paths such as Browser/Passwords, Browser/Cache, and Browser/AutoFills. These look like files collected from a browser profile, which fits the description of a stealer log.

Second, several paths start with [SA]94.98.79.157. The SA country code points to Saudi Arabia, and the IP is a strong candidate for our first answer.

But a filename is still just a clue. Before putting that IP in the flag, let’s confirm it against the victim record.

3. Confirming the Victim IP with Oathnet

In the IntelX view shown above, accessing the full contents required a subscription. So, I moved to Oathnet, where the results exposed more of the relevant metadata.

We get four IP addresses. The interface labels three as being in the USA and one as being in Saudi Arabia.

At first glance, the Saudi IP looks like the obvious match because it agrees with the country code in the IntelX paths. Still, geolocation alone isn’t enough to decide which IP belongs to the victim. An indexed record can contain several addresses, and they don’t all have to describe the infected endpoint.

The useful confirmation is inside the victim details. Open the Raw tab, and we find these fields:

{
  "pwned_at": "2026-06-16T19:50:00Z",
  "indexed_at": "2026-07-13T11:24:54Z",
  "victim_ip": "94.98.79.157"
}

This is a shortened extract of the fields we need. The important part is that the record explicitly identifies 94.98.79.157 as victim_ip, matching the address from IntelX.

So, now we have our first answer:

94.98.79.157

4. Separating the Infection Date from the Indexing Date

The same record also gives us the second answer, but let’s make sure we read the right timestamp.

• pwned_at is the compromise timestamp reported by the platform for this record. This is the field used for the challenge’s breach-time answer.
• indexed_at tells us when the platform indexed the record. It is a later event, not the infection time.

The Z at the end of the timestamps means UTC. Since the flag asks for the breach time to the minute, our answer becomes:

2026-06-16 19:50

We will cross-check that time against the original log later. For now, also keep July 13 in mind, because the indexing date gives us another lead.

5. Narrowing the Publication Window

Taking one step back to IntelX, some of the matching files appear under a different archive name containing the date July 7, 2026.

Now we have a July 7 date embedded in an archive name and a July 13 indexing date in Oathnet. That gives us a useful starting window: July 7–13.

This needs a small clarification: a date inside an archive name doesn’t prove when the file was uploaded. It might reflect packaging or naming, and logs can be renamed or republished. Likewise, an indexing date doesn’t identify the original publication source.

So, this window helps us prioritize the search. It isn’t proof that every copy of the data must have been uploaded during those six days.

6. Following the Public Log Drops

Assuming the data had been publicly shared, my next stop in this investigation was cracked.st, where I looked through the leak posts.

(Assuming you don’t know that, you will take a tour in some breach website until you will eventually make it anyway, so don’t worry.)

You will see the term ULP around these posts. It stands for URL, login, password: credential entries associated with a service. A full stealer log can contain additional device and collection metadata, which is what we need for the remaining questions.

For the search in this write-up, I used the Leaks category, searched for stealer, sorted by post creation time, and focused on the July 7–13 window.

Post creation time matters here because a new reply can bring an older thread back to the top. The last reply date doesn’t tell us when the archive was originally advertised.

We end up with around 20 posts, which is still enough to need some filtering.

First, we can set aside unrelated results, such as posts under Monetizing Techniques. They mention stealers, but they aren’t the log drops we are trying to match.

In the set I reviewed, the two main publishers left to compare were DevelMakss and fatetraffic.

7. Comparing the Archive Structure

The next clue is the file structure. We already saw how the indexed paths were organized, so we can compare that with the sample archives from these publishers.

The DevelMakss sample used a different naming pattern:

The fatetraffic sample looked closer to our lead, with country codes at the beginning of the folder names:

That makes fatetraffic worth checking first. The naming pattern alone doesn’t confirm the match, especially since repackaging can change folder names. We still need the contents to agree with the victim record.

At this point, I had around 5–6 posts from fatetraffic to choose from.

So, in the worst case, there would still be six candidate archives to check, but as they say “Moderation is key” , so let’s just pick the post on 10-07-2026.

To be clear, picking the middle date isn’t a deduction from the evidence. It was the candidate I checked, and the confirmation comes in the next step.

8. Confirming the Matching Log

Inside that archive, we find the Saudi Arabia entries:

And seems like we’ve made it there.

After matching the original lead against the archive, the relevant UserInformation.txt gives us the details we need:

The IP matches 94.98.79.157, and the log date is June 16, 2026, at 22:50. Wait, wasn’t our answer 19:50?

Look a little further down: the log reports TimeZone: UTC+3.

2026-06-16 22:50 (UTC+3)
                 - 3 hours
2026-06-16 19:50 (UTC)

Now it agrees with Oathnet’s pwned_at value. The matching IP and timestamp give us much stronger confirmation than a similar folder name.

The branding line also lists the three Telegram handles used in the challenge answer:

@FATETRAFFIC:@GGFATE:@FATEPRODUCTBOT

The description calls this part C2 Infrastructure, but what we can directly establish from this screenshot is that these handles are advertised in the log. That associates them with the log drop; it doesn’t, by itself, prove that the infected machine communicated with each handle as a command-and-control endpoint.

9. Finding the File-Host Upload Timestamp

The next piece is the upload time of the archive linked in the forum post.

On the Pixeldrain page, the Details panel gives us the file metadata:

The displayed Upload Date is:

2026-07-10 13:00:50

This is the value used for the challenge’s upload-time field, exactly as displayed in the screenshot.

Also, this records the upload of that archive to Pixeldrain. It doesn’t establish the first time the malware sent data off the victim’s machine, or rule out an earlier copy elsewhere. The challenge uses the term exfiltration timestamp for the file-host upload, so keep that distinction in mind.

10. The FateTraffic Attribution

Finally, we need the malware name.

By now, the publisher name, archive branding, and Telegram handles all point to FateTraffic. My original lookup also returned this summary:

But that summary alone isn’t enough to establish a malware family. A log distributor can repackage data, and the distributor’s branding doesn’t automatically identify the software that collected it.

For an external reference, MyCERT’s Q3 2025 incident report lists Fatetraffic Cloud Stealer among the infostealers reported to it. This supports the use of the name in threat reporting, while the artifacts above explain why FateTraffic is the intended answer here.

FateTraffic

Final Flag

Now we can put all the pieces together:

Field	Challenge answer	Supporting evidence
Victim IP	94.98.79.157	IntelX paths, Oathnet’s victim_ip, and the matching log
Breach time, UTC	2026-06-16 19:50	Oathnet’s pwned_at, cross-checked against the UTC+3 log time
File-host upload time	2026-07-10 13:00:50	The Upload Date displayed in Pixeldrain’s Details panel
Attribution expected by the challenge	FateTraffic	The log branding and associated publication chain
Telegram handles	@FATETRAFFIC:@GGFATE:@FATEPRODUCTBOT	The branding line in the matching log

Using the order and formatting required by the challenge:

CATF{94.98.79.157_2026-06-16 19:50_2026-07-10 13:00:50_FateTraffic_@FATETRAFFIC:@GGFATE:@FATEPRODUCTBOT}

Conclusion

My goal with this challenge was to give you a taste of how a threat intelligence investigation can grow from a single lead. You start with limited information, figure out what questions to ask, and use each finding to decide where to look next. Along the way, you learn to narrow down possibilities, connect clues from different sources, and build a clearer picture of what happened.

The advice I want you to take away is simple: stay curious, be patient, and question your assumptions. A result that looks right is worth investigating, but you still need to understand its context and check whether the evidence supports your conclusion. And if a lead doesn’t work out, take a step back and try another approach. That’s part of the process too :)

For sure, this isn’t the only way to solve this challenge. At the end of the day, threat intelligence is all about methodology: how you follow the clues, connect the information, and verify what you find.

This write-up covers the path I took, but I can’t claim to cover every possible solution, source, or approach. You might start somewhere else, use different sources, or find a shorter route to the same answers.

As long as you reach your end goal and have the evidence to support your answers, that’s what matters. You don’t have to follow my exact steps :)

I hope you enjoyed this challenge as much as I did creating it. Thanks again to everyone who participated!

Thank you for reading, and I hope you found it helpful, learned some new stuff, and enjoyed solving the challenge.

If you have any questions or comments, feel free to contact me on LinkedIn — Discord — GitHub