Kerberoast攻擊檢測之服務賬戶蜜罐

02-03

在我的上一篇文章「檢測Kerberoast攻擊活動」中，我解釋了Kerberoast攻擊是如何工作的，並描述了如何檢測潛在的Kerberoast攻擊活動。檢測的關鍵是理解什麼樣的活動是正常的，通過過濾掉「噪音」，提高警報的準確度。

這篇文章描述了如何從數百萬個事件中過濾並檢測Kerberoast攻擊活動。

檢測Kerberoast攻擊活動

正如我在上一篇文章中所指出的，尋找使用RC4加密的TGS服務票證是一個用來發現Kerberoast攻擊活動的一個很好的方法。

微軟從Windows Server 2008和Windows Vista開始，添加了Kerberos AES（128和256）加密，這意味著在任何現代Windows操作系統中大多數的Kerberos請求將使用AES進行加密。任何一個使用Kerberos RC4加密請求的票證都是例外情況。有些系統默認情況下僅支持Kerberos RC4加密（NetApp）。林與林之間的Kerberos票證使用的也是RC4，除非手動配置為AES – 確保你創建的林信任支持AES，然後通過信任啟用AES加密。

一旦在所有的域控上配置記錄ID為4769的事件，那麼在將數據發送到SIEM/Splunk之前，需要對這些事件進行過濾。由於我們只對RC4加密的Kerberos TGS服務票證感興趣，所以可以通過過濾器過濾此類事件。如上所示，帶有AES加密的Kerberos事件的票證加密類型設置為0x12。

使用Kerberos RC4加密過的票證的加密類型欄位的值設置為0x17。

這些事件可以使用以下過濾器，這將大大減少流入SIEM/Splunk的事件數量：

票證選項：0x40810000
票證加密：0x17

有了這些信息，我們就可以開始調查潛在的Kerberoast攻擊活動並減少ID為4769的事件的數量。

我們可以進一步減少流入到SIEM/Splunk中的ID為4769事件的數量：

過濾掉服務帳戶的請求（ads45service@lab.adsecurity.org）
過濾「審查成功」的請求
使用「$」符過濾掉那些通常用於計算機帳戶（信任或託管的服務帳戶，Windows會為所有此類帳戶自動生成長而複雜的密碼）的服務名稱的請求。

在有限的測試中，我已經看到通過使用這些過濾手段後，ID為4769的事件總數從數百萬減少到數千，數百個。

這裡有一個可疑的4769事件，很可能是Kerberoast攻擊活動：

遵循這樣的檢測思路，我們可以查看具有特定票證加密和票證選項的TGS票證請求，以識別潛在的Kerberoast攻擊活動。

我們可以使用PowerShell來解析DC的事件日誌，來查找具有相關可疑的票證加密類型和票證選項信息且ID為4769的事件日誌。

上圖中的信息看起來很奇怪。為什麼任何帳戶都可以在一秒或兩秒內請求多個不同的服務名稱（Citrix PVS，BizTalk，Business Objects，AGPM GPO管理和多個SQL服務帳戶）？

這些行為比較明顯而且看起來確實很可疑，因此，這很可能就是Kerberoast攻擊活動。這提供了關於哪些用戶可能已被入侵以及在哪些計算機上的哪些活動應該進行仔細檢查等這些很有用的信息。

單個用戶請求多個服務的RC4加密過的TGS票據，例如大量的SQL服務主體名稱等都比較可疑，而且也值得去調查請求來源的IP（客戶端地址）。對於許多服務主體名稱，多個RC4加密的TGS請求隨時間的變化也都是一樣的。當有一個或兩個帳戶請求多個或RC4 加密的TGS票證時，這種攻擊模式就會顯現。

詳細的檢測方法可以閱讀本文開頭提到的那篇文章，可以了解到Kerberoast攻擊原理等的更多的詳細信息。

過濾「噪音」以查找惡意攻擊活動

我在本文開頭提到的那篇文章中指出過，域控制器上的ID為4769的事件是非常多的，可能會是一些網路上數量最多的事件。

但是，如果我們只關心1個事件呢？

這會將ID為4769的事件的數量減少到只在惡意事件產生時的單個事件嗎？

本文將會描述如何進一步將日誌記錄的事件數量縮小到最佳範圍，以便檢測網路上的Kerberoast攻擊活動：創建服務帳戶蜜罐。

注意：我仍然建議在域控制器上過濾ID為4769的事件，並將它們導入到SIEM/Splunk中，因為這將提供有關用戶正在訪問的資源的一些信息，以及能夠作為在單個用戶請求多個服務主體名稱（這樣的行為是可疑的）時的幫助標記。

創建Kerberoast服務帳戶蜜罐

