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

写在前面

先说明为什么写这篇案例。

做应急响应数百起，我们处置过大量勒索事件，其中不乏手法精密的攻击：0day 漏洞、无文件落地、内存加载。但这起案件不一样，它的攻击技术难度并不高，真正难的从来不是技术，而是人。

攻击者没有用任何高深的手法，入口只是一次"图省事"的端口映射：第三方运维人员私自将内网服务器的 3389 远程桌面映射到公网，事后又不愿承认。我们在应急响应中遇到过太多次类似场景：运维私开测试端口、用 frp 做内网穿透、在路由器上随手做一条映射，方便是方便了，门也敞开了。而事后追问时，第一反应往往是否认。

这篇文章，完整还原我们从"日志被清空、线索近乎中断"的现场，用逆向思维反推出入口、再用证据链坐实全过程的思路。为保护受害单位信息，文中内容已做脱敏处理，仅分享溯源思路与防范建议，供同行参考。

文中涉及两台 Windows 服务器，为便于阅读，统一标注为：

• A 主机：最先被我们分析的被加密服务器，攻击者在此对内网发起 SMB 爆破；

• B 主机：后被确认为攻击入口的跳板机，也是最后一个被加密的机器。

一、案发现场：凌晨 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 开放，意味着至少在那之前它是开着的。

我们拿着这张截图再次询问运维。运维沉默了许久，回复道："这是我们当初对外映射的测试端口，没几天就关了。"

从"从未开启"到"测试端口"，中间隔着的不是记忆偏差，而是一整套值得说道的心理。做应急响应这些年，我们对此早已司空见惯：运维对外映射端口、用 frp 等工具做内网穿透的情况，我们遇到过不止一次。有时候是图省事，有时候是安全意识薄弱；而出事之后不愿意配合，多半是怕担责任，承认一个"临时测试"，比承认一个"长期暴露"听起来责任小得多，这是人在压力下的本能反应。

五、攻击链复盘：先逆向，再正向

至此，所有线索可以拼成一条完整的链。先看时间线：

把逆向推理翻译成攻击者的正向视角，整个过程并不复杂：

第一步，找门：攻击者通过资产测绘平台检索开放 RDP 服务的 IP，攻击者不需要自己扫描，测绘平台早已把数据整理好，检索即是踩点。

第二步，进门：B 主机的 Guest 来宾账户呈启用状态，攻击者甚至无需暴力破解密码。

B 主机账户状态：Guest 账户启用（帐户启用：Yes），无需暴力破解

第三步，站稳脚跟：进门后必然伴随着提权与权限巩固，但具体手法已无法还原，日志被清理了，我们只能诚实地说"未知"，而不是编一个故事。这是应急响应的职业底线：能证明的写死，不能证明的留白。

第四步，投放工具、横向移动：攻击者将整套工具包放在桌面 x64-Release 目录，用 5-NS 扫描内网共享与存活主机，用 netpass64 抓取本机保存的网络密码（A 主机上未执行成功），能直接登录的机器直接拿下。

第五步，清理痕迹：工具包里的两个脚本用于反取证：

:: LogDelete.bat —— 遍历并清空 Windows 全部事件日志
FOR /F "delims=" %%I IN ('WEVTUTIL EL') DO (WEVTUTIL CL "%%I")
:: Clearr.cmd —— 先判断是否有管理员权限，有则逐条清空所有日志通道
@echo off
FOR /F "tokens=1,2*" %%V IN ('bcdedit') DO SET adminTest=%%V
IF (%adminTest%)==(Access) goto noAdmin
for /F "tokens=*" %%G in ('wevtutil.exe el') DO (call :do_clear "%%G")
:do_clear
wevtutil.exe cl %1

第六步，加密。 加密前的准备工作同样专业，killprocess.cmd 停止指定服务：停掉 SQL Server 相关服务（避免数据库文件被占用导致加密失败）、关闭系统防火墙、删除备份目录、禁用系统自动恢复：

:: killprocess.cmd（节选）—— 停服务、删备份、关恢复、关防火墙
net stop SQLWriter
net stop MSSQLSERVER
net stop SQLSERVERAGENT
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quiet
netsh advfirewall set currentprofile state off
netsh firewall set opmode mode=disable

攻击者工具包 x64-Release 全貌：5-NS 扫描器、清日志脚本、killprocess 脚本、netpass64、勒索信模板

最后一步，才是加密入口机 B 本身。 为什么入口机最后一个被加密？因为它是攻击者进出内网的唯一通道，只有把内网能加密的机器全部加密完，确认再无价值可榨，攻击者才会"过河拆桥"，加密跳板并离场。这也是我们最初会误以为 A 主机是入口的原因：攻击者刻意把入口留到了最后。

攻击路径复盘图示

RDP 日志里的来源 IP，为什么是路由器网关？

这是本案中最容易被忽略、也最能体现功底的一环。原理并不神秘：运维在路由器上做端口映射（DNAT，目的地址转换）时，路由器为保证回程流量正确返回，对入站连接同时做了源地址转换（SNAT/MASQUERADE），于是 B 主机看到的连接来源，就被替换成了路由器自己的内网地址 192.168.1.254。这在运维圈是常见的配置现象（RouterOS 等系统上尤为典型）。

真正的麻烦在于：这类路由器普遍不具备连接日志记录能力，转换表随会话结束即销毁。攻击者的真实外网 IP，随着路由器重启或会话老化，永久消失了。攻击者未必懂这个原理，但客观上，这条随手配置的映射替攻击者完成了一次日志清理。

六、举一反三：这扇门，到底该怎么管

这起案例里没有 0day，没有免杀，没有域控攻防，攻击者全程使用的都是公开工具和标准协议。真正的漏洞只有一个：一条没人记得、没人审批、没人关闭的端口映射。 对此，我们从甲方、乙方两个视角各给一份清单。

如果你是甲方（企业），管不住的人要用制度管：

1. 第三方运维必须纳管：远程运维一律走堡垒机或 VPN，账号专人专号、限时授权、操作留痕；禁止私自使用 frp 等内网穿透工具，写进合同与安全责任书；

2. 端口变更要审批：任何对公网的端口映射（含"临时测试"）必须走审批并设定自动关闭时间，到期未续批自动失效；

3. 定期自查暴露面：每季度用资产测绘平台（FOFA、ZoomEye、Quake 等）查一遍自己的出口 IP，你看到的，就是攻击者看到的；

4. 日志必须外发：Windows 事件日志实时转发到独立的日志服务器，本机日志可以被清，外发的日志清不掉。本案中 Amcache 能成为突破口，恰恰说明"多留一份证据"的价值。

如果你是乙方（运维人员）：

1. 测试端口即开即关，关上之后在测绘平台复查一遍，确认它真的关了；

2. 出了事，第一时间说实话。应急人员要的是时间线和入口，不是你的检讨书；隐瞒的代价，是把企业和你自己都拖进更深的坑里；

3. 你图省事打开的那扇门，攻击者一定会找到，测绘平台一周之内就会把它挂上索引，剩下的只是时间问题。

规模不同，打法不同：

• 小企业：记住三条底线，3389/445 等管理端口永不出公网；Guest 账户保持禁用；核心数据留一份离线备份。做到这三条，能挡掉绝大多数同类攻击；

• 大企业：把攻击面管理纳入常态运营，对全部分支机构、子公司、供应商的出口资产做持续测绘监控；内网做分段隔离，让一台跳板机的沦陷不等于整网沦陷。

附：本案 IOC（指标情报）