How We Solved the C0C0N CTF: A Story of Late Starts, Quick Thinking, and Teamwork

When our team jumped into the C0C0N CTF, the competition clock was already halfway done. Many teams had a head start, but that didn’t slow us down. With a mix of quick reconnaissance, careful analysis, we tackled a range of challenges from exposed API endpoints and DNS exfiltration to GitHub commit history leaks.

Even with a late start, we managed to secure 20th place.

Network Challenges:

🚨 The Alert

Time: 01:50 AM, Friday, September 12, 2025. An alarm blared at the Adversary City Cyber Defense Unit. The ACPD’s Public Evidence Submission Portal had been breached. Initial telemetry suggested the Shadow Snakes were behind it. They didn’t just break a server; they broke the public’s trust.

As the lead incident responder, I was given:

• A raw Apache access log (apache_access_1.log)
• A network traffic capture (capture_1.pcap)

My mission: Find the attacker’s footprint, reconstruct the attack chain, and identify what was stolen.

🔍 Step 1: Finding the Attacker’s Footprint

The Apache log was filled with noise — routine traffic, automated scans, and harmless requests. But one IP address stood out: 203.0.113.10. It was repeating the same unusual pattern.

Using this filter in Wireshark:

ip.addr == 203.0.113.10

I found the smoking gun a path traversal attack:

GET /view.php?file=../../../../.env HTTP/1.1
Host: 203.0.113.10
User-Agent: http_cloner/1.09.0 (Linux x86_64)

The custom User-Agent was the attacker’s fingerprint — their tool was leaving a distinct signature.

c0c0n-ctf{http_cloner/1.09.0 (Linux x86_64)}

🔍 Step 2: The Silent Breach

Following the HTTP stream for this request, I found the server’s response:

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 126

APP_ENV=production
APP_DEBUG=false
DB_NAME=acpd_evidence_vault
DB_USER=evidence_user
DB_PASS=ChangeMeInProd!
DB_HOST=127.0.0.1

The attacker had successfully leaked the database credentials. Their target was clear: the evidence database.

c0c0n-ctf{acpd_evidence_vault}

🔍 Step 3: Whispers in the Wire - The Hidden C2 Channel

The attacker exfiltrated an encrypted package. The brief mentioned they “repurposed a fundamental internet protocol” for secret communications. I knew this pointed to DNS tunneling — a classic technique for covert data exfiltration and C2.

I filtered the traffic for the attacker’s IP to focus only on their activity:

ip.addr == 203.0.113.10

Then, I specifically looked for DNS traffic involving this IP:

dns and ip.addr == 203.0.113.10

Scrolling through the packets, I quickly spotted an anomalous DNS query to status.cdn-updates.test requesting a TXT record. The domain name itself seemed suspicious—like a prearranged drop point.

The corresponding DNS response contained a TXT record with the value:
K9p3-4vQx-72Bm-NEt1

This was the decryption key delivered out-of-band via DNS — exactly as the brief described. The Shadow Snakes used DNS as their hidden command-and-control channel, bypassing traditional security monitoring that might focus only on HTTP traffic.

c0c0n-ctf{K9p3-4vQx-72Bm-NEt1}

API Challenges: Fire Station 13 at Risk

Uncovering the API Breach That Threatened Adversary City’s Emergency Response

🚨 The Crisis at Fire Station 13

Fire Station 13 stood as a symbol of strength and reliability in Adversary City — until their digital infrastructure became the target of a sophisticated attack. While firefighters battled blazes, a different kind of threat smoldered in their computer systems, where small oversights in their incident management application created catastrophic vulnerabilities.

The station’s seemingly ordinary shift assignment and incident logging tools had become the entry point for attackers. Exposed APIs provided a direct path to sensitive information: firefighter rosters, dispatch records, response times, and eventually, their secure communication system.

🔍 Step 1: Initial Reconnaissance and Flag Discovery

I began with the target: http://adversary-city-firestation13.adversarycity.online

Basic enumeration revealed critical endpoints:

# Discovering the initial vulnerability
curl http://adversary-city-firestation13.adversarycity.online/api/flag.txt

The response was immediate and gave the flag directly.

🔍 Step 2: The Backdoor

The situation escalated when I discovered the secure communication application had been compromised. What should have been their digital shield had become their greatest vulnerability.

This challenge i spent time finding API endpoints using the older url which wasn’t. So just to give a try i search for the API endpoint on public postman collection where i got the endpoints to query.

Critical Clue Discovery

The website footer contained an IP address that would prove crucial: 206.189.142.59:8888

Following the trail to Postman collections, I found the API clue:

curl http://206.189.142.59:8888/api/v1/clue

Response:

{
    "clue": "Study this: https://www.rfc-editor.org/rfc/rfc9110.html#name-methods, 
            https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.2, 
            and 'ADVERSARY_WARS@c0c0n' might be the key you're looking for ;)"
}

RFC 9110 Analysis

The RFC documents revealed critical insights about HTTP methods and authentication mechanisms. Section 5.6.2 specifically discussed custom HTTP methods and authentication headers — exactly what the attackers had exploited.

🔍 Step 3: Crafting the Counter-Attack

The clue ADVERSARY_WARS@c0c0n wasn't just a string—it was a custom HTTP method. According to RFC 9110, methods are case-sensitive and can be extended for specific applications.

crafted this request which led to a different error.

curl -X "ADVERSARY_WARS@c0c0n" -H "User-Agent: UNIT-8-SYS4-AE11" http://206.189.142.59:8888/api/v2/getflag

{"error":"Error Detected"}

then upon testing older version would reveal the full extent of the compromise:

curl -X "ADVERSARY_WARS@c0c0n" -H "User-Agent: UNIT-8-SYS4-AE11" http://206.189.142.59:8888/api/v1/getflag

The response was chilling:

{
    "flag": "c0c0n-ctf{d983d887184fe083159d95c83e78c281} - 
            So, can you crack the code from this so-called secure app right now? → 
            http://139.59.60.26/api/s3cure-app/"
}

c0c0n-ctf{d983d887184fe083159d95c83e78c281}

🚨 The Leak Challenge Infra

Challenge Hint: The story mentioned a developer’s “quick fix” that was later meant to be cleaned up. That pointed directly to hardcoded credentials accidentally committed to version control.

What I Did:

• Searched GitHub for GridTech Inc. or related repositories.
• Looked for a diagnostic tool repo, likely named something like gridtech-diagnostics or power-station-tool.
• Found a older commit where the developer had hardcoded a username and password in a config file.
• Used those credentials to form the flag in the format:
  c0c0n-ctf{username:password}

c0c0n-ctf{c0c0n_2025_Adv_admin:PowerGrid_c0c0n_2025_Adv!}