又一种后门病毒针对Linux系统，火绒可拦截

火绒工程师

近期，火绒威胁情报系统监测到一种针对Linux系统的后门型病毒，经排查分析后，确定其与HelloBot家族有关。HelloBot是一个针对Linux系统的恶意软件家族，执行远程控制受害者计算机等恶意活动，因其配置测试中输出“hello world”而得名。

该病毒自2019年被披露后，被多个犯罪团伙和APT组织使用，对用户构成较大的威胁。目前，火绒安全产品可对上述病毒进行拦截查杀，请企业用户及时更新病毒库以进行防御。

病毒查杀图

该病毒被激活后，会释放“worker”文件并为其进行配置，后者在受害者电脑上执行关键操作。不同的配置会导致不同的恶意行为，包括进程伪装、备份文件、防火墙设置和远程控制等。该病毒执行流程，如下图所示：

病毒执行流程图

一、样本分析

该类病毒是一个由配置主导的成熟复杂的后门程序，不同的配置有不同的执行结果，这里仅以当前样本配置的执行过程进行阐述：

配置查看

在观察中发现样本有四个启动参数： --builder、--test、--shell、--dump。

--builder 需要传入指定的配置和要更新的样本文件名 filename，用于重新构建服务。
--test 只是简单地测试样本执行输出。

--shell 开启一个 shell 进行连接，需要输入密码进行 md5 校验，md5 解出来的值为 "tk_shell"。

--dump 后接要导出配置的样本名，用于显示当前样本的配置信息

参数设置

前期操作：通用执行部分

由于样本执行阶段主要分为“释放器”和“工作者”两个部分，两者执行流程因配置修改而异，但在根据配置进行“分流”之前，有着共同的初始化部分，梳理如下：

1：重置 shell 相关历史记录。

历史清除

2：校验输入参数，并进行相应处理。如果没有输入参数，就进行后续处理。

校验参数

3：从自身获取配置

提取配置

4：忽略所有信号并重新注册 SIGCHLD 信号。（重置 mgr_pid 和 monitor_pid 为 -1）

注册信号

5：根据配置将自身进程替换成虚假进程名。

进程替换

释放器分析：

启动程序运行前会先查看一下系统环境，主要检查 /tmp 目录是否存在，tmp_start_dir 配置对应的 /var/tmp 是否存在等，为后续副本投放执行作铺垫：（auto_start 也会先设置为 0）

路径查看

样本会遍历运行中的进程获取要伪装的文件（这里只开启了 firefox），然后将重命名的副本释放到 /var/tmp/ （tmp_start_dir）目录下并设置好对应的执行权限：

进程路径获取

系统函数调用图

随后释放器会设置 is_worker 为 1 用于更新副本 firefox 的配置，is_worker 标志表示该样本将要用于正式执行阶段：

配置更新

最后，释放器通过 fork 分支执行 "/bin/sh -c /var/tmp/firefox" 并将其设置成后台进程。释放器结束任务，剩下操作移交到 firefox 代表的 worker 中：

开启 "worker"

工作者执行：

由于该样本属于后门程序的设定，所以后续操作围绕着“上线”展开。且由于 is_worker 值的设置，该样本在执行时跳过了前面释放器提到的流程。

工作者先是删除文件自身，以内存加载的方式执行：

删除自身

进程图展示

配置中 lock_file 对应的文件起一个类似“互斥体”的作用，通过判断该文件占用情况来确定 worker 是否重复执行：

“互斥体”设置

fork 的进程：

样本后续通过 fork 分支了多个子进程，子进程之间互相关联且涉及到配置中的 mgr_pid 和 monitor_pid 进程，梳理如下：

流程图

子进程1：监控全局

最先分支出来的子进程 1 被设立成脱离终端的独立进程，用于后台运行：

后台执行

接着 fork 出子进程 2，并设其为 mgr_pid 值，用于管理“上线”的操作。并接着在 start_monitor_child 函数中开启子进程 3，用于执行监控操作。在开启子进程 2、3 之后，子进程 1 进入到监听消息的循环当中，通过指定的消息执行不同的操作。

监听消息

监听的特定消息应由“上线”后以发出，包括 restart、update、uninstall 3 种管理方式。其中这三种操作的对象都指向进程 3 在 install_path 和 install_path_bak 中存放的最新配置的“启动器”：

管理分支进程

子进程3：配置更新

在 start_monitor_child 中开启的子进程 3 负责监控操作，其获取配置中的 mon_interval （10 秒）值作为监控周期，循环执行：

循环检测

对于配置中设置了的 "cmd%d" 命令，则会在该进程中遍历执行：

命令执行

该进程最关键的还是对于配置的更新，根据配置中的 install_path 和 install_path_bak 值，把自身复制到对应的目录下并设置 is_worker 为空（相当于启动器），目的是在“上线”后根据交互时刻更新命令配置。

配置更新

子进程2：维持通信

子进程 2 负责“上线”操作，在通信之前会校验防火墙配置，如果设置了值，则执行 "iptables -F" 清除防火墙规则：

防火墙设置

随后在循环中遍历配置中的 host%d，获取 C2 域名进行连接：（拽写本文时，C2 已失效）

C2 连接

在连接前，获取 DNS 解析的 IP 地址进行连接，构造特定的报文发送来获取特定的返回数据：

报文构造

流量查看

连接成功后根据配置中的 protocol 来选择要使用的通信协议进行管理：

协议选择

关于 SIGCHLD 信号：

在前期对信号的处理操作中注册的 SIGCHLD 信号处理函数是对“工作者”的进程 2、3 进行处理的。因为当第一个子进程终结后，SIGCHLD 的处理函数还要等待第二个子进程终结才能进入条件。在该条件句中，执行的操作是重置 mgr_pid 和 monitor_pid 的值。

SIGCHLD 信号

关于壳与配置：

样本是用常规 upx 壳压缩的，并没有什么修改。但是对于配置部分，程序采取的是将加密后的配置附加在文件末尾，这就导致了自动脱壳失败：

配置写入

相关字节码

二、附录：

HASH：

C&C