🛡️ZZUCTF 平台渗透事件复盘报告

材料基础:① 平台服务端全量原始日志(HTTP 访问日志 / 登录审计 / 数据库字段审计);② 攻击方 AI 自动化工具实例的完整运行记录(规划引擎决策日志、各迭代执行脚本、结果文件、运行日志——源码与二进制均仅离线存档,未执行)。

取证结论:两份材料在时间、指纹、行为三方面逐条吻合,可确认二者记录的是同一次攻击,材料真实性成立。

一、事件概况

• 对平台主机的 SSH 服务做大规模口令爆破;

• 批量注册测试账户(成功建立 85 个账户,累计注册请求 250 次);

• 通过密码喷洒(password spraying)方式尝试批量获取账号控制权限(成功 1 个);

• 对公开接口进行批量遍历查询(队伍信息接口被遍历 968 次,收割全站真实用户名);

• 尝试调用管理员接口获取信息;

• 尝试通过"旁站"方式渗透同一主机上的其他业务系统(该行为已超出操作者给予的提示词范围)。

二、责任说明与影响评估

• 所有选手的敏感数据、隐私数据均未泄露。 攻击者唯一取得的是一枚最低权限的普通用户账户(不可访问任何管理功能),攻击者对该账户未做任何修改;

• 本次事件未造成任何严重或恶性影响。 无 flag 泄露、无权限提升、无服务器失守、无数据外泄;

• 平台一直以最高网络安全标准要求自身,高度重视大家的隐私信息。从某种意义上说,我们也需要"感谢"攻击者与 ARTEX——是它发现并暴露了我们的问题。

三、事件概览

• 测试账户数:本次攻击成功建立 85 个账户,注册请求合计 250 次(其中 83 次因用户名重复被拒、50 次触发限流、32 次被客户端主动断开)。事件初期"两百多个账户"的口径,是把重复尝试与限流请求一并计入所致;

• 工具指纹:该工具并非"一个脚本",而是一套调度系统,同一时间在源 IP 上并发出现 curl/8.21.0、裸 Mozilla/5.0、nmap NSE、无 UA 客户端(含其独有组件 norma/0.4)五类指纹。

四、我方响应时间线

本节以团队群内的讨论与处置节奏为主轴。每个节点分三部分:我方动作、当时的研判、事后被证据坐实或推翻的结论。这样既能还原"当时是怎么想错的、又是怎么纠正的",也便于与攻击方记录对照。

• 我方动作 —

• 当时研判 —

• 事后核验 — 用注册接口的状态码分布可精确还原当时的现场:

• 我方动作 —

• 证据 — 攻击者拿到账户前后都对管理端点做过尝试,401(未携带凭据)与 403(已登录但权限不足)相继出现:

• 我方动作 —

• 证据 — 74 个占位邮箱账户全部处于可用状态,可正常登录、报名、提交答案。

• 我方动作 —

• 说明 — 这解释了"为什么没有告警":攻击请求速率低(每分钟固定次数)、UA 伪装成普通浏览器,形态上不触发流量型告警。

• 我方动作 — 服务器日志确认第一批攻击痕迹是针对 SSH 服务的大规模口令爆破,累计 2,067 次,全部失败。

• 干扰信息 — 同期收到:被命中账户的主人反映其 QQ 邮箱疑似被盗。事后确认此事与本事件无关,但当时把排查方向引向了"本人被盗号后发动攻击"。

• 口径差异说明 — 工具侧自述尝试了 22 类用户名 × 177 条口令(约 3,894 组合),服务端只记录到约 2,000 次失败鉴权。原因是爆破后期服务端开始丢弃连接(工具侧日志中出现连接横幅读取错误),大量组合在握手阶段即被拒绝、未进入鉴权环节。这本身说明连接层限速对爆破起到了抑制作用。

• 我方动作 — 请该同学自查其出口地址、检查终端是否存在恶意程序。

