github 地址:https://github.com/LilDean17/ShellcodeLoader2025
一、項目背景
近年來,隨著 C2 框架廣泛應用于安全對抗模擬,各大安全廠商也不斷提升其檢測能力,那么安全廠商自研的安全軟件,是否能有效防御此類威脅?對于此疑問的好奇,我開始對安全軟件和 C2 框架進行了深入的研究,于是此項目誕生了。此項目旨在模擬嚴苛的靜態環境來測試安全軟件對于 C2 框架的檢測力度。此項目對于研究安全問題的伙伴,對于安全廠商以及對于研發安全產品的企業提供了關于 C2 框架檢測相關的數據支持。
1.1 什么是 C2 框架?
C2(Command &Control 命令與控制)框架,特指滲透人員用于建立、管理和維持對已控系統(被控端)的集中化、結構化的軟件體系平臺。它是高級持續性威脅和定向攻擊的核心工具,實現了攻擊行動的數據竊取和橫向移動。其核心目標如下:
-
持久化:長期地潛伏在目標網絡而不被發現。
-
數據竊取:將竊取的機密數據傳輸回滲透人員。
-
任務執行:向被控端下發指令,用于執行惡意操作。
-
隱蔽通信:在受害者系統與攻擊者服務器之間建立難以檢測的通信通道。
-
集中化管理:提供滲透人與一個中心界面,用于批量控制大量被控端。
1.2 C2 框架的核心組件是什么?
-
C2 服務器:滲透人員的指揮中心,用于接收被控端連接、存儲指令和任務、收集滲透數據、管理被控端狀態。
-
被控端代理程序:用于植入在被控端的軟件程序,在目標系統上接收并執行 C2 服務器下發的指令,也是安全軟件對抗的核心。
-
C2 操作界面:滲透人員使用的圖形化或命令行界面。
C2 框架的核心架構圖如下:
1.3 為什么要使用 loader?
shellcode 作為威脅存在的一種重要形式,其存儲方式非常隱蔽,且可被攻擊者快速地傳播利用。loader 加載器是加載執行 shellcode 的一串代碼,它通常直接或間接的運行 shellcode 程序。為了測試安全軟件的功能性,觀測其在木馬隱蔽場景下的查殺率,所以選用 shellcode + loader 的方式測試安全軟件的功能。
1.4 靜態查殺與動態查殺的區別?
靜態查殺通常是通過掃描文件的靜態特征匹配病毒庫來判斷此文件是否屬于木馬家族或其他惡意文件,如果屬于,安全軟件則會發送告警。動態查殺通過監測可執行文件的行為,來匹配其是否屬于惡意文件,如果其觸發了安全廠商設定的敏感行為(如:修改注冊表),則觸發告警。
1.5 安全軟件對 shellcode 的檢測挑戰
由于 shellcode 以二進制形式連續存儲于內存之中,其可以被攻擊者實施加密存儲,因此靜態識別并查殺情況下,shellcode 具有非常強的隱蔽性,安全軟件需要多方面判斷來識別 shellcode 所運行的進程是否具有危害。這極大的要求了安全軟件在靜態查殺和動態查殺方面的結合,通過一系列復雜的判斷條件識別潛在的威脅。
二、軟件設計
為了測試各大廠商的安全軟件對于 shellcode 的識別能力,我自主開發了一套靜態混淆型 shellcode 加載框架用于測試。本項目由兩個子系統構成,分別承擔 shellcode 構建、加殼和加載的任務。
2.1 shellcode builder(構建端)
使用 python 實現,主要職責:
-
讀取 shellcode 文件。
-
初始化動態加密密鑰/iv,并進行加密和編碼。
-
初始化動態的函數哈希。
-
將以上所有配置信息注入到 shellcode loader(運行端)中。
-
使用 ollvm 混淆編譯 shellcode loader(運行端)。
包含模塊:
-
encrypt.py:加密模塊,用于生成動態 aes 密鑰和 iv 并加密數據。
-
patch.py:配置注入模塊,用于將如下信息注入到 shellcode loader:
-
動態生成的 aes key 和 iv。
-
動態生成的函數哈希。
-
加密編碼后的 shellcode。
-
-
compiler.py:編譯模塊,使用 ollvm 混淆編譯 shellcode loader。
2.2 shellcode loader(運行端)
使用 c 實現,主要職責:
-
通過對比函數哈希初始化 winapi 地址。
-
初始化 syscall 函數。
-
解密并還原加密的 shellcode 數據。
-
選擇加載方式進行加載(指針回調、纖程執行、winapi 回調)
包含模塊:
-
peb.cpp:用于讀取函數哈希初始化 winapi 函數地址。
-
syscall.cpp:用于初始化間接 syscall 函數。
-
decrypt.cpp:用戶解密解碼 shellcode。
-
cLoader.cpp:用于執行 shellcode。
2.3 架構圖
三、靜態混淆策略
3.1 函數哈希的隨機化
特征提取檢測是安全軟件檢測市面上木馬病毒常用手段,安全廠商通過提取特征碼并存儲到病毒庫中來匹配某一特定的惡意程序。通常情況下特征碼是從一些靜態數據或恒定的二進制代碼端提取的,為了避免被提取特征碼,我將一些靜態數據如函數哈希和密鑰/iv 做了隨機化處理,確保每一次生成的 loader 的靜態數據都是不唯一的。
3.2 shellcode 加密處理
shellcode 加密是最常見的混淆手段,在程序運行前,shellcode 同時是加密存儲在二進制文件中。加密存儲雖然有效,但是安全廠商也有針對的應對策略,基于熵值的檢測。shellcode 加密會導致文件熵值增高,這會導致可執行文件在安全軟件嚴重十分可以,為了避免熵值的膨脹,我們需要將加密后的數據轉換成合法數據。
3.3 shellcode 編碼處理
shellcode 編碼將加密后的數據轉換成合法數據,如:ipv4 地址、uuid、mac 地址等,此軟件實現 ipv4 地址和 uuid 編碼降低熵值。
3.4 ollvm 混淆
為了防止代碼段特征的提取,我使用了 clang 編譯器開發此軟件,重點使用此編譯器拓展的 ollvm 混淆功能。ollvm 混淆能有效提升編譯后的代碼復雜度和逆向難度,ollvm 有非常多的混淆機制:如控制流平坦化、指令替換、虛假控制流等。
3.5 動態混淆策略
由于此項目的目的是針對安全軟件對靜態混淆型 shellcode loader 的測試,而不是單一地去繞過某一安全軟件的檢測,所以只添加了最基礎的動態混淆的代碼以提升 shellcode loader 的存活率。動態混淆方面,此項目使用到了開源 syscall 工具 hell’s gate,結合本項目,其詳細功能如下:
-
動態解析 ssn 號:遍歷 ntdll 導出表。(動態解析 ssn 號,能防止源碼嵌入 ssn 號而提取靜態特征。)
-
直接 syscall:動態獲取 nt 函數地址并進行 0x12 偏移來提取多個 syscall 地址。
四、項目拓展
為了進一步測試安全軟件的功能,我對此項目進行了擴展。真實場景中 loader 不一定是 exe 可執行文件,它很有可能是 dll 文件。某些情況下,dll 文件可能通過進程劫持注入代碼。這種情況下,shellcode 的執行可能會更加隱蔽,為了模擬這種效果,我為我的項目實現了生成 dll 的功能。
五、安全軟件測試結果
本項目設計目標之一是驗證相同的靜態混淆策略對主流終端安全軟件的觸發行為差異,以評估各加載方式的有效性與隱蔽性。
5.1 測試環境
-
windows 10 22H2(x64)
-
測試平臺:VMware 17
-
是否接入互聯網:是
-
測試樣本(被控端代理程序):
-
cobaltstrike 4.8 beacon
-
havoc demon
-
-
安全軟件版本
-
Microsoft Defender(客戶端版本: 4.18.1909.6)
-
360 安全衛士(版本:13.0.0.2009)
-
火絨安全(個人版:6.0.6.6,病毒庫:2025.6.28)
-
卡巴斯基(企業版:kes 11.6.0.394)
-
5.2 測試方式說明
階段 | 說明 |
---|---|
靜態查殺 | 下載 loader 可執行文件并執行后是否觸發報毒。 |
解密解碼 | 解密解碼 shellcode 后是否觸發報毒 |
執行階段 | 開始執行是否觸發報毒 |
執行后 | 執行后進行常規操作是否觸發報毒(這里采用讀取文件信息進行測試) |
敏感操作 | 執行后進行敏感操作是否觸發報毒(這里采 用讀取系統進程信息進行測試) |
5.3 測試結果
cobaltstrike 4.8 beacon 測試結果
安全軟件 | 文件類型 | 靜態查殺 | 解密解碼 | 執行階段 | 執行后 | 敏感操作 |
---|---|---|---|---|---|---|
Microsoft Defender | exe 可執行文件 | ?觸發掃描,但未報毒 | ?內存明文存放 shellcode,未報毒 | ??立刻報毒 | 無 | 無 |
Microsoft Defender | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
360 安全衛士 | exe 可執行文件 | ?主動掃描,未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
360 安全衛士 | dll 劫持 | ??立刻報毒,標記為檢測到 dll 劫持 | 無 | 無 | 無 | 無 |
火絨安全個人版 | exe 可執行文件 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
火絨安全個人版 | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
卡巴斯基企業版 | exe 可執行文件 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
卡巴斯基企業版 | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
havoc demon 測試結果
安全軟件 | 文件類型 | 靜態查殺 | 解密解碼 | 執行階段 | 執行后 | 敏感操作 |
---|---|---|---|---|---|---|
Microsoft Defender | exe 可執行文件 | ?觸發掃描,但未報毒 | ?內存明文存放 shellcode,未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
Microsoft Defender | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
360 安全衛士 | exe 可執行文件 | ?主動掃描,未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
360 安全衛士 | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
火絨安全個人版 | exe 可執行文件 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
火絨安全個人版 | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
卡巴斯基企業版 | exe 可執行文件 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
卡巴斯基企業版 | dll 劫持 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 | ?未報毒 |
??注:以上測試僅用作數據參考,不代表安全產品的優劣。
六、測試結果分析
6.1 C2 框架測試結果對比
對比維度 | cobaltstrike 4.8 beacon | havoc demon |
---|---|---|
靜態檢測風險 | 高(即使高強度加密編碼,仍能被 360 啟發式識別) | 極低(無法識別) |
內存行為檢測風險 | 高(Defender 捕獲 exe 內存特征可以識別) | 極低(無法識別) |
感知強度 | 高(安全廠商針對性研究) | 極低(全平臺規避監測) |
6.2 各大廠商安全軟件測試結果對比
安全廠商 | 查殺方式類別 | 對 beacon 的響應 | 對 demon 的響應 | 查殺策略水平評估 | 初步技術判斷/推測機制 |
---|---|---|---|---|---|
Microsoft Defender | 內存行為感知 + 部分特征掃描 | ?? 執行階段立刻報毒 | ? 全程繞過 | ????(4/5) | 監控內存 + 內存掃描 |
360 安全衛士 | 啟發式判定 | ?? dll 劫持加載瞬間攔截,exe 無響應 | ? 全程繞過 | ???(3/5) | 啟發式判定系統評估 |
火絨安全軟件 | 以防護為主 | ? 全程繞過 | ? 全程繞過 | ??(2/5) | 未知 |
卡巴斯基企業版 | 未知 | ? 全程繞過 | ? 全程繞過 | ??(2/5) | 未知 |
6.3 什么是啟發式查殺?
啟發(heuristic):(一種教學方法)讓學生通過自己發現事物并從自己的經驗中學習,而不是通過告訴他們事物來學習。
啟發式查殺:給予安全軟件一定的規則,讓安全軟件以此規則作為經驗,去分析一個程序的合規性,而不是通過嚴格的邏輯推理來解決問題。常見的啟發式查殺經驗:
-
文件熵值過高。
-
導出表空但含大量代碼段。
-
導出表含大量函數,但代碼段很小。
6.4 Microsoft Defender 測試結果分析
查殺 beacon 原因推測分析如下:
執行階段立刻查殺,此時 shellcode 已被解密解碼,明文存儲在內存中。但是,Microsoft Defender 全程監控此進程內存,當檢測到 shellcode 的內存由 RW -> RX 修改時,掃描該區域并匹配到 beacon 特征。
未檢測到 dll 劫持原因推測分析如下:
完全忽視 dll 劫持場景,不對進程進行監控。
未檢測到 demon 的原因:
未分析并提取 demon 特征。
6.5 360 安全衛士測試結果分析
瞬間查殺 beacon 的 dll 劫持原因推測分析如下:
啟發式判定系統檢測到可疑 dll(導出表可疑等),最主要的判定其為惡意 dll 的原因是分析加密編碼后的 shellcode 的特征,如:
-
即使 aes 加密 + uuid 編碼,其 payload 長度與 beacon 做同樣操作后長度類似。
-
aes 加密 + uuid 編碼后長度過長,引起懷疑。
未檢測到 exe 中的 shellcode 的原因如下:
啟發式判定系統認為 exe 中存在過長的數據是合理行為。
dll 劫持未查殺 demon 的原因:
-
缺乏 demon payload 的確切特征。
-
aes 加密 + uuid 編碼后長度非常小。
6.6 火絨安全軟件測試結果分析
未檢測到 shellcode 的原因:
個人版以安全防護為主,考慮真實用戶體驗。
6.7 卡巴斯基企業版測試結果分析
卡巴斯基企業版即使開啟云查殺等所有功能,但仍未檢測到 shellcode 的原因:
-
個人研發的 loader 具備強大的靜態混淆能力,幾乎達到 100% 的靜態混淆。
-
未對內存中的明文 shellcode 進行掃描。可能掃描機制是延遲或事件觸發型。
-
卡巴斯基可能沒有 360 那種對 beacon payload 的泛化機制,它沒有對 aes 加密 + uuid 編碼的 shellcode 起疑心
本實驗使用卡巴斯基企業版默認配置,聯網環境并開啟云查殺,但在本測試環境下確實未觸發檢測機制。
??注:以上結論可能導致對卡巴斯基的查殺水平錯誤低估,請理性看待。
6.8 總結
針對嚴苛靜態無特征化的 shellcode loader 有用的技術:
-
內存監控 + 內存掃描
-
啟發式判定
七、使用方法
7.1 運行環境
-
Python:3.11.0
-
ninja:1.12.0.git
-
clang:20.1.5(ollvm)
-
vs 2022 C++ 桌面開發環境
-
python 庫:pycryptodome=3.20.0
-
python 庫:pyfiglet=1.0.2
注:以上是本人使用的運行環境,僅僅作為參考。
7.2 支持參數
-
--i:用于輸入 shellcode.bin 文件。
-
shellcode 的 文件路徑。
-
-
--exec:用于設置執行方式。
-
thread:創建線程執行 shellcode。
-
fiber:創建纖程執行 shellcode。
-
callback:Winapi 回調函數執行 shellcode。
-
-
--encode:
-
ipv4:用于將加密的 shellcode 編碼成 ipv4 地址。
-
uuid:用于將加密的 shellcode 編碼成 uuid 地址。
-
-
--file:
-
exe:用于指定生成 exe 文件。
-
dll:用于指定生成 dll 文件。
-
-
--export(僅在生成 dll 文件情況下生效):
-
文件路徑:用于指定 dll 文件的導出函數。
-
?
其中 --export 導出函數文件存儲如下示例內容:
7.3 構建過程
使用如上默認配置進行構建,python 將執行如下操作進行構建:
配置注入:
-
獲取 loader 的項目路徑(c 語言) 。
-
獲取 shellcode.bin 文件路徑,讀取、加密、編碼并 patch 到源文件。
-
初始化 aes 密鑰和 iv,并 patch 到源文件。
-
初始化 Winapi 函數哈希,并 patch 到源文件。
編譯 loader:
-
構建并編譯 loader。
?
構建完成后,在 build 目錄下會生成 loader。
八 、項目價值與邊界
8.1 應用場景價值
本項目設計初衷為在合法授權的環境中,用作以下內容的研究與評估:
-
安全軟件測試評估:測試安全軟件在嚴苛的靜態對抗環境下的檢測能力。
-
安全軟件行為研究:測試安全軟件用于檢測威脅的技術方式。
-
教學與演示:適合作為教學樣例,展示設計架構和靜態混淆技術。
-
提供數據:向研究人員提供數據參考。
8.2 合規邊界聲明
本項目不包含任何惡意 payload 或遠控功能,僅提供 loader 框架和加密封裝機制,所有測試 payload 必須由用戶在合法授權環境下自行提供,且盡在授權環境中使用。
8.3 作者聲明
-
本人不對任何非法使用本項目代碼所產生的后果負責。
-
嚴禁在未授權的目標環境中部署與測試。
-
若您是安全廠商/研究人員,歡迎就技術實現展開探討。
九、聲明與許可
9.1 項目免責聲明
本項目僅供安全研究、教育教學和防御評估。不得將其用于任何非法用途,包括但不僅限于未授權滲透、后門植入等。所有示例均在授權環境下進行測試。