PPL滥用

摘要 Windows 受保护进程轻量级是微软自 Windows 8.1 以来构建的核心安全边界，通过基于数字签名的层级信任模型阻止恶意代码篡改反恶意软件和端点安全产品。本文从 PPL 信任层级架构出发，逐层拆解 ClipUp 提权与 EDR-Freeze 竞态条件的技术原理，将 BYOVD 与 PPL 滥用合二为一的融合攻击链，并讨论跨 PPL 等级的内存转储攻击面及检测盲区。 PPL信任边界 Windows Vista 首次引入了受保护进程模型：进程要么受保护，要么不受保护。该模型过于二元化，无法适应实际安全需求。从 Windows 8.1 开始，微软引入 PPL 扩展了这一概念，引入了保护级别层级，使得某些受保护进程比另一些更受保护，且定义了一个根本性原则：不受保护的进程只能使用受限的访问标志集（如 PROCESS_QUERY_LIMITED_INFORMATION）打开受保护的进程，若请求更高访问权限则返回拒绝访问错误。 对于 PP/PPL 进程而言，其可请求的访问权限取决于自身的保护级别，该级别部分由文件数字证书中的特殊增强密钥使用字段决定。进程创建时，保护信息存入 EPROCESS 内核结构中的特定字段，存储着保护级别（PP 或 PPL）以及签名者类型（如反恶意软件、LSA、WinTcb 等）。 签名者类型在 PP/PPL 之间构建了严格层级： 若 PP 的签名者类型高于或等于目标 PP/PPL，则可以完整访问目标进程 若 PPL 的签名者类型高于或等于目标 PPL，则可以完整访问目标进程 PPL 无法以完整访问权限打开 PP，无论前者使用何种签名者类型 PPL 的签名者类型构成了四条明确的信任等级，每一层都有其典型代表进程和关键特权： 保护层级 签名者类型 典型进程 关键特权 可访问对象 WinTcb-Light…

BYOVD攻击面从漏洞驱动到合法证书的范式转移

