翻譯自：https://blog.talosintelligence.com/2019/01/what-we-learned-by-unpacking-recent.html
翻譯：聶心明

在過去兩個月的時間里，Cisco Talos一直在追蹤一系列Imminent rat病毒感染事件，下面的數據來自思科高級惡意軟件防護（AMP）漏洞利用防護引擎。在病毒開始感染主機之前，AMP成功的阻止了病毒，但是在最初的分析中就展示了比較強大的跡象，就是在rat部署之前就已經探測出病毒的存在。讓人驚喜的是，amp檢測出這個病毒是Imminent RAT，而不是一個合法的商業軟件。

這一系列攻擊的設計者設計出的病毒可以躲避檢測和阻礙分析。從外表來看，這個病毒了用了一個叫Obsidium的商業的加殼工具，這個加殼工具在過去一直被用于保護一些開發者的知識產權。這個Imminent RAT病毒就用了剛才提到的殼來達到使自己合法化的目的。Imminent 是一個商業的rat，它的零售價為$25 到 $100?？梢愿鶕蛻舻男枨髞砀淖儾《镜捏w積。雖然它不希望被用于惡意用途，但是在這次案例中，我們依然把他檢測為惡意病毒。

盡管現發現潛在惡意應用 (PUA)的方法已經比較成熟了，但并不是每個人都能阻擋住惡意軟件。我們還有一些其他的技術，探測潛在漏洞利用引擎，它就非常適合去發現一些潛在的威脅。我希望通過讀者在讀完這篇文章之后，你能不僅明白攻擊者使用了一個非常復雜的殼，還要明白amp是怎樣阻擋的這次攻擊，而這次攻擊者使用的病毒躲過了靜態分析和沙箱的動態分析。

當AMP發現軟件中包含Imminent后，我們看看這個病毒使用的殼有多復雜，是怎樣逃避檢測的。我們決定進一步調查這個病毒，下面是病毒動態運行時的調用過程。

我們識別出這個病毒用了商業的殼，通過運行這個病毒，我們來看看它到底究竟用了多少反調試反虛擬機的技術。病毒啟動時，會覆蓋SEH句柄。技巧是把處理句柄放在FS:0前后，然后把棧指針指向FS:0?？赡苁且驗闃颖臼?2位的，且沒有用SafeSEH進行編譯。代碼會故意出錯，然后執行流程會跳轉到準備好的代碼。之后解密病毒代碼。

當執行到準備好的代碼時，下面用于用戶處理異常的代碼將會被跳過，大家都知道處理異常時都必須用到ntdll->KiUserExceptionDispatcher，你跳過異常處理到應用程序，如果下面還有異常處理函數或者如果runtime還能繼續運行的話，那么你就在條件跳轉前面下斷點。

最后，ECX存儲了一個指向CONTEXT 結構的指針，然后EIP會指向這個結構，這樣就會調用上面的NtContinue，在運行時，EIP就會指向ECX地址，并且會在32位環境中應用 CONTEXT結構。

病毒會在同一時間內解密和再加密病毒代碼段，如果你沒有手動運行每一個代碼段，你很難完整的確定完整解密的時間點，加密方式是采用的是AES加密還有其封裝的函數。

上面是解密初始化代碼，你可以看到一些復雜api的解析，首先類似于二進制文件的其他位置，但是這里會阻止你的分析： junk byte insertion for anti-disassembly

有一種希望就是，依賴現代反編譯工具的流程控制圖和函數代碼塊能快速梳理。在幾個函數返回的地方下好斷點之后，你要開始注意在通用寄存器拋出的api字符串。通過一些實驗和試錯，你可能不會把斷點下在重要的返回地址上，解析api的返回地址一般存儲在eax上。程序會在調試器中運行，直到函數返回，但是你將會在代碼中遇到一些額外的程序崩潰和訪問非法結構的問題。就像下圖展示的那樣。當病毒開始運行payload時檢測到用戶使用調試器時，反調試器就會觸發崩潰和訪問非法結構，這在加殼軟件中是非常常見的。

值得一提的是，當病毒運行時，如果你沒有運行到函數的返回地址時，程序就不應該在api地址上斷下，或者跳轉。殼也不總會讓函數返回到正常的api地址上。并且，api地址不會被直接使用，而是存在于幾個函數中，并且每個api會被改變。最好的方式是在api函數地址上下斷，目的是當病毒偶然調用這些api時會看到原始的參數。更重要的是，殼會會提前檢測api代碼中會不會存在軟斷點（0xCC 或者 int 3）

