3 AI检测安卓恶意软件

3.1 安全问题

Android恶意软件简单来说是一种旨在损害Android用户移动设备的恶意软件或代码,如病毒、木马、勒索软件、广告软件、间谍软件或钓鱼应用。这种恶意软件可以通过各种途径下载或安装,包括电子邮件中的恶意下载、访问可疑网站或点击来自未知发件人的链接。一旦恶意软件侵入Android用户的手机,它可以执行多种有害操作,包括窃取并出售您的敏感信息,监视您的手机使用,如短信、电话等,或者勒索要求支付赎金。

尽管Android用户的移动设备通过侧加载应用程序向攻击者敞开了攻击面,但应用市场如Google Play和Amazon AppStore仍在今天的移动生态系统中发挥着至关重要的作用,通过这些市场,大多数移动应用程序都被发布、更新和分发给用户 [33]。在应用程序被批准发布到应用市场(如Google Play、T-Market)之前,Android应用程序开发者首先将他们的新应用或更新后的应用上传到应用市场。为了获得批准,提交的应用将由应用市场分析,以确定它是否是恶意的。最终,审核报告将被发送回应用程序开发者,告知他们应用是被检测为恶意还是已获批准发布。

3.2 安卓恶意样本

在过去,Android勒索软件利用了一个名为"SYSTEM_ALERT_WINDOW"的特殊权限,该权限可以绘制一个窗口,无论按下哪个按钮,该窗口都会位于所有其他窗口之上。这些Android勒索软件故意滥用此权限来显示勒索通知,占据屏幕,使设备在用户支付赎金之前无法使用。

有关一种新的Android勒索软件变种的详细信息于2020年10月8日揭示[68]。基本上,为了发布其勒索通知,它联合使用“call”通知和“onUserLeaveHint()”来触发勒索屏幕。如代码3.1所示,恶意软件创建了一个通知构建器。setCategory方法用于使此通知需要立即用户操作。setFullScreenIntent方法将通知与图形用户界面连接,以便在用户点击时弹出。

为了持续占据屏幕并显示勒索通知,恶意软件需要调用勒索软件屏幕的自动弹出,而无需用户交互。如代码3.2所示,恶意软件重写了Activity类的onUserLeaveHint()回调函数。每当恶意软件屏幕被推到后台时,将调用回调函数,将呼叫活动带到前台。由于恶意软件已经使用通知类型设置为“call”挂钩了RansomActivity意图,已经形成了一系列的函数调用链,使得恶意软件能够占据屏幕。

3.3 用例的机器学习流程

由于深度学习未应用于本章,因此无法采用图1.1中显示的统一深度学习流程。在本用例中采用的机器学习流程是在[33]中提出的,并在图3.1中显示。从一个应用程序开始,通过基于Google官方Android模拟器[4]和Xposed Hooking框架[85]构建的动态分析引擎[33]提取其元数据。预期的元数据包括所请求的权限、调用的API和使用的意图。为了实现高UI覆盖率,动态分析引擎采用Monkey UI exerciser [74]在应用程序和系统级别生成UI事件流。有了这些提取的元数据,特征工程组件负责选择关键API集,以进行进一步的特征嵌入编码。随后,这些编码后的特征向量将由Random Forest机器学习算法用作训练数据集。经过交叉验证后,训练好的模型将在生产环境中部署进行在线测试。同时,将收集假阳性和假阴性以准备进行模型重新训练。在[33]中,定期重新训练的时间设置为一个月。在模型重新训练期间,新提交的应用程序和现有的应用程序数据集将经过上述整个流程,以获得适应不断发展的Android恶意软件的重新训练模型。

3.4 特征工程

在机器学习和模式识别中,特征是现象的个别可测属性或特性[8]。在模式识别、分类和回归的有效算法中,“选择信息丰富、具有区分性和独立的特征是至关重要的,而特征通常是数值型的”[27]。在通过动态API级别机器学习技术进行的Android恶意软件检测中,APIs(应用程序编程接口)被选为特征,用于训练机器学习模型,随后将用于将一个Android应用分类为恶意软件或非恶意软件。例如,如果在应用程序运行时调用了某个API,则针对测试的应用程序将记录此API的特征值为1,或者将其值设为0。

