关于BITTER APT是否利用内核零日漏洞实施定向攻击，想必许多读者心中仍有疑问。为此，小编特意整理了相关解析，希望能为各位提供参考。

2020年12月，DBAPPSecurity威胁情报中心截获了BITTER APT组织的最新攻击组件。经深入剖析，我们发现其中潜伏着win32kfull.sys的一个零日漏洞。初始样本主要针对彼时主流的Windows 10 1909 64位系统，但该缺陷同样波及并可能在新版Windows 10 20H2 64位环境中遭滥用。我方已及时向微软MSRC通报该隐患，微软于2021年2月的安全补丁中将其正式修补为CVE-2021-1732。

截至目前，监测到利用该漏洞的实际攻击案例极为稀少，且目标均集中于国内。

时间线

·2020/12/10：DBAPPSecurity威胁情报中心成功捕获BITTER APT新型攻击组件。

·2020/12/15：分析人员在组件中识别出未知的Windows内核漏洞，随即展开根源排查。

·2020/12/29：DBAPPSecurity威胁情报中心正式向MSRC提交漏洞报告。

·2020/12/29：MSRC确认收悉并完成立案登记。

·2020/12/31：MSRC核实该缺陷确认为零日漏洞，要求补充详细资料。

·2020/12/31：DBAPPSecurity按要求向MSRC递交了补充技术细节。

·2021/01/06：MSRC致谢并着手启动漏洞修复流程。

·2021/02/09：微软将该漏洞纳入安全更新，分配编号CVE-2021-1732。

核心特征总结

结合技术分析，此次在野零日漏洞具备以下显著特点：

1、高度聚焦最新版Windows 10系统

1.1、在野样本直接锁定当时的旗舰版本Windows 10 1909 64位（编译日期为2020年5月）。

1.2、原始 exploit 兼容范围较广，覆盖从Win10 1709至1909等多个版本。

1.3、仅需微调即可适配新版Win10 20H2环境。

2、漏洞技术含量极高，利用链条繁琐精密

2.1、原生 exploit 巧妙绕过了KASLR内存布局随机化保护。

2.2、并非传统的UAF类漏洞。整个利用链不依赖堆喷射或内存复用，类型隔离防护机制对此无效。即便开启Driver Verifier内核调试验证，在野样本仍可平稳运行，常规沙盒难以拦截检出。

2.3、任意读取能力依托漏洞点与GetMenuBarInfo API组合实现，设计相当精巧。

2.4、构建好任意读写原语后，exploit 采用“仅数据攻击”手法完成提权，现有内核缓解措施难以防范。

2.5、实战成功率近乎百分之百。

2.6、利用结束后会完整还原关键结构体字段，全程不触发蓝屏死机。

3、攻击手法隐蔽克制

3.1、执行 exploit 前，样本会主动扫描特定杀毒软件进程。

3.2、样本内置系统版本号校验逻辑，若当前构建号低于16535（Win10 1709），则直接放弃调用 exploit。

3.3、该在野样本编制于2020年5月，直至同年12月才被捕获，潜伏期长达数月，侧面印证了其极强的隐蔽性与反检测能力。

深度技术分析

0x00 触发现象

若在终端部署最新版的 Windows 10 1909 64位系统并运行该在野样本，初期可观察到目标进程以中等完整性级别运行。

执行漏洞代码后，进程完整性跃升至系统级。这证实 exploit 通过替换 Token 完成了提权，属于典型的内核越权手法。

而在 Windows 10 20H2 64位环境下直接运行同批样本，则会立刻引发系统蓝屏崩溃。

0x01 漏洞原理

该缺陷源于 win32kfull!xxxCreateWindowEx 函数触发的 xxxClientAllocWindowClassExtraBytes 回调机制。该回调导致内核结构体成员与其对应状态标志发生不同步。

当创建包含 WndExtra 附加数据的窗口时，系统将调用上述回调返回用户态内存地址并存入内核结构体。攻击者可在自定义回调中注入 NtUserConsoleControl 调用，传入当前句柄，从而将内核结构体的成员指针篡改为相对偏移量，并打上标记位。随后通过 NtCallbackReturn 返回伪造值。当回调返回内核态时，返回值会覆盖原有的 offset 字段，但对应的清除标志并未联动重置。此后内核代码若未经验证直接使用偏移量访问堆内存，便会引发越界访问。

0x02 根源剖析

我们对在野 exploit 进行了完整逆向工程，并复原了基础 PoC。下图展示了 PoC 的核心执行流，我们将借此阐明漏洞触发机制。

