標題：MANTICORE的攻擊範圍正在逐步擴大（下）

MANTICORE的攻擊範圍正在逐步擴大（上）

Web shellManticore部署了多個Web shell，包括之前被間接歸因於OilRig的Web shell，其中一些web shell因其混淆、命名約定和工件而更受關注。與Manticore在過去幾年的攻擊中使用的許多其他web Shell和基於.NET的工具相比，web Shell保留了類和方法模糊以及類似的字符串加密算法，該加密算法與一個字節異或，密鑰從第一個字節或前2個字節派生。

其中一個shell是對開源XML/XSL轉換web shell (XSL Exec shell)進行了嚴重混淆和略微修改的版本。這個web shell還包含兩個混淆的函數，它們返回字符串“~/1.aspx”。這些函數從未被調用過，很可能是其他版本的殘餘，正如我們在Manticore之前使用的工具(如FOXSHELL)中觀察到的那樣：

FOXSHELL web shell版本中未使用的字符串

攻擊目標根據對最新利用LIONTAIL的分析發現，受害者遍布中東地區。大多數受影響的實體屬於政府、電信、軍事和金融部門，以及IT服務提供商。

至少從2019年開始，Manticore就開始在中東地區活躍。它最初是基於開源的web部署代理，隨著時間的推移演變成一個多樣化和強大的工具集，既利用了自定義編寫的組件，也利用了開源組件。

Manticore使用的多個惡意軟件版本的代碼和功能演變概述

基於Tunna的Web shell最早的一個與攻擊者活動相關的樣本是基於Tunna的web shell, Tunna是一個開源工具，旨在通過HTTPTunna傳輸任何TCP通信。 Tunna web shell允許從外部連接到遠程主機上的任何服務，包括那些在防火牆上被阻止的服務，因為所有與web shell的外部通信都是通過HTTP完成的。在配置階段，將遠程主機的IP和端口發送給web shell，在很多情況下，主要使用Tunna來代理RDP連接。

該攻擊者使用的web shell的內部版本為Tunna v1.1g (Github上只有1.1a版本)。與開源版本相比，最重要的變化是通過使用預定義的字符串szEncryptionKey對數據進行異或處理並在末尾附加常量字符串K_SUFFIX來加密請求和響應：

攻擊者使用的“Tunna 1.1g”代理中的加密功能

Tunna代理對數據的解密和加密

FOXSHELL：XORO版本之後，代碼被重構，失去了與Tunna的相似之處。我們將此版本和所有後續版本都稱為FOXSHELL。下面的類結構在大多數FOXSHELL版本中仍然存在：

FOXSHELL中的類

所有負責加密流量的功能都轉移到一個單獨的EncryptionModule類中。此類加載一個.NET DLL，該DLL嵌入FOXSHELL主體內的base64編碼字符串中，並調用其加密和解密方法：

web shell中base64編碼的EncryptionDll

EncryptionModule類負責加密和解密方法調用

嵌入式加密模塊的名稱是XORO.dll，它的類是Encryption.XORO實現解密和加密方法的方式與基於Tunna的web shell相同，使用相同的硬編碼值：

XORO.dll中的加密常量和解密函數

所有對web shell的請求也封裝在一個名為Package的類中，該類處理不同的PackageTypes：Data、Config、OK、Dispose或Error。 PackageType是由包的第一個字節定義的，根據包的類型，web shell解析包並應用配置(在配置中指定的遠程計算機上打開一個新的套接字，如果提供的話，應用一個新的EncryptionDll)，或者處理現有的套接字，或者如果包是Data類型代理連接：

FOXSHELL中的包處理

FOXSHELL：Bsae64（非拼寫錯誤）版本這個版本的web shell仍然沒有混淆，它的內部版本在代碼中指定：

web shell還包含嵌入的默認EncryptionDll。模塊的名稱是Base64.dll，加密類(拼寫錯誤為Bsae64)公開了加密和解密方法。然而，兩者都只是簡單的base64編碼：

Base64.dll中的加密和解密方法

