银行手机木马分析 – 作者:Kriston-安全小百科

Android银行木马Geost是最初监视HtBot恶意代理网络检测到的。该僵尸网络以俄罗斯银行为目标，受害者人数已超过80万。该木马使用了混淆，加密，反射和注入非功能代码等方法使逆向分析更加困难。

初步分析

Geost隐藏在随机生成的服务器主机名非官方网页中，利用恶意应用进行传播。受害人在寻找Google Play找不到所需应用或无法访问应用商店时通常会在一些不起眼的Web服务器上找到该应用的链接，下载应用程序然后启动。应用程序将请求权限，如果受害者允许，则可以启用恶意软件。

Geost样本嵌入在俄语名为“установка”的恶意应用中，该应用程序显示了一个Google Play图标。

启动应用程序时，它要求设备管理员特权，用户可能在不知不觉中允许重要权限包括访问SMS消息。攻击者可以访问银行应用程序，收集受害者的姓名，余额和其他银行帐户详细信息。只需单击几下，攻击者便可以从受害者的银行帐户中转移资金。

确认必要的权限后，应用程序自我隐藏，并隐藏应用程序图标使受害者认为该应用已被删除。恶意软件一直在后台运行，攻击者获得设备访问权限，可以监视已发送和已接收的消息，包括来自银行的SMS确认消息。为了在重新后启动，它会注册BOOT_COMPLETED和QUICKBOOT_POWERON广播。

第一阶段

与许多恶意软件一样，Geost运行分为多个阶段。第一阶段是下载解密并运行第二阶段，第二阶段将变得更加复杂。

Geost示 APK在的classes.dex文件中包含已编译的Java代码，还包含AndroidManifest.xml和资源文件，还有一个大小为125k的“ .cache”文件。

第一阶段中所有字符串都通过R**加密，该算法被拆分为多个函数以避免表明它使用了R**。下一步就是找到用于R**解密的密钥。

R**密钥：
R**内部状态随每个解密的符号而变化，通常必须与加密相同的顺序解密。但本样并非如此，R**加密代码始终复制数组S []，编写者简化了R**不保留解密之间的内部状态。

搜索通用代码库，发现Android.support.v4库和ReflectASM Java Reflection库。

第一阶段使用相同的R**算法和密钥解密第二阶段的文件，反射方法调用：

“ .cache”文件被重命名为.localsinfotimestamp1494987116，在解密后另存为ydxwlab.jar，从中加载并启动.dex文件。

代码作者插入错误标志HttpURLConnection及其URL，该URL已连接到命令和控制（C＆C）服务器，但是此http连接永远不会执行。错误标志：

第一阶段在第二阶段开始部分加载一个类，其名为“ MaliciousClass”。

第二阶段

c第二阶段中再次使用了混淆和加密，符号名称部分替换为长度为1-2个字符的字符串，不是6-12个字符串，修改了字符串加密算法。此外，针对每个类别分别修改了解密算法的参数。

每种类的解密算法都有不同的参数顺序和不同的常量。

字符串解密后，可以检测到所使用的库：

AES加密

Base64编码

仿真环境检测

文件下载服务

IExtendedNetworkService

USSD API库

Zip4jUtil

初始化阶段

第一阶段调用的MaliciousClass充当实例化类的envelope，研究人员命名为“ Context”。

Context类首先启动EmulatorDetector服务。然后将启动AdminService和LPService，然后启动主应用程序Intent。

仿真环境检测

检测器会检查其是否在仿真环境中运行，样本可检测Nox，Andy，Geny，Bluestacks和Qemu Android仿真环境。

AdminService

该服务负责向应用程序授予管理员权限，可以访问敏感数据并启动特权操作。

LP服务

该服务负责保持应用程序运行并连接到C＆C服务器。

LPService创建LPServiceRunnable线程，该线程每五秒钟唤醒一次，负责监视和重新启动以下服务：

MainService

AdminService

SmsKitkatService

MainService

MainService首先挂接到AlarmManager，然后注册两个广播接收器MainServiceReceiver1和MainServiceReceiver2。在初始化阶段结束时，它将启动MainServiceRunnable Thread。样本执行onDestroy方法时，将再次重新启动MainService。

MainService中processApiResponse()处理从C＆C服务器接收的JSON字符串命令。