go 二进制程序守护_Blackrota，一个Go开发的高度混淆的后门-CSDN博客

文章转载自Netlab三六零

概述

近日，国内有关安全团队捕获到一个用 Go 语言编写的恶意后门程序，该程序利用 Docker Remote API 未授权访问漏洞来传播。由于它上线的 C2 为 blackrota.ga ，我们把它命名为 Blackrota。

Blackrota 的后门程序目前只有 Linux 版，是 ELF 文件格式，支持 x86和x86-64 两种 CPU 架构。Blackrota 基于 geacon 配置和编译，geacon 是一个以 Go 语言实现的 CobaltStrike Beacon。它可作为 CobalStrike 的 Beacon 与 CobaltStrike 交互来控制失陷的主机：

该程序可实现原生 CobaltStrike Beacon 的部分关键指令：

CMD_SHELL: 执行 Shell 命令；
CMD_UPLOAD: 上传文件；
CMD_CD: 切换目录；
CMD_PWD: 当前目录；
CMD_SLEEP: 设置睡眠延迟时间；
CMDDOWNLOAD: 下载指定文件；
CMD_FILE_BROWSE: 文件浏览器；
CMD_EXIT: 退出。

而不同的是，Blackrota 编译前，会对 geacon 源码及 geacon 用到的第三方 Package 里面的变量名、函数名甚至源码文件路径字符串进行了混淆处理。导致研究人员在逆向分析的过程中无法直观看到该后门程序导入了哪些第三方 Package，进而无法直接恢复出关键的函数符号和其中有意义的 Type Names。

此外，Blackrota 的作者还将程序中所有的字符串进行编码处理，其中每一个字符串都用了一个 XOR 编码的函数来进行编码，程序执行的时候将其动态解码后再调用。从而导致研究团队的逆向工程师无法直接看到程序中使用的字符串，目前现有的针对 Go 语言二进制文件逆向分析的辅助脚本和插件更加无法解析这些字符串，给相关安全团队进行逆向分析带来很大的阻力。

在国内相关安全团队研究的历史上， Go 编写的恶意软件最多是在编译时做 Strip 处理，极少数会有轻微的混淆处理，都不会对相关安全团队的逆向分析带来多大困难。而 Blackrota 则带来了全新的混淆方式，这是相关团队迄今为止发现的混淆程度最高的 Go 编写的 ELF 格式恶意软件。

分析

Blackrota 的传播

该程序的作者有多个针对未授权 Docker Remote API 利用的 Payload，其中典型的 Payload 关键部分详见下图：

利用成功的 Payload 会从以下两个 URL 下载 32bit 或者 64bit Blackrota 后门程序：

Blackrota 后门程序概况

如上所述，Blackrota 的后门程序是由 Go 语言编写的，在 IDAPro 中使用 go_parser 解析后，可发现该程序由 Go1.15.3 编译而来，编译该项目的主机中，GOROOT 的路径是 "/usr/local/Cellar/go/1.15.3/libexec" 。还可以分析出这个项目涉及的源码文件路列表(源码文件的目录以随机字符串命名)，详见下图：

Blackrota 的函数符号

从 go_parser 的解析结果来看，Blackrota 样本中导入的第三方库源码中的数据类型名(Type Names)、函数名(Function Names)以及部分类型绑定的方法名(Method names)被混淆成了无意义的随机字符，给逆向分析工作带来了最大的阻力。解析后的部分函数列表详见下图：

被混淆的数据类型定义，详见下图：

此外，还有部分绑定在数据类型上的方法名没有被完全混淆：

该Go 语言二进制文件构建时，为全静态链接构建二进制文件。会把第三方库和标准库中用到的所有代都打包进二进制文件中，从而导致二进制文件体积变得很大。从逆向分析角度来看这种特性，就是在反汇编工具中打开 Go 二进制文件就将看到少则几千，多则上万个的函数。若这些函数无相应的符号信息，那针对 Go 二进制文件的逆向分析工作就会变得举步维艰。

