Ghostwriter攻擊活動中的加密通信

一、背景

今年2月份，俄烏沖突爆發后，在物理戰場之外，以俄烏為主的多方勢力在網絡空間也展開了激烈較量。3月初，在社交平臺上，研究人員公開了一個針對烏克蘭的攻擊樣本（MD5：2556A9E1D5E9874171F51620E5C5E09A）。隨后，烏克蘭CERT也發布通告，將該攻擊樣本歸屬于APT組織UNC1151，該組織疑似隸屬于某東歐國家。

UNC1151組織是“Ghostwriter”活動背后的攻擊者，該活動的重點攻擊目標是烏克蘭、立陶宛、拉脫維亞、波蘭和德國的政府和私營部門實體，以及白俄羅斯持不同政見者、媒體實體和記者。“Ghostwriter”活動中，UNC1151使用高度針對性的魚叉式網絡釣魚發起攻擊，并使用看似合法的域名作為C2服務器。此次攻擊中，攻擊者通過郵件下發了一個Dropper，Dropper經過一系列釋放過程后執行開源后門MicroBackdoor，該后門使用RSA+RC4混合加密方式和C2服務器進行通信。

二、樣本下發

攻擊者通過釣魚郵件下發CHM格式的攻擊文件，CHM文件是微軟推出的基于HTML文件特性的幫助文件系統，雙擊攻擊文件，會默認用Windows自帶的hh.exe程序打開并執行內置的HTML代碼。其中HTML代碼分為JavaScript、vbs兩部分，其中JavaScript負責展示誘餌圖片，如下圖所示：

圖1樣本誘餌圖片

Vbs代碼則會釋放一些系列文件來執行攻擊，具體流程如下：

1. CHM攻擊文件釋放“ignit.vbs”樣本和“desktop.ini”樣本；
2. “ignit.vbs”樣本釋放三個文件：“core.dll”、“Windows Prefetch.lnk”、“desktop.ini”；
3. “Windows Prefetch.lnk”被釋放到啟動目錄下，用于實現持久化；
4. “desktop.ini”調用“C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe”加載“core.dll”；
5. “core.dll”文件執行后會再次釋放一個DLL文件，該DLL文件是開源的后門程序MicroBackdoor；
6. 通過后門程序MicroBackdoor和固定的域名“xbeta.online”、端口“8443”的C2服務器建立連接，期間會釋放一個臨時RSA證書文件“C:\Users\xxx\AppData\Local\Temp\Tmpxxxx.tmp”，用于后續加密通信使用。

圖2下發流程

三、加密通信流程分析

此次攻擊的通信過程通過開源后門MicroBackdoor實現，樣本內部存放了固定的域名“xbeta.online”和端口“8443”，客戶端解析域名得到IP后根據IP、端口和C2服務器建立連接。通信過程使用的是TCP協議，使用RSA身份驗證加密協商產生RC4隨機會話密鑰用于實際的數據加密通信。

整個通信過程分為兩個階段，第一階段是驗證過程，由客戶端發起驗證請求，和服務端進行身份驗證并完成密鑰的協商。第二階段是命令交互階段，客戶端通過select函數持續等待服務端命令下發，收到命令后解密并執行。

圖3客戶端通信

3.1驗證階段

1. 客戶端根據IP和端口創建套接字并連接，準備向服務端進行驗證通信。

圖4發起TCP連接

2. 由客戶端先向服務器發出驗證請求包，其中包含三個內容：客戶端版本信息、RSA證書的SHA1摘要以及隨機生成的RC4密鑰。

圖5驗證請求包結構

客戶端版本信息由客戶端決定，為固定值；SHA1摘要是從RSA證書獲取的中，該證書由服務器生成并內嵌在客戶端中；RC4密鑰會在每次會話隨機生成，長度為128位。

圖6構造驗證請求

根據證書獲取RSA公鑰，然后將上述內容用零補齊到和RSA公鑰相同長度（256字節），使用RSA公鑰加密后作為驗證請求包發送給服務端。

圖7加密并發送驗證請求

3. 服務端接收到驗證請求包后，用RSA私鑰進行解密，解密后會驗證客戶端版本和RSA證書的SHA1摘要是否正確。驗證通過后，保存RC4密鑰并計算RC4密鑰的MD5值發送給客戶端作為響應包。

圖8服務端驗證客戶端

4. 客戶端收到響應包后，計算RC4密鑰的MD5值并和響應包的內容進行驗證，驗證通過后則驗證通信階段完畢，等待服務端下發命令。

圖9客戶端驗證服務端

3.2命令交互階段

通信雙方驗證無誤后，后續通信中全部使用協商好的RC4密鑰進行加密。客戶端通過select函數持續等待服務端命令。收到服務端發出的命令后，客戶端使用RC4密鑰進行解密，解析并識別命令，然后執行。執行后將結果上傳給服務端時，也會使用RC4密鑰加密后發送。

圖10接收命令并解密

下圖為MicroBackdoor支持的命令，包括獲取本機信息，執行程序，反彈shell，上傳下載文件等常規遠控功能。

圖11命令列表

3.3流量數據分析

本次分析的樣本未獲取到實際的C2服務端私鑰，不能進行數據的解密。

圖12實際加密攻擊流量

我們通過模擬木馬通信過程，從中得到的流量各階段數據如下。

在驗證階段雖然數據都進行了加密，但是流量長度固定，客戶端發起的驗證請求包為256字節（RSA公鑰長度），服務端返回的響應包長度為16字節（MD5長度）。

圖13實驗驗證交互數據

在命令交互階段，由于命令長度不固定，且數據全部使用了RC4加密，所以無法獲取有效特征。只有獲取到服務端的RSA私鑰后，才能對數據進行解密。

圖14實驗命令執行數據

下圖為服務端的RSA私鑰文件和證書，RSA私鑰文件和證書由攻擊者自己生成。

圖 15 實驗服務端上的公私密鑰

   依據證書中的公鑰和私鑰文件可以對加密數據進行解密。先使用上圖RSA私鑰對驗證請求包的載荷進行解密，解密后輸入如下。

使用解密后獲取的RC4密鑰對后續的命令交互過程進行解密，解密后可以發現命令為“id”。

圖17實驗命令解密

圖18解密命令為“id”

四、分析小結

此次攻擊采用TCP自定義加密通信，使用RSA身份驗證加密協商產生RC4隨機會話密鑰用于實際的數據加密通信，全程加密通信。攻擊產生的流量中，驗證階段有明顯的流量長度特征，驗證請求包和響應包為固定長度。從加密機制來看，獲取到服務端私鑰才能將流量進行解密。

同時，我們也可以看到越來越多的APT組織頻繁利用TCP、UDP、HTTP等傳輸層和應用層協議進行自定義加密方式傳