zoukankan      html  css  js  c++  java
  • 病毒木马查杀实战第026篇:“白加黑”恶意程序研究(上)

    前言

           众所周知,传统的恶意程序都是由单一文件构成的。从而实现某一种或者几种恶意功能。

    而这类的恶意程序为了避免被发现以及被查杀,往往会採用五花八门的自我隐藏技术以及免杀技术,病毒程序的作者非常多时候也是脑洞大开。为了对抗杀软的查杀也是无所不用其极。

    我们每天所处理的恶意文件中面。反查杀手段运用得最好的就是脚本木马,关于这类程序。我在之前的《病毒木马查杀实战第025篇:JS下载者脚本木马的分析与防御》这篇博文中也做过简单的论述。可是,不论恶意程序怎样进化。杀软厂商总有各种各样的方法来应对现有的以及未知的威胁,因此,恶意程序的作者就势必要採用更加隐蔽的方式来保护自己,免于被查杀。

    或许正是由于这个原因,“白加黑”恶意程序就应运而生了。

     

    “白加黑”恶意程序概述

           所谓的“白加黑”恶意程序。最为显著的特征是由之前的单独作案,发展为团伙“犯罪”。

    也就是为了实现恶意的目的,往往会由多个程序协作完毕。

    而这些程序假设单独拿一个出来,似乎并没有什么恶意的行为,可是仅仅要把这些文件放在一起,运行当中的某一个文件,那么就会诱发一系列的连锁反应,从而令计算机被感染。

           在这种一个“团伙”里面。一般来说至少会拥有一个.dll文件。

    这个.dll文件自身不见得包括有恶意行为。或许仅仅是为了实现恶意行为链条当中的一环。

    由于.dll文件自身并不能直接运行,因此非常多朋友往往会对其放松警惕,所以从某种意义上来说,.dll文件天生就带有自我隐藏恶意行为的效果。而“白加黑”恶意程序(们)不可能单独放出来一个.dll文件。还须要包括有至少一个.exe程序(或脚本程序等)来激活.dll文件,也就是说这个“团伙”至少也得有两个成员构成才行。而这篇博文,主要讨论的就是这种最为简单的情况。

     

    是真的“酷狗”程序吗

           话说前段时间的某一天,我收到了由我们技术支持发来的一批样本。当中有两个程序引起了我的注意,这两个文件一个叫做KuGou.exe,另一个叫做kugou.dll。

    依照常理,我们一般都会对.exe这种能够直接运行的程序抱有非常大的戒心。并且又看到这个文件的名称是“KuGou”,那么给我的第一印象就是,要么这真的就是一个由“酷狗”官方出品的正常程序。要么就是某个恶意程序弄虚作假,混淆视听。让我们错误地以为它是真的“酷狗”。减少我们的戒心。让我们不假思索地去点击。

           “酷狗”毕竟是一款非常知名的程序,那么为了验证它到底是不是官方正品格货,最简单的方法能够使用由Sysinternals出品的sigcheck.exe来检測一下这个程序的数字签名:


           当中Verified后面的Signed表明该程序的数字签名有效。加上文件的各个信息也是填写得非常完整,那么基本就能够确定这个程序的真实性了。不放心的话能够进一步验证这个数字签名的真伪:


           数字签名信息都能够对得上。那么就能够把这个程序归类到“干净”目录中了。当然了,更为严谨的做法是须要对其进行逆向分析,确保百分百没问题之后才干够放到“干净”目录,关于这个我们后面再讨论。

           假设大家不相信“数字签名”的奇妙。我这里最好还是做一个实验。我利用二进制编辑器(这里我所使用的是Free Hex Editor Neo)将KuGou.exe的第4个字节(偏移为0x3)。由原来的00改为01:

           这里请大家注意的是,虽然我改动了这个文件,可是一般来说并不会影响这个程序的正常运行,由于PE结构的这个偏移位置并没有多大用处,至少不会对全局产生致命的影响。

    然后我们再用sigcheck.exe来检測一下:


           能够看到。如今的数字签名处于无效的状态。说明要么它被病毒感染了,要么它就是一个虚假的程序。

     

    进一步验证

           本着求真务实的工作态度,虽然.dll程序并不能直接运行,但既然是由客户发给我们分析的。我还是要认真看一看的。

    首先还是要利用sigcheck.exe来检測一下这个kugou.dll文件:


           可见,这个文件的信息能够说是一片空白。此时我心中是有疑问的。难道“酷狗”的.dll文件就是不带数字签名的吗?于是我到“酷狗”的官方站点下载了程序的安装包。安装后就得到了绝对官方正品的kugou.dll文件。查看一下它的数字签名信息:


           结果非常明显,即便是.dll文件,也是带有数字签名的。可是如今还不能草率下结论,毕竟我所下载的版本号较新(8.1.32.19628),而我收到的样本较旧(8.1.00.19303),有没有可能旧的版本号就是这种呢?好,那么最好还是再深入对照一下。

    既然是.dll文件,那就从二者的导出函数入手吧。首先看一下已经确认为官方正品的导出函数情况:


           能够看到。一共同拥有三个导出函数(不知道为啥第三个导出函数的编号是4呢?)。

    接下来再看一下那个可疑文件的导出函数:


           对照发现,可疑文件多出来了一个叫做“FlashboxMain”的函数,并且另一点非常奇怪的是,编号为1、2、3的这三个函数的地址居然全都是0x100011E0,也就是说这三个函数实际上调用的是同一处代码,正常的程序怎么可能会这么干呢?最好还是再看一下这个位置的代码:


           能够看到,它实现的功能就是eax异或自身。也就是自身清零,接下来就利用retn直接返回了。能够理解为这段代码并没有实现什么实用的功能。然后也就结束了。

    至此。我能够百分百确定说,这就是一个恶意程序。再总结一下我的理由:

           1、这个文件的名称是kugou.dll,虽然你起什么名字我是管不着的,可是既然你的名字与一家知名公司的知名软件相同。那我就必须要怀疑一下了。万一你是想欺骗无知大众呢?

           2、既然你认为你是“酷狗”的组件,可是为什么没有文件信息以及数字签名呢?

           3、对照真实的kugou.dll文件。你们导出函数的数量不一样也就算了(毕竟不是一个版本号),但为什么有三个导出函数的地址是一模一样的呢?并且查看反汇编代码发现。这三个函数事实上什么功能都没有实现。你还想说你是清白的?真正大公司的程序猿。谁会写这么无聊的代码啊?

           可见。我们分析恶意程序,非常多时候就是推断目标文件有哪些不正常的地方。或许出现一两个不正常的地方,我还能够理解为是程序猿的恶作剧,可是假设不正常的地方实在是太多。那么我就仅仅能理解为是黑客在搞鬼了。

           虽然我还没有分析这个恶意程序到底是想要实现什么功能,可是分析到眼下这一步事实上基本也就够用了。一般来说,这类程序属于后门或者远控木马。或者属于DLL劫持,给它分个类。起个名字,提个特征,添加病毒库。也就完毕了整个分析的流程。可能大家看我在这里啰哩吧嗦地讲了这么多认为时间非常漫长,但在我们的日常工作中,推断一个文件是不是干净的,仅仅几分钟就够用了。毕竟世界上每天都会出现非常多的恶意程序,那么分析的速度以及准确率的高低。就是我们每天能不能按时下班以及会不会收到非常多投诉的关键因素了。

     

    kugou.dll是怎么实现恶意功能的

           不知道大家想过没有,这个假的kugou.dll是怎么运行的呢?事实上在正常的软件开发中,程序猿们不可能把要实现的全部功能都写在一个.exe程序里面,这种话必定会让这个程序越来越大,同一时候也不利于功能的升级,所以将一些经常使用的功能写成.dll的形式,有须要的时候再进行调用就能够了。简单来说,在有须要的时候,KuGou.exe能够利用LoadLibrary()函数将kugou.dll载入到内存中。然后再利用GetProcAddress()函数调用kugou.dll中的导出函数就能够了。

    普通情况下,对于KuGou.exe这种程序来说。它一般不会去验证自己调用的.dll程序是不是真的由自己公司出品的.dll程序(我并没有做逆向分析,仅仅是感觉),仅仅会根据文件路径、文件名称称以及导出函数的名字来直接进行调用。毕竟程序开发人员不可能把全部方面都考虑到,可是在调用.dll文件之前,先进行验证,比方进行哈希运算再进行哈希值的对照,虽说大大添加了工作量,但却不失为一种安全的做法。但这么做到底有没有必要,还是须要好好讨论一下的。

           事实上根据我的理解,随着软件project开发方法的不断完好,软件的安全也越来越被开发人员所重视。

    推动安全开发方法学发展的。正是那些“孜孜不倦”地研究怎样黑掉那些软件,从而为自己牟利的黑客们,正是他们推动了整个开发理论的不断进步。

    当然了。像是.dll劫持这类的恶意利用方法。还是比較0基础的,如今流行的是五花八门的漏洞利用技术,令即便是资深软件开发project师也防不胜防。也是顶级黑客们的脑力竞赛。关于这个。以后有机会。我再好好讨论一下。

     

    再说说数字签名

           在上面的内容中。我推断一个程序是不是恶意程序的一个关键方法是查看它是否具有数字签名。可是这段时间以来,我还是遇到了非常多文件名称为dllhost.exe、svchost.exe以及explorer.exe这一类的程序。乍一看还不敢随便下推断,由于Windows中的非常多自有文件就是这个名字,假设再查看一下他们的签名信息。可能是这种:


           文件基本信息倒是非常全。可是只有最重要的数字签名反而没有。难道这是伪造的吗?事实上,假设从系统中把这个explorer.exe给找出来,那么相同会发现。微软官方系统中的文件也是没有数字签名的,有的仅仅是诸如上图那样的基本信息,这可就麻烦了,难道真的要反汇编一点一点地逆向分析可疑文件功能了?

           事实上也不用那么麻烦。毕竟我拥有各式各样的Windows系统。虚拟机和工作机中就有Windows XP以及两个版本号的Windows 7。再加上我笔记本中的Windows 10,那么就足以应付日常分析的须要了。毕竟黑客再牛。也不可能把文件哈希也做出来一模一样的吧?于是每次遇到这种情况,为了保险起见,我都会根据文件的版本号号,从相应的Windows系统中找到真正的文件出来,对照他们的哈希值,一下就能够知道真假了。不晓得这算不算是投机取巧呢?

           大部分情况下,黑客想“伪造”一个Windows文件,还是比較用心的。文件信息就如同上图那样,和真的一模一样。但我有些时候也会遇到一些做事不严谨的黑客,他们伪造的文件信息可能会是这样:


        当中最大的问题是Publisher后面多打了一个回车,使得公司名称到下一行了,那么非常明显。这就是一个恶意程序了。

    仅仅几秒钟。就完毕了文件黑白的推断。

     

    小结

           大家从我的这篇文章也能够看到数字签名的重要性。包括在写代码的时候,千万不要写得过于晦涩难懂,不要搞恶作剧。免得就被当作病毒给误杀了。当然了,“白加黑”恶意程序事实上远远没有这么简单,我这次讨论的仅仅是高速推断的方法,具体的分析我会在接下来的文章中为大家讨论一下。


         《从苏宁电器到卡巴斯基》终稿完整版,请訪问

           https://user.qzone.qq.com/3149487460/blog/1494822165


  • 相关阅读:
    Flex4 启动失败: 正在等待 Adobe Flash Player 连接调试器
    软件的黑盒和白盒分析方法
    PAIP.国内软件公司的现状及解决.txt
    软件逆向分析方法小结
    应用程序中主键ID生成与UUID
    JDK1.4下载 JRE1.4下载
    壳与软件保护
    数据恢复软件
    跨语言调用模块.TXT
    论文格式
  • 原文地址:https://www.cnblogs.com/lxjshuju/p/7338730.html
Copyright © 2011-2022 走看看