Windows通知设施(WNF)代码完整性深入解析

本文详细介绍了Windows通知设施(WNF)的代码完整性功能,包括WNF状态名称的结构、新添加的代码完整性相关状态名称及其在安全防御中的应用,特别探讨了如何利用WNF调查LSASS保护机制。

介绍Windows通知设施(WNF)的代码完整性

WNF(Windows通知设施)是一种未公开记录的通信机制,支持进程内、进程间或用户模式进程与内核驱动程序之间的通信。类似于ETW(Windows事件追踪)和ALPC(高级本地过程调用)等其他通知机制,WNF通过不同的“通道”进行通信,每个通道代表一个独特的信息提供者或类别。

攻击工程师已经发现了WNF的多种用途。Alex Ionescu和Gabrielle Viala报告了信息泄露和拒绝服务漏洞,这些已被微软修复;@modexpblog演示了通过WNF名称进行代码注入,这几乎不被所有EDR产品检测到;NCC Group的Alex Plaskett展示了攻击者如何利用WNF分配来喷洒内核池。

Windows组件广泛使用WNF来发送或接收关于软件和硬件状态的信息。第三方应用程序也可以以相同的方式使用它来了解系统状态、向Windows进程或驱动程序发送消息,或作为进程或驱动程序之间的内部通信通道(尽管WNF未公开记录,因此并不打算供第三方使用)。

读取和解释WNF状态名称

在WNF世界中,之前提到的“通道”被称为状态名称。WNF状态名称是64位数字,由以下部分组成:

  • 版本
  • 生命周期:
    • 众所周知的,系统中预定义的
    • 永久的,在启动会话间持久保存在注册表中
    • 持久的,在内存中持久保存,但不跨启动会话
    • 临时的,仅在进程上下文中存在,进程终止时消失
  • 范围:系统、会话、用户、进程或物理机器
  • 永久数据位
  • 唯一序列号

这些属性使用以下位布局组合到状态名称中:

1
2
3
4
5
6
7
typedef struct _WNF_STATE_NAME_INTERNAL {
    ULONG64 Version : 4;
    ULONG64 NameLifetime : 2;
    ULONG64 DataScope : 4;
    ULONG64 PermanentData : 1;
    ULONG64 Unique : 53;
} WNF_STATE_NAME_INTERNAL, * PWNF_STATE_NAME_INTERNAL;

直到最近,这种机制几乎专门用于硬件组件,如电池、麦克风、摄像头和蓝牙,对防御工程师的兴趣不大。但随着内核代码完整性管理器最近添加了几个新的状态名称,这种情况开始改变,现在它使用WNF来通知系统有关可能对安全工具有用的代码完整性事件。

虽然仍然未公开记录且不推荐一般使用,但可能是时候让防御者开始进一步研究WNF及其潜在好处了。从Windows 10开始,WNF现在提供了几个新增的众所周知的状态名称,由内核代码完整性管理器(CI.dll)通知。该组件负责所有内核哈希、签名检查和代码完整性策略,这对所有安全产品来说都是丰富的信息。

我们如何找出这些名称?要转储机器上所有众所周知的状态名称,您需要安装Microsoft SDK,然后运行WnfNameDumper来检索perf_nt_c.dll中定义的所有WNF名称,并将它们的人类可读名称、ID和描述转储到文件中,如下所示:

1
2
3
4
{"WNF_CELL_UTK_PROACTIVE_CMD", 0xd8a0b2ea3bcf075},        // UICC toolkit proactive command notification for all slots. SDDL comes from ID_CAP_CELL_WNF_PII        // and UtkService in %SDXROOT%\src\net\Cellcore\packages\Cellcore\Cellcore.pkg.xml
{"WNF_CELL_UTK_SETUP_MENU_SLOT0", 0xd8a0b2ea3bce875},        // UICC toolkit setup menu notification for slot 0. SDDL comes from ID_CAP_CELL_WNF_PII        // and UtkService in %SDXROOT%\src\net\Cellcore\packages\Cellcore\Cellcore.pkg.xml
{"WNF_CELL_UTK_SETUP_MENU_SLOT1", 0xd8a0b2ea3bdd075},        // UICC toolkit setup menu notification for slot 1. SDDL comes from ID_CAP_CELL_WNF_PII        // and UtkService in %SDXROOT%\src\net\Cellcore\packages\Cellcore\Cellcore.pkg.xml
etc., etc., etc

在Windows版本22H2中,Windows SDK包含超过1,400个众所周知的状态名称。其中许多名称可能具有揭示性,但现在我们将专注于WNF_CI(代码完整性)名称:

