哈希傳遞對于大多數企業或組織來說仍然是一個非常棘手的問題，這種攻擊手法經常被滲透測試人員和攻擊者們使用。當談及檢測哈希傳遞攻擊時，我首先開始研究的是先看看是否已經有其他人公布了一些通過網絡來進行檢測的可靠方法。我拜讀了一些優秀的文章，但我沒有發現可靠的方法，或者是這些方法產生了大量的誤報。

我不會在本文深入剖析哈希傳遞的歷史和工作原理，但如果你有興趣，你可以閱讀SANS發布的這篇優秀的文章——哈希攻擊緩解措施。

總之，攻擊者需要從系統中抓取哈希值，通常是通過有針對性的攻擊（如魚叉式釣魚或通過其他方法直接入侵主機）來完成的（例如：TrustedSec 發布的 Responder 工具）。一旦獲得了對遠程系統的訪問，攻擊者將升級到系統級權限，并從那里嘗試通過多種方法（注冊表，進程注入，磁盤卷影復制等）提取哈希。對于哈希傳遞，攻擊者通常是針對系統上的LM/NTLM哈希（更常見的是NTLM）來操作的。我們不能使用類似NetNTLMv2（通過響應者或其他方法）或緩存的證書來傳遞哈希。我們需要純粹的和未經過濾的NTLM哈希。基本上只有兩個地方才可以獲得這些憑據；第一個是通過本地帳戶（例如管理員RID 500帳戶或其他本地帳戶），第二個是域控制器。

哈希傳遞的主要成因是由于大多數企業或組織在一個系統上擁有共享本地帳戶，因此我們可以從該系統中提取哈希并移動到網絡上的其他系統。當然，現在已經有了針對這種攻擊方式的緩解措施，但他們不是100％的可靠。例如，微軟修補程序和較新版本的Windows（8.1和更高版本）“修復”了哈希傳遞，但這僅適用于“其他”帳戶，而不適用于RID為 500（管理員）的帳戶。

你可以禁止通過GPO傳遞哈希：

“拒絕從網絡訪問此計算機”

設置路徑位于：

Computer ConfigurationWindowsSettingsSecurity SettingsLocal PoliciesUser Rights Assignment 

大多數企業或組織都沒有能力實施GPO策略，而傳遞哈?？杀焕玫目赡苄詤s非常大。

接下來的問題是，你怎么檢測哈希傳遞攻擊？

檢測哈希傳遞攻擊是比較有挑戰性的事情，因為它在網絡中表現出的行為是正常。比如：當你關閉了RDP會話并且會話還沒有關閉時會發生什么？當你去重新認證時，你之前的機器記錄仍然還在。這種行為表現出了與在網絡中傳遞哈希非常類似的行為。

通過對成千上萬個系統上的日志進行廣泛的測試和分析，我們已經能夠識別出在大多數企業或組織中的非常具體的攻擊行為并且具有非常低的誤報率。有許多規則可以添加到以下檢測功能中，例如，在整個網絡中查看一些成功的結果會顯示“哈希傳遞”，或者在多次失敗的嘗試后將顯示憑證失敗。

下面我們要查看所有登錄類型是3（網絡登錄）和ID為4624的事件日志。我們正在尋找密鑰長度設置為0的NtLmSsP帳戶（這可以由多個事件觸發）。這些是哈希傳遞（WMI，SMB等）通常會使用到的較低級別的協議。另外，由于抓取到哈希的兩個唯一的位置我們都能夠訪問到（通過本地哈希或通過域控制器），所以我們可以只對本地帳戶進行過濾，來檢測網絡中通過本地帳戶發起的傳遞哈希攻擊行為。這意味著如果你的域名是GOAT，你可以用GOAT來過濾任何東西，然后提醒相應的人員。不過，篩選的結果應該去掉一些類似安全掃描器，管理員使用的PSEXEC等的記錄。

請注意，你可以（也可能應該）將域的日志也進行分析，但你很可能需要根據你的實際情況調整到符合基礎結構的正常行為。比如，OWA的密鑰長度為0，并且具有與基于其代理驗證的哈希傳遞完全相同的特征。這是OWA的正常行為，顯然不是哈希傳遞攻擊行為。如果你只是在本地帳戶進行過濾，那么這類記錄不會被標記。

