本文将根据360Netlab报告中提到的RotaJakiro后门特点以及微步报告中描述的Buni后门特点对二者关联分析。经分析,两种后门的相似之处如下:
单一实例
RotaJakiro通过文件锁来实现单一实例,具体实现如下图左所示。图右为Buni单一实例实现方式

发包与收包
RotaJakiro后门将构造上线信息加密发送至C2,其中send函数如下

同样的,recv函数也十分相似

然而,RotaJakiro与Buni的不同之处似乎更多
C2解密算法
OceanLotus RotaJakiro样本中调用AES+Rotate Left解密C2,对抗技巧之一:使用stack strings obfuscation技术存储加密的敏感资源信息。其与解密相关的各种参数如下图所示,密文长度为32字节,明文长度为26字节

AES解密,其中aes_dec的采用的是AES-256, CBC模式,key&iv都是硬编码。
Rotate为循环移位,此处使用的循环左移,其中移位的次数由plain_len(明文长度)&7的值决定

AES解密后得到以下“次级密文”:

从次级密文中取出有效密文,其中有效密文从第8字节开始,长度为明文长度减8,此处即为26-8=18字节。
最后通过明文长度26可以计算26&7=2,得到移位的次数,将上述有效密文逐字节左移2位之后得到C2明文。

而Buni后门中使用的C2加密算法为XOR

与0xB1异或结果为 zabbixasaservice.com:443
结构化流量/网络通信包
RotaJakiro的网络通信包由Head,Key,Payload三部分组成。其中header是必须的,长度为82字节,而body&payload部分是可选的。head&key采用的XOR&Rotate加密,payload采用AES&ZLIB加密压缩。

- head通过逐字节左移3位,然后和0x1b异或进行解密
解密后可得
offset 0x09, 4 bytes -> payload length
offset 0x0d, 2 bytes -> key length
offset ox0f, 4 bytes -> cmdid
key的长度为0x8字节,payload 的长度为0x20字节,要执行的指令码为0x18320e0,即上报设备信息
- key使用和head一样的解密方法,解密后作为AES的密钥来解密payload
- payload 使用解密后的key做为AES-256的密钥,以CBC模式解密,第8字节起即为ZLIB压缩数据,进行解压
解压后做为新的AES密钥,配合参数解密样本中硬编码的加密指令
最后发送至C2的数据包仍以上述结构组成,其中payload 经解密为上述指令执行的结果
Buni则是通过逐字节recv接收的方式解析流量结构

解析结果如下,要执行的指令码为0xdafe

Buni的通信流量特征与RotaJakiro相似度较低
- 进程伪装
RotaJakiro进程伪装对root/non-root做了区分
针对root用于伪装的文件名:/bin/systemd/systemd-daemon 或 /usr/lib/systemd/systemd-daemon;
针对non-root:$HOME/.dbus/sessions/session-dbus 和$HOME/.gvfsd/.profile/gvfsd-helper
Buni 通过随机函数产生6-12的随机长度字符串,调用 prctl 函数设置随机进程名称,伪装成系统进程
再来看RotaJakiro与2017年Palo Alto披露的海莲花macOS后门的相同之处
- C2会话建立函数
RotaJakiro与海莲花macOS后门均使用了相对小众的getaddrinfo()函数,Buni后门中则使用Linux常见的域名解析函数gethostbyname()。
- 上线包构造手法
RotaJakiro和海莲花的网络数据包都是由Head,Key,Payload三部分组成,其中Head是必须的,长度为82字节,而Key和Payload则是可选的。Head中的关键字段包括:
偏移1,DWORD类型,存放一个magic;
偏移9,DWORD类型,存放Payload长度;
偏移13,WORD类型,存放Key长度;
偏移15,DWORD类型,存放消息码。
RotaJakiro通过一个单独的函数初始化上线包的Head,海莲花样本中也存在一个专门初始化上线包Head的函数

最终上线包如下,RotaJakiro与海莲花上线包明文结构一样,关键字段值基本相同

Buni上线包如下

- 均存在rotate函数
RotaJakiro和海莲花都存在一个“rotate()”的函数,用于加/解密,Buni后门不包含该特征
- 相同的指令码
RotaJakiro和海莲花都用DWORD类型的指令码来指定消息的功能,并且共享了多个语义相同的指令码。
Buni指令码为WORD类型,未发现指令码共享
研究人员将Buni后门归因为海莲花的主要原因是其与RotaJakiro后门存在相似之处。
经分析,Buni后门与RotaJakiro后门的关联性较低,只有创建文件锁、发包与收包函数相似,在其他方面例如加解密算法:RotaJakiro样本中几乎没有明文存在,C2地址以及执行指令均经过加密,涉及到的算法包括动态AES、Rotate Letf、ZLIB,而Buni中的指令以明文硬编码存在,C2地址仅以异或加密,上线包特征,指令特征,持久化实现、进程伪装等方向均无重合之处,因此笔者认为Buni后门或不足以归因为海莲花
更多【RotaJakiro后门与Buni后门关联性分析】相关视频教程:www.yxfzedu.com