内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

初出茅庐逆向狗:恶意程序分析第1课

2018-11-06 20:05 出处:清屏网 人气: 评论(0

不知道在座的各位逆向狗中,有多少人是从CTF开始的逆向之路,在我认识的逆向狗中,要么是从一些小小的破解入坑,要么就是通过CTF

而开始通过CTF入坑的童鞋们,在CTF逆向题做多了之后,都会想要找一个现实生活场景中的案例来试验一下学到的技术:比如恶意程序分析!

今天笔者就提供给大家一个自己遇到的样例:一只可爱的远程控制木马,供各位练练手。

程序不是很出名,“市面上”应该也找不到,大体来源就是有一位给人开发票的大叔想套客户信息,做了个伪装成发票样板的远控马…blabla……分析难度不是很大,但也挺费力气,拿来作为人生第一个分析的恶意程序难度刚刚好~整个分析过程有章可循,对思维启发还是很好的

程序下载链接: 木马在这里吃草~

Warning:木马真实有效,功能为远程控制,但已确定无其他对计算机的破坏性行为,请自行丢虚拟机调试!!!若不慎运行可立即断开网络并检查开机启动项,即可解除危险

一、文件概览

顶级文件夹内就是这些东西,除了exe外皆隐藏,exe图标进行了伪造,打开文件夹1,里面是一个无害txt发票样板

二、文件类型初步窥探

notepad++看一下bin文件和db文件,分别如下:

bin文件是什么文件暂时看不出来,但是db比较有意思,是一串base64编码,我们尝试解码一下:

有发现,竟然是对一个pe文件做了编码(脑洞选手可能已经想到这个可能是木马功能代码,但是我们出于训练逆向能力的目的,不要去解码来分析得到的文件,先一步一步走)

三、静态分析

就目前的情况来看,诱骗用户运行的应该就是那个exe,我们把它丢进IDA来分析一下:

这是WinMain的汇编开头部分,F5看它的伪代码:

可以看到,程序开始运行后,首先是打开了文件夹1中的txt,让用户看到所谓的发票模板,然后就开始搞事情了。

CreateFileA是创建了一个文件指针,指向了log.bin那个文件,返回的文件指针给了v4,v4就可以理解成代表这个文件的文件指针,对文件的操作都是通过v4来完成的。

GetFileSize,顾命思意,拿到文件的大小,值给了v5.

VirtualAlloc分配了一块内存空间,刚刚的v5作为参数表示分配的大小,0x40时该空间的属性为可执行,这意图就很明显了,想创建一块和log.bin一样大的内存,然后属性还是可执行,显然就是要把这个文件载入这块内存,而且内容还是可执行的代码!然后v6就指向了这儿

果然,下面马上ReadFile把文件读进来了,此时,v6就指向了这么一块可执行区域,内容即是log.bin

倒数第二行讲v6当作函数指针使用,也就使得程序跳到了那块内存去执行了

(函数具体的参数和说明请自行百度!)

可见,exe只是个启动器,它只是加载了log.bin中的代码,更阴暗的东西在log.bin里头

四、动态分析

log.bin并不是一个完整的程序,因此IDA已经无能为力了

想要知道log.bin的代码载入内存后究竟做了什么,只能依靠动态调试的力量,我们祭出神器:x64dbg(这个例子中实际是32位的)

调试器打开exe后,先运行一下,让程序运行到Entrypoint:

接下来我们需要找到刚刚静态分析时载入bin文件的地方,结合IDA静态分析的结果,该位置用到了一些字符串,如”1\1.txt” “log.bin”等等,我们使用调试器的搜索字符串功能来辅助定位。

右键功能里面有:

很快有了结果:

我们在第一条结果右键转到汇编代码,就可以转到对应的汇编代码的位置如下:

对比之前IDA的反汇编,可以确认就是这儿了,此外,可以发现,指令的地址和IDA中是不一样的,应该是开启了随机化,只有低位的地址是和原来一样

下一步我们往下找,找到IDA中调用函数指针v6的地方,因为就是从那儿跳转到log.bin的代码:

很容易就找到了,readfile调用之后,call eax就是对之前v6函数指针的调用,具体讲的话,就是前面VirtualAlloc返回值eax(函数指针)先压在了栈中,然后通过mov又给回了eax

我们在这儿下上了一个断点,运行到这儿以后再单步运行一下,就可以进入到log.bin的地盘了。

我们运行到断点,然后步进到log.bin的区域:

先是如之前分析那样,到断点时打开了txt

然后步进:

这就是log.bin的代码区域了,之前被加载进来的文件就是这些!

大体扫一眼,不知道各位是否已经看出了端倪?是不是某个地方有点似曾相识呢?

没错!我们看到了从0x3510064开始进行了一系列的push,而push的3、1、80000000和之前IDA中看到的某个函数调用惊人的相似!

而这个函数,回头去看,正是CreateFileA!

还要CreateFile?!这次又要关联哪个文件呢?稍加分析思考,无非两种可能:

1、上面的一大堆call调用的函数创建了一些文件,然后在此处关联上它

2、并没有创建新的文件,那这个文件十有八九就是前面文件夹里的log.db了

显然,下面call esi应该就是调用CreateFileA,我们在那儿下断点,过去就知道是打开哪个文件了:

不出所料,就是log.db,看来这回是要加载log.db了,那么大概大家也可以猜到这个程序的“好意”了:很有可能就是把db文件读进来,base64解码它,然后执行!

接着往下看汇编,果不出我们所料:

正如上图,接下来的三个call依次调用了GetFileSize、VirtualAlloc、ReadFile,与之前的操作如出一辙!

但是再仔细看一下就会发现,VirtualAlloc传参时,压进的第一个参数4,这个参数之前说过是内存属性,为4时是不可执行的!

这就很奇怪,log.db不是要执行的吗?为啥是不可执行的?是因为这里读进来的是base64编码,当然不可执行,这也提示我们,后面肯定要做解码,然后肯定会去执行它!

我们可以猜到,很可能程序是这样一个思路:exe加载执行bin  ->  bin再加载、解码、执行db  ->  恶意功能实现在db中,整个就是一套跳板

当然只是猜测,我们顺着这个思路来尝试一下:

思路1、既然是先解码再调用,那会不会这两步是连在一起的,也就是说找到了解码函数就离调用不远了呢?

思路2、解码后,要把解码得到的可执行代码放到一块内存,这块内存还要设置成可执行的属性才行,这样的话是否可以利用VirtualAlloc压栈0x40来定位呢?找一下push 0x40就行

还真别说,稍稍往下一看,隔了没几行代码,还真找着了:

看到了push 40,后面push的值也和之前类似,可以断定最下面那个call就是VirtualAlloc,设置了一块可执行内存,那么上面那俩神秘函数有可能是base64解码也说不定。

我们把这三个call都下断点,去跑一下:

1:我们先进入第一个call,看了看有一些字母表数字表的字符串处理,所以应该是和base64有关,有可能是初始化对照表吧

2:完了以后就是第二个call,可以看到第二个call是有两个参数的,分别是ebx和esi压进去做了参数,此外还mov了一个edi,我们在第二个call下个断点,断到那儿以后回头看这仨寄存器的值:

esi和edi对应了两块内存,对应看:

可见esi是一个未经写入的新内存区域,而edi指向的是之前db文件载入的base64编码

我们往上回溯看一下两个寄存器的来源,就可以看出:在call 0x3510143和读db的call ReadFile之间,还有一个VirtualAlloc的调用,它返回的内存指针eax,mov给了现在的esi;而之前用来存db内容的VirtualAlloc得到的返回指针也是由eax,mov给了现在的edi

而作为参数之一的ebx寄存器,细心往上回溯也可以找到来源:是GetFileSize的返回至mov给它的(夹在中间那个VirtualAlloc也用的它的大小)

也就是说,在进入第二个call之前:传的两个参数是 db文件的大小对应着这个大小的空内存区域 ,并且还把db文件base64编码内容的内存指针拷贝给了edx

结合这一层分析,我们开动脑洞来猜一下第二个call要干嘛,如果说edx也是个函数接口的化,那么可以认为这个函数有三个参数:大小、空内存、base64编码内存

便越想越容易怀疑到:这个函数要进行base64解码,大小作为参数可能是为了进行循环、空内存是目标写入区域、ebx就是编码原文!

跟进去看看,会有一堆字母数字字符表操作、一个大大的循环、中间某步还看到了MZ哈哈,怎么看怎么像

我们跟进去,直接找到ret附件下断点来验证我们的猜想:

断到ret,看esi对应的那块内存:

之前参数传入的那块空内存已经被写进了base64解码得到的可执行二进制内容!猜想正确!

第一个call经验证的确也是base64编码初始化,完美!

3:之后就是用VirtualAlloc拿到了一块可执行的内存空间,并通过mov将返回的内存指针从eax交给了ebx

到这儿为止,关于db文件base64解码的操作过程就分析出来了

我们已经拿到了可执行内存空间,但是里面还没有把db解码得到的可执行内容拷贝过去,于是我们接着往下找,VirtualAlloc拿了可执行内存后紧接着的是call了三个神秘函数:

我们直接步过第一个call,然后去看那块可执行的空内存(ebx),里面已经有东西了:

说明第一个call就是我们要的拷贝函数了!

后面俩call忘记是做什么的了,反正不重要,我们略过

一直往后分析就不是很难了,后面ebx一直没有再被写过,也就是说ebx始终还是指向可执行内存的,然后做了一些玄妙的偏移计算:

反正这块偏移运算作用就是:可执行内存开头是pe文件头,并不是从开头就可执行的,因此这段就是通过偏移计算得到可执行内存中这只pe程序入口点!(应该能猜得到吧)

然后就是:

call eax,跳到db解码出来的pe的入口点去执行!!!

至此,我们终于把整个db文件的载入过程分析清楚并且成功的找到了db那块可执行代码的跳转点!

到这儿已经很累了,希望写这个木马的人有点良心,从这儿开始能正式进入木马关键代码┭┮﹏┭┮

call eax下断点后,步进去,就可以看到db对应可执行代码的空间了:

这里面的代码挺多的,我们祭出“所有call统统下断点大法”,挨个call下断!

注意:下断不要顾前不顾后!!万一你只下前面call的断点不检查中间有没有向后jmp,有可能人家直接jmp走了,你程序就丢失跟踪了!!!!这个很坑!!!!而且还有!!!还有!!!!!ret处也要下断点!!!!!不然直接jmp到ret呢!!!

咱们把所有函数调用都下上断点并且ret也断上以后,每断到一个函数我们就步进看看,第一次停到一个函数,进去看了,没啥,但是当第二次断到call时,跟进去,很惊喜:

这个WSAFDIsSet是和winsocket有关的东西,说明已经开始涉及网络链接功能了,看来db文件就是木马核心功能所在了

但是在执行这个jmp之前就已经ret了,我们ret出去以后再运行,结果就直接到了ret了,看来刚刚下了那么多断点,结果最后一共就执行了两个函数,而且都没什么敏感东西,猜测可能是做了一些简单的初始化吧,看来最重要的东西并不在这个call eax里面,我们ret出来以后继续往下看:

开始我们是进的上面那个call eax,也是从上面那里出来的,但是出来后我们看到,下面还有一个call eax调用,我们把它下上断点,跑过去,看一下eax对应的内存,是db解码出的pe的另一个偏移位置,我们步进这个call eax:

里面是这样的。

往下翻翻,这才是正确的画风(*^_^*)~~

好了,好戏要到了

往下是一大堆系统调用,中间还有个神奇的ShellExecute,竟然是个奇怪的1.jpg,也不知道是什么东西,反正逆了半天不知道干啥的,结合上下文是弄图标?还是留给大家来分析吧

但是这些系统调用看了看都和网络链接没有任何关系,但是我们的木马必须要连服务器啊,我们带着这个目的往下找:

首先略过所有与网络无关的系统调用

然后就到了靠近结尾那部分了,老规矩,call全下断点,一个个看,因为这段跳转太多

结果直接就跳到图中最后一个call了,中间的call都没执行

再往后看出来一个sleep就是ret了,已经没东西了

所以可以肯定关键部分就在图中最后这个call里面

而且另外一个细节值得我们警觉:

最后这个call,竟然是个持续的循环,下一行的jmp又跳到了这个call,反复执行!这就很“木马”了!!!都懂不多说

步进这个call:

一眼就看到,右侧有串base64,我们解码一下发现是乱码:

好,我们又开始瞎猜了:这么短的一串乱码,肯定不是指令,那它是乱码又不是指令还能是什么呢?会不会是加密的一条数据!比如服务器url?要把自身拷贝到的路径?注册表项?……

不管它是啥,我们一定要解出来

可以看到,这串base64字符串是作为一个参数传给了24fb330这个函数,应该是base64解码函数

直接步过它看返回值,结果令人哭笑不得:

搞半天base64解码和解码后的解密都在这里面了,没办法,我好奇怎么解密的,就重新加载了程序看(因此地址变了,大家看了不要奇怪):

进了这个函数是这样子的:

经分析,里面第一个call是base64解码函数,下面选中的那段循环则是对base64解码所得字符串的解密过程,反编译一下:

凯撒加异或,很简单的加密过程

这两步以后解码得到一个ip地址,可见原来那个base64串是一个对应了一个ip,很可能就是服务器ip

往后看,到这儿对应了两条base64串,第一个和之前一样,第二个我们同理解码出来,是一个端口号:

此后肯定就在某一步以这对ip地址和端口号为参数建立socket链接了,没什么悬念,就不分析具体的链接过程,我们接着往下看,可以看到几个神秘的非系统调用函数:

出于好奇,我都下了断点,打算一个一个看看:

第一个call进去以后就是进行socket链接如上,没啥好说的

只是这儿很坑,因为如果服务器没开它就会一直搁在这里面等,给你造成一种调试器对程序失去控制了或者崩溃了的假象,其实过一会儿链接不上它就自己步过了,等一会儿(很久)就好

真正令人窒息的是,如果网络链接不上的话,这个负责链接的call执行完后,jne不会执行,因此就会执行到后面的jmp,就往回跳了,进入了一个无限的循环,直到链接成功,才jne跳出去继续往下执行(如下图)。。。因此如果调试的时候服务器没开,唯一的办法就是把jne改成无条件跳转。。

改了以后就可以跳出去了,断在了下一个有断点的call,跟进去,是一些和网络链接有关的东西,以及获取了中招机器的系统信息,免杀模块也再这里面(附在第二张图) :

免杀模块就是下图选中的那条(下图中那个call GetSystemInfo和上面那张图中的是同一个,由于这是两次调试的图片,所以地址被随机化了,就不太一样,但其实是同一处的代码):

跟进这个免杀模块可以看到具体的东西:

可以得出结论:建立socket链接完毕后,我们后面的第一个call(也就是我们强行修改为无条件跳转跳出来后遇到的第一个调用),完成了受害机器本地信息获取以及免杀两项工作,我们可以将这个call看作木马的“本地运行环境侦测与处置”模块。

之后的call就没啥意思了,我们直接走到下面这个函数调用:

断到这儿后,调着调着就会发现,这个是循环执行的!也就是说你断到这儿后运行,eip又回到这,看起来就跟没运行一样;如果你把断点删去,运行,它就会一直处于运行状态;处于运行状态的时候你突然下上断点,它就会立即停到这儿

综合以上,说明最终木马的最核心实现就在这儿了,它在这个函数里面,会保持和服务器已经建立的链接,持续监听(wait)服务器的具体指令,根据对面的具体指令,去执行具体的功能函数代码!

我们这时候再打开字符串搜索,搜个”Ten”看看出来啥:

读者请自己跟到汇编处去看那部分都是干嘛的,反正很邪恶哦~(据说看到了steam)

五、分析报告与总结

1、该远控木马的大体执行过程如下:

通过将exe图标变换伪装成txt欺骗用户运行,运行后由exe打开“发票”txt使用户看到所需内容,然后将log.bin载入内存并执行

log.bin的代码将载入log.db,并对其进行base64解码得到可执行代码,并执行得到的代码

log.db解码得到的代码执行过程中,首先对服务器ip和端口号进行base64解码,得到密文,并解密得到真实的ip和port,建立socket链接

之后进行本地运行环境侦测与处置,获取受害机器信息并进行对自身进行免杀保护

最后开启对服务器的命令监听模式,根据接收到的命令执行相应的远程控制操作

2、db文件其实可以手动解码,丢ida分析的,我们为了练习能力没有这样做,回头读者可以自己尝试

静态动态调试相结合是分析恶意代码的重要方法哦~


分享给小伙伴们:
本文标签: 恶意程序

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.

清屏网 版权所有 豫ICP备15026204号