真实的 Windows LPE 0 Day：见解和检测策略

本文将使用 Elastic Defend 功能基于动态行为分析来评估 Windows 本地权限提升技术的检测方法。

根据微软、谷歌、卡巴斯基、Checkpoint和其他行业参与者的披露，很明显，Windows 本地权限升级 (LPE) 零日漏洞已成为复杂网络犯罪和 APT 武器库中日益普遍和重要的组成部分。对于检测工程师来说，仔细检查这些可公开访问的样本并评估可能的检测途径非常重要。

本文不会深入探讨漏洞的根本原因或具体细节；但是，我们确实提供了相应漏洞研究文章的链接。我们将使用Elastic Defend功能评估基于动态行为分析的检测方法。

案例1-通用日志文件系统

通用日志文件系统 (CLFS)是一种通用日志记录服务，可供需要高性能事件日志记录的软件客户端使用。Microsoft安全更新指南显示，自 2018 年以来已修补了 30 多个 CLFS 漏洞，其中 5 个漏洞是在 2023 年勒索软件攻击中观察到的。2024 年还以针对同一 CLFS 驱动程序的漏洞报告开始（由几位研究人员提交）。

您可以在此处找到一系列深入研究 CLFS 漏洞利用的优秀文章。这些漏洞利用的一个共同点是它们利用一些clfsw32.dllAPI（CreateLogFile和AddLogContainer）来创建和操作 BLF 日志，从而允许它们写入或损坏内核模式地址。与其他利用原语相结合，这可以导致成功的提升。

根据这些漏洞的具体情况，可以设计高级检测来识别异常进程。例如，以低或中等完整性运行的进程可能会创建 BLF 文件，然后意外地执行系统完整性级别的活动（生成系统子进程、API 调用、文件或使用系统权限进行注册表操作）。

以下 EQL 查询可用于关联 Elastic Defend 文件事件，其中调用堆栈包含用户模式 APICreateLogFile或 的引用AddLogContainerSet，特别是当以普通用户身份运行，然后创建以 SYSTEM 身份运行的子进程时：

sequence with maxspan=5m [file where event.action != "deletion" and not user.id : "S-1-5-18" and   user.id != null and   _arraysearch(process.thread.Ext.call_stack, $entry,                $entry.symbol_info: ("*clfsw32.dll!CreateLogFile*", "*clfsw32.dll!AddLogContainerSet*"))] by process.entity_id [process where event.action == "start" and user.id : "S-1-5-18"] by process.parent.entity_id

以下示例是 CVE-2022-24521 上的匹配，其中cmd.exe以 SYSTEM 启动：

CLFS LPE 漏洞检测

以下 EQL 查询使用与前一个类似的逻辑，但它不是生成子进程，而是在 BLF 文件事件之后查找具有 SYSTEM 权限的 API、文件或注册表活动：

sequence by process.entity_id  [file where event.action != "deletion" and not user.id : "S-1-5-18" and user.id != null and   _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info : ("*clfsw32.dll!CreateLogFile*", "*clfsw32.dll!AddLogContainerSet*"))] [any where event.category : ("file", "registry", "api") and user.id : "S-1-5-18"] until [process where event.action:"end"]

以下屏幕截图与 CLFS 利用提升的权限（使用系统权限删除文件）后的工件清理阶段相匹配：

CLFS LPE 漏洞检测

除了前两个行为检测之外，我们还可以利用 YARA 来寻找导入用户模式 APICreateLogFile或AddLogContainerSet非典型数量函数的未签名 PE 文件clfsw32.dll（普通 CLFS 客户端程序会从同一 DLL 导入更多函数）：

import "pe" 
rule lpe_clfs_strings {    strings:     $s1 = "NtQuerySystemInformation"     $s2 = "clfs.sys" nocase    condition:     uint16(0)==0x5a4d and (pe.imports("clfsw32.dll", "CreateLogFile") or pe.imports("clfsw32.dll", "AddLogContainer")) and all of ($s*)}
rule lpe_clfs_unsigned {    condition:     uint16(0)==0x5a4d and pe.number_of_signatures == 0 and filesize <= 200KB and       (pe.imports("clfsw32.dll", "CreateLogFile") or pe.imports("clfsw32.dll", "AddLogContainer")) and       not (pe.imports("clfsw32.dll", "ReadLogRecord") or pe.imports("clfsw32.dll", "CreateLogMarshallingArea"))}

