恶意软件和工具分析
BeaconLoader 和 Cobalt Strike Beacon
如前所述,BeaconLoader 是使用 DLL Hijacking 上传的。在第一阶段,库接收其操作所需的函数和库的地址。然后,它会检查父进程的名称和权限类型(为了进一步工作,需要 SYSTEM 类型和名称 msdtc.exe、msdtc.exe.mui 和 vmtoolsd.exe)。这些名称以加密形式位于二进制文件中,它们的解密是根据同一个不同寻常的方案进行的:每个值都放在一个单独的寄存器中,然后每个寄存器分别以modulo 2 添加到单个字节值并复制到堆栈中。
解密进程名称的代码
此外,如果进程名称正确,请注意使用库内的直接本机调用来创建新线程,以及使用内存。
启动一个新线程
接下来,库使用有效载荷对文件名进行解密,然后读取它。请注意,文件本身必须位于与库相同的目录中。
带有载荷的文件名
然后解密主要的有效载荷,一开始,前 16 个字节与文件分离(下图中以红色突出显示),这些字节将作为准备解密密钥的基础。
文件内的加密密钥
然后是解密密钥准备的第一阶段,准备文件的 16 个分隔字节的一个周期。过程如下:每个字节加modulo 2 到以下值(有关前 6 个字节的示例,请参见下图)。此外,在某些阶段,存储在寄存器中的常量会被修改,在此基础上,加密密钥的值会在某个特定阶段发生变化。
加密密钥修改的前六次迭代
之后,从接收到的数据中读取 MD5 哈希值。结果值将是所需的加密密钥。
主要有效载荷在CBC模式下由AES算法解密,使用在准备阶段获得的16字节密钥和一个零(空)初始化向量。
解密的有效载荷
解密后,指定内存区域的安全属性通过 NtProtectVirtualMemory被更改,之后控制会在一个新的线程中转移给它们。
在使用IKEEXT服务上传的另一个版本的BeaconLoader中,很多代码部分与之前的代码是相同的,但仍然有很多不同之处。
一开始,还会检查进程名称。在该示例,进程名称应该是 svchost.exe。接下来,读取文件C:\Windows\Temp\MpCmdRun.log.1,这与前一种情况一样,它包含一个有效载荷。第一阶段的加密方案与 oci.dll 中的不同:其中前 4 个字节包含对剩余数据进行 XOR 解密的密钥, (该密钥在下图中以红色突出显示)。
解密的有效载荷
解密后,指定内存区域的安全属性通过 NtProtectVirtualMemory被更改,之后控制会在一个新的线程中转移给它们。
在使用IKEEXT服务上传的另一个版本的BeaconLoader中,很多代码部分与之前的代码是相同的,但仍然有很多不同之处。
一开始,还会检查进程名称。在本例中,进程名称应该是 svchost.exe。接下来,读取文件C:\Windows\Temp\MpCmdRun.log.1;与前一种示例一样,它包含一个有效载荷。第一阶段的加密方案与 oci.dll 中的不同:其中前 4 个字节包含对剩余数据进行 XOR 解密的密钥, (该密钥在下图中以红色突出显示)。
XOR 解密周期
解密后的数据结构如下:
请注意,sizeOfDecryptedData 值与原始文件大小相差 41:此处包含两个服务字段和加密密钥。
第一阶段解密的数据
在下一阶段,形成 AES 算法的初始化向量。该值是通过加密密钥 741668454FFA04A95EBA720E1B74A5B3(encryptionKey 字段)的 MD5 哈希获得的,然后在 AES_CBC 模式下使用这些参数对主要载荷进行解密。
解密的有效载荷
在这两种示例中,Cobalt Strike Beacon 是有效载荷,在 oci.dll 的示例下,SMB Beacon 被解密并启动,在第二种示例下,HTTPS Beacon。
在调查第一个事件时,研究人员发现了两个版本的 Cobalt Strike Beacon:一个用于通过 SMB 进行交互,另一个用于通过 HTTPS。这两个版本的配置如下所示。
HTTPS信标
两个版本都有相同的水印 1936770133,研究人员在其他攻击中并没有发现类似的情况。
当用户访问C2服务器www.funding-exchange[.]org时,会被重定向到网站thefundingexchange[.]com。但是,研究人员没有注意到此网站上有任何恶意活动。
用户被重定向到的网站的主页
BeaconLoader 和 Cobalt Strike Beacon v2
在对第二起事件的调查中,研究人员发现了两个版本的 Cobalt Strike Beacon,它们的配置如下所示。
水印1028153346是唯一的,以前没有在公开可用的资源中发现。
ProxyT
该应用程序用于检查是否存在到远程URL的连接。URL地址作为参数传递给程序,然后程序调用InternetCrackUrlA将其划分为多个组件。如果不能执行此操作,则程序结束,并在控制台中显示“Error on InternetCrackUrl: error_code”。
接下来,尝试创建连接描述符(InternetOpenA;如果出现错误,控制台将显示:"Error On InternetOpen: error_code")并初始化连接(InternetConnectA,类似地,"Error On InternetConnect: error_code" 或"Error On INTERNET_SCHEME: error_code" 将被显示)。
应用程序的主要逻辑
接下来,形成一个 GET 请求并将其发送到服务器。如果出现错误,其代码也会显示在控制台中。
带有 HTTP_QUERY_RAW_HEADERS_CRLF 参数的 HttpQueryInfoA 函数负责从服务器响应中获取标头。此参数表示将返回所有服务器响应标头,并且每个标头都将用回车符分隔。
接收到标头信息后,所有标头信息都输出到控制台(fnPrintToConsole_fromReg函数)。
DoorMe 后门
在研究人员调查事件中发现的恶意软件样本中,DoorMe后门是最有趣的。基本上,它是一个本机IIS模块,注册为处理HTTP请求和响应的过滤器。
该文件有两个入口点:主入口点没有任何函数集,第二个入口点是registermodule,它是注册本机模块所必需的,它初始化 DoorMe 类的一个实例。该名称暗指后门功能。研究人员在公共来源中没有发现任何类似后门。
原始代码的调试行与研究人员在后门中发现的相同,这表明某些处理程序没有在后门中实现:
来自 Microsoft IIS.Common 存储库中其中一个函数的调试消息
该模块为 OnGlobalPreBeginRequest 事件创建自己的处理程序,该事件在处理IIS上web应用程序的web界面接收到的请求之前启动。
处理程序被混淆,几乎所有的字符串都用 XOR 加密,这使得分析变得复杂。
处理程序的逻辑如下:
1. 模块决定哪个短语会开启主要的后门功能。该短语在注册表中的 HKEY_CLASSES_ROOT\\.zip\\config 中设置。如果密钥不在注册表中,则使用默认的“fuckme”短语。
访问注册表以获取所需的值
2. 传入的 HTTP 请求应包含带有 MD5(key) 值的 IISSessions cookie。本例中的MD5来自fuckme,即79cfdd0e92b120faadd7eb253eb800d0。如果不满足此条件,该函数将不会干扰请求处理。
3.如果请求方法是GET,函数返回字符串。这是攻击者的一个指标,表明后门确实已安装并正在运行。
形成对 GET 请求的响应
4.如果请求方式为POST,则接收到的POST请求的内容使用AES加密。密钥为MD5—MD5的前半部分(source_key)。
总的来说,这个后门可以接收6个不同的命令。命令及其参数之间的分隔符是管道符号:|
命令执行的结果以加密形式返回。
第二版DoorMe 后门
在调查第二起事件时,研究人员发现了这个后门的扩展版本:混淆方式发生了变化,出现了新的命令。但是,包含实现一组后门函数的重写方法的类的名称保持不变——DoorMe。
使用 DoorMe 类
为了使分析更加复杂,使用了调度程序的控制流混淆:
控制流混淆
这个后门的一些敏感字符串现在是明文的,而另一些则受到以下混淆方案的影响:
字符串混淆
仔细查看 x[i] 和 y[i] 值,你会发现它们互为倒数。因此,每个字节的最终公式都可以被简化:
有趣的是,这个公式可以归结为两个XOR,并且鉴于代码使用相同的 x 和 z 对,可以说这些字符串的生成器可能更简单。
与 IDA Pro 不同,Ghidra 简化了这些等式,尽管它并没有处理所有这些:
Ghidra 反编译器中的字符串混淆
此外,还使用了一种“破坏”IDA Pro 的技术:它错误地拆分了函数,导致图的某些节点从反编译器中消失。
反调试方法
IDAPython 脚本解决了这个问题:
与之前的版本相比,命令的数量增加到了 11条:
网络基础设施
在创建网络基础设施时,攻击者试图尽可能将自己伪装成合法服务。攻击者注册了伪装成Microsoft、TrendMicro、McAfee、IBM 和 Google 合法服务的网络钓鱼域,包括他们的支持服务、内容交付 (cdn) 和更新。以下是一些已发现的域:newtrendmicro.com、centralgoogle.com、microsoft-support.net、cdn-chrome.com、mcafee-upgrade.com。 APT 组织还在其服务器上放置了 SSL 证书,这些证书也模仿了合法的证书:github.com、www.ibm.com、jquery.com、update.microsoft-support.net。
ChamelGang 服务器上的 其中一个SSL 证书
钓鱼证书信息:
通过 JARM 获得的数据表明攻击者在连接到网络基础设施的服务器上使用 Cobalt Strike 框架。在攻击期间,该组织还使用Beacon(来自 Cobalt Strike 框架)作为主要载荷。这一事实进一步支持了研究人员的假设,即该网络基础设施是由相同的攻击者创建的。
攻击者的服务器主要位于几个子网上:
154.210.12.0/24
194.113.172.0/24
45.131.25.0/24
45.158.35.0/24
45.195.1.0/24
45.91.24.0/24
根据某些域的 WHOIS 数据和 SOA 记录,研究人员设法获得了注册或用作联系地址的电子邮件地址。请注意,为了达到这个目的,攻击者使用了内置加密的ProtonMail邮件服务。
为了使网络基础设施的分析复杂化,攻击者将其域的 IP 地址隐藏在 CloudFlare 中。
攻击对象
除了俄罗斯的两个组织(燃料和能源以及航空生产公司)被攻击外,美国、日本、土耳其、台湾、越南、印度、阿富汗、立陶宛和尼泊尔等10个国家的13个大型机构也被攻击了。特别是,印度、阿富汗、立陶宛和尼泊尔的政府服务器被攻破。 Microsoft Exchange Server 位于几乎所有受攻击的节点上。这些节点很可能是通过ProxyLogon和ProxyShell等漏洞被破坏的。
总结
由于执行的复杂性,信任关系攻击在今天很少见。在第一个示例中使用这种方法,ChamelGang组织能够实现其攻击目标,并从受攻击的网络中窃取数据。此外,该组织还试图使用操作系统功能和合理的网络钓鱼域将其活动伪装成合法活动。此外,攻击者还为IIS服务器留下了一个以模块形式存在的被动后门DoorMe。在对 ChamelGang 组织活动的进一步调查中,研究人员发现了五个国家/地区的政府服务器遭到攻击。此外,攻击者开始尝试利用 ProxyShell 漏洞。 FireEye 最近的研究证实了其利用示例数量的增加。
本文翻译自:https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/new-apt-group-chamelgang/如若转载,请注明原文地址