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，攻击者启用可扩展身份验证协议：

在将LIONTAIL作为可执行文件部署的样本中，观察到的一个值得注意的特征是试图将可执行文件伪装成Cyvera Console (Cortex XDR的一个组件)。

    配置

恶意软件首先对包含其配置的结构执行一个1字节的异或解密，该结构用以下结构表示：

字段listen_urls定义了恶意软件侦听传入请求的特定URL前缀

所有示例的URL列表都包含 http://+:80/Temporary_Listen_Addresses/前缀，这是一个默认的WCF URL保留，允许任何用户从该URL接收消息。其他示例包括端口80、443和444上的多个url(在Exchange服务器上)，模拟现有服务，例如：

许多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截获的请求，并为其生成响应。

    C&C通信

在提取配置后，恶意软件使用相同的1字节异或通过侦听提供的URL前缀列表来解密负责建立C&C通信通道的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有效负载的C&C解密方案

解密后的有效负载具有以下结构：

恶意软件创建一个新线程并在内存中运行shellcode。由于某种原因，它使用请求消息中的shellcode_output和shellcode_output_size作为指向内存中各自数据的指针。

为了加密响应，恶意软件选择一个随机字节，使用它作为密钥对数据进行异或编码，将密钥添加到结果中，然后对整个结果进行base64编码，最后使用IOCTL 0x12403F - UlSendHttpResponseIoctl将其发送回C&C服务器。

    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加载器解密从攻击者的C&C服务器接收到的有效负载及其参数后，它开始解析参数。它是一个结构，描述了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数据的真正使用者。

参考及来源：https://research.checkpoint.com/2023/from-albania-to-the-middle-east-the-scarred-manticore-is-listening/