最新Patchwork(白象)Protego远控木马接收某远控指令后将导致远控木马无法响应后续远控指令

文章首发地址：
https://xz.aliyun.com/t/16255
文章首发作者：
T0daySeeker

概述

近日，笔者在浏览威胁情报的时候，发现了不少Patchwork(白象)APT组织使用的最新活动样本，在对其进行分析研究的过程中，无意间发现了Patchwork(白象)APT组织使用的Protego远控木马存在多处逻辑BUG，严重的将导致远控木马无法再响应后续远控指令。

相关威胁情报截图如下：

释放程序分析

通过分析，发现c417fb3008a6180fc6099d5e4d3d8849b3b12477dfa7008af1fdd356f0840622程序是一个用于释放后续载荷的释放程序，详细情况如下：

解密算法

通过分析，发现此样本运行后，即会从自身区段中使用解密算法解密shellcode，相关代码截图如下：

创建线程

通过分析，发现此样本将使用CreateThread函数加载执行shellcode代码，相关代码截图如下：

内存加载Protego远控木马

通过分析，发现shellcode运行后，将解密释放最终Protego远控木马。

「备注：由于Protego远控木马是由.NET编写的，因此，我们在使用工具查看其进程模块时，即会很直观的发现其为.NET程序。」

相关截图如下：

Protego远控木马分析

尝试从内存中提取PE文件内存片段，通过分析，发现其为Protego远控木马，详细分析情况如下：

互斥对象

通过分析，发现Protego远控木马运行后，首先会创建互斥对象，以保证主机中只有一个实例运行，相关代码截图如下：

内置配置信息

样本内置了外联地址及自定义加解密算法密钥信息。「（备注：实际上，内置的密钥信息并没有使用。。。。。。）」

相关代码截图如下：

木马上线

样本运行后，即将发起上线请求，上线请求载荷中将包含sosid与slid数据，相关代码截图如下：

上线请求数据包截图如下：

自定义加解密算法

通过分析，发现此样本通信过程中的通信数据均会使用自定义加解密算法对其进行加解密运算。

加密算法代码截图如下：

解密算法代码截图如下：

上传主机信息

通过分析，发现主机上线成功后，将加密上传主机信息，主机信息包括：系统版本、主机名、用户名、木马路径、IP地址、系统防病毒软件、系统所有已安装程序等信息。

相关代码截图如下：

远控指令

成功上传主机信息后，样本将循环发起心跳请求，用以接收远控指令，相关远控指令如下：

相关代码截图如下：

inmem指令

通过分析，当样本接收到“inmem shellcode路径”指令时，样本将从C&C地址外联下载shellcode载荷，然后调用VirtualAlloc与CreateThread函数加载执行shellcode代码。

相关代码截图如下：

download指令

通过分析，当样本接收到“download 文件路径”指令时，则将从被控主机中压缩上传指定文件至C&C服务器。

相关代码截图如下：

downexe指令

通过分析，当样本接收到“downexe 外联URL”指令时，则将外联下载exe程序文件，然后运行此exe程序文件。

相关代码截图如下：

lksfjdgjkxv指令

通过分析，当样本接收到“lksfjdgjkxv cmd命令”指令时，则将调用cmd执行cmd命令。

「备注：远控指令中很多远控指令与cmd命令指令相同，因此，攻击者增加了此指令便于对cmd命令的区分运行」

相关代码截图如下：

自定义加解密算法详解

自定义加密算法

梳理自定义加密算法逻辑如下：

• 调用xop函数对数据异或加密
• 调用b64E函数对数据Base64编码
• 调用Protean函数对数据进行自定义加密
• 调用Homenum函数对数据进行加密，密钥为：0|\|3 |>|3c3
• 调用FerulaE函数对数据进行加密，密钥为：+_I-I3 |<||\|9 |5 |3/-\c|<
• 对加密数据进行Base64编码

xop函数代码截图如下：

Protean函数代码截图如下：

Homenum函数代码截图如下：

FerulaE函数代码截图如下：

自定义解密算法

梳理自定义解密算法逻辑如下：

• 调用Charm函数对数据进行自定义解密
• 对加密数据进行Base64解码
• 调用FerulaD函数对数据进行解密，密钥为：+_I-I3 |<||\|9 |5 |3/-\c|<（FerulaD底层也是调用FerulaE函数）
• 调用Revelio函数对数据进行解密，密钥为：0|\|3 |>|3c3
• 对数据进行Base64解码
• 调用xop函数对数据异或解密

Charm函数代码截图如下：

FerulaD函数代码截图如下：

Revelio函数代码截图如下：

xop函数代码截图如下：

程序逻辑BUG

异或密钥未发挥作用

通过分析，发现此样本其实在第一次上线时，即会从控制端接收一段数据用作后续的异或算法密钥，但由于代码逻辑原因，导致此密钥未发挥作用。

第一次上线接收异或密钥的代码截图如下：

后续接收远控指令时调用异或解密算法代码截图如下：

进一步剖析，发现：

• xop函数实际上并未使用key参数对text参数进行异或加密
• xop11函数会使用key参数对text参数进行异或加密，但仅在第一次上线解密接收数据时使用过

相关代码截图如下：

压缩上传文件时，压缩文件大小比原始文件大小大很多

在使用download指令从被控端下载指定文件时，笔者发现了一个比较有趣的地方，应该是远控木马开发人员开发程序时没有认真测试过传输文件吧……导致文件压缩后的文件比原始文件大挺多，具体情况如下：

远控指令：download C:UsersadminDesktop111.txt

被控端指定文件大小为20字节，截图如下：

远控木马通信传输的文件大小为1864381字节，截图如下：

解密还原的文件大小为1MB，远远大于原始文件大小，截图如下：

尝试对其原理进行梳理，发现其代码逻辑为：

• 本地压缩原始文件，存放于%temp%目录；
• 初始化缓冲区大小byte[] array = new byte[1048576]，调用bufferedStream.Read(array, 0, 1048576)函数读取压缩后的文件内容；
• 加密载荷内容，发送数据；

相关代码截图如下：

通过分析代码，发现此远控木马是通过分段传输的方式实现的文件传输，木马程序每次均会读取1048576字节大小数据，然后加密发送。

整段代码虽然能够正常运行，但是在通信过程中，却发送了大量的空字节数据，且发送数据大约为1MB的整数倍大小，例如：若压缩后的文件大小<1MB，则通信过程中将传输1MB大小的加密数据；若1MB < 压缩后的文件大小 < 2MB，则通信过程中将传输2MB大小的加密数据。

本地压缩后的文件内容如下：

通信过程中接收的压缩文件内容如下：

执行enablecmd指令后，将导致远控木马无法再响应后续远控指令

在执行enablecmd指令时，笔者发现此命令的设计初衷与实际功能不符，执行enablecmd命令后，将导致远控木马无法再响应攻击者的后续远控指令。

远控木马代码中的字符串信息为“Cmd mode enabled, all commands will be redirect to CMD. Response delay is : miliseconds”，此字符串的意思是：开启cmd模式，后续所有远控指令均将重定向至cmd运行。

实际代码逻辑中，开启cmd模式后，将导致远控木马无法再进入响应远控指令的代码分支中，相关代码截图如下：