免责声明：本文为个人技术学习与工程实践笔记，所涉操作仅应在获得授权的环境中进行。因不当使用造成的后果由使用者自行承担。
本次比赛我的发挥并不理想，原本有机会取得更好的名次。赛前没有仔细研读比赛文档，误以为靶机只有一台，于是在那一台靶机上反复搜寻线索：先测试注入点，再尝试经数据库写入脚本文件，取得执行权限后植入命令执行组件并建立 C2 会话，随后便认定全部 Flag 都在该主机上，继续在其内部排查许久，赛后才知道现场共有数台靶机。这也充分说明一名细心的队友何等关键：或许令人难以置信，我们队伍仅为写入一个 Web 脚本便反复尝试许久，最终在我本地硬盘里翻出一条年代久远的脚本才写入成功
比赛结束后，学长告知入口靶机共有两台。我随即打开官方说明文件核对，果然如此，一时颇为无奈。这确是我的疏忽，终归是没有提前梳理整条网段的资产，不够细心
最后的分析溯源环节表现尚可，共计解出两道题。
团队赛最终沦为个人赛，队伍之间的配合仍有提升空间。希望明年能有更好的团队协作。
防御启示
- 资产台账先于一切操作：本次误判靶机数量，直接原因是未通读赛前的资产说明。真实环境中同样如此，未纳入资产台账的主机不会被巡检覆盖，也不会产生告警，应通过主动探测结果与 CMDB 双向核对，保证台账与现网一致。
- 授权边界必须书面化：竞赛与实战演练都应事先明确授权范围（域名、网段、时间窗）与责任人，范围之外的目标即便技术上可达也不得操作。
- 凭据与脚本需要受控管理：依赖本地遗留脚本才完成写入，说明工具与凭据缺乏版本管理。应建立受控的脚本仓库，凭据由统一的密钥管理下放并定期轮换，避免历史凭据长期有效。
- 单点投入要设定停止条件：在一个目标上长时间无效尝试，本质是缺少时间盒。排障同样应设置检查点，到期即切换方向或升级求助，而不是持续消耗时间预算。
- 交接必须留有记录：配合不足往往源于信息未同步。值班与接续作业应以书面交接（时间、操作、结果）替代口头传达，事后复盘才有可核查的依据。