默认情况下，win32kfull!xxxCreateWindowEx 会调用 user32!_xxxClientAllocWindowClassExtraBytes 为 WndExtra 分配内存，并将返回的用户态指针写入内核结构体。

若在自定回调中植入对 win32kfull!xxxConsoleControl 的调用并传入句柄，WndExtra 成员将被覆写为偏移量，同时标记位 |=0x800 被置位。

PoC 在调用 DestoryWindow 时触发崩溃。此时 win32kfull!xxxFreeWindow 会校验前述标志：若已置位，表明 WndExtra 为偏移量，转而调用 RtlFreeHeap 释放区域；否则视为普通用户态指针，继续调用 xxxClientFreeWindowClassExtraBytes 清理。

在自定回调末尾，Exploit 通过 NtCallbackReturn 返回特定用户态堆地址。回调终结并重返内核时，该返回值直接覆盖 offset 成员，而清除标志未被重置。

PoC 故意返回一个指向用户态堆的假地址（fake_offset），致使后续 win32kfull!xxxFreeWindow 误将其当作内核堆地址传递给 RtlFreeHeap，最终造成越界访问。

● RtlFreeHeap 预期释放的目标实为 RtlHeapBase+offset

● 实际被执行释放的地址却变为了 RtlHeapBase+fake_offset

在此处强行调用 RtlFreeHeap 必然导致 BSOD。

0x03 利用流程

该在野样本为64位架构。初始化阶段，它会先调用 CreateToolhelp32Snapshot 枚举进程，优先搜寻“avp.exe”（卡巴斯基主进程）。

需注意的是，即便检测到该杀软，样本也仅是记录特定参数至自定义结构体，不会中断运行，仍会正常执行后续提权逻辑。实测安装卡巴斯基后运行样本，依然能顺利获取系统权限。

接着程序通过 IsWow64Process 判断运行环境位数，据此修正相关偏移地址。源码注释存在一定歧义，变量命名虽为 g_x64，实则代表 x86 环境标识，但开发者在初始化阶段已硬性将其赋值为 TRUE，因此后续的环境判断调用实际上形同虚设。不过这也暗示厂商可能同步维护过32位分支版本。

完成环境适配后，样本依次解析 RtlGetNtVersionNumbers、NtUserConsoleControl 及 NtCallbackReturn 的模块基址。随后调用版本查询接口比对构建号，仅当 Build > 16535（Win10 1709）时才会激活 exploit 逻辑；若 Build > 18204（Win10 1903），则进一步动态调整部分内核结构偏移。这表明多版本兼容性是后期迭代补充的功能。

环境校验通过后，Exploit 正式接管控制权。它首先通过特征码搜索定位 HmValidateHandle 函数地址，并挂钩 USER32!_xxxClientAllocWindowClassExtraBytes 至恶意回调例程。

紧接着，Exploit 注册两类窗体类：“magicClass”专用于构建漏洞载体窗口；“normalClass”则用于生成常规窗口，后续将配合实现任意地址写入功能。

基于 normalClass 批量创建10个窗口实例后，调用 HmValidateHandle 逐一泄露 tagWND 用户态地址及相对偏移。随后立即销毁末尾8个实例，仅保留窗口0与窗口1。

针对64位环境，Exploit 调用 NtUserConsoleControl 介入窗口1，促使窗口0的 WndExtra 成员转为偏移量格式，并借此提前窃取窗口0的内核 tagWND 偏移备用。

随后利用 magicClass 新建窗口2（携带预设 cbWndExtra 参数）。建窗过程再次激发 xxxClientAllocWindowClassExtraBytes 回调。在恶意例程内，程序校验 cbWndExtra 数值及当前是否为64位环境。双重条件满足后，调用 NtUserConsoleControl 修改窗口2状态并打标记，随后通过 NtCallbackReturn 投递窗口0的内核 tagWND 偏移值。待回调返回内核层，窗口2的 WndExtra 即被篡改为窗口0的 tagWND 偏移，从而实现跨窗口读写控制。

窗口2成型后，Exploit 借由改写其 WndExtra 区域获得操控窗口0内核 tagWND 的原语。期间先通过 SetWindowLongW 进行通路测试。

确认无误后，调用 SetWindowLongW 将窗口0的 cbWndExtra 强行置为 0xfffffff，为其开放越界读写通道。借助该越界写入能力，Exploit 篡改窗口1样式（dwStyle|=WS_CHILD），并利用伪造的 spmenu 替换原对象。

