FireEye：恶意软件家族拥有共同的起源

简介

2月19日，IBM XForce研究者发布了一篇报告[1]，是关于2015年12月份公布出来的恶意软件GM Bot的源代码。GM Bot是一款很繁杂的安卓恶意软件家族，2014年年末出现在俄罗斯的地下犯罪网络中。IBM声称，最近发现的好几款安卓恶意软件家族实际上都是GM Bot的变异体。其中包括Bankosy[2], MazarBot[3], 还有最近FireEye描述的SlemBunk恶意软件。

安全厂商可能对恶意软件的变体有不同的定义。恶意软件变体指的是和原来恶意软件的代码几乎相同或者有一些不同，但是这些从代码是看只有轻微的差别，但实际上差别的非常大。

通过IBM的报告，我们比较了GM Bot样本和SlemBunk。基于这两个恶意软件家族的反汇编，我们认为GM Bot和SlemBunk有足够的代码相似性，他们很可能有共同的起源。有趣的是，我们的研究表明实际上有一个更早的恶意软件家族，名字叫SimpleLocker——这是第一个已知的文件加密的安卓恶意软件[6] ——这和一些银行木马家族很相似。

GM Bot 和SlemBunk

我们的分析表明，有四个GM Bot样本都共同引用了SlemBunk的主要组件。图1是我们早期的报告，是SlemBunk的主要组件的代码部分，对应的类名如下：

1. 服务启动器(ServiceStarter): 该服务是一个接收器，当一个应用或者设备启动的时候，该服务就会在后台启动监控服务MainService。

2. 主服务(MainService): 该服务在后台运行，可以监控设备上所有正在运行的进程。它会像正常的app提醒那样通过覆盖视图提醒用户。同时，这个监控服务会和远程主机进行通信，会发送设备的初始数据、设备的状态信息以及应用程序首选项。

3. 信息接收器(MessageReceiver): 是一个安卓的信息接收器，可以处理输入的文本信息。一方面提供拦截银行的身份认证信息的功能，另一方面作为客户端执行远程主机的控制命令。

4. 请求管理权限(MyDeviceAdminReceiver): 当app第一次运行的时候，该服务会向系统请求管理员权限，成功后，该app就更难从系统中移除。

5. 自动以UI界面(Customized UI views): 可以自定义用户登录界面，可用于模拟一个假的银行应用程序登录界面或者社交网络登录界面，用于银行钓鱼或者盗取社交账号。

图1 SlemBunk恶意软件家庭的主要组件

前面三个GM Bot样本和提到的SlemBunk样本具有相同的包名称。此外，GM Bot的样本具有的这5个组件和图1中的SlemBunk样本具有相同的组件名。

第四个GM Bot样本具有不同的初始包名，但是，在运行起来后解压出真正的payload，发现，解压后的payload其实和SlemBunk样本是一样的，同样也有一些改变的地方：MessageReceiver变成了buziabuzia，MyDeviceAdminReceiver变成了MDRA。

图2 GM Bot和SlemBunk之间的代码结构比较

图2展示了GM Bot样本和SlemBunk样本之间代码结构的相似性(其中SHA256 9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e和SHA256 e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27分别是GM Bot和SlemBunk)。通过这幅图，我们可以知道我们以前的文章中[4]讨论到的5个重要组件也同样存在于GM Bot样本中。其他常见的类包括：

1. Main，两中样本的启动。

2. MyApplication，应用程序的类，比任何其他都早启动

3. SDCardServiceStarter，另一个接收器，可以监控MainService的状态，并且如果MainService死了，可以重启它。

在上面提到的所有组件和类当中，最关键的是MainService。App启动的时候它通过Main类启动，并且在保持在后台运行并且实时监控正在运行的进程。当检测到有可以攻击的app运行的时候(e.g. 一些银行的移动应用程序)就会用模拟的登录界面覆盖真实的登录页面，进行钓鱼。为了保证MainService持续运行，恶意软件的作者增加了两个启动器——ServiceStarter和SDCardServiceStarter，用于检测软件的运行状态，防止特殊的系统时间发生。GM Bot和SlemBunk有相同的代码结构。如图3所示，我们可以看到SDCardServiceStarter类的主要代码，以及GM Bot和SlemBunk是如何通过同一种机制运行MainService。

图3 GM Bot和SlemBot中的SDCardServiceStarter类中的方法

从上图可以看出，GM Bot和SlemBunk使用相同的代码启动MainService。注意，当样本检测到系统的本地位置是在俄罗斯的时候，就会避免使用MainService启动。唯一不同的是，GM Bot样本将会对这些类、方法和字段进行重命名，例如：在GM Bot中的静态变量“MainService;->a”和SlemBunk中的“MainService;->isRunning”实际上具有相同的作用。恶意软件的作者这么做就是为了混肴视听，让他的代码更难以理解，但是这些无法从底层改变代码架构。

