文章首發地址：https://xz.aliyun.com/news/18222文章首發作者：T0daySeeker概述
近期，筆者在日常攻擊活動分析中，發現了某最新攻擊活動中的系列樣本攜帶了多個國內正常數字簽名，進一步分析，發現其中的“Chengdu Nuoxin Times Technology Co., Ltd.”數字簽名曾被Higaisa APT組織使用過。
為了一探究竟，筆者嘗試對此次攻擊活動中系列樣本的技術手法進行了詳細分析梳理：
-
攻擊活動中使用了多個國內正常數字簽名，用於偽造惡意程式的合法性，繞過安全檢測，數字簽名如下： -
Chengdu Nuoxin Times Technology Co., Ltd. -
海口市勤萊佳科技有限公司 -
對比歷史APT攻擊活動中的數字簽名 -
2023年10月26日，Cyble安全團隊釋出的《Higaisa APT Resurfaces via Phishing Website targeting Chinese Users》攻擊活動中，存在攜帶Zhiya Yunke (Chengdu) Finance and Tax Service Co., Ltd.數字簽名的惡意樣本； -
2024年10月09日，毒霸安全團隊釋出的《Higaisa 組織近期活動分析，利用仿冒頁面進行釣魚攻擊》攻擊活動中，存在攜帶Chengdu Nuoxin Times Technology Co., Ltd.數字簽名和Zhiya Yunke (Chengdu) Finance and Tax Service Co., Ltd.數字簽名的惡意樣本； -
2024年12月12日，奇安信威脅情報中心釋出的《國內最大IT社群CSDN被掛馬，CDN可能是罪魁禍首？》攻擊活動中，存在攜帶Chengdu Nuoxin Times Technology Co., Ltd.數字簽名的惡意樣本； -
此次攻擊活動中的技術手法 -
白+黑技術載入攜帶正常數字簽名的惡意dll檔案，白檔案為騰訊影片應用程式； -
攜帶正常數字簽名的惡意dll檔案啟動後，將使用RC4演算法解密.edskv檔案並在記憶體中載入執行，RC4演算法解密金鑰由.txt檔案生成； -
解密後的.edskv檔案實際為XtremeRAT遠控木馬； -
嘗試對此次攻擊活動中的碼址進行關聯分析，又關聯發現大量惡意樣本攜帶了國內其他正常數字簽名，數字簽名如下： -
Chengdu Nuoxin Times Technology Co., Ltd. -
GZ.PurestJone Network Technology Co., Ltd. -
Harman International Industries, Incorporated -
Hena Luxion Network Technology Co., Ltd. -
Hoozoou Leeser Smart Technology Co., Ltd. -
Klimine Far Year Electronic Commerce Co., Ltd. -
Meizhou Fisherman Network Technology Co., Ltd. -
PrimeSnap Technologies Network Company -
Shanghai Linyao Network Technology Co., Ltd. -
Shenzhen Xiangyou Network Technology Co., Ltd. -
Ventis Media, Inc. -
海口市勤萊佳科技有限公司 -
運城市鹽湖區風顏商貿有限公司
威脅情報線索
起初，筆者關注到X社交平臺上的一條威脅情報線索，情報線索上提到某惡意樣本攜帶了成都某公司的數字簽名，進一步分析，發現“Chengdu Nuoxin Times Technology Co., Ltd.”數字簽名曾在多個攻擊活動中出現過。
-
X社交平臺
-
《Higaisa 組織近期活動分析，利用仿冒頁面進行釣魚攻擊》攻擊活動
-
《國內最大IT社群CSDN被掛馬，CDN可能是罪魁禍首？》攻擊活動
2025052868PNG.pif
樣本基本資訊如下：
檔名稱：2025052868PNG.pif檔案大小：39592 位元組檔案版本：15.0.0.0修改時間：2025年5月28日 17:51:26MD5 ：445B4EFED7865395B51E157813A4F008SHA1 ：13A2D8BA2A14C5DAA0B4792D0CBA716171F22D47CRC32 ：27F796DB編譯語言 ：C#正常數字簽名
透過分析，發現此樣本是一款.NET樣本，攜帶了正常的數字簽名：Chengdu Nuoxin Times Technology Co., Ltd.
相關截圖如下：
外聯下載執行
進一步分析，發現此樣本執行後：
-
將向
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/V.txt地址發起外聯請求，獲取後續載荷下載地址； -
外聯下載後續載荷檔案：
-
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/LogManager.dll -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/commonbase.dll -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerMainModule.dll -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.edskv -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.txt -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/image.jpg -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/VideoManagerEntry.exe -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/msvcp140.dll -
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/vcruntime140.dll -
載入執行VideoManagerEntry.exe樣本，觸發後續惡意行為；
相關程式碼截圖如下：
https://videomanagerentry.s3.ap-northeast-1.amazonaws.com/V.txt外聯請求響應內容如下：後續載荷檔案梳理
嘗試對後續載荷檔案進行梳理，梳理內容如下：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
image.jpg檔案截圖如下：
VideoManagerEntry.exe
透過分析，發現此樣本為正常騰訊影片檔案，對應騰訊影片版本為11.120.1281.0（當前騰訊影片客戶端的最新版本）
相關截圖如下：
載入惡意LogManager.dll
進一步分析，發現攻擊者採用了白+黑的技術手法載入惡意LogManager.dll的ReleaseLogManager函式。
相關程式碼截圖如下：
惡意LogManager.dll
正常數字簽名
透過分析，發現此樣本是一款偽造的惡意LogManager.dll檔案，攜帶了正常的數字簽名：海口市勤萊佳科技有限公司
相關截圖如下：
載入惡意commonbase.dll
進一步分析，發現此樣本執行後，將載入惡意commonbase.dll的IW2tkUqqoIoErrUR3IlsSkUsHtZdoYB函式。
相關程式碼截圖如下：
此外，在此樣本的匯出表中，還發現了大量相同長度的隨機字串匯出函式，除IW2tkUqqoIoErrUR3IlsSkUsHtZdoYB函式外，其餘匯出函式程式碼內容均為空。
相關截圖如下：
惡意commonbase.dll
正常數字簽名
透過分析，發現此樣本同樣攜帶了正常的數字簽名：海口市勤萊佳科技有限公司
相關截圖如下：
解密.edskv檔案
透過分析，發現此樣本執行過程中，將讀取本地目錄下的.txt檔案和.edskv檔案內容，使用.txt檔案內容生成解密.edskv檔案的解密金鑰，解密.edskv檔案生成最終遠控木馬載荷。
-
解密前檔案內容如下：
-
解密後文件內容如下：
記憶體載入遠控木馬
成功解密VideoManagerEntry.edskv檔案後，樣本將在記憶體中載入並執行記憶體木馬的FJYSA8D1ACE89219943A45570628FEE12787KTAC函式。
相關程式碼截圖如下：
解密演算法剖析
在分析過程中，筆者發現此次攻擊活動中的碼址關聯的其他樣本的攻擊手法與此次攻擊活動的攻擊手法基本相同，均會在記憶體中解密載荷並載入。
因此，筆者琢磨，若能成功梳理其最後解密載荷的解密演算法，則可在不動態除錯的情況解密最終木馬載荷。
分析流程如下：
-
透過動態除錯確定最終木馬載荷其實是由.edskv解密所得； -
解密函式中，將傳遞兩個引數，一個是.edskv加密檔案內容，一個是“FHKAA8D1ACE89219943A45570628FEE12787”值（「推測是解密金鑰」）； -
嘗試對“FHKAA8D1ACE89219943A45570628FEE12787”值進行分析，發現此值實際是由“FHKA”字串和“A8D1ACE89219943A45570628FEE12787”字串構成，“A8D1ACE89219943A45570628FEE12787”字串有點像MD5值； -
進一步分析，發現“A8D1ACE89219943A45570628FEE12787”字串實際是由.txt檔案內容計算所得，**但是，直接計算.txt檔案內容得到的MD5又不是A8D1ACE89219943A45570628FEE12787。。。**神奇。。。 -
進一步分析，發現在生成“A8D1ACE89219943A45570628FEE12787”字串的過程中確實是呼叫了MD5演算法，但最終生成的值不同。 -
為了搞清楚上述MD5值的計算過程，筆者嘗試構建了MD5演算法程式碼進行除錯對比，「最終發現：原來此程式計算MD5時，將原始.txt檔案中的字串轉換成了UNICODE編碼，但是計算MD5時使用的字串長度卻是ASCII編碼字串長度」。。。坑。。。不清楚是故意為之還是無意之舉。。。
解密.edskv檔案
透過分析，梳理解密.edskv檔案的邏輯為：
-
讀取VideoManagerEntry.txt檔案內容，呼叫MD5演算法生成解密金鑰； -
讀取VideoManagerEntry.edskv檔案內容，配合解密金鑰解密生成後續遠控木馬載荷檔案；
相關程式碼截圖如下：
“通義千問”識別解密演算法
嘗試對解密VideoManagerEntry.edskv檔案內容的解密演算法進行剖析，筆者發現，此解密函式並沒有像MD5、AES演算法一樣的運算元特徵，若非經驗可能一時半會還不是很好剖析出其演算法型別。
相關程式碼截圖如下：
基於此，筆者琢磨，AI其實在自動化程式碼識別方面有一定的優勢，可能會比人工識別準確度更高。
因此，筆者嘗試使用了「阿里雲百鍊上的通義千問大模型」對上述IDA中的解密函式虛擬碼進行分析，發現其成功識別出上述解密函式實際為RC4演算法。
相關截圖如下：
嘗試使用CyberChef平臺進行驗證，發現可成功基於RC4演算法（金鑰：FHKAA8D1ACE89219943A45570628FEE12787）對VideoManagerEntry.edskv檔案進行解密。
相關截圖如下：
生成解密金鑰的一個小坑
在分析由.txt檔案內容生成解密金鑰的過程中，筆者其實還是花費了一點時間，不過好在最終搞明白了其底層原理。
VideoManagerEntry.txt檔案內容如下：
動態除錯過程中，筆者發現傳入.txt檔案中的字串實際是UNICODE編碼格式，字串長度實際是ASCII編碼字串長度：0xB == 11
相關程式碼截圖如下：
嘗試使用CyberChef平臺，按照上述邏輯計算MD5，發現得到的MD5值與上述解密金鑰中的MD5相同。
相關截圖如下：
自動化解密指令碼
基於上述解密演算法邏輯，筆者嘗試構建了一個自動化解密指令碼，解密效果如下：
自動化解密指令碼程式碼如下：
package mainimport ("crypto/md5""crypto/rc4""encoding/hex""flag""fmt""os""strings")// 計算MD5值funccalculateMD5(data []byte)string { hash := md5.Sum(data)return hex.EncodeToString(hash[:])}functextToUnicodeHex(text string)string {var hexBuilder strings.Builderfor _, r := range text { hexBuilder.WriteString(fmt.Sprintf("%X00", r)) }return hexBuilder.String()}funcmain() {// 定義命令列引數 txtFile := flag.String("txt", "", "Path to the .txt file") edskvFile := flag.String("edskv", "", "Path to the .edskv file") flag.Parse()// 驗證引數if *txtFile == "" || *edskvFile == "" { fmt.Println("請提供 .txt 檔案和 .edskv 檔案路徑") fmt.Println("用法: go run decrypt_files.go -txt <text_file> -edskv <edskv_file>") os.Exit(1) }// 讀取 .txt 檔案內容 txtContent, err := os.ReadFile(*txtFile)if err != nil { os.Exit(1) } unicodehex := textToUnicodeHex(string(txtContent)) txtContent_unicode, _ := hex.DecodeString(unicodehex) key := "FHKA" + strings.ToUpper(calculateMD5(txtContent_unicode[:len(txtContent)])) fmt.Printf("解密金鑰: %s\n", key)// 讀取 .edskv 檔案內容 edskvContent, err := os.ReadFile(*edskvFile)if err != nil { os.Exit(1) }// RC4解密 cipher, err := rc4.NewCipher([]byte(key))if err != nil { os.Exit(1) } decrypted := make([]byte, len(edskvContent)) cipher.XORKeyStream(decrypted, edskvContent)// 儲存解密後的內容到新檔案 outputFile := strings.TrimSuffix(*edskvFile, ".edskv") + "_decrypted.bin" err = os.WriteFile(outputFile, decrypted, 0644)if err != nil { os.Exit(1) } fmt.Printf("解密後文件：%s,MD5： %s \n", outputFile, calculateMD5(decrypted))}VideoManagerEntry.edskv
樣本家族
透過分析，在此樣本的字串中發現了
Please, send a email to XtremeCoder ---> [email protected]字串。嘗試對此字串進行網路調研，發現此字串其實是XtremeRAT遠控木馬內建的字串資訊。相關截圖如下：
進一步分析，發現此樣本的字串還存在
Embarcadero Delphi for Win32 compiler version 28.0 (21.0.17707.5020)字串，說明此樣本是由Delphi語言編譯，與網路中關於XtremeRAT遠控木馬的編譯語言一致。相關截圖如下：
網路調研截圖如下：
互斥物件
透過分析，發現此樣本執行後，將建立互斥物件
hkuewdbghrgxv，用於確保主機中只存在一個程式例項執行。相關程式碼截圖如下：
外聯通訊
樣本執行過程中，將根據ConnectIp登錄檔項選擇不同的外聯地址進行外聯通訊。
-
u.arpuu.com|#3158|：外聯地址實際在commonbase.dll檔案中； -
kimhate.com|#1516|：外聯地址在當前遠控木馬中；
相關程式碼截圖如下：
遠控功能
透過分析，發現此樣本遠控功能函式中，存在200餘個switch case分支呼叫，包含常見的檔案遍歷、程式執行等遠控功能模組。
相關程式碼截圖如下：
XtremeRAT模擬
為了更直觀的瞭解XtremeRAT遠控木馬，筆者嘗試在網路中找到了一個XtremeRAT 3.8遠控程式（老版本），成功配置木馬端程式並上線，發現XtremeRAT遠控木馬支援的功能還比較全面，支援近40餘個遠控行為操作。
配置木馬端程式截圖如下：
木馬上線後遠控功能截圖如下：
關聯擴線分析
為了更全面的瞭解此次攻擊活動，筆者嘗試基於VT平臺對此次攻擊活動中的碼址進行關聯分析，發現：
-
此次攻擊活動中的碼址，最早可追溯至2025年3月21日，截至筆者分析時，每天都有新的關聯樣本產生； -
嘗試提取多個樣本進行分析，發現其最終釋放的樣本Hash相同，均為此次攻擊活動中的XtremeRAT遠控木馬； -
嘗試提取關聯樣本中的數字簽名，「發現大量除此次攻擊活動外的國內其他正常數字簽名」；
梳理不同數字簽名的代表樣本列表如下（備註：樣本量大，因此每個數字簽名只列舉了一個樣本）：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
相關截圖如下：
數字簽名調研
嘗試基於企查查對數字簽名中的公司名稱進行調研，結果如下：