分析Android银行木马GM Bot的变异过程

2016年2月19日，IBM XForce的研究员发布了一个情报报告，这份报告声称GM BOT的源代码在2015年12月被泄漏到了一个恶意软件论坛上。GM BOT是一个复杂的安卓恶意软件家族，它出现在2014年末俄语地区的网络犯罪地下组织。IBM XForce同时还发现Banskosy，MazarBot，以及恶意软件Slembunk。实际上也是GM BOT的变种，包括Banskosy，MazarBot，以及FireEye最近提到的恶意软件Slembunk。

GM BOT中的很多功能都是针对Android用户的,包括拦截他们的短信。它允许攻击者控制目标设备,还能根据用户的手机,定制假的手机界面。

简而言之, GM Bot这样的手机银行木马对于罪犯来说，简直就是一种一站式的、提供各种欺诈手段的商店。

1.他们仿造银行应用程序的界面，使用假的界面覆盖原先的银行界面，从而窃取用户凭证和支付卡的信息。
2.他们控制设备的SMS继电器，然后窃听、截取并且发送SMS消息。         
3.他们还可以将电话转接给远程攻击者。         
4.他们也有间谍软件的功能,可以通过远程命令控制设备。

目前，GM Bot又把目标瞄准了MobilePay（丹麦银行的移动支付平台MobilePay）和Nem ID（丹麦的一种双因素认证系统）。本文通过静态分析和动态分析来对GM Bot的源代码打包过程进行剖析。

我们看到即使使用基本的静态分析，我们也可以分析出 GM Bot的恶意意图也可以很容易地实现，而且通过一个微小调试我们可以快速获得可读的源代码。

背景

要了解网络安全的，我们就有必要认真了解一下移动恶意软件是如何运作的。

本文就列举一些例子，来对它们的恶意运作过程进行演示。

SHA256: 44ed4bbd5cdc13c28992c16e99a7dc58f5f95463e889dd494a433549754f7863
MD5: da88bdcb3d53d3ce7ab9f81d15be8497

如果您还想要浏览此示例，可以通过google快速的搜索这些哈希值可能导致的后果。虽然分析人员已经有了这些源代码，但不清楚如何它们是如何实现的。有消息说这些代码已经被打包，但是还没有关于如何解压缩的分析的信息。

这篇文章就是要分析这些源代码解压缩的过程，希望能为的其他人提供一些提示。本文的分析过程分为以下五个阶段：

1.公共分析 ：首先我们可以使用现有的公共信息来源来进行查找，看看目前的分析到了什么阶段以及进行了哪些方面的分析。

2.静态分析：我们可以从找到的实际样本中进行分析，而不是在模拟环境中分析。

3打包调试：假设样本被打包并阻止我们对其分析，我们如何调试解包器以了解样本正在加载/运行的内容。

4.DEX文件提取和反编译：一旦我们实现了解包器的功能，我们如何对其进行反编译。

5.功能和动态分析 ： 一旦我们提取和反编译了代码，我们就会在安全模拟环境中看到GM Bot是如何进行工作的。

第一阶段，公共源分析

首先让我们看看我们在这个阶段可以找到什么？在Virus Total将其已经被标识为恶意产品，然而，我们还注意到，通过启发式分析所检测出的这些恶意软件是指所有含有“恶意代码”的产品。这种检测最初是由Ganga Man在暗网论坛上建立和销售。

第二阶段，静态分析

首先，我们要使用APK工具解压缩APK文件。这将解压缩内容，以及将DEX文件中的代码拆分成Smali：

apktool d da88bdcb3d53d3ce7ab9f81d15be8497.apk

这个结果可以在下面看到，该工具还提供了一个可读的AndroidManifest.xml文件版本。

第一个停止是看看Android清单文件，应该提供应用程序的组件和请求的权限的概述。

清单分析 - AndroidManifest.xml

初始分析显示恶意行为已经获取了广泛的权限，包括以下权限：

控制所有SMS消息（发送，接收，读取，写入，删除）
列表运行应用程序
读取手机的状态，联系人，SD卡数据
请求是设备管理员，使得能够在不向用户发出警告的情况下远程擦除设备