雖然這種簡單的編碼可以在web shell本身的代碼中完成，但其他嵌入式dll的存在，如XORO.dll，以及在配置階段提供另一個EncryptionDll的能力，意味著攻擊者更喜歡控制他們在某些環境中默認使用的特定類型的加密。

這個版本中的其他變化是將PackageType配置重命名為RDPconfig，將ConfigPackage重命名為RDPConfigPackage，表明攻擊者專注於代理RDP連接。這些類的代碼保持不變：

RDP Configuration類

最後，代碼中的另一個條件處理web shell接收非空參數WV-RESET的情況，該參數調用函數關閉代理套接字並向攻擊者發送OK響應：

“Close proxy” WV-RESET參數

編譯的FOXSHELL除了針對中東之外，這個版本也於2021年5月針對阿爾巴尼亞發起攻擊。通過利用一個面向internet的Microsoft SharePoint服務器，攻擊者部署了ClientBin。在受攻擊服務器上的Aspx來代理外部連接，從而進行橫向攻擊。

在發現的所有樣本中，FOXHELL都被編譯為DLL並嵌入到base64的基本web shell中。編譯後的DLL將加載System.Reflection.Assembly.Load，則調用來自它的ProcessRequest方法。 DLL是用.NET編寫的，其名稱模式為App_Web_

加載App_Web_*.dll的web shell

App_Web* DLL受到類和方法混淆的影響，所有字符串都使用Base64，第一個字節的異或和AES的組合加密如下：

inchpublic函數，負責字符串加密，展示了方法和類的混淆

當web shell被編譯成DLL時，它包含初始化存根，這確保web shell偵聽正確的URI。在這種情況下，初始化發生在以下代碼段：

web shell App_Web_*.dll中的初始化存根

否則，去混淆後：

這個初始化將FOXSHELL設置為偵聽相對路徑~/1上的請求。研究發現，在涉及LIONTAIL的攻擊的其他web shell中，它是一個未使用的工件。

在內部，DLL具有與以前版本相同的“1.5”版本的FOXSHELL，其中包括用於停止代理的WV-RESET參數和相同的默認Bsae64加密DLL。

基於IIS ServerManager和HTTPListener的獨立後門自2020年年中以來，除了FOXSHELL作為代理流量的手段外，我們還觀察到了一個相當複雜的獨立被動後門，它是用.NET編寫的，旨在部署在IIS服務器上。它被類似於FOXSHELL的技術混淆，並偽裝成System.Drawing.Design.dll。

CC通信SSD後門通過受感染計算機上的HTTP偵聽器設置CC通信。它是通過兩個類實現的：

ServerManager——.NET中System.Web.Administration命名空間的一部分，用於管理和配置Windows服務器上的Internet信息服務（IIS），例如獲取配置、創建、修改或刪除IIS站點、應用程序和應用程序池。

HTTPListener——.NET框架中的一個類，用於創建自定義HTTP服務器，獨立於IIS並基於HTTP API。

ServerManager用於提取IIS服務器託管的網站，並構建要偵聽的URL前綴的HashSet：

構建URL前綴HashSet的angleoppose_river函數的混亂代碼基於IIS服務器上配置的網站和綁定

本文的惡意軟件示例中配置的唯一相對URI是Temporary_Listen_Addresses。然後惡意軟件使用HttpListener類開始偵聽指定的URL前綴：

HttpListener啟動代碼

CC命令執行後門程序有幾個功能：使用cmd.exe執行命令，上傳和下載文件，使用指定參數執行進程以及運行其他.NET程序集。

SDD後門的請求handler

首先，如果POST請求主體包含數據，惡意軟件會對其進行解析，並將消息作為其支持的4個命令之一進行處理。否則，如果請求包含參數Vet，惡意軟件只需從base64中解碼其值，並用cmd/c執行。如果這些都不是真的，那麼惡意軟件會處理心跳機制，如果請求URL包含小寫的字符串wOxhuoSBgpGcnLQZxipa，則惡意軟件會發回UsEPTIkCRUwarKZfRnyjcG13DFA以及200 OK響應。

POST請求中的數據使用Base64和簡單的基於異或處理的加密進行加密：

