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…

巧妙绕过面部活体检测

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

页面双生

简介 页面双生（Twin Pages）是一种网络钓鱼技术，攻击者通过创建两个相互依赖的网页——主页面和副页面，只有当目标同时打开这两个页面时，副页面才会动态渲染成钓鱼的登录网页。如果主页面或副页面单独打开，则显示正常的页面。页面双生技术利用了目标的浏览习惯和行为模式，使其难以察觉到正在进行的攻击。 构建页面 页面双生技术需要创建两个相互依赖的网页，只有当目标同时打开这两个页面时，副页面才会动态渲染成钓鱼的登录网页。 因此，我们首先需要编写main.html文件作为主页面。 <!DOCTYPE html> <html> <head>     <title>Main Page</title>     <script>         functionmarkMainPageOpen() {             window.name = 'main';             localStorage.setItem('mainPageOpened', 'true');         }         functioncheckTwinPage() {             if (localStorage.getItem('twinPageOpened') === 'true') {…

创建RDP有效负载

前言 随着网络钓鱼技术的不断发展，攻击手段也变得越来越复杂和隐蔽且攻击者已经熟练地利用 Windows 的标准功能来传递恶意负载。虽然这些方法看似巧妙，但实际上存在潜在的操作安全风险。这些技术可能会无意中暴露攻击者的行踪，使防御者能够发现并有效应对。 在现今环境中，尖端的预防技术已成为常态，成功传递恶意负载而不引起警报已成为一门真正的艺术。 而通过 Windows 内部服务配置文件及其注入内容的技术可以很适合的达到这一点。在本篇文章中，我们将以研究 RDP 连接文件为例。要注入RDP有效负载，关键在于如何确保 RDP 连接文件在嵌入内容后仍能正常工作。 文件结构 RDP 连接文件，通常以.rdp结尾，是一种配置文件，用于简化与 Windows 系统的远程桌面连接。这个文件包含多个参数，每个参数都对远程连接的设置和行为起到重要作用。 文件结构的细节可能因RDP客户端版本和配置有些差异，但通常存在以下组件。 screen mode id:i:2：屏幕模式 ID，2 表示全屏模式。 use multimon:i:0：是否使用多显示器，0 表示不使用。 desktopwidth:i:2560：远程桌面的宽度，单位为像素。 desktopheight:i:1440：远程桌面的高度，单位为像素。 session bpp:i:32：会话的颜色深度，32 表示 32 位色。 winposstr:s:0,3,0,0,800,600：窗口位置和大小参数。 compression:i:1：是否启用压缩，1 表示启用。 keyboardhook:i:2：键盘钩子模式，2 表示在远程会话中启用。 audiocapturemode:i:0：音频捕获模式，0 表示禁用。 videoplaybackmode:i:1：视频播放模式，1 表示启用。 connection type:i:7：连接类型，7 表示高质量宽带。 networkautodetect:i:1：是否自动检测网络，1 表示启用。 bandwidthautodetect:i:1：是否自动检测带宽，1 表示启用。 displayconnectionbar:i:1：是否显示连接栏，1 表示启用。 enableworkspacereconnect:i:0：是否启用工作区重新连接，0 表示禁用。 disable wallpaper:i:0：是否禁用壁纸，0…

Redis编写自定义模块

简介 Redis自定义模块允许用户扩展Redis的功能，添加新的命令和数据类型。这种灵活性使得Redis不仅仅是一个键值存储，还可以用于更复杂的应用场景。然而，这也带来了潜在的安全风险，攻击者可能利用这些自定义模块执行恶意命令。下面是关于Redis自定义模块执行命令的介绍和漏洞利用方法。 Redis自定义模块介绍 Redis自定义模块是从Redis 4.0版本开始引入的，允许开发者编写自己的模块并加载到Redis中。模块可以用C语言编写，并编译成动态库（.so文件），然后通过Redis命令加载。 创建模块文件：编写一个简单的C语言文件，例如malicious_module.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include "redismodule.h" int MaliciousCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) { RedisModule_ReplyWithSimpleString(ctx, "Malicious code executed!"); return REDISMODULE_OK; } int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) { if (RedisModule_Init(ctx, "malicious_module", 1, REDISMODULE_APIVER_1) == REDISMODULE_ERR) { return REDISMODULE_ERR; } if (RedisModule_CreateCommand(ctx, "malicious_command", MaliciousCommand, "write", 1, 1,…