# T5 Virus 解題思路
{%hackmd theme-dark %}
## 題目資訊
Download：https://tinyurl.com/yd72y3ty [已過期]
報名表：https://tinyurl.com/ycmf4yu4 [已過期]

- Virus: b6eeed4fd8eb48126ffb216fd392ae74.zip
- (密碼:infected)
-
- 上述連結內，含有一個惡意程式樣本
- - b6eeed4fd8eb48126ffb216fd392ae74
- 麻煩您嘗試分析此樣本，並且記錄以下資訊：
- [x] 執行流程
- [x] 檔案資訊
- [x] 封包內容
- [x] 常駐方式
- [x] 加解密方式
- [ ] 後門功能
- [ ] 中繼站資訊
- [x] 相關的情資
- [x] 其他有趣的發現
- [x] 研究花費的總時數
- [x] Write-up

請詳述分析的流程、使用的工具... 等等，盡可能描述與呈現更多您的思考過程，或找到的任何可能跡象，有助於讓我們更了解您的分析程序

P.S. 提醒您，此樣本為真實樣本改造，可能仍有危險性，請勿在 VM 外執行
執行流程

## 環境設定
### 首先將檔案放到虛擬環境中
- [虛擬環境資訊](https://drive.google.com/file/d/1Yecg-cKpNieo1WuLuorzjDCdKsJiztPI/view?usp=sharing)
- VMware Fusion
- OS: Windows 7(6.1) x64
- 軟體與版本
- upx: 3.96
- IDA Pro: 7.0
- OllyDbg: v1.10
- Process Hacker: 2.39
- Wireshark: 3.2.2
- PE-bear: v0.4.0.2
- PE Viewer: 2
- Regshot: 1.9.1
- CFF Explorer: 8
### 將 Network Adapter 調整成 host only（如下圖）
這邊不連接 Network Adapter 或者可以將 Network Adapter 設定成 Private to my Mac，確保分析樣本不至於影響內網的其他 IP。


### 設定 Snapshots(如下圖)
- 我主要 snapshot 的時間點
- 放入分析樣本之前(確保乾淨環境)
- 放入分析樣本之後(尚未執行樣本前)
- 開始分析樣本之後（想確保特定的狀態）

### 開啟監控軟體
- Process Hacker
- 用來監控執行分析樣本時，它執行了哪些 Process(如下圖)


- 確保在 View -> Scroll to new processes 將該選項開啟（預設為關閉，如下圖）。透過此設定，便可以捕捉新生成的 Process。（若有新的 Process 會亮起橘燈，已經執行一段時間的則為淺、深藍色）


- Wireshark
- 透過 Wireshark 觀察分析樣本有何種網路行為、或對任何網址進行請求（如下圖）
### 開啟 Regshot
- 因為未知該分析樣本是否會更動註冊表，先透過 Regshot 進行第一次 shot。透過右上角（如下圖）的 1 與 2 shot 進行比較，確認分析樣本是否更改註冊表。
- 輸出結果

### Overview
- 執行該分析樣本前的環境最後的樣子（如下圖）。最左邊為 cmd ，右上角為 Process Hacker，右下角為 Wireshark。透過以上設定，可以較清楚的看出分析樣本有哪些行為。

### 開始執行
- 解開壓縮檔後，將該檔案副檔名改成 .exe。接著按一般執行 exe 檔的方式執行該分析樣本後，發現跳出錯誤訊息(如下圖)。

- 分析錯誤原因，我假設可能有幾個原因：
1. 它可能是 x32 的架構，因此無法跑在這台 x64 的電腦上
2. 程式可能被混淆，導致無法正常執行
3. 可能是 DLL 檔，Windows 無法直接執行
- 開始驗證假設：
- 透過 PE-bear 觀察分析樣本的檔案資訊（如下圖）
- 發現在 Sections Header 裡有 UPX 等字樣（如下圖紅色框選處），因此我更加確定分析樣本被混淆。
- 再透過 upx 的 command 將該分析樣本反混淆：

        upx -d b6eeed4fd8eb48126ffb216fd392ae74

- \-d 代表 decompress
- 結果如下圖（獲得新的分析樣本）：
- 將該新的分析樣本丟到 PE-bear
- 可以看到 Sections Header 的差異。藍色框起來的地方（如下圖）為反混淆前，Sections Header 只顯示 UPX；相對的，紅色框起來的的方為反混淆後，可以看到 Sections Header 顯示 .text, .rdata, .data .rsrc 等資料。
- 此外，也可以用 PEiD 了解分析樣本是用何種混淆方法（如下圖）。PEiD 偵測該分析樣本使用 UPX 0.80-1.24的版本進行混淆。

## 檔案資訊

### 透過 PE Viewer 觀察分析樣本檔案資訊
- 一般資訊（如下圖）
- 根據 PE Viewer 可以看出該分析樣本編譯時間為 2020/06/19 上午02:00:19，並且為 DLL 檔。
- 導入函式資訊（如下圖）
- 主要來自兩個 .dll ，分別為 KERNEL32.DLL 與 ADVAPI32.dll。有看到特定的 Windows API 表示該樣本分析可以引入其他函式庫（e.g. LoadLibrayA）、甚至是隨意創建檔案（e.g. CreateFileA, CreateFileA）。因此，在分析該樣本的時候，我主要是以上述兩個方向趣觀察該樣本的行為。

- 匯出函式資訊（如下圖）
- 總共三個，也是我最感興趣的地方。分別為 autobicycle001，autobicycle002，DllRegisterServer。
- 載入設定檔（如下圖）。

### 透過 Resource Hacker
- 發現一個可利用的資源
### 使用 strings
先透過 strings 進行簡易的檢查分析樣本是否有特別的字串，使用方式如下：
- ```c=
strings b6eeed4fd8eb48126ffb216fd392ae74

- Output：沒發現特別的文字（如下圖、擷取片段）。
![](https://i.imgur.com/I8OsW1u.png =50%x)

## 封包內容
### 靜態分析
透過 IDA Pro 進行靜態分析：
- IDA Pro
    - 發現除了 autobicycle001，autobicycle002，DllRegisterServer 之外，多了 dropper-regsvr32.dll。
        ![](https://i.imgur.com/s5STMIa.png =80%x)
    - 找到許多可疑的字串（如下圖）
        ![](https://i.imgur.com/LtEGyXS.png =80%x)
- 執行過程中，透過 Wireshark，並未錄到特別的內容（如下圖）。
![](https://i.imgur.com/i2WOYLH.png =70%x)
- 但在 IDA Pro，可以發現許多與網路相關的字串（如下圖）。比方說：POST、GET、HTTP/1.1、參數等等。
    ![](https://i.imgur.com/8X5Z3oZ.png =80%x)
- 從上述字串 x-reference 之後，可以看到哪些地地方呼叫到 POST 該字串。
    ![](https://i.imgur.com/eyDpPQ9.png =80%x)
- 點選第一個 reference，發現它的程式邏輯（如下圖）。第38判斷，字串是否為 "POST"，若否改成 "GET"。就代表說，該分析樣本需要帶參數才能成功使用 "GET"的方法對網路發起請求。接著看到第55行，分析樣本將一串字串丟入後，回傳某結果。
    ![](https://i.imgur.com/oTZUAHN.png =80%x)
- 在第90行有個判斷，若判斷成立，第92行就發起 HTTP 請求（如下圖）。
    ![](https://i.imgur.com/7L1Cdti.png =70%x)
因為靜態分析分析的結果大多仍未搞懂，因此時間分配下優先轉戰動態分析。

## 常駐方式
### 動態分析
首先，我使用 rundll32.exe 進行基本的動態分析，但效果不彰，遇到一些問題。
- 執行 DLL 遇到的狀況：
    - 執行 rundll32.exe 的時候一閃而逝（如下圖紅色背景），其他監控系統完全沒什麼反應。
    ![](https://i.imgur.com/gGL3ulj.png)
- 基本動態分析完，我接著使用 OllyDbg
    - 使用 OllyDbg 分析過程中，將最常使用的指令，整理如下：

//重新執行程式
fn + ctrl + F2

//Execute till return
fn + ctrl + F9

//單步追蹤
fn + ctrl + f8

    - 我設定 Olly Dbg 在分析樣本呼叫其他 DLL 的時候下斷點，可以發現分析樣本呼叫了哪些 DLL （如下圖）
        ![](https://i.imgur.com/cxDBbn0.png)
    - 按 fn + ctrl + F9 後，可以發現在 OllyDbg -> Debug -> Call DLL export 可以按（如下圖）。如此一來，就可以分析該分析樣本 export 的新的 DLL。
        ![](https://i.imgur.com/5KJ5EHH.png)
    - 在 Call export 的視窗欄中，有三個選項可以選（如下圖）。但並沒看到 autobicycle001，反而多出現了 \<ModuleEntryPoint\>
        ![](https://i.imgur.com/UBJFdqz.png =80%x)


    - 感興趣的是 DllRegisterServer 這個 DLL，因此點選該 Export (如下圖)
    ![](https://i.imgur.com/FQzxmG3.png =80%x)
    - 發現在執行 DllRegisterServer 時跳出 conhost.exe(如下圖)
    ![](https://i.imgur.com/EgR1Ezy.png =80%x)
    - 接著 b6eeed4fd8eb48126ffb216fd392ae74.dll 就消失了。（據我觀察，樣本分析在執行完 DllRegisterServer 後，就將自己刪除）
    - 不過 Process Hacker 有紀錄到有趣的 Process：regsvr32.exe（如下圖）。可以發現，它的 Parent Process 是來自 loaddll.exe，也就是在呼叫 DllRegisterServer 後新出現的 Process。
        ![](https://i.imgur.com/6g1Sudu.png)
    - 進入 regsvr32.exe 內容後，可以發現，它下命令（如下圖）：

regsrv32.exe /s "C:\ProgramData\Software\Microsoft\Windows\Defender\AutoUpdate.dll"

    ![](https://i.imgur.com/DfdsZSi.png =80%x)
    - 看到 regsvr32.exe 內容後，我不是很清楚，難道這不是 Windows Defender AutoUpdate 時預設的指令嗎？為什麼會出現在我剛剛呼叫的 loaddll.exe 裡面？因此，我假設了幾種可能原因：
        1. 可能剛剛在 OllyDbg 裡我手動 patch 了幾個指令，導致記憶配置錯誤，意外呼叫 regsvr32.exe Windows Defender AutoUpdate.dll 
        2. 可能是分析樣本故意要讓我有上述的想法，因而故意將檔案名稱更改成常見的 Windows Defender AutoUpdate.dll ，藉此魚目混珠。
    - 接著是驗證上述想法的階段，第一個原因很快就證實不是因為個人的 patch  導致意外呼叫。驗證方法是，我重新解壓縮原本的分析樣本，在不改動任何暫存器、記憶體的情況下，重新呼叫 DllRegisterServer，發現仍然為相同結果。
    - 接著驗證是否為第二個原因，先說結論：是。驗證方法如下，直接到該目錄底下（C:\ProgramData\Software\Microsoft\Windows\Defender\AutoUpdate.dll），可以發現他偽裝成 Defender AutoUpdate.dll（如下圖）。透過 CFF Explorer 開啟後，發現跟分析樣本輸出一模一樣的函式名稱（e.g. autobicycle001, autobicycle002, DllRegisterServer）。雖然他的修改時間是 2020/12/22，但透過 CFF Explorer 可以發現他的創立時間是 2021/01/06，也就是在執行 DllRegisterServer 的當天，時間也符合。因此，可以推論這是分析樣本的常駐方式。
    ![](https://i.imgur.com/oTFLeTU.jpg)
        
    - 也可以多方驗證，在 Debug 結束後去翻 DllRegisterServer 的 Stack（如下圖），也可以發現該 DllRegisterServer 有呼叫 regsvr32.exe。
    ![](https://i.imgur.com/atC1r6Q.png)
    - 此外，從 Stack 也可以發現 DllRegisterServer 曾修改 92E8.temp，因為我發現字串有關聯性（如下圖）
    ![](https://i.imgur.com/P1N6Qdt.png)
    ![](https://i.imgur.com/vuDy4lX.png)
## 加解密方式
透過  IDA Pro 定位到呼叫密文（return_string_result）的地方（如下圖），可以發現該密文先做了字串驗證（string_validation），接著就是加密的地方。
![](https://i.imgur.com/xGiRMyP.jpg)

## 後門功能
## 中繼站資訊
## 其他有趣的發現
- Debug 的時候發現有趣的字串（如下圖）
![](https://i.imgur.com/MNydSqz.png)
    - 快放棄的時候，又到看有趣的 ASCII Code（如下圖），又燃起繼續分析的動力。看到一些關鍵字，包括："successfully removed, successfully inserted."。猜測這跟分析樣本自動刪除有些許關係。
    ![](https://i.imgur.com/NZsAIYf.png)
    ![](https://i.imgur.com/wrStUcf.png)
    ![](https://i.imgur.com/DIFA4iD.png)

- 覺得奇特的地方：不同的編譯時間（相同分析樣本在不同工具顯示的編譯時間居然不同）（如下圖）
    - PE-bear:（顯示2020.06.18 星期四編譯完成，與下方 PE Viewer 顯示的編譯時間不同）
        ![](https://i.imgur.com/xdwoO6l.png)
    - PE Viewer:（顯示2020.06.19 星期五編譯完成）
        ![](https://i.imgur.com/ZjUnnu6.png =80%x)
- 不小心刪錯 Process(csrss.exe) -> 藍屏...
    ![](https://i.imgur.com/kSdEE48.png =80%x)


## 研究花費的總時數
總共：9-12小時左右
- 分析：6-8小時
- 寫報告：3-4小時