威脅情報是指在信息安全和安全防御領域，收集、分析和解釋與潛在威脅相關的信息，以便預先發現并評估可能對組織資產造成損害的潛在威脅，是一種多維度、綜合性的方法，其通過信息的收集、分析和研判，幫助組織了解可能對其安全構成威脅的因素。這種方法不僅僅著重于技術層面，還包括了社會、心理、政治等多個維度，以此更好地應對不斷變化和復雜化的威脅環境。旨在為分析人員提供關鍵信息，幫助他們采取預防措施和應急響應策略，從而降低威脅應對實施的風險和影響。

前言

隨著愈發嚴峻網絡攻擊對抗環境，網絡威脅情報逐漸在攻擊行為分析中扮演著不可或缺的角色。網絡威脅情報的重要性主要在于其能夠幫助組織了解自身所面臨不斷變化的威脅，提供數據驅動的防御策略，減少潛在的風險和損失，并為建立更強大的信息安全體系提供支持。

本文聚焦于針對C2基礎設施視角下的威脅情報對抗策略，文內筆者將對于威脅情報分析過程的攻防思路展開論述。從高級攻防過程中，攻擊者的視角來看威脅情報的分析思路，淺析在情報研判及狩獵過程中存在的問題。在工作過程中，筆者發現，站在攻擊視角看待威脅情報是十分必要的，我們需要從攻擊者的角度去思考威脅情報中可能存在的不嚴謹的地方。當發生攻擊行為時，研判人員的分析思路是基于自己對于攻擊的理解還是客觀情報？相信通過本文讀者將對此有所思考。由于威脅情報的對抗概念較為廣義，涵蓋了很多不同的細分方向，限于篇幅，本文將僅講解C2基礎設施對抗的方向。

本文僅為作者個人觀點，如有不恰，請指正。

攻擊者視角下的威脅情報研判思路

在看到疑似攻擊行為時首先應該想一下，我們所看到的威脅情報是否完全真實？分析安全事件時，威脅情報應作為輔助判斷依據，但不應該是決定性的因素。分析人員判斷安全事件的第一準則即“行為”，而行為概念在網絡空間測繪中也有體現，但是兩者之間存在互通又具有歧義。在威脅情報流量側狩獵的過程中，行為主要是該主體做了什么，聚焦于通信過程，而測繪中則為個體獨有特征，目的為最終能夠形成指紋。但是該主體所表現得特征同樣可以作為威脅情報的聚焦信息之一，以此來關聯其某一組織的資產設施。

行為：不同的群體，可能表現出基本的獨有的特征，當我們能掌握到這個特征，那么我們就能盡可能識別出這個群體里的所有個體，而這些行為特征在網絡空間測繪里表現出的是這個設備各個端口協議里的banner特征。

這里可以把行為理解為特征，而如何提取這些特征，進行更加精準的匹配無疑也成為了最重要的環節之一。

為了形成某APT組織的設施資產，我們應該提取這些設施所表現的**“行為”，從而構建出能夠指向性該組織資產的指紋，所以繼而我們要引入一些更加“精準”、“特異”、“不可更改”**的個體特征，可以決定性的指向某個人或團伙的資產范圍，既要精準的區分目標資產又要具有特異性，不可以被輕易修改的特點。

這里我認為，在威脅情報針對某一組織或某特殊C2設施的資產標記時，分析人員可以通過做出相關指紋進行初步資產過濾，再進一步對關聯到的資產進行驗證，最終同步到威脅情報中，而威脅情報的狩獵，寧可不全，也不要出現不準確的情況，給后續面對攻擊事件的分析人員造成誤導。

針對惡意樣本的威脅狩獵，針對樣本側進行定位，分析流量側通信情況，同步至威脅情報端，體現在情報側對C2進行綜合研判，標注惡意行為這樣的過程。而流量在這個過程中起到了至關重要的作用，在當下的攻防對抗進程中，武器化工程師對于樣本的生成已經做到了很精巧的地步，各種白+黑層出不窮，所以通信行為無疑是需要更加注意的地方，用一句話來總結就是不要看它的外在，而要看做它了什么事情。

C2設施通信特征：

