前言

随着 Solar 月赛临近尾声，第三届 Solar 年赛也将在年底如期而至。本届年赛赛制全面升级，分为线上初赛与线下决赛两个阶段；月赛总榜前三名将直通线下决赛，差旅全包。比赛详情将在后续文章中陆续发布，敬请期待。

也请各位选手珍惜最后两场月赛——当前分差极小，往往 1、2 分之差，便足以决定最终名次。

1.9月月赛排名

2026年9月Solar应急响应公益月赛已圆满结束。以下为最终WP提交情况

以下为9月月赛最终排名结果

月赛榜总分统计（积分相同排名并列）

天狩·网络安全竞赛平台是由 思而听网络科技有限公司 推出的一款Saas化部署的网络安全竞赛平台。平台可满足CTF、AWD、渗透赛等各种赛制的举办需要，可以满足万人同时竞赛的需要，支持最高全国级的网络安全大赛承办。具备竞赛中心、竞赛管理、练习场、试卷管理、赛题管理、人员管理、报名管理、数据中心、日志管理、防作弊机制、3D大屏等功能模块，能够全面、精准地考核选拔网络安全人才。

本次应急响应挑战赛围绕钓鱼邮件分析、主机取证、新兴威胁排查和网络流量监测四类场景，构建了七条完整分析链：邮件头溯源与勒索家族匹配、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，而在于选手能否将邮件取证、内存分析、日志溯源、流量解析、逆向工程和威胁情报串联起来，完成从异常发现、攻击链还原到证据提取与检测规则落地的完整闭环。

趋势榜单

解题榜单

我们不留存业务数据

一、题目说明

1.1 场景背景

黑客拿下了一个中转站，在上面抓了一部分数据开始研究...

1.2 任务目标

1. 用户使用的模型id是什么
2. 用户的服务器密码是什么
3. AI在服务器上执行的第一个命令是什么
4. 用户这些请求花了多少钱（单位人民币，以当前官方API价格计，精确到小数点后8位）

1.3 Flag 格式说明

flag{xxxxxxxx}，共4个Flag，全部为静态提交。

二、环境信息

2.1 靶场架构

静态流量分析题

2.2 部署方式

2.3 环境依赖说明

无

三、靶场附件清单

四、考点设计

4.1 排查路径

1. 分析网络TCP流，找到请求明文
2. 找到LLM读取本地文件中附带的敏感信息
3. 找到LLM工具调用的请求与返回内容
4. 根据请求返回的用量信息，计算出用户花费

4.2 考核点清单

4.3 干扰项设计

数据包里大部分内容都是codex默认的提示词，选手需要找到真正的用户输入与工具调用内容。

4.4 前后题关联与引导

本题目较简单，按题目顺序排查即可。

五、Flag 及标准答案

六、官方 WriteUp

6.1 解题工具清单

6.2 解题步骤

步骤一：分析TCP流

1.使用Wireshark打开，右键数据包，选择追踪流-TCP Stream

2.请求体开头的deepseek-flash即为用户请求的模型

3.在第3条tcp流中，模型的思考过程中出现了服务器密码0000

4.在第6条tcp流中，可以看到发送的第一个命令是id

5.统计10个请求结尾的usage字段，输入缓存：184192 输入：12794 输出：5687

6.查询deepseek官网，根据时间戳，按照高峰价计算得到0.07845168

Ransomware

一、题目说明

1.1 场景背景

公司遭到了一款名为 Solar 的勒索软件攻击，所有重要文件都被加密了！但是安全团队找到了加密器的样本。

1.2 任务目标

请分析加密算法，恢复被加密的文件。

1.3 Flag 格式说明

flag{xxxxx}，共1个flag

二、环境信息

2.1 靶场架构

（在此填写，可插入图片）

2.2 部署方式

2.3 环境依赖说明

三、靶场附件清单

4.1 排查路径

4.2 考核点清单

4.3 干扰项设计

无

4.4 前后题关联与引导

无

五、Flag 及标准答案

六、官方 WriteUp

6.1 解题工具清单

6.2 解题步骤

Step 1: 初步分析

查看加密目录，发现所有文件被加上了 .locked 后缀：

flag.txt.locked                          (40 字节)sierting.txt.locked公司logo 透明.png.lockedhint.txt                                 (赎金提示, 明文)

