Month: June 2026

摘要 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 结构及签名位置:…

摘要 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…