回帖：14004C6D0函数负责在注册表驱动/服务项中注册、加载驱动程序，相关注册表操作代码和字符串 如下图所示：https://attach.52pojie.cn/forum/202602/11/174457xfd6dd5gcaa51wzg.pnghttps://attach.52pojie.cn/forum/202602/11/174520g6yg606d66r7yu0u.png

然后，我们回头来看KANG.exe给STProcessMonitor Driver的"\.STProcessMonitorDriver"设备发送的IOCTL 0xB822200C：https://attach.52pojie.cn/forum/202602/11/174526ehs7caw72wyscsax.png我们接下来查看在STProcessMonitor Driver中，IOCTL 0xB822200C对应的功能，对STProcessMonitor Driver进行分析。

STProcessMonitor Driver驱动程序首先检查操作系统版本，如果系统是Windows 8（版本6.2）或更高版本，则设置特定的内存池类型和标志。随后，驱动程序调用IoCreateDevice创建一个名为"DeviceSTProcessMonitorDriver"的设备对象，接着调用IoCreateSymbolicLink建立符号链接"DosDevicesSTProcessMonitorDriver"，这样用户态应用程序就可以通过以上设备对象或链接名称访问该驱动设备。然后是关键IRP： 复制代码 隐藏代码DriverObject->MajorFunction[2] = (PDRIVER_DISPATCH)&sub_140001A10;DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)&sub_140001A10;DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)&sub_140001B70;DriverObject->DriverUnload = (PDRIVER_UNLOAD)sub_1400021F0;

驱动程序设置了关键IRP（I/O请求包）的派遣函数：IRP_MJ_CREATE（0）：处理打开设备的请求。IRP_MJ_CLOSE（2）：处理关闭设备的请求。IRP_MJ_DEVICE_CONTROL（14）：处理设备控制操作（IOCTL），这是用户态与内核态驱动通信的主要方式。同时，设置了DriverUnload例程，以便在驱动卸载时清理资源。如下图所示：https://attach.52pojie.cn/forum/202602/11/174608chzvhlary5oovvyx.pnghttps://attach.52pojie.cn/forum/202602/11/174618atdtotej5oj95eh1.jpg

因此，我们应进入sub_140001B70查看。

在sub_140001B70中，我们看到case 0xB822200C的主要操作为：打开进程/获取进程句柄=>结束进程=>关闭/释放进程句柄，其主要功能为终止、结束进程，如下图所示：https://attach.52pojie.cn/forum/202602/11/174631i78ya3dkw8yyscs6.png

该驱动程序在没有经过目标验证的情况下，将结束进程功能的IOCTL暴露给用户模式，使攻击者能够终止内核模式中的任意进程。在样本发现时，在VirusTotal上该脆弱驱动程序尚未被安全产品标记，截至本文撰稿前被一家安全产品标记，如下图所示：https://attach.52pojie.cn/forum/202602/11/174701k5ipikx5pr55w3dp.pnghttps://attach.52pojie.cn/forum/202602/11/174713dxlld7idpxzidi33.png

来自VirusTotal Relations的信息表明相关驱动至今仍有被分发的迹象，如下图所示：

https://attach.52pojie.cn/forum/202602/11/174830xuvtazi6o95h954t.pnghttps://attach.52pojie.cn/forum/202602/11/174835p4y5oarp56jh6lw6.pnghttps://attach.52pojie.cn/forum/202602/11/174840byykzntki33jikjy.png

本次使用的STProcessMonitor Driver在先前并未使用过。同时，鉴于该驱动在互联网、开源仓库、漏洞数据库中均未找到相关记录，且来自VirusTotal Relations的信息表明相关驱动至今仍有被分发的迹象，即相关驱动目前可能仍在被使用、分发，我们将其提交至CVE漏洞数据库并分配编号CVE-2025-70795。这表明该批银狐行为者可能会在真实世界中主动搜寻和挖掘全新的漏洞驱动。

将KANG.exe与STProcessMonitor Driver的IOCTL 0xB822200C控制码发送过程直观地合影留念，如下图所示：https://attach.52pojie.cn/forum/202602/11/174858f9qoe2j0o2j9eszq.png



D.) StartMenuExperienceHostker.exe



SHA-256: cf111e28e40d20c9695e191c66b11882049c9559d5b4f2ed2090cf4626fdba39我们从StartMenuExperienceHostker.exe的StartAddress函数中观察到其主要实现两个功能：用于启动WUDFCompanionHoste.exe用于释放并加载C:Cndom6.sys驱动，以使用InfinityHook技术实现系统内核API Hook具体如下：i) 用于启动和重启动WUDFCompanionHoste.exe样本首先不断循环遍历进程（的szExeFile），寻找byte_841CD0中的值(即"WUDFCompanionHoste.exe")，获取"WUDFCompanionHoste.exe"进程PID (th32ProcessID为进程PID指针)，如下图所示：https://attach.52pojie.cn/forum/202602/11/174921jv8wy3m4r3zx3itj.png

随后先调用sub_843220(th32ProcessID)，通过SuspendThread(Win32 API)函数挂起其进程中的所有线程（下方还有错误处理未展示：如果线程挂起失败或原本已被挂起，则立即恢复线程原先状态，避免重复挂起），如下图所示：https://attach.52pojie.cn/forum/202602/11/174928ui9gfizbifzwsyi2.png

然后再调用sub_8432F0(th32ProcessID)，通过GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtResumeProcess")方式从ntdll.dll中动态获取NtResumeProcess(NT API)函数，如果成功则调用NtResumeProcess函数恢复其进程中的所有线程，之后再次尝试通过ResumeThread(Win32 API)函数恢复其进程中的所有线程，如下图所示：https://attach.52pojie.cn/forum/202602/11/174939krrbuyjcwrcjkkku.png

完成上述步骤后，将WUDFCompanionHoste.exe文件路径赋给CmdLine，使用WinExec(CmdLine, 0)重新再次启动WUDFCompanionHoste.exe，如下图所示：https://attach.52pojie.cn/forum/202602/11/174948pe0e3l2ooljkk07l.png

ii) 用于释放并加载C:Cndom6.sys驱动，以使用InfinityHook技术实现系统内核API Hook创建驱动/服务项（ServiceName="Cndom6"; BinaryPath="C:Cndom6.sys"）、打开设备"\.Cndom6"，如下图所示：https://attach.52pojie.cn/forum/202602/11/174959hnrn1swprzwrmi6r.pnghttps://attach.52pojie.cn/forum/202602/11/175007g87cgmjbsjvvmnmm.pnghttps://attach.52pojie.cn/forum/202602/11/175015rpenhre5nn60kn5n.png

本地实测，成功复现该加驱行为，如下图所示：https://attach.52pojie.cn/forum/202602/11/175044d8tctzzcvu3tv8jy.jpghttps://attach.52pojie.cn/forum/202602/11/175057prof1w1kp1ai20u1.pnghttps://attach.52pojie.cn/foru