HITCON ENT 惡意軟體新型API呼叫行為實作（Patten式GetProcAddress找碴呼叫API）

-

動機

這次HITCON Enterprise正好坐在R0場有幸聽到PK大神講的議程XD。不過本來想聽這場是想知道實際Google Drive C2 API呼叫過程的Olly分析，不過似乎整場議程重點不放在那Otz...

但正好聽到一件有趣的事情，議程內提到新型惡意軟體呼叫不再像以前是用GetProcAddress，而是自幹了一個叫做GetProcAddressEx呼叫方式會像是：

GetProcAddressEx( ModuleBase, "0=L;3=d;4=L;11=A");
//找尋一個API根據函數名，第0個為L、第3個為d、第4個為L、第11個為A

這手法聽起來像是在逃避正常靜態分析軟體（如IDA Pro）可以很容易根據Import Address Table得知呼叫過程或者透過對GetProcessAddress下斷點動態反查API過程，所以我想這個GetProcAddressEx內部應該：
  1. 不該使用到任何API來增加分析難度
  2. 暴力分析DLL模組結構體找碴外導函數
  3. 暴力列舉API過程中根據Pattern（也就是0=L;3=d...）找到第一筆合適的API名
根據這個原則，於是我開始實做惹XD

Visual C++實作

關於這種奇怪的要求，想到之前有研究過類似的發文 [Windows][PE][ASM]純組語手幹Dll Header解析外導函數表撈出函數地址（如LoadLibraryA動態地址）索性我就拿這個的部分Code來改成VC++函數版本了XD

首先Pattern檢測部份，我寫了一支簡單的函數
int StrVal(std::string Data)
{
 return std::stoi(Data);
}

bool ChkPatten(char* Str, char* Patten)
{
 bool retn = true;
 std::string n = "";
 for (int i = 0; Patten[i]; i++)
 {
  if (*(char*)(Patten + i) == '=')
  {
   int LPos = StrVal(n);
   char RChar = *(char*)(Patten + i + 1);
   if (Str[LPos] != RChar)
   {
    retn = false;
    break;
   }
   n = "";
   i += 2;
  }
  else
  {
   n += *(char*)(Patten + i);
  }
 }
 return retn;
}
這支ChkPatten寫法重點就是一直複製左邊的數字到n的String結構體內，直到遇到”=“時就解析右邊的一個Char看指定位置的字詞是否為該Char然後不停的確認Pattern，就這樣而已XD

那再來就是重點的DLL結構體解析，根據DLL結構體的定義可以寫出以下Code：
int GetProcAddrEx(int ModBase, char* Patten)
{
 int Data = 0;
 _asm
 {
 
  mov esi, ModBase
   mov edx, [esi + 0x3c]//e_ifanw
   add edx, esi//Point To NTHeader Address.
   add edx, 0x18//OptionalHeader
   add edx, 0x60//IMAGE_OPTIONAL_HEADER -> DataDirectory
   add edx, 0x00//Export Directory Offset Addr
   mov edx, [edx]//Export Directory Addr
   add edx, esi

   mov ecx, [edx + 0x18]//Number Of Names

  FindAddrOfNames:
   mov ebx, [edx + 0x20]//Addr Of Name Offset
   add ebx, esi//Point to Addr Of Name
   mov ebx, [ebx + ecx * 4]
   add ebx, esi//Current Name Addr
   dec ecx
   jl ExitFunc


   pushad
   push Patten
   push ebx
   call ChkPatten
   add esp, 0x08
   test al, al
   popad
   jz FindAddrOfNames

   GetAddr :
   inc ecx
   mov ebx, [edx + 0x24]//AddressOfNameOrdinals Offset
   add ebx, esi
   mov cx, [ebx + ecx * 2]//ECX = AddressOfNameOrdinals  + Index As WORD(2 BYTE)
   mov ebx, [edx + 0x1c]//AddressOfFunction Array Offset.
   add ebx, esi
   mov ebx, [ebx + ecx * 4]//Set EDX = Value Of AddressOfFunction[Index] = Offset.
   add esi, ebx
   mov[Data], esi
   ExitFunc :
 }
 return Data;
}
如果不懂的話可以去翻 [Windows][PE][ASM]純組語手幹Dll Header解析外導函數表撈出函數地址（如LoadLibraryA動態地址）來看一下，這邊主要就是改了一下那篇部落格文內的比對文字。

pushad
   push Patten
   push ebx
   call ChkPatten
   add esp, 0x08
   test al, al
   popad
   jz FindAddrOfNames

去呼叫我們前面寫好的ChkPatten函數來確認我們當前列舉的API ESI對應的文字名字是否為Patten所求的API，比較特別的是add esp, 0x08部分是為了平衡VC內函數寫法固定都得平衡參數使用的空間（我記得C++ Builder好像不用這樣平衡？看IDE）

最後就是Demo一下這兩個函數的猛猛效果了

DEMO

首先，為了做到完美的不使用API我還使用到了之前PO過的[Windows][PE][ASM][CE]從PE架構到模組架構到暴力列舉模組找模組位置（如Kernel32.dll）來找碴模組在當前記憶體中的位置。

int GetKernel32Mod()
{
 int dRetn = 0;
 _asm
 {
  Main:
   mov ebx, fs:[0x30] //PEB
   mov ebx, [ebx + 0x0c]//Ldr
   mov ebx, [ebx + 0x1c]//InInitializationOrderModuleList
  Search :
   mov eax, [ebx + 0x08]//Point to Current Modual Base.
   mov ecx, [ebx + 0x20]//Point to Current Name.
   mov ecx, [ecx + 0x18]
   cmp cl, 0x00//Test if Name[25] == \x00.
   mov ebx, [ebx + 0x00]
   jne Search
   mov[dRetn], eax
 }
 return dRetn;
}
那最後就是實作怎麼不用任何API（應該說IAT表、靜態工具分析看不出來）怎麼做到漂亮的呼叫API了，這邊以Console程式要呼叫MessageBoxA為例，因為MessageBoxA在User32.dll之下但是Console程式預設是不會載入這個模組的，所以實際程式碼我們得先透過LoadLibraryA把User32.dll給載入進記憶體在找碴MessageBoxA的實際記憶體地址然後做呼叫：

int _tmain(int argc, char* argv[])
{
 int Kernel32Base = GetKernel32Mod();
 HMODULE(WINAPI*MyLoadLibraryA)(LPCTSTR lpFileName) = (HMODULE(WINAPI *)(LPCTSTR))(GetProcAddrEx(Kernel32Base, "0=L;3=d;4=L;11=A"));
 
 int User32Base = (int)MyLoadLibraryA((LPCTSTR)"User32.dll");
 int(WINAPI*MyMessageBoxA)(HWND hWnd,LPCTSTR lpText,LPCTSTR lpCaption,UINT uType) = (int(WINAPI *)(HWND, LPCTSTR, LPCTSTR, UINT))(GetProcAddrEx(User32Base, "0=M;2=s;3=s;7=B;10=A"));
 MyMessageBoxA(0,(LPCTSTR)"Adr Handsome!", (LPCTSTR)"Adr Say", 0);
 return 0;
}
實作效果：

效果拔擢啊！！
如果想下載完整的專案代碼，可以到我的GitHub：
https://github.com/aaaddress1/Virus-Patten-API-Call/tree/master

留言

張貼留言

這個網誌中的熱門文章

[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...
閱讀完整內容