API规范是对开发者进行详细说明,指导其如何使用此接口来满足特定的需求或功能。其中一个作为特征选取的API是android.telephony.SmsManager sendTextMessage。该API专门负责发送基于文本的短信,其规范如代码3.3所示[66]。

特征工程是为了识别特征,更好地表示机器学习处理的目标问题,并进一步提高其准确性。它通常使用领域特定的知识或自动方法来提取、选择或构建正确的特征。对于这个Android恶意软件检测用例,实现高准确性的关键在于特征选择,而在[33]提出的方法中,本质上是API的选择。考虑到当前Android SDK提供了超过50,000个API,一个主要问题是是否应选择所有API。如[33]中所演示的,只需选择其中的一小部分API即可实现。实际上,选定了426个关键API作为特征。关于为什么只选择了一小部分API,主要原因如下:

  1. 由于该技术在测试应用程序的动态仿真过程中记录API的调用,所以选择的API数量将大大影响动态分析时间。

  2. 通过有选择地跟踪较小一部分API,可以实现更好的检测准确性,而不是跟踪所有50,000个API。

  3. 一些API在功能上互补,可以结合在一起以提高准确性。

3.4.1 理解API选择的权衡

理解API选择背后的洞察有三个方面:API与应用程序恶意性之间的统计相关性、动态分析的时间消耗、恶意软件检测的准确性[33]。

  • 基于对Spearman秩相关系数(SRC [51])的评估,选择了260个APIs,其中包括247个具有SRC ≥ 0.2和13个具有SRC ≤ −0.2。

  • 基于定量分布,通过跟踪不超过前490个APIs,每个应用程序可以实现平均少于5分钟的检测时间。

  • 通过使用随机森林分类器跟踪前n个相关APIs比较恶意软件检测的准确性,可以通过采用有效的策略跟踪更少的APIs来实现更好的精确度和召回率。

3.4.2 关键API选择策略

API选择有四个步骤:

  • 选择与恶意软件具有最高相关性的API(Set-C),从而得到前260个高度相关的APIs。

  • 选择需要受限权限的API(Set-P),其中包括112个APIs。为了确保用户信息的隐私/安全需求,应用程序需要被授予访问特定信息或执行特定功能的权限[83]。两个工具Axplorer [20]和PScout [22]可以用于进行选择。

  • 选择执行敏感操作的API(Set-S),其中包括70个已识别的APIs。选择是基于领域知识的,考虑先前用于实现攻击的敏感操作[13, 26, 90, 95]。

  • 将上述三者结合起来,得到总共426个关键APIs,即Set-P∪Set-S∪Set-C,如图3.2所示。

3.4.3 进一步丰富特征空间

由于存在某些关键API调用可以通过其他机制(如Java反射和意图)绕过的限制,这种“隐蔽”的API调用需要额外的缓解。考虑到在调用这些隐藏API之前,应用程序需要请求权限的事实[30],因此增加了两个辅助特征[33],分别是所请求的权限和已使用的意图。因此,加入这些额外的特征,可以实现最佳性能,即精度从96.8%提高到98.6%,召回率从93.7%上升到96.7%。

3.5 训练数据

在[33]中使用的应用程序数据集中有501,971个新的和更新的应用程序,这些应用程序是从2017年3月到12月提交到T-Market的。每个应用程序都由T-Market提供了一个恶意或良性的标签,这被视为地面真相。总共有463,273个良性应用程序和38,698个恶意应用程序在数据集中。

在机器学习中,特征向量基本上是一组特征。每个应用程序都有其自己的一组特征。不同的特征由不同的数值或符号特征值表示,多个特征值可以组合形成一个特征向量。为了进行处理和统计分析,机器学习算法通常需要数值特征向量[28]。采用Random Forest算法对应用程序进行恶意软件或非恶意软件的分类。在每个应用程序的动态仿真过程中,跟踪的API的调用状态(API调用的名称和参数)被记录下来。如代码3.4所示,每个仿真都被分配一个唯一的任务ID。例如,任务ID 20170718000003300对应于一个名为“meimeicaicaicai”的应用程序。采用One-Hot编码[33]将日志转换为包含总共n位的特征向量,其中n是跟踪的API的总数。如代码3.5所示,每一位对应于一个跟踪的API - 如果调用API,则相应的位设置为1;否则设置为0。

