【木马分析】深入分析Android/Ztorg的最新变种

【木马分析】深入分析Android/Ztorg的最新变种

2017-03-26 11:45:21
来源：fortinet.com 作者：shan66

阅读：313次
点赞(0)
收藏

【木马分析】深入分析Android/Ztorg的最新变种

作者：shan66

稿费：300RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

前言

Ztorg，又称为Qysly，是Android恶意软件的最大家族之一。它于2015年4月首次现身，目前变种数量已经超过25个，截止2017年，其中一些变种仍然处于活跃状态。然而，关于Ztorg的技术说明却非常匮乏——好像只有最初的Ztorg.A样本的相关分析，所以我决定根据2017年1月20日检测到的较新版本的Android / Ztorg.AM！tr做一番深入的分析。

该样本以“Cool Video Player”身份示人，并且它的恶意活动是如此隐蔽，以至于最初我认为这是一个误报。但是，它绝非善类，不久您就会明白了。

寻找恶意代码

这个样本的manifest表明main activity位于com.mx.cool.videoplayer.activity.mainactivity中。

这个activity用于初始化多个SDK，但是从中没有检测到恶意行为：

com.adjust：调校SDK，用于应用程序的分析

com.batmobi：Batmobi，用于移动广告

com.catchgift：这显然是广告

com.marswin89：这是一个marsdaemon，该库用于保证应用程序的处于运行状态，但没有恶意行为。

com.squareup：移动支付

com.umeng：移动广告分析

那么，恶意代码到底在哪里呢？难道只是某个开发工具包中的一些“不太干净的”代码触发了警报（假阳性）吗？

我继续在这个应用程序的其他命名空间中进行寻找：

u.aly包含MobClick广告代码，

android.support.v4是应用开发标准。

命名空间e.i.o.q除了命名空间a调用函数之外，没有做任何事情。

所以，当我开始探索命名空间a…

字符串混淆

我立即注意到有许多经过混淆处理的字符串，并且忍不住要进行反混淆处理（要不咋叫Crypto Girl呢，对吧？）

例如，请看下列代码：

其中c.a()函数的实现代码如下所示：

简单来说，这就是将第一个和最后一个字节作为XOR密钥对字节数组的其余部分进行混淆处理。于是，我写了一个单独的python解码器，来模拟反编译代码。它的确很方便，不过要是使用JEB2脚本的话，可能会更好一些，这样就可以让它直接在反编译的输出中替换这些字符串了。

