摘要 ARM64 的指针认证通过 PACIA/PACIB 指令为返回地址和函数指针附加密码学签名，阻断了传统 ROP/JOP 攻击。然而，PAC 的密钥分域——指令地址用 A-key，数据地址用 B-key——留下了裂隙。攻击者可以在 JavaScript JIT 编译过程中喷射精心构造的 shellcode，利用 JIT 引擎生成混合了返回指令序列的代码，在指令域签名却在数据域校验，从而绕过 PAC 验证。 ARM64 PAC密钥分域与签名 PAC 指令与密钥 ARMv8.3-A 引入了指针认证（PAC），使用基于 QARMA 的轻量级 MAC 算法为 64 位指针生成认证码，嵌入指针的高位。核心指令： PACIA Xd, Xn：使用指令 A-key 对 Xn 生成签名，存储到 Xd。 PACIB Xd, Xn：使用指令 B-key 对 Xn 签名。 AUTIA Xd, Xn：验证 A-key 签名，若失败则将 Xd 设为无效指针。 AUTIB Xd, Xn：验证 B-key 签名。 A-key 用于指令地址（如返回地址、函数指针），B-key…
摘要 Git Large File Storage 用轻量指针文件替代大文件，再通过 Smudge Filter 在 checkout 时透明下载真实内容。这套机制原本是为了解决版本控制中的大文件管理问题，却在不经意间开辟了一条隐蔽的持久化通道：指针文件仅通过格式校验即可被认定为合法，而 Smudge Filter 在 checkout 时执行的命令完全由仓库内的 .gitattributes 控制。攻击者可以在指针文件通过验证后、实际下载内容完成前的微秒级窗口内，利用竞态条件将恶意载荷替换为“真实”文件，或直接注册一个伪装成 LFS Filter 的恶意 Smudge Filter，在 git clone 的瞬间执行任意命令。 Git LFS信任机制 LFS 指针文件的静态格式 Git LFS 的核心设计理念是“用指针文件替代大文件”。在 Git 仓库中，一个被 LFS 管理的大文件（如 video.mp4）会被替换为如下结构的指针文件： version https://git-lfs.github.com/spec/v1 oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393 size 341283 这个文件仅包含三行文本：版本声明、对象 OID（SHA-256 哈希）、文件原始大小。Git 对 LFS 指针的合法性校验仅基于两点： 第一行匹配version https://git-lfs.github.com/spec/v1。 第二行以oid sha256: 开头，后跟 64 个十六进制字符。 只要满足这两个格式条件，Git 就认为该文件是一个有效的 LFS 指针，并在后续操作中触发…
摘要 Windows 内核中存在一条鲜为人知的“返魂术”——KeUserModeCallback。它是唯一一种从 Ring-0 主动调用 Ring-3 代码的合法设计机制，在 win32k 处理 GUI 请求时被高频使用。该机制通过 PEB 中存储的 KernelCallbackTable 函数指针表实现回调分发——内核以 ApiNumber 为索引调用表中的回调函数，而该表存储在用户态可写内存中。攻击者一旦获取了 KernelCallbackTable 的写入权限，即可劫持回调函数指针，将控制流重定向至恶意 Shellcode。 KeUserModeCallback 机制全解 NT 4.0架构决策 在 Windows NT 4.0 之前，图形子系统完全运行在用户态。NT 4.0 时期，微软将窗口管理器（Window Manager）和设备无关图形接口（GDI）的主体逻辑迁入内核，形成了 win32k.sys 这一内核态图形驱动。这次架构重组引入了一个此前不存在的需求：内核态的 win32k 需要频繁调用用户态的代码——例如执行应用程序注册的钩子函数、发送事件通知、拷贝应用层数据。 常规的系统调用是 Ring-3 → Ring-0 → Ring-3 的单向流程，而这一新需求要求的是 Ring-0 → Ring-3 → Ring-0 的双向流程——内核主动向用户态发起调用，等待用户态代码执行完毕后将结果返回内核。微软为此实现了“反向系统调用”机制，其核心函数就是由 NT 执行体导出的 KeUserModeCallback。 函数原型与执行限制 KeUserModeCallback 的函数原型如下： NTSTATUS KeUserModeCallback(…
摘要 NTFS并非单一真相源。文件创建、修改、访问时间戳同时存在于MFT的$STANDARD_INFORMATION和$FILE_NAME属性中，且更新规则迥异。USN Journal以变更日志形式记录了每一次文件操作的精确时刻与原因码，$LogFile则以事务日志形式保存了更深层的元数据操作序列。攻击者常利用Timestomping技术篡改$SI时间戳以掩盖入侵时间线，但$FN时间戳、USN Record中的USN_REASON_DATA_OVERWRITE事件以及$LogFile中的重做/撤销记录往往被忽略。这三者在微秒级精度上的不一致，恰构成最坚固的证据链。 NTFS文件系统时间戳架构 $STANDARD_INFORMATION与$FILE_NAME NTFS的核心元素是主文件表（MFT），它存储系统中每个文件的条目。MFT中的每个条目包含许多存储文件描述元数据的属性。其中最为关键的两个属性——$STANDARD_INFORMATION（$SI）和$FILE_NAME（$FN）——各自独立存储着文件的MAC(B)时间戳：M（修改时间）、A（访问时间）、C（MFT变更时间）、B（创建时间）。 $SI属性中的时间戳大致与文件内容的交互相关——当你编辑一个文档、更改其权限或写入数据时，$SI时间戳会被更新。$FN属性中的时间戳则大致与文件位置和名称的交互相关——当你重命名文件、移动文件到另一个目录时，$FN时间戳会被更新。 这种设计上的分歧制造了一个天然的取证双轨系统：同一个文件，在不同的元数据属性中可能存储着不同的时间信息。关键点在于，攻击者通常只修改$STANDARD_INFORMATION中的时间，而忽略$FILE_NAME属性中的副本。 严格地说，修改$SI时间戳是一种极为常见的Timestomping方式，因为可以通过用户层面上的API进行操作——包括Cobalt Strike、Timestomp.exe和Metasploit在内的主流攻击工具都内置了此项功能。然而，修改$FN则需要调用内核API或滥用$FN时间戳的生成方式。已知的$FN篡改手段仅有两个：其一，在未引入Patch Guard的旧操作系统上，使用NtSetInformationFile和NtQueryInformationFile直接写入；其二，在任何操作系统上先篡改$SI，然后移动或重命名文件，Windows会自动将修改后的$SI复制到$FN中。 值得注意的是，在取证分析实践中广泛流传着两个误区：一是认为$FILE_NAME中的时间戳永远不会被篡改，二是认为自动化工具生成的时间戳纳秒部分必定为全零。事实上，高级攻击者完全可以通过上述方法同步修改$FN时间戳，部分经过定制化的工具（如Metasploit的timestomp模块）也支持带纳秒精度的时间戳生成。这要求取证分析师必须超越简单的$SI/$FN比对，深入到USN Journal和$LogFile层面进行交叉验证。 在实际攻击事件中，Timestomping的使用已相当普遍。APT28在入侵后的第一时间即篡改了后门文件的时间戳，APT29（Cozy Bear）在SolarWinds事件中大规模使用时间戳篡改以将其恶意DLL混入合法更新包，Lazarus Group更是直接复制calc.exe的时间戳注入到其恶意投放的文件中——这正是Cobalt Strike内置timestomp模块的标准操作方式。 MFT Record的物理结构 要深入理解上述两类时间戳的差异，必须了解MFT记录的物理结构。 每个MFT记录恰好为1024字节（1 KiB）。前42字节包含FileRecordHeader，紧接着是一系列属性的顺序排列。属性序列以类型为0xFFFFFFFF的结束标记终止。 FileRecordHeader的关键字段包括： 字段 类型 偏移 描述 signature [u8; 4] 0x00 总是 b”FILE” usa_offset u16 0x04 更新序列数组偏移 lsn u64 0x08 $LogFile序列号，用于日志关联 sequence_number u16 0x10 每次记录复用递增 attrs_offset u16 0x14 第一个属性的偏移（通常0x30） flags u16 0x16 标志位：0x01=已分配, 0x02=目录,…
摘要 终端模拟器是现代开发者和系统管理员的日常入口，但很少有人意识到，那串出现在命令行上的蓝色下划线文字，背后承载的远不止一个 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…
简介 在信息安全领域，已修复漏洞的再次出现是一个持续存在的挑战。 本文在对 Active Directory 环境中的中继攻击进行深入研究时，发现了一种新型的反射式 Kerberos 中继攻击。自微软发布 MS08-068 补丁以阻止 NTLM 消息被中继回源主机后，类似的反射攻击被认为已得到有效缓解。然而，我们的研究证实，通过将攻击向量从 NTLM 转向 Kerberos，可以绕过这一经典防护机制。 研究表明，若攻击者能强制任意 Windows 主机通过 SMB 向其发起 Kerberos 身份验证，便可截获并中继该主机的计算机账户票证，攻击主机自身的服务，最终利用一个提权漏洞获得 NT AUTHORITYSYSTEM 级别的特权，并实现远程代码执行 (RCE)。 要了解该反射攻击我们首先需要了解 CVE-2025-33073 – 反射型 Kerberos 中继攻击漏洞。 反射型 Kerberos 中继攻击 2025年1月，RedTeam Pentesting 在一次深入研究中，偶然发现了一个潜藏在 Kerberos 认证机制中的严重漏洞——命名为“反射式 Kerberos 中继攻击”，并获得了CVE编号CVE-2025-33073。在将详尽的白皮书提交给微软后，官方已于2025年6月10日发布了修复程序。 攻击的起点非常经典：我们强制一台 Windows 主机通过 SMB 连接到我们的攻击系统，并使用 Kerberos 进行身份验证。按照传统的中继攻击逻辑，当我们把这枚 Kerberos 票证再“反射”回主机自身时，我们本以为最多只能拿到一个普通的计算机账户会话。但一个惊人的结果出现了——我们建立的 SMB 会话，其权限竟然直接跃升至 NT AUTHORITYSYSTEM。这个意料之外的权限提升，将一个看似普通的认证中继，变成了一把能够执行任意命令、完全控制系统的钥匙。…