主应用程序，活动（15）和服务（2）的引用类文件的摘要视图如下所示：

此外，我们看到另外4个类映射为广播接收器，它将处理事件消息（Android系统Intents），如下所示：

从上图我们可以看到应用程序如下：

在手机通电时执行代码（自动启动应用程序）

当设备管理员被授予，请求或接收到禁用管理员的请求时接收通知（从而干扰或阻止用户启用它）

接收新的入站SMS的通知 - 具有高优先级标志，以确保代码可以首先拦截它，并可能停止任何进一步的警报（可以用于窃取2FA令牌）

在进行任何反编译之前，我们要做的就是探索APK中的其他文件的线索。

比如以下文件：

文件：assets / fytluah.dat

一个没有立即明显格式的二进制文件。可能的代码在运行时未加密/解压缩？

文件：res / values / strings.xml

应用程序的英语字符串，如下所示：

字符串清楚地表明此恶意软件的目标是获取受害者的信用卡信息。如此之外，我们还发现了以下线索：

有趣的是，这里的资源键都是英文，表明原始开发者可能是英语区域

尽管这个资源文件是用于英语编写的，但仔细看会发下其中有一些特定的字符串是丹麦语，

除了英语字符串，我们还看到其他几个目标国家：

文件：res / values.xml

此文件包含国家/地区代码列表，特别是“非vbv”这组。这被理解为意味着他们不使用“通过签证验证”过程，该过程用于在在线购买期间强制执行额外的验证检查。很可能攻击者会试图通过恶意软件获取额外的VBV凭证（ 是VISA国际组织为提高信用卡网上支付的安全性,保障客户网上支付安全,维护客户利益而共同推出的一项安全验证服务），以允许在线购买卡详细信息（或避免这些国家）。

目录：res / drawable

图片和图标包括：

丹麦语“Nem Id”的示例照片 - https://en.wikipedia.org/wiki/NemID
丹麦银行移动支付的图标
万事达卡安全代码
通过签证验证的图标
Google Play
Flash图标（主应用程序图标）
Whatsapp

此外，有png图像前缀“overlay_”，表示欺诈覆盖活动可能使用。

反编译为Java源代码

接下来，我们尝试将DEX文件反向工程恢复为原始的Java源代码。为此，我们使用dex2jar如下将DEX文件（在APK中）转换为Java类文件存档：

Dex2jar da88bdcb3d53d3ce7ab9f81d15be8497.apk

然后可以使用JD-GUI解压缩生成的jar文件，如下所示：

java -jar ../../jd-gui-1.4.0.jar da88bdcb3d53d3ce7ab9f81d15be8497_dex2jar.jar

我们在JD-GUI中看到的结果java类显示应用程序中只包含4个java类。这与我们在应用程序清单中声明的16个不同类形成了直接对照。确认必须有在运行时动态加载的附加代码 - 这很可能是这四个类实际上是一个解包器。

检查代码，我们看到它被严重混淆，并且已经被制定以防止干净的反编译代码。除此之外，我们可以通过检查在应用程序首次执行时导入（因此使用）的系统类，开始了解这四个类的功能。

从JD-GUI导出java源并解压缩到新文件夹后，我们可以从这些文件中提取导入的类：

find . -type f -exec grep "^import" {} \; | sort –u

我们可以从中找到如下的分类

基本上我们用了一个非常小的库被导入和使用。这些功能包括：

一般Android应用程序和上下文类（预期和所有Android应用程序需要）
文件相关类（红色） - 用于访问，读取和写入本地文件
Java反射类（绿色） - 用于创建新类和实例以及动态调用方法
这证实了这样的假设，我们最有可能处理从本地文件资源解包它的可执行代码的解包器。

第三阶段：解压缩调试

由于Java代码不能被容易地反编译（由于恶意软件的开发者也会进行注入保护），我们将根据Smali汇编代码调试可执行文件。 Smali是Dalvik虚拟机使用的DEX代码的反汇编。

需要用于Android Studio的Smali / Baksmali插件，然后将Apktool的输出作为新项目导入。我们接下来在三个类（a，b，c）中根据需要设置断点：

具体如下：

