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

本篇文章給大家分享的是有關如何進行越南APT攻擊樣本的深度分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

一、前言

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

Eleven Paths旗下Innovacio?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

7. 該函數會判斷是不是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通信開始，如下圖示所示：

圖片三十二：建立通信

9. 繼續分析，使用函數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攻擊樣本的深度分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。