如何進行越南APT攻擊樣本的深度分析

一、前言

APT已經成為了安全領域熱門的話題。

Eleven Paths旗下Innovación y laboratorio 4月發表《Docless Vietnam APT》報告：

上述資訊表述，我們偵測到一些惡意郵件寄到屬於越南政府的信箱，這封越南文郵件的日期是2019年3月13號。這封郵件有可疑因素，可能是來自越南政府內部，但也不能排除有人投送該郵件到安全部門。

TKCT quy I nam 2019.doc.lnk.malw樣本資訊如下：

圖片一：TKCT quy I nam 2019.doc.lnk.malw

二、靜態分析

1. TKCT quy I nam 2019.doc.lnk.malw樣本被下載到本地後，巧妙偽裝成Word快捷方式，欺騙受害運行或者習慣性雙擊查看，如下所示：

圖片二：偽裝doc快捷方式

首先word文檔一般不會是.lnk鏈接，鏈接的大小應該在1kb左右，而該APT樣本快捷方式竟然126kb，很明顯隱藏著別的東西，很多病毒把檔名偽裝成.dat、.docx等，其實後綴是.exe，開啟檔名擴充就可以看到。

2. 提取樣本屬性中目標包含的惡意程式碼，發現是經混淆加密的一段cmd指令，且執行powershell，如下所示：

圖三：混淆指令

APT攻擊手段非常青睞vbs、powershell、js等型別腳本語言，容易混淆與加密，而且方便做免殺處理。

所以歷來的病毒及惡意軟體都有這種共通性，如蔓零花、Xbash、勒索都喜歡執行powershell作為第一個「見面禮」（payload）送給電腦當作驚喜。

3. 解析混淆指令，發現重定向TKCT quy I nam 2019.doc.lnk快捷方式到s.sp1文件，其實桌面快捷方式是一個powershell的腳本文件，梳理混淆變量如下所示：

最終將TKCT quy I nam 2019.doc.lnk重定向到temp資料夾下，命名為s.ps1執行該powershell，如下所示：

圖片四：去混淆

4. 手動去除iex混淆也是可以的，打開文件去掉“iex”這幾個字符，powerhell運行指令格式：文件名（原） >> s.sp1（新檔案名稱）即可，重定向檔案如下所示：

圖片五：powershell惡意代碼

5. 如圖五所示，發現了兩段Base64編碼的數據，powershell意圖將編碼後的惡意數據執行，添加定時任務，每9分鐘執行創建，利用了InstallUtil服務實現了自啟動與持久性化，有意思的利用Wscript.Shell執行，越出其不意越有意想不到的效果，如下所示：

############### ######圖片六：s.sp1######6. Base64編碼資料解析後，其實是兩個可執行文件，分別是惡意.net與.doc，執行手段如下圖所示： ########################圖片七：通用的套路######7.分析tmp_pFWwjd.dat.exe，經過dnSpy工具反彙編後，程式碼清晰可見，雖然有一些小混淆（可以使用de4dot.exe去混淆即可），不影響程式碼程度。 ######定位關鍵函數Exec(),發現Base64String編碼的數據，根據執行流程，由.NET去委託去調用函數Call，而且是可讀可寫，那麼就要申請內存VirtualAlloc(),將Base64shellcode拷貝到申請記憶體中，取得CreateThread()指針委託執行回調指針，執行惡意的shellcode，如下所示：###

圖片八：.net反組譯

如何理解shellcode或payload？本質上可以是說一堆十六進位組成的數據，對於可執行檔來說則是能夠被彙編引擎所解釋執行的數據。

因為下面將會涉及二進位資料擷取與組譯分析，所以這裡做了一副簡單的圖先介紹關於shellcode或payload基本概念(針對惡意程式碼)，如下圖所示：

圖片九：payload

如圖九所示，對於病毒來說，特別是可自啟動，持久化攻擊,沒有後門很難實現（漏洞持續化利用，每次拉取少量流量做資料竊取之類的除外）。

舉例來說，ASLR位址隨機化每次系統重啟後基址都會改變，或是注入到新的進程空間，程式碼本身的函數基址都是錯誤的，如何精準的取得函數位址？從而達到完美運行，需要格外的一些操作，當然這些都不是問題，技術相對成熟。

假設讀者俱備一定的Windows PE格式、彙編和核心相關知識，則以下知識講解將更易理解。不會普及基礎知識，將從PE格式及彙編層面去分析這些shellcode如何去做，如何實現動態獲取模組基址如kernel32.dll，如何利用散列值或Hash遍歷導出表，過免殺敏感字串及敏感函數API等。

