信標、數據集、Cobalt Strike
1Cobalt Strike信標數據集
數據集beacons.jsonl.gz是一個GZIP壓縮文件，包含128,340行JSON格式的信標元數據作為。讀者可以從以下存儲庫下載該數據集，並查看隨附的Jupyter notebook：
https://github.com/fox-it/cobaltstrike-beacon-data
該數據集涵蓋了從2018年7月到2022年2月近四年的歷史Cobalt Strike信標元數據。然而由於存檔問題，丟失了2019年內五個月的數據。此外，該數據集主要關注團隊服務器中HTTP端口80、443和DNS上的x86信標，不包含來自其他來源的任何信標，例如 VirusTotal。
由於數據集大小限制，信標有效負載本身不在數據集中。相反，數據集中會存儲不同的信標配置設置，包括其他元數據，例如：
收集信標的日期以及來自哪個IP地址和端口
GeoIP + ASN元數據
DER格式的TLS證書
PE信息（時間戳、magic_mz、magic_pe、stage_prepend、stage_append）
如果負載是XOR編碼的，哪個XOR密鑰用於模糊配置
原始信標配置字節，方便手動解析信標配置。（例如使用dissect.cobaltstrike或其他選擇的解析器）
雖然有一些簡單的方法可以從信標有效負載中識別破解或盜版的Cobalt Strike Team服務器，但很難分辨出所使用的方法。因此，該數據集是未經過濾、完全公開的，並且包含收集的所有信標。
2信標介紹以及如何獲取
Cobalt Strike信標是通過首先識別Internet上的團隊服務器，然後使用checksum8 HTTP請求下載信標來獲取的。通過蜜罐，可以看出並非只有RIFT在挖掘信標。現在很多團隊都在這樣做。與Cobalt Strike檢測相關的博客文章和示例腳本的增加，很大程度上都歸因於此，當然， Cobalt Strike的日益普及也是一個因素。
Cobalt Strike掃描探測的發展十分引人注目，先後出現了用於識別團隊服務器和檢索信標的不同技術和策略。有些甚至跳過了識別部分，直接去請求信標。這種方式可能很複雜，但對於某些威脅參與者來說值得重視。
圖1 針對x86和x64信標的checksum8請求
上面顯示的請求是在2021年2月訪問了託管真實網站的普通網絡服務器的checksum8請求（針對x86和x64信標）。
此外也可以使用作者團隊提供的checksum8-accesslogs.py腳本完成掃描識別。採用checksum8驗證的該方式檢測結果更準確，還可以輸出統計信息。圖2是一個輸出為x86和x64信標的HTTP請求，該請求命中一個蜜罐並生成相應的統計信息：
圖2 checksum8-accesslog.py腳本在訪問日誌中發現可能的信標階段請求
如圖3所示，在輸出中還可以看到正在使用的不同信標掃描技術。通過繪製統計數據，可以看到蜜罐上的信標掃描明顯增加：
圖3 Cobalt Strike信標掃描增長趨勢
3Cobalt Strike版本更替情況
鑑於擁有多年的信標元數據，作者團隊可以很好地描繪Internet上活躍的Cobalt Strike服務器以及其使用的版本的情況。
為了提取Cobalt Strike版本數據，使用了以下兩種方法：
(1) 使用信標設置常量
當引入新的Cobalt Strike信標配置設置時，設置常量會增加然後進行分配。可以根據提取的信標配置中的最高可用常量來推斷版本。
(2) 使用PE導出時間戳
BlackBerry在《在黑暗中尋找信標：網絡威脅情報指南》一書中也記錄了這一方式，這是確定確切版本的更準確方法。
dissect.cobaltstrike支持這兩種推斷版本號的方法，並且更傾向於使用PE導出時間戳的方法。
圖4 Cobalt Strike版本隨時間變化趨勢
可以看出，在2021年4月，在線Cobalt Strike服務器和信標出現了相當突出的高峰，但除了當月修改的（可能是惡意的）信標增加了3%外不確定是什麼原因造成的。
圖5更清晰地顯示了不同版本之間的採用度和流行度：
圖5 Cobalt Strike各版本使用百分比
可以看出，Cobalt Strike 4.0（2019年12月發布）在2020年1月至2021年1月期間仍然很受歡迎。
4信標水印統計
自Cobalt Strike 3.10（2017年12月發布）以來，信標包含一個名為SETTING_WATERMARK的設置。這個水印值由授權服務器發行，在每個Cobalt Strike安裝中是唯一的。
但是，破解或盜版版本通常會將其修補為固定值，這樣可以輕鬆識別哪些信標更有可能是惡意的。這種可能性與迄今為止的事件響應活動一致，其中與網絡攻擊相關的信標使用了已知的不良水印。
圖6排名前50的Cobalt Strike信標水印
5定製信標
在解析收集到的信標時，會發現一些信標被修改了，例如，使用自定義shellcode存根、非默認XOR密鑰或重新分配的信標設置。因此，具有大量自定義的信標無法正確轉儲並且不包含在數據集中。
圖7自定義XOR密鑰
雖然使用自定義XOR密鑰可能會使信標成為異常值，但確實可以保護自己免受一些現有的Cobalt Strike配置轉儲程序的影響。dissect.cobaltstrike支持在默認XOR密鑰不起作用時嘗試使用所有XOR密鑰。例如，可以將命令行標誌--all-xor-keys傳遞給beacon-dump命令。
6PE組件
雖然大多數現有的Cobalt Strike轉儲程序都專注於信標設置，但Malleable C2配置文件中的一些設置不會最終出現在有效載荷的嵌入式信標配置中。例如，Malleable C2 配置文件中的一些可移植執行文件(PE)設置直接應用於信標負載。dissect.cobaltstrike支持提取此信息，數據集包括以下提取的PE標頭元數據：
magic_mz：MZ標頭
magic_pe：PE標頭
pe_compile_stamp：PE編譯時間戳
pe_export_stamp：導出表的時間戳
stage_prepend：附加到信標載荷前面的（shellcode）字節
stage_append：附加到信標載荷後面的字節
作者列舉了所有常見的 ASCII字節形式的stage_prepend字節，如圖8所示。這些字節位於MZ標頭前面，並且必須是有效的匯編代碼，但在作為shellcode執行時會導致無法操作。
圖8常見ASCII stage_prepend shellcode 字節
圖9是stage_prepend shellcode 「JFIFJFIF」的反匯編示例，可以看到它主要由ESI單增和EDX單減指令構成，所以不完全是一個無操作的shellcode，但很可能也不影響暫存過程。
圖9反匯編shellcode JFIFJFIF
7使用空格加水印的releasenotes.txt
Cobalt Strike在HTTP 服務器標頭中的空格之後，還有一個稱為SETTING_SPAWNTO的信標設置，其填充為文件releasenotes.txt（或者同一文件目錄中具有相同checksum8值152和相同文件名長度的另一個文件）的MD5哈希值。
當激活或更新Cobalt Strike服務器時，會自動從許可證服務器下載releasenotes.txt。這個文件很可能是使用空白字符加水印的，從而使該文件及其MD5哈希值在每次安裝時都是唯一的。許可證服務器可能會跟蹤所有這些唯一生成的文件，以幫助打擊盜版和阻止Cobalt Strike的泄漏。在一些盜版信標中，該字段全為零，或者不可用，這意味着盜版製作者知道此文件的作用，並決定不將其發送到盜版版本中，否則字段值已被修補。儘管如此，在使用時，該字段仍可用於搜索或關聯信標。兩個版本的差別如圖10所示，注意文件之間行尾的細微空格變化：
圖10兩個releasenotes.txt文件間的空格變化
8使用dissect.cobaltstrike分析信標有效載荷
圖11pip安裝dissect.cobaltstrike命令
項目的GitHub存儲庫為：https ://github.com/fox-it/dissect.cobaltstrike
目前存儲庫安裝了三個命令行工具：
(1) beacon-dump—用於從信標載荷中導出配置（也適用於內存轉儲）。
(2) beacon-xordecode—用於經過異或編碼的載荷解碼的獨立工具。
(3) c2profile-dump—用於讀取和解析Malleable C2配置文件。
如圖12所示，信標轉儲的一個簡潔功能是將信標配置轉儲回來，因為它是與可擴展 C2 配置文件兼容的等效項：
圖12 將信標設置轉儲為可擴展 C2 配置文件
9結束語
信標數據集已被證明非常有用，尤其是數據集包含的歷史特性，提高了在事件響應參與期間的洞察力。作者團隊提供的這個數據集， 可用於C2基礎設施映射、威脅主體跟蹤、威脅狩獵、高質量威脅指標提取、檢測工程實現等等。希望這個數據集以及相關Python庫能夠對社區有所幫助。另外，讀者可從以下幾方面拓展：
(1) 使用DBSCAN等聚類算法對信標和C2配置文件特徵進行聚類。
(2) 改進惡意信標的分類。
(3) 使用GeoIP ASN數據確定最惡意信標的託管位置。
(4) 分析x509證書數據，例如是否自簽名。
(5) 確定信標是否使用域前置技術以及使用的是哪個CDN。
原文：
https://research.nccgroup.com/2022/03/25/mining-data-from-cobalt-strike-beacons/
編輯| 陳蓉
審校|何雙澤、金矢
本文為CNTIC編譯整理，不代表本公眾號觀點，轉載請保留出處與鏈接。聯繫信息進入公眾號後點擊「關於我們」可見。
留言列表