Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863103497

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

微信截图_20230319161953.png

在過去的幾個月裡，CPR一直在監測DotRunpeX惡意軟件以及它在野外的使用情況。監測顯示，這種新型的網絡注入器仍在不斷發展中。 CPR發現了幾種不同的傳播方法，在發現的所有示例中，DotRunpeX都是第二階段感染的一部分。這種新的威脅被用來傳播許多不同的惡意軟件家族，主要與竊取程序、RAT、加載程序和下載程序有關。

與新版DotRunpeX相關的最早示例的日期為2022.10.17。關於這一威脅的首次公開信息發布日期為2022.10.26年。

本研究的主要主題是對兩個版本的DotRunpeX注入器進行深入分析，對比它們之間的相似之處，並介紹用於分析新版本的DotRunpeX的PoC技術，因為它是由自定義版本的KoiVM .NET protector.虛擬化傳播的。

主要發現Check Point Research（CPR）對DotRunpeX注入器及其與舊版本的關係進行了深入分析；DotRunpeX受到虛擬化（KoiVM的自定義版本）和混淆（ConfuserEx）的保護；

調查顯示，DotRunpeX在野外被用來傳播許多已知的惡意軟件家族；

通常通過網絡釣魚電子郵件作為惡意附件和偽裝成常規程序的網站進行傳播；

CPR確認並詳細說明了惡意使用易受攻擊的進程資源管理器驅動程序來禁用反惡意軟件服務的功能；

本文會介紹幾種PoC技術，這些技術已被批准用於反向工程受保護或虛擬化的dotnet代碼；

DotRunpeX是一種使用Process Hollowing技術在.NET中編寫的新註入器，用於感染各種已知惡意軟件家族的系統。儘管這種注入器是新的，但與舊版本有一些相似之處。此註入器的名稱基於其版本信息，在dotRunpeX的兩個版本中都是一樣的，在CPR分析的所有示例中都是一致的，並且包含ProductName–RunpeX.Stub.Frame。

在CPR監測這一威脅的同時，CPR發現了一些主要由獨立研究人員公開共享的信息，這些信息與DotRunpeX的功能有關，但被錯誤地歸因於另一個著名的惡意軟件家族。

CPR通過對這一威脅連續進行幾個月的監測，CPR獲得了足夠的信息來區分第一階段和第二階段（DotRunpeX）加載程序，但沒有跡象表明它們之間存在關係。在各種下載程序和加密貨幣竊取程序中，CPR發現了這些由dotRunpeX傳播的已知惡意軟件家族:

AgentTesla

ArrowRAT

AsyncRat

AveMaria/WarzoneRAT

BitRAT

Formbook

LgoogLoader

Lokibot

NetWire

PrivateLoader

QuasarRAT

RecordBreaker–RaccoonStealer2.0

Redline

Remcos

Rhadamanthys

SnakeKeylogger

Vidar

XWorm

1.png

DotRunpeX傳播的惡意軟件家族

從發生的時間順序來看，基於DotRunpeX示例的編譯時間戳，這種新的威脅主要在2022年11月和2023年1月開始流行。

2.png

DotRunpeX時間軸——編譯時間戳

感染途徑DotRunpeX注入器通常是原始感染的第二階段。典型的第一階段是.NET加載程序/下載程序的非常不同的變體。第一階段加載程序主要通過釣魚電子郵件作為惡意附件（通常是“.iso”、“.img”、“.zip”和“.7z”的一部分）或通過偽裝成常規程序實用程序的網站進行傳播。除了最常見的感染途徑外，DotRunpeX的客戶還很善於濫用谷歌廣告，甚至通過木馬惡意軟件構建器構建其他潛在的攻擊者。

釣魚郵件“Transaction Advice 502833272391_RPY - 29/10/2022”將第一階段加載程序作為惡意“.7z”附件的一部分傳播第一階段加載程序，導致加載DotRunpeX（SHA256:“457cfd6222266941360fdbe36742486ee12419c95f1d7d3502243e795de28200e”）。

3.png

釣魚郵件“Transaction Advice 502833272391_RPY - 29/10/2022”

釣魚網站會偽裝成常規程序實用程序（Galaxy Swapper、OBS Studio、洋蔥瀏覽器、Brave Wallet、LastPass、AnyDesk、MSI Afterburner），並提供第一階段加載程序，導致dotRunpeX在第二階段的一部分被感染。

偽裝成Galaxy Swapper的網站：https://www.galaxyswapper[.]ru/：

4.png