三、PE與病毒雜談

以上述的惡意程式碼舉例，因為.net執行shellcode偵錯過程中遇到許多問題，所以用c/c 還原了tmp_pFWwjd.dat.exe樣本。

再一次OD進行動態調試，當然可以Dump下來分析，根據個人愛好，直接在執行shellcode下斷，如下所示：

圖片十：Pointer

1. 入口點進入，接著就是資料的異或解密，將需要真正執行的惡意程式碼還原，如下所示：

# #圖片十一：異或解密

2. 散列值加密字串，這樣的好處既可以減少shellcode體積，而且可以隱藏敏感字符，不容易被殺毒軟體截獲，如下所示：

圖片十二：雜湊值取得函數位址

3. 我們進入函數1E0A42，發現一堆看上去很平常的賦值運算，如下所顯示：

圖片十三：fs:[0x30]

Fs是暫存器，核心態是fs = 0x30，使用者狀態fs = 0x3B，fs在內核態指向_KPCR，用戶態指向_TEB。

TEB(Thread Environment Block)，執行緒環境塊，也就是說每一個執行緒都會有TEB，用於保存系統與執行緒之間的數據，以便於操作控制。那麼Fs:[0x30]就是PEB進程環境塊。

4. PEB就是當前進程環境，shellcode就可以輕易獲取PEB信息，透過偏移0xc獲取到了_PEB_LDR_DATA,這個結構體包含有關進程的已加載模組的信息.

透過偏移0x1c取得到一個雙向循環鍊錶，每個鍊錶指向LDR_DATA_TABLE_ENTRY結構體，這個結構體包含的資料我們來看一下，以上資料偏移與作業系統有關，如下所示：

圖片十四：取得模組基質

圖片十五：取得目前環境模組基底步驟

5. 透過上述的過程，就會成功取得如ntdll.dll，如下所示：

#圖片十六：取得模組Address

##6. 繼續分析函數1E0B2A,兩個參數，根據函數呼叫約定，參數1是kernel32基底位址，參數2是函數名稱散列值，函數則是一個自己實作的GetProcAddress()函數，如下所示：

圖片十七：GetProcAddress

這個函數的目的是檢查是否符合PE標準格式，並取得NT頭和匯出表。匯出表保存了三張表的位址，先來看導出表結構體，如下圖所示：

惡意程式碼需要定位到這三張表的位址，遍歷函數名稱表AddressOfName,取得函數名稱進行雜湊值計算，如果與參數2雜湊值相同，則意味著是同一個函數。

傳回目前遍歷的下標，透過下標去函數序號表AddressOfNameOrdinals找到對應的序號，取得序號表保存的數值，在函數位址表中取得AddressOfFunctions，如下圖所示簡單表述了三者關係：

圖片十八：三者關聯

如上圖所示，序號表與名稱表一一對應，下標與下標中儲存的值是相關聯的，這三張表設計巧妙，利用了關係型資料庫的概念。

要注意的是，序號不是有順序的，而且會有空白。地址表中有些沒有函數名，也就是地址表有地址卻無法關聯到名稱表中，這時候用序號調用，序號內容加上Base序號基址才是真正的調用號。

8. 當有了這些認知，再來看樣本中的惡意程式碼，會發現與上述的描述是一摸一樣的，如下所示：

圖片十九：GetProcAddress()

9. 最後驗證結果是否成功，如下所示：

圖片二十：驗證

11. 創建了新得線程，線程回調會創建目錄及文件，但是本地驗證創建文件失敗，如下所示：

圖片二十一：建立目錄

建立檔案及目錄名稱路徑c:\User\......\AppData\Roaming\

11. 伺服器回應及下載惡意程式碼，這將開啟一段新得旅程，如下所示：

圖二十二：DownLoader

#四、vkT2模組分析

1. 跟進函數後我們發現了大量的雜湊值，動態獲取函數位址，與上述函數呼叫一致，梳理函數名稱如下：

1E0AAA函數解密如下：

##2 . 做了預熱操作，其實根據函數名稱，應該猜測到接下來會發生什麼，如下圖所示：

#圖片二十三：InternetOpenA

圖片二十四：InternetConnectA

#圖片二十五：HttpOpenRequestA

3. 動態偵錯過程中會卡住在請求，靜態分析程式碼，lstrcmpiA比較下載資料的指紋資訊text欄位是否為plain，然後利用InternetReadFile讀取下載資料執行，否則的話將陷入睡眠、請求死循環狀態。

圖片二十六：請求狀態

我們根據已知的ip與請求格式，直接造訪該網頁，如下所示：