a.smali（一个基于java.lang.reflect.Constructor实例创建的行）

b.smali（通过反射调用对象上的方法的行）

c.smali（与上述a.smali类似）

现在我们将应用程序安装到模拟器（通过ADB，以确保它不会像在一些模拟环境中自动启动）。

要启用调试器连接到应用程序，我们在启动应用程序之前执行以下操作：

通过在设置>关于设备中重复点击内部版本号来启用开发人员选项

在开发人员选项中，选择“选择调试应用程序”，然后选择恶意应用程序 - “Adobe Flash”

在开发人员选项中，启用“等待调试器”

现在从启动器中启动应用程序，将提示您附加调试器，

在Android Studio中，使用图标附加调试器。选择恶意应用程序进程。然后调试器在我们的第一个断点处停止，如下所示：

注意，你现在应该设置一些变量来观察 - 按照上面的设置v0到v10和p1到p3。我们的第一个断点被击中，我们看到我们将要通过反射执行一个方法。注意到我们还没有调用newInstance（），我们可以假设这是调用现有的（加载）类 - 应用程序加载的四个之一，或一些其他Android框架类。

接下来，我们使用该方法强制进入，以查看它调用哪个方法（smali调试器看起来有点儿错误，我们现在不能看到传递的参数）。

初始调用获取当前上下文对象，可能是从APK开始检索本地资源。 我们现在允许调试器继续并重复此模拟几次以建立反射方法调用的流程：

Context android.context.ContextWrapper.getBaseContext()
//expected 2 arguments, got 1 – error in malware code, or to throw off debugging?
//Several more of these not shown
IllegalArgumentException java.lang.IllegalArgumentException(String s)
void Java.lang.reflect.setAccessible(boolean flag)
File android.app.getDataDir()// returns /data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjqjava.io.File.getAbsolutePath() ContextImpl android.app.getImpl(Context context)//filename is fytluah.datInputStream android.content.res.AssetManager.open(String fileName)

暂停在这里，我们可以看到代码正在尝试加载我们以前在静态分析部分中标记为的文件。 继续我们看到文件被读取，可能被解密，然后作为一个jar文件再次写出：

int android.content.res.AssetManager.read(byte[] b)
//className = java.io.FileClass java.lang.Class.forName(String className) 
//args = String “/data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjq/gpyjzmose.jar”
T Java.lang.reflect.Constructor.newInstance(Object.. args) 
void java.io.FileOutputStream.write(byte[] b) #25
void java.io.FileOutputStream.close()

最后调用DexClassLoader来将附加代码加载到系统中：

ClassLoader java.lang.Class.getClassLoader()
//className is dalvik.system.DexClassLoaderjava.lang.Class.forName(String className)

查看DexClassLoader的API，我们可以看到它需要两个参数： 要加载的文件的位置，以及一个可写区域，它将用于为特定机器架构重新编写优化版本的代码，例如 Android运行时间（ART）。 有关这方面的更多信息，请参阅Android API文档：

https://developer.android.com/reference/dalvik/system/DexClassLoader.html

第四阶段：DEX提取和解码

我们可以在下面的调试器中看到jar文件的确切位置，下一步是通过ADB命令行恢复这个文件。

执行类加载器后，通过ADB shell连接我们可以看到这两个文件，原来的和DEX优化后的代码：

我们将这些文件复制到/ sdcard /下载（+ chmod），然后将.jar文件拖到本地模拟实践中，进一步使用adb pull分析。

提取jar文件我们找到classes.dex文件，重复此步骤，使用dex2jar将其转换为jar文件并使用JD-GUI反编译，现在我们就有这个恶意软件示例的完整的源代码了。

第五阶段：动态和功能分析

首次安装

在初始分析时，我们可以看到代码库与静态分析中确定的泄漏源具有显着的相似性。然而，也存在显着差异，并且代码已被模拟成为专门针对丹麦银行MobilePay的应用程序了。

由于代码基本上没有混淆，现在将简要介绍这个恶意软件的关键功能，从第一次安装开始。

首次安装过程如下：

