翻譯自：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。可以根據客戶的需求來改變病毒的體積。雖然它不希望被用於惡意用途，但是在這次案例中，我們依然把他檢測爲惡意病毒。
儘管現發現潛在惡意應用 (PUA)的方法已經比較成熟了，但並不是每個人都能阻擋住惡意軟件。我們還有一些其他的技術，探測潛在漏洞利用引擎，它就非常適合去發現一些潛在的威脅。我希望通過讀者在讀完這篇文章之後，你能不僅明白攻擊者使用了一個非常複雜的殼，還要明白amp是怎樣阻擋的這次攻擊，而這次攻擊者使用的病毒躲過了靜態分析和沙箱的動態分析。
當AMP發現軟件中包含Imminent後，我們看看這個病毒使用的殼有多複雜，是怎樣逃避檢測的。我們決定進一步調查這個病毒，下面是病毒動態運行時的調用過程。
我們識別出這個病毒用了商業的殼，通過運行這個病毒，我們來看看它到底究竟用了多少反調試反虛擬機的技術。病毒啓動時，會覆蓋SEH句柄。技巧是把處理句柄放在FS:0前後，然後把棧指針指向FS:0。可能是因爲樣本是32位的，且沒有用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