任意读取功能依托伪造 spmenu 联动 GetMenuBarInfo API 达成。程序通过读取 tagMenuBarInfo.rcBar.left 与 .top 字段提取64位数据。此手法此前鲜少公开披露，其设计思路与《Windows 10 Anniversary Update上的LPE漏洞利用》(ZeroNight,2016)一脉相承。

任意写入功能则结合窗口0与窗口1，协同 SetWindowLongPtrA API 完成操作，具体示意如下。

打通双向读写通道后，Exploit 顺藤摸瓜泄漏源 spmemu 中的内核指针，从中剥离出当前进程的 EPROCESS 结构体。

最后，遍历 ActiveProcessLinks 链表定位 SYSTEM EPROCESS 的 Token 及当前进程的 Token 存储区，执行双 Token 互换操作，彻底夺取最高权限。

提权落地后，为避免重启或蓝屏，Exploit 动用任意写入原语全面恢复窗口0、1、2的相关修改项（如窗口1的原始 spmenu、窗口2的状态标志等），整个攻击链路表现极其稳健。

0x04 总结评述

此次暴露的零日缺陷源自 win32k 回调机制设计瑕疵，足以助黑客穿透 Microsoft IE 或 Adobe Reader 等主流应用的沙箱壁垒。该类漏洞工艺精良且利用难度大，其在野部署充分彰显了攻击团伙雄厚的漏洞囤积底蕴。此类威胁实体往往要么吸纳了顶尖研发人才，要么从地下黑市高价购得高阶弹药。

总体来看，零日漏洞在网络攻防体系中占据战略高地，通常作为APT组织的秘密武器，肩负特殊使命与长远布局。伴随软硬件快速更迭与安全防线升级，挖掘并利用底层漏洞的技术门槛与资金成本水涨船高。

多年来，全球厂商在APT防御领域持续重金投入，迫使攻击方在使用零日时更为审慎。为榨取其最大战略价值，这些高危漏洞往往仅投喂给极少数高价值目标。稍露马脚便可能导致生命周期锐减。与此同时，部分漏洞会长期蛰伏才浮出水面，诸如“永恒之蓝”所依托的 MS17-010 便是典型范例。仅2020全年，全球公开曝出的 0Day/1Day 攻击案便多达数十起，其中 DBAPPSecurity 威胁情报中心独立追踪到的就有三例。据现有数据统计研判，2021年浏览器逃逸与权限提升领域的零日曝光量预计将持续走高。

零日检出能力正是APT博弈进程中亟需不断演进的核心环节。除关注终端侧攻势外，边界网络、核心设备及集中管控平台的渗透风险同样不容忽视。近年来的数次安全动荡已敲响警钟。

未曾现网并不意味着绝对安全，更多时候仅是处于暗网潜伏期。应对高级别威胁，需在对抗循环中持续打磨检测与防御体系，多维度筑牢点、线、面立体防护网。网络安全是一场持久战，唯有携手共进方能行稳致远。

如何构筑防御纵深

DBAPPSecurity APT预警平台具备洞察已知隐患与未知威胁的双重实力。系统支持全天候实时捕获、动态分析与处置恶意程序，并能对钓鱼邮件投递、漏洞载荷下发、持久化驻留及C2通讯等各阶段的木马活动实施严密监控。

此外，平台深度融合双向流量审计、AI智能机器学习、高效动态沙盒、海量指纹库及多维检测策略，对网络全量数据进行透视级分析。其防护矩阵完整贯穿APT杀伤链全周期，可精准揪出用户关切的重点威胁、新型变种及整体安全态势异常。

雅拉匹配规则

rule apt_bitter_win32k_0day{

meta:

author="dbappsecurity_lieying_lab"

data="01-01-2021"

strings:

$s1="NtUserConsoleControl" ascii wide

$s2="NtCallbackReturn" ascii wide

$s3="CreateWindowEx" ascii wide

$s4="SetWindowLong" ascii wide

$a1={48 C1 E8 02 48 C1 E9 02 C7 04 8A}

$a2={66 0F 1F 44 00 00 80 3C 01 E8 74 22 FF C2 48 FF C1}

$a3={48 63 05 CC 69 05 00 8B 0D C2 69 05 00 48 C1 E0 20 48 03 C1}

condition:

uint16(0)==0x5a4d and all of($s*) and 1 of($a*)

}

以上就是关于BITTER APT利用内核零日漏洞开展定向攻击的深度解读，感谢大家的阅读与支持，希望本文能为各位的安全防护工作带来切实帮助。

《夸克》非常好用的免费AI浏览器

下载APP查看