1
2
3
4
5
{"WNF_CI_APPLOCKERFLTR_START_REQUESTED", 0x41c6072ea3bc2875},        // This event signals that AppLockerFltr service should start.
{"WNF_CI_BLOCKED_DRIVER", 0x41c6072ea3bc1875},        // This event signals that an image has been blocked from loading by PNP
{"WNF_CI_CODEINTEGRITY_MODE_CHANGE", 0x41c6072ea3bc2075},        // This event signals that change of CodeIntegrity enforcement mode has occurred.
{"WNF_CI_HVCI_IMAGE_INCOMPATIBLE", 0x41c6072ea3bc1075},        // This event signals that an image has been blocked from loading as it is incompatible with HVCI.
{"WNF_CI_SMODE_CHANGE", 0x41c6072ea3bc0875},        // This event signals that change of S mode has occurred.

在这个版本中,我们可以看到五个带有WNF_CI前缀的状态名称,全部由代码完整性管理器生成,每个都有一个有用的描述告诉我们它的用途。与大多数其他WNF名称不同,这里我们看到一些可能对防御工程师有帮助的事件:

  • WNF_CI_APPLOCKERFLTR_START_REQUESTED – 表示AppLockerFltr服务应该启动
  • WNF_CI_BLOCKED_DRIVER – 表示一个驱动程序因在阻止列表中被发现而被HVCI(Hypervisor保护的代码完整性)阻止加载
  • WNF_CI_CODEINTEGRITY_MODE_CHANGE – 表示代码完整性执行模式发生了变化
  • WNF_CI_HVCI_IMAGE_INCOMPATIBLE – 表示一个映像因与HVCI不兼容而被阻止加载,很可能是因为它有既可写又可执行的区域,或从可执行非分页池分配内存
  • WNF_CI_SMODE_CHANGE – 表示S模式发生了变化

通常,传递给WNF状态名称的缓冲区是一个谜,其内容必须通过逆向工程来解析。但在这种情况下,微软通过公共Microsoft符号服务器公开了传递给其中一个状态名称的数据,可通过symchk.exe和symsrv.dll访问:

1
2
3
4
5
6
7
typedef struct _WNF_CI_BLOCKED_DRIVER_CONTEXT
{
  /* 0x0000 */ struct _GUID Guid;
  /* 0x0010 */ unsigned long Policy;
  /* 0x0014 */ unsigned short ImagePathLength;
  /* 0x0016 */ wchar_t ImagePath[1];
} WNF_CI_BLOCKED_DRIVER_CONTEXT, *PWNF_CI_BLOCKED_DRIVER_CONTEXT;

我们可以从代码完整性管理器获取一些信息,这可能对EDR产品有用。其中一些信息也可以在Microsoft-Windows-CodeIntegrity ETW(Windows事件追踪)通道中找到,以及其他有趣的事件(值得单独写一篇文章)。尽管如此,这些WNF名称中的一些数据无法在任何其他数据源中找到。

现在,如果我们将SDK版本更新到预览版本(撰写本文时为25336),我们可以看到一些尚未发布到常规版本的其他WNF状态名称:

1
2
3
4
5
6
7
{"WNF_CI_APPLOCKERFLTR_START_REQUESTED", 0x41c6072ea3bc2875},        // This event signals that AppLockerFltr service should start.
{"WNF_CI_BLOCKED_DRIVER", 0x41c6072ea3bc1875},        // This event signals that an image has been blocked from loading by PNP
{"WNF_CI_CODEINTEGRITY_MODE_CHANGE", 0x41c6072ea3bc2075},        // This event signals that change of CodeIntegrity enforcement mode has occurred.
{"WNF_CI_HVCI_IMAGE_INCOMPATIBLE", 0x41c6072ea3bc1075},        // This event signals that an image has been blocked from loading as it is incompatible with HVCI.
{"WNF_CI_LSAPPL_DLL_LOAD_FAILURE", 0x41c6072ea3bc3075},        // This event signals that a dll has been blocked from loading as it is incompatible with LSA running        // as a protected process.
{"WNF_CI_LSAPPL_DLL_LOAD_FAILURE_AUDIT_MODE", 0x41c6072ea3bc3875},        // This event signals that an unsigned dll load was noticed during LSA PPL audit mode.
{"WNF_CI_SMODE_CHANGE", 0x41c6072ea3bc0875},        // This event signals that change of S mode has occurred.

在这里,我们看到两个新的状态名称,它们添加了关于与PPL不兼容的DLL被加载到本地安全机构子系统服务(LSASS)中的信息。LSASS是操作系统身份验证管理器,作为PPL(受保护进程轻量级)运行。这确保了进程不被篡改,并且只运行使用正确签名级别签名的代码。

使用WNF调查LSASS保护