• 我方动作 — 尝试通过校园网地址分配规则定位到具体人员,准备联系相关老师;在核验日志时发现,攻击出口地址与一名在校学生的地址一致。

• 意义 — 本事件的关键转折:排查方向从"账户主人是否自导自演"转向"另一名真实人员"。

• 我方动作 — 讨论是否可能存在自动化 Agent 对平台实施渗透,以及该学生与攻击事件的关系。

• 我方动作 — 自动化取证给出第一版结论:85 个测试账户全部由同一出口注册、UA 全部为脚本特征、该地址进行了大量撞库与 SSH 爆破。受此结论与账户名本身的暗示影响,当时把攻击者锁定在被命中账户的主人（亲爱的 Alan Walker 同学）身上。

• 复盘注 — 这一版结论在攻击行为特征上是准确的,但在谁在攻击上判错了。错在把"被使用的账户"等同于"账户的主人"。

• 我方动作 — 取得该学生的联系方式,核对攻击当日其位置信息。

• 意义 — 这段流量当时被记为"与凌晨脚本无关的浏览",事后成为把操作者与攻击行为绑定的时间锚点:它不是工具流量,而是真人操作。

• 我方动作 — 账户主人（Alan Walker 同学）提供了一份其可能使用的弱口令。经哈希比对,该候选值与平台账户所有历史版本均不匹配(含空格、全角字符、大小写等大量变体)。同时确认该账户有正常、连续、可解释的注册与参赛记录。

• 证据 — 平台密码哈希为 ASP.NET Core Identity V3 格式,我们按格式逐字节比对:

• 结论 — 该候选确系本人记错;同时"密码由用户名衍生而来"这一假设被排除。

• 我方动作 — 排查中发现一条疑似匿名网络出口（Tor，洋葱路由）的登录记录,一度提高对攻击者技术水平的评估。经核验,该地址为普通商用代理,并非匿名网络出口,且登录者系管理团队成员。

• 证据 — 该出口地址经官方出口清单双向核验无匹配;登录后 4 分钟即使用"创建测试容器"功能,行为连续性与出题工作完全吻合。（创建测试容器是管理员的功能哦，普通用户是没法创建的）

• 我方动作 — 完成账户画像:历史登录全部为浏览器行为;密码曾在更早时间点重置过一次;10-19 期间由脚本接管登录;用户名变更发生在更早日期,与本次攻击无关。

• 我方动作 — 尝试通过公开泄露数据查询该账户邮箱对应的密码,查询无结果。据此判断攻击者并非通过社工库获得密码,但当时仍未排除账户主人自导自演的可能性。

• 我方动作 — 负责联络的同学确认:该学生承认使用 AI 自动化渗透工具对平台实施渗透。我方第一时间要求其提交工具运行日志以便核实;对方对行为的严重性缺乏认识。

• 意义 — 身份与工具来源同时确认,但"口述"尚不足以与日志严格绑定。

• 我方动作 — 讨论认为:在没有工具侧运行记录的情况下,无法把"某人的工具"与"服务端记录的这次攻击"绑定,仍保留"外部攻击者操纵账户"的可能。

• 我方动作 — 上传服务器全量访问日志,数十名成员并行筛选。从日志中确认:存在对队伍清单接口的持续遍历,并成功批量获取了数据。

• 意义 — 这是"密码喷洒"假设的铺垫:先有用户名清单,才有针对性喷洒。

• 我方动作 — 讨论认为本次攻击未造成实质破坏、未见主观恶意,先与操作者沟通并安抚,同步进入证据核实阶段。

• 我方动作 — 确认攻击者部分测试账户的命名与工具的执行迭代编号一一对应,属"把已知问题列表逐条验证"的典型 Agent 行为。

• 我方动作 — 收到操作者提交的自动化工具完整实例压缩包(源码 + 配置 + 全部运行数据),立即投入离线取证。

