简介
为了绕过静态和动态分析,威胁组织经常为恶意程序采取"加壳"或"加密"措施,并且这种做法非常流行。实际上,免杀和查杀是一个军备竞赛,因此,在这场持久战中,各种新技术会不断涌现,并被迅速采用。例如,据我们观察,许多加密服务都是由地下论坛提供的,他们声称能够绕过反病毒技术、沙箱和其他端点解决方案,任何恶意软件只要采用了他们的服务,就能够实现“完全无法检测(Fully Undetectable,FUD)”的效果。我们还发现,越来越多的威胁组织正在设法模拟正常的用户行为,并将其作为基于恶意软件指纹分析技术的有效对策。
恶意软件的保护神:Delphi代码
在这里,我们所考察的样本具有Delphi签名(见图1),并且与使用IDR(Interactive Delphi Reconstructor)分析时看到的Delphi代码构造完全一致。
图1:样本中的Delphi签名
对于基于Windows API函数的应用程序和程序来说,Delphi是一种简单易用的编程语言。事实上,一些组织会故意将某些默认库包含进恶意软件中,以此转移静态分析人员的注意力,并能让应用程序在进行动态分析时“看起来很正常”。图2显示的地下论坛帖子,就是在讨论这些技术。
图2:地下论坛中的免杀技术帖
有效载荷的投递
我们发现,许多攻击组织都曾利用这种有效载荷进行加壳处理,然后通过垃圾邮件进行分发,当然,针对不同的人群,他们会使用不同的邮件主题。
一个样本是与电汇有关的垃圾邮件,它将一个文档文件作为邮件附件(哈希值:71cd5df89e3936bb39790010d6d52a2d),其作用是利用恶意宏来投递有效载荷。该垃圾邮件如图3所示。
图3:垃圾邮件样本1
另一个例子是报价方面的垃圾邮件,它将一个漏洞利用文档文件作为附件(哈希值:0543e266012d9a3e33a9688a95fce358),其作用是利用公式编辑器漏洞来投递有效载荷(图4)。
图4:垃圾邮件样本2
样本中的文档会从http://5.152.203.115/win32.exe下载有效载荷,其实,就是Lokibot恶意软件。
用户行为检测
这个加壳器会尽力确保自己不在安全分析环境中运行。对于普通用户来说,通常会在一定时间内切换多个应用程序窗口。该加壳器的第一个变体,会使用GetForegroundWindow API来检测用户切换窗口的次数,准确来说,只有切换三次之后,它才会继续执行其他代码。如果它没有检测到窗户的变化,就会自动进入无限期的睡眠状态,具体代码如图5所示。有趣的是,尽管这种技术非常简单,却能检测到多种常用的沙箱。
图5:检测窗口的变化情况
为了对用户活动进行印证,加壳器的第二个变体使用GetCursorPos和Sleep API来检查鼠标和光标的移动情况,而第三个变体则使用GetLastInputInfo和GetTickCount API来检查系统的空闲状态。
从PE资源中提取实际有效载荷
原始的有效载荷被拆分为多个二进制代码段,并分别存储在资源目录内的不同位置,如图6所示。
图6:具有加密内容的位图资源
为了定位和组装实际有效载荷的代码字节,该加壳器首先会从资源部分内硬编码的资源ID中读取相应的内容。其中,前16个字节用于生成一个XOR密钥,用于通过滚动XOR方法来解密其余字节。解密后的字节内容,实际上就是一些内部数据结构,具体如图7所示,供加壳器用于引用各种资源ID对应的缓冲区,注意,这些缓冲区都经过了相应的加密和混淆处理。
图7:展示加密文件信息的数据结构
之后,该加壳器就会从加密缓冲区读取相应的值,从dwStartResourceId开始,直到dwStartResourceId+dwNumberOfResources为止;并通过读取dwChunkSize块信息将其放到一个地方。一旦准备好最终数据缓冲区,就会通过前面讲过的滚动XOR算法和上述结构中的新密钥对其进行解密,从而生成有效载荷可执行文件。这个脚本可用于静态提取实际有效载荷。
恶意软件的家族分布
根据我们从样本集中提取的许多未加壳的二进制文件来看,它们都属于Lokibot恶意软件家族。此外,我们还能够识别Pony、IRStealer、Nanocore、Netwire、Remcos和nJRAT恶意软件家族,以及挖矿恶意软件家族,等等。使用该加壳器的恶意软件家族的分布如图8所示。不难看出,这里出现了多种恶意软件家族,这意味着许多威胁组织正在使用这种“加密”服务/工具进行免杀处理,并且很可能是从开发人员本身那里购买的。
图8:使用该加壳器的恶意软件家族分布情况
小结
自从有了加壳和加密服务之后,威胁组织就可以直接将有效载荷的免杀工作外包出去,一方面是简单省事,另一方面,还能提高免杀效果。而且,这些免杀服务的提供者经常会找到基于安全分析对抗技术的沙箱环境绕过方法;因此,利用模拟真实用户行为的沙箱环境来“引爆”恶意软件样本的方法已经不再可靠了。
IOC
853bed3ad5cc4b1471e959bfd0ea7c7c
e3c421d404c08809dd8ee3365552e305
14e5326c5da90cd6619b7fe1bc4a97e1
dc999a1a2c5e796e450c0a6a61950e3f
3ad781934e67a8b84739866b0b55544b
b4f5e691b264103b9c4fb04fa3429f1e