从PAC到权限:深入解析钻石票据与蓝宝石票据的攻击原理与防御
1. Kerberos协议与PAC基础Kerberos作为Windows域环境的核心认证协议其安全性直接关系到整个域架构的稳固性。想象一下Kerberos就像机场的登机系统TGT票证授予票证相当于登机牌PAC特权属性证书则是藏在登机牌里的VIP休息室权限标识。这个看似简单的设计却成为近年来高级攻击的主要突破口。PAC本质上是个数字权限清单记录着用户所属组、特权级别等关键信息。当用户申请服务时服务端会像海关官员一样检查这个清单的真实性。传统检测主要关注票证本身的合法性却忽视了PAC内容可能被调包的风险。我曾遇到过这样的案例攻击者通过篡改PAC中的组标识将普通用户伪装成Domain Admins组成员整个过程就像给假护照贴上真签证。2. 钻石票据攻击深度剖析钻石票据Diamond Ticket之所以得名是因为它像钻石一样兼具高价值和隐蔽性。与传统的黄金票据相比它的独特之处在于整容而非伪造——攻击者获取真实的TGT后只修改其中的PAC部分。这就像拿到真护照后只替换内页的个人信息保留所有官方印章和防伪特征。具体攻击流程分为三个关键阶段密钥获取阶段通过DCSync攻击获取krbtgt账户的AES-256密钥。这个密钥相当于域控制器的印章机我在测试中发现Windows Server 2016后默认启用AES加密反而使这种攻击更容易得手。PAC手术阶段使用Rubeus工具解密原始TGT精细修改PAC中的组标识符。常见手法是将普通用户的RID 513改为域管理员的RID 512就像把经济舱机票偷偷改成头等舱。重加密阶段用原密钥重新加密修改后的TGT保持所有数字签名有效。实测中这种票据能绕过大多数SIEM检测因为票证结构完全合规。防御方面微软建议的补丁KB5008380能有效检测异常PAC修改。我在企业环境中部署时发现配合启用Kerberos ArmoringFAST技术能显著增强检测能力。3. 蓝宝石票据攻击技术解密蓝宝石票据Sapphire Ticket采用了更巧妙的移花接木手法。它不直接修改PAC而是通过Kerberos委派机制借来高权限PAC。这种攻击就像身份窃贼不是伪造证件而是说服官方机构签发真证件。攻击过程主要利用S4U2Self扩展协议# 示例使用Impacket工具生成蓝宝石票据 python ticketer.py -request -impersonate administrator -domain contoso.com -aesKey krbtgt_key -domain-sid SID -user 普通用户这个过程中攻击者先以普通用户身份请求服务票据然后通过约束委派获取目标用户的完整PAC。最近遇到的真实案例显示攻击者会特意选择具有委派权限的服务账户作为跳板这类账户在大型企业平均存在15-20个。蓝宝石票据最危险的特征是它使用完全合法的PAC替换。某次红队演练中我们用它生成的票据甚至通过了Microsoft ATA的深度检测。防御建议包括严格审核具有委派权限的账户启用Kerberos令牌绑定Token Binding监控异常的服务票据请求模式4. 两种攻击的对比分析通过对比测试我们整理出关键差异点特征钻石票据蓝宝石票据PAC来源人工修改原始PAC窃取真实高权限PAC技术要求需要AES-256密钥需要委派权限和服务账户检测难度中等存在签名异常极高所有数据均合法典型使用场景持久化访问权限提升在实际防御中我们发现钻石票据通常会留下以下痕迹TGT有效期异常常设置为10年PAC中的组数量突然增加请求票据的加密类型突变而蓝宝石票据更隐蔽但可能暴露在异常的S4U2Self请求日志同一服务账户短时间内请求多用户PAC委派服务的TGS_REQ频率异常5. 立体防御体系建设基于实战经验我总结出分层的防御方案网络层防护部署网络级Kerberos流量分析工具如Zeek加密类型强制策略拒绝DES/RC4等弱加密关键服务启用通道绑定CBT主机层防护# 强制审计PAC验证事件 auditpol /set /subcategory:Kerberos Service Ticket Operations /success:enable启用LSA保护防止凭据窃取定期轮换krbtgt账户密钥每180天监测层策略建立TGT签发基线检测异常签发模式监控敏感组如Enterprise Admins的PAC变更分析服务票据中的SID历史记录在最近某金融机构的部署案例中这种组合方案成功将Kerberos攻击的检测率从32%提升到89%。特别提醒要定期测试防御措施的有效性——我们开发的PAC验证测试工具能模拟各种攻击场景需要的团队可以私信获取。6. 攻击检测的实战技巧在事件响应中有几个快速判断PAC异常的方法时间戳分析法 正常PAC的AuthTime应早于StartTime而伪造票据常出现时间倒置。使用Rubeus解析票据时要特别注意时间差超过1小时的情况。组清单比对# 使用klist检查当前会话的组信息 klist get ticket /groups对比AD中用户的真实组关系异常情况常见于出现本不应存在的敏感组如Schema Admins组数量突然增加攻击者常添加多个冗余组加密类型检查 突然从RC4转向AES256加密的TGT请求可能预示钻石票据攻击。企业应建立加密类型基线我们开发的KerberosEye工具能自动分析这种异常。最近协助某企业调查的案例中攻击者使用蓝宝石票据后还特意调用了Get-Aduser来验证权限。这种权限检查行为反而成为检测线索通过监控AD查询日志中的异常管理员权限验证我们成功定位到了攻击入口点。