用十六进制编辑器查看 .locked 文件尾部 44 字节：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)

关键发现: 对比所有 .locked 文件的尾部 32 字节 random_key，发现 完全相同！这意味着所有文件使用同一个密钥加密。

Step 2: 逆向加密器（可选，加深理解）

使用 IDA/Ghidra 分析 encryptor.exe，识别到：

• ChaCha20 流密码加密（特征常量 0x61707865 "expand 32-byte k"）
• 密钥结构: key[0:16] 来自哈希派生 + key[16:32] = 固定字符串 "Welcome_to_Solar"
• 所有文件使用同一个 key 和 nonce（nonce 由 SHA-512 派生，不写入文件）→ 产生相同的 keystream

Step 3: 识别漏洞 — Two-Time Pad

ChaCha20 是流密码：ciphertext = plaintext XOR keystream

当 key + nonce 相同时，所有文件使用相同的 keystream。这就是经典的 Two-Time Pad 漏洞：

PNG_ciphertext  = PNG_plaintext  XOR keystreamflag_ciphertext = flag_plaintext XOR keystream

如果我们知道 PNG 的明文，就能恢复 keystream，进而解密 flag。

Step 4: PNG 已知明文攻击

PNG 文件的前 16 字节是固定的标准文件头：

89 50 4E 47 0D 0A 1A 0A   PNG signature00 00 00 0D 49 48 44 52   IHDR chunk (length=13, type="IHDR")

计算 keystream：

keystream = PNG_ciphertext[0:16] XOR PNG_header[0:16]

Step 5: 解密 flag.txt.locked

flag.txt.locked 的内容部分恰好 16 字节（文件总大小 60 = 16 内容 + 44 尾部），直接用恢复的 keystream XOR：

flag_plaintext = flag_ciphertext[0:16] XOR keystream[0:16]

解题脚本

#!/usr/bin/env python3"""Solar Ransomware - Two-Time Pad Solver"""PNG_HEADER = bytes([0x89,0x50,0x4E,0x47,0x0D,0x0A,0x1A,0x0A,                    0x00,0x00,0x00,0x0D,0x49,0x48,0x44,0x52])TAIL_SIZE = 44  # random_key(32) + magic(12)# 1. 从 PNG.locked 恢复 keystreamwith open("公司logo 透明.png.locked", "rb") as f:    png_data = f.read()keystream = bytes(a ^ b for a, b in zip(PNG_HEADER, png_data[:16]))# 2. 用 keystream 解密 flagwith open("flag.txt.locked", "rb") as f:    flag_data = f.read()flag = bytes(a ^ b for a, b in zip(keystream, flag_data[:16]))print(flag.decode())# Output: flag{s0lar_ctf!}

只需 10 行 Python，无任何外部依赖。

运行结果

$ python solve.pyflag{s0lar_ctf!}

Flag

flag{s0lar_ctf!}

hotfix

一、题目说明

1.1 场景背景

某企业的一个服务器遭受到了黑客攻击，运维发现其机器好像被传入了木马，但是这个企业的运维好像不会处理安全事件，你能否帮他完成任务报告并进行服务器的修复加固呢？

1.2 任务目标

本题目共设 6 个任务，参赛者需依次完成排查与加固，并按平台要求提交对应结果。任务清单如下：

任务按「发现—止损—加固」的顺序展开：先排查出 phpmyadmin 弱口令入口与黑客上传的木马，再完成数据库密码的修改与木马清除，最后修复文件上传漏洞本身。

1.3 Flag 格式说明

Flag 统一采用 flag{xxxxxxxx} 的格式提交。本题共设 2 个静态 Flag：

• 任务 2「请提交管理员现在的密码」——提交管理员修改前的原密码

flag{password}

• 任务 5「文件哈希」——提交黑客上传文件的 MD5 哈希，小写 32 位

flag{6ed3a6cb86bd8f6f96bf83f36c50763a}

其余 4 个任务均为「自动校验」类型，参赛者完成对应操作后由平台自动判定，无需提交 Flag。

二、环境信息

2.1 靶场架构

（在此填写，可插入图片）

2.2 部署方式

2.3 环境依赖说明

三、靶场附件清单

四、考点设计