事件ID：4624 

登錄類型：3 

登錄過程：NtLmSsP 

安全ID：空SID – 可選但不是必需的，目前還沒有看到為Null的 SID未在哈希傳遞中使用。

主機名 ：(注意，這不是100％有效;例如，Metasploit和其他類似的工具將隨機生成主機名)。你可以導入所有的計算機列表，如果沒有標記的計算機，那么這有助于減少誤報。但請注意，這不是減少誤報的可靠方法。并不是所有的工具都會這樣做，并且使用主機名進行檢測的能力是有限的。

帳戶名稱和域名：僅警告只有本地帳戶（即不包括域用戶名的賬戶）的帳戶名稱。這樣可以減少網絡中的誤報，但是如果對所有這些賬戶進行警告，那么將檢測例如：掃描儀，psexec等等這類東西，但是需要時間來調整這些東西。在所有帳戶上標記并不一定是件壞事（跳過“COMPUTER$”帳戶），調整已知模式的環境并調查未知的模式。

密鑰長度：0 – 這是會話密鑰長度。這是事件日志中最重要的檢測特征之一。像RDP這樣的東西，密鑰長度的值是 128位。任何較低級別的會話都將是0，這是較低級別協議在沒有會話密鑰時的一個明顯的特征，所在此特征可以在網絡中更好的發現哈希傳遞攻擊。

另外一個好處是這個事件日志包含了認證的源IP地址，所以你可以快速的識別網絡中哈希傳遞的攻擊來源。

為了檢測到這一點，我們首先需要確保我們有適當的組策略設置。我們需要將帳戶登錄設置為“成功”，因為我們需要用事件日志4624作為檢測的方法。

讓我們分解日志并且模擬哈希傳遞攻擊過程。在這種情況下，我們首先想象一下，攻擊者通過網絡釣魚獲取了受害者電腦的憑據，并將其提升為管理級別的權限。從系統中獲取哈希值是非常簡單的事情。假設內置的管理員帳戶是在多個系統間共享的，攻擊者希望通過哈希傳遞，從SystemA（已經被入侵）移動到SystemB（還沒有被入侵但具有共享的管理員帳戶）。

在這個例子中，我們將使用Metasploit psexec，盡管還有很多其他的方法和工具可以實現這個目標：

在這個例子中，攻擊者通過傳遞哈希建立了到第二個系統的連接。接下來，讓我們看看事件日志4624，包含了什么內容：

安全ID：NULL SID可以作為一個特征，但不要依賴于此，因為并非所有的工具都會用到SID。雖然我還沒有親眼見過哈希傳遞不會用到NULL SID，但這也是有可能的。

接下來，工作站名稱肯定看起來很可疑; 但這并不是一個好的檢測特征，因為并不是所有的工具都會將機器名隨機化。你可以將此用作分析哈希傳遞攻擊的額外指標，但我們不建議使用工作站名稱作為檢測指標。源網絡IP地址可以用來跟蹤是哪個IP執行了哈希傳遞攻擊，可以用于進一步的攻擊溯源調查。

接下來，我們看到登錄過程是NtLmSsp，密鑰長度為0.這些對于檢測哈希傳遞非常的重要。

接下來我們看到登錄類型是3（通過網絡遠程登錄）。

最后，我們看到這是一個基于帳戶域和名稱的本地帳戶。

總而言之，有許多方法可以檢測環境中的哈希傳遞攻擊行為。這個在小型和大型網絡中都是有效的，并且基于不同的哈希傳遞的攻擊方式都是非?？煽康?。它可能需要根據你的網絡環境進行調整，但在減少誤報和攻擊過程中溯源卻是非常簡單的。

哈希傳遞仍然廣泛的用于網絡攻擊并且是大多數企業和組織的一個共同的安全問題。有許多方法可以禁止和降低哈希傳遞的危害，但是并不是所有的企業和組織都可以有效地實現這一點。所以，最好的選擇就是如何去檢測這種攻擊行為。