黄金票据攻击利用域控krbtgt账户的 NTLM Hash 伪造 Kerberos TGT(Ticket Granting Ticket),从而在域内获取任意权限,甚至长期保持访问权限。由于该攻击能够绕过正常身份认证流程,那么流量层能做到什么力度的检测和效果?
Kerberos中的黄金票据
如果对基本的Kerberos认证流程都不清楚,那么黄金票据的讨论将显得突兀。黄金票据的产生是因为攻击者掌控了1、2号过程的TGT票据生成权限,TGT票据的生成是由域控机器上krbtgt账号的Hash票据加密而生成,如果知道此票据,也就掌握了制作TGT的关键条件。绕过AS的检测,直接进行TGS的获取。
参考常见的KDC示意图
服务名称 |
|
|
|
|
域控制器,与环境内具有最高管理行政权的服务器,通常也由域控担任KDC |
|
keydistributed center (密钥分发中心) |
整个安全认证过程的票据生成管理中心,其中包含AS(认证服务)和TGS(票据生成服务) |
|
accountdatabase (账号数据库) |
存储所有账号的信息,用户名、密码等,Windows域环境下账号数据库在域控中 |
|
authenticationservice (认证服务) |
对客户端身份进行鉴别与生成TGT的服务,由krbtgt用户Hash进行加密生成 |
|
ticketgranting service (票据生成服务) |
为客户端生成服务所需的票据 |
|
ticket-grantingticket (票据生成票据) |
首先从访问目标服务中申请凭证后使用该凭证向AS申请凭证,最终使用AS生成的凭证用于访问目标服务 |
|
ServiceTicket |
服务票据,由TGS进行发布,作为访问域内服务的凭证 |
黄金票据的攻击利用
利用条件
① 伪造的域管理员用户名
② 完整的域名
③ 域 SID
④ krbtgt的 NTLM Hash或AES-256值
利用过程
在黄金票据攻击中,攻击者必须是在获取到krbtgt账号的hash下才能伪造任意票据,因为颁发票据的前提是需要用krbtgt账号的hash才可以制作票据。制作票据之后可直接使用伪造的票据进行服务访问。
通过流量分析检测黄金票据
黄金票据的异常行为主要体现在 Kerberos 认证过程的异常,攻击过程中由于票据已经自己产生,所以与正常认证过程中会缺少认证请求应答与票据请求应答。当需要访问目标服务时会将注入的票据作为凭证提供并校验。可以尝试通过网络流量进行分析和检测。
1. Kerberos完整性识别:
记录AS-REP与TGS-REP后可以获知域内用户在何时申请过票据服务。当其他客户端通过票据请求访问服务端时可以通过检索AS-REP与TGS-REP的方式进行审查是否通过KDC申请并获取过票据,从而判断是否为票据攻击
由于黄金票据的利用涉及多条会话流,且每个流会话中无明显威胁特征;实战中的威胁特征判断时是基于整个KDC身份校验过程是否完整无误;所以单条流量无法判断黄金票据的攻击行为; 需要结合主机日志检测,单独讨论。
2. 识别异常票据时间的 TGT :
正常的KerberosTGT票据默认有效期10小时,最长续期7天
攻击者可能生成一个长期有效的TGT或TGS(如9年到期)
检测策略:
监控AS-REQ和TGS-REQ流量,检查ticket lifetime,基于流量规则对 Kerberos 票据相应包时间字段进行分析。
Suricata检测规则:
alerttcp$DC88->anyany(msg:"KerberosTGT-GTLongTime";content:"|301EA003020105A1|";distance:0;within:8;pcre:"/[x18-x19]x0Dx00x00/";flow:from_server;sid:100001
1.AD域控的响应包流量检测
2.匹配Kerberos 票据的基本结构特征(特征匹配优先级高,可控制正则的性能消耗)
3.正则识别时间字段,并判断时间值。
黄金票据的攻击难以通过单一方法完全检测,所以需要结合主机日志和流量内容才能有效分析(因为单一的规则无法面对庞大的Keberos认证的流量,逐一识别归类每一个认证流量,然后基于场景进行完整性分析,其中间涉及到的延迟、标签、误报判断问题都是显著的阻力。本地日志可结合win系统自身的日志ID进行分析,准确率较高。)
安全防护措施
-
定期重置krbtgt账户密码(最有效的Golden Ticket防御)
-
确保Kerberos认证的完整性,基于互不信任原则,建立非对称加密的通信机制。
-
进行流量+主机日志的安全风险检测
原文始发于微信公众号(安全驾驶舱):【流量安全】黄金票据GT的后门检测
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论