不过 Go 语言本身还有另外一个机制：在构建二进制文件时，还会把运行时类型信息(RTTI, Runtime Type Information)和运行时符号信息(RTSI, Runtime Symbol Information)都打包进二进制文件中，且无法被 Strip 掉。目前业界大部分针对 Go 二进制文件的逆向辅助脚本或插件，以 go_parser 为例，都是利用解析 Go 二进制文件中这些类型信息和符号信息以恢复大量的符号和类型定义，从而辅助逆向分析工作。Go 语言项目经常导入大量的第三方开源 Package，通过研究分析这类工具解析出来的符号信息，就能够找到对应的开源 Package，阅读第三方 Package 的源码，则能让逆向分析效率更进一步。

而 Blackrota 中混淆符号信息和类型信息的手法，恰好击中这类逆向辅助工具的弱点。令它们解析、恢复出来的符号信息变得没有可读性，失去意义，更无法获知项目中用了哪些第三方库。使得逆向分析变得阻碍重重。

经过国内有关安全团队研究分析发现，Blackrota 的样本是以 geacon 改写的。所以我们就可以尝试通过以下步骤来恢复 Blackrota 样本中的函数符号：

1、编译一个与 Blackrota 样本相同 CPU 架构的 geacon ，不做 striped 处理，保留符号信息；

2、在IDAPro中用idb2pat.py来提取 geacon 中函数的 Pattern(geacon.pat)；

3、用 Flair Tools 中的 sigmake 工具来制作 geacon 的 Flirt Signature 文件(geacon.sig)；

4、在 IDAPro 中向 Blackrota 的样本导入 geacon.sig，识别并恢复函数符号。

但是我们发现 Blackrota 的函数符号没有被完全识别，还有近百个函数没被 geacon 的符号所覆盖，部分被识别的函数详见下图：

Blackrota 中的字符串

实际上， go_parser 本来是可以解析到 Go 二进制文件中的字符串的，它还可为解析好的字符串创建 Data Reference 到字符串引用的地方中，这样在逆向二进制文件时，什么代码处引用什么字符串就会一清二楚。可是我们上面用 go_parser 来解析 Blackrota 时，只看到了极个别的 Go 标准库里用到的函数被解析，而 geacon 内部的字符串则没有被解析。

那么问题就出在没有被 geacon 的符号覆盖的函数上。

通过研究分析，发现该程序对其内部所用的所有字符串进行了 XOR 编码处理，并且在运行的时候动态解码字符串后再引用。每个字符串都有对应的 XOR 解码函数，此函数解出字符并返回，然后解出的字符串将会在父函数中被引用。

其中的一个 XOR 解码函数关键部分详见下图：

总结

以Go 语言编写的被混淆过的程序相对稀少，除个别白帽子简单的尝试，以前业内也曝光过一个只混淆 package main 中函数符号的勒索病毒：

该勒索病毒只是简单混淆了 main package 中几个函数的名字，几乎没有给逆向分析带来阻力：

而 Blackrota 的混淆方式，则为逆向分析工作带来了全新的挑战。随着 Go 语言的流行，未来 Go 语言编写的恶意软件只会越来越多，而针对性的对抗也会频频出现。Blackrota 的出现或许只是一个开始。

IoCs

MD5

e56e4a586601a1130814060cb4bf449b

6e020db51665614f4a2fd84fb0f83778

9ca7acc98c17c6b67efdedb51560e1fa

C&C

blackrato.ga

参考链接

https://github.com/0xjiayu/go_parser

https://github.com/fireeye/flare-ida/blob/master/python/flare/idb2pat.py

https://github.com/darkr4y/geacon

https://twitter.com/joakimkennedy/status/1298554039240732672

往期精选

【风险通告】Cisco发布多个严重漏洞

【漏洞通告】Apache Unomi 远程代码执行漏洞(CVE -2020-13942 )

【漏洞通告】Drupal 远程代码执行漏洞(CVE-2020-13671)