Nim 的 C-FFI 隐身衣

摘要 Nim 语言凭借其接近 C 的性能与 Python 般简洁的语法，正逐渐成为恶意软件开发者的新宠。其独特的编译期代码执行能力，使得恶意代码可以在编译时读取系统信息、生成仅在特定目标环境中激活的分支，并直接绑定 Win32 API——不依赖 LoadLibrary/GetProcAddress 的动态解析，也不在导入表中暴露敏感函数名。与 Go 的 cgo 和 Rust 的 cc crate 不同，Nim 生成的 C 中间产物在最终二进制中几乎不留痕迹，逆向工程师面对的是一张高度定制的“C-FFI 隐身衣”。 Nim编译管道与C-FFI绑定 Nim 编译器的工作流程 Nim 编译器（nim）并非直接生成机器码，而是默认通过 C 后端生成 C 源代码，再调用系统的 C 编译器（GCC、Clang 或 MSVC）完成最终编译。这一设计的核心优势在于：Nim 程序天然具备与 C 语言相同级别的底层访问能力，同时保留了高级语言的类型安全和元编程能力。 编译流程分为四个阶段： Nim 源码解析与语义分析：编译器将 .nim 文件解析为 AST，进行类型推导和宏展开。 中间表示生成：经过语义检查的 AST 被转换为 Nim 虚拟机指令或直接进入代码生成阶段。 C 代码生成：代码生成器遍历中间表示，输出对应的 C 代码。Windows 下通常输出 .nim.c 文件，包含所有函数的 C 实现和 Nim 运行时支持代码。 C…

PAC 签名无效引发的域信任降级攻击

摘要 Kerberos 票据中的特权属性证书承载着用户的组成员身份和安全标识符，其完整性由 KDC 的长期密钥签名保护。然而，当 PAC 签名验证失败时，Windows 域控制器的默认行为并非一律拒绝，而是在特定配置下（尤其是跨林信任场景中）采取降级策略——忽略 PAC 签名错误，转而使用 Active Directory 中存储的组成员身份重建用户的访问令牌。攻击者可构造 PAC 被篡改或签名缺失的 TGT，利用跨林信任的 SID 过滤与选择性认证盲区，将低权限用户提升为域管理员。 PAC 签名架构与信任边界 PAC 的双签名体系 Kerberos PAC 是微软对标准 Kerberos 协议的扩展，嵌入在 TGT 和 ST 的授权数据字段中。它包含用户的 SID、组成员身份 SID 列表以及用于权限判断的额外信息。为了防止用户或恶意服务篡改 PAC 内容，微软采用了双签名机制： 服务签名：使用目标服务账户的密钥对 PAC 内容进行签名，验证该 PAC 确由 KDC 为该服务签发。 KDC 签名：使用 KDC 自身密钥对 PAC 进行二次签名，提供额外的完整性保障，防止拥有服务密钥的内部人员伪造 PAC。 这两组签名数据存储在 PAC_SIGNATURE_DATA 结构中，分别包含签名类型（如 Kerberos、HMAC_SHA1_96）、签名算法标识符和签名值本身。 PAC 结构及签名位置:…

UBTI的攻击面测绘与 COM 劫持