4.1 排查路径

关于取证与清除的先后。步骤 5 的取证建议在步骤 6 的清除之前完成——木马文件一旦删除，其原始哈希将无法再从目标服务器上计算。若参赛者先行删除了文件，需通过题目另行提供的样本途径取得该文件后再计算哈希。

关于步骤 1 与后续步骤的关系。停用 phpMyAdmin 属于暴露面收敛，与「发现木马」并不互斥：前者切断的是管理入口这条路径，木马则是另一条路径的产物，两者都需要处理，且都不应因处理其一而跳过另一项。

4.2 考核点清单

4.3 干扰项设计

漏洞修复过程，可能涉及多个位置的检测，而非单独单一的文件上传位置修复。

4.4 前后题关联与引导

五、Flag 及标准答案

六、官方 WriteUp

6.1 解题工具清单

6.2 解题步骤

步骤一：删除phpmyadmin

删除phpMyadmin目录或禁用该目录访问即可

步骤二：请提交管理员现在的密码

找到MySQL根目录

进入数据库

密码来源于配置文件或phpstudy内显示

解密密码：$2y10

fCOiMky4n5hCJx3cpsG20Od4wHtlkCLKmO6VLobJNRIg9ooHTkgjK

获得：password

步骤三：请修改数据库的密码

在phpstudy中，可以直接修改数据库的密码，只要不和原密码重复即可

但注意的是，只修改数据库密码无法完成后续任务，所以还需要修改配置文件。

C:phpstudy_proWWWconn.php和C:phpstudy_proWWWadminincludesconn.php

步骤四：请删除黑客上传的木马

删除黑客上传的一句话木马，只需要保证其为403/404即可，也可以禁止访问该文件进行解决。

根据访问日志或文件记录，检查删除黑客上传的木马文件即可。 步骤五：请提交黑客上传文件的MD5哈希

在删除前，发现特征文件应取MD5等哈希数据，提交获取的哈希即可。

步骤六：请修复文件上传的漏洞

本题目考察文件上传漏洞，后台中多个文件内包含文件上传漏洞，主要修复为:]

<?php    include 'includes/session.php';if(isset($_POST['add'])){$firstname = $_POST['firstname'];$lastname = $_POST['lastname'];$address = $_POST['address'];$birthdate = $_POST['birthdate'];$contact = $_POST['contact'];$gender = $_POST['gender'];$position = $_POST['position'];$schedule = $_POST['schedule'];$filename = $_FILES['photo']['name'];if(!empty($filename)){            move_uploaded_file($_FILES['photo']['tmp_name'], '../images/'.$filename);           }        //creating employeeid$letters = '';$numbers = '';        foreach (range('A', 'Z') as $char) {$letters .= $char;        }for($i = 0; $i < 10; $i++){$numbers .= $i;        }$employee_id = substr(str_shuffle($letters), 0, 3).substr(str_shuffle($numbers), 0, 9);        //$sql = "INSERT INTO employees (employee_id, firstname, lastname, address, birthdate, contact_info, gender, position_id, schedule_id, photo, created_on) VALUES ('$employee_id', '$firstname', '$lastname', '$address', '$birthdate', '$contact', '$gender', '$position', '$schedule', '$filename', NOW())";if($conn->query($sql)){$_SESSION['success'] = 'Employee added successfully';        }else{$_SESSION['error'] = $conn->error;        }    }else{$_SESSION['error'] = 'Fill up add form first';    }    header('location: employee.php');?>

1.SQL 注入 —— 高危

这里直接把 $_POST 参数拼接进 SQL：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)0

例如：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)1

随后直接进入：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)2

如果攻击者能够控制 firstname、lastname、address、contact 等字段，就可能构造恶意 SQL。

正确做法：使用 MySQLi prepared statement。

例如：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)3

2.文件上传漏洞 —— 高危

这里尤其值得注意：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)4

代码没有检查上传文件的真实类型，也没有限制扩展名。

也就是说，程序把用户提供的：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)5

直接作为服务器上的文件名。

如果服务器的 ../images/ 目录能够执行 PHP，那么这类上传功能可能进一步导致远程代码执行。

至少应该：

• 限制允许的扩展名
• 检查 MIME 类型
• 检查文件内容
• 重新生成随机文件名
• 不使用用户提供的原始文件名
• 上传目录禁止执行 PHP 等脚本