以下是使用 Elastic 的 YARA 规则对CVE-2023-2825进行 VT 匹配的示例：

CLFS LPE 漏洞检测 CVE-2023-2825 的 YARA 规则匹配

案例 2 – Windows DWM 核心库 EoP

自 Windows Vista 以来，桌面窗口管理器 ( dwm.exe) 一直是 Microsoft Windows 中的合成窗口管理器。该程序启用硬件加速来渲染Windows图形用户界面，并具有较高的权限；然而，低权限的用户可以与DWM进程交互，这显着增加了攻击面。

安全研究员Quan Jin报告了CVE-2023-36033 的野外漏洞利用，Google Project Zero 稍后发布了解释该漏洞利用阶段的详细文章。

根据我们的理解，DWM Core Library ( dwmcore.dll) 漏洞利用很可能会在dwm.exe以 Window ManagerDWM 用户权限运行时触发进程中的 shellcode 执行。请注意，这是高度完整性，但还不是系统。

在 Elastic Defend 上引爆 ITW 公共样本确实会触发自注入 shellcode 警报。如果没有先验知识和上下文，人们可能会将其与通用代码注入警报或误报混淆，因为它是由 Microsoft 可信系统二进制文件发出的自注入警报，具有正常的父进程且未加载恶意库。

以下 KQL 搜索可用于查找类似的 shellcode 警报：

event.code : "shellcode_thread" and process.name : "dwm.exe" and user.name : DWM*

CVE-2023-36033 的 Shellcode 检测警报

dwm.exe除了 shellcode 执行之外，我们还可以通过对子进程和文件活动进行基线检查来查找异常活动。下面，我们可以看到一个由于利用而产生dwm.exe的示例：cmd.exe

cmd.exe由于 LPE 漏洞而 产生 DWM

根据我们的遥测可见性，dwm.exe很少产生合法的子进程。可以通过以下检测来发现异常：

process where event.action == "start" and process.parent.executable : "?:\Windows\system32\dwm.exe" and user.id : ("S-1-5-90-0-*", "S-1-5-18") and process.executable : "?:\*" andnot process.executable : ("?:\Windows\System32\WerFault.exe", "?:\Windows\System32\ISM.exe", "?:\Windows\system32\dwm.exe")

为了进一步将 Window ManagerDWM 用户的权限提升到 SYSTEM，shellcode 将一个 DLL 放入磁盘，并在进程kernelbase!MapViewOfFile内的调用上放置一个 JMP 挂钩dwm.exe。然后它通过执行命令触发注销shutdown /l。

注销操作会触发进程的执行LogonUI.exe，该进程以 SYSTEM 用户身份运行。该LogonUI.exe进程将与桌面窗口管理器进程进行通信，类似于任何桌面 GUI 进程，该进程将编组/取消编组直接组合对象。

MapViewOfFile里面的钩子监视dwm.exe映射的堆内容。当资源堆数据在进程内解组时，它会使用另一组精心设计的小工具来修改它，这些小工具用于执行对LoadLibraryA删除的 DLL 的调用LogonUI.exe。

这里的两个主要检测点发生在dwm.exe将 PE 文件拖放到磁盘时以及LogonUI.exe加载 DLL 时，调用堆栈指向dcomp.dll- 封送/解封直接组合对象的指示符。

dwm.exe下面是一个 KQL 查询，它通过在文件事件和恶意软件警报中将 PE 文件拖放到磁盘来进行查找：

(event.category :"file" or event.code :"malicious_file") and 
process.name :"dwm.exe" and user.id:S-1-5-90-0-* and 
(file.extension :(dll or exe) or file.Ext.header_bytes :4d5a*)

DWM 在利用执行后将反射 DLL 丢弃到磁盘

下面是一个检测EQL 查询，用于查找 LogonUI DLL 加载劫持：

library where process.executable : "?:\Windows\System32\LogonUI.exe" and  user.id : "S-1-5-18" and  not dll.code_signature.status : "trusted" and  process.thread.Ext.call_stack_summary : "*combase.dll|dcomp.dll*"

LogonUI.exe加载被删除的DLLdwm.exe

案例 3 – Windows 激活上下文 EoP