图4向我们展示的是GM Bot和SlemBunk的核心代码类MainService，这表明两种恶意软件具有相同的逻辑结构。安卓中，但一个服务启动时，onCreate方法就会被调用。两种样本中的onCreate方法中，都是先把一个静态变量设置成true。在GM Bot中，静态参数命名为“a”，然而在Slembu中命名为“isRunning”。然后，两个都继续移动到真实程序的正常设置中。注意，两个样本有相同的设置“AppPrefs”。两个样本最后步骤做的任务也都是一样的。特别是，为了检测是否有可以攻击的app在运行，都调用了一个线程。如果有可攻击的app，相应的覆盖视图将会被加载到这个app的顶部。在这两个线程中唯一的不同也仅仅是名字上的不同。在GM Bot中是“d”类，在SlemBunk中是“MainService$2”，功能都是用来做凭证钓鱼。

图4 GM Bot和SlemBunk中的MainService类

总之，我们通过分析二进制代码的相似度的结果表明IBM的结论没错，GM Bot和SlemBunk确实有相同的起源。

SimpleLocker 和 SlemBunk

在我们的研究中，我们注意到一个更早的安卓恶意软件名叫SimpleLocker也有着和SlemBunk和GM Bot相似的代码结构。不同的是，SimpleLocker要求受害者提供赎金。SimpleLocker在安卓设备上运行后，先是扫描设备中特定类型的文件，并且加密这些文件，然后向用户索要赎金之后，才给解密。在SimpleLocker之前，也有其他形式的勒索软件可以锁定屏幕，然而，SimpleLocker被认为是第一款文件加密型的安卓勒索软件。

最早对SimpleLocker的报告是在2014年由ESET公布的[6]。然而，在2014年5月份的时候，在我们的恶意软件库里面发现了一个更早的样本(SHA256 edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb)，这个程序的编译日期是2014年5月20日。我们用相同的方法将这个SimpleLocker样本和其中一个SlemBunk样本(SHA256 f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96)进行对比。

图5就是两种样本的代码结构对比图。注意，SimpleLocker变体也有主要的组件ServiceStarter 和MainService，而这两个组件在SlemBunk中也用到。然而，SimpleLocker中的主服务目的不是用于监控app的运行和钓鱼银行登录页面。反而，SimpleLocker的主服务是用于扫描设备中的特定文件，扫到了就调用加密算法对文件进行加密，然后索要赎金。SimpleLocker代码中最大的区别如下图红色框标志的部分：AesCrypt和FileEncryptor。其他的类如下描述的：

1. Main，样本的启动

2. SDCardServiceStarter，另一个接受器，可以监控MainService的状态，同时，如果MainService死掉了，还可以重启它

3. Tor and OnionKit，私人通信的第三方库

4. TorSender, HttpSender and Utils，支持类提供CnC通信代码并且收集设备信息

图5 SimpleLocker和SlemBunk样本的代码结构对比

最后，我们来看看另一个在2014年7月份发现的SimpleLocker样本

(SHA256 304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b)，大约是发现第一个SimpleLocker样本后2个月。这个新的样本并没有用Tor作为私密通信，但是，他和SlemBunk样本

(SHA256: f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96)由着四个相同的主要组件。图6向我们展示了两种样本的代码结构对比。

图6 SimpleLocker和SlemBunk变体的代码结构对比

正如图6所示，新的SimpleLocker样本使用了和SlemBunk相似的包结构，都是把HttpSender 和Utils封装进“utils”包。它也添加了其他两个SlemBunk中的主要组件： MessageReceiver 和MyDeviceAdminReceiver。总的来说，SimpleLocker和SlemBunk有四个主要的组件相似。

图7是之前样本的MessageReceiver的主要代码，这表明SimpleLocker和SlemBunk使用的是基本相同的流程，并且，使用相同的逻辑结构进行CnC通信。首先，MessageReceiver类本身用来处理传入的短信，这将会触发onReceive函数。如下图所示，他们的逻辑结构基本上是相似的。他们都是先读取应用程序的key值。注意两个软件的key值的名字和preference的名字是相同的：key值是“CHECKING_NUMBER_DONE”并且preference值是 “AppPrefs”。

接下来的步骤就是调用retrieveMessage 方法来检索短信息。在这里，唯一一个不同点是SimpleLocker多了一个额外的名叫processControlCommand的控制流。

SmsProcessor类定义了恶意软件提供的CnC指令。我们来看下SmsProcessor类，我就发现，越来越多的证据指向SimpleLocker和SlemBunk有共同的起源。首先，SimpleLocker提供的CnC指令实际上是SimpleLocker提供的一个子集。在SimpleLocker中，CnC指令包括“intercept_sms_start”, ”intercept_sms_stop”, ”control_number” 和“send_sms”，这些指令在SlemBunk样本中也有提供。甚至，SimpleLocker和SlemBunk的CnC指令都有一个常见的前缀“#”。这也表明两种软件由着相同的起源。