.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
最近James Forshaw發表的關於Kerberos中繼的博客推翻了以前不能中繼Kerberos的結論。其中介紹了一些技巧，可以將Windows身份驗證轉換為不同的服務主體名(Service Principal Name, SPN)，而不是通常從客戶機連接的主機名派生出來的服務主體名，這意味著Kerberos並非如我所設想的那樣是完全可靠的。這促使我去尋找一些其他的濫用途徑，包括我在幾年前研究過但從未付諸實踐的做法——中繼DNS認證。當你能夠使用mitm6通過DHCPv6欺騙來欺騙DNS服務器時，這一點尤其重要。在這個場景中，你可以使用Kerberos和它們的設備帳戶對受害設備進行可靠的身份驗證。這種身份驗證可以中繼到任何不強制執行完整性的服務，例如Active Directory證書服務(AD CS)基於http(s)的註冊，這反過來使它可以在該主機上以SYSTEM的形式執行代碼，正如我在AD CS中繼的博客中討論的那樣。與用mitm6中繼WPAD身份驗證相比，這種技術更快、更可靠、侵入性更小，但當然需要使用AD CS。這個博客描述了這項技術的背景，以及我對krbrelayx所做的更改，以便這次能夠支持真實的Kerberos中繼。
基於DNS 的Kerberos如果你熟悉Kerberos，就會知道DNS是擁有一個工作的Kerberos基礎設施的關鍵組件。但是你知道Active Directory中的DNS也支持使用Kerberos通過DNS進行身份驗證的操作嗎?這是“安全動態更新”操作的一部分，該操作用於保持動態地址的網絡客戶端的DNS記錄與其當前IP地址同步。下圖顯示了動態更新過程中涉及的步驟：
步驟如下（按照上面的數據包從上到下）。在此交換中，客戶端是Windows 10 工作站，服務器是一個具有DNS角色的域控制器。
客戶機在起始授權機構(SOA)記錄中查詢它的名稱，這表明客戶機所在的域的哪個服務器是授權的。
服務器響應授權的DNS服務器，在本例中是DC icorp-dc.internal.corp。
客戶端嘗試在區域internal.corp 中使用其名稱對A 記錄進行動態更新。
這個動態更新被服務器拒絕，因為沒有提供身份驗證。
客戶端使用TKEY 查詢來協商經過身份驗證的查詢的密鑰。
服務器以TKEY 資源記錄作為回复，完成身份驗證。
客戶端再次發送動態更新，但現在伴隨著TSIG記錄，這是使用步驟5和6中建立的密鑰的簽名。
服務器確認動態更新，新的DNS記錄現在已經就位。
讓我們仔細看看步驟5和步驟6，TKEY查詢實際上是通過TCP發送的，因為它比UDP允許的最大512字節大很多。這主要是因為TKEY的附加記錄相當大，它包含了我們經常看到的Kerberos認證結構：
事實證明，此查詢包含完整的GSSAPI 和SPNEGO 結構，其中包含Kerberos AP-REQ。這本質上是對服務的正常Kerberos 身份驗證流程。回复再次包含一個GSSAPI 和SPNEGO 結構，指示認證成功，並使用AP-REP 回复。這個AP-REP包含一個新的會話密鑰，客戶端可以使用它來通過TSIG記錄對他們的DNS查詢簽名。請注意，encAPRepPart通常是用只有客戶機和服務器知道的會話密鑰加密的，但是因為我將測試域中各種系統的Kerberos密鑰加載到Wireshark接受的keytab中，所以我們可以對整個交換進行解密，以查看它包含什麼內容。
此流程的概念相當簡單（實際的實現並不簡單）。客戶機使用Kerberos進行身份驗證並安全地交換會話密鑰，然後使用該會話密鑰對進一步的更新查詢進行簽名。服務器可以存儲密鑰和經過身份驗證的用戶/計算機，並以一種經過身份驗證的方式處理更新，而不必將身份驗證綁定到特定的TCP套接字，因為稍後的查詢可能通過UDP發送。
濫用DNS身份驗證如果我們能夠攔截DNS查詢，那麼就有可能欺騙受害客戶端，讓其向我們發送真實DNS服務器的Kerberos票據。這種攔截可以在默認的Windows配置中由同一(V)LAN中的任何系統使用mitm6完成。 mitm6將自己宣傳為DNS服務器，這意味著受害者將把SOA發送到我們的假服務器，如果我們拒絕它們的動態更新，則使用Kerberos進行身份驗證。這就有點棘手了。通常，DNS服務器角色將在域控制器上運行。因此，DNS服務的服務票據已經適合於運行在DC上的服務，因為它們使用相同的帳戶，我們可以在票據中更改服務名稱。這意味著我們可以將此票據中繼到例如LDAP。然而，如果我們仔細查看TKEY查詢中的驗證器，我們會看到請求完整性（簽名）的標誌被設置了。
這將自動觸發LDAP簽名，這將使整個攻擊失敗，因為如果不對每條消息提供有效的加密簽名，我們就不能在之後與LDAP交互。我們無法生成此簽名，因為我們中繼了身份驗證，並且實際上並不擁有解密服務票據和提取會話密鑰所需的Kerberos密鑰。
這最初讓我碰壁有兩個原因：
當時，沒有任何已知的默認高值服務可以接受設置了完整性標誌的身份驗證，但不會在協議級別上強制它。
客戶端專門請求他們在其Kerberos 票證請求中使用的SPN 中的“dns”服務類。此SPN 僅在實際的DNS 服務器上設置，因此要中繼到的合法主機的數量非常少。
在閱讀了James的博客後，我重新審視了這個問題：
由於AD CS研究由Lee Christensen和Will Schroeder發表，我們在大多數AD環境中都有一個高價值的端口，並提供了在受害者身上執行代碼的可能性，正如我在上一篇關於AD CS中繼的博客中所描述的那樣。
正如James在他的博客中所描述的，許多服務類實際上會隱式地映射到HOST類。事實證明，這包括DNS，因此當受害者請求DNS服務的票據時，這實際上適用於任何帶有HOST SPN的帳戶。默認情況下，這是在域中的所有計算機帳戶上設置的，因此可以針對在這些帳戶下運行的任何服務。
解決了這兩個問題後，我們就可以將在偽DNS服務器上接收到的Kerberos身份驗證轉發到AD CS。當這一切完成後，我們可以為我們中繼的計算機帳戶請求證書，並使用NT哈希恢復技術或S4U2Self技巧。使用這些技術，我們可以獲得對受害計算機的SYSTEM訪問權限，只要AD CS http端口可用來中繼，這就有效地使其成為可靠的RCE。
對krbrelayx 和mitm6 的更改最初，krbrelayx並不是一種真正的中繼工具。相反，它通過使用不受約束的委託配置(系統)帳戶來捕獲Kerberos tgt，並且以與ntlmrelayx相同的方式使用這些tgt可以使用傳入NTLM身份驗證。由於現在有一個實際中轉Kerberos身份驗證的用例，所以我更新了krbrelayx中的功能，使其能夠在中轉模式而不是不受約束的委託模式下運行。如果你不指定任何NT哈希值或AES密鑰(這些密鑰可用於從傳入的Kerberos身份驗證中提取信息)，那麼它實際上將默認使用這種模式。簡而言之，現在可以使用krbrelayx中繼Kerberos身份驗證，儘管只支持中繼到HTTP和LDAP。至於mitm6，我已經添加了指定中繼目標的選項，當受害者詢問查詢SOA記錄時，該目標將是授權命名服務器響應中的主機名。這將使受害者為我們的目標服務而不是合法的DNS服務器請求Kerberos服務票據。
需要注意的一點是，當目標AD CS服務器不是受害者用於Kerberos操作的DC時，這種方法最有效。如果它們在同一主機上(例如在小型或實驗室環境中)，目標服務器同時是KDC和AD CS服務器，則可能導致受害者向你而不是DC發送Kerberos票據請求(TGS-REQ)。雖然你可以代理此流量，但這超出了本項目的範圍，你可能最終得不到任何身份驗證數據。
我們還得克服最後一個障礙。 Kerberos AP-REQ實際上並沒有告訴我們正在進行身份驗證的是哪個用戶，這只是在Authenticator的加密部分中指定的。所以我們不知道哪個用戶或設備帳戶正在向我們驗證。幸運的是，在默認的AD CS模板場景中，這實際上並不重要，因為這些場景允許將任何名稱指定為CN，而且無論如何它都會被Active Directory中的名稱覆蓋。但是，為了獲得最好的結果，我建議你在使用mitm6時將攻擊範圍限定在一台主機上，並在krbrelayx中使用—victim指定該主機名，這樣它就能正確地填寫字段。
攻擊示例讓我們看看這在實踐中是怎樣的。首先，我們設置krbrelayx，指定AD CS主機(在實際示例中為adscert.internal.corp)作為目標，並指定接口的IPv4地址作為綁定DNS服務器的接口。這可以防止與通常在例如Ubuntu 上偵聽環回適配器的DNS 服務器發生衝突。
然後我們設置mitm6，使用AD CS主機的名稱作為中繼目標：
我們等待受害者獲得IPv6 地址並連接到我們的惡意服務器：
屏幕截圖顯示，受害者試圖更新他們的DNS記錄，我們拒絕這樣做，因為缺乏認證。認證通過TCP發送給krbrelayx的DNS服務器，DNS服務器接受並轉發給AD CS：
我們看到了預期的流程：
受害者(192.168.111.73)查詢其主機名的SOA記錄。
我們指出我們的惡意DNS服務器是權威的名稱服務器，受害者將向其發送動態更新查詢。
該查詢被mitm6拒絕，這將表明受害者需要驗證他們的查詢。
客戶機與KDC對話，以獲得我們所指示的服務的Kerberos票據。
客戶端建立到krbrelayx的TCP連接，並發送包含Kerberos票據的TKEY查詢。
該票據被轉發到AD CS主機，從而導致我們的認證成功並頒發證書。
有了這個證書，我們可以使用PKINITtools(或Windows上的Rubeus)使用Kerberos進行認證，並模擬一個域管理員來訪問我們的受害者(在本例中是icorp-w10)：
使用smbclient.py，我們可以列出C驅動器，以證明我們有管理員訪問權限：
緩解措施此技術濫用Windows 和Active Directory 中的不安全默認設置。這裡的主要問題是Windows對IPv6的偏好，以及AD CS web應用程序的默認安全問題。這些問題可以通過以下方法加以緩解：
緩解mitm6mitm6 濫用了這樣一個事實，即使在僅IPv4 的環境中，Windows 也會查詢IPv6 地址。如果你在內部不使用IPv6，防止mitm6 的最安全方法是通過組策略在Windows 防火牆中阻止DHCPv6 流量和傳入路由器發布。完全禁用IPv6 可能會產生不必要的副作用。將以下預定義規則設置為阻止而不是允許可防止攻擊起作用：
（入站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-In）；
（入站）核心網絡——路由器發布(ICMPv6-In)；
（出站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-Out）；
緩解對AD CS 的中繼默認CertSrv 網站不使用TLS，這應該首先強制執行，然後才能啟用進一步的保護。使用有效證書啟用TLS 後，在IIS 中啟用身份驗證的擴展保護將防止中繼攻擊。這應該在提供此服務的所有單個CA 服務器上的AD CS 的所有基於Web 的註冊功能上啟用。