前一个贴子给大家介绍了在内核中借助ALPC消息扫描技术，实现的DNS发起方的探查，很多朋友留言，表达了自己的见解，也提到了ETW技术，这里也算是做个结尾，再来介绍基于ETW技术的“驱动加载方exe回溯”的方法，如果上一个帖子的方案与这个帖子的方案结合，基本上DNS发起方源头探查与SYS加载发起方源头探查就都能覆盖了，当然，也有一些特殊手段实现的SYS加载，像是借壳加载这种，那需要其他的特殊手段（Section对象访问+DriverObject对象访问等）来实现监控了。废话不多说，我们来介绍技术流程。

        在dll/sys的加载中，常规手段上有两种方法（当然还有其他的方法）实现这个过程的感知，一个是通过IMG镜像回调，另一个是通过MF文件过滤器的IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION 这个IRP，这两个方法都能发现镜像加载的过程。对于dll来说，加载宿主的PID就在参数中，但是对于SYS驱动来说，获取到的PID基本就是System（4）这个进程了。但在EDR或者其他安全产品中，我们始终需要想办法找到“发起方”，这个时候通过参数里的信息就不能满足了，需要借助其他辅助信息旁路来获取对应的宿主信息（当然不能说绝对，借助InfinityHook也是可以一步到位的），这里介绍的就是ETW。

        通过ETW是如何拿到这个SYS加载的发起方呢？这里就需要简单介绍一下SYS在应用层常规的加载技术:

1. 应用层加载 SYS 的典型 API 链：应用层加载驱动最常见的方式是把驱动注册成一个“驱动服务”。核心 API 链如下：

API说明：

2.CreateServiceW 写入的服务注册表结构：CreateServiceW 会在 SCM 数据库中创建服务对象。对本机系统而言，服务配置最终落在注册表：

对于驱动服务，常见字段如下：

        当后续调用 StartServiceW 时，用户态传递的是服务名，而不是直接把 SYS 文件交给内核。 SCM 会把服务名解析到上述注册表路径，再构造 Native API 所需的驱动服务路径：

3. 从 Win32 API 到 services.exe：RPC 与 ALPC

    OpenSCManagerW、CreateServiceW、OpenServiceW、StartServiceW 这些 Win32 API 暴露在 advapi32.dll 中。应用程序调用它们时，实际并不会在当前进程内直接执行服务数据库修改和驱动加载。 这些请求会被转换成发往 SCM 服务进程 services.exe 的 RPC 调用。本机场景通常使用本地 RPC 协议序列 ncalrpc。从 Win32 API 视角看，这是 RPC runtime 的内部细节； 从 ETW 视角看，本地 RPC 在现代 Windows 中会落到 LPC/ALPC 通信上，因此可以通过 Kernel ALPC 相关事件观察到.

4.链路拓扑

5.services.exe 内部如何触发 NtLoadDriver

    services.exe 收到 StartServiceW 对应的 SCM RPC 请求后，会检查服务配置。 如果服务类型是 SERVICE_KERNEL_DRIVER 或 SERVICE_FILE_SYSTEM_DRIVER，它不会像普通 Win32 服务那样创建用户态服务进程， 而是进入驱动服务启动路径。

核心动作可以概括为：

    从内核角度看，ZwLoadDriver 的参数不是普通 DOS 文件路径，而是驱动服务注册表路径。 这也是为什么很多驱动加载流程必须先写入 Services 注册表项，随后才能启动。

[内核课程]《Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。