• 回連地址
• 通信內容
• 特殊信道
• 通信頻率
• 持續時間
• .....

我覺得，通信內容的檢測始終是一個難點，經過加密的通信流量，無法獲知加密后的通信數據，傳統明文檢測使用的規則匹配、載荷還原檢測等流量檢測技術無法對加密會話所傳遞信息內容進行檢測。像C3 這類利用流行應用程序的合法功能來偽裝受感染端點和 C2 服務器之間通信使得威脅追蹤更加困難，面市面上針對加密流量檢測的產品面對高版本TLS協議基本是束手無策的。通信頻率即心跳包，稍加進行心跳靜默+偏移即可繞過，這也是基本操作。因此，在以后的攻擊者對抗中可能會開始發現利用更隱蔽的C2信道，情報團隊應加快分析端點機器數據以便快速檢測整個殺傷鏈中的威脅。

針對自簽名類樣本，代碼簽名的指紋無疑是一個不錯的思路。

14.png

我認為根據代碼指紋為基礎，可以針對一些自簽名的證書樣本做關聯，之前有了解過微步的OneSec，那么有沒有可能以此去關聯組織中傳輸的惡意樣本之間的關系。他這個簽名的指紋，應該是以該證書簽名的程序均是同一個，而攻擊者通常會給程序進行白+黑簽名，對應多個樣本的前提是他們都是這個證書簽名的。**如果在終端設備上已經部署了Agent，那么將關聯終端可疑程序的簽名指紋對比，以云沙箱的檢出情報為基礎，識別相同代碼簽名的惡意程序，來作為一個檢出依據，我認為這樣的思路如果應用在組織架構的環境下應該是可行的。**當然，具體可行性還是要專業人員思考，理論商所有以Agent端部署作為防護基礎的設備應該都是可以借鑒的。

組織應始終關注自身風險暴露面，以情報為驅動，關注輿情（代碼泄露、聯系方式、數據泄露、供應鏈風險），可能某些數據泄露事件的后期影響會直接導致相關組織發生安全事件。隨著組織業務的發展，業務云上化、移動辦公需求、合作伙伴、分支機構的拓展，安全風險會逐步上升，所以需要更加關注近期發生的安全情報。 站在攻擊者的角度，滲透并不會從最安全的位置發起，而是觀察與目標有關聯的互聯網資產、輿情以此作為移動至目標組織的特殊橋梁，須知木桶原則是從防御體系最薄弱的地方突破的。

總結一下，在威脅情報的狩獵過程中，未命中、發現的情報始終是最重要的，攻擊已經成為事實的情況下，再進行情報狩獵分析只能在某種程度上減少組織的損失。威脅情報分析團隊應加強針對正在進行攻擊、已經發生攻擊的事件的關注，在此基礎上發掘將要發生攻擊的事件，及時將攻擊事件根據情報推送至處于高風險的行業，及時排查，將安全事件風險降低，做到事先預防、事后有效處置的舉措。

對抗C2威脅情報的策略與實施

命令與控制服務器，也稱為 C&C 或 C2，攻擊者使用它來維持與目標網絡內受感染系統的通信。“命令”和“控制”這兩個術語經常被廣泛使用，過去十年中，惡意網絡攻擊呈上升趨勢。最具破壞性的攻擊之一通常通過 DNS 執行，是通過C&C完成的，命令和控制被定義為威脅行為者用于通過網絡與受感染設備進行通信的技術。

顧名思義，命令和控制服務器向受感染的系統（通常是家庭用戶的連接互聯網的計算機，然后形成僵尸大軍，稱為僵尸網絡）發出命令和控制。這些通信可以像維護定時信標或“心跳”一樣簡單，以便運行攻擊的操作員可以保留他們在目標網絡中受到損害的系統的清單，或將它們用于更惡意的操作，例如遠程控制或數據傳輸。滲漏。雖然命令和控制服務器用于控制目標組織內部的系統，但通常是受感染的主機發起從網絡內部到公共 Internet 上的命令和控制服務器的通信。【Command-and-control servers: The puppet masters that govern malware】By Adam RiceJames Ringold, Westinghouse Electric Company

