1. 项目概述最近在整理一些内部红队工具库时又翻到了这个挺有意思的玩意儿——CVE-2024-26229-BOF。这是一个将CVE-2024-26229漏洞利用代码封装成Beacon Object FileBOF格式的项目。简单来说它就是一个可以直接在支持BOF的命令与控制C2框架比如Cobalt Strike、Sliver、Havoc等中运行的本地提权模块。其核心是利用Windows CSC客户端缓存驱动中的一个漏洞通过直接内核对象操作DKOM窃取SYSTEM进程的令牌从而让当前进程获得SYSTEM权限。对于做内网渗透测试和红队评估的兄弟来说这种“轻量化”、“无文件落地”的提权工具在特定场景下往往能起到奇效。今天我就结合自己的实操经验把这个项目的原理、用法、坑点以及如何适配不同环境掰开揉碎了跟大家聊聊。2. 漏洞原理与利用链深度解析2.1 CVE-2024-26229漏洞本质这个漏洞的根源在于Windows CSC驱动csc.sys对某个特定IOCTL输入输出控制码的处理存在缺陷。CSC驱动负责“脱机文件”功能也就是我们常说的“脱机文件”或“客户端缓存”。漏洞点在于驱动在处理IOCTL 0x001401a3对应CSC_DEV_FCB_XXX_CONTROL_FILE时对用户传入的输入缓冲区指针缺乏充分的验证。攻击者可以通过NtCreateFile打开一个指向CSC驱动的特殊路径\Device\Mup\;Csc\.\.来获取一个驱动句柄。然后通过这个句柄发送精心构造的IOCTL。关键在于构造的输入缓冲区可以指向内核空间的一个特定偏移地址——当前线程的KTHREAD结构体中的PreviousMode字段之前的一个位置。由于缺乏验证驱动会向这个地址写入数据从而意外地修改了PreviousMode字段。PreviousMode这个字段至关重要它告诉内核当前的操作是来自用户模式UserMode还是内核模式KernelMode。许多内核API如NtReadVirtualMemory、NtWriteVirtualMemory会根据这个标志来决定是否对用户提供的指针进行严格的探针probe和边界检查。通过这个漏洞我们可以将PreviousMode从UserMode1覆写为KernelMode0。注意这里有一个精妙的偏移计算。代码中指向的是KTHREAD-PreviousMode - 0x18。这是因为驱动写入操作可能有一定的结构或对齐要求直接指向PreviousMode字段本身可能无法成功触发内存破坏需要找到一个能通过驱动检查且最终能影响到目标字段的相邻可写地址。这通常是通过逆向分析驱动代码确定的。2.2 DKOM令牌窃取技术一旦PreviousMode被设置为KernelMode当前进程就获得了一种“伪内核”能力。最直接的利用方式就是调用NtWriteVirtualMemory这类函数向内核地址空间任意写入。这个BOF项目采用的策略是经典的DKOM令牌窃取。每个进程在Windows内核中都有一个EPROCESS结构体其中有一个Token成员指向一个_TOKEN结构体它代表了该进程的安全上下文和权限。SYSTEM进程PID 4的令牌拥有最高权限。利用步骤如下定位内核对象首先需要在内核内存中找到当前进程的EPROCESS和SYSTEM进程的EPROCESS。这通常通过遍历进程活动链表或利用一些未导出的内核函数如PsLookupProcessByProcessId的地址来实现。在这个BOF中它可能通过固定的偏移或特定的内存扫描模式来定位。覆写令牌使用获得内核写入能力的NtWriteVirtualMemory将SYSTEM进程EPROCESS中的Token值复制到当前进程EPROCESS的Token位置。权限生效完成覆写后当前进程的安全令牌就变成了SYSTEM令牌立刻拥有系统最高权限。这种方法的优势是“干净”它不创建新的进程、不注入Shellcode到其他进程除非你后续主动操作只是修改了当前进程内核数据结构中的一个指针。2.3 BOF格式的优势与局限Beacon Object File是一种特殊的COFF通用对象文件格式文件它可以直接被C2框架在内存中加载和执行无需在磁盘上生成可执行文件EXE/DLL。这带来了几个好处无文件落地减少了被终端检测与响应EDR基于文件扫描检测的风险。内存执行所有代码逻辑在Beacon进程内存空间内完成行为更贴近合法进程活动。即插即用可以很方便地集成到现有的C2框架中作为一条命令调用。但BOF也有其局限性依赖框架必须在支持BOF API的C2框架中运行。功能受限BOF运行在RDI反射式DLL注入类似的上下文中不能直接调用某些需要特定初始化的Windows API或C运行时库函数通常需要借助框架提供的Beacon API如BeaconPrintf输出、BeaconDataExtract解析参数或使用动态函数解析DFR。单次执行BOF代码执行完毕后其占用的内存通常会被释放不适合需要持久驻留的任务。这个CVE-2024-26229-BOF项目就利用了DFR技术来解析CreateProcessA这样的API使其能在BOF环境中正常使用。3. 环境准备与编译实操3.1 目标系统与依赖检查这个漏洞有特定的适用范围不是在任何Windows电脑上都能成功。操作系统版本主要影响Windows 10 19041至19045版本以及Windows Server 201917763。其他版本的内核结构体偏移可能不同。补丁状态该漏洞已在2024年4月的微软月度安全更新中修复。因此目标系统必须未安装2024年4月及之后的累积安全更新。CSC服务状态漏洞利用需要CSC驱动处于运行状态。在默认的Windows 10工作站上该服务通常是启用的。但在服务器系统上可能默认禁用。检查命令sc query csc查看注册表HKLM\SYSTEM\CurrentControlSet\Services\CSCStart值需要为1自动或2自动延迟启动。在实战中第一步永远是信息收集。通过systeminfo、wmic qfe list查看补丁通过sc query确认服务状态可以快速判断目标是否可能易受攻击。3.2 编译工具链与过程项目源码是C语言需要编译成.o对象文件供C2框架加载。编译环境推荐使用mingw-w64。安装编译环境以Kali Linux或Ubuntu为例sudo apt update sudo apt install mingw-w64 -y获取源码和头文件从GitHub克隆项目或直接下载cve-2024-26229.c和beacon.h。beacon.h是关键它定义了BOF与C2框架交互的API。不同C2框架Cobalt Strike, Sliver, Havoc的beacon.h可能有细微差别务必使用与你C2框架匹配的版本。通常框架的安装目录或开发工具包中会提供。执行编译x86_64-w64-mingw32-gcc -c -o cve-2024-26229.x64.o cve-2024-26229.c这个命令会生成一个64位的对象文件cve-2024-26229.x64.o。-c参数表示只编译不链接因为BOF是对象文件最终的链接由C2框架在内存中完成。实操心得编译时如果遇到beacon.h找不到或者函数未定义的错误大概率是头文件不匹配。确保你的beacon.h来自你正在使用的C2框架。有时直接使用项目自带的头文件可能不行需要替换为框架官方提供的。3.3 内核偏移量的确认与调整这是该利用工具最需要关注的地方。源码中硬编码了两个关键偏移#define OFFSET_EPROCESS_TOKEN 0x4B8 #define OFFSET_KTHREAD_PREVIOUS_MODE 0x232这两个偏移量EPROCESS.Token和KTHREAD.PreviousMode是特定于Windows内核版本构建号的。作者给出的偏移适用于Win10 19041-19045和Server 2019 17763。如果你的目标系统是其他版本比如Win10 1809、21H2等直接使用会导致蓝屏BSOD因为写错了内存位置。如何获取正确偏移离线查询如果你有目标系统版本的内核调试符号ntoskrnl.pdb可以在WinDbg中使用命令dt nt!_EPROCESS Token dt nt!_KTHREAD PreviousMode查看输出中Token和PreviousMode字段相对于结构体起始地址的偏移0x???部分。在线参考一些开源项目如Sysinternals的WinObj原理、或ReactOS源码以及安全社区的漏洞利用代码中经常会整理不同版本的内核偏移。可以多方比对。动态探测高风险在高度可控的测试环境中可以编写一个小型测试程序尝试读取自身进程的_EPROCESS地址例如通过NtQuerySystemInformation的特定信息类然后计算字段偏移。但这需要深厚的底层知识且极易导致系统不稳定。修改源码一旦确定了新偏移需要修改cve-2024-26229.c文件开头的#define值然后重新编译。4. 在C2框架中的集成与使用4.1 Cobalt Strike集成与调用对于Cobalt Strike集成BOF非常简单。放置文件将编译好的cve-2024-26229.x64.o文件放入Cobalt Strike客户端的BOF目录下例如~/cobaltstrike/BOF/。通过Aggressor Script调用你可以编写一个.cna脚本方便调用或者直接在Beacon控制台使用execute-assembly对于.NET工具或inline-execute对于BOF的变体。更常见的是使用bof命令。直接使用bof命令需要提前将.o文件上传到目标beacon upload /path/to/cve-2024-26229.x64.o beacon bof cve-2024-26229.x64.o --path C:\Windows\System32\cmd.exe --args /c whoami C:\temp\out.txt或者在Aggressor Script中封装一个命令alias cve2024 { local($path $args $bof_data); $path C:\\Windows\\System32\\cmd.exe; $args /c whoami; // 按照BOF期望的格式打包参数两个C字符串 $bof_data bof_pack($path . \x00 . $args . \x00); btask($1, Executing CVE-2024-26229 BOF...); // 假设.o文件已位于团队的BOF目录并被同步到Beacon beacon_inline_execute($1, cve-2024-26229.x64.o, $bof_data, go); }然后在Beacon中运行cve2024。4.2 其他框架Sliver/Havoc集成示例Sliver框架对BOF的支持也很友好。通常你需要将.o文件放在服务器的~/sliver-client/bofs/目录下或者通过generate命令链使用。使用bof命令sliver use [beacon-id] sliver (BEACON) bof cve-2024-26229.x64.o --path C:\loader.exe --args --local-shellcodeSliver的bof命令会自动处理参数传递和内存执行。Havoc框架同样支持BOF。你需要将编译好的.o文件放入Havoc团队的data/目录下的相应位置然后在Demon控制台使用bof或inline-execute命令。Demon inline-execute cve-2024-26229.x64.o --path C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe --args -ep bypass -c Get-Process注意事项不同框架的BOF加载器和API实现可能有细微差异。务必查阅你所使用框架的官方文档了解其BOF支持的具体语法、参数打包方式BeaconDataExtract的调用约定以及beacon.h的兼容性。一个在Cobalt Strike上编译的BOF可能需要在Sliver的mingw环境下用Sliver提供的头文件重新编译才能正常工作。4.3 参数详解与实战用例该BOF接受两个参数--path:必需。指定在提权成功后要以SYSTEM权限启动的可执行文件路径。--args:可选。传递给上述可执行文件的命令行参数。为什么要有--path参数因为令牌窃取成功后当前Beacon进程本身已经拥有了SYSTEM令牌。--path参数指定的进程是一个“子进程”它会继承父进程即已提权的Beacon的令牌从而也以SYSTEM身份运行。这个设计提供了灵活性启动新代理可以启动一个新的、以SYSTEM权限运行的Payload如Meterpreter、Cobalt Strike Beacon的execute等建立一个新的高权限会话。执行单次命令可以启动cmd.exe或powershell.exe执行一个命令如添加用户、转储哈希命令执行后子进程退出。作为持久化跳板可以启动一个合法的系统服务或计划任务程序。实战用例直接获取SYSTEM命令行cve-2024-26229 --path C:\Windows\System32\cmd.exe运行后会弹出一个具有SYSTEM权限的cmd.exe窗口如果会话有图形界面。在无界面的C2会话中这通常用于执行后续命令。执行PowerShell命令并获取输出cve-2024-26229 --path C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe --args -ep bypass -c \whoami; hostname\ C:\Temp\result.txt这条命令会以SYSTEM权限运行PowerShell执行whoami和hostname并将结果输出到文件。之后你可以用Beacon的cat或download命令读取结果。注入到稳定进程更隐蔽的方式通常我们不会直接让Beacon进程长期保持SYSTEM权限那样太显眼。更佳实践是 a. 利用此BOF将Beacon提权至SYSTEM。 b. 立即使用psinject或shinject等命令将你的Payload Shellcode注入到一个以SYSTEM运行的稳定进程如lsass.exe,services.exe,svchost.exe中。 c. 然后让原始的Beacon进程退出或降权。这样高权限的持久化访问就转移到了一个更不易被怀疑的系统进程中。5. 操作安全OPSEC考量与规避在红队行动中利用漏洞不是目的不被发现才是关键。使用此类工具时必须考虑OPSEC。5.1 行为特征分析与检测点文件路径访问利用第一步是NtCreateFile打开\Device\Mup\;Csc\.\.。这个路径非常罕见正常的用户态程序几乎不会访问。高级的EDR/ETDR系统如果监控了底层的文件系统调用例如通过ETW的FileIO事件可能会将此视为可疑行为。异常的IOCTL调用向csc.sys驱动发送0x001401a3这个IOCTL码是一个极强的指示器。任何非微软官方组件进行此类调用都极其可疑。Sysmon如果配置了DriverLoad和ProcessAccess事件并关联或内核回调监控可能捕获此行为。直接内核对象修改DKOM修改EPROCESS.Token是典型的恶意内核内存篡改。具备内核态防护能力的解决方案如Windows Defender Credential Guard、受保护的进程、某些EDR的内核驱动可能会检测或阻止此类操作。不过通过篡改PreviousMode来间接实现写入绕过了某些用户态钩子但内核层的内存写操作本身仍可能被监控。进程创建利用成功后通过CreateProcessA创建子进程。这是最常见的监控点Sysmon Event ID 1。子进程的路径、命令行参数、父进程关系从可能权限较低的进程突然生出SYSTEM进程都是分析重点。5.2 规避建议与战术调整路径与IOCTL的伪装几乎无法伪装。这两个是漏洞利用的固有特征。因此这个漏洞利用的核心OPSEC价值在于其“一次性”和“本地性”。它不依赖网络下载、不释放文件到磁盘、不注册服务。攻击窗口短痕迹相对较少。关键在于快速利用快速转移。规避进程创建监控不创建新进程修改BOF代码移除或注释掉CreateProcessA相关的部分。提权成功后Beacon进程自身已是SYSTEM可以直接使用execute、run等C2命令执行操作或者使用psinject注入到已有的SYSTEM进程中。这避免了新的进程创建事件。伪装父进程如果必须创建进程可以考虑使用CreateProcess的CREATE_SUSPENDED标志创建挂起的进程然后通过进程镂空Process Hollowing或模块篡改等技术将目标映像替换为更合法的系统进程如svchost.exe然后再恢复执行。但这会引入更多复杂操作。使用合法的系统工具子进程路径尽量使用系统目录下的合法工具如cmd.exe、powershell.exe、rundll32.exe、regsvr32.exe等。命令行参数也应模仿正常管理行为。清理与恢复该BOF在利用完成后会将PreviousMode恢复为UserMode。这是一个很好的做法避免了因PreviousMode异常而导致后续进程行为异常可能触发检测。确保利用代码的这一部分成功执行。结合环境变量在决定是否使用此漏洞前务必做好侦察。确认目标系统版本、补丁、CSC服务状态都符合条件。盲目尝试可能导致蓝屏造成攻击中断和警报。6. 常见问题排查与实战心得6.1 利用失败原因分析现象可能原因排查方法运行后无任何输出Beacon无反应或断开。1. 目标系统已打补丁2024年4月后。2. CSC驱动未运行或禁用。3. 内核偏移量不正确导致写入错误地址引发蓝屏BSOD。1. 检查系统补丁号wmic qfe get HotFixID。2. 运行sc query csc查看服务状态。3. 在测试环境中用WinDbg双机调试确认偏移或检查系统版本是否在支持列表内。输出类似[]的前几步成功但令牌替换失败或进程创建失败。1. 权限不足需管理员权限运行初始Beacon。2. 防病毒或EDR拦截了内核内存写操作或进程创建。3.--path指定的可执行文件路径不存在或访问被拒绝。1. 确保Beacon是以管理员权限运行的getuid返回高完整性。2. 尝试在禁用实时防护的测试环境中运行。3. 检查路径是否正确特别是转义字符如C:\\Windows\\...。编译失败提示beacon.h相关错误。使用的beacon.h头文件与C2框架不兼容。从你所用的C2框架官方安装包或GitHub仓库中获取正确的beacon.h文件替换。在C2框架中执行BOF时参数传递错误。参数打包格式与BOF代码中的BeaconDataExtract不匹配。查看BOF源码它期望两个C字符串cstr。确保在Aggressor Script或框架命令中参数被打包为两个以空字符结尾的字符串拼接。6.2 进阶技巧与扩展思路自动化偏移获取硬编码偏移是最大的限制。可以尝试在BOF中集成一个简单的“偏移探测”功能。例如通过NtQuerySystemInformation枚举内核模块基址然后解析ntoskrnl.exe的PE头寻找特定导出函数如PsInitialSystemProcess的地址再结合一些特征码搜索来动态计算EPROCESS和KTHREAD结构体的字段偏移。这能极大提升工具的通用性但会显著增加代码复杂度和体积。备用利用路径CVE-2024-26229的本质是获得了任意内核写原语。除了DKOM令牌窃取这个原语还可以做很多事情禁用驱动签名强制DSE修改Ci.dll相关的内核全局变量。清除进程回调移除EDR注册的进程创建回调实现进程隐藏。修补内核函数在内核函数开头打补丁jmp到自己的代码实现更底层的钩子绕过。 你可以基于这个BOF的初始利用部分设置PreviousMode编写新的Payload来实现上述功能。与其它本地提权漏洞结合在实战中一个目标可能打了这个补丁但存在另一个漏洞。维护一个本地提权漏洞工具集是必要的。这个BOF格式轻便非常适合集成到这样的工具集中。后利用阶段的隐蔽成功提权到SYSTEM后应尽快将权限“转移”或“沉淀”。例如立即转储lsass.exe的内存获取凭证或者向一个受信任的、以SYSTEM运行的Windows服务进程如services.exe注入一个后门DLL。然后让当前这个刚刚执行了可疑内核操作的Beacon进程安静退出。这样高权限访问得以维持而明显的攻击进程已消失。这个CVE-2024-26229-BOF项目是一个很好的例子展示了如何将一个复杂的本地提权漏洞封装成适合红队作战的、即插即用的轻量级工具。理解其背后的原理远比单纯会使用命令更重要。在实战中结合精准的情报收集、对目标环境的深入理解以及严格的OPSEC纪律这类工具才能发挥出最大的价值帮助你在网络的攻防对抗中于无声处听惊雷。