文章总结： 文章通过红蓝对抗演练真实案例，揭示了信任工具默认行为带来的风险：Kerberos票据因时差失败、SSRF因PHP换行符标准化绕了五次、沙箱环境与真实链路差异导致误判、SIEM聚合规则掩盖了第六次成功攻击、NDR因交换机生成树重算丢包四成。核心教训是不要盲目信任工具默认设置，需主动验证时间、重放环境和基线变化。 综合评分： 90 文章分类： 实战经验,红队,内网渗透,安全运营,渗透测试

网安回忆录 – 金融系统攻防演练，三次差一点拿下

绿洲安全

2026年7月22日 08:00 北京

在小说阅读器读本章

去阅读

以下文章来源于MessFreeSecurity ，作者messfree

MessFreeSecurity .

提供社区优质咨询服务

演练第二天晚上，老方在群里发了条消息。

“域控没拿下。Kerberos 票据有问题。”

小温回：”卡在哪？”

“Access Denied。hash 对的，SID 对的，票据打进去了，klist 能看到，就是不通。”

“时差查了没？”

老方没回。

过了大概四十分钟，群里弹了一张截图。mimikatz 命令行，最后一段有个参数被黄色高亮标出来了——/startoffset:-120。

“操。域控跟我本机差了一个多小时。”

“默认取的本机时间？”

“对。文档有 startoffset 参数，我没看。”

小温发了个拍肩的表情。

我们那支队三个人。老方打域，小温打 Web，我打入口和横向。蓝队那边 SOC 五个分析员轮班，负责人姓周，手底下有个刚来三个月的女生叫小程。

这个进度——第二天晚上才拿到域控——是慢的。按计划老方应该在第一天就拿下域控，第二天我们俩跟着域管权限铺横向。但现在老方在 Kerberos 上耗了一个下午，整个攻击节奏往后拖了一天。

我们不知道，蓝队那边也在出问题。

第三天：蓝队第一次差点抓到我们

老方拿到域控后的第二天上午，小温在 Web 入点扫到了一个图片代理接口。imageUrl 参数，后端 file_get_contents 读图，没做协议白名单。内网有台 Redis，10.3.5.12:6379，密码是从上一台机器配置文件里抠的。

小温构造了 SSRF payload，用 HTTP POST body 嵌入 RESP 协议命令打 Redis。写 crontab 拿 shell。

发第一次。Redis 返回 WRONGPASS。

发第二次。-ERR unknown command "CONFIG"。

发第三次。payload 里的 \n 被 PHP 的 HTTP wrapper 自动补了 \r，RESP 长度字段错位，整条命令被 Redis 丢弃。

小温一条条调。试了五次。

与此同时，蓝队的 SIEM 在第一次 SSRF 请求出去的时候就弹了告警。WAF 拦截到了。告警推到了小程的队列里。

小程把告警打开。源 IP 是一个互联网云主机，payload 是一段带 tcp://10.3.5.12:6379 前缀的乱码。她在沙箱里重放了一次——沙箱环境是内网 Redis 的镜像容器，空密码，默认配置。沙箱返回 -ERR unknown command。小程备注：攻击尝试，未成功。关了。

她不知道两件事。

第一，沙箱的镜像容器跟真实 Redis 不一样。真实 Redis 有密码验证流程，镜像没有。她重放的 payload 在真实 Redis 上已经到 AUTH 那步了，但在沙箱里根本没走到认证就被 service 拒绝了——因为 payload 前面嵌的 AUTH 命令中包含特殊字符，被沙箱 Redis 的协议解析器跳过了。同一个 payload，在不同环境返回的错误码不一样。小程看到沙箱报 unknown command，以为攻击没生效。实际上只是沙箱没还原真实环境。

第二，WAF 给她的 payload 截断是 WAF 二次解析之后的版本。WAF 在分析 tcp:// URL 时自动做了换行符标准化——跟 PHP HTTP wrapper 做的是一样的操作。小程拿到的已经是字节被改动过的 payload。她用被改过的 payload 重放，结论天然是错的。

这两个问题叠加，导致小程判了”未成功”。告警关了。

四十分钟后，同一个源 IP 又发了一次 SSRF。小程打开，payload 跟前一条略有差异，但结构一样。备注：”同源重复探测，无新攻击向量”。关了。

第三次。又关了。第四次、第五次，都关了。同源 IP 的同类告警在 72 小时内堆积超过五条后，SIEM 的聚合规则自动触发——后续同类告警不再推送实时告警，改为每小时汇总一条日报摘要。

半年前蓝队被外部扫描器轰炸过，老周亲手写了这条聚合规则。当时的逻辑：同一个扫描器扫五遍，后面不可能有新东西，没必要一条条报。这条规则上线之后，分析员的告警处理量降了 30%，所有人都觉得是好规则。

没有人考虑过一个场景：攻击者在第五条失败、第六条成功。

没有人给聚合规则加过一个判断：payload 中的协议类型字段是否发生了变化。