希望讀者通過閱讀本小段能夠從攻擊者的角度思考安全防范策略，了解新型的C2設施防護手段，本段也將從對抗威脅情報的C2基礎設施的方法實施論講解。下圖為通過微步Graph生成的示意圖，讀者可以先閱讀正文然后再看該圖例，加強理解相關技術思路，以實現更好的閱讀效果。

baidu.png

[^微步情報]: Graph概覽

RedGuard是基于命令與控制（C2）前端流控技術的衍生工具，具有更輕量級的設計、高效的流量交互以及可靠的兼容Go編程語言開發。隨著網絡攻擊的不斷演變，紅藍團隊隨著演練變得越來越復雜，RedGuard旨在為紅隊提供更好的C2通道隱藏解決方案，為C2通道提供流量控制，阻斷“惡意”分析流量，更好地完成整個攻擊任務。

RedGuard是一款C2前端流量控制工具，可以躲避Blue Team、AVS、EDR、Cyberspace Search Engine的檢測。

Github下載地址

https://github.com/wikiZ/RedGuard

偽造TLS證書

在部署域前置隱匿C2流量時，默認情況下加速的域名是不具備HTTPS證書信息的，這樣顯然是存在問題的，所以配置域名時需要注意對證書進行配置，這也是判斷樣本是否為域前置流量的默認依據。

1.png

[^騰訊云]: 內容分發網絡證書配置

相信看到這里，大家會有所疑問，**配置的證書怎么獲得？如果使用自己申請證書是不符合我們預期想達到的隱匿效果。**這里可以使用克隆的證書進行配置，以騰訊云為例，測試中發現其不會對自定義上傳的證書進行校驗有效性，我們可以使用與加速域名實際站點相同的證書進行偽造。雖然偽造的證書在正常情況下替換CS的默認證書是無法通信的，但是在云服務廠商CDN全站加速和RedGuard上面部署是不會進行校驗有效性并且可以正常通信C2交互流量。

以下為Github已有項目地址

https://github.com/virusdefender/copy-cert

盡管樣本域前置流量側的證書已經解決，但是站在大網測繪的角度來看，我們的C2服務器仍然暴露于外，依然可能被探測到真實C2服務器并實現關聯，這時就可以通過RedGuard修改C2的前置默認證書實現隱匿。

2.png

[^微步社區情報信息]: 數字證書

以上即為C2服務器偽造的證書效果，可以看到在微步社區的情報中是可信且未過期的狀態，而其獲取數字證書的主要途徑也是在云沙箱進行樣本分析時進行提取并實時更新的，但是顯然沒有經過有效校驗，狀態值僅對失效時間進行驗證，證書可信驗證應該是只以是否能夠正常通信作為判斷依據。

需要注意的是，微步情報并不會對樣本請求的SNI及HOST的地址進行標注證書情報，這其實也是出于防止出現誤報的考量，**我認為這是正確的，作為輔佐研判人員分析的重要依據，威脅情報寧可不全，也最好不要出現錯誤指向，對后續分析造成誤判。**如果說在全站加速配置證書是偽造通信流量的證書，那么配置RedGuard C2的前置響應證書就是為了針對部署于公網的真實C2服務器的行為特征進行偽造，以實現抗測繪的效果，這是十分必要的。

提取證書序列號：55e6acaed1f8a430f9a938c5，進行HEX編碼得到TLS證書指紋為：26585094245224241434632730821

Search Result Amount: 2291

通過網絡空間測繪發現2291個獨立IP，進行驗證確定均為百度所屬TLS證書，如果單從通信流量來看是比較難判斷是否為惡意通信的，而上面針對域前置+C2前置流量設施的TLS證書進行了偽造，成功對空間測繪與威脅情報實現了干擾，造成了錯誤的信息關聯，使得攻擊者的流量特征更加逼真，實現了偽造正常通信流量的目的。

3.png

[^RedGuard]: 使用默認證書的RG資產

