清除勒索软件：一次 Windows 文件服务器共享目录遭加密的入侵路径还原与恢复复盘

一、问题背景

公司核心文件服务器 FS01 是一台加入域的 Windows Server 2019，承载设计部与财务部共用的 SMB 共享目录，约 4 TB 资料，包含合同、图纸与月度结算表。该服务器原本只对内网开放 445 端口，但因一次临时远程运维需求，运维同事将 3389（RDP）通过边界防火墙映射到了公网并设置了弱口令，事后未及时回收。这台机器长期处于"能连就行"的灰色状态，直到某个周一早上被业务电话叫醒——共享目录里几乎所有文件都打不开了。

二、故障现象

周一 08:20，多名同事反馈无法打开共享文件，双击文档提示"文件已损坏"或"拒绝访问"。登录服务器后发现：

大量文件的扩展名被改写为 .locked（如 合同2026.docx.locked），共计约 3.7 TB 文件受影响；
每个目录下都多出一个 README_RESTORE.txt，内容是勒索信，要求以比特币支付赎金换取解密密钥；
系统的卷影副本（Shadow Copy）被清空——vssadmin list shadows 返回"没有卷影副本"，说明攻击者删除了备份快照；
服务器 CPU 与磁盘 IO 在凌晨 02:00-03:10 出现一段异常的持续高位，之后恢复正常；
部分用户报告登录域账号时偶发缓慢，但并未报错。

初步判断：这是一次典型的勒索软件（Ransomware）加密事件，且攻击者已经拿到服务器的较高权限并清除了本地恢复点。

三、排查过程

1. 止血与隔离。 第一动作不是解密，而是隔离。立即在交换机上把 FS01 的端口 shutdown，断开其所有网络访问，避免加密进程横向扩散到其他主机或继续加密。同时保留内存现场（不重启，便于后续取证）。

2. 定位加密进程。 既然攻击发生在凌晨且已经结束，现场进程里大概率看不到加密程序。转而从 Windows 事件日志与文件系统时间线入手：用 wevtutil 导出 Microsoft-Windows-PowerShell/Operational 与 System 日志，发现凌晨 02:05 有一条可疑的 powershell.exe -enc <Base64> 执行记录；vssadmin delete shadows /all /quiet 的调用时间与此吻合。结合文件 MFT 修改时间，最早一批被加密的文件集中在 02:07，逐目录向外扩散，符合单进程遍历加密的特征。

3. 还原初始入侵入口。 勒索软件本身不是入口，它只是"载荷"。真正的入口要从认证日志找。筛选 Security 日志事件 ID 4625（登录失败），统计发现 07-15 深夜起出现来自同一境外 IP 的高频失败记录，峰值每分钟 40+ 次，持续约 90 分钟，随后出现一条 4624（登录成功）——这正是公网映射出去的 RDP 弱口令被暴力破解。该成功会话的账户为 admin_local，随后以此为跳板，通过 net use 挂载其他共享、并启用 RDP 端口转发做横向移动。

4. 确认横向范围。 用域控上的登录日志（4624 + 4768 Kerberos TGT 请求）反查 admin_local 这个账号在失陷窗口内的所有登录主机，确认其仅触达 FS01 与一台跳板机，尚未拿到域管权限，未对域控本身造成破坏——这是不幸中的万幸。

5. 样本与 IOC 提取。 从 C:\Windows\Temp\ 与回收站残留中找到了加密母体（一个伪装成 svchost.exe 的二进制）和其释放的批量脚本，计算哈希并上传到威胁情报平台比对，确认为某已知勒索家族的变种，IOC（C2 域名、互斥量名）被登记进防火墙封禁列表。

四、解决方案

1. 数据恢复（不付赎金）。 由于卷影被删、无有效本地备份，最终恢复依赖两点：一是磁带/异地备份——庆幸财务部每周日的全量备份在隔离前已完成且未被加密，从备份恢复到干净环境；二是对少数无备份的目录，尝试用文件恢复工具扫描磁盘未覆盖扇区，挽回了约 60% 的最近修改文件。

2. 清除载荷。 在断网单机环境下，删除 C:\Windows\Temp 下的母体与启动项（检查 HKLM\Software\Microsoft\Windows\CurrentVersion\Run 与任务计划程序里新增的恶意条目），用杀毒软件全盘扫描确认无残留。

3. 回收公网暴露面。 立即在防火墙上删除 3389 的公网映射，RDP 仅允许从堡垒机网段访问；为 admin_local 设置强口令并加入账户锁定策略（5 次失败锁定 30 分钟）。

4. 重建与加固。 FS01 从干净镜像重装系统、重新加域，共享权限按"最小权限"重新划分，并开启文件服务器审计（对象访问审计策略），对关键目录的改名/删除做日志留存。

五、根因分析

这次事件的根因不是"勒索软件太强"，而是暴露面管理失职 + 凭据薄弱 + 恢复点缺失的叠加：

公网 RDP 映射配了弱口令且长期未回收，给攻击者敞开了第一道门；
服务器没有启用网络级身份验证（NLA）强制与多因素认证（MFA），暴力破解成本低；
备份只在本机卷影与同网段存储，加密者一句话就能清空，缺乏异地/离线副本，导致几乎无险可守；
缺乏对外暴露服务的资产台账与定期回收机制，临时开口变成永久后门。

六、预防措施

收敛暴露面：公网只放必要服务，RDP/SSH 一律走堡垒机或 VPN，禁止直接映射；建立"临时开口登记 + 到期自动提醒回收"流程。
强化认证：所有对外远程入口强制 MFA，启用账户锁定与登录失败告警；禁用弱口令，定期用密码审计工具扫描。
备份三二一：至少一份离线/异地备份，且定期做恢复演练验证可用性；关键系统开启不可变备份（immutable backup）或对象存储版本锁，让勒索软件删不掉。
监控与告警：对 4625 暴破、vssadmin 调用、非常规时段大量文件改名等异常行为配置 SIEM 告警；终端部署 EDR 实现进程级行为检测。
最小权限与分段：共享目录按角色授权，服务器网段与普通办公网隔离，限制失陷后的横向移动半径。

七、总结

勒索软件不是天灾，而是运维疏忽的放大器。本次事件里，攻击者真正利用的只是一个被遗忘的公网弱口令 RDP，而真正的代价来自没有离线备份与暴露面失控。排查的关键节奏是"先隔离止血、再还原入口、最后谈恢复"——永远不要急于解密而放跑现场。对运维来说，最便宜的安全投入是关掉不该开的端口和留一份删不掉的备份。