摘要 Bring Your Own Vulnerable Driver（BYOVD）在2025-2026年间完成了一次根本性的攻击范式转移：从依赖已知漏洞驱动的黑名单对抗，进化为滥用未被标记、持有有效合法签名的驱动程序。攻击者不再寻找“有漏洞的驱动”，而是将任何具有内核级特权的签名驱动本身视为攻击面。 当签名成为攻击面 Bring Your Own Vulnerable Driver并非新概念，但其内涵在2025-2026年间已发生根本性漂移。传统定义下的BYOVD——攻击者携带一个已知存在漏洞的合法驱动程序，利用其内核级权限执行恶意操作——过于狭隘地聚焦于“漏洞”本身。BYOVD的核心在于“合法签名 + 漏洞”的组合利用——攻击者无需自行开发驱动，而是从公开渠道（如厂商官网、GitHub、驱动仓库）搜集已被微软WHQL签名、但存在任意写（Arbitrary Write）、UAF（Use-After-Free）等漏洞的旧版驱动（例如ASUS、EVGA等硬件厂商历史驱动）。 更精确的表述是：BYOVD攻击滥用了Windows驱动信任模型的一个根本性假设——签名等同于信任。由于这些驱动具备有效证书，即使在启用了Secure Boot和Driver Signature Enforcement的系统中，仍可被加载执行。Windows内核在加载驱动时验证的是数字签名的密码学有效性，而非驱动本身的安全性。这一信任传递的断裂构成了BYOVD的全部理论基础：攻击者不需要绕过签名验证，他们只需要找到一个签了名的驱动，然后滥用其合法功能。 BYOVD攻击正被广泛用于从勒索软件到国家支持间谍活动的各类隐蔽行动，而大多数公共沙箱仅检查用户态活动，导致此类内核级滥用通常无法被检测。 驱动签名验证的技术基础 要理解BYOVD为何如此难以根治，必须从驱动签名验证的底层机制入手。Windows从Vista开始引入的内核模式代码签名（KMCS）策略，要求所有内核驱动必须携带有效数字签名。签名验证的核心链路如下：驱动程序的PE文件经过哈希运算后，该哈希值使用发行者的私钥进行加密。当系统加载驱动时，验证模块首先检查证书是否由受信任的根证书颁发机构（CA）签发，然后验证证书是否在有效期内且未被吊销，最后验证PE文件的当前哈希值与签名中加密的哈希值是否匹配。 然而，签名验证仅限于验证签名本身的密码学有效性——它不验证驱动内部的代码行为是否存在漏洞，也不验证驱动暴露的IOCTL接口是否可以被用户态任意调用。这种“只管签名、不管行为”的信任模型，为BYOVD攻击提供了结构性的可乘之机。一个持有微软WHQL签名的硬件监控工具驱动，在签名验证层面与一个微软自家内核模块享有同等的信任等级。 从已知漏洞到合法证书 范式转移发生在攻击者不再满足于利用那些已被列入微软易受攻击驱动黑名单（Vulnerable Driver Blocklist）的已知驱动之时。2025-2026年，三个关键趋势标志着这一转变的完成： 第一，未知漏洞驱动的武器化。Silver Fox APT利用的WatchDog反恶意软件驱动（amsdk.sys）是一个典型样本——该驱动持有有效微软签名，但此前从未被报告存在漏洞，也未出现在任何公共黑名单中。Check Point Research于2025年8月首次披露了这一攻击活动。 第二，合法证书的独立滥用。HoneyMyte（Mustang Panda）APT组织使用了2015年过期的广州Kingteller Technology被盗证书来签署自己的内核级迷你过滤驱动——攻击者不再是“利用有漏洞的合法驱动”，而是利用被盗或失效的合法证书签署自己编写的恶意驱动。Huntress在2026年2月的一次入侵响应中发现，攻击者滥用了Guidance Software（EnCase）取证驱动的吊销证书——该证书于2010年到期并随后被吊销，但Windows仍然加载了该驱动。 第三，单字节翻转绕过哈希黑名单。这是范式转移中最精致的攻击手法。当WatchDog厂商发布了修复版本（1.1.100）并通过更严格的DACL限制特权提升漏洞后，Silver Fox迅速适应：仅翻转驱动文件中时间戳字段的一个字节，在完整保留微软数字签名的同时改变了文件哈希值，从而绕过了基于哈希的黑名单机制。 这三个趋势共同指向一个结论：攻击者的关注点已从“驱动内部的代码漏洞”转移到“签名信任体系的结构性缺陷”。 驱动签名本身——而非驱动代码中的bug——成为了最大的攻击面。 实验到工业化 双驱动 Check Point Research于2025年8月首次披露了Silver Fox APT组织利用微软签名驱动的大规模攻击活动。该组织自2024年以来已从经济动机的网络犯罪演变为复杂的APT式行动。Silver Fox采用了一种精巧的双驱动策略以覆盖不同Windows版本——在Windows 7系统上使用已知存在漏洞的Zemana驱动，而在Windows 10/11系统上则部署了此前未被报告的WatchDog反恶意软件驱动（amsdk.sys，版本1.0.600）。 为了使用该方法，攻击者需要将漏洞驱动加载到内核。典型方法如下： // 方法一：使用 SC 命令创建并启动内核服务…

SYLK 文件格式的武器化滥用

摘要 在攻击者与防御者的持续军备竞赛中，最新锐的攻击手法总是被紧盯，而最古老的合法功能却常常成为完美的隐匿空间。SYLK 文件格式正是这一规律的最新注脚。 SYLK 诞生于 1980 年代，设计目标是仅使用可显示的 ANSI 字符，让不同应用程序之间能可靠地交换表格数据。它的文件扩展名 .slk 至今仍被 Microsoft Office 默认映射到 Excel，涵盖 2010、2013、2016 乃至更新版本。此前，安全研究员 Matt Nelson 已演示过将 DDE（动态数据交换）攻击与 SYLK 结合的方法，且该方法已被多起真实恶意软件样本所采用。 本文则进一步揭示一个更严重的滥用维度：SYLK 可以直接承载 Excel 4.0/XLM 宏，且这一能力在当前安全生态中几乎未被充分认知和检测。在 VBA 宏已受到层层监视的今天，XLM 宏在 .slk 容器中的复活，为攻击者提供了一条低风险、高成功率的新通道。 SYLK特权 在对攻击面进行任何深入拆解之前，必须首先理解 SYLK 在网络防御体系中的特殊地位——它不是靠漏洞获得特权，而是靠“默认信任”。 受保护视图沙箱的豁免 当文件从互联网或不受信任来源下载时，Windows 会为其附加“网络标记”（Mark of the Web, MotW）。对于常规 Office 文件，这会触发受保护视图沙箱，阻止宏执行并显示醒目的安全警告。然而，SYLK 文件格式并不适用此沙箱。用户双击打开恶意 .slk 文件时，不会看到受保护视图的屏障。 邮件与浏览器网关的通行证 在典型的攻击链中，.slk 文件在传输阶段几乎不被拦截： MS Outlook 阻止附件列表：不包含 .slk。 OWA（Outlook Web Access）默认阻止扩展名列表：同样不包含 .slk。 Chrome…

