【实战案例】因第三方运维私开测试端口，致某企业被LockBit勒索

写在前面 先说明为什么写这篇案例。 做应急响应数百起，我们处置过大量勒索事件，其中不乏手法精密的攻击：0day 漏洞、无文件落地、内存加载。但这起案件不一样， 它的攻击技术难度并不高，真正难的从来不是技术，而是人。 攻击者没有用任何高深的手法，入口只是一次"图省事"的端口映射：第三方运维人员私自将内网服务器的 3389 远程桌面映射到公网，事后又不愿承认。我们在应急响应中遇到过太多次类似场景：运维私开测试端口、用 frp 做内网穿透、在路由器上随手做一条映射，方便是方便了，门也敞开了。而事后追问时，第一反应往往是否认。 这篇文章，完整还原我们从"日志被清空、线索近乎中断"的现场，用逆向思维反推出入口、再用证据链坐实全过程的思路。 为保护受害单位信息，文中内容已做脱敏处理，仅分享溯源思路与防范建议，供同行参考。 文中涉及两台 Windows 服务器，为便于阅读，统一标注为： 一、案发现场：凌晨 5 点 29 分 2026 年 8 月 20 日凌晨 5 点 29 分，A 主机上的业务文件最先被批量加密。通过文件检索工具可以看到，大量文件的修改时间整齐地停在 05:29 至 05:30 之间，加密就是在这个时间点开始的。 A 主机上被加密的文件：文件名变为随机字符，修改时间整齐停在 2026-08-20 05:29（Everything 检索视图） 在 A 主机提取的系统日志中，我们观察到 05:29 起出现大量 SMBClient 报错：该机器正在对内网 192.168.1.* 网段的 445 端口发起密集连接： 它正在对内网其它机器进行SMB爆破 。 但奇怪的是：往前翻，日志里没有任何记录能说明攻击者是怎么拿到这台机器权限的。仿佛这台机器是"凭空"被控制的。（答案后文揭晓：入口机器上的日志被攻击者清理了。） A 主机系统日志：2026-08-20 05:29 起，对内网 445 端口的大量连接失败记录（SMBClient 事件） 日志被清了，但有一个地方攻击者清不掉： Amcache （Windows 程序执行记录数据库）。在 A 主机的 Amcache 中，我们发现 5-NS new.exe 于 2026-08-20 05:28:13 被执行，SHA1 哈希为 629c9649ced38fd815124221b80c9d9c59a85e74 。 A 主机 Amcache 程序执行记录（取证分析表）：5-NS new.exe 于 2026-08-20 05:28:13 执行 这个"5-NS"是什么？我们通过哈希在公开沙箱与威胁情报中核实了它的身份：这是一款基于 NetShareEnum、WNetAddConnection2W 等 API 的 内网共享扫描/爆破工具， 程序内嵌"%d ips by network mask""Scan by: %s"等网段扫描输出字符；国外安全团队 The DFIR Report 在 2025 年 5 月披露的一起 ELPACO 勒索攻击报告中，攻击者工具包里也出现了完全相同的文件（名为 ns v.2.exe ，哈希一致）。一个 2018 年编译的老工具，至今仍在勒索攻击一线被使用。 05:28 执行扫描器，05:29 开始加密，攻击者的节奏紧凑到分钟级。 此外，A 主机的 C:\Users\Administrator\Desktop\x64-Release\ 目录下还留有攻击者的完整工具包：加密器本体（Stub）和密码抓取工具 netpass64（经核实为 NirSoft 出品的网络密码恢复工具，A主机本机上未执行）。 A 主机桌面 x64-Release 目录：netpass64.exe、勒索信 DataRecovery.txt、加密器 Stub 等攻击工具 二、加密特征：典型的 LockBit 3 签名 被加密文件的命名遵循 LockBit 3 家族的标志性规则： 随机 10 位字符（大小写字母+数字）+ 勒索组织联系邮箱 + 8 位随机扩展名 ，且文件图标被统一替换为 黑色背景、白边、大写字母 B 。 被加密文件特征：随机文件名 + 8 位随机扩展名，图标为黑底白边大写 B（LockBit 3 家族标志性特征）（图示为B主机截取，开始加密时间为8月20日凌晨5:32） 桌面上的勒索信 DataRecovery.txt 内容（受害者标识已打码） 勒索信要求受害者以邮件联系攻击者，并在标题中注明个人 ID，这是 LockBit 系勒索的典型谈判流程。 三、第二台主机：RDP 登录来源，竟是"路由器网关" 顺着时间往前推，我们在另一台受灾机器（B 主机）的系统日志中发现：加密时间段附近存在远程桌面登录记录，而登录来源 IP 是 192.168.1.254， 这是企业路由器的网关地址。 B 主机 RDP 登录日志：2026-08-20 05:34，用户 Administrator，来源网络地址 192.168.1.254（路由器网关） 更关键的是，B 主机的 C:\Users\Administrator\Desktop\x64-Release\ 目录下，存在 同一套工具包 ：加密器 Stub、netpass64、5-NS 扫描器、勒索信模板。 B 主机桌面 x64-Release 目录：同一套攻击工具 到这里，思路已经比较清晰：攻击者先拿到某台对互联网开放的主机权限，植入加密器和内网横向工具，再对内网网段进行 SMB 爆破，能匿名登录的直接拿下并加密。 但两个核心问题没有答案： 黑客通过什么方式拿到的权限？拿到的又是哪台主机？ 而登录来源显示为网关 IP 这件事，本身就透着不合理（原理后文详解）。 四、突破口：一句"我们从没开过任何服务" 带着这两个问题，我们联系了该企业的第三方运维人员，询问服务器出口 IP 的相关信息，并明确询问：是否曾对外开放过 WEB 服务、RDP 服务？ 运维的回答义正言辞： "没有开启过其它服务，我们所有业务均为内网使用。" 在应急过数百起案例之后，我们只相信一句话： 合理怀疑一切，找到一切不合理。 日志可以缺，口供可以否，但互联网会记得。 我们通过资产测绘平台查询该企业出口 IP，结果显示： 该 IP 曾对外开放 3389（RDP）端口 ，测绘记录中的主机名字段与 B 主机一致，平台最新检测时间为 2026-08-11 08:33:37 。 资产测绘平台记录：该企业出口 IP 曾开放 3389 端口（rdp/ssl），主机名与 B 主机一致，最新检测时间 2026-08-11 08:33:37 这里有个知识点，必须展开讲，因为它是本案的关键一环： 测绘平台 8 月 11 日的记录，能证明 8 月 20 日被攻击时端口还开着吗？ 能作为佐证，而且时间差完全合理。全球 IPv4 地址约 43 亿个，任何测绘平台都不可能实时扫完全网：Shodan 官方文档写明，其爬虫 7×24 小时不间断、以随机方式探测全球地址空间，覆盖一轮整个互联网约需一周；国内 ZoomEye 官方介绍其拥有 2000+ 探测节点 24 小时不间断扫描，国内资产才能做到每日更新一次。所以测绘数据滞后几天到一周以上，是行业常态。8 月 11 日测绘到 3389 开