MANTICORE的攻击范围正在逐步扩大(下)
2023-12-29 11:32:0 Author: www.4hou.com(查看原文) 阅读量:9 收藏

MANTICORE的攻击范围正在逐步扩大(上)

Web shell

Manticore部署了多个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)中观察到的那样:

14.png

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

攻击目标

根据对最新利用LIONTAIL的分析发现,受害者遍布中东地区。大多数受影响的实体属于政府、电信、军事和金融部门,以及IT服务提供商。

至少从2019年开始,Manticore就开始在中东地区活跃。它最初是基于开源的web部署代理,随着时间的推移演变成一个多样化和强大的工具集,既利用了自定义编写的组件,也利用了开源组件。

16.png

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来加密请求和响应:

17.png

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

18.png

Tunna代理对数据的解密和加密

FOXSHELL: XORO版本

之后,代码被重构,失去了与Tunna的相似之处。我们将此版本和所有后续版本都称为FOXSHELL。下面的类结构在大多数FOXSHELL版本中仍然存在:

19.png

FOXSHELL中的类

所有负责加密流量的功能都转移到一个单独的EncryptionModule类中。此类加载一个.NET DLL,该DLL嵌入FOXSHELL主体内的base64编码字符串中,并调用其加密和解密方法:

20.png

 web shell中base64编码的EncryptionDll

21.png

EncryptionModule类负责加密和解密方法调用

嵌入式加密模块的名称是XORO.dll,它的类是Encryption.XORO实现解密和加密方法的方式与基于Tunna的web shell相同,使用相同的硬编码值:

22.png

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

所有对web shell的请求也封装在一个名为Package的类中,该类处理不同的PackageTypes: Data、Config、OK、Dispose或Error。PackageType是由包的第一个字节定义的,根据包的类型,web shell解析包并应用配置(在配置中指定的远程计算机上打开一个新的套接字,如果提供的话,应用一个新的EncryptionDll),或者处理现有的套接字,或者如果包是Data类型代理连接:

23.png

FOXSHELL中的包处理

FOXSHELL: Bsae64(非拼写错误)版本

这个版本的web shell仍然没有混淆,它的内部版本在代码中指定:

24.png

web shell还包含嵌入的默认EncryptionDll。模块的名称是Base64.dll,加密类(拼写错误为Bsae64)公开了加密和解密方法。然而,两者都只是简单的base64编码:

24+.png

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

虽然这种简单的编码可以在web shell本身的代码中完成,但其他嵌入式dll的存在,如XORO.dll,以及在配置阶段提供另一个EncryptionDll的能力,意味着攻击者更喜欢控制他们在某些环境中默认使用的特定类型的加密。

这个版本中的其他变化是将PackageType配置重命名为RDPconfig,将ConfigPackage重命名为RDPConfigPackage,表明攻击者专注于代理RDP连接。这些类的代码保持不变:

25.png

RDP Configuration类

最后,代码中的另一个条件处理web shell接收非空参数WV-RESET的情况,该参数调用函数关闭代理套接字并向攻击者发送OK响应:

26.png

“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_

27.png

加载App_Web_*.dll的web shell

App_Web* DLL受到类和方法混淆的影响,所有字符串都使用Base64,第一个字节的异或和AES的组合加密如下:

28.png

inchpublic函数,负责字符串加密,展示了方法和类的混淆

当web shell被编译成DLL时,它包含初始化存根,这确保web shell侦听正确的URI。在这种情况下,初始化发生在以下代码段:

29.png

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

否则,去混淆后:

30.png

这个初始化将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。

C&C通信

SSD后门通过受感染计算机上的HTTP侦听器设置C&C通信。它是通过两个类实现的:

ServerManager——.NET中System.Web.Administration命名空间的一部分,用于管理和配置Windows服务器上的Internet信息服务(IIS),例如获取配置、创建、修改或删除IIS站点、应用程序和应用程序池。

HTTPListener——.NET框架中的一个类,用于创建自定义HTTP服务器,独立于IIS并基于HTTP API。

ServerManager用于提取IIS服务器托管的网站,并构建要侦听的URL前缀的HashSet::

31.png

构建URL前缀HashSet的angleoppose_river函数的混乱代码基于IIS服务器上配置的网站和绑定

本文的恶意软件示例中配置的唯一相对URI是Temporary_Listen_Addresses。然后恶意软件使用HttpListener类开始侦听指定的URL前缀:

32.png

HttpListener启动代码

C&C命令执行

后门程序有几个功能:使用cmd.exe执行命令,上传和下载文件,使用指定参数执行进程以及运行其他.NET程序集。

33.png

SDD后门的请求handler

首先,如果POST请求主体包含数据,恶意软件会对其进行解析,并将消息作为其支持的4个命令之一进行处理。否则,如果请求包含参数Vet,恶意软件只需从base64中解码其值,并用cmd/c执行。如果这些都不是真的,那么恶意软件会处理心跳机制,如果请求URL包含小写的字符串wOxhuoSBgpGcnLQZxipa,则恶意软件会发回UsEPTIkCRUwarKZfRnyjcG13DFA以及200 OK响应。

POST请求中的数据使用Base64和简单的基于异或处理的加密进行加密:

34.png

命令解密算法

在解密消息的数据后,恶意软件会按照以下顺序对其进行解析:

35.png

处理可能的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版本相比,核心代理结构还与原来一样。

36.png

.NET 负载中硬编码的版本

37.png

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”活动将会更加活跃,并可能蔓延到其他地区。

文章翻译自:https://research.checkpoint.com/2023/from-albania-to-the-middle-east-the-scarred-manticore-is-listening/如若转载,请注明原文地址


文章来源: https://www.4hou.com/posts/poD1
如有侵权请联系:admin#unsafe.sh