背景

CobaltStrike（簡稱CS）作為一款滲透測試神器，采用C/S架構，可進行分布式團隊協作。CS集成了端口轉發、服務掃描、自動化溢出、多模式端口監聽、Windows exe與dll 木馬生、Java 木馬生成、Office 宏病毒生成、木馬捆綁等強大功能，深受廣大紅隊同學的喜愛。為了規避偵測，紅隊往往會對CS采用一些隱匿手段，常見方式有云函數和CDN等。這些隱匿手段隱匿了CS的真實IP，諸如DDoS之類的流量無法穿透CDN到達CS，常規的攻擊方式難以對CS服務器形成有效干擾和打擊。只能止步于此了嗎？有沒有反擊CS的奇技淫巧？答案當然是肯定的！接下來帶各位看官體驗一種批量偽造肉雞來戲耍CS的新方法，希望各位藍隊同學引（付）以（諸）為（實）戒（踐）。

CS上線流量特征分析

首先，我們先研究下CS上線的流量有無特征。圖1使用Wireshark分析HTTP型Beacon的上線包。

圖1

肉眼來看，上線包的敏感信息隱藏到了Cookie中，特征非常明顯。通過進一步分析，我們發現上線包的請求Cookie值是受控主機元數據經過非對稱加密后的密文，CS服務器接收到Cookie值后進行解密從而獲取到受控主機信息。受控主機元數據包含了若干敏感信息，如圖2所示：

圖2

此處劃重點，HTTP型Beacon 上線包的核心在于Cookie，而Cookie是對受控主機元數據的非對稱加密的密文。

HTTP Beacon重放實驗

由于HTTP屬于明文傳輸協議，HTTP型Beacon的上線過程存在中間人重放的可能。

我們做了一個簡單的測試，驗證了這種可能性（此處迫于運營小姐姐壓力，稍微有湊字數嫌疑）。

首先抓取測試環境中的HTTP Beacon上線請求，使用Python腳本（如：圖3）進行重放（注意：Header頭信息不能錯誤，CS Server對Header頭檢查非常嚴格）。

圖3

結果顯示，重放Response符合我們的預期，CS Server成功響應了我們的請求。（如：圖4）

圖4

此外，紅隊同學在使用CS時候會自定義Malleable C2 Profile修改默認流量特征，但是這個對中間人重放沒有影響。

新的問題產生了。

中間人重放的方法，只能偽造已經上線的主機，不能偽造新的受控主機。

這句話翻譯過來就是，沒啥鳥用。

好了，字數湊夠了。書接上回，言歸正傳。

現在聚焦最迫切的問題：有沒有辦法偽造全新的受控主機呢？

答案當然是肯定的。

新主機偽造

我們先看一個效果圖（如：圖5）。

圖5

短時間內大量主機上線。想想1分鐘上線了千八百個主機，紅隊同學是不是有點慌？這是如何做到的呢？

我們以Stager型Beacon為例，按照KillChain模型從攻擊者角度回顧下CS上線流程（如：圖6）。

圖6

攻擊者利用CS Server生成新的Beacon監聽（包括一對非對稱公私鑰）并生成Stager；

攻擊者投遞Stager到受控主機；

受控主機在Exploit階段執行小巧的Stager；

受控主機根據Stager Url請求特征向Beacon Staging Server下載體積較大更復雜的Stage到本地，Beacon Staging Server會校驗Url的合法性；

Stage解密并解析Beacon配置信息（比如公鑰PublicKey、C2 Server信息）；

Stage通過公鑰PublicKey加密主機的元數據并發送至C2 Server；

C2 Server用私鑰解密數據獲取主機元數據。

從上述流程中，我們能Get到2個核心點：

Stager Url校驗算法

Beacon配置的解密算法

與CS Server合法通信的問題等價轉換為獲取Stager Url和Beacon解密問題，即：

CS/C2 Server合法通信 = （Stager Url校驗算法，Beacon解密算法）

只要拿到了（Stager Url校驗算法，Beacon解密算法），相當于我們掌握了與CS/C2 Server合法通信的憑據。我們分別對上述2個核心點進行分析。

Stager Url校驗算法

Stager Url校驗算法在公開的NSE腳本中可以找到，關鍵函數包括：checksum8、MSFURI、isStager。

其中，MSFURI函數從大小寫字母+數字的字符數組中隨機指定長度的字符序列并調用checksum8函數計算字符序列的ASCII和與256的模是否等于固定值（32位Stage與64位Stage分別使用92、93作為固定值），如果相等返回字符序列，否則繼續直至找到符合條件的字符序列。MSFURI（如：圖7）、checksum8（如：圖8）、isStager（如：圖9）函數的定義：

圖7

圖8

圖9
如果找到符合條件的字符序列，則作為Stager Url向Beacon Staging Server發送下載請求。Beacon Staging Server在_serve函數中校驗Url的合法性，如：圖10。

圖10

至此，我們獲取到了Stager Url的校驗算法，手動下載Stager。下載效果如圖11下：

圖11

很好！已經成功一半了。接下來，我們再來研究Beacon配置的解密算法。

Beacon配置解密算法

感謝前人栽樹！

之前已經有人發布了Beacon配置的解密算法，比如JPCERT的Volatility插件cobaltstrikescan（https://github.com/jpcertcc/aa-tools/blob/master/cobaltstrikescan.py）、美國SentinelOne安全公司開源的CobaltStrikeParser工具（https://github.com/Sentinel-One/CobaltStrikeParser）等。

具體的解密算法此處不再贅述，感興趣的同學可參考上述的開源工具。解密結果如圖12所示：

圖12

從解密的配置中可以看到PublicKey和C2 Server地址。

OK！2個算法我們都已經搞定，接下來就該反擊CS了！

反擊！

萬事俱備，只欠東風！

想象以下場景：藍隊同學防守時獲取到了一個CS的上線地址。

首先，構造Stager Url下載Stage，如果在抓到CS上線地址的同時抓到了Stage，此步可跳過。

然后，解析Stager Beacon的配置文件，得到了PublicKey公鑰與C2 Server地址。

最后，構造虛假主機元數據，加密發送至C2 Server。

Github上開源的CobaltSpam（https://github.com/hariomenkel/CobaltSpam）已實現此功能，但CobaltSpam上線的主機信息都是隨機生成，很容易被識破。因此，需要將主機信息偽造的更加準確，提高混淆度。

最終，通過修改CobaltSpam代碼，添加自定義的更加精準的主機信息，達到了我們想要的效果，如：圖13。

圖13

最終效果見下圖（圖14）！！！

圖14

結語

通過這種以假亂真的方法，藍隊同學可很好的混淆紅隊同學的視線，以此來反制攻擊者。

對于低級的攻擊者而言，目前不能夠很好的防御這種攻擊手段。

同樣，上面提及的2種算法可用于Beacon Staging Server和C2 Server的挖掘。

目前，防御上述反制的方法，可通過修改CS代碼上述2種算法的邏輯，阻止虛假主機上線和C2挖掘。

在HVV過程中，如果發現紅隊的CS木馬樣本或者CS服務器，我們可以用上述方法來混淆紅隊同學的視線、拖延他們的時間，讓紅隊同學陷入懷疑人生的地步。

【網絡安全學習資料筆記】

總結

以上是生活随笔為你收集整理的反击CobaltStrike的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。