在谷歌搜索Galaxy Swapper得到的結果“https://www.galaxyswapper[.]ru/”

下載重定向到https://gitlab[.]com/forhost1232/galaxyv19.11.14/-/raw/main/galaxyv19.11.14.zip。

5.png

“https://www.galaxyswapper[.]ru/”上的下載按鈕重定向到一個木馬程序

偽裝成LastPass密碼管理器的網站：http://lastpass[.]shop/en/

6.png

網站“http://lastpass[.]shop/en/”偽裝成LastPass密碼管理器

LastPass密碼管理器的假冒網站在調查時已經關閉。儘管如此，CPR可以確認該假冒軟件是從“最終URL”https://gitlab[.]com/forhost1232/lastpassinstaller/-/raw/main/LastPassInstaller.zip下載的。

7.png

“http://lastpass[.]shop/en/”上的下載按鈕重定向到一個木馬程序

GitLab頁面https://gitlab[.]com/forhost1232包含數十個被DotRunpeX惡意軟件木馬化的程序。

8.png

GitLab存儲庫“https://gitlab[.]com/forhost1232”上的數十個木馬程序

在前面提到的GitLab頁面上，所有的木馬程序都包含了主.NET應用程序，並通過覆蓋層進行了放大，以避免使用沙盒進行掃描。

9.png

由GitLab存儲庫' https://gitlab[.]com/forhost1232 '提供的木馬程序示例

上面提到的帶有覆蓋的.NET應用程序是典型的第一階段，其行為就像帶有簡單混淆的dotnet加載程序。這些不同的加載程序變體在第二階段使用反射來加載DotRunpeX注入器。其中有些非常簡單，有些則更高級。

簡單的第一階段加載程序（System.Reflection.Assembly.Load()方法）：

10.png

簡單的第一階段加載程序

下面可以看到更高級的第一階段加載程序的示例（使用AMSI Bypass和DynamicMethod通過反射加載和執行第二階段加載程序）。這種高級加載程序的優點是沒有直接引用System.Reflection.Assembly.Load()方法，因此它可以避免檢測依賴於.NET元數據靜態解析的引擎。

11.png

使用AMSI繞過和DynamicMethod的更高級的第一階段加載程序

後一種的去混淆形式如下圖所示：

12.png

更高級的第一階段加載程序的去混淆形式

從這些類型的加載程序中提取第二階段（DotRunpeX階段）的編程方式可以簡單地使用AsmResolver和反射來實現，如下所示。

13.png

使用AsmResolver和反射從第一階段加載程序提取DotRunpeX

值得注意的是，那些指向GitLab頁面的釣魚網站的示例只與一個活動有關，在這個活動中，DotRunpeX注入器總是負責注入帶有C2–77.73.134.2的Redline惡意軟件。

除了前面提到的最常見的感染途徑外，CPR還觀察到了一個非常有趣的感染途徑示例，在這個示例中，DotRunpeX的一位客戶可能已經厭倦了以普通受害者為目標，並決定以其他潛在的攻擊者為目標。 Redline構建器Redline_20_2_crack.rar(SHA256: “0e40e504c05c30a7987785996e2542c332100ae7ecf9f67ebe3c24ad2468527c”)被下載程序木馬化，該下載程序使用反射來加載dotRunpeX作為構建器的隱藏“添加功能”。

14.png

木馬化的Redline構建器的文件夾結構

事實證明，在Redline的構建過程中，根據需求進行配置，使用者還將獲得另一個Redline示例。

15.png

使用反射來加載DotRunpeX的下載程序，該下載程序傳播另一個Redline惡意軟件

舊版本的DotRunpeX：

使用自定義混淆：僅對名稱進行混淆；

配置有限（有效負載注入目標、提升+UAC繞過、有效負載解密的XOR密鑰）；

只有一種UAC繞過技術；

使用簡單的XOR對要注入的主要有效負載進行解密；

使用D/Invoke類似的技術來調用本機代碼（基於使用GetDelegateForFunctionPointer()），但使用誘餌系統調用例程；

使用D/Invoke重新映射' ntdll.dll '

新版本的DotRunpeX：

由自定義版本的KoiVM虛擬程序保護；

高度可配置(禁用反惡意軟件服務，反虛擬程序，反沙盒，持久性設置，有效負載解密密鑰，UAC繞過方法)；

更多的UAC繞過技術；

使用簡單的XOR來解密要注入的主要有效負載(在最新開發的版本中省略了)；

濫用procexp驅動程序(Sysinternals)阻止受保護進程(反惡意軟件服務)；

