长亭百川云 - 文章详情

对学校服务器挖矿木马的一次逆向分析

看雪学苑

67

2024-07-15

前不久,学弟突然找上了我,说学校分配的服务器被人种了挖矿木马,心中一听顿时一惊。内网一台服务器的沦陷的话,可能其它服务器也遭黑手了(可惜我不是应急响应大神,加上学校对网安这块不太重视,我也没资格上人家的服务器看一看情况,只能让学弟把软件发给我。)

一共有两个文件,其中名字分别为:

其中会定期执行-bash文件:

但是由于学弟那边排查占用率最高的是python2.8文件,所以先用ida打开,查找字符串发现:

好家伙,xmrig,于是校验一波hash。

可以发现就是xmrig6.21.3 版本,于是我问了问被入侵的时间,结果是6月9号左右,那个时候xmrig还没更新6.21.3版本,好家伙,到被发现快有1个月了,既然确定了python2.8的真身,接下来就要开始分析-bash文件了。

可以看到被upx压缩了,于是打算upx -d脱壳,结果:

网上搜了搜,大多都是在说修改了upx特征,如果不看upx源码找到被修改的特征就只能找到oep之后dump下来,想了想后者比较快,于是先试了试后者,

脱壳操作参考了Linux逆向之加壳&脱壳 - 先知社区 (https://xz.aliyun.com/t/6881?time\_\_1311=n4%2BxnD0DRDyBeAK4GNnm0WY4D50QKQDgeRYD&alichlgref=https%3A%2F%2Fcn.bing.com%2F)。

然而ida打开搜索字符串发现了go语言特有的字符串:

这样的话oep dump会丢失很多信息,而且调试符号本身也被去除了。

在尝试了go_parser和IDAGolangHelper工具恢复符号失败后,不得已开始研究pclntab和moduledata,这里参考了安全客一位师傅写的文章(https://www.anquanke.com/post/id/215419#h2-4),在其中发现gopclntab
 Section 就对应于 pclntab 结构,由于-bash软件没有开pie,所以gopclntab不会被删除,这下必须研究upx源码并尝试恢复特征进行工具脱壳了。

源码的研究参考了[原创]UPX 4.0.2 源码分析(https://bbs.kanxue.com/thread-278288.htm)

简单说一下研究过程,首先全局搜索哪个函数爆出错误信息"NotPackedException: not packed by UPX"。

定位throwNotPacked函数。

可以发现visitAllPackers是关键函数,继续定位,这里给出部分代码,但可以确定核心是func(pb.get(),user),结合刚刚传递的参数,确定核心为try_can_unpack。

跟进

核心是pb->canUpack,这下要跟进类方法了,不过很容易就确定是:

里面的printf都是我后来加的,是为了确定哪个条件出了问题。

虽然不知道为何会多次调用,不过看样子感觉是为了尝试不同平台,这里主要解决父类canUnpack的问题,因为第一次调用e_machine是对的上的。

核心在于find_overlay_offset,跟进

由于find_overlay_offset并未抛出下面两种异常,所以问题只能在第一次条件判断,经过调试后得知是getPackHeader的问题,由于其篇幅过长,只给出核心地方,可以看见在解码时爆出错误,继续跟进。

还是给出核心地方。

这下问题一目了然,在解码时,没有找到UPX的magic字段,而根据前面的代码得知upx是从文件倒过来开始解码的,所以16进制打开文件看一看。

原来文件末尾硬编码一段数据upx也脱不了壳,网上那些各种改特征虽然很牛,但第一次觉得没有这个快捷方便。

虽然编码看起来像base64,但解出来不太行。

/var/tmp/.x就是之前学弟找到的位置,不过前后的信息就有点迷惑了

先将尾部全置0,这样upx就能脱壳了。

脱壳之后再打开ida。

这下就能快速定位gopclntab,然而这份样本上来就给我上了一课。

magic字段为16B867D6h,我在网上看了很多go样本混淆的,但magic字段都是FF开头,从来没见过这种。这下我也就知道了为什么go_parser和IDAGolangHelper不行了,因为这两个工具找magic的前提是0xFF开头的

go_parser。

IDAGolangHelper:

这下只能手动写脚本恢复符号了,这里参考了[原创]2021 CISCN gift题解(恢复符号+逆向算法)(https://bbs.kanxue.com/thread-267813.htm)

没想到2021CISCN就有过这种题了。

修改后的脚本:

from ida\_bytes import del\_items, DELIT\_SIMPLE  
from ida\_funcs import add\_func  
from ida\_name import set\_name, SN\_NOCHECK  
from idc import get\_strlit\_contents  
import idaapi  
  
moduledata = 0x642240  
func\_table = idaapi.get\_qword(moduledata + 0x80)  
func\_table\_size = idaapi.get\_qword(moduledata + 0x88)  
string\_table = idaapi.get\_qword(moduledata + 0x8)  
  
start\_addr = func\_table  
end\_addr = start\_addr + func\_table\_size \* 8  
  
i = 0  
  
while start\_addr < end\_addr:  
    func\_entry = idaapi.get\_dword(start\_addr) + 0x401000  
    start\_addr += 4  
    func\_struct = func\_table + idaapi.get\_dword(start\_addr)  
    string\_addr = string\_table + idaapi.get\_dword(func\_struct + 4)  
    string\_name = get\_strlit\_contents(string\_addr).decode('utf-8') if get\_strlit\_contents(string\_addr) else "unknown\_"+str(i)  
    print('Renaming ' + hex(func\_entry) + ' to ' + string\_name)  
    del\_items(func\_entry, DELIT\_SIMPLE, 1)  
    add\_func(func\_entry)  
    set\_name(func\_entry, string\_name, SN\_NOCHECK)  
    start\_addr += 4  
    i += 1

这里说以下为什么不用func_struct里第一个字段entry,这里我计算两个func_struct地址。

func_table = 0x6026A0

第一个func_struct为0x6026A0 + 0x56B0 = 0x607D50

我们要的前两个数据都是没问题的,第一个是相对于基址的偏移,第二个是相对于字符串table的偏移。

然后再看第二个func_struct为0x6026A0 + 0x5708 = 0x607DA8

这个func_struct第一个字段就完全对不上了,如果有知道原因的大佬还请指出

脚本执行恢复符号后。

可以看到很多都是混淆的。

在逆到这后突然就没多少力气继续逆下去了,本人在go语言方面并没有多少经验,要继续下去得花很大的时间才能搞懂究竟做了哪些事情,路漫漫其修远兮,吾将上下而求索。

看雪ID:Ghost_196615

https://bbs.kanxue.com/user-home-835864.htm

*本文为看雪论坛优秀文章,由 Ghost_196615 原创,转载请注明来自看雪社区



# 往期推荐

1、Alt-Tab Terminator注册算法逆向

2、恶意木马历险记

3、VMP源码分析:反调试与绕过方法

4、Chrome V8 issue 1486342浅析

5、Cython逆向-语言特性分析

球分享

球点赞

球在看

点击阅读原文查看更多

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备2024055124号-2