终端隐形链：OSC 8超链接注入攻击

摘要 终端模拟器是现代开发者和系统管理员的日常入口，但很少有人意识到，那串出现在命令行上的蓝色下划线文字，背后承载的远不止一个 URL。OSC 8 超链接转义序列允许终端在纯文本中嵌入可点击的链接，其设计初衷是增强可用性，却意外为攻击者提供了一个从“只读终端”突破到本地资源执行的低成本跳板。 本文深度解析 OSC 8 协议的底层语法、在 Windows / Linux 终端中的注入向量、file:// URI 的跨平台行为差异，以及各操作系统与终端模拟器层层设限的安全机制。最后，我们将在一个微秒级竞赛的视角下，重新审视这类“非代码执行”攻击面在纵深防御体系中的真实威胁等级。 终端噪声 如果你在 GNOME Terminal 或 Windows Terminal 中执行 ls，忽然看到一行“点击此处领取奖励”，并且鼠标真的可以点，你的第一反应是什么？ 多数人会将此归结为“终端的新奇特性”。但从安全角度看，当终端的输出不再是纯文本，而能够嵌入可点击的交互元素时，终端就从“被动显示设备”升级为了“半主动交互界面”。这意味着，原本只能通过社工诱导用户手动复制粘贴执行的攻击，现在可以简化为一次点击。 这就是 OSC 8 超链接转义序列 所带来的根本性攻击面变化。它不是漏洞，而是协议特性——一个被主流终端广泛支持的、允许向输出流中注入点击行为的公开标准。 OSC 8超链接协议 OSC（Operating System Command）是终端控制序列的一族，由 ESC ]（x1b]）引入。OSC 8 专门用于“超链接”，其完整格式为： ESC ] 8 ; params ; uri ST 或者用 BEL（x07）作为终止符： ESC ] 8 ; params ; uri…

巧妙绕过面部活体检测

