Splunk 检测到 Windows Modules Installer 服务启动类型发生异常切换

Question

我正在调查我们的安全运营中心（SOC）今早捕获的一连串突发 SIEM 警报。在审查 Splunk 采集的遥测数据时，我注意到有重复的事件表明，Windows Modules Installer Service（Windows 模块安装程序服务）的启动类型正在不规律地来回切换——从“自动”变为“要求（手动）”，然后又恢复为“自动”。

我的团队严格执行手动更新部署策略，我们使用传统的 MBSA 漏洞评估来确立服务器的安全基线，然后直接从 Microsoft Update Catalog（微软更新目录）提取所需的 KB 补丁文件。既然我们为了维持严格的变更控制而故意禁用了后台自动下载，我对这个特定的服务组件为何会修改自身的启动参数感到非常困惑。

是操作系统在执行某种隐藏的补丁自我验证检查从而触发了这种行为，还是有某个完全不同的管理进程在强迫该服务配置反复横跳？

Answer 1

您好，

您观察到的 Windows Modules Installer Service（TrustedInstaller，服务名为 Windows Modules Installer）启动类型在“自动”和“手动”之间来回切换，并不是恶意进程，而是 Windows 自身的维护逻辑。 这个服务的启动类型在注册表路径 HKLM\SYSTEM\CurrentControlSet\Services\TrustedInstaller\Start 中定义，数值会在某些系统操作下被修改。

在 Windows Server 2019 以及 Windows 10/11 的较新版本中，TrustedInstaller 被设计为“按需启动”服务。 操作系统在执行组件存储一致性检查（例如 CBS Servicing、DISM、SFC）或在后台准备更新时，会临时将其启动类型切换为自动，以确保能够立即调用。 完成任务后，系统会恢复为手动。 这个行为在 20H2 之后更为频繁，因为微软在 Servicing Stack Updates（SSU）中引入了更严格的自检机制。

换句话说，您看到的“反复横跳”并不是外部进程强制修改，而是 Windows Servicing 框架自身在执行健康检查时动态调整服务配置。 即便您禁用了自动更新，操作系统仍会周期性地验证组件存储和更新堆栈的完整性，这会触发 TrustedInstaller 的启动类型变化。

如果您要保持严格的变更控制，可以通过组策略或本地策略确保 Windows Update 服务（wuauserv）保持禁用，同时在安全基线中允许 TrustedInstaller 按需启动。 不要尝试强制锁定其启动类型为“禁用”，否则会导致 SFC、DISM、以及手动安装 KB 补丁时失败。 微软官方文档明确指出 TrustedInstaller 是核心服务，必须保持可用。

因此，结论是：这种行为属于系统自检机制的正常现象，而不是隐藏的补丁下载或外部管理进程。 它不会绕过您手动部署补丁的策略，但会继续在后台维护组件存储的健康状态。

多米克配音。