从Geost到Locker：监控Android恶意软件混淆的演变过程

趋势科技的研究人员通过相隔近一年的Geost和Locker样本研究了Android恶意软件混淆方法的演变，发现该恶意软件的开发者使用了外部混淆服务。

早在2019年，趋势科技的研究人员研究了Geost，这是一个具有有趣的混淆层的Android木马。通过比较2019年的发现和2020年的新样本，本文详细介绍了其混淆方法的演变。

本次的调查始于研究人员调查Android木马僵尸网络的活动，他们发现攻击者实际上正在使用外部服务进行APK混淆，而以前从未发现过这种情况。然后，他们通过了解其使用情况并发现其客户端来详细审查这项服务。我们在一篇论文和三篇博客文章中分享了我们联合调查的结果。

本文从技术方面描述了所使用的混淆方法，以及随着时间的推移，在不同样本中反映的混淆师代码的演变。如前所述，研究人员第一次分析Geost样本是在2019年。将近一年后，作为联合调查的一部分，研究人员分析了新的样本。第二次，研究人员分析了三个被同一个服务混淆的应用程序：一个Locker应用程序，一个SMS窃取程序和一个广告软件。本文集中讨论了2019年以来的Geost恶意应用程序和2020年之后的Locker混淆的应用程序之间的差异，这些差异显示了混淆服务在大约一年内生成的代码的演变。

一个混淆应用程序的string .xml文件的摘要

从上图中可以明显看出，所有符号名称都被混淆了。上面的图还显示了研究人员遇到的第一级混淆。有趣的是，在一个程序包中，原始类名被连续生成的字符串替换，这些字符串从一个字母(比如“a”到“z”)开始，到两个字母(比如“aa”、“ab”等等)开始，程序包中的最后一个以“fm”结束。与第一阶段一样，其余的类名称被随机生成的字符串替换，长度范围从6到12个字符不等。更改很可能是由服务混淆程序完成的。不过在外部混淆之前，先前恶意APK中已经存在的符号很可能已经被混淆了。

恶意Geost样本中的字符串被打乱的字节数组替换，事实上，这是另一个被混淆的层。在以前至少包含一个字符串的每个类中插入一个反汇编方法。这个方法总是有三个参数，它们定义了反汇编算法的参数；但是，每个方法中的参数都是随机排序的，这使得解压缩任务变得复杂。因此，一个反汇编Python脚本是不够的，必须对每个类进行修改。图2是一个反汇编方法的示例。

一个反汇编方法的示例

鉴于第二阶段的复杂性高于第一阶段，因此这种方法使对第二阶段进行逆向工程的任务处于同一级别。与其他恶意APK样本相比，该方法还被证明是防止有害信息泄漏的有效方法。

垃圾代码数量大大增加

从2020年年中开始，样本中的垃圾代码数量明显高于将近一年之前的Geost样本中的垃圾代码数量。表1中的数字证明了这种猜测，除了少量的滴管程序代码更改外，垃圾类和垃圾代码行的数量都大大增加了。

不同滴管APK样本的复杂度比较

加密的恶意APK文件名

在Geost示例中，加密的第二阶段DEX文件存储在名为“.cache”的文件中，该文件又存储在根APK目录中。该文件在解密并存储在“ydxwlab.jar”文件中之前，已重命名为“.localsinfotimestamp1494987116”。在所有较新的示例中，APK根目录中还有一个名为“tracks”的目录，如图3所示，该目录包含几个随机命名的文件。

“tracks”的目录内容

小于100字节的文件包含随机生成的字符串，文件“online.m3u”包含路径“tracks / radio.ogg”。这个radio.ogg文件包含一个加密的恶意载荷。

值得注意的是，与以前的Geost示例相比，这里也有很小的变化，因为现在有了一个非常简单的标头，它是加密数据的前缀。如图4所示，此标头包含以小尾数形式编码的四个字节的长度。此外，临时解密的DEX文件的名称已修改为“skjoxawp.jar”。

radio.ogg文件的标头，其中包含后面的加密数据的长度

字符串串联方法

