介绍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位数字，由以下部分组成：
- 版本
- 生命周期：
- 众所周知的，系统中预定义的
- 永久的，在启动会话间持久存在于注册表中
- 持久的，在内存中持久存在，但不跨越启动会话
- 临时的，仅存在于进程上下文中，进程终止时消失
- 范围：系统、会话、用户、进程或物理机器
- 永久数据位
- 唯一序列号
这些属性使用以下位布局组合到状态名称中：
|
|
直到最近，这种机制几乎专用于硬件组件，如电池、麦克风、摄像头和蓝牙，并且对防御工程师的兴趣很小。但随着内核代码完整性管理器最近添加了几个新的状态名称，这种情况开始发生变化，该管理器现在使用WNF来通知系统有关可能对安全工具有用的有趣代码完整性事件。
虽然仍然未公开且不建议一般使用，但可能是时候让防御者开始进一步研究WNF及其潜在好处了。从Windows 10开始，WNF现在提供了几个新增的众所周知的状态名称，这些名称由内核代码完整性管理器（CI.dll）通知。该组件负责所有内核哈希、签名检查和代码完整性策略，这对所有安全产品来说都是丰富的信息。
我们如何找出这些名称？要转储机器上所有众所周知的状态名称，您需要安装Microsoft SDK，然后运行WnfNameDumper来检索perf_nt_c.dll中定义的所有WNF名称，并将它们的人类可读名称、ID和描述转储到文件中，如下所示：
|
|
在Windows版本22H2中，Windows SDK包含超过1,400个众所周知的状态名称。其中许多名称可能具有揭示性，但现在我们将重点关注WNF_CI（代码完整性）名称：
|
|
在这个版本中，我们可以看到五个带有WNF_CI前缀的状态名称，所有这些都由代码完整性管理器生成，并且每个都有一个有用的描述，告诉我们它的用途。与大多数其他WNF名称不同，这里我们看到一些可能对防御工程师有帮助的事件：
- WNF_CI_APPLOCKERFLTR_START_REQUESTED – 表示应启动AppLockerFltr服务
- WNF_CI_BLOCKED_DRIVER – 表示驱动程序已被HVCI（虚拟机监控程序保护的代码完整性）阻止加载，因为它在阻止列表中被发现
- WNF_CI_CODEINTEGRITY_MODE_CHANGE – 表示代码完整性执行模式已发生变化
- WNF_CI_HVCI_IMAGE_INCOMPATIBLE – 表示映像因与HVCI不兼容而被阻止加载，很可能是因为它具有既可写又可执行的区域，或者从可执行非分页池分配内存
- WNF_CI_SMODE_CHANGE – 表示S模式已发生变化
通常，传递到WNF状态名称的缓冲区是一个谜，其内容必须进行逆向工程。但在这种情况下，微软在公共Microsoft符号服务器中公开了传递到其中一个状态名称的数据，通过symchk.exe和symsrv.dll访问：
|
|
我们可以从代码完整性管理器获取一些信息，这些信息可能对EDR产品有用。其中一些信息也可以在Microsoft-Windows-CodeIntegrity ETW（Windows事件追踪）通道中找到，以及其他有趣的事件（值得单独写一篇文章）。尽管如此，这些WNF名称中的一些数据无法在任何其他数据源中找到。
现在，如果我们将SDK版本更新到预览版（在撰写本文时为25336），我们可以看到一些尚未发布到常规版本的其他WNF状态名称：
|
|
在这里，我们看到两个新的状态名称，它们添加了有关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加载很有趣，因为它们可能表明存在利用尝试（或组织试图将其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演讲中详细介绍了它。他们后来发布了一篇博客文章和一组有用的脚本。