哪怕在C2流量前置設施之前不存在隱匿轉發的處理，也最好對RedGuard進行更改證書。默認狀態下，任何目前在網絡空間測繪里常用的通用組件指紋識別形成的指紋庫就是利用了通用組件默認配置特征這個行為來進行識別的，在這些自定義過程中不同的群體又可能表現出不一樣的獨有特征。當然，指紋的形成需要對目標組件具有一定理解，從而提取出目標的默認特征，形成關聯指紋。這里利用RG證書表現的行為特征進行網絡空間測繪，關聯到了大量部署在公網的RG節點。

作者能夠提取出該指紋不足為奇，但是依然建議RedGuard用戶修改的默認證書信息，做一個專業的Hacker:)

劫持站點響應

相信不少讀者對劫持響應會比較感興趣，大概原理為當客戶端對真實的C2服務器發起請求時，由于不符合入站規則，所以C2服務器會獲取指定的正常站點并返回其響應信息，所以從效果請求端來看好像是與該IP進行服務交互，但是實際是以中間C2服務器為代理服務器與正常站點進行交互，很難發現異常。而如果符合入站請求時，則會將流量請求轉發至真實的C2服務監聽端口進行交互，而真實監聽端口已經被云防火墻過濾，僅允許本機訪問，從外部是無法直接訪問的。所以從外部端口開放情況來看僅開放了該HTTP/S端口，而某種意義來說這也確實為C2的上線端口。

7.png

[^流量示意圖]: C2服務器流量交互過程

在網絡空間測繪數據中，該IP的HTTP/S開放端口響應碼為200，不是302跳轉，更加具有真實性。

8.png

HTTPS證書與上述偽造證書效果相同，均為真實證書的指紋。

9.png

相信不少紅隊在打項目的過程中，都會廣泛的使用云函數/域前置一類的隱匿手段，但是在今天的攻防對抗的博弈中，上述兩種隱匿手段均存在一個致命的問題，就是可以直接連通C2服務，而這些導致結果無疑就是當我們掌握到云函數地址或者域前置的交互IP/HOST即可直接訪問C2監聽服務并證明其為攻擊設施。

11.png

由于流量可以直接到達C2，那么這里不妨思考一下，安全設備針對SNI與HOST不相符的流量是否可以進行CS掃描來識別是否為惡意流量，云函數或者沙箱環境也為同理，除去樣本側也可以多一些流量層面的分析過程。

而當進行劫持響應后，直接訪問HTTP服務是可以正常網站交互的，但是Cscan是無法掃描出樣本信息的，因為流量無法到達真實的C2監聽器，只有當滿足流量發起的特征時才可以正常C2交互，但是這就存在一個問題，C2掃描的腳本需要符合入站規則，這對藍隊分析人員的代碼能力也就具有了一定考驗，目前公開的掃描腳本為Nmap形式的。

12.png

這里提一點Tips，除卻域前置，也可以嘗試搶注一些高信譽的域名，而一些組織可能會疏漏注冊某些域名，這時可以搶注然后使用隱藏WHOIS信息服務作為交互域名，可信度更高。

13.png

P.S.深信服大哥能不能回購啊，我留著沒用 >_<

識別云沙箱指紋

JA3為客戶端與服務器之間的加密通信提供了識別度更高的指紋，通過 TLS 指紋來識別惡意客戶端和服務器之間的 TLS 協商，從而實現關聯惡意客戶端的效果。該指紋使用MD5加密易于在任何平臺上生成，目前廣泛應用于威脅情報，例如在某些沙箱的樣本分析報告可以看到以此佐證不同樣本之間的關聯性。

如果可以掌握 C2 服務器與惡意客戶端的JA3(S)，即使加密流量且不知道 C2 服務器的 IP 地址或域名，我們仍然可以通過 TLS 指紋來識別惡意客戶端和服務器之間的 TLS 協商。相信看到這里大家就能想到，這也正是對付域前置、反向代理、云函數等流量轉發隱匿手段的一種措施，通過沙箱執行樣本識別與C2之間通信的 TLS 協商并生成JA3(S)指紋，以此應用于威脅情報從而實現輔助溯源的技術手段。

該技術在去年的時候就已經公布，在測試微步沙箱環境時發現，其請求交互的出口IP雖然數量不大，但是通過IP識別沙箱并不準確，并且這是很容易改變的特征，但是其在相同系統環境下JA3指紋是唯一的。后續得到反饋稱沙箱已完成指紋隨機化，但是近期通過測試發現仍沒有完全實現，還是希望可以正視流量側指紋的問題。