圖片二十七：vkT2

發現Web解析的全是亂碼？下載到本地，根據原始程式碼執行流程，這是一段二進位數據，老規矩寫個程式來調試這段惡意程式碼。

4. vkT2分析，先是解密了數據，然後動態取得函數位址,樣本慣用的老套路了。

循環拼接各區段(節表)數據，這裡按照VirtuallAddress，各區段在加載到內存後的地址循環拼接，內存的對齊粒度0x1000，抹掉了DOS頭特徵碼,形成了一個PE格式文件，如下所示：

圖片二十八：記憶體擴充

5. 既然是PE格式擴展到了記憶體裡面，接下來就是修復了IAT表與重定位了，這裡涉及的面比較多，還屬於PE格式內容，可查閱《Windows權威指南》，如下圖所示：

#圖片二十九：修正IAT

6. 接下來分析關鍵要點，取得了系統變量，判斷是否運行在64bit系統上，如下所示：

圖片三十：判別運作環境

8.系統資料、主機ip、主機名稱等資訊收集，如下所示：

#圖片三十一：資料收集

9. 新一輪的C&C通訊開始，如下圖示所示：

圖片三十二：建立通訊

對於進一步分析，可以使用HttpOpenRequest和HttpSendRequest函數開啟該檔案。 HttpOpenRequest建立個請求句柄並且把參數儲存在句柄中，HttpSendRequest把請求參數送到HTTP伺服器，如下所示：

圖片三十三：HttpOpenRequest

圖片三十四：HttpSendRequestA

11. 遺憾的是HttpSendRequeSt已經沒有什麼回應了，靜態分析剩餘的程式碼(模擬執行)，讀取伺服器回傳的惡意程式碼，有用到線程安全上下文。

情報分析沒找到更有價值的數據，不過這種請求方式很獨特，而且建構的資料包也很特別，下面會講到這樣做的特殊性。

關聯樣本過程，梳理執行流程圖如下所示：

#圖片三十五：TKCT quy I nam 2019.doc執行流程

如圖三十五，客戶端通訊的伺服器應該都是代理伺服器，其實真是的環境遠遠要比上述過程複雜更多，這也是溯源的難點。

如圖三十三，在堆疊記憶體中提取關鍵的資料訊息，這與往常的我們所見到的請求資料不太一樣，梳理如下所示：

APT通訊的手段越來越謹慎，如果不進行詳細的樣本分析，沙箱模擬運行、內訪問證、抓包工具來對網絡層面進行分析，結果與想要的數據可能有一定的出入，樣本進行通訊的時候，其實實用到了域前端網路攻擊技術。

什麼是網域前端網路攻擊技術？簡單點來說可以將msf、cs（Cobalt Strike）等團隊控制伺服器的流量，目的用來繞過一定程度的防火牆與檢測器，一些較大的廠商都會提供服務，所以用msf或cs等工具都可以實現。

我們用Cobalt Strike這款工具舉例，整合了連接埠轉送、掃描多模式連接埠Listener、Windows exe程式生成、Windows dll動態連結庫生成、java程式產生、office巨集程式碼生成，包括網站複製擷取瀏覽器的相關資訊等。

其中比較有用的一個功能就是Beacon payload的行為，修改框架預設屬性值，更改檢入的頻率及修改Beacon網路流量，而這些功能的設定都在檔案Malleable C2。

Malleable-C2-Profiles功能就可以做到建構一個正常的Web偽裝流量，最後達到通訊隱匿的效果，我們摘取amazon.profile舉例，如下圖：

set useragent "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko";http-get {Seturi"/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books";client {header "Accept" "*/*";header "Host" " www.amazon.com ";metadata {base64;prepend "session-token=";prepend "skin=noskin;";append "csm-hit=s-24KU11BB82RZSYGJ3BDK|1419899012996";header "Cookie";}http-post {set uri "/N4215/adj/amzn.us.sr.aps";client {header "Accept" "*/*";header "Content-Type" "text/xml";header "X-Requested-With" "XMLHttpRequest";header "Host" " www.amazon.com ";parameter "sz" "160x600";parameter "oe" "oe=ISO-8859-1;";id {parameter "sn";}parameter "s" "3717";parameter "dc_ref" "http%3A%2F%2F www.amazon.com ";}

上述程式碼與樣本vkT2.shellcode通訊的特徵完全匹配，透過載入對應的profile文件，來改變目標主機與server端的流量特徵，以此來隱藏流量，最終達到通訊隱匿的目的。

以上是如何進行越南APT攻擊樣本的深度分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！