文章总结： 本文基于一次攻防演练经历，揭示安全团队过度依赖网络遥测而忽视物理入口的盲区。攻击者通过线下冒充面试进入办公区，接入办公网横向移动，而门禁、访客等记录未纳入SIEM关联。事后团队改进访客流程、设备准入及跨部门事件关联，强调未闭合的入口可能不在现有观测范围内。
综合评分： 88
文章分类： 实战经验,红队,安全运营,物理安全,安全建设
网安回忆录 – 一白板上那行”待确认”，答案不只在网络日志里
原创
messfree
messfree
MessFreeSecurity
2026年9月19日 21:23
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
2024 年攻防演练第三周，一个深夜。SIEM 弹了一条告警：网络侧观测到域内一台文件服务器作为源，探测多个办公网段的端口和服务，并尝试通过 SMB/LDAP 枚举账户。这台机器的日常职责是跑文件共享，跟这个行为完全对不上。
当时我负责这轮演练的事件研判，能调取终端、网络和服务器日志.
我先去看了这台文件服务器的认证记录。最近有一个域账号成功登录过，这个账号的常用使用者，正是办公区一台普通员工终端的主人；源 IP 和登录类型也指向那台终端。我又去翻那台终端的 EPP 日志，上面有凭据相关的工具执行记录。几个小时后，我以为自己把网络侧的攻击链拼完了。
我们以为顺藤摸瓜
终端平台日志里，那台员工终端上出现过常见的凭据访问工具，本地存储的凭据材料有被读取的痕迹。相邻时间窗口内，这位员工常用的域账号成功认证了文件服务器，文件服务器的审计日志里也留下了共享目录访问记录。网络侧把后来那轮大范围扫描的源定位到了这台文件服务器。
横向路径看起来很清楚。我把 SIEM 里的认证事件都翻出来了：终端到文件服务器，文件服务器到其他机器，用的账号、时间点，一条一条对得上。
但有两点当时没有追下去。一是终端上凭据访问工具到底导出了什么、导出的材料是不是后来登文件服务器用的那个，日志给不出确定答案。两组事件时间相邻、相互支持，但不能单独证明这条因果。二是攻击者怎么在文件服务器上把扫描跑起来的，现有日志也没有完整记录。
真正奇怪的是那台员工终端自己。它没有发现异常的交互式远程登录，没有可疑的 Web 访问，邮箱里也没有钓鱼邮件。它就像从某天开始，自己开始跑这些工具。我们当时归了一个比较保守的假设：这个终端上某个账号可能用了弱口令，或者某个暴露服务没打补丁，被人从网络上摸进来了。但具体是哪条路径，日志里没有实锤。
到天亮的时候，我在白板上画了一张图：从这台终端，到文件服务器，到扫描告警。终端之前那一段，我写了一行字：首台可见受害主机，前置入口待确认。终端和文件服务器隔离了，相关账号重置了，持久化机制在完成证据保全后清除，剩下的交接给白班，我去睡觉了。
报告写得很漂亮
后面几天，我们按这个方向继续查。文件服务器的审计记录里还能翻出更多痕迹：按日志记录，相关账号访问过几个共享目录，尝试认证过域控，但没有看到成功的域控会话。复盘材料后来确认，这些动作属于红队路径的一部分。
网络侧的攻击链，在现有遥测里看起来很完整：一台终端出现凭据访问行为，域账号认证文件服务器，文件服务器作为源发起大范围扫描。我们甚至能标出每个动作大致发生的时间窗口。
报告里,我们写了时间线、已观测影响范围、整改建议：那个终端的补丁要打上，相关账号的弱口令要清掉，文件服务器的共享权限要收一收。已确认共享访问的主机、认证失败的账号、只有扫描命中尚未证明受控的资产，是分开列的。每条已确认的网络事实都有日志或告警来源，假设单独标注。
报告里唯一单独留作根因假设的，是前置入口。凭据因果和文件服务器启动扫描的方式，也作为未闭合的技术细节单独标注。我们在报告里写：前置入口可能是某个账号弱口令，也可能是暴露服务未打补丁，建议进一步排查。大家都觉得这不是什么大问题，终端和文件服务器已经隔离，账号已经重置，后半段风险暂时压住了，剩下那一段慢慢查就是。
演练还在继续，我们盯着剩下的告警，等着下一条线冒出来。
答案是别人告诉我们的
演练结束后，上级整理了一份红队攻击路径的复盘材料，同步给了我们。这也是惯例。演练期间我们和红队不碰面，打完之后从组织方那里拿到他们怎么打的。
材料的开头，就跟我们白板上那张图对不上。
上面写：没有通过 Web 应用取得入口，也没有发钓鱼邮件。
上面写：初始入口是线下物理进入。
按组织方复盘材料所述，踩点当天，他们以面试的名义跟 HR 约了一次。那天前台给了他们一张临时通行凭证，就是一张纸条，上面印着二维码，扫码就能过大堂门禁。他们当时没说什么，正常进、正常出。材料只确认到这里：这次访客流程让他们掌握了临时凭证的发放、校验和有效期。材料没有说明大堂的二维码访客凭证和办公区门禁卡是否属于同一套系统；后来如何取得制作办公区门禁凭证所需的数据，材料没有展开。
红队材料里关于大门怎么过的，其实只有一句结论：利用了访客流程和保安信任。具体怎么利用的，材料没写。
真正把这段过程拼出来，是演练结束后我们找保安和前台聊了几次，又调了走廊监控，才一点点对上的。
保安说，那段时间确实有这么个人。天热，进门的时候总递根烟，出门的时候顺手从便利店带瓶水。保安室就那么两个人，每天进进出出好几百人，能停下来聊两句的没几个。几次下来，脸就熟了。他记得这人”好像是楼上面公司来面试的”，只觉得他是个好人。后来再来，登记也懒得仔细看了，抬抬手就放了。
监控里也对得上：不是一次进来的，前后来了好几趟，每次一个人，穿得挺干净，走路不东张西望。等到演练入场那天，他走到门口，保安连身份证都没让掏。
进了大堂，他们用自己做的那张凭证刷开了办公区的门。
从进楼、过门禁到接入网口的这段物理过程，没有产生进入 SOC 的可疑 Web、认证或端点告警。门禁、交换机和 DHCP 都留下了记录，但这些记录没有触发安全异常产生告警。
这一段最让我不舒服的地方就在这里。保安放他进来，是因为他认识这张脸；门禁放他进来，是因为那张凭证在技术上”有效”。这两个动作在物理世界里都合情合理。一个大热天愿意跟你说话、还给你递烟送水的人，怎么看都不像个攻击者。但拼在一起，就是一个完整的入侵入口。
进办公区之后，他们找了个没人的工位，把自己的笔记本接上了办公网。这个动作只让笔记本获得了一个办公网的网络落点，并不等于已经控制了任何员工终端。门禁和访客记录只能证明人和卡曾经到过现场；笔记本接的是哪个网口、拿到哪个 IP、落在哪个 VLAN，材料没有写。这些记录当时由网络组分别维护，没有进入 SOC，也没有和资产、人员建立统一映射；事后只能知道有设备接入，不能可靠地把它对应到具体工位和人。
告警发生在入场当天深夜。材料没有说明笔记本是接入后留在工位，还是由外部远程控制；这不影响物理入口的判断，但网络落点和深夜告警之间的时间差，现有记录，回头在看也没有完全解释的通。
材料里接着写：那台员工终端不是他们进入办公网时的第一落点；笔记本接入之后，他们横向到过这台终端，在上面执行了凭据相关的操作，这才有了后来我们看到的那条链。具体使用了什么协议、凭据或漏洞，材料没有写；我们现有的日志也没还原出这一步。
我坐在工位上，盯着那行字看了好一会儿。
脑子里回到白板上那行字。“首台可见受害主机，前置入口待确认。”我留了个待办，以为网络日志里早晚能补上。实际上组织入口那一段，从一开始就不在我们当时使用的 SOC 采集、检索和关联链里。
痕迹一直在，只是我们不看
复盘完我回去翻记录。
按材料里的时间线，我们事后核对到：HR 的预约记录里，那次”面试”真有；前台访客登记簿上的姓名与复盘材料中的身份一致；办公区走廊监控的画面，与材料给出的时间窗口和行进路径相符。门禁系统记录了与对方所称凭证对应的卡号、门点和时间；”这是自制卡”这一点来自复盘材料，不是门禁日志本身。这些记录能相互印证到场时间、路径和门点，但不能单独证明画面里的人就是红队成员。
这些记录不是不存在。是它们当时没有进入 SOC 的采集、检索和事件关联。我们的 SIEM 接了 EDR、接了防火墙、接了域控、接了邮件网关，但没有接门禁系统的事件，没有接 HR 的预约记录，也没有跟前台的访客登记做任何关联。监控平时也不交给安全团队看，更没有建立按需调阅的流程。
攻击者从大门走进来的那一段，发生在另一个世界，一个当时根本不在 SOC 事件链里的世界。
我们错在哪里
这件事之后我想了挺久。
我们这套溯源流程，默认初始访问发生在网络边界内，然后优先收集网络遥测：边界请求、连接记录、进程链、认证日志。这套方法在凭据访问、横向移动这些环节确实好用，这次也一样，从扫描告警回溯到文件服务器和员工终端，几个小时就拼完了。
但这个默认前提有个漏洞。它假设攻击者必须从网络上”打”进来，必须穿过边界，必须在我们采集的系统里留下请求和连接。这次他们告诉我们，人可以根本不”打”。他走进来，把自己的电脑接上你们的办公网。在当时的网络配置下，他取得了一个可通信的办公网落点；但这仍不等于他已经控制了任何域内主机。至于他之前怎么过的保安、怎么刷的门禁、怎么在 HR 系统里约的面试，这些事发生在门禁、HR、前台的系统里，跟我们的 SIEM 不在同一条事件链上。
物理接入解释了他怎么走进办公楼、怎么在办公网里拿到一个落点，却不解释他怎么控制第一台受害主机。网络落点和主机执行之间，还隔着一段我们没有证据闭合的桥。按材料所述，他确实从笔记本横向到过那台员工终端；但用什么协议、什么凭据、什么漏洞，材料里没有写，我们的日志也还原不出。我们看到的，是这台终端上确实发生了凭据访问，是之后文件服务器确实被认证、确实发起了扫描；中间那一段桥梁，我们没有独立证据。
更麻烦的是，当时我们没有把这个口子往外说。连续两轮网络排查都无法解释入口，我们没有把事件升级给 HR、前台、设施组和网络组，而是把它留在了报告末尾的根因假设里。后来我们把”初始入口未闭合”设成了跨部门升级条件：网络证据无法解释时，必须同步查预约、访客、门禁、交换机和 DHCP，而不是把它当成安全团队自己慢慢查的事。
我们当时也不是”查不到”。我们是查到了一个看起来合理的假设，弱口令，或者未打补丁，然后就停了。那个假设在当时证据里既未被证实，也未被证伪。它刚好够我们把报告写完，让我们以为结了。
真正危险的不是没看到。是看到了一个不完整的故事，然后把它当成了完整的。
结束后改了什么
没有改什么惊天动地的东西。
HR、前台和保安对预约身份增加了二次核验，电话回拨确认。访客进入办公区要求全程陪同，不允许单独走到开放工位。临时通行凭证改成一次性、短时有效，绑定预约和陪同人，离场后自动失效并回收载体，不再是一张能长期使用的纸条。办公区闲置网口做了禁用，办公网推设备准入，未纳管设备进来只能进隔离网络。门禁刷卡事件、交换机端口接入、DHCP 分配记录，开始跟 SOC 的事件做关联；我们也建立了按需调阅监控和访客登记的流程。
新员工入职第一周会收到一次钓鱼演练。除此之外，HR、前台和保安也做了几次线下冒用身份的桌面推演。重点不是测点击率，是让他们知道，约面试的人不一定是真的。
后来验收的时候，我们不只看系统里有没有接入日志，还看三个具体结果：未经回拨核验，或现场身份与预约信息不一致的访客，不能独自进入办公区；未登记的设备插到办公口必须落进隔离网络；门禁、交换机端口、DHCP 和终端事件，能按同一个时间窗口关联到同一个事件。
这些改动后来写进了值班规则、访客流程和验收项，而不是停在安全团队自己的文档里。
我后来在白板上把那行字改了。原来写的是”首台可见受害主机，前置入口待确认”。现在我把它分成了四行：组织入口，通过访客和门禁进入办公楼；网络落点，笔记本接入办公网，具体网口和地址未独立还原；首台可见受害主机，员工终端；横向执行方式，笔记本怎么落到这台终端，仍然没有被日志还原。
我才分清：组织入口的到场时间、门点和访客流程，已经由红队材料与门禁、访客记录相互印证；但笔记本的具体接入位置，以及它如何落到员工终端，仍然没有独立证据。
白板最后一行，我写的是：你没查到的那一段，可能不在现有观测范围里。
本文基于一次真实的攻防演练经历改写，人名、主机名和部分细节已做脱敏。如有雷同纯属巧合，因为都是瞎编的。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：MessFreeSecurity messfree
messfree《网安回忆录 – 一白板上那行”待确认”，答案不只在网络日志里》