如何識別惡意Cobalt Strike服務器

如何識別惡意Cobalt Strike服務器，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

摘要

Cobalt Strike是一個滲透平臺，供安全專業人員用于模擬高級黑客的定向攻擊和后滲透行動。該工具由總部位于華盛頓的Strategic Cyber LLC公司開發并授權，該公司對該工具的非法使用受到監管，并受到出口管制。盡管如此，Cobalt Strike框架已經成為該類軟件中的最熱門的選擇，其中包括Metasploit Pro、Core Impact等其他付費套件。在這類平臺中，雖然Cobalt Strike并不是唯一一個被盜版用戶和網絡罪犯使用的平臺，但其已經被各種包括APT32在內的威脅集團使用，他們使用該工具進行初步滲透，而以同名命名的Cobalt集團也嚴重依賴該框架。

考慮到安全測試人員，更重要的是惡意攻擊者，大量使用Cobalt Strike平臺，識別Cobalt Strike服務器連接到企業網絡資產的必要性是顯而易見的。

盡管檢測方法已經公開，但仍由大量的Cobalt Strike服務器并沒有打補丁，允許指紋識別和后續其他方式的探測。通過對在野的Cobalt Strike服務器取樣，并比較指紋識別的方法以幫助防御者更好地跟蹤和監控該框架。追蹤Cobalt Strike服務器可以幫助紅隊探測沒有修改Cobalt Strike默認配置藍隊的活動。

盡管補丁使得特定的指紋識別方法更加困難，Cobalt Strike服務器仍然相當暴露，相對容易被發現。許多Cobalt Strike服務器在補丁發布之前沒有更新他們的系統，而新部署的使用了升級后的軟件。

最近和部署的Cobalt Strike服務器更有可能部署更新的Cobalt Stike版本（超過3.12），同時繼續使用默認的TLS證書，因此這仍然是一個可靠的檢測機制。

當前Cobalt Strike服務器與歷史威脅活動相比，大部分惡意和中立用戶似乎都是用了默認的、未補丁的Cobalt Stike配置，也許是為了兼容其他Cobalt Stike服務器，或者僅僅因為默認設置運行良好因此使用者懶得改動什么東西。

對Cobalt Strike服務器的探測可以幫助防御者在其企業網絡中建立預警機制，先于藍隊先發制人。

公開的Cobalt Strike服務器識別方法

2019年2月19日，Strategic Cyber LLC發布了Cobalt Strike Team Server Population Study。該研究的部分目的是調查Cobalt Strike軟件的許可狀態，并識別和分析對當前使用的軟件版本所做的重大更改。

該研究確認了多種方法用于識別在野的Cobalt Stike服務器：

Cobalt Strike服務器附帶默認的安全證書，除非管理員修改了默認證書，否則可以使用該默認證書進行指紋識別：

SHA256: 87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

Serial Number: 146473198

當啟用時，Cobalt Strike DNS服務器會響應任何DNS請求與bogon（假）IP：0.0.0.0 （這并不是CS服務器獨有的特征）

Cobalt Strike服務器的默認控制端口是50050/TCP，這個端口在其他服務器上大部分不會打開。

Cobalt Strike服務器的”404 Not Found“ HTTP響應與NanoHTTPDweb服務器不同，并且能被探測到。

總的來說，上面列表中最可靠的方法是使用默認安全證書對Cobalt Strike服務器進行指紋識別。其余的檢測方法不太確定，所有方法與其他方法相互印證后都具有較高的置信度。例如，任何使用50050端口、同時提供NanoHTTP web服務器特有的HTTP響應的服務器都更像是Cobalt Strike服務器，而不是僅顯示HTTP響應簽名的服務器。

基于NanoHTTPD響應的方法

Cobalt Strike服務器基于NanoHTTPD，于2012年首次發布。NanoHTTPD是一個基于java的開源web服務器框架。NanoHTTPD服務器響應中包含一個額外的空字節："HTTP/1.1"后面是一個空字節（0x20），而在其他web服務器響應中不存在這個空字節。

2019年1月2日， Cobalt Strike 3.13版發布。Cobalt Strike發布的聲明指出，與以前的版本相比，其中一個變化是“從HTTP狀態響應中刪除了無關的空字節”。

任何來自3.13之前的Cobalt Strike服務器的HTTP響應都包含這個空字節，可以使用掃描器檢索HTTP響應來搜索它們。也可以手動對Cobalt Strike服務器的連接抓包，可以很容易看到這個額外的空位。由于運行破解版本的Cobalt Strike實例沒有更新或打補丁，這種方法增加了發現惡意Cobalt Strike服務器的可能性。

安全公司Fox-IT于2019年2月26日發布了關于Cobalt Strike服務器的研究，該研究不僅提供了細節和如何識別3.13版本之前的服務器（對應HTTP響應中額外的空字符），還包括從Rapid7公開數據中從2015到2019年使用該檢測方法發現的超過7000 Cobalt Strike 主機IP列表。