目前主要為以下JA3指紋：

• 55826aa9288246f7fcafab38353ba734

在云沙箱的立場上，通過監控樣本與C2服務器之間流量交互生成JA3(S)指紋識別惡意客戶端從而進行關聯，而我們逆向思考，同樣作為C2前置的流量控制設施，我們也可以進行這樣的操作獲取客戶端請求的JA3指紋，通過對不同沙箱環境的調試獲取這些JA3指紋形成指紋庫從而形成基礎攔截策略。

設想在分階段木馬交互的過程中，加載器會首先拉取遠程地址的shellcode，那么在流量識別到請求符合JA3指紋庫的云沙箱特征時，就會進行攔截后續請求。那么無法獲取shellcode不能完成整個加載過程，沙箱自然不能對其完整的分析。如果環境是無階段的木馬，那么沙箱分析同樣無法最終上線到C2服務器上，想必大家都有睡一覺起來C2上掛了一大堆超時已久的沙箱記錄吧，當然理想狀態下我們可以對不同沙箱環境進行識別，這主要也是依賴于指紋庫的可靠性。

在測試的過程中，我發現在指紋庫添加ZoomEye GO語言請求庫的JA3指紋后監測RG請求流量情況，大部分的請求均觸發了JA3指紋庫特征的基礎攔截，這里我猜測該測繪產品底層語言是以GO語言實現的部分掃描任務，通過一條鏈路，不同底層語言組成的掃描邏輯最終完成了整個掃描任務，這也就解釋了部分測繪產品的掃描為什么觸發了GO語言請求庫的JA3指紋攔截特征。而其與云沙箱指紋的識別規則原理是相同，均利用了請求客戶端環境及請求庫的唯一性，區別于PC端，這些產品的請求環境基本上是不會隨意更改的，這也導致了我們能夠掌握到其流量側指紋并攔截，那么是否可以思考安全設備是否可以把主動探測流量的JA3指紋作為攔截依據？當然，當業務流量較大時可能會有一定的誤報，這里僅提出理論上可實施的產品需求。

P.S.讀者也可以自行上傳樣本至沙箱中獲取并驗證其JA3指紋添加至指紋庫，需要注意的是，如果沙箱僅更改JA3指紋不為上述指紋是沒有意義的，真正需要解決的是每次沙箱動態分析時均不為同一指紋，而其變化需要滿足盡可能的不重復，如果重復率較高依然會被作為指紋使用。

自定義樣本指紋

這里提出一個實戰場景，當攻擊者希望不同監聽器均對應獨立樣本，而在某一樣本被捕獲或希望其**“失效”的情況下，能夠指定樣本流量是否允許放行到達C2，這時就可以使用自定義樣本指紋。該功能基于對Malleable Profile自定義設置HTTP Header字段作為樣本指紋“樣本Salt值”，為相同C2監聽器/Header Host提供唯一辨識。**此外，結合其他相關請求字段生成的木馬樣本指紋，可用于檢測自定義樣本存活性。

根據攻擊方任務要求，木馬樣本指紋識別功能可針對希望失效的樣本進行“下線操作”，更好地規避惡意研判流量的樣本通聯性關聯及分階段樣本PAYLOAD攻擊載荷獲取分析，給予攻擊方更加個性化的隱匿措施。針對不同C2監聽器，可以給不同的Malleable Profile配置別稱、自定義相關header的字段名和值作為樣本Salt值，以此作為區分不同樣本之間的唯一辨識。下列代碼是為了方便說明，而在實際攻防場景下我們可以給予更加貼合實際的HTTP請求包字段作為判斷依據。

http-get "listen2" {
	set uri "/image.gif";
	client {
		header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //用戶自定義字段名及值
		metadata {
			print
		}
	}
}

HTTP流量

5.png

如圖所示，我們根據上述樣本Salt值及Host字段作為指紋生成依據，這里我們已知:

• Salt值：866e5289337ab033f89bc57c5274c7ca
• Host字段值：redguard.com

根據對上述值進行拼接并使用32位小寫MD5哈希得到sample指紋為：