首先在安装和执行时，应用程序将执行两个主要功能。它最初将收集用户数据的范围，包括电话联系人，所有SMS消息和其他密钥数据，并将其发送到C＆C服务器。 C＆C服务器然后返回唯一的安装标识符，然后唯一的安装标识符被用于所有未来的通信以唯一地标识受损的设备。

其次，恶意软件将使用户接受软件作为设备管理员。如果用户拒绝请求那该软件会被重新被触发，最终大多数用户将会选择同意。有了这个权限，恶意软件实现了两个目标：

1.应用程序不能被用户轻松地卸载，以保证不被取消设备管理员权限。尝试执行此操作将触发启动覆盖，以防止删除设备管理员

2.在将来的某个时间点，一旦从电话窃取了另外的数据，C2服务器可以发出命令来擦除设备，移除感染的证据并将设备恢复到出厂状态

包括每次重新启动后，正在进行的操作

恶意软件维护C2服务器的正常运行，这为攻击者向设备发出特定命令提供了一种机制。每次运行包含安装ID和当前屏幕状态。前提是攻击者会在用户关屏时进行。

首先，我们看到了“锁定”和“解锁”手机的能力。这模拟了Android软件更新屏幕，并有效隐藏了屏幕覆盖后面发生的任何其他活动（例如发送，接收或删除SMS消息）。此外，这可以用于禁用用户，并且防止他们使用电话，而他们的帐户或卡被实时泄密。

接下来，我们看到另一个功能，意图拦截和转发SMS消息到C2服务器，并专门试图删除他们曾经存在的证据，删除它们。这用于窃取2FA凭证。

接下来从C2服务器的角度看，我们看到两个“重置”命令。第一个，“软”复位，用于重置内部标志以重新尝试窃取Nem ID凭证。第二种是“硬”复位，执行并立即擦除器件数据。

最后，我们看到向攻击者定义的移动设备发送任意SMS消息的能力以及向设备上的另一个应用程序启动定制推送通知的功能。暂时不清楚这可以用于什么。

通过短信远程操控

通过侦听传入的SMS消息，恶意软件还可以触发假的Android更新屏幕，然后截获此信息，转发并尝试在消息到达电话时删除消息。可以通过经由SMS传递到电话的定制的SMS命令消息来启用和禁用该模式。

数据自动窃取

根据原始文章和静态分析的许多指标，应用程序的主要目的是通过在合法应用程序之上执行覆盖来窃取数据。恶意软件针对三种特定的应用程序类别：

丹麦银行的MobilePay应用程序，具体意图窃取Nem ID凭据

触发试图通过自定义叠加层窃取信用卡详细信息的应用

触发窃取用户移动电话号码的尝试的应用（可能用于触发上述“管理”模式）

覆盖丹麦银行MobilePay的过程

在启动MobilePay应用程序时，覆盖尝试窃取用户的CPR号码（唯一的社会安全类型id），移动号码和Nem密码。然后它要求用户拍摄他们的Nem ID存折的照片，其中包含一次性使用代码，攻击者可以使用该代码登录到MobilePay（和其他丹麦语系统）并支付款项。

窃取信用卡详细资料

在启动目标应用程序之一时，根据启动的应用程序，显示具有可配置图标的信用卡覆盖图。收集基本卡详细信息后，应用程序将尝试恢复用户的Visa验证密码。然后将这些详细信息转发到C2服务器。

盗取电话号码

最后，我们看到的目标是获取用户的电话号码的功能，可能会通过获得这些信息绕过2FA进一步对受害者帐进行攻击。

总结

本文对GM Bot的变异似乎是仅仅针对于MobilePay应用程序这个变体的分析，但通过分析我们发现，一旦一个恶意软件的源代码被发布并且在网上能轻而易举的搜到，那它被快速改变的可能性就很大。

MobilePay应用程序就是一个很好的例子，GM Bot源代码一旦发布，复杂的代码可以快速，轻松地被不太专业的开发者和一个成熟的黑客模式所应用，而且代码库变体的扩展变得更难以跟踪和检测。

一如既往，防止成为此类恶意软件的受害者的最佳方法就是确保您的手机在安装第三方应用程序时始终要保持审查权限请求 - 例如，它们是否与应用程序的使用说明一致等等。