例如：

[32 字节 random_key] [53 61 72 5f 54 65 73 74 5f 45 6e 63]                                  "Sar_Test_Enc" (12B magic)6

不过，仅检查扩展名仍然不够，生产环境还应该结合 MIME 和图片内容检测。

澜生生物钓鱼事件-第二期《猎杀》

一、题目说明

1.1 场景背景

六周前，你作为澜生生物 SOC 的当值分析师，处理了一起针对研发部的钓鱼邮件事件。你沿着跳转链一路追到了攻击者的 C2 控制台，在系统被清场前抢回了一段加密信标。当时的结案报告写着“表面遏制”——邮件清了、域名封了，但有一条遗留事项你一直没忘：书禾账户上的恶意 OAuth 应用授权，因为租户审批流卡壳，至今没有撤销。

现在，SIEM 在凌晨触发了 P1 级告警：那个组织——你给它起了个代号，叫 NIGHTBLOOM——又动了。SIEM 关联引擎确认，六周前你破解的那段密文就是本次事件的案件密钥，而攻击者正在通过母集群基础设施，活跃窃取澜生三期临床新药 LS-818 的核心申报资料。数据外传窗口已经打开。

董事会企业安全部直接压了单子过来：立即开案，在数据外传完成前阻断。

你是威胁狩猎分析师 CherryWhite（小张）。这次的根子在你上次没拔干净——去拔干净它。

1.2 任务目标

向参赛者发布的任务清单如下，全部答案使用 flag{} 包裹提交：

本期全部证据均在靶机内，无需回访第一期环境。

1.3 Flag 格式说明

flag{xxxxxxxx}，共 13 个 Flag（12 个任务 Flag + 1 个体验结局 Flag）。全部为静态提交，不使用 check 脚本。

二、环境信息

2.1 靶场架构

单台 Windows 靶机，QEMU/KVM 虚拟机，选手通过平台 RDP 直连（3389）接入。靶机内置全部服务与证物，开机即用。

所有“外部平台”均为本地模拟：RDAP / crt.sh / Wayback / urlscan 四个页面由 nginx + php-cgi 在 127.0.0.1:3000 端口提供服务，数据经 AES-256-CBC 加密落盘，由 PHP 后端按查询解密返回。无外网依赖。

靶机内组件：SOC 工作台（开案／解码／倒计时）、四大情报平台、跨事件归因台、联动处置台（OAuth 授权撤销 + 边界联动封堵）、知识库（一期结案报告 + 资产人员档案）、澜信企业 IM（四会话）。

2.2 部署方式

2.3 环境依赖说明

三、靶场附件清单

必传。附件不全将直接影响审核“完整性”得分。本题附件如下：

无外部附件文件。所有解题证据均在靶机内，随镜像一并交付。

四、考点设计

4.1 排查路径

4.2 考核点清单

隐式顺序联动（服务端强制）：封堵候选池由各平台“已核实”记录动态派生（服务端 C:phase2logsintel-state.json）：未查 RDAP 无根域候选、未查 crt.sh 无母集群候选、未查 urlscan 无 IP/C2 候选、未开归因台无诱饵候选。开案即重置核实池。不完成前序调查，边界台无对象可下发——以此在不显式锁题的前提下强制排查顺序。

4.3 干扰项设计

干扰程度把握：干扰项均为“可识别但需判断”级别，不阻塞主线证据获取——误选干扰项仅导致封堵台校验拒绝，可重试（失败频控 5 次/60 秒防组合枚举，仅返回通用错误），不存在一次性惩罚，避免为难而难。

4.4 前后题关联与引导

• 承接第一期《入局》：开案密钥 YF818-PNFR-8s3n 即一期从 C2 抢回并取证固定的加密信标（复考一期解码技能）；一期结案报告“OAuth 授权未撤销”遗留事项是本题撤销授权任务的因果钥匙；一期 IOC（logivex.group / globaltradebd.com）以封堵候选诱饵形式回归。
• 自包含原则：二期证据全部在靶机内（移交简报密文、四大情报平台、归因台、urlscan Linked URLs），未参加一期的选手可完整解题，一期仅作剧情前情与技能铺垫。
• 内部引导：封堵台候选池按前序调查进度动态点亮，隐式引导排查顺序；澜信 IM 研判组会话提供方法论软提示；「处置手册」浮层按 intel-state 实时点亮 9 步 SOP 进度（服务端派生，只引导流程不泄答案）。
• 题目间关系：本期为钓鱼系列第二期（威胁情报篇），与第一期《入局》（邮件分析篇）构成“入口链分析 → 基础设施猎杀与协同遏制”的递进；一期只考入口链/C2，RDAP、CT、Wayback、urlscan、深度归因与处置为本期独有考点。