基於俄羅斯procexp驅動程序的標誌名稱Иисус.sys 翻譯過來就是“jesus.sys”；

兩個版本的相似之處：

用.NET編寫的64位可執行文件“.exe”；

用於注入幾個不同的惡意軟件家族；

使用簡單的XOR對要注入的主要有效負載進行解密；

可能使用相同的UAC繞過技術（新版DotRunpeX提供了更多技術）；

16.png

UAC繞過技術

使用相同的版本信息；

17.png

DotRunpeX版本信息

使用相同的.NET資源名稱BIDEN_HARRIS_PERFECT_ASSHOLE來保存要注入的加密有效負載：

18.png

新舊版本的Dotnet資源名

使用相同的代碼注入技術——Process Hollowing；

使用相同的結構化類定義本機委託；

19.png

用於定義Native委託的相同結構化類

完整的技術分析——舊版本的DotRunpeX對於舊版本的DotRunpeX的分析，使用了示例SHA256:“65cac67ed2a084beff373d6aba6f914b8cba0caceda254a857def1df12f5154b”。這個示例是一個用.NET編寫的64位可執行文件“.exe”，實現了自定義的混淆——只對名稱進行混淆。 CPR分析的所有示例的版本信息都是一致的，CPR可以注意到ProductName - RunpeX.Stub.Framework，這可能是某種CPR正在處理網絡注入器的第一個提示。

20.png

舊DotRunpeX版本信息

為了方便介紹，CPR對方法名稱、參數和局部變量進行了部分清理。就在Main()方法中，CPR可以看到資源BIDEN_HARRIS_PERFECT_ASSHOLE的簡單XOR解密，該資源包含要注入的加密有效負載。 CPR分析的所有示例的資源名稱都是一致的。

21.png

主要方法導致嵌入式有效負載的簡單XOR解密

CPR還可以看到具有類名UAC的名稱空間UACBypass，此類實現了UAC（用戶帳戶控制）繞過方法，但未配置為在此示例中使用。

22.png

UAC繞過方法

方法Inject()實現了一種稱為“Process Hollowing”的代碼注入技術。下圖顯示了一個正在生成處於掛鉤狀態的進程。

23.png

創建掛鉤的流程作為Process Hollowing技術的一部分

這種技術在惡意軟件開發領域並不新鮮。儘管如此，一旦CPR檢查了這個示例的P/Invoke（允許從託管代碼訪問非託管庫中的結構、回調和函數的技術）定義的方法，就可以立即發現一些有趣的東西。這些方法可以在ImplMap表中看到，該表是.NET元數據的一部分。

24.png

ImplMap表——舊版本的DotRunpeX

必須使用某些WIN API或NT API來執行Process Hollowing技術。正如CPR在ImplMap表中看到的那樣，缺少了一些最關鍵的API。更具體地說，CPR看不到任何與取消映射和寫入遠程進程內存相關的API。這背後的原因是使用D/Invoke框架來調用某些通常會引起注意的NTAPI例程。

D/Invoke包含功能強大的原語，這些原語可以智能地組合在一起，以精確地從磁盤或內存動態調用非託管代碼。它依賴於dotnet方法GetDelegateForFunctionPointer()的使用和相應的委託定義。

在這種情況下，NT API ZwOpenSection、ZwMapViewOfSection、ZwUnmapViewOfSection、NtClose、NtWriteVirtualMemory、NtResumeThread和RtlMoveMemory是通過D/Invoke實現的。委託的相應定義如下所示。

25.png

用於定義Native委託的類

更有趣的是，通過D/Invoke實現的4個NT api (ZwUnmapViewOfSection, NtWriteVirtualMemory, NtResumeThread, RtlMoveMemory)使用了一些可以被認為是添加的PoC技術，而不是原始D/Invoke框架的一部分——系統調用補丁。例如，CPR可以通過CallNtWriteVirtualMemory()方法檢查NtWriteVirtualMemory調用是如何實現的。

26.png

導致系統調用修復的D/Invoke實現示例

首先，我們可以看到MapDllandGetProcAddress()方法中D/Invoke框架的用法發生了變化。每次調用此方法時，它都會重新映射指定的庫，並獲得所需函數的地址。在返回所需函數的地址之前，使用指針算術將指針移動4個字節，使其指向系統調用號的地址。在這種情況下，' ntdll.dll '模塊被重新映射，返回NT API例程NtWriteVirtualMemory的地址，偏移量為4個字節。

27.png

改變了D/Invoke的用法，它返回指