摘要 Windows 计划任务早已超越“定时执行脚本”的原始范畴。自 Windows 10 1607 引入统一后台任务基础设施（UBTI）后，大量系统与第三方任务被悄然迁移至 COM 组件驱动的新架构，由 taskhostw.exe 进程承载。这一变革在提升可靠性的同时，也将攻击面从 XML 配置文件扩展到了 COM 注册表与 DLL 加载路径。攻击者不再需要写入恶意脚本，而仅需劫持一个计划任务所引用的 COM CLSID，即可将系统原生的合法任务转化为隐蔽的持久化触发器。 UBTI架构 传统计划任务模型 长久以来，Windows 计划任务的核心引擎是 Schedule 服务（schedsvc.dll），运行在 svchost.exe -k netsvcs 共享进程中。任务定义以 XML 格式存储于 C:WindowsSystem32Tasks 目录，管理员通过 schtasks.exe 命令行工具或任务计划程序 MMC 管理单元进行管理。执行时，传统任务启动一个独立的进程（如 cmd.exe /c script.bat），其生命周期完全可见于进程树中。 这种模型简单明了，但也存在明显局限：失败重试机制脆弱、任务隔离性差、对触发条件的响应不够精细。更关键的是，随着 Windows 向“系统即服务”演进，大量后台维护工作（如磁盘整理、系统诊断、Windows 更新后任务）需要更高级的执行容器。 统一后台任务基础设施 Windows 10 版本 1607 引入了统一后台任务基础设施（Unified Background Task Infrastructure，UBTI），作为“后台任务现代化”工程的核心组件。UBTI 并非替换计划任务调度器，而是为其增加了一套全新的执行路径。 在 UBTI 模型下，一个计划任务可以注册为COM 任务——其操作不是启动一个可执行文件，而是实例化一个实现了 ITaskHandler 接口的 COM 组件。该接口定义了两个核心方法： Start：接收任务触发信息，执行任务逻辑。 Stop：接收任务取消请求，执行清理。 任务的实际执行者不再是 cmd.exe 或用户指定的可执行文件，而是 COM 代理进程 taskhostw.exe。该进程以当前用户的会话权限运行（部分系统任务以 SYSTEM…

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）的搭建成本高、资源消耗大，不具备大规模滥用条件。 这就引出了一个关键问题：能不能绕过“显示器呈现”这个环节，直接把视频信号注入给验证系统？ 虚拟摄像头注入 核心思路极为简洁： 传统攻击：真人视频 → 显示器播放 → 摄像头“看”屏幕 → 验证系统 注入攻击：预录视频…

利用TG收集网页钓鱼信息

引言 在不断演变的网络威胁环境中，网络钓鱼攻击早已脱离了粗制滥造的早期形态，演变得愈发隐蔽和精巧。如今的攻击者不仅擅长利用像素级复刻的伪造 HTML 登录页面来攻破用户的心理防线，更在窃取数据的“最后一公里”展现出了极其狡猾的一面——他们正越来越多地将目光投向了 Telegram 等合法的即时通讯平台，将其转化为数据外发的“暗道”。 传统上，黑客往往依赖自建的服务器来接收窃取的账号密码，但这些未知 IP 和域名极易被安全软件标记并拦截。为了在重重防御中隐匿行踪，现代网络钓鱼攻击开始巧妙地“寄生”于受信任的合法服务之上。通过在恶意 HTML 页面中嵌入自动化脚本，攻击者能够将受害者提交的敏感凭证，利用 Telegram Bot API 转化为加密消息，悄无声息地推送到攻击者的手机端。 由于企业防火墙和安全网关通常不会拦截流向 Telegram 的正常 HTTPS 流量，这种“滥用合法通道”的策略使得数据窃取过程如同披上了隐形斗篷，极大地增加了安全团队检测和阻断的难度。 本文将深入探讨这一结合了社会工程学与云服务滥用的威胁模型。我们将揭开“伪造登录页面与 Telegram 数据外传”协同运作背后的逻辑，分析这种攻击方式为何如此难以被传统安全手段察觉，并探讨企业和个人应如何升级防御体系，以抵御这种暗藏杀机的新型钓鱼攻击。 伪造登录页面并集成TG 整个攻击流程的第一步，是向用户展示一个极具迷惑性的虚假登录表单，诱导受害者输入其用户名和密码。当受害者点击“登录”按钮时，真正起作用的并非合法的验证机制，而是潜伏在网页后台的恶意 JavaScript 代码。这些代码会瞬间截获用户输入的敏感数据，随后调用 Telegram Bot API，将窃取到的凭证作为消息，直接且隐蔽地推送到攻击者的 Telegram 聊天窗口中。 为此，我们简单的创建个登录表单： <div class="login-container"> <h2>登 录</h2> <form id="loginForm"> <div class="input-group"> <input type="text" id="username" placeholder="用户名" required> </div> <div class="input-group"> <input type="password" id="password" placeholder="密码" required> </div>…