2018年，FortiGuard安全实验室发现了一场针对日本用户的恶意软件行动，攻击者通过将自己伪造成一家物流公司来传播Android恶意软件“FakeSpy”。

FortiGuard一直对此行动保持密切关注，直到最近，攻击者创建的钓鱼网站中开始出现了新的Android恶意payload。

此次出现的payload像往常一样，由封装程序和payload组成，但这两者与我们以往遇到的都不同。以我们的经验来看，这是一类新的恶意软件，很可能是由活动背后的同一个人开发，用以替代他们已经“太过出名”的FakeSpy恶意软件。根据在payload的持久性机制中找到的日志字符串（如图7），我们决定将这个新的恶意软件系列称为FunkyBot。

我们分析的样本为：152be211ecd21c8abfd7c687a5ca8a17906f589c59055516e5482ff3fc。

封装器

封装器由两个独立的部分组成：

· classes.dex文件中的Java代码

· libcsn.so文件中的本地代码

Java函数

样本中的封装器代码是经过混淆的，不过经过一些搜索，我们还是找到了一个未混淆的版本。

封装器样本是：b4f3b7850c4332bcf85bbd64ebd6d837a3de64a03c1150cdd27e41599d2852b6。

它执行的第一个的函数是_attachBaseContext（Context base）。此函数访问APK资源文件夹中的配置文件——一个名为“_dcfg_.data”的JSON文件，并加载以下参数：

· “size”：确认封装器生成后缀为“.dex”的payload数量

· “payloadType”：标识payload的加密数据所在的位置

· “isTestIn”：用于测试的标志

· “type”：标识所使用的加密类型

在分析样本中，我们发现了以下两种配置：

· {"size":2,"payloadType":0,"isTestIn":"0","type":3}

· {"size":2,"payloadType":1,"isTestIn":"0","type":3}

封装器会确定运行的Android版本以生成适当payload，还会生成一些假dex文件干扰分析。

图1：创建假Dex文件

接着检查'payloadType'值，如果等于1则将资源数据复制到另一个文件夹；否则将在不移动任何东西的情况下继续运行，因为它使用了加载在内存中的classes.dex文件。

图2：Dex加密文件的提取

JNI函数

JNITools类声明了一组包含在libcsn.so中的本地函数。

图3：JNITools本地函数声明

本地JNI_OnLoad函数在加载库时运行。它注册在JNITools中声明的本机函数，允许以不同于Java_<className>_<FunctionName>的常规方案进行调用，这可能会增加逆向过程的难度。

如果配置变量'type'的值不等于0（意味着payload需要解密），代码将访问文件夹/data/data/<appname>/app_csn0/并在其中创建一个文件夹”.unzip”，需要注意的是，该文件夹的名称中的第一个字符是一个点，普通的ls命令会对其不可见。

解密例程在从加密payload数据生成的文件上运行。根据'payloadType'的值，该数据来自以下两个来源之一:：

· 0：'classes.dex'文件，包含所有已执行的代码

· 1：资源文件，在本例中为assets / csn-enc.data

在第一种情况下，封装器访问/ proc / <pid> / maps文件，找到加载classes.dex文件的内存，然后在内存中查找标识加密数据开头的特定字符集。在本例中，魔法词是`csn_`。找到后，它会从该点开始复制。

图4：搜索'csn_'

配置变量“type”的不同值对应于不同的解密例程。代码支持以下值：

· 0：没有加密

· 2/3：用值“0x51”（81）基于XOR解密的变体

图5：解密选项

在此样本中，配置的值始终为3，对应于以下解密函数：

图6：类型3

最后解密例程都会生成一个由类加载器加载的“classes.dex”payload文件。

Payload：FunkyBot

在分析样本中，payload由两个.dex文件组成。一个是恶意软件冒充的原始合法应用程序的副本，另一个是恶意代码。

通过Java反射调用方法`runCode` 类`com.wfk.injectplugin.EntryPoint`来启动payload。此方法首先启动`KeepAliceMain.start()`。

图7：EntryPoint

KeepAliceMain

此类用作恶意软件的持久性机制。它使用的是在Github上找到的开源库，使设备上的服务保持活动状态；还允许恶意软件静音设备，不过我们观察的当前样本中没有使用此功能。

此类能定期重新启动恶意软件的主要服务，创建与远程服务器的gRPC连接。

GRPC客户端

C2地址

服务器地址没有硬编码在' classes.dex '文件中，但会在执行期间进行检索——通过函数`GprcsUtils.Regist_Server(String str)`调用`UrlTool.loadIPAddrFromIns()`来提取C2的 URL。

图8：加载来自Instagram的IP

此恶意软件使用社交媒体来获取其C2：首先下载一个没有照片的Instagram帐户的网页，然后提取此帐户的档案字段，并使用Base64对其进行解码。

图9：假Instagram帐户

最后，使用DES解密生成的字符串，并使用值“d2a57dc1d883fd21fb9951699df71cc7”作为其种子（恰好是对应于单词'app'的MD5哈希）生成密钥，这可以在字符串下的图8中看到变量str3。

生成的URL为149.28.24.166:11257，我们已向Instagram进行了报备。

短信服务

启动与服务器的连接后，恶意软件会继续收集并发送有关设备的以下信息：

· IMEI

· IMSI

· 电话号码

· 联系人列表

能滤出的信息的数量相对有限，特别是与像Anubis、Cerberus、Hydra之类的较大的勒索软件家族相比时，不过在传播技术上，FunkyBot跟后者们一样先进。

在将设备的所有联系人发送到C2之后，C2再以短信形式将恶意链接发送给受害者的联系人。这种策略已在多种恶意软件行动（比如FakeSpy和MoqHao）中使用过，能使恶意软件以类似蠕虫的方式传播。因此，假设该样本也是通过该类方式进行传播的猜想是合乎逻辑的。

另外值得注意的是，此恶意软件能够识别SIM卡的提供商，并将目标专门锁定在了日本几家移动供应商上。这么做需要先检查设备的IMSI值，该值由两部分组成：第一部分标识供应商，第二部分标识设备唯一值。恶意软件检查值的前半部分是否与供应商列表相对应。

图10：检查设备供应商

一开始我们认为，攻击者之所以这么做是为了针对特定运营商的用户。检查供应商的函数 `is<Provider>()` ，如果返回的是true，那么恶意软件只会继续增加短信发送最大数量的值。

经过一些研究后我们得出结论，这种行为可能只是因为这类供应商的用户之间发送短信是免费的，能够避免让用户产生怀疑。

最后，恶意软件能够将自己设置为默认的SMS处理应用程序，并荣国它将所有收到的消息上传到C2。考虑到目前大多数银行都通过SMS使用双因素身份验证，此功能可能非常危险。

结论

在分析过程中，我们还遇到了其他未完全开发的样本，表明该恶意软件目前正在开发测试的阶段。

目前这款恶意软件体现出的能力有限，但进步的速度也非常快，其之后的影响力也不应被低估。

IOC

封装器:

b4f3b7850c4332bcf85bbd64ebd6d837a3de64a03c1150cdd27e41599d2852b6

152be211ecd21c8abfd7c687a5ca8a17906f589c59055516e5482ff3fcf42dbf

Payloads:

02036825d69208612fd281b3d4fd9be06fc315addeac1fe8872eb2cc9f6f1fcd

beb6cb245f6597b6d2b9e9232774329b94f2eada5980a3cb28f9100cc161f4a4

CCs:

149[.]28[.]24[.]166[:]11257

108[.]61[.]187[.]156[:]11257