類似的，2019年2月27日，知道創宇安全研究團隊發表了一篇博客，詳細介紹了他們使用Strategic Cyber LLC報告的NanoHTTPD 404 Not Found響應異常以及空字節異常來識別Cobalt Strike服務器。他們在ZoomEye的數據中發現的服務器更少，但仍然超過了3000臺。知道創宇報告稱，構建Cobalt Strike的開源NanoHTTPD代碼響應方式如下：

HTTP/1.1 404 Not Found
Content-Type: text/plain
Date: Day, DD Mmm YYYY HH:MM:SS GMT
Content-Length: 0

知道創宇的檢測邏輯就是基于這一發現。然而他們隨后還觀察到HTTP響應中的順序實際上可能不同，在一些Cobalt Strike系統的響應中"Content-Type"在"Date"之后顯示。

基于JA3指紋的檢測方式

對于由詳細網絡流量數據的用戶，JA3是一種更可靠的發現Cobalt Strike服務器的方法。由三位Salesforce研究員開發的開源JA3項目，可以通過對服務器和客戶端之間的TLS協商進行指紋識別來檢測可疑的HTTPS瀏覽。TLS/SSL版本、可接受的加密套件和elliptic curve細節（如elliptic curve point格式）可以被做成指紋，就像瀏覽器可以被其他版本、附加組件和特定于該瀏覽器的其他特性指紋一樣。

JA3簽名用于客戶端，而JA3S簽名用于服務器。在Cobalt Strike的案例中，Client beacon（使用Windows套接字來發起通信）和運行在Kali Linux上的Cobalt Strike服務器的TLS協商已經有了指紋。這些指紋需要一起使用才能可靠地發現Cobalt Strike服務器。盡管Cobalt Strike使用者可以通過重定向來部分避開這種檢測，但許多Cobalt Strike服務器并不使用這種代理。

JA3和JA3S簽名可以與Zeek/Bro和Suricata等工具一起使用。來自這些網絡檢測工具的數據可以隨后輸入到諸如Splunk這樣的SIEM中。JA3和JA3S的簽名可以從Salesforce’s Github account和其他sources獲得。

JA3

Cobalt Strike默認的SSL/TLS證書是固定的，所以一般都是使用這個證書作為特征值來發現Cobalt Strike服務器，服務端傳給客戶端的SSL默認證書有很明顯的特征：

C=Earth，ST=Cyberspace，L=Somewhere，O=CobaltStrike，OU=AdvancedPenTesting，CN=Major CobaltStrike

JA3方法用于收集Client Hello數據包中以下字段的十進制字節值：版本、可接受的密碼、擴展列表、橢圓曲線密碼和橢圓曲線密碼格式。然后將這些值串聯到一起，在使用“,”分割開各個字段，同時用“-”來分隔各個字段中的各個值。

這些字段的順序如下：TLS版本信息、可接受的密碼、擴展列表、橢圓曲線密碼和橢圓曲線密碼格式。

用CobaltStrike4.1的連接流量舉例。

771,49188-49192-61-49190-49194-107-106-49162-49172-53-49157-49167-57-56-49187-49191-60-49189-49193-103-64-49161-49171-47-49156-49166-51-50-49196-49195-49200-157-49198-49202-159-163-49199-156-49197-49201-158-162,67,,11-2-256(如果無上述字段，則這些字段的值為空)

然后會計算這些字符串的MD5哈希值，以生成易于使用和共享的長度為32字符的指紋，他們就是JA3 TLS客戶端的指紋。比如上述CobaltStrike4.1客戶端指紋：fa704723a210632b2ff9ad03be418651

JA3S

創建JA3后，就可以使用同樣的方式對TLS的服務端進行指紋識別，即對TLS Server Hello信息進行指紋識別。JA3S會收集Server Hello數據包中以下各個字段的十進制字節值：版本、可接受的加密算法和擴展列表，然后將這些值串聯起來，使用“,”來分隔各個字段，使用“-”分隔每個字段中的各個值。

這些字段的順序如下：TLS版本信息、可接受的密碼、擴展列表

CobaltStrike4.1的服務端：771,49192,9-------->5513ab2983a0db88fadd353de0341e7c

同一臺服務器會根據Client Hello信息機器內容以不同的方式創建Server Hello消息，因此這里不能跟JA3那樣，僅僅根據服務器的Hello消息來對其進行指紋識別。盡管服務器對不同客戶端的響應不同，但是他們對同一客戶端的響應總是一致的。