五、Flag 及标准答案

六、官方 WriteUp

6.1 解题工具清单

除没做过第一期的选手需要在外部完成开案密钥解码外，全部步骤均使用靶机环境提供的工具即可完成。SOC 解码工具为靶机内置离线网页工具，不开外网；不开工作台的情况下，全程亦可用系统自带 PowerShell 5.1 替代完成。

6.2 解题步骤

这道题的场景改编自我们处理过的两起真实钓鱼应急——发票类 LogoKit 凭据钓鱼，和伪装 Adobe Acrobat Sign 的 OAuth 同意钓鱼。二期取的是后者的协议层（恶意 Azure AD 应用、redirect_uri）加前者的归因线（base64 邮箱指纹），全部证物做了虚构化处理（澜生生物、nightbloom.top、crimsonmesh.top）。整条解题链就是把一次真实溯源的推进顺序倒过来铺：开案，然后沿 RDAP→CT→urlscan→Wayback 把一个域名背后的集群挖出来，最后落在撤销授权、边界封堵两步处置上。

步骤 0：RDP 登录 → 工单弹窗 → 全屏告警

首先下发环境后，会自动用 SandBox账户RDP 登录靶机（跟一期同一个账号）。桌面还没完全加载完，工单弹窗会先跳出来——董事会企业安全部的紧急工单，P1。这里留了个小互动：弹窗上「立即接收工单」和「转派其他分析师」两个按钮都能点，选转派会被系统驳回（本案只有你一个责任人），殊途同归进告警页。

点完之后 explorer 会被杀掉，Edge 以 kiosk 全屏接管桌面，这就是告警详情单。先提醒一句：右上角的处置时限从告警推送这一刻就在倒数了，不是等开案才起算——真实应急里 SLA 就是从告警开始算的，别在剧情文本里泡太久。

告警单上的信息很全：威胁等级 P1，ATT&CK 标了 T1566.002（钓鱼链接）和 T1528（OAuth 令牌窃取），受影响资产、处置要求都在，最底下是案件移交简报（物证 EVT-2026-07-18-EXH-01）。简报里那串密文就是本案的起点——也就是一期结尾你从 C2 控制台抢回来的那段加密信标。

步骤 1：解码信标 → 开案（任务 1）

密文长这样：NTk0NjM4MzEzODJkNTA0ZTQ2NTIyZDM4NzMzMzZl。字符集一看就是 base64，先在工作台「工具→编码转换」里 Base64 Decode 一下，出来的是 59463831382d504e46522d3873336e——一串纯 hex。别急着提交，这还不是答案，点「输出回填输入」换 Hex Decode 再来一层，明文就出来了：YF818-PNFR-8s3n。

不想开工作台的话，PowerShell 一行也能解到中间值：

# → "59463831382d504e46522d3873336e"

# 再将 hex 按两位拆开转 ASCII → "YF818-PNFR-8s3n"

这个双层编码是刻意保留的——一期的信标就是这么嵌在 C2 页面里的，开案这一步本身就是对一期技能的复考。把密钥填进开案门，案件号 LS818-CASE-2026 落地，倒计时继续走（50 分钟，带 0~2 分钟随机延长）。眼熟的选手这时候应该已经注意到 818 这个数字了，后面我们还会用得到。

步骤 2：RDAP 查注册信息（任务 2a/2b）

开了案通过「澜信」（我们为澜生生物这个虚构的公司虚构的IM）了解到案件相关信息后，可以先去「威胁情报→注册信息（RDAP）」查 nightbloom.top。这步没什么花活，考的就是知不知道 RDAP 这东西——whois 的替代协议，返回结构化 JSON，比裸 whois 的文本墙好读得多。卡片上两行就是答案：Registered: 2026-07-14（任务 2a），Registrar: NameSilo, LLC · IANA ID 1479（任务 2b）。