CVE-2022-41073是另一个有趣的野外漏洞。核心漏洞是用户可以C:在模拟过程中为特权进程重新映射根驱动器 ( )。此特定示例通过在客户端服务器运行时子系统 (CSRSS) 中生成激活上下文期间将驱动器重定向到来printfilterpipelinesvc.exe欺骗进程加载任意 DLL 。然后它会伪装成目录，并且非特权用户无法写入。C:C:OneDriveRootC:WindowsWinSxS

从行为角度来看，它属于由系统完整性进程加载 DLL 的类别，而该 DLL 被低/中完整性进程删除。还有一个伪装成合法 Windows WinSxS 文件夹的标记。

以下 EQL 搜索可用于查找伪装成受信任系统文件夹进行重定向的类似尝试：

any where (event.category in ("file", "library") or event.code : "malicious_file") and (  file.path : ("C:\*\Windows\WinSxS\*.dll", "C:\*\Windows\system32\*.dll", "C:\*\Windows\syswow64\*.dll", "C:\*\Windows\assembly\NativeImages*.dll") or 
  dll.path : ("C:\*\Windows\WinSxS\*.dll", "C:\*\Windows\system32\*.dll", "C:\*\Windows\syswow64\*.dll", "C:\*\Windows\assembly\NativeImages*.dll") )

CVE-2022-41073 EoP 尝试伪装成受信任的系统文件夹

这也与此通用端点检测相匹配，该端点检测查找由提升的系统本机进程加载的不受信任的模块：

警报 – 系统 Windows 进程加载不受信任的 DLL

通用行为检测

上面提供的示例说明每个漏洞都具有不同的特征。利用方法根据原语的灵活性而有所不同，例如写入地址、执行 shellcode、加载任意 DLL 或创建文件。某些系统组件可能比其他组件存在更多漏洞，需要专门的检测工作（例如 CLFS、win32k）。

尽管如此，这些漏洞的最终目标和影响仍然是一致的。这强调了设计更有效的检测策略的机会。

权限升级可以表现为多种形式：

• 低/中完整性进程生成提升的子进程

• 低/中完整性进程将代码注入到提升的进程中

• 系统完整性进程意外加载不受信任的 DLL

• 系统本机进程意外删除 PE 文件

• 低/中完整性进程将文件删除到受系统保护的文件夹

• 用户模式进程写入内核模式地址

利用 Elastic Defend 的功能，我们可以设计检测并寻找上述每种可能性。

低/中完整性进程生成提升的子进程：

sequence with maxspan=5m [process where event.action == "start" and  process.Ext.token.integrity_level_name in ("medium", "low")] by process.entity_id [process where event.action == "start" and  process.Ext.token.integrity_level_name == "system" and user.id : "S-1-5-18"] by process.parent.entity_id

利用易受攻击的驱动程序 (Zemana ) 作为SYSTEM生成的样本的匹配示例：zam64.sys cmd.exe

检测异常父子进程完整性级别

低/中完整性进程将代码注入到提升的进程中：

以下是一个ES|QL查询，用于查找罕见的跨进程 API 调用：

from logs-endpoint.events.api*| where process.Ext.token.integrity_level_name in ("medium", "low") and Target.process.Ext.token.integrity_level_name == "system" and process.Ext.api.name in ("WriteProcessMemory", "VirtualProtect", "VirtualAllocEx", "VirtualProtectEx", "QueueUserAPC", "MapViewOfFile", "MapViewOfFileEx")| stats occurrences = count(*), agents = count_distinct(host.id) by process.Ext.api.name, process.executable, Target.process.executable| where agents == 1 and occurrences <= 100

当我们运行此查询时，我们会winlogon.exe通过令牌交换将 LPE 漏洞注入到提升后：

检测从Medium IL到winlogon.exe以SYSTEM运行的跨进程注入

系统完整性进程意外加载不受信任的 DLL

下面是一个 ES|QL 查询，用于查找已由提升的 Microsoft 二进制文件加载的罕见未签名 DLL：