命令解密算法

在解密消息的數據後，惡意軟件會按照以下順序對其進行解析：

處理可能的SDD後門命令類型的開關

由攻擊者命名的命令，包括：

' Command ' -使用指定參數執行進程。在該樣本中，將解析數據以提取進程名稱及其參數；

“Upload”—將文件上傳到受攻擊系統的指定路徑；

“Download”-將指定的文件發送給攻擊者；

“Rundll”-加載程序集並使用指定參數運行它。

響應數據的構建方式與請求相同（返回命令類型、命令名稱和輸出），然後使用與請求相同的基於XOR的算法進行加密。

WINTAPIX驅動程序最近，Fortinet披露了一系列針對中東目標的攻擊，這些攻擊涉及內核模式驅動程序，研究人員將其命名為WINTAPIX。儘管安裝驅動程序的確切感染鏈尚不清楚，但它們僅針對IIS服務器，因為它們使用IIS ServerManager對象。高級執行流程如下：

1.WINTAPIX驅動程序在內核中加載；

2.WINTAPIX驅動程序枚舉用戶模式進程，以查找具有本地系統權限的合適進程；

3.WINTAPIX驅動程序將嵌入的shellcode注入到先前找到的進程中，shellcode是使用開源的Donut項目生成的，這允許創建能夠從內存加載和執行.NET程序集的與位置無關的shellcode。

4.注入的shellcode加載並執行加密的.NET負載。

最後的有效負載除了已經熟悉的類、方法和字符串混淆之外，還使用商業混淆器進行混淆，並且它結合了SDD後門和FOXSHELL代理的功能。為了實現這兩個目標，它偵聽兩組URL前綴，使用ServerManager和HTTPListener，類似於SSD後門。

驅動程序負載中使用的FOXSHELL版本設置為1.7。在這個版本中引入的主要增強是使用掛起EventLog Service線程的已知技術來繞過事件日誌。在驅動程序中硬編碼的默認EncryptionDll是相同的Bsae64.dll，與FOXSHELL 1.5版本相比，核心代理結構還與原來一樣。

.NET負載中硬編碼的版本

FOXSHELL 1.7類結構

由於已經提供了對WINTAPIX驅動程序及其版本SRVNET2的廣泛分析，我們只強調它們與其他討論的工具之間的主要重疊部分，它們之間的聯繫如下：

1.與SDD後門相同的代碼庫，包括基於相同字符串值wOxhuoSBgpGcnLQZxipa和UsEPTIkCRUwarKZfRnyjcG13DFA的心跳；

2.支持相同的後門命令類型，使用相同的密鑰進行加密；

3.與FOXSHELL相同的代碼庫、結構和功能；

4.使用相同的混淆和加密方法。

LIONTAIL框架組件與FOXSHELL、SDD後門和WINTAPIX驅動程序共享類似的混淆和字符串工件。目前，我們不知道有任何其他攻擊者利用這些工具，我們根據多個代碼重疊和共享的受害者特徵將它們全部歸因於Manticore。

總結在過去的幾年裡，Manticore被觀察到在中東地區進行了頻繁活動，包括獲得該地區電信和政府組織的訪問權限，並維持和利用這種訪問權限幾個月來系統地從受害者的系統中竊取數據。分析他們的活動歷史可以發現，攻擊者一直在改進攻擊方法。

雖然LIONTAIL代表了FOXSHELL迭代的邏輯進展，並且仍然具有一些獨特的特徵，使我們能夠將涉及LIONTAIL的攻擊歸因於Manticore。 LIONTAIL框架不再依賴於Internet Information Services (IIS)、它的模塊或. net框架提供的任何其他選項和庫來以編程方式管理IIS。相反，它通過直接與HTTP.sys驅動程序交互來利用最低級別的Windows HTTP堆棧。此外，它允許攻擊者自定義植入程序、配置參數和加載程序的文件傳遞類型，這些都增強了植入程序的隱身能力，使其能夠長時間躲避檢測。預計“Manticore”活動將會更加活躍，並可能蔓延到其他地區。