欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

揭开病毒的面纱:恶意代码自解密技术

来源:本站整理 作者:佚名 时间:2019-05-28 TAG: 我要投稿

分析病毒的时候,常常遇到一种很奇怪的现象,使用查壳工具查看一个样本明明没有加壳,但是反编译或调试时,却不能直观地看到样本的恶意操作,这是为什么呢?很简单,这是因为攻击者采用了自定义的加密方法,在样本运行时实现自解密并执行真正的恶意操作,所以看到的只是样本还没解密的样子,自然分析不出恶意代码的逻辑。
下面就通过实例来窥探下恶意代码自解密的技术吧,如下是一个Ammyy病毒的下载器(MD5:28EAE907EA38B050CBDCC82BB623C00A),使用DIE查壳发现,该样本并没有加任何的壳。

然而当查找字符串时,却未能发现一些可疑的字符串(如下载器常有的恶意url),看到的只是一堆乱码,看来,该样本很有可能就是使用了自解密的技术。

反编译该样本,也难以看出它的代码逻辑,很多动态地址的call。

对于这种样本,反编译器很难看到一些重要的操作,因为大部分都是解密操作,所以只能通过调试器单步调了。单步调试没啥好技巧,遇到跑飞的call下断点然后重新调试。调试的时候,要注意VirtualAlloc、GlobalAlloc、HeapCreate这些函数,因为恶意代码通常使用这些函数来申请一段内存空间,来存放解密出来的恶意代码。如下图,该样本调用的是HeapCreate创建了0×230000这段内存。

接着恶意代码用了je + retn的方式循环解密0×230000处的数据。

解密完毕后,恶意代码调用call esi将执行流从0x40XXXX转到0×230000。

然而,0×230000处的代码并不执行核心的恶意操作,目的在于修改0x40XXXX处的原始代码。如下,它会调用VirtualProtect将0×400000的内存属性改为RW(读写),进而修改原来的代码。

修改后的0×400000内存段的属性如下。

修改完代码,调用jmp esi跳回到0x40XXXX进行执行,此时,这段内存的代码已经被修改过了,终于开始执行核心的恶意操作了。

将内存dump下来发现,现在的代码已经是解密后的恶意代码了,程序逻辑清晰可见,通过字符串查找可以找到待下载的病毒的url。

至此,该下载器的功能已经分析完毕,主要功能为从http://thespecsupportservice.com/load.png下载Ammyy病毒并运行。

由此,可以总结得出,恶意代码自解密的步骤一般为以下5步:申请内存 -> 复制数据 -> 解密数据 -> 跳转到堆中执行恶意代码 -> 修改原始代码并跳回执行。不过,我们可能会有个疑惑,病毒为什么不直接在堆中执行核心的恶意操作呢,还要通过修改原始代码来在0×400000空间解密执行核心的恶意代码。这是因为,一些比较高级的沙箱、杀软会监控病毒创建大片内存空间的操作,这时一旦释放出解密代码,便会立刻被沙箱、杀软检测到,所以在堆中的代码一般不会只会直接进行核心的恶意操作。

了解了恶意代码自解密技术后,来看看最近流行的GandCrab勒索病毒(MD5:48A673157DA3940244CE0DFB3ECB58E9),使用的也是这种自解密技术,来实现免杀。使用DIE对样本进行检测,显示并未加壳。

自解密的手法跟上述提到的相似,在0×1280000处申请了一段内存空间。

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载