顺手把整张卡看完，剩下的字段都是氛围：注册到案发不到俩月，状态挂着 add period，NS 托在 Cloudflare（CLOE / MICAH.NS.CLOUDFLARE.COM），DNSSEC signed，到期时间 2027-07-14。抠细节的选手可以展开底部的 Raw RDAP JSON 自己核对原始数据。

步骤 3：CT 日志揪母集群（任务 3/4）

拿到域名先查证书透明度：「证书透明度」页查 nightbloom.top。结果只有一张证书（Let's Encrypt 签的），但 matching_idents 一列里有两条身份：nightbloom.top 和 nightbloom.top.crimsonmesh.top。

第二条一看就不正常——没人会给自己的子域签「主域.母域」这种倒挂名字。这正是 CT 日志在真实溯源里最好用的地方：攻击者给子域签证书时，经常无意间把关联域的命名空间一起晒进公开日志。顺着 crimsonmesh.top 就摸到了母集群（任务 3）。

集群规模在 crt.sh 的 summary 或 urlscan 的 Unique IPs 聚合里都能看到：174 个活跃子域（任务 4）。这个数量级摆在面前，就不是一次性钓鱼了，是集群化运营。

步骤 4：urlscan 挖历史落点与 OAuth 链路（任务 5 + 10a 证据）

「URL 扫描档案」查 domain:crimsonmesh.top，回来 8 条历史扫描。8 条的 page.ip 全是同一个 203.0.113.76（任务 5），托管在南非 1-Grid（AS36943）。历史解析高度一致本身就是强信号——母集群的钓鱼页就住在这台机器上，没有做 CDN 藏匿。

主菜在列表最后一条（2026-07-16，adobe-sign.crimsonmesh.top/sign.html）：手动展开它的 Linked URLs，里面挂着钓鱼页的完整 OAuth 授权链路：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize

?state=c2h1aGVAbGFuc2hlbmJpby5jb20=

&client_id=7a3e9c2b-8f14-4d62-9e2a-c4b71f083a5e

&redirect_uri=https%3A%2F%2Fc2.nightbloom.top%2Fcgi_bin%2F

&uri=https%3A%2F%2Fsiemens.com

这条 URL 值得分层读：state 里的 base64 解开是 [email protected]，一期那位当事人的邮箱，老朋友了；redirect_uri 指回 c2.nightbloom.top，是授权码的落点；至于 uri=siemens.com，凑数的干扰参数，真实攻击里它就是拿来糊弄检测的。要交的答案是 client_id=7a3e9c2b-8f14-4d62-9e2a-c4b71f083a5e（任务 10a），完整 32 位记好别截断，后面撤销授权要一字不差地输。

这一层我们做得比较深：client_id 不出现在任何页面上，结果列表里只给一个 Linked URLs 的展开入口。OAuth 钓鱼溯源的关键本来就在这种「页面不显示、请求参数里才有」的地方，希望这一步能逼着选手养成看链接关系的习惯。

步骤 5：Wayback 追历史足迹（任务 6/7）

「历史档案」查 nightbloom.top。timemap 显示 Saved 17 times between 2024-05-09 and 2026-09-08（任务 6），按年份分的日历热图上最早快照有高亮。

眼尖的话这里会发现问题：RDAP 明明说这域名 2026 年 7 月才注册，快照怎么比注册时间还老？这不是数据打架，是原样保留的真实对抗细节——这类组织惯于让域名过期掉注册再重新注册，RDAP 只记得「最近一次」，Wayback 记得「曾经」。单看任何一个源都会把它当成新域名误判，交叉看才知道是张熟面孔。这正是我们把四个平台串成一条链的原因。

点开 2024 年的第一个快照（0509），Wayback 原版工具栏加载出来（web.archive.org/web/20240509131200/https://nightbloom.top/），内嵌页面是一面 Apache 默认 403——Server: Apache/2.4.41 (Ubuntu)（任务 7）。一面两年前就对外挂 403 的裸服务器，恰好就是本案 redirect_uri 里那个 /cgi_bin/（注意是下划线，不是 Apache 标准的 /cgi-bin/）伪装成「良性报错页」的出处——历史足迹和作案手法在这里对上了，归因很硬的一块拼图。