即使在第一阶段中使用的所有字符串都已加密，但出于某种原因，其中的三个字符串也会被分成两部分，然后通过一种研究人员已命名为CombineStrings的混淆方法进行连接。仅当第二个参数大于零时，此方法将第一个和第三个参数中获取的字符串连接起来。将字符串拆分为“forName”，“android.app.Instrumentation”和“newApplication”。这个细节说明了混淆代码的开发者是如何特别小心处理这些字符串的，这三个字符串都用在核心函数中，该函数加载并启动第二阶段的代码，如图5所示。

这段代码展示了特殊的combineStrings()串联方法的用法

此时，旧示例和新示例之间的差异仅在第二个参数小于或大于零（参见图6）的代码分支中才可见，这从未真正执行过。因此，改变的原因是未知的。

新旧版本的combineStrings()方法之间的差异

调用方法的演变

与我以前的文章一样，部分代码混淆是通过用Java Reflection等效项替换某些系统方法调用来完成的，在此方法中，用于反射调用的字符串参数被加密。图7显示了此方法的示例。

上图是通过反射调用替换getDir()方法的示例，然而，字符串参数已经被解密。

研究人员已将此阶段命名为invokeMethod，该方法的主要任务是验证参数并调用对应的类method.invoke（）。在新的示例中，与Geost使用的版本相比，这种方法要复杂得多。这是滴管程序的代码仍在不断发展以及该服务背后的参与者仍在投资于代码开发的主要证明之一。

两个版本在复杂性上的差异如图8到图11所示，图8显示了Geost的invokeMethod，而图9到图11显示了用于Locker的相同方法的代码。

Geost示例中的完整invokeMethod()

新示例中使用的invokeMethod()的第一部分

新示例中使用的invokeMethod()的第二部分

invokeMethod()的新版本中使用的invocationProcess()方法

虚假标志代码

在已经描述过的滴管代码部分中，虚假标志代码可能是最不重要的。尽管如此，值得注意的是，新样本发生了令人惊讶的变化。除了Geost示例中的HttpURLConnection类和方法符号之外，滴管中的所有字符串都是加密的，符号名称也都是被混淆的。在消除混淆之后，很明显，代码的相关部分也永远不会被执行。这可能是开发者设计的另一种转移注意力的策略，目的是将分析师的注意力转移到一个虚假标志代码上。这个虚假标志代码模仿命令和控制(C&C)打开序列，如图12所示。

Geost示例中的虚假标志

这段代码被放置在Geost示例的invokeMethod()中，还应该注意的是，较新的示例不使用HttpURLConnection类。相反，它们使用SQLiteQueryBuilder类和其他相关方法，在deleteFile()方法中放置虚假标志，如图13所示。

较新示例中的虚假标志

自动有效载荷解密

第一个阶段中的所有字符串以及有效载荷均使用RC4算法进行了加密，并且解密密钥已进行了硬编码。所有新的和旧的分析示例也是如此，也就是说，在找到密钥之后，这也允许脚本化的有效载荷解密和进一步分析。

幸运的是，找到密钥并不困难，因为有一个byte[]变量的声明，该变量具有包含所述密钥的立即初始化数组值。但是，除了一个byte[]变量之外，我没有找到另一个这样声明的示例。在声明时初始化的变量数组的其余部分为int类型，这些大多是字节数组初始化文字。尽管如此，它们直接作为字符串构造函数参数放置。

总结

对被自动混淆服务混淆的样本的分析证明，该服务背后的攻击者仍在对其改进进行努力。值得庆幸的是，代码中的更改似乎对混淆质量和最终检测率几乎没有影响。除了滴管程序代码的变化之外，插入的垃圾代码数量显著增加。包含有效载荷的文件通过标头的改变而变得丰富，这个可能是为了提高解密的可靠性或使有效载荷的解密更加复杂。有效载荷的位置和名称也已被更改，以模仿一组audio track文件。

尽管有这些变化，但新旧示例的特性使它们成为可能，而且很容易被解密。例如，目录和有效负载文件的固定名称使得对恶意文件的追溯变得简单。APK资源文件中存储的来自恶意有效载荷的字符串也使检测和回溯更加容易，因为这些字符串允许有效载荷进行分类。

然而，尽管存在这些缺陷，仍然有必要监控这种混淆服务的可能发展。被该服务混淆的数千个示例也证明了其可用性。毕竟，它很容易被使用，并且减少了检测混淆APK的机会。通过这种方法，攻击者成功地实现了隐藏恶意内容的主要目标。