3.6 机器学习

随机森林是一种通过集成学习思想整合多个树的机器学习算法。其基本单元是决策树,如图3.3所示。决策树是一种树状结构(可以是二进制或非二进制)。每个非叶节点表示对特征属性的测试,每个分支表示特征属性在某个值范围内的输出,每个叶节点存储一个分类结果。使用决策树进行决策的过程是从根节点开始,在待分类的项中测试相应的特征属性,并根据其值选择输出分支,直到达到叶节点,然后使用叶节点中存储的分类结果作为决策结果。随机森林算法本质上是一种集成方法,可以有效减少过拟合。它基本上是从原始训练数据集中抽样出几个小集合,然后在每个小集合上训练模型。最后,对所有模型输出进行平均值(回归)或投票(分类)。

代码3.6显示了一个用于实现上述随机森林机器学习算法的代码片段。在[33]的实验中,模型的超参数是根据领域知识配置的,这些超参数包含在[33]作者创建的存储库中,将在第3.9.1节中简要提及。

3.7 模型部署

上述的机器学习流程是在[33]中提出的,被称为APIChecker。自2018年3月以来,APIChecker已经部署并运行。它能够使用一个单一的普通服务器,同时在16个核心上运行16个模拟器,每天检查大约10,000个应用程序。具体而言,它将一个应用程序的APK文件作为输入,该文件将安装在一个空闲的Android模拟器上。然后,APIChecker运行应用程序并记录所有进行特征工程所需的信息。最后,应用程序的恶意性将由随机森林分类器确定。整个过程平均耗时1.92分钟,应用程序安全分析占用1.4分钟。在2018年3月到2019年2月的12个月内,APIChecker每月检测到大约2,400个可疑应用程序。检测结果的示例可在代码3.7中看到。

准确性结果表明,通过这12个月,每月的精度都超过98%(最小:98.5%,最大:99.0%),召回率都超过96%(最小:96.5%,最大:97.0%)[33]。在后续工作中[34],他们更新了部署,如图3.4所示,而不是原始的单片式的背靠背执行序列。

3.8 系统评估

系统需要不断演进,具体来说,是以一个月的周期更新所选的关键APIs。有两个原因,一是新的应用程序不断添加到T-market的数据库中;另一个是API本身的更新,因为Android SDK每隔几个月就会进行定期更新[33]。

3.9 代码、数据和其他问题

[33]的作者已在https://apichecker.github.io上发布了他们选择的关键Android API列表,部分分析日志以及他们实现的高效仿真器。

3.9.2 其他问题

APIChecker对复杂攻击者有多么健壮? 根据对Android SDK(级别27)源代码的扫描,选择的关键API的计算使用范围可以覆盖高达5,242个(10.5%)APIs[33],即使是经验丰富的攻击者也很难逃避APIChecker的检测,如果不是不可能的话。 我们是否可以进一步减少关键API的数量? 基于使用所有426个关键API实现的类似检测性能[33],仅通过跟踪排名前150位的高排名关键APIs也能实现,似乎可以进一步减少关键API的数量。同时,每个应用程序的分析时间也减少了。 APIChecker是否可以被其他应用市场使用? APIChecker中使用的所有技术都可以合理地应用于其他应用市场。

3.9.3 相关工作

在现有的工作中有很多基于机器学习的技术,包括但不限于基于权限的足迹检测方案[96]、静态分析[1, 5, 29, 35, 83]、动态分析[11, 26, 82, 84]。由于这些解决方案在市场规模部署时缺乏实际的着陆经验和有效性评估,[33]的作者提供了他们在主要的Android应用市场——腾讯应用市场中构建和部署基于机器学习的方法的经验。 为了使基于机器学习的恶意软件检测系统在市场级别可靠运行而不会导致平均应用程序运行时的显着开销,[33]的作者采用以API为中心的分析方法,重点关注API特征选择和应用程序运行时分析的减少。他们提供了创新性的关键API选择策略和优化的动态分析引擎。最后,他们商业化部署了他们的解决方案并及时更新了机器学习模型。

Last updated