當你搞定反調試器時，你就可以正常調試了。這是成功破解的關鍵步驟。更方便的技術就是讓病毒代碼運行，然后從內存中導出完整的鏡像出來，或者相關的代碼，這個病毒似乎沒有對這種情況做相關的檢測。這個殼有幾種反調試的檢測，我用用一個列表詳細的列舉出來。

• 類注冊后，傳遞給CreateWindowsEx，通過CallWindowProc來傳遞回調參數?；卣{函數調用NtQueryInformationProcess，并且把發給ProcessDebugPort 的數據設置為ProcessInformationClass類型。
• API調用兩次ProcessInformationClass enumerations ProcessDebugObjectHandle 和 ProcessDebugFlags，這些數據都沒有文檔支持。
• 通過給SystemInformationClass 傳遞無文檔支持的枚舉類型來調用NtQuerySystemInformation 。在這一部分中，標準的SYSTEM_BASIC_INFORMATION 結構不會被返回，但是SYSTEM_KERNEL_DEBUGGER_INFORMATION 結構會被返回，這個結構里面包含UCHAR KernelDebuggerEnabled 和 UCHAR KernelDebuggerNotPresent。用戶通常用這兩個標志繞過調試器的檢查。
• 一個錯誤的句柄去調用CloseHandle ，當你用調試器調試進程時，病毒一般會出現異常，然后退出，而不是無聲的退出。在這個例子中，如果程序出現異常則會被調試器捕捉到（EnumWindows->MessageBoxA->“Debugger detected…”），當調試的時候就會丟棄這樣的異常從而繞過這樣的檢查
• CreateFileA 會被調用幾次，目的是為了檢測主機上是否有與調試器相關的文件

\\.SICE \\.\NTICE \\.\NTFIRE

• 下一個檢測比較有趣，在程序運行之前，病毒程序解析了超過20給函數。幸運的是，僅僅只有一小部分函數被檢測到了(InternalGetWindowText, IsWindowVisible, and EnumWindows)，在早期的討論中，通常認為在解包之前獲取EnumWindows是一種不好的跡象，這樣你不會通過調試器的檢查。在這個例子則不同，傳遞給EnumWindows 的回調函數必須通過斷點來處理和迭代，檢查獨立的調試器時，會檢測 InternalGetWindowText 和 IsWindowVisible的調用。
• 設置的值直接會傳遞給SetLastError，但是要遵守內部錯誤機制。GetLastError 被調用，目的是檢查是否有值被設置，如果有就證明有調試器，程序隨即崩潰
• GetCurrentThread 會提取當前進程，然后把獲取到的值傳遞給NtSetInformationThread，外加來自于THREAD_INFORMATION_CLASS的ThreadHideFromDebugger enumeration。它會檢測是否存在調試進程。
• CheckRemoteDebuggerPresent
• FindWindowW 會尋找與調試器相關的類名稱，而不是窗口名稱：ObsidianGUI, WinDbgFrameClass, ID, 和 OLLYDBG
• CreateFileW 會檢查會不會創建\\.\VBoxGuest

這僅僅是反調試器的一部分功能。不幸的是，我沒有足夠的時間去介紹病毒反虛擬機的技術，但是希望這篇文章相當于一個拋磚引玉的功能。我們決定繼續在 bare-metal主機上破解這個病毒以得到它最終的二進數據。最后我們識別出這是一個商業的RAT病毒。通過分析動態域名，發現其他樣本也用了同樣復雜的加密殼(Themida等)。但是這個主機不會只控制一個，肯定會同時控制多種RAT（包括我現在破解的）

這一些攻擊讓檢測策略變得更為復雜。最開始，我們使用商業加密殼來保護開發者的知識產權。而現在商業的rat也會用到加密殼。我們的PUA能夠檢測到病毒，我們的潛在漏洞利用引擎也發現了這次攻擊，此外我們使用病毒預防技術對這次事件做了進一步分析。我們發現攻擊者最近研究了幾種新的技術去繞過病毒檢測機制。在這次事件中，商業病毒的能力似乎也不行。攻擊者的病毒被Cisco Advanced Malware Protection’s (AMP) Exploit Prevention引擎成功阻止，并且這次攻擊給我們提供了更多有用的信息，讓我們知道攻擊者在攻擊目標時用到了什么樣的工具。

IOCS

原始病毒：
3bc0ae9cd143920a55a4a53c61dd516ce5069f3d9453d2a08fc47273f29d1cf3
破解之后的病毒：
12cca4fcfe311d1136db6736e7f17854746a5e6c7a284c27ea84a5016bf982d7

總結

以上是生活随笔為你收集整理的使用APM破解Imminent rat病毒后我们学到的东西的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。