微软一直试图让LSASS作为PPL运行。但由于与需要完全访问LSASS的产品的兼容性问题,包括注入不同的插件,它无法完全启用。然而,他们试图尽可能保护LSASS免受像Mimikatz这样的凭据窃取者的攻击,同时仍然允许用户选择将LSASS转回常规进程。

自Windows 8.1以来,有一个选项可以在审计模式下将LSASS作为PPL运行。这意味着系统仍然将其视为正常进程,但会记录任何在作为PPL运行时会被阻止的操作。在Windows 11中,它默认作为常规PPL运行,有一个选项通过注册表和安全中心(在预览版本中)在审计模式下运行它。

这就是我们两个新状态名称的用武之地:

  • WNF_CI_LSAPPL_DLL_LOAD_FAILURE在LSASS作为常规PPL运行时被通知,并且一个未根据PPL要求签名的DLL被阻止加载到进程中。
  • WNF_CI_LSAPPL_DLL_LOAD_FAILURE_AUDIT_MODE在LSASS在审计模式下作为PPL运行并加载一个在作为正常PPL运行时会被阻止的DLL时被通知。

端点检测与响应(EDR)工具可以通过一个已记录的内核回调来警报所有DLL加载。映像加载通知例程确实包括缓存的签名信息在IMAGE_INFO中的ImageSignatureLevel和ImageSignatureType字段中,然而这些信息可能并不总是可用,并且回调不会通知被阻止的DLL加载。被阻止的DLL加载很有趣,因为它们可能指示 exploitation尝试(或组织试图将其2003年编写的插件加载到LSASS中)。

因此,虽然这些新状态名称都不包含任何对EDR特别有趣的信息,但它们确实有一些安全产品可能觉得有用的有趣数据,并且至少可以增加一些可见性或节省EDR的一些工作。

当然,已经有一些用户使用这些WNF_CI状态名称:Windows Defender命令行工具MpCmdRun.exe。MpSvc.dll是加载到MpCmdRun.exe中的DLL之一,订阅了两个WNF状态名称:WNF_CI_CODEINTEGRITY_MODE_CHANGE和WNF_CI_SMODE_CHANGE。每当它们被通知时,DLL查询它们以获取新值并相应地更新其内部配置。

系统的其他部分也订阅这些状态名称。我使用WinDbg命令从自己的系统中提取了这个列表:

  • DcomLaunch服务注册到WNF_CI_SMODE_CHANGE、WNF_CI_BLOCKED_DRIVER和WNF_CI_APPLOCKERFLTR_START_REQUESTED
  • Utcsvc服务(通过utcsvc.dll)注册到WNF_CI_SMODE_CHANGE
  • SecurityHealthService.exe注册到WNF_CI_SMODE_CHANGE
  • Msteams.exe注册到WNF_CI_SMODE_CHANGE
  • PcaSvc服务(通过PcaSvc.dll)注册到WNF_CI_HVCI_IMAGE_INCOMPATIBLE和WNF_CI_BLOCKED_DRIVER – 这是负责在您喜欢的易受攻击驱动程序在启用HVCI的系统上无法加载时显示弹出消息的服务。

目前,没有进程订阅新的LSA(本地安全机构)状态名称(WNF_CI_LSAPPL_DLL_LOAD_FAILURE和WNF_CI_LSAPPL_DLL_LOAD_FAILURE_AUDIT_MODE),但由于这些仍处于预览阶段,这并不令人惊讶,我相信我们将来会看到一些订阅。

探索新WNF信息的可能性

Windows通过WNF中新获得的信息赋予了安全爱好者在攻击和防御两方面的能力。通过扩展历史范围并向WNF添加状态名称,研究人员对事物如何运作有了更透明的视图。随着时间的推移,您很可能会看到安全研究人员将这些信息与其他事件和进程相关联,以展示新颖的安全研究!

在这里,我们快速介绍了WNF及其新功能,以及一个简单的示例,说明如何使用它来调查LSASS。如果您对WNF内部及其攻击能力的更多细节感兴趣,Alex Ionescu和Gabrielle Viala在BlackHat 2018演讲中详细介绍了它。他们后来发布了一篇博客文章和一系列有用的脚本。

如果您喜欢这篇文章,请分享: Twitter LinkedIn GitHub Mastodon Hacker News

页面内容 读取和解释WNF状态名称 使用WNF调查LSASS保护 探索新WNF信息的可能性 最近的帖子 构建安全消息传递很难:对Bitchat安全辩论的 nuanced 看法 使用Deptective调查您的依赖项 系好安全带,Buttercup,AIxCC的评分回合正在进行中! 使您的智能合约超越私钥风险 Go解析器中意想不到的安全 footguns © 2025 Trail of Bits。 使用Hugo和Mainroad主题生成。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计