步骤 6：跨事件归因（任务 8/9）

证据攒得差不多了，进「跨事件关联归因」。引擎把三起事件摆到一起：一期韵捷发票 LogoKit 钓鱼链（EVT-2025-10）、本案 Adobe Sign OAuth 钓鱼（EVT-2026-07）、crimsonmesh.top 母集群长期运营（EVT-2024-NOW）。TTP 矩阵里最扎眼的共享项就是答案：base64 邮箱 c2h1aGVAbGFuc2hlbmJpby5jb20=（解开就是 [email protected]，任务 8）。

为什么拿它当指纹？一个地方出现算巧合，三起互相独立的事件都复现同一个 OPSEC 小习惯，那就是「改不掉的手法」了。矩阵按 MITRE ATT&CK Enterprise v15 标了技术编号（T1583.001 / T1584.006 / T1566.002 / T1528 等），写研判报告时可以直接引用。

归因结论顺势把组织画像立起来了：TA-NIGHTBLOOM / crimsonmesh.top，长期医药间谍。至于他们到底想要什么，归因台只给了一半，剩下的一半在结案报告里。

步骤 7：联动处置 · OAuth 授权撤销（任务 10a）

进「联动处置→OAuth 授权撤销」。应用卡上只有表象：Adobe Acrobat Sign 伪装、第三方租户应用——没有 client_id。这里要交的就是步骤 4 从 Linked URLs 里挖出来的那串：7a3e9c2b-8f14-4d62-9e2a-c4b71f083a5e，后端精确比对，多一位少一位都不行。

多说一句为什么这个处置是必须的：OAuth 同意钓鱼拿的是令牌不是密码——受害者改密码没用，MFA 也拦不住已经同意过的应用，只有把应用授权撤掉才真断了。这也正是剧情里之前提到的：六周前因为租户审批流卡壳没撤掉的授权，今天来还账。

校验通过，签发撤销令牌。

步骤 8：联动处置 · 边界联动封堵（任务 10b）

进「联动处置→边界联动封堵」。候选池这时候应该已经亮出 6 项——这个池子不是预先摆好的，是前面每查完一个平台点亮一块：RDAP 给根域、crt.sh 给母集群、urlscan 给 IP 和 C2、归因台给一期关联域。前序调查没做完这里就是空的，顺序由服务端强制，前端做不了弊。

至少要下发三项：nightbloom.top（根域）、*.crimsonmesh.top（母集群）、203.0.113.76（历史 IP）。两个坑提前说：c2.nightbloom.top 别勾，根域封了它自然就死，单独勾它属于误封；一期的 logivex.group / globaltradebd.com 也别顺手全选，它们是一期的事，不是本案必封项。校验是精确匹配，缺封误封都只回一句通用错误、不告诉差在哪，失败还有频控（5 次/60 秒）——别蛮力试组合，真实世界下发封堵本来就该过脑子，这里只是把「过脑子」做成了机制。

通过，签发封堵令牌。

步骤 9：结案研判报告（收尾）

双令牌齐，结案研判报告自动归档。归因台按着没说的答案在这里：攻击者真正要的是 LS-818——澜生三期临床新药的分子配方和临床试验数据（任务 9）。步骤 1 里那个 818在这里就找到了。母集群 174 个子域盯的也不止澜生一家，多家创新药企都在名单上，澜生只是当前阶段目标；一期的韵捷发票和这次的 OAuth 钓鱼，都是围着这个目标转的链条。

研判结论：CONTAINED，遏制成功，事件关闭。结论代码就是收尾 Flag——开案时开始倒数的那 50 分钟，压的就是这一下。

BREACH 线（超时体验）

如果时限烧完还没闭环，工作台会锁屏：矩阵雨加文件外传动画，锁屏直接给 BREACH 线的 Flag（服务端下发）。说明一下：两种结局都是有效体验——10a/10b 的分数看的是你分析出的 client_id 和 IOC，不看手速；没打完的选手也会拿到自己那条线的收尾。最终研判页在未处置时只提示「报告尚未生成」，不出具任何结论。

请选择您心中最具实战价值且最具创新突破的题目（可多选）