Garena 釣魚蠕蟲 Dropper 樣本分析（照片.zip）與如何清除病毒

-

前言

事情是這樣的，一如反常的我打開我的 macbook、打開虛擬機、打開 Windows、打開 Garena、打開 LoL 想發洩一下 這時候發現一堆人都在密我呢，好害羞啊，可是大家都密我一樣的東西，丟了一份 照片.zip 過來，這引起了我的好奇

註：這篇文章只分析 Dropper 部分，後面還有一支 *.exe 惡意程式有加殼，如果時間比較有空了我才會分析進去他在幹嘛XD，這篇文章主要是分享分析 *.vbe 加密後的 VBScript 的方法與解混淆的技巧。我不會承認是因為我懶得開虛擬機，所以這篇文章都在真實工作電腦內純靜態分析哈哈哈哈哈哈


TL;DR：如何清除病毒？

因為這隻惡意程式把路徑跟檔名都寫死的，所以檢查一下你 Windows 的「啟動」資料夾是否有 r.vbe，跟 C:\programdata\opopopk.exe 這個程式是否存在。把啟動資料夾內的 r.vbe 與 C:\programdata\opopopk.exe 刪除就完成清除病毒惹

惡意壓縮包附件

首先你拿到這份壓縮包後，會看到裡面只有一個「照片.vbe」檔案，類型可見是 VBScript 編碼後的腳本文件
打開這份 *.vbe 文件後，即可見內部是編碼過後的腳本，無法直接觀看到程式碼，你可以透過 VBS decrypter and encrypter 來完成這個解碼的部分，這個編碼解碼有一套固定算法沒有任何技術性，不要浪費人生在這種無意義的東西上

把解碼後的程式碼稍微重新排版後，可以看到他的混淆很簡單，就只是把 VBScript 程式碼以字串方式，把每個 ASCII 碼以數字與逗號做切割保存在 Str 變數內。執行時，再將每個數字轉回文字並組合存在 restorecode 內，回傳 ASCII 組合起來的字串，再透過內建的 Execute 函數將 VBScript 執行起來。所以只要把 Execute 換為 MsgBox 函數：
我們就可以很輕易的把程式碼攔截下來，接著進到下一步驟做分析。


Dropper 核心程式碼



上面是完整攔截下來的 VBScript 的 Dropper 程式碼。
一開始執行起來這一段很好理解，基本就是把自己目前這份混淆過後的 *.vbe 惡意腳本拷貝一份到 Windows 的「啟動目錄」來做到開機自動執行，自動下載惡意程式到本機執行（詳閱後面）
這一部分就只是目標放置惡意程式的地方在 C:\programdata 資料夾，所以展開其資料夾中每一個路徑看看資料夾是否存在，不存在的話就自動創建資料夾（避免後續放置檔案時失敗）

接著是用 WMI 方式判別當前電腦的版本號是否為 XP，如果是就執行第一種行為，不是就執行第二種（不過看起來是大同小異，我直接分析 Win7+ 的行為）
對，我知道我很偷懶，我完全不想解它的混淆，把看不懂的變數部分用 MsgBox 彈粗乃就可以發現它創建了 Wscript.Shell、MsxMl2.Http 與 ADODB.Stream 的結構實體，後續用於抓後門下來。
最後透過 MsxMl2.Http 將「http://%77%77%77%2E%66%7A%66%7A%31%32%33%2E%75%73%61%2E%63%63/%69%6D%61%67%65%73.%67%69%66」（http://www.fzfz123.usa.cc/images.gif，實際上是一隻惡意程式）下載到 C:\programdata\opopopk.exe，然後透過「cmd /c set &&ping -n 10 127.0.0.1 &&start C:\ProgramData\opopopk.exe」把這隻惡意程式給叫起來，完成 Dropper 的工作

留言

張貼留言

這個網誌中的熱門文章