比如：客戶端正在發送TLS Client Hello數據包，其中數據都是A。因此，服務器會的響應的內容也是由A構成，并將始終用A來提供同樣的響應。與此同時，另一個客戶端也在發送數據包，并且內容都是B。類似的，服務器現在會用B進行響應，并且總是用B組成的B串進行響應。可以看到，對于不同的客戶端，服務器會給予不同的響應，但是對于每個客戶端來說，總是以相同的方式進行相應。

在這個日志輸出中，JA3位于左側，JA3S位于右側，使用同一客戶端與同一服務器交互了4次。然后，再次使用不同的客戶端進行了4次以上的交互。不難發現，服務器的響應方式對于同一客戶端總是相同的，但對于不同的客戶端卻是不同的。

例如，MetaSploit 的 Meterpreter 和 CobaltStrike（并非4.1版本） 的 Beacon 都使用 Windows 套接字來啟動 TLS 通信。在 Windows 10 上，JA3=72a589da586844d7f0818ce684948eea（指定 IP 地址），JA3=a0e9f5d64349fb13191bc781f81f42e1（指定域名）。由于 Windows 上的其他普普通通的應用程序也使用相同的套接字，因此，我們很難識別其中的惡意通信。但是，Kali Linux 上的 C2 服務器對該客戶端應用程序的響應方式與 Internet 上的普通服務器對該套接字的響應方式相比來說是獨一無二的。盡管服務器對不同客戶端的響應不同，但它們對同一客戶端的響應總是一致的。因此，如果結合 ja3+ja3s，就能夠識別這種惡意通信，而不用考慮目的地 IP、域名或證書等細節信息。

基于JARM的檢測方式

介紹

近期，Salesforce研究人員發布了一篇名為Easily Identify Malicious Servers on the Internet with JARM的文章，并在github上發布了一個JARM掃描工具，相關內容引起了國外部分研究人員的討論。

JARM是一個主動TLS服務端指紋工具，主要用途如下：

快速驗證一組TLS服務器是否使用相同的TLS配置；

通過TLS配置劃分TLS服務器，并識別可能歸屬的公司；

識別網站默認的應用或基礎架構；

識別惡意軟件C&C控制節點，以及其他惡意服務器。

JARM的核心在于：TLS Server根據TLS Client Hello中參數的不同，返回不同的Server Hello數據包。而Client Hello的參數可以人為指定修改，因此通過發送多個精心構造的Client Hello獲取其對應的特殊Server Hello，最終形成TLS Server的指紋。具體能夠產生影響的參數包括但不限于：

操作系統及其版本

OpenSSL等第三方庫及其版本

第三方庫的調用順序

用戶自定義配置

……

而前文提到，TLS服務器對不同客戶端的響應不同，但是他們對同一客戶端的響應總是一致的。因此不能跟JA3那樣，僅僅根據JA3S對服務器進行指紋識別。

而JARM采取了一種類似fuzz的方式，主動向TLS服務器發送10個TLS Hello數據包并對Server Hello中的特定字段進行分析，以特定方式對10個TLS服務器響應進行哈希處理，最終生成JARM指紋。

JARM中的10個TLS客戶端Hello數據包經過特殊設計，目的就是提取TLS服務器中的唯一響應。例如：

JARM以不同的順序發送不同的TLS版本，密碼和擴展；

TLS Clint將密碼從最弱到最強排序，TLS Server將選擇哪種密碼？

……

總之JARM與我們在進行流量分析威脅時常用的JA3、JA3/S不同：

JA3、JA3/S主要基于流量，服務器面對不同客戶端產生不同的JA3S指紋。

JARM則是完全主動的掃描并生成指紋，服務器可以生產唯一的JARM指紋。

利用JARM識別C2的問題

在Easily Identify Malicious Servers on the Internet with JARM原文中，作者給出了一份C2和JARM對應的清單：

在理想情況下如果JARM與C2唯一對應，那么我們就多了一種主動發現C2節點的特征。

然而，360Quake團隊在驗證時，搜索Cobalt Strike對應的JARM發現了2338個獨立IP，但TOP5的應用為：

可以看到和上面CobaltStrike相同JARM的還有 Tomcat、Weblogic和WordPress等開啟TLS的Web應用，也就是說CobaltStrike這個應用只是該JARM對應TLS服務器其中的一個子集。

而在之后的驗證中發現，JARM指紋與上層應用無強關聯性，使用相同JDK的Tomcat和Cobalt Strike擁有相同的JARM指紋，這也解釋了為什么會有那么多的Weblogic和Tomcat應用被識別出來了。

因此不能直接通過JARM去判定CobaltStrike；同樣，對于CobaltStrike而言JARM也并不唯一，其JARM與不同JDK環境下TLS服務有關。JARM僅僅是一種TLS服務端特征的標識方式，只能作為一個輔助手段，不能完全被用作Web上層應用的唯一指紋。

看完上述內容，你們掌握如何識別惡意Cobalt Strike服務器的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！