redguard.com866e5289337ab033f89bc57c5274c7ca	//拼接后待哈希字符串
d56da55231dfd8e9a4f3ad2e464f49e4				//Sample FingerPrint

目前已知上述樣本指紋，現在我們在RedGuard配置文件中設置自定義的Header字段及樣本指紋用于惡意流量攔截。**值得注意的是，這里的Header字段及值可以自定義為更符合實際的，這里為了更好的展現效果所以Accept-Finger與長字段的Hash為例。**我們可以拓展多個樣本指紋，不同指紋之間FieldName和FieldFinger字段用逗號分隔，FieldName字段需要和Malleable Profile中配置的Header字段名稱保持一致，這也是獲取請求包所攜帶Salt值的重要依據。

6.png

因為RG的配置文件為熱配置，所以這里我們不需要重新啟停RG即可實現針對希望失效的樣本進行攔截，當我們希望該樣本重新生效時，只需在RG配置文件中刪除相關樣本指紋即可實現。

蜜罐惡意誘捕

蜜罐惡意誘捕的原理主要是依賴于RG流量導向的劫持響應or重定向功能，將研判C2設施的分析者導向蜜罐沙箱的地址，在劫持響應的狀態下，RG會將不符合入站規則的請求流量導向蜜罐資產中，而碰到一些比較厲害的蜜罐（例如抓取運營商手機號那種），客戶端就會依照目標站點的響應發起請求被jsonp劫持到相關信息。

試想，當分析人員對C2上線端口直接訪問就會被導向至蜜罐資產，造成的結果無疑就是對分析人員造成了擾亂，而分析人員被惡意導向請求蜜罐資產，蜜罐監測端則捕獲到藍隊分析人員的相關信息從而錯誤溯源。如果從開始分析目標就是錯誤的，又怎么會得到好的結果，無疑對防守隊伍造成了嚴重的內耗。

這里給大家提供一組關聯蜜罐資產的ZoomEye指紋：

(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之協同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA辦公系統") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")

4.png

而實現這一效果的方式非常簡單，僅需更改RG配置文件相關鍵值即可。

# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action   = proxy
# URL to redirect to
Redirect      = https://market.baidu.com

P.S.相信不解釋大家也知道該怎么配置:)

該方式算是一種奇淫巧計吧，更多的是體現在思路上，如果進一步利用就可以在C2前置流量控制設施部署蜜罐捕獲的功能然后再進行交互流量導向，效果也就是如傳統蜜罐一樣能夠獲取客戶端的瀏覽器緩存數據。但是個人感覺在公開版本中，應用于現階段的攻防對抗可能意義不大，攻擊者捕獲得到藍隊分析人員的社交信息再進行溯源是無意義的操作。當然退一步來想，這或許會讓C2樣本的分析更加危險，當黑灰產的攻擊者能夠獲取得到分析人員的虛擬身份后，如果能夠做到虛實身份的轉換，那么還是比較危險的。所以我認為，以后的研判分析應該更加謹慎，提高警惕意識。

后記

又到了比較輕松的階段，這也是我寫文章最喜歡的環節，已經一年沒有寫過文章了，也沒有關注安全方向，嗯。。可能會有些不跟形勢。剛剛完成了第四年的HW經歷，有朋友說的一句話讓我印象深刻，“感覺，HW對我們來說就是參加了一場跟我們關系不大的熱鬧”，哈哈哈哈，感覺十分貼切啊。回首自己的安全經歷，感覺依然是學的比較雜，難道是博觀而約取，厚積而薄發？給自己后期的規劃可能也不會主要去做技術，實話說我一直不是一個喜歡追求技術的人，所以在我畢業之后可能會去做面向接觸人和技術打交道的工作崗位，而不是專注于安全研究。我給自己的定位是一個善于理解+聯想+創新的人，可能說白了就是一個善于總結創新的人吧，所以我始終喜歡接觸新興事物，因為這樣總能讓我有所啟發，發現一些不一樣的東西。2023是全新的開始，風起依然在路上。

最后，祝大家心想事成，美夢成真!

作者：風起

本文作者：風起， 轉載請注明來自FreeBuf.COM