摘要 在现有社交媒体的今天，聊天视频是社交的一种手段，而面部活体检测则成为抵御身份欺诈的最后一道屏障。但是，攻击者可以通过虚拟摄像头注入预录视频，绕过面部活体检测的传感器层。 本文深入拆解这一攻击手法的实施方式及其背后的技术逻辑，并探讨对身份验证体系的深层威胁与防御方向。 身份验证 在数字世界里，“证明你是你”是一个根本性的安全命题。主流的身份验证方式可以分为四个递进的层级： 知识因子：密码、PIN码、安全问题。这是成本最低、也最容易被钓鱼和爆破的方式。 持有因子：一次性验证码、硬件令牌。增加了攻击成本，但SIM卡劫持和OTP拦截已相当成熟。 文档因子：身份证、护照、驾照。通过OCR提取信息并与数据库比对，但证件伪造产业已高度工业化。 生物特征因子：人脸、指纹、虹膜、声纹。因为“身体无法被窃取”，被视为最强验证手段。 其中，面部识别因其非接触、低摩擦的特性，成为金融、加密货币交易平台等高风险场景的首选。但它回答的仅仅是“这是对的人吗？”，而一个更前置的问题——“这是真人吗？”——则由面部活体检测来回答。 面部活体检测的本质，是判断摄像头前呈现的到底是一个真实的、有生命的人类，还是一个伪造的呈现物。根据实现方式，它分为两大流派： 类型 机制 优势 劣势 被动活体检测 无需用户配合，通过分析输入图像的纹理、光照、颜色空间等特征判断真伪 用户体验好，快速无感 对输入质量要求高，低光环境等场景表现不佳 主动活体检测 要求用户做出指定动作（转头、眨眼、追踪移动物体等） 难以用预录视频欺骗 体验繁琐，用户容易不耐   然而，这个看似坚固的防御体系，正在面临一种根本性的威胁——攻击者选择直接欺骗传感器本身。 传统呈现攻击 在学术界，对生物识别传感器的攻击被称为“呈现攻击”，常见有三种形态： 2D静态欺骗：将目标的高清照片打印在纸上，或显示在手机、显示器屏幕上，对着摄像头展示。 视频重放攻击：播放预先录制或AI生成的视频，而非静态图像。 3D硅胶面具：制作高仿真的三维面具，物理上覆盖攻击者的面部。 2019年曾发生过一起轰动行业的真实案例：诈骗者使用硅胶面具，通过Skype视频通话冒充法国外交部长，骗取了高达9000万美元的资金。 在这三种方法中，视频重放攻击看似最经济，但存在两个难以克服的技术短板： 一是质量损失。 当预录视频通过显示器屏幕再次被摄像头捕获时，会经历一次“二次采样”——摄像头的CMOS传感器重新捕捉屏幕发出的光线，这个过程必然引入： 颜色空间退化：原始视频的HSV/HSL色彩信息被压缩并二次编码，饱和度与亮度曲线发生偏移； 对焦/模糊损失：显示器的像素网格与摄像头的对焦系统之间产生摩尔纹或柔焦效果； RGB通道失真：屏幕的背光光谱与自然光不同，灰度层次被压缩。 二是显示器物理特征的暴露。 任何显示屏都无法完全隐藏自身的存在： 屏幕表面的眩光和反射； 特定角度的色度偏移； 显示器刷新率导致的频闪（50Hz/60Hz的电网频率残留）。 这些特征正是活体检测系统重点捕捉的异常信号。2019年Black Hat大会上展示的硬件级视频注入方案虽然有效，但基于专用芯片（如TC358749XBG）的搭建成本高、资源消耗大，不具备大规模滥用条件。 这就引出了一个关键问题：能不能绕过“显示器呈现”这个环节，直接把视频信号注入给验证系统？ 虚拟摄像头注入 核心思路极为简洁： 传统攻击：真人视频 → 显示器播放 → 摄像头“看”屏幕 → 验证系统 注入攻击：预录视频…

挖掘注入线程

简介 在红蓝对抗中，进程注入是攻击者维持访问、绕过防御的经典手段。本文通过一个完整的实验——从向 explorer.exe 注入 shellcode 获取反向 Shell，到使用 PowerShell 脚本与 WinDBG 进行交叉检测——逐层揭开线程注入的攻防细节，并深入解析检测工具背后的内存取证逻辑。 注入 首先，我们使用课程中编写的注入器程序，将一段用于反弹 Shell 的 shellcode 注入到 notepad.exe 或 exploer.exe 进程中。选择 explorer.exe 是因为它通常是用户态下长期运行且拥有合法网络连接权限的进程，注入后不易被察觉。 注入器内部会执行以下关键步骤： 打开目标进程：通过 OpenProcess 获取 notepad.exe 的句柄，申请必要的访问权限（如 PROCESS_VM_WRITE、PROCESS_CREATE_THREAD）。 分配内存：在目标进程虚拟地址空间内调用VirtualAllocEx，申请一块可读、可写、可执行（RWX）的内存区域，大小与 shellcode 匹配。 写入 Shellcode：使用WriteProcessMemory将准备好的反弹 Shell 字节码拷贝到新分配的内存中。 启动远程线程：调用CreateRemoteThread或RtlCreateUserThread等 API，让目标进程执行这片内存中的代码。 执行注入器后，我们的受害者主机会立即显示弹窗信息，证明 shellcode 已在 notepad.exe 的上下文中成功运行。 注入检测 攻击发生后，我们切换到蓝队视角，使用开源 PowerShell 脚本 Get-InjectedThreads.ps1（来自 NetSPI）对系统内所有进程的线程进行扫描。 下载地址： https://gist.github.com/jaredcatkinson/23905d34537ce4b5b1818c3e6405c1d2 $a = Get-InjectedThread; $a 脚本遍历当前系统中的每一个进程，并检查其内部的所有线程。很快，我们捕捉到一个异常项： 从输出可以明确看到，notepad…