from logs-endpoint.events.library-*| where host.os.family == "windows" and event.action == "load" and  starts_with(process.code_signature.subject_name, "Microsoft") and  user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and  process.code_signature.status == "trusted" and  dll.Ext.relative_file_creation_time <= 500 and  (dll.code_signature.exists == false or dll.code_signature.trusted == false) and
  /* excluding noisy DLL paths */   not dll.path rlike """[C-F]:\Windows\(assembly|WinSxS|SoftwareDistribution|SystemTemp)\.+.dll""" and
 /* excluding noisy processes and potentially unrelated to exploits - svchost must be covered by a dedicated hunt to exclude service dlls and COM */not process.name in ("rundll32.exe", "regsvr32.exe", "powershell.exe", "msiexec.exe", "svchost.exe", "w3wp.exe", "mscorsvw.exe", "OfficeClickToRun.exe", "SetupHost.exe", "UpData.exe", "DismHost.exe")
| stats occurrences = count(*), host_count = count_distinct(host.id) by dll.name, process.name/* loaded once and the couple dll.name process.name are present in one agent across the fleet */| where occurrences == 1 and host_count == 1

LogonUI 通过 dcomp 解组加载恶意 DLL

系统本机进程意外删除 PE 文件

以下 ES|QL 查询可用于寻找特权 Microsoft 签名二进制文件的实例，该二进制文件的可执行文件创建历史记录数量较少，并且仅限于受监控主机群中的一个代理：

from logs-endpoint.events.file-*| where  @timestamp > now() - 30 day| where host.os.family == "windows" and event.category == "file" and event.action == "creation" and user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "S-1-5-90-0-*") and starts_with(file.Ext.header_bytes, "4d5a") and process.code_signature.status == "trusted" and starts_with(process.code_signature.subject_name, "Microsoft") and process.executable rlike """[c-fC-F]:\Windows\(System32|SysWOW64)\[a-zA-Z0-9_]+.exe""" andnot process.name in ("drvinst.exe", "MpSigStub.exe", "cmd.exe")| keep process.executable, host.id| stats occurrences = count(*), agents = count_distinct(host.id) by process.executable| where agents == 1 and occurrences == 1

SYSTEM 进程创建不寻常的 PE 文件

用户模式进程写入内核模式地址

破坏PreviousMode是一种广泛流行的利用技术。覆盖KTHREAD结构中的这一字节会绕过系统调用（例如NtReadVirtualMemory或 ）内的内核模式检查NtWriteVirtualMemory，从而允许用户模式攻击者读取和写入任意内核内存。

在 x64 上，虚拟地址空间分为范围从0x0000000000000000-的用户模式地址和范围从- 的0x0000FFFF FFFFFFFF内核模式地址。以下 EQL 查询可用于检测目标地址为内核模式地址的API或调用，这是一种异常行为：0xFFFF0000 000000000xFFFFFFFF FFFFFFFFNtReadVirtualMemoryNtReadVirtualMemory

api where process.pid != 4 and process.Ext.api.name : "WriteProcessMemory"and process.executable != null and/*  kernel mode address range - decimal */   process.Ext.api.parameters.address > 281474976710655

以下是利用此原语的漏洞触发这些警报的示例：

检测 PreviousMode 滥用

结论

检测特定漏洞的提权需要对漏洞及其利用方法有深入的了解，这不是常识。因此，投资于通用行为检测机制，重点关注对系统的利用影响和常用原语，如KASLR 绕过、令牌交换、PreviousMode 滥用等，事实证明更有效。然而，对于高度针对性的 Windows 系统组件（例如 CLFS 和 win32k），专门的检测始终很有价值 – 最好是行为和 YARA 的组合。

尽管技术复杂且缺乏常见原语的日志，但蓝色团队不应忽视漏洞利用和漏洞研究内容；相反，他们应该努力理解并应用它。此外，通过 VirusTotal 或类似的野外 LPE 漏洞利用样本与防御社区共享将有助于进一步测试和增强检测控制。

可以在此处访问利用权限升级的其他检测规则。

参考

• https://i.blackhat.com/USA-22/Thursday/us-22-Jin-The-Journey-Of-Hunting-ITW-Windows-LPE-0day-wp.pdf

• https://securelist.com/windows-clfs-exploits-ransomware/111560/

• https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part2-exploit-analysis

• https://googleprojectzero.github.io/0days-in-the-wild/rca.html

• https://conference.hitb.org/hitbsecconf2023ams/session/hunting-windows-desktop-window-manager-bugs/

• https://research.checkpoint.com/2024/raspberry-robin-keeps-riding-the-wave-of-endless-1-days/