本篇为安天工程师在响应客户需求时，遭遇两例SSD磁盘在运行中丢失事件，进行处置排查工作的工作记录

这是典型的“游蛇”（银狐）组织的攻击手法。宝刀通过用户开通的远程访问入口，进行了排查处置，通过安天CERT研发“游蛇”专项排查工具发现了内存木马。检索其他主机记录，并发现了感染原因为该用户在搜索引擎搜索下载某软件，但实际下载到的是被绑定木马的软件安装包，安装后导致远控木马植入。该用户下班离开后，并未关机，也未退出WEB微信，此时攻击者远控了感染主机，实施传播木马，拉群诈骗等活动。快速协助用户清除了木马，并将“游蛇”专项排查工具、Atool系统安全内核分析工具推荐给客户使用，用户在其他主机上还发现了其他木马病毒。 用户对安天的处置工作表示满意，并主动将台式终端和笔记本原有杀毒软件全部替换为安天智甲EDR，公司安排我做技术支持，8月17日，安装部署基本完成，我协助用户进行了安全策略设定调整，系统补丁更新等工作。

8月19日，客户反馈，当日，有两台设备使用中发生逻辑盘F:消失，重启后恢复正常，但继续使用中还会重新发生掉盘现象，客户IT管理人员询问我是否是因智甲查杀扫描过程，增加磁盘工作负载导致。这是我过去在技术支撑中，从没遇到过的情况，其他同事也没有遇到过。虽然我不是开发工程师，但通过多年的技术支持和响应经验，能够基本判定事件和安装智甲无关，一方面本着“安天工程师文化”导向是为客户解决问题的原则，我决心一定要把客户的问题解决。我先告知客户对丢失的磁盘上的重要内容进行备份，之后，经过初步电话沟通，整理情况如下：

1、两台设备均为某品牌同型号笔记本电脑，均运行Win11系统，有多块磁盘，均为SSD。

2、丢失的磁盘专门用于存放虚拟机镜像，用户是基于虚拟机系统崩溃观测到磁盘掉电的。

3、用户在磁盘消失后，打开计算机管理器，发现对应的物理盘不可见，重启后会恢复正常。

两台电脑均在8月17日安装了智甲EDR，但对应虚拟机镜像内尚未安装，我们引导用户查看了智甲管理中心的相关日志、本地日志，在发生掉电事件的阶段，智甲均未执行类似全盘扫描等重载任务。根据智甲的设计机理，虽然智甲为驱动级主防，但从机理和防御点上分析，没有触发类似磁盘设备消失故障的可能性。我与测试与交付中心同事也做了确认，且8月17日~19日间，智甲除升级安天AVL SDK反病毒引擎库和主防规则库外，并没有主防的模块级更新，进一步可以判断事件与安装智甲无关。

我又将系统日志事件与智甲管理中心的日志进行了对比，在介质管控日志中，发现在两台设备掉电发生前，均曾插入U盘，且为同一个U盘（用户用该U盘和对应虚拟机进行文件交换）。而且由于两台设备均为笔记本电脑，我们从历史处置经验猜测，可能是一个电源管理问题，由于插入U盘后增加了系统工作负载，导致对应磁盘供电不足而掉电。于是我带着USB功耗测试设备和其他工具打车到了客户现场，但经过测试，该U盘的功耗等参数并无异常。

我查看了故障主机的Windows日志，对应故障序列均为：

Virtual Disk Service服务停止，事件ID=4

iaStorVD的\Device\RaidPort0 的重置，事件ID=129

disk的逻辑块地址IO重试操作，事件ID=153

disk的传呼期间在设备上Device\Harddisk2\DR2 检测到错误，事件ID=51

Ntfs的延迟写入失败，事件ID=50

由于我的IT能力经验并不丰富，于是我将电话打给了IT运管部的同事，他和我一起分析认为当前的情况下，整体可以认为：1）与智甲无关；2）无法验证是U盘的问题。还有哪些因素是能导致两台主机出现同样的问题呢？他提醒我查看一下系统补丁情况，果然相关主机都在15日后更新了如下补丁：

2025-适用于 Windows 11 Version 24H2 的 08 累积更新，适合基于 x64 的系统 (KB5063878) (26100.4946)

几分钟后，他很兴奋的打电话和我说，经过检索KB5063878补丁有问题，网上能找到不少关于补丁更新后会出现磁盘丢失的发帖[1][2][3]。他反馈根据检索的资料推测该故障可能由连续写入数据量≥50GB或硬盘控制器使用率持续>60%触发，系统可能突然无法识别硬盘，重启后短暂恢复但故障反复出现，主要影响无DRAM缓存型号的硬盘，是驱动层死锁等因素导致Windows存储驱动与SSD固件间的NVMe指令序列存在设计冲突。当驱动发送特定组合命令时，固件陷入"等待对方先响应"的死锁状态。

客户发生丢失的硬盘型号为“NVMe KXG70PN84T09 NVMe KIOXIA”，而经过我的检索，其对应的控制器为"KIOXIA Corporation NVMe SSD Controller BG4 (DRAM-less) "，其中"DRAM-less"正表明了该控制器对应的SSD为无DRAM设计。

在微软网站，我没有找到对此提供新的补丁或策略更新，但我查找对应品牌机网站，看到有新的固件。在和客户讨论后，决定先更新固件，再进行观察。如果依然无效，就卸载对应的补丁。

在固件更新后，客户未再出现类似的情况，我于是把这个工作过程记录了下来。

8月20日一早，和智甲团队、测试和IT的同事们进行了讨论总结，最后的结论是，这件事情与智甲还是有关联的，因为客户原有使用的主机杀毒软件，是不带系统补丁更新功能的。客户安装智甲后，就有了统一补丁管理机制，虽然我是根据和用户的策略讨论，整体设定了统一补丁更新策略。但补丁毕竟是通过智甲管理中心分发的，我们应该和客户说明这一点。

智甲团队的负责人大圣立即给客户打了电话，客户对我们的担当表示了高度赞赏。而且表示，经历了前面令人后怕的木马感染事件后，他们觉得安全非常重要，虽然及时打补丁可能会有稳定性问题，但总比被入侵了好。客户还表扬了前面做木马处置的同事和我，我也感到非常欣慰。

但同时我也感到，随着操作系统的日趋复杂，系统安全的风险也日趋复杂。类似这种具有一定概率性的系统故障，安全企业作为提供防御能力的第三方，通过类似补丁稳定性测试，以及灰度补丁策略这种方式，可能也很难及时发现。作为网络安全技术支持工程师，我们不仅要更了解安全威胁对抗，了解自己的产品，也要更了解操作系统和客户的IT环境。

20250819初记

20250820补充更新、校对

（宝刀、箭羽均为化名）