.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
Check Point Research與Sygnia事件響應小組合作，追踪分析Manticore活動，這是一個主要針對中東政府和電信部門的攻擊活動。據分析，Manticore與OilRig(又名APT34、EUROPIUM、Hazel Sandstorm)有關聯。
在最新的攻擊活動中，攻擊者利用了LIONTAIL框架，這是一套複雜的自定義加載程序和內存駐留shellcode有效負載。 Manticore使用HTTP.sys驅動程序的未記錄功能從傳入的HTTP流量中提取有效負載。觀察到的LIONTAIL相關惡意軟件的多種變體表明，Manticore為每台受攻擊的服務器生成了一個自定義的植入程序，使惡意活動能夠融入合法的網絡流量中，並且無法從中識別。
儘管LIONTAIL框架本身看起來很獨特，並且與任何已知的惡意軟件家族沒有明顯的代碼重疊，但這些攻擊中使用的其他工具與之前報告的活動重疊。最值得注意的是，其中一些最終與OilRig有關聯。
在這篇文章中，我們提供了最新工具的技術分析。
LIONTAIL框架LIONTAIL是一個惡意軟件框架，包括一組自定義shellcode加載器和內存駐留shellcode有效負載。它的一個組件是用c語言編寫的LIONTAIL後門。它是一個輕量級但相當複雜的被動後門，安裝在Windows服務器上，使攻擊者能夠通過HTTP請求遠程執行命令。後門為其配置中提供的url列表設置偵聽器，並執行攻擊者向這些url發送請求的有效負載。
LIONTAIL後門組件是最新的Manticore攻擊中使用的主要植入程序。利用來自面向公眾服務器的訪問權限，攻擊者鏈接了一組被動植入程序來訪問內部資源。到目前為止，我們看到的LIONTAIL後門的內部樣本要么偵聽HTTP，要么在某些情況下使用命名管道來促進遠程代碼執行。
LIONTAIL惡意軟件框架概述
LIONTAIL加載器安裝我們觀察到在受攻擊的Windows服務器上有兩種後門安裝方法：獨立可執行文件和通過Windows服務或合法進程的搜索順序劫持加載的dll。
當作為DLL安裝時，惡意軟件利用Windows Server操作系統發行版中缺少的一些DLL：後門被放置到系統文件夾C：\ Windows \system32中，作為wlanapi.dll或wlbsctrl.dll。默認情況下，Windows Server安裝中不存在這兩個選項。根據Windows Server版本，惡意DLL繼續由其他進程(如Explorer.exe)直接加載，或者攻擊者啟用特定服務(默認禁用)，這些服務需要這些DLL。
在wlbsctrl.dll的情況下，DLL在IKE和AuthIP IPsec key Modules服務開始時加載。對於wlanapi.dll，攻擊者啟用可擴展身份驗證協議：
sc.execonfigEaphoststart=auto；
sc.exestartEaphost；在將LIONTAIL作為可執行文件部署的樣本中，觀察到的一個值得注意的特徵是試圖將可執行文件偽裝成Cyvera Console (Cortex XDR的一個組件)。
配置惡意軟件首先對包含其配置的結構執行一個1字節的異或解密，該結構用以下結構表示：
字段listen_urls定義了惡意軟件偵聽傳入請求的特定URL前綴
所有示例的URL列表都包含http://+:80/Temporary_Listen_Addresses/前綴，這是一個默認的WCF URL保留，允許任何用戶從該URL接收消息。其他示例包括端口80、443和444上的多個url(在Exchange服務器上)，模擬現有服務，例如：
https://+:443/autodiscover/autodiscovers/；
https://+:443/ews/exchanges/；
https://+:444/ews/ews/；許多LIONTAIL示例包含量身自定義的配置，其中添加了多個其他自定義url，以匹配受攻擊服務器上現有的web文件夾。由於實際的IIS服務已經使用了現有文件夾的url，因此生成的有效負載在路徑中包含額外的隨機字典單詞。這確保了惡意軟件通信與合法通信融合在一起，方便隱藏。
配置中所有前綴的host元素由單個加號(+)組成，這是一個匹配所有可能主機名的“強通配符”。當應用程序需要處理指向一個或多個相對url的請求時，無論這些請求如何到達計算機或它們在host標頭中指定的站點(主機或IP地址)，強通配符都是有用的。
為了理解惡意軟件如何在這些前綴上配置偵聽器以及該方法如何隨時間變化，有必要對Windows HTTP堆棧有所了解。
Windows HTTP棧組件WindowsServer2003中引入了一種端口共享機制，允許多個HTTP服務共享相同的TCP端口和IP地址。該機制封裝在HTTP.sys中，HTTP.sys是一個內核模式驅動程序，負責處理HTTP請求，偵聽傳入的HTTP請求，並將它們引導到相關的用戶模式進程或服務以進行進一步處理。
在驅動程序層之上，Windows提供了HTTP服務器API，這是一個用戶模式組件，提供了與HTTP.sys交互的接口。此外，後台的Internet信息服務（IIS）依賴於HTTP API與HTTP.ssys驅動程序交互。以類似的方式，NET框架中的HttpListener類是圍繞HTTPServerneneneba API的簡單包裝器。
Windows服務器上HTTP棧組件的架構
應用程序接收和處理特定URL前綴請求的過程可以概述如下：
1.惡意軟件通過Windows操作系統提供的任何方式向HTTP.sys註冊一個或多個URL前綴。
2.當接收到HTTP請求時，如果該惡意軟件負責該前綴，HTTP.sys識別與請求前綴相關聯的應用程序，並將該請求轉發給惡意軟件。
3.惡意軟件的請求handler隨後接收HTTP.sys截獲的請求，並為其生成響應。
CC通信在提取配置後，惡意軟件使用相同的1字節異或通過偵聽提供的URL前綴列表來解密負責建立CC通信通道的shellcode。雖然在面向web的Windows服務器上使用被動後門的概念並不新鮮，早在2019年就有人在野外觀察到它劫持了同一個Windows DLL wblsctrl.DLL，但LIONTAIL的開發人員提高了他們的方法。該惡意軟件不使用HTTP API，而是使用IOCTL與底層HTTP.sys驅動程序直接交互。這種方法更隱蔽，因為它不涉及IIS或HTTP API，這些通常由安全解決方案密切監控，但考慮到HTTP.sys的IOCTL沒有記錄，還需要進一步研究。
首先，shellcode使用以下IOCTL向HTTP.sys註冊URL前綴：
0x128000–UlCreateServerSessionOctl：創建HTTP/2.0會話。
0x128010–UlCreateUrlGroupIoctl：創建新的UrlGroup。 UrlGroup是在服務器會話下創建的一組URL的配置容器，並繼承其配置設置。
0x12801d–UlSetUrlGroupIoctl：通過設置HttpServerBindingProperty將UrlGroup與請求隊列相關聯。
0x128020–UlAddUrlToUrlGroupIoctl：將listen_urls數組添加到新創建的UrlGroup中。
HTTPsys IOCTL表
註冊URL前綴後，後門啟動一個負責處理傳入請求的循環，直到它從一個等於後門配置中提供的end_string的URL獲得請求。
後門使用0x124036–UlReceiveHttpRequestIoctl IOCTL接收HTTP.sys的請求。
根據受攻擊服務器的版本，使用0x12403B–UlReceiveEntityBodyIoctl或（如果高於20348）0x12403A–UlReceiveEntityBodyFastIo接收請求正文。然後，通過將整個數據與數據的第一個字節異或，對其進行base64解碼和解密。這是在多個惡意軟件家族中觀察到的常見加密方法，包括但不限於DEV-0861的網絡部署反向代理。
來自LIONTAIL有效負載的CC解密方案
解密後的有效負載具有以下結構：
惡意軟件創建一個新線程並在內存中運行shellcode。由於某種原因，它使用請求消息中的shellcode_output和shellcode_output_size作為指向內存中各自數據的指針。
為了加密響應，惡意軟件選擇一個隨機字節，使用它作為密鑰對數據進行異或編碼，將密鑰添加到結果中，然後對整個結果進行base64編碼，最後使用IOCTL0x12403F - UlSendHttpResponseIoctl將其發送回CC服務器。
LIONTAIL web shell除了PE植入程序外，Manticore還使用基於web shell的LIONTAIL shellcode加載器。 web shell以類似於其他Manticore . net有效負載和web shell的方式進行混淆。
LIONTAIL web shell的主要函數(格式化，保留混淆)
web shell接收帶有2個參數的請求：
马云惹不起马云 要執行的shellcode；
马云惹不起马云要使用的shellcode參數；
這兩個參數的加密方式與其他通信相同：對第一個字節進行異或，然後進行base64編碼。
發送到基於web shell的shellcode加載程序的shellcode和參數的結構與LIONTAIL後門中使用的結構相同，這表明觀察到的工件是一個更大框架的一部分，該框架允許根據攻擊者的訪問和需求動態構建加載程序和有效負載。
使用命名管道的LIONTAIL版本我們還發現了與LIONTAIL樣本具有相似內部結構的加載器。這個版本不是偵聽URL前綴，而是從命名管道獲取有效負載，並且可能被指定安裝在無法訪問公共web的內部服務器上。惡意軟件的配置有點不同：
主shellcode首先將字符串安全描述符“D:（A；FA；WD）”轉換為有效的、功能性的安全描述符。由於字符串以“D”開頭，它表示DACL（自由訪問控制列表）條目，通常具有以下格式：entry_type:heritance_flags（ACE_type；ACE_flags；rights；object_GUID；heritance_object_GUID；account_SID）。在該樣本中，安全描述符允許（A）對所有人（WD）進行文件全訪問（FA）。
然後使用安全描述符根據配置中提供的值創建命名管道。在我們觀察到的示例中，所使用的管道的名稱是\\.\pipe\test-pipe。
值得注意的是，與HTTP版本不同，惡意軟件沒有使用任何更高級的技術來連接到命名管道，從中讀取和寫入。相反，它依賴於標準的kernel32.dll api，如CreateNamedPipe和ReadFileWriteFile。
基於命名管道的LIONTAIL的通信與HTTP版本相同，具有相同的加密機制和相同的負載結構，在內存中作為shellcode運行。
LIONTAIL內存組件有效負載類型在LIONTAIL加載器解密從攻擊者的CC服務器接收到的有效負載及其參數後，它開始解析參數。它是一個結構，描述了shellcode要執行的有效負載類型，並且根據有效負載的類型構建不同：
TYPE=1 ：執行另一個shellcode：
TYPE=2 ：執行指定的API函數：
API執行的參數結構如下：
下一個階段為了防止分析，Manticore將最終有效負載封裝在嵌套的shellcode中。例如，從攻擊者那裡收到的一個shellcode會運行另一個幾乎相同的shellcode，而這個shellcode又會運行負責計算機指紋識別的最後一個shellcode。
此有效負載收集的數據是通過運行特定的Windows api或枚舉註冊表項收集的，並包括以下組件：
1.計算機名(使用GetComputerNameW API)和域名(使用GetEnvironmentVariableA API)；
2.如果系統是64位的標誌(使用GetNativeSystemInfo API，檢查是用wProcessorArchitecture==9完成的)；
3.處理器數量(使用GetNativeSystemInfo API的dwNumberOfProcessors)；
4.物理內存(GetPhysicallyInstalledSystemMemory)；
5.來自當前版本註冊表項的數據(類型、名稱長度、名稱、數據長度和數據)；
6.來自SecureBoot\State註冊表項的數據；
7.來自System\Bios註冊表項的數據；
最後的結構包含所有收集到的信息，也有一個錯誤代碼的位置，供攻擊者使用，以找出為什麼他們使用的一些api不像預期的那樣運行：
額外的工具除了使用LIONTAIL，我們還觀察到Manticore利用了其他自定義組件。
LIONHEAD網絡傳送器在一些被攻擊的交換服務器上，攻擊者部署了一個名為LIONHEAD的小型網絡傳送器。 LIONHEAD也作為服務安裝，使用與LIONTAIL相同的幻影DLL劫持技術，並利用類似的機制將流量直接轉發到Exchange Web Services (EWS)終端。
LIONHEAD的配置與LIONTAIL不同：
後門以與LIONTAIL相同的方式註冊listen_urls前綴並偵聽請求。對於每個請求，後門都會復制內容類型、cookie和正文，並將其轉發到配置中指定的
這個傳送器可以用來繞過對EWS外部連接的限制，隱藏EWS數據的真正使用者。