BloodHound 3.0 介紹
簡介
經過幾個月的開發和質量測試，我們很自豪地宣布BloodHound 3.0 正式發布！ 在這個版本中，包括了3個新的攻擊原語，GUI 和 SharpHound 的一些性能改進，以及對 Neo4j 4.0的支持。
對那些直接或間接為本次發布做出重大貢獻的人表示感謝： Tim McGuffin (@NotMedic), Michael Grafnetter (@MGrafnetter), Will Schroeder (@harmj0y), Lee Christensen (@tifkin_), Sean Metcalf (@PyroTek3), Dirk-jan Mollema (@_dirkjan), 以及 Mark Gamache (@markgamacheNerd)。
這是一個大版本的發布，意味著我們將在這個版本中引入打破兼容性的特性—— SharpHound2和你的 BloodHound 2.x 資料庫將與 BloodHound 3.0不兼容，因此請確保你使用的是最新的 SharpHound。 BloodHound 3.0與 Neo4j 4.0兼容，節點現在是通過它們的 SID 唯一標識的而不是名稱。
新的攻擊原語
在 BloodHound 3.0中，包括了三個新的攻擊原語: GMSA 控制、 OU 控制和 SID 歷史記錄。 默認情況下，任何經過域身份驗證的用戶都可以讀取與這些新攻擊原語相關的配置，並且每個攻擊原語都可以使用實用工具進行處理。 攻擊者可以根據這些攻擊原語找到新的攻擊路徑，從而找到以前未被發現的能夠拿到 DA 許可權 (或者不管你的目標是什麼) 的攻擊路徑，而防禦者可以使用 BloodHound 來審計和補救相同的攻擊路徑。
以下是每個新的攻擊原語的工作原理:
新攻擊原語: GMSA 控制
組管理服務帳戶(GMSA)是活動目錄中的特殊服務帳戶，它解決了許多關於最小特權和憑證安全的問題。 GMSA 的密碼由域控制器管理，每30天自動更改一次(默認情況下) ，由128個字元組成(可以理解為: 你不可能猜出來)。
GMSA 的關鍵在於管理員需要指定允許誰讀取 GMSA 的明文密碼。 例如，假設我們的用戶 Dwight Hohnstein 可以讀取 SQL GMSA 的密碼。 在 BloodHound 的圖形用戶界面中，你可以看到從 Dwight 到 SQL 計算機的攻擊路徑：
如果我們能夠進入 DHOHNSTEIN 用戶的上下文，我們就可以檢索 GMSA-SQL01的明文密碼，然後橫向移動到 SQL01.CONTOSO.LOCAL。 已經有一些工具可以檢索出 GMSA 密碼，但是沒有一個可以讓你保持完全的內存駐留。 出於這個原因，Rohan 創建了 GMSAPasswordReader，它利用了一個 C# 中的功能，可以讀取 GMSA 的密碼。 下面是使用 GMSAPassword.exe 和 Cobalt Strike 的 execute-assembly 函數來檢索 GMSA-SQL01的 NT 哈希的示例：
現在，通過使用 GMSA 帳戶密碼的 NT 哈希，你可以模擬用戶(例如，使用 overpass-the-hash) ，然後從側面移動到 SQL01.CONTOSO.LOCAL。
有關 GMSA 的更多信息，請參閱 Michael Grafnetter 的發表的這篇優秀的文章。
新攻擊原語: OU 控制
AD 管理員經常會在 OU 上定義 ACE，這些 ACE 適用於 OU 本身或 OU 及其派生的對象，但不適用於派生的用戶、組和計算機對象。 在過去，我們已經看到了通過與 OU 鏈接的 GPO 對象來控制 OU，以及將惡意的 GPO 鏈接到你所控制的 OU 的可能性。 這有幾個問題，最關鍵的是，你需要能夠在一台惡意的 GP 伺服器上正確地託管你的惡意 GP 文件—— 到目前為止通過命令行的方式已被證明要完成攻擊相當困難。 然後它像一噸磚塊一樣砸向我們: 通過控制 OU ，你可以將 ACE 推送到 OU 上，然後將 ACE 繼承到 OU 派生的對象！
例如，假設 Justin Bui 完全控制了我們的 Workstation Admins OU，其中包含 Josh Prager 的 user 對象：
這裡的攻擊相當簡單: 從 JBUI 的上下文中，我們可以向 Workstation Admins OU 添加一個新的 ACE，這個 ACE 將繼承到 JPRAGER。 這是由 PowerView 的一個叫做 New-ADObjectAccessControlEntry 的 cmdlet 實現的，作者是 Lee Christensen (@tifkin_)。 一旦新的 ACE 就位，我們就可以從 JBUI 的上下文中濫用 JPRAGER 用戶，就像我們在 BloodHound 1.3 ACL 更新後所做的那樣: 重置他的密碼，或者進行目標明確的 kerberos 煅燒攻擊。
當你將 ACE 應用於 OU 並將其設置為向下繼承到子對象時，你可以選擇將其應用於所有對象、某個類的對象，甚至可以控制它是否應用於 OU 的直接子對象或所有子對象。 有關如何在 OU 上執行通用或特定於某個對象的 ACE 的完整示例，請參閱 BloodHound GUI 中的邊緣幫助模式:
新攻擊原始: SID 歷史
最後，我們還將 SID 歷史作為一個新的攻擊原語包含在 BloodHound 3.0中。 作為一個紅隊成員，你可能首先會想到濫用 SID 歷史功能的黃金票證，但實際上我們看到的是用戶、計算機和組，它們已經在其 AD 對象的 SIDHistory 參數中列出了 SID。 當一個對象從一個活動目錄域遷移到另一個域時，可以合法地填充這些參數——目的是為了維護該主體所擁有的許可權和特權，新的域中的對象將包含該主體所屬的任何組的 SID。
例如，假設 Josiah Massari 的用戶對象從 FABRIKAM 域遷移到 CONTOSO 域。 在 FABRIKAM 域，Josiah 屬於工作站管理員組（Workstation Admins），它擁有 FABRIKAM 所有工作站的本地管理許可權。 在 CONTOSO 域中，Josiah 的用戶對象將包含 FABRIKAM 中 Workstation Admins 組的 SID。 現在，每當 Josiah 在企業中進行身份驗證時，他的 kerberos 票證將在票證的 PAC 的 ExtraSIDs 部分包含該組的 SID，從而授予他該組所擁有的所有相同的許可權和特權。
總結起來就是一句話: Josiah 實際上仍然是 FABRIKAM Workstation Admins 組的成員，儘管他的用戶對象不再屬於那個組。 更多有關的詳細信息，請看 Sean Metcalf 的精彩博文: Sneaky Active Directory Persistence #14: SID History。
在BloodHound 圖形用戶界面中，上面的情況是這樣的：
這裡的濫用方式是相當簡單的。 事實上，你可以簡單地認為「HasSIDHistory」就是你已經認為的「MemberOf」的邊緣。 從 JMASSARI 上下文中，你將對 FABRIKAM 域中的兩個工作站擁有管理許可權。
這裡有一個極其重要的警告: 如果 CONTOSO 和 FABRIKAM 域之間的域信任強制執行 SID 過濾，這種攻擊將不起作用，因為 JMASSARI 的 kerberos 票證 PAC 的 ExtraSIDs 部分中的 SID 將被 FABRIKAM 域忽略。 有關 SID 過濾的更多信息，請參閱 Will Schroeder 的優秀博客文章「攻擊域信任指南」。
性能改進
我們在兩個主要的方面做了很大的性能改進: 使用 SharpHound 收集數據，使用 BloodHound GUI 導入數據。 在 SharpHound 方面，你應該可以看到 LDAP 收集的速度大約提高了25% 到30% 。 主機收集稍微慢一點，但有了一個更好的準確性權衡。 與前一版本相比，嘗試將主機解析為正確值的檢查次數比前一個版本顯著增加。。
在數據導入方面，Rohan 已經完全重新構建了 JSON 解析和導入邏輯，因此將文件拖放到 GUI 中將非常非常快。
如果有足夠的興趣，Rohan 將在未來的博客文章中描述他是如何實現這些速度改進的技術細節，以及從主機獲取信息的更新方法。
質量改進
在 GUI 如何處理特別吃內存的查詢和GUI如何處理具有許多節點和邊的圖形呈現方面有兩個主要的變化。
首先，每當你點擊 BloodHound GUI 中的一個節點時，該節點的信息標籤就會填充並開始顯示關於該對象的各種信息：
其中一些查詢對於資料庫來說非常容易處理，比如從用戶節點獲取「password last set」日期和時間，或者甚至獲取用戶已經分組授予管理許可權的計算機數量。 但是其中一些查詢實際上非常吃內存，尤其是當你開始處理超過一定規模的資料庫時(比如說，超過30000個節點)。 具體地說，任何使用 shortestPath() 的情況中，如果開始節點或結束節點可以是圖中的任何其他節點(而不是特定節點) ，都會給資料庫帶來大量的運算工作。
以前，每次單擊用戶節點時，我們都會啟動3個這樣的查詢: 派生的本地管理許可權、傳遞對象控制器和傳遞對象控制器。 我們並沒有刪除這些查詢，我們只是改變了默認的行為，現在你可以點擊一個「play」按鈕來啟動這個查詢，而不是每次你點擊一個用戶節點(並在資料庫上投入大量的工作)都會運行這些查詢：
其次，BloodHound GUI 的一個大問題是渲染由數百個節點和邊組成的非常大的圖。 這是因為我們依賴於免費和開源的圖形渲染庫——所有這些庫都被限制用 CPU 而不是 GPU 來渲染圖形布局。 當然，GPU 在渲染圖形方面的數量級要比 CPU 快，因此這是我們目前必須解決的一個限制，而不是必須解決的。
我們的解決方案是攔截 neo4j 返回的數據，確定數據量是否可能導致 GUI 掛起很長時間，然後讓用戶選擇如何繼續：
點擊「Cancel」會完全按照你的想法去做。 「Save Data」將為你提供一個通用的對話窗口，你可以在這個窗口中以 JSON 格式保存原始圖形數據。 「Draw Graph」將繼續像通常一樣嘗試渲染邊和節點。
總結
我們希望你能喜歡 BloodHound 3.0的這個版本，它提高了性能，增加了新的攻擊原語，並且提高了質量。 請記住: 這是一個主要版本，你還必須使用 SharpHound 的最新版本: SharpHound3。 我們真誠地感謝 BloodHound Slack 頻道中使用測試版的每一個人，感謝他們幫助我們測試所有的組件。 我們還要再次感謝 Tim McGuffin (@NotMedic), Michael Grafnetter (@MGrafnetter), Will Schroeder (@harmj0y), Lee Christensen (@tifkin_), Sean Metcalf (@PyroTek3), Dirk-jan Mollema (@_dirkjan), 以及 Mark Gamache (@markgamacheNerd)，感謝他們對本次發布的直接和間接的貢獻。 謝謝！
參考來源：https://posts.specterops.io/introducing-bloodhound-3-0-c00e77ff0aa6