為了創建Kerberoast服務帳戶蜜罐，我們需要在AD中創建一個用戶帳戶並給它設置一個假的服務主體名稱（SPN）。這個SPN必須是假的，所以我們應該知道，當這個SPN被請求時，很顯然這個請求將是無效的，但卻是惡意的請求行為。同樣重要的是，通過將「AdminCount」屬性設置為1，使此服務帳戶看起來更有吸引力（對攻擊者來說），因為這會將此服務帳戶標記為可能用於提升AD許可權的域賬戶。將此帳戶添加到一組偽造的用戶組中，使其看起來像是能夠用來提供額外的提升許可權的方式，這些做法將有助於增添一些「迷幻色彩」。

步驟1：創建新的AD用戶帳戶。

步驟2：將「AdminCount」屬性設置為1。

步驟2：向帳戶添加服務主體名稱（SPN）。此SPN需要確保是唯一的，因此不應該簡單地從另一個系統中直接複製。 SQL服務帳戶比較常見，所以這不是一種「壞」的使用（MSSQLSvc / http://sql01.lab.adsecurity.org）。只是不要重用已經存在的SPN。

下面的例子有點少…。 ??

步驟3：將蜜罐帳戶添加到看起來可能具有管理員許可權的假的用戶組中可能也很有用。

注意：

為了讓事情變得有趣，你可以為此帳戶設置一個容易猜到的密碼，例如「Password1234」（或常用的鍵盤組合式密碼）。這樣我們就可以監控是否有人使用此帳戶進行登錄。通過Kerberos TGS服務票據請求我們足以知道Kerberoast攻擊活動是否正在發生，可以從日誌記錄的事件信息（「客戶端地址」）中得知攻擊行為是從哪個計算機上完成的。

檢測Kerberoast服務帳戶蜜罐的「訪問」

一旦創建了蜜罐帳戶並為此賬戶設置了不執行任何操作的服務主體名稱，就不應該再請求或使用此SPN。不應該請求這個服務主體名稱的原因是它用於搭建蜜罐，並且此SPN也沒有鏈接到任何真正用於處理請求的應用程序。正常情況下，任何一個請求該SPN的Kerberos TGS服務票據都是沒有理由的，因為沒有運行與此SPN實際關聯的服務。因此，如果我們看到有人請求了Kerberos TGS票證，他們很可能會嘗試使用Kerberosast攻擊爆破此帳戶的登錄憑證。

攻擊者獲得對內部網路的訪問許可權，並搜索具有服務主體名稱且「admincount」屬性為1的帳戶。

上圖顯示了我們為攻擊者準備的新的蜜罐帳戶，從圖中可以看到，攻擊者對此賬戶很感興趣並請求了使用RC4加密的Kerberos TGS票證的SPN。

使用Klist命令可以顯示攻擊者在內存中得到的TGS票證。

通過使用票證加密選項0x12（以及我在Kerberoast檢測的文章中提到的其他過濾器）查找域控制器上的4769事件，我們可以看到Joe 這個用戶請求了一個不存在的SPN的Kerberos票據，並且此SPN正常情況下是不應該被請求的，因為這是一個蜜罐！

帳戶名稱顯示了請求時所使用的帳戶，客戶端地址提供了來自攻擊者請求Kerberos服務帳戶蜜罐的計算機的IP地址。

當我們在域控制器上運行需要處理域控事件日誌且用於檢測Kerberoast攻擊的PowerShell腳本時，我們發現Joe這個用戶請求了很多Kerberos服務票證，包括我們的蜜罐服務賬戶的票證（因為蜜罐的SPN實際上是不存在的，所以它不應該會有請求）。

使用服務帳戶蜜罐，將檢測從「潛在的」Kerberoast攻擊活動變為「明確的」Kerberoast攻擊活動。

注意，我們還可以配置一個IDS規則，檢測帶有服務名稱「KerberoastHoneyPot」的TGS-REQ的數據包。

結論

Kerberoast攻擊需要請求使用RC4加密過的Kerberos TGS服務票證，這樣的行為不應該是網路上的大多數Kerberos的正常活動。在域控上記錄ID為4769的事件，通過票證加密類型（0x17），已知的服務帳戶（帳戶名稱欄位）和計算機（服務名稱欄位）來過濾這些事件可以極大的減少轉發到中央日誌記錄中心和警報系統的事件數量。收集並監測這些數據也可以創造一個良好的「安全」基線，以便於更容易的檢測異常活動。

通過在域控制器上記錄正確的活動行為可以檢測到Kerberoast攻擊活動。確定此活動行為是否是惡意的不需要深入了解RC4 加密的TGS票據在環境中的使用方式。創建具有不執行任何操作的SPN的服務帳戶蜜罐提供了其他的數據點。發送到服務帳戶蜜罐的Kerberos票據的任何請求都應該被視為是惡意的請求行為。

本文參考來源於adsecurity，如若轉載，請註明來源於嘶吼： Kerberoast攻擊檢測之服務賬戶蜜罐更多內容請關注「嘶吼專業版」——Pro4hou