微软最近的精力主要放在了Win11 22H2年度更新上了，正式版本预计要到明年9月底正式发布，现在已经大量推送。

近年来，微软下大力缓解和修复特定的恶意软件或漏洞，增加了大量的缓解措施，如零初始化池分配（zero-initialized pool allocation）、CET、XFG和最新的CastGuard，攻击者利用漏洞变得越来越困难。最重要的是，通过ETW，特别是威胁情报ETW通道，可以提高对恶意软件和利用技术的可见性。

在23H2预览版本中，微软推出了一个新的ETW事件，这次针对的是NT API，这些API可针对各种可疑行为。Windows 事件跟踪 (ETW) 提供了一种用于检测用户模式应用程序和内核模式驱动程序的机制。Log Analytics 代理用于收集写入到管理和操作 ETW 通道的 Windows 事件。但是，有时需要捕获和分析其他事件，例如写入分析通道的事件。

随着这一新的变化，微软将重点放在几个系统调用上，这些调用通常不应该被许多应用程序使用，但可能会被漏洞利用，例如KASLR绕过、VM检测或物理内存访问。这个新事件所涉及的许多情况都已被限制为特权进程，有些需要为管理员或系统进程保留特权，有些则限制为低IL或不受信任的调用方。但是，试图调用这些系统调用中的任何一个都可能表明存在可疑活动。

到目前为止，EDR检测这类活动的唯一方法是将用户模式挂钩放置在泄漏内核指针的所有不同NtQuery函数中。但实践证明，这并不理想。一段时间以来，微软一直试图让EDR远离用户模式挂钩，主要是通过添加ETW事件，允许EDR通过非侵入性方式使用相同的信息。

为了跟上这一趋势，Windows 11 23H2向威胁情报频道添加了一个新的ETW事件——THREATINT_PROCESS_SYSCALL_USEGE。生成此ETW事件是为了指示非管理员进程对API+信息类进行了API调用，该API调用可能会及时发现某些异常以及潜在的恶意活动。此事件将为两个API中的信息类生成：

这些API有许多信息类，其中许多是“无害的”，并且通常被许多应用程序使用。为了避免发送不感兴趣或无用的信息，以下信息类将生成ETW事件：

包含这些信息类的原因各不相同，有些会泄漏内核地址，有些可用于VM检测，另一些用于硬件持久性，还有一些表示大多数应用程序不应具备的物理内存知识。总的来说，这一新事件包含了应用程序无法正常运行的各种指标。

每一种缓解措施都必须考虑潜在的性能影响，当在频繁调用的代码路径中生成ETW事件时，可能会降低系统的速度。因此，有一些限制适用于此：

1.事件只会为用户模式的非管理员调用者生成。由于Admin->内核不被认为是Windows上的边界，因此许多缓解措施不应用于管理进程，以降低对系统的性能影响。

2.对于每个流程，每个信息类只生成一次事件。这意味着如果NtQuerySystemInformation被一个进程调用10次，并且都使用相同的信息类，那么只会发送一个ETW事件。

3.只有在调用成功时才会发送事件，失败的调用将被忽略，并且不会产生任何事件。

为了支持上述第2个限制并跟踪流程所涉及的信息类，EPROCESS结构中添加了一个新字段：

当一个流程第一次成功调用一个被监控的信息类时，将设置与该信息类对应的位，即使没有为这些流程发送ETW事件，也会发生在管理流程上。ETW事件仅在未设置位时发送，已确保每个类只发送一次事件。虽然没有API来查询这个EPROCESS字段，但它确实有一个很好的副作用，那就是留下每个进程使用哪些信息类的记录——如果你分析一个系统，可以查看这些记录，但前提是在系统中启用了Syscall Usage事件，否则位不会被设置。

目前还没有启用这个事件，也没有人使用它，但我希望看到Windows Defender很快开始使用它，希望其他EDR也能使用。我手动启用了这个事件，以查看这些“可疑的”API是否在常规设备上被使用，使用我的I/O环漏洞作为完整性测试，因为我知道它使用NtQuerySystemInformation泄漏内核指针。以下是正常执行几分钟后的一些结果：

显然，有一些信息类在设备上使用非常频繁，到目前为止主要的是SystemFirmwareTableInformation。这些常见的类可能会在早期被EDR忽略，因此更容易被滥用。

这是否意味着不再有基于API的KASLR绕过，或者所有现有漏洞都会立即被检测到？当然不会。EDR需要一段时间才能开始注册和使用这些事件，特别是因为23H2将在明年秋天的某个时候正式发布，而大多数安全产品可能还需要一两年的时间才能意识到这一事件的存在。由于此事件被发送到只有PPL才能注册的威胁情报频道，因此许多产品根本无法访问此事件或其他与攻击相关的事件。此事件将使EDR能够获取恶意进程进行的一些额外调用的信息，但这只是攻击的其中一步，如果安全产品过于依赖它，无疑会导致许多误报。无论如何，这一事件只涉及一些已知的指标，而其他许多指标则被忽略。

参考及来源：https://windows-internals.com/an-end-to-kaslr-bypasses/