小温的第六条 payload 换了 tcp://，绕过了 PHP HTTP wrapper 的换行符标准化。RESP 字节原样到达 Redis。AUTH 通过。CONFIG SET 成功。定时任务写入。

反弹 shell 弹回来了。

而第六条 payload 的告警，已经不在小程的实时队列里了。它在当天的日报摘要中，混在几十条”持续监测”建议中，被往下翻页的手指划过去。

不是没看到。是看到第五次之后，系统替人做了”后面不用看了”的决定。

第四天到第七天：蓝队的另一台设备出问题了

小温拿到 shell 之后，我们开始横向。

从 Web 入点的这台机器往内网深处打，SMB 传文件、WinRM 执行命令、MySQL 查询导出。攻击面铺开了。我负责横向，老方负责维持域控权限，小温继续找 Web 面的新入点。

一切顺利。三天之内摸了六台机器。唯一的困惑是：为什么蓝队没反应？

不是没告警。是告警量异常的低。我们三天里打了六台机器，蓝队 SIEM 对这期间我们跳板 IP 的告警只有三条，全是 ICMP 探测，没一条横向移动检测。老周在复盘时说，他那几天也觉得不对劲——NDR 的流量告警量从第三天晚上开始，平稳地降到了正常水平的六成左右。不是骤降，是一条平滑的曲线。凌晨降到 70%，到早上稳定在 60%。

他想过查一下。但告警量下降在运维视角里有太多合理的解释——晚上业务低谷、部分服务维护下线、网络流量自然减少。他没有往设备故障方向想。而且那几天他的注意力在别的地方——小程那边积压了上百条告警没清完，他帮着处理了一半。

直到第七天演练快结束的时候，NDR 厂商例行巡检，发现核心交换机上的一次生成树重算事件。时间是第三天凌晨两点零三分。重算过程中，交换机的端口镜像优先级被临时降了一级——镜像流量在交换机内部队列里排到了生产流量后面。核心交换机那段时间负载本来就高，高峰瞬时缓冲队列溢出，镜像流量被丢弃。

丢的不是全部流量。短包——ICMP、心跳——几十个字节，在队列里排得进去，基本没丢。长包——SMB 文件传输、WinRM 长连接、MySQL 查询结果回传——持续几十秒到几分钟的 TCP 流，丢了至少四成。

恰好是我们横向移动的三种主要流量类型。

我们在那三四天里用 SMB 传了不下二十个文件，用 WinRM 执行了几十条命令。NDR 一个都没抓到。蓝队 SIEM 收到的 NDR 告警，只有几条 ICMP 探测，是我们横向之前做主机存活扫描的残留噪声。

不是蓝队没发现我们。是蓝队的眼睛在我们横向的那几天，有一半时间是半闭着的。而我们完全不知道这件事。我们以为自己在躲避检测，实际上检测根本就没在工作。

双方都不知道。蓝队不知道 NDR 丢了十二个小时的流量。我们不知道自己在走后门的时候面前根本没有锁。

直到演练结束后的复盘准备阶段，NDR 厂商把丢包报告拿给老周看。他才明白那几天 SIEM 告警量为什么少了四成。

老周在复盘会上说这句话的时候，语气特别平静：”你们以为自己是 stealth 模式打进来的。我们以为你们只是还没横向。双方都猜错了。”

复盘会

复盘会开了四个小时。

红队讲了自己 Kerberos 死在时差上，SSRF 被 PHP 默认换行符补了五次才绕过去。蓝队讲了沙箱重放环境跟真实链路不一样，聚合规则把第六次攻击埋进了日报摘要。然后老周翻出厂商的 NDR 丢包报告，讲了交换机生成树重算、端口镜像降权、十二小时的流量黑洞。

三方复盘，所有人的根因都指向同一个东西：信任工具的默认行为。

老方信任 mimikatz 的默认时间。小程信任沙箱重放的结果和 SIEM 的聚合逻辑。老周信任 NDR 的告警量下降是正常的业务低谷。

老方在会议结束前站起来，在白板上写了三行字：

一、时间。 你的”现在”不是目标的”现在”。工具默认取本机时间的时候，它不会问你。

二、重放。 沙箱环境不是真实链路。被截断、被解析、被补过字节的 payload，重放出来一定是假结果。

三、基线。 安全设备的”正常”不等于设备在正常工作。告警量降了 40%，就是有一扇窗户被风吹上了。你得去推开看看。

写完他把笔放下。

“这次演练，红蓝两边加起来的问题，都是同一个——我们默认工具在帮我们，但实际上它在骗我们。”

老周接了一句：”而且它骗你的时候，不会弹告警。它只是安静地少给你一点数据，让你自己猜错。”

“网安回忆录”系列第四篇。名字隐了，事是真的。mimikatz 默认取本机时间是真的，PHP stream wrapper 换行符标准化是真的，NDR 交换机端口镜像丢包是真的，SIEM 告警聚合掩盖重试也是真的。

🔚 点个「在看」，或者转发给那个从来不看安全设备日志量的同事。让他今天去对比一下昨天的数字。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：绿洲安全 《网安回忆录 – 金融系统攻防演练，三次差一点拿下》