[C#] Lambda花式應用噁爛寫法（跨UI委派秒幹、多線程處理...etc）

-
為啥會有這篇呢...因為最近寫太多C# 突然發現Lambda對程式碼減化太有幫助了=...= 為了怕哪天老人癡呆忘了這些噁心的花式寫法，就開一篇Blog文紀錄了 以前在寫多線程,可能得這麼寫： void Func() {/*多線程要做的事情*/} //接著呼叫： Thread nThread = new Thread(Func); nThread.Start(); 但今天用Lambda可以改寫： Thread nThread = new Thread(() => {/*多線程要做的事情*/}); nThread.Start(); 甚至在噁心點寫的寫法： new Thread(() => {/*多線程要做的事情*/}).Start(); 簡單來說Lambda的形式可拆解成： ()是指你的函數參數列、然後可用=>代表你要接的Lambda陳述句/塊，最後用{}把事情包起來。 在來就是比較討厭的C#內要做跨UI線程操控UI上物件，會有跨UI安全性線程問題， 所以一般會額外寫個委派函數，然後請求UI Thread去處理這個委派函數請求，才能控制 這樣往往可能只用一兩次的委派函數，卻要占用一個篇幅去寫委派函數 先看看正常的跨UI委派寫法： private delegate void nCallback(string ContentText); public void n(string ContentText) { if (this.InvokeRequired) { nCallback obj = new nCallback(n); this.Invoke(obj, new object[] { ContentText }); return; } this.Text = ContentText; } //調用時呼叫n("str") 就可以改寫成： this.Invoke(new Action(() => { this.Text = "Str"; })); 又因為=>後面可接陳述塊或者陳述句，所...
閱讀完整內容

[Windows] 逆向工程 C++ 中入口函數參數 main(argc, argv) 與如何正確的進行參數劫持

-
圖片
前言 我在 Github 上三年前開源了精簡的以 C/C++ 撰寫的 Windows 執行程式裝載器： aaaddress1/RunPE-In-Memory  用以從記憶體執行以 C/C++ 開發的 *.exe 程式不必以 CreateProcess() 來叫起，算是一種概念性 PoC 啦畢竟這種手段在惡意程式和殼上經常使用，所以寫一寫就丟出來給大家玩 XD 不過有人在我的專案發起了 Issue：既然能從記憶體中執行 *.exe 那能否偽造 *.exe 取得的參數呢？嗯好問題XD 正逢去年蠻忙的所以一直懶得弄，這個月比較閒於是就決定在專案中新增 參數偽造 的功能，這邊簡單提一下 C++ 中 main() 入口所收的 argc 與 argv 來的。 [附註] 以下逆向工程內容以 MinGW 生產的程式為例， 系統逆向工程為 Win10 企業版 1809版  CRTStartup 在 Windows 下通常取得參數通常分為兩種狀況：  WINAPI GetCommandLineW() 系統函數返回字串指針指向當前完整應用程式參數 從 main(argc, argv) 拿回來的參數，那麼第二種狀況在編譯器是怎麼吐參數給開發者 main 入口的呢？ 在編譯器吐出執行程式後，連結器會生產一段 CRTStartup 的函數用於做一些基礎的例如像是 Security Cookies、Control Flow Guard 保護的初始化，在一系列初始化之後 .data 段的全域變數 _argv、argc 紀錄著要傳入給開發者入口函數的 參數陣列 與 數量，就以參數形式呼叫 main() 函數 好問題，那這兩個全域變數是在哪裡被初始化的？ 你會發現以 MinGW 為例的話，會去呼叫 msvcrt!__getmainargs() 來取得參數資訊保存到 .data 全域變數上，後續再傳遞給 main() 函數；如果是 VC++ 吐出來的則是直接呼叫 GetCommandLineW() 在做文字切割取出參數 MSVCRT MSVCRT.dll 有導出一系列 C 函數是引用 #include <stdio.h> 時會用到的，例如 printf, sprintf, gets 等等。...
閱讀完整內容

重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計

-
圖片
前言 這份研究是從去年底開始摸的，主因是一直對 Windows 如何實作 WOW64 兼容架構覺得有意思，並且坊間蠻多開源的天堂之門專案都死掉了 QQ 所以才打算自己完全重新逆向工程分析過一次。 逆向整個 WOW64 架構可以發現很多蠻有意思的問題，比方說 Intel 晶片指令集模式切換、記憶體模擬分配、WOW64 偽造的原生 32-bit 環境，例如 System32 在 32-bit 下會被重導向至 SysWOW64 到底在哪一層實作重導向的呢 ;)  此研究也運氣不錯分別被國內研討會 CYBERSEC 收錄為 《重建天堂之門：從 32bit 地獄一路打回天堂聖地》 與 HITB（Hack In The Box Security Conference）收錄為  《WoW Hell: Rebuilding Heavens Gate》 若對線上演講內容有興趣可以參考 Youtube 上 HITB 的直撥串流  HITB2021AMS D1T2 - WoW Hell: Rebuilding Heavens Gate - ShengHao Ma   不過我英文很破能不看就不看啦 由於整份演講內容想提的細節太多了，所以本部落格文拆成上下兩集。 當前本文是上集，會講述完整逆向工程整套微軟設計的 WOW64 架構怎麼設計的 。而下集《 重建天堂之門：從 32 位元地獄一路打回天堂聖地（下）攻擊篇：x96 Shellcode、天堂聖杯 ＆ 天堂注入器 》會著重在我今年發表出來的幾個有趣的攻擊點 :) 如果對天堂之門技術已經很熟的大佬，可以跳過本文看下一集了 <(_ _)> ＊注意＊ 本份研究在 2021/06/11 是基於 Windows 10 Enterprise 最新版本逆向工程結果所紀錄， 可能與讀者電腦中反編譯出來的結果有所出入是正常的 。筆者實測了同樣是 Windows 10 但不同組建版本在組合語言層級皆有些許差異，不過各個函數設計用途是固定且規律的、不會因版本而有所差異。 而整份研究不限但至少涉及了以下已知文獻，蠻值得一看的 2011 -  Mixing x86 with x64 code by ReWolf 2012 -  Knockin’ on Heaven’s Gate by georg...
閱讀完整內容