JEB脚本写起来很是需要一些技巧。Mine用于对反编译的类进行解析，并在每个类中使用c.a（new byte [] {...}）来定位语句。许多情况下都会出现对这个解码函数的调用，例如v0 [6] = ca（new byte [] {...，以及 a = new String(c.a(new byte[]{....。因此，我们需要对其右侧的代码进行非常细致的分析。当检测到一个调用时，脚本就会对相应的值进行解码，并使用解码的结果将其替换掉。

例如，第一个图（左边）展示了a.a.a.的初始的反编译代码。第二个图展示了使用脚本处理后的结果。

这里使用的脚本可以从Github上下载。

模拟器检测

在解码的字符串中，我们注意到许多VirtualBox，QEMU之类的引用。这是模拟器检测，下面您会发现，这是一种非常高级的技术。

让我们回到执行的流程。主活动（MainActivity）的onCreate()方法会调用f()，f()会调用e.i.o.q.d()。通过逆向e.i.o.q.d()，我们发现该函数会检测是否在模拟器上运行。如果不是在模拟器上的话，它就只运行代码中的恶意部分，这正是沙盒没有记录下任何恶意活动的原因。

这个模拟器检测例程是一种非常复杂的技术，并且用途广泛。它能检测标准的Android模拟器、Genymotion模拟器、Bluestacks模拟器、BuilDroid虚拟机，以及使用TaintDroid的环境。

那么它是如何检测模拟器呢？它可以根据：

1.系统属性中的特定值。

2.与模拟器有关的IMEI、IMSI和电话号码的典型值。在Genymotion中，IMEI是可以定制的，但IMSI则不可以。在标准Android SDK模拟器上，这些都难以定制，除非给模拟器打补丁并重新编译模拟器。

3.存在特定文件。例如，/ dev / qemu_pipe。从AV分析师的角度来看，这是很难对付的，因为没有这些文件的话，许多模拟环境将无法正常工作。

4.检查特定系统文件中的某些值。需要特别指出的是，这是我第一次见到恶意软件检查/ proc / net / tcp中的值。这一点非常有趣：该文件是记录活动的TCP连接的。第一列对应于条目数，第二列是本地地址，第三列是本地端口，第四列是远程地址。在真实的设备上，我们会看到下列内容：

0:4604D20A:B512A3D13AD8...

但是在模拟器上，地址会被清零，这很容易注意到：

0:00000000:001600000000:0000

5.特定的TaintDroid类（dalvik.system.Taint）和注入的字段（FileDescriptor类中的名称和Cipher中的密钥）。这些代码可能是来自Tim Strazzere的反模拟器代码。

下载远程内容

我们已经看到，该样本实现了高级的仿真器检测功能。然而，许多正常的应用程序也会出于各种原因而做这些事情的。那么，恶意的代码究竟在哪里呢？当目前为止，我们仍然无法确认这不是一个误报。

其实，我们离真相已经越来越近了。当样本检测到并非在模拟器上运行之后，它就会发送一个HTTP请求到hXXp：//bbs.tihalf.com/only/ [$ 1] /2.html ?。这正是我们在上一步中反混淆处理后得到的那个网址。[$ 1]被替换为gp1187（另一个反混淆后得到的字符串），并且将一个blob附加到url中，这里的blob是一个包含代码版本、SDK版本等信息的经DES加密的JSON对象。

它已经越来越可疑了。

响应是base64编码形式的，并用DES-CBC进行了加密（见类a.c.a）：

密钥是硬编码的（就是反混淆处理后的字符串sokhlwej），IV是DES_e.IV = new byte [] {1,2,3,4,5,6,7,8}。好了，现在我们对服务器的响应进行解密：
【木马分析】深入分析Android/Ztorg的最新变种

我们注意到o和p含有一个关于Android包的链接。那么，它们被用到了吗？是的! 检索JSON对象后，该样本就会读取o中的URL，并尝试下载该文件。如果o无法正常使用，它就会尝试p。

因此，基本上可以确定，这个样本会从hXXp：//alla.tihalf.com/only/gp1187/gp1187.apk下载另一个Android软件包，并将其保存智能手机上。

但事情还没有这么简单，因为下载的APK不是明文形式的：

实际上，它是与0x99进行异或（参见类a.d.f的代码）处理后，才被复制到名为dba.jar的文件中的：

但是，这确实得到了一个有效的Android包：

然后呢？当然是加载刚才所下载的应用程序了！具体过程，请看下面取自a.d.n的相关代码。

这个应用程序的安装是通过DexClassLoader完成的，并且对最终用户来说是不可见的。

最后，它将调用该应用程序的一个方法。具体来说，它将加载JSON对象中的键q引用的类，并调用JSON对象的方法h：

在我们的样本中，q是n.a.c.q，h是c，所以这个样本将会调用n.a.c.q.c()。

小结

虽然这个Ztorg样本在隐藏其恶意行为方面做得非常好，但我们仍然可以确认它是恶意的，而不是误报。

它实现了许多模拟器检测功能。它会检测Android SDK模拟器，以及来自Genymotion、Bluestacks和BuilDroid的模拟器。它还会检测受感染的环境。它的这些检测是难以绕过的。

它使用基于XOR的字符串混淆。

它使用DES-CBC加密与远程服务器的通信。

它从远程服务器下载、安装并启动Android应用程序。

在本文的下篇中，我们将对下载的应用程序进行深入考察。

下篇

在本文的上篇中，我们看到Android / Ztorg.AM！tr会静默下载远程加密APK，并进行安装，然后在n.a.c.q类中启动一个名为c()的方法。在这篇文章中，我们将深入调查它究竟做了些什么。

下面是n.a.c.q的方法c()代码：

它会打印“world”，接着等待200秒，然后启动一个名为n.a.c.的线程。这里，需要注意的第一件事情是，这个样本实际上使用的是相同的字符串模糊例程，只不过这里的名称不是a.b.c.a()，而是a.a.p.a()。所以，我们需要对JEB2脚本进行相应的修改，以便对这些字符串进行反混淆处理：

内嵌的软件包

该样本会查找各种包（om.android.provider.ring.a，com.ndroid.livct.d）。如果找到了，就会启动它们。如果没有，就设法获取并启动它们。

它获取应用程序的方式也是非常奇葩的。默认情况下，它不会从Web下载，而是从代码本身存储的十六进制字符串中获取。如果这个字符串没有找到的话，那么它就只能从网络下载了。

它会通过这种方式来获取多个文件：Android应用程序、ELF可执行文件和脚本。所有这些都被嵌入在样本自身中。有时，它们是以加密形式嵌入其中的，这会给反病毒引擎造成不小的麻烦。其中，mainmtk.apk应用程序就属于这种情况，它是从DES加密的十六进制字符串中获取的。这里的DES密钥是使用定制的算法构建的，该算法由许多Base64编码和解码组成。

加密的文件下载

当文件从Web下载时，它们不是以明文形式发送的，而是通过XOR进行加密（见b.b.b.a.b类）。XOR密钥包含在加密信息流中。

通过对解密类实施逆向工程，我们可以实现相应的解密程序。Mine可以从在这里下载。

例如，一旦完成解密，从hxxp：//ks.freeplayweb.com/lulu/bx下载的bx文件就会变成ELF可执行文件（获取root权限的漏洞利用代码）：

创建脚本

该样本还使用了一些shell脚本。它们没有保存到asset或resource中，而是嵌入在代码中。这可能是为了阻止防病毒引擎进行直接匹配或找到这些脚本。

例如，下面的代码编写了一个名为boy的shell脚本。

该脚本如下所示，可用于运行shell命令。

文件汇总

现在让我们总结这个样本所使用的各种文件。这里包括一些应用程序和ELF可执行文件。如果你想在源代码中进行跟踪的话，可以到b.b.d.a命名空间中进行检索。

这些文件的本地存储位置位于该应用程序的目录中，具体来说是名为.zog或.zok的子目录中。注意，以点开头的名称能够实现隐身。

我们看到，这些文件主要分为三类：

工具，如busybox和supolicy。它们本身不属于恶意代码。Busybox用于支持Android上的各种Unix命令。Supolicy用于修改Android上当前的SE linux策略。

用来获取root权限的漏洞利用代码。例如，可执行文件Agcr32用于获取手机的root权限。如果它认为自己得手了，输出就会包含关键字TOY，具体见下文。这里是32位版本，但是如果需要的话，这个样本还会下载64位版本。

运行命令的脚本。

运行漏洞利用代码

一旦将用于获取root权限的漏洞利用代码下载到文件系统上，接下来就是运行它们了。为此，这个样本创建了一个运行sh的新进程，将shell命令写入进程的输出流，并读取输入流上的响应。

有效载荷

让我们把这些零部件组合起来。

样本将：

获取大量的漏洞利用代码、工具和脚本文件，它们可以用于获取root权限的。这些文件都嵌入在代码本身中，或从外部网站获取。

降低SE Linux策略的安全级别，然后尝试获取设备的root权限。

一旦获取了设备的root权限，真正的有效载荷就要上场了：

将某些系统文件替换为自己的版本。例如，它对原始/ system / bin / debuggerd进行备份，然后用它自己的.zog / .k文件替换它，为其赋予root权限，并更改其SE Linux安全上下文。

安装各种应用程序并运行它们。在这个样本中，这些应用程序是com.android.provider.ring.a、com.ndroid.livct.d和com.android.musitk.b。.zog / .k 这个ELF可执行文件还可以从远程服务器下载并安装其他应用程序。下面的屏幕截图表明.zog / .k启动了一个密码助手应用程序（am start -n），并且正在从http://api.agoall.com/进行下载（不再响应）。