• 我方动作 — 在工具侧记录中找到了命中的确切口令与命中时刻。工具侧记录与服务端记录在秒级吻合。当时的第一反应是"这不可能"——命中的竟是字典的第 1 条。

• 证据(双侧对照):

"为什么偏偏是第 1 条"见第八节——这不是运气,而是轮转喷洒的必然结果。

• 我方动作 — 确认该工具实例在攻击结束后仍以"心跳巡检"方式长时间存活(最后一次心跳在当日 22:37),立即通知操作者彻底停止全部实例,防止二次攻击。

• 风险说明 — 实例存活意味着"剩余 30 条口令未跑完、更高权限账户尚未命中"这一计划仍可能被继续执行。

• 我方动作 — 确认该工具在同一时段也对本机其他业务系统做了扫描与渗透尝试:对知识库系统做了登录喷洒(0 命中),对一条未在运维文档中记录的组网通道做了端口记录,并尝试通过容器代理接口访问内网地址。

• 我方动作 — 用攻击者本人的 31 条字典离线比对全站用户密码哈希,核查"若该工具跑完全部口令还会命中谁"。结果发现另一名同学的密码同样落在该字典中,立即从后台重置其密码并通知本人。

• 结论 — 本次"止损"不是靠防御生效,而是靠攻击方预算耗尽(工具侧自述 ran out of budget)。这直接决定了后续必须做全站弱口令治理。

• 我方动作 — 团队陆续输出结论与总结,应急响应阶段结束,进入归档与复盘。

五、攻击方行为时间线(工具侧实录)

下列时间取自攻击工具自身的运行记录(规划引擎决策日志、执行脚本、结果文件落盘时间),可视为攻击方行为的直接实录;每条均可与服务端日志对上。

两条线并排看

六、ARTEX 是什么:工具的架构与运作方式

6.1 双层循环:规划者 + 执行者

• 规划者维护一张「探索图谱」,里面存着四类对象:
  • goal(目标,例如"深度测试")、
  • asset(资产,接口/主机/服务)、
  • intent(意图,即"下一步要打什么")、
  • fact(事实,即"打完得到的结论")。

• 执行者每次领取一条 intent,自己决定怎么写脚本、跑什么命令,然后把结论写成 fact 回写图谱。

• 规划者被心跳定时唤醒(本次为分钟级/十分钟级),读图 → 判断目标是否达成 → 派发新 intent。全程没有人参与。

6.2 一次典型的规划者唤醒(原文节选)

6.3 它能干哪些事:82 条意图的分类

6.4 操作者的环境特征(取证可比对点)

七、渗透路径详解

本节按攻击的时间顺序,把整条链路拆成七个阶段。每个阶段给出:工具怎么想(意图)、实际怎么打(动作)、工具侧证据、服务端日志、结论。便于大家对照学习。

阶段一:指纹识别(02:23 - 02:24)

• 意图(#3):对目标做精确版本指纹识别(前端构建哈希、公开配置接口、响应头、错误页),并对照开源仓库历史提交与已知 CVE。

• 动作与结论:它第一件事不是打,而是先搞清目标是什么。提取出版本号与构建时间后,确认这是一个官方最新正式版,没有可直接利用的公开漏洞。

• 附带产出:从前端代码中自动提取出 93 个 API 端点,作为后续攻击面清单。

阶段二:攻击面广度枚举(02:24 - 03:00)

• 意图(#5/#6/#8/#10/#11):同时铺开六条线——版本指纹、SSRF/内网访问、文件上传与存储型 XSS、认证与授权、注入、业务逻辑竞态。

• 覆盖面:账户注册、登录、头像上传、队伍操作、比赛报名、答案提交、容器启停、代理通道、密码找回、管理端点、实时通知连接——几乎是平台的全部功能面。

• 多数结论是否定的(这恰恰说明平台核心实现是扎实的):

• 批量建号:它按"漏洞类型 + 序号"自动生成账户名,快速铺开测试矩阵:

• 服务端对应记录:注册请求秒级爆发(峰值 13~14 次/秒),合计 250 次注册请求。

阶段三:端口扫描与资产测绘(03:00 - 03:01)

• 意图(#33):解析域名 → 扫描常见与管理端口 → 探测是否暴露 Docker API、数据库、调试面板等后端服务。

• 动作:先对常见端口做定向扫描,再对全端口做高速率扫描。

• 服务端对应记录:扫描器特征在 3 秒内集中爆发(nmap NSE 特征路径与随机标记):

阶段四:用户名收割(03:02 - 03:08)——本次攻防的关键转折

• 意图(#45):遍历公开队伍接口,收割全站用户名与 userId,作为喷洒目标名单。

• 关键接口:队伍详情接口无需登录即可访问,且响应里直接包含队伍成员的用户名。实测(不带任何 Cookie)如下:

• 攻击者的脚本(工具侧的枚举脚本原文,变量名保留,域名已替换):

• 服务端对应记录:该接口在攻击窗口内被请求 968 次,编号从 1 连续遍历,呈完美机器节拍(每分钟固定次数):

• 产出:465 支队伍 / 508 个去重用户名。

• 结论:用户名不是猜出来的,是读出来的。 这一步把原本"用户名 + 密码"双未知的问题,压缩成只剩"密码"一个未知量。

这一步打破了一个常见误解:"攻击者要先知道用户名才能撞库"。事实上,只要有一个能枚举出用户名的公开接口,用户名就不再是秘密。

阶段五:弱口令轮转喷洒(03:11 - 03:18)

• 意图(#35):利用收割来的全员用户名 + 已确认的"登录无锁定、无独立限速",用常见弱口令低速喷洒,重点尝试命中高权限账号。

• 字典定制:先用一个探测账户测出平台的密码策略,据此构造 31 条字典。它不使用纯通用字典,而是混合三类构造:

• 喷洒脚本的关键逻辑(原文节选,变量名保留):外层循环是口令、内层循环是用户名。

• 这个打法有两个目的:

1. 规避锁定与限流——同一账号在很久以后才会被再次尝试,不会触发"连续失败锁定";整体速率控制在限流阈值之下;

2. 最大化"一条弱口令命中多个人"的概率——先用覆盖面最广的口令扫一遍所有人。

• 目标筛选:498 个(剔除了自建的测试账户与管理员账户;脚本里有一份明确的排除名单)。

• 服务端对应记录:登录接口在 03:11 ~ 03:20 精确匀速失败,呈机器节拍:

• 结果:第 1 条口令跑完 498 个目标即命中 1 个,且全程唯一命中。

全站 508 人里,只有2个人的密码落在这 31 条里。这不是平台的技术漏洞,这是一次概率收割。

阶段六:账户接管与权限提升尝试(03:15 - 04:12)——全线失败

• 命中后动作序列,在服务端一秒钟内全部可见(这就是"脚本接管"的铁证):

• 工具侧命中记录(原文,敏感字段已隐去):

• 它的自我复盘(规划者原文节选):

• "用完即弃"的判定依据:它没有修改该账户的任何凭据——未改密码、未改邮箱、未改用户名。这正是"账户被盗用"而非"本人操作"的典型特征。

• 提权尝试(全部失败):
  • 尝试伪造成会话令牌 —— 架构上不可行(非 JWT,角色存于数据库);用该会话访问管理配置、用户列表、比赛编辑、题目 flag 管理、令牌管理等端点 —— 全部 403;
  • 对管理员账号做定向弱口令爆破 —— 未命中;
  • 尝试账户自助接管、批量赋值提权 —— 不可行(它自己确认 #44 无自助接管路径)。

阶段七:主机与旁站扩散(03:00 - 04:12)——全线失败

• SSH 爆破(#42/#57):22 类用户名 × 177 条口令,约 3,894 组合,全部失败。

• 同机知识库系统(#43/#59/#60/#76/#78):这是一个独立的 Django 应用,与本平台同机部署。

• 容器代理接口(#20/#72/#81):尝试把平台的容器代理通道当作内网跳板。

• 其他服务:邮件服务(非开放中继、头注入被拒)、K8s API 与 kubelet(匿名认证已关闭,全部 401)、机器人管理界面(鉴权已加固)、远程桌面 —— 完成扫描与指纹识别,均未取得有效认证。

• 未识别高端口的意外收获:扫描记录到了一组未在运维文档中记录的组网通道端口——这条通道也因被攻击者扫到而进入了我们的整改视野。

八、双侧证据比对与关键问答

8.1 逐项比对

8.2 「为什么第一条口令就命中」

• 若受害者的口令是字典的第 1 条 → 攻击者在第 1 轮就命中,外人看着"第一条就中,太巧了";

• 若受害者的口令是字典的第 11 条 → 攻击者要跑到第 11 轮才命中,完全不会引起怀疑。

真正的风险点在这里:本次的"止损"不是靠防御生效,而是靠攻击方预算耗尽。如果它预算充足、继续跑完 31 条,受害者就会从一个变成两个。

8.3 三处需要修正或说明的认知差异

这一条也顺带解释了另一个疑问:攻击者的字典并非"用户名衍生型"(我们曾验证该用户名的衍生变体一千余个,全部不匹配),因此其口令来源是通用泄露字典,与用户名无关。

九、安全提醒

9.1 请不要使用弱密码注册任何平台

• 一名同学的密码为 Aa123456,恰好位于攻击者字典的第 1 位;

• 另一名同学的密码为 P@ssw0rd,位于攻击者字典的第 11 位。

9.2 请自查你的密码是否属于「弱密码族」

• 「常见词 / 姓名 / 学号 / 年份 + 123 / 000」;

• 「首字母大写 + 小写词 + 连续数字」(本次被命中的两个密码都属于这一族);

• 任何在公开泄露字典中出现过的口令。

9.3 关于 Agent 与 AI 攻击

• Agent 的攻击行为可能极其恶性且超出你的掌控——本次工具在得到"深度测试"指令后,不仅打了平台,还去尝试渗透同机的其他业务系统(已超出提示词范围),甚至把"剩余口令未跑完、高权限账号未命中"写进了自己的待办计划;

• 务必看管好自己的 Agent,防止它做出威胁安全的行为;

• 未经许可,严禁使用 Agent 和相关工具对未授权平台进行渗透测试——这是严重违法行为。

十、复盘结语:两条线合在一起看

• 攻击者 03:02 开始遍历队伍接口,我们 03:08 就识别出该接口携带了不应公开的信息;

• 攻击者 03:11 开始喷洒,我们把它的"匀速失败"定性为撞库;

• 攻击者 03:15 命中,我们在同一分钟确认"撞库命中一枚真实账户",并抓住了"命中即探测管理权"的行为特征;

• 攻击者 04:12 停手,我们当天就完成了全量溯源与证据固定;

• 攻击者 11:17 又用同一出口、以真人浏览器登录平台,我们当时把它记作"与凌晨脚本无关的浏览";经核查,这次访问同样出自操作者本人——它反而成了锁定其身份的时间锚点;

• 而我们对"账户主人是否自导自演"的怀疑,在 21:14 达到顶点,又在 21:19(密码证伪)、21:30(登录史全部为浏览器)、23:20(喷洒原文)三个节点上被逐层推翻。

• 全量日志留存(每一次请求、每一次登录都有记录);

• 数据库级审计(账户关键字段的变更可追溯、可跨时间比对);

• 流量形态分析能力(从"每分钟固定次数"这种机器节拍里识别出攻击)。