基于AI+大数据技术的恶意样本分析（一）

阅读Enhancing State-of-the-art Classifiers with API Semantics to Detect Evolved Android Malware翻译及笔记

使用API语义增强最先进的分类器来检测不断发展的安卓恶意软件

论文出处：CCS ’20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications SecurityOctober 2020 Pages 757–770
原文链接

摘要

关键字 ：

进化的恶意软件检测，API语义，模型老化

1、介绍

机器学习(ML)分类器在实践中被广泛应用于检测安卓恶意软件，并取得了惊人的性能。尽管取得了成功，但在恶意软件检测中应用ML的一个新兴问题是恶意软件的发展，以增强功能和避免被检测到，从而导致随着时间的推移，ML分类模型的性能显著下降。这个问题被定义为模型老化或类似的概念，如时间衰减[39]、模型退化[24]和恶化[9]。模型老化是严重的：2019年卡巴斯基的一份白皮书[23]显示，一种基于ml的商业分类器的检出率在短短三个月内就从近100%急剧下降到80%以下，在另一种配置下甚至是60%。

考虑到老化问题的严重性，先前的工作提出了检测模型老化和提高恶意软件分类器性能的方法。例如，DroidOL[37]和机器人[49]通过在线学习不断引入新的恶意软件样本。另一个例子是，超越[21]检测模型老化的早期信 ，并对模型进行再训练以进行改进。在超越之后，[39]引入了主动学习来选择一小组具有代表性的进化恶意软件样本进行改进。然而，尽管之前的工作可以逆转老化和改进衰减的模型，底层模型仍然在很大程度上没有意识到恶意软件的进化，特别是进化的恶意软件之间的语义。不出所料，他们需要成千上万的带有标签的新恶意软件样本来让底层模型开始进化，这涉及到在标记方面的大量人工工作。

具体来说，我们设计了一个框架APIGraph，基于官方文档中提供的信息并从官方文档中提取，构建所谓的Androidapi关系图。图中的每个节点表示一个关键实体，如API、异常或权限；每条边表示两个实体之间的关系，例如一个API抛出异常或需要权限。然后，APIGraph通过将每个API实体转换为集群并将类似API进行嵌入，从关系图中提取API语义。以API集群格式提取的API语义可以进一步用于现有的Android恶意软件分类器中，以检测进化的恶意软件，从而减缓老化。

我们将APIGraph应用于之前的四个安卓恶意软件分类器，即MamaDroid[32]、机器人[49]、Drebin[3]和Drebin-DL[18]，并使用自己根据现有指南[39]创建的数据集对它们进行评估，[39]包含从2012年到2018年超过322K的安卓应用程序。我们的评估显示，APIGraph结合上述四种恶意软件分类器可以显著减少标记努力，即根据分类器的不同，从33.07%到96.30%。我们还测量了Tesseract提出的新度量时面积(AUT)，并在APIGraph的帮助下显示模型老化显著减缓。

• 论文表明，尽管安卓恶意软件会随着时间的推移而进化，但许多语义仍然相同或相似，这让我们有机会在进化后检测它们。
• 论文提出在关系图中表示AndroidAPI的相似性，并设计一个系统APIGraph来构建API关系图并从关系图中提取语义。

图2：一个说明性的关系图，演示了APIGraph如何捕获图1中不同版本的XLoader的语义。

接下来，我们将解释APIGraph如何在发送PII方面捕获三个不同版本的XLoader之间的语义相似性，从而帮助使用V1训练的ML分类器检测进化的V2和V3。图2显示了由APIGraph构建的关系图的一小部分，它捕获了Androidapi、权限和异常的相互作用。所有三个api——即打开连接、SocketFactory.createSocket和ssl。SSLSocketFactory.createSocket-抛出IOExcepet和使用互联 权限；这三个api中的两个共享更多的异常和权限。也就是说，这三个api在关系图中的邻域上足够接近，可以在一个聚类中聚在一起。因此，ML分类器在关系图的帮助下，可以捕获V2/V3和V1之间的相似性，并在进化后检测出V2和V3为恶意软件。

2.2系统架构

图3显示了APIGraph的整体架构，它构建在一个被称为API关系图的概念的中心部分之上，该概念捕获了所有AndroidAPI的语义意义和相似性。APIGraph有两个主要阶段：(i)构建API关系图，和(ii)利用API关系图。首先，APIGraph通过收集与某个API级别相关的AndroidAPI文档并提取实体——如API和权限——以及这些实体之间的关系来构建一个API关系图。

其次，APIGraph利用API关系图来增强现有的恶意软件检测器。具体来说，APIGraph使用图嵌入算法将关系图中的所有实体转换为向量。这里的见解是，嵌入空间中两个实体之间的向量差反映了关系的语义意义。因此，APIGraph通过求解一个优化问题来生成所有的实体嵌入，使其具有相同关系的两个实体的向量相似。然后，APIGraph将嵌入空间中的所有API实体聚类，将语义上相似的API聚在一起。这些API集群被进一步用于增强现有的分类器，以便它们可以在检测过程中使用某些API级别捕获Android恶意软件的语义等价进化，从而减缓老化。

3、设计

在本节中，我们首先定义关键概念，即我们的API关系图，然后描述如何构建和利用这个API关系图。
一个API关系图=<，>被定义为一个有向图，其中是所有节点（称为实体）的集合，而是两个节点之间的所有边（称为关系）的集合。API关系图是异构的，即有不同的实体和关系类型。

实体类型。 API关系图中有四种实体类型，它们是Android中的基本概念：方法、类、包和权限。前三种实体类型是组织Java程序的关键代码元素，最后一种描述了AndroidAPI在执行期间所需要的资源。这四个实体一起提供了足够的能力来捕获api之间的内部关系。

关系类型。 我们按照之前的工作[25,30]提供的关系分类法定义了10种关系类型，它涵盖了关于API配置文件的不同信息。这十种类型的关系，如表1所示，也被总结为五类，如下描述。

• 组织类别描述了不同实体之间的代码布局关系。考虑到这四种实体类型，我们定义了class_of关系连接类实体与其所属的包实体，function_of关系连接方法实体与其所属实体的类实体，继承关系连接类实体与其继承的类实体。
• 包括三种类型的关系：uses_parameter、返回、抛出关系，它们反映了一个方法实体，可以分别使用一个类实体作为其参数、返回值或抛出的异常。
• 用法类别指定如何使用API。我们关注这种关系的两种类型：条件关系指定一个方法实体对另一个方法实体的条件使用，例如，一个API只能在调用另一个API后使用；替代关系描述一个方法实体可以被另一个方法实体取代。
• 引用类别具有一个refers_to关系，它描述了两个实体之间的一般关系。例如，API文档在使用诸如“请参见……”这样的句子来描述一个方法实体时，可以引用另一个方法实体。
• 权限类别包含uses_permission关系，描述方法实体可能需要的权限实体的关系。

为了构建API关系图，我们需要提取上述类型的实体和关系。在本节的其余部分中，我们将首先介绍AndroidAPI参考文档的组织结构。然后，我们描述了如何从这些文档中提取不同类型的实体和关系。

表1：在APIGraph中定义的关系类型。

3.2 API文件收集

APIGraph从官方 站1下载所有平台API的API和API参考文档。每个Android版本都有相应的API级别，例如Android10的API级别为29。APIGraph抓取API级别14到29的文档，它们对应于Android4.0到android10，它们是目前主要的活跃安卓版本。

AndroidAPI参考文档是分层组织的。从顶层到底层，都有一些软件包、类和方法。API文档是在类的级别上给出的。每个类都有一个HTML文件来描述基本的类层次结构信息，以及这个类中所有方法的详细文档。图4显示了安卓电话文档示例。电话管理器和一个方法得到了()。文档可以分为两部分：1)结构化信息，包括类配置文件和原型、方法的返回值和抛出的异常；2)几种文本格式的非结构化描述，其中描述了API的功能、需求和指令。

3.3 实体提取

在我们的API关系图中有四种实体类型。我们通过以下方式从文档中提取这些实体类型：

• 首先，由于API文档是按类组织的，因此APIGraph从每个类的文档文件中提取一个类实体。如图4所示，一个类的名称是用结构化的文本来描述的。
• 其次，APIGraph通过将包名从完整的类名中拆分来提取包实体。
• 第三，APIGraph将每个类的文档文件解析为文档对象模型(DOM)，然后提取属于一个类的方法实体。
• 第四，APIGraph解析清单文件2，其中列出了提取权限实体的所有权限。

表2：提取4种关系类型的模板，其中“ENT”表示一个实体。

3.4关系提取

如前所述，由于一些关系，如class_of关系，是组织成结构良好的HTML元素的，而一些关系，如refers_to关系，是嵌入在非结构化文本中的，因此我们采用两种方法从API文档中提取关系。

3.4.1 关系从结构化文本中进行解析。根据表1中定义的关系类型，文档中在结构上描述了6个关系。APIGraph通过直接的文档解析来提取这类关系。以下是详细信息。首先，APIGraph在提取类、方法和包实体的过程中提取function_of和class_of关系。其次，APIGraph从每个类文档文件中的类概要文件部分中提取继承关系。最后，APIGraph提取uses_parameter，返回并在每个方法的原型部分抛出关系。

3.4.2 从非结构化文本中获得的基于3.4.2模板的关系匹配。APIGraph在NLP（自然语言处理）技术的帮助下，使用基于模板的关系匹配方法提取四种类型的关系，即条件、替代、refers_to和uses_permission。请注意，APIGraph还从现有工作[4,5]生成的两个API权限映射中提取uses_permission关系，以补充从API文档中提取的关系，因为AndroidAPI文档中的这些信息可能是不完整的。一般来说，基于模板的关系提取有三个步骤：(i)手动形成匹配模板，(ii)模板集的迭代扩展，(iii)nlp增强的模板匹配。

手动制定匹配的模板。 在此步骤中，我们将手动检查1%的API文档，以调查用于描述这些关系的模式。表2给出了几个正则表达式格式的示例模板，这些模板是手动制定的，以匹配来自非结构化文本的关系。例如，模板“参见ENT”匹配当前方法实体和ENT实体之间的refers_to关系。模板集的迭代扩展。在这一步中，APIGraph采用了一种半自动的策略来迭代地制定关系匹配的模板。本过程中有三个子步骤，如下所述：

• 首先，我们随机选择1%的api并收集它们的文档。
• 其次，我们使用现有的模板集，利用NLP技术从这些文档中提取关系（请在下一段中解释）。
• 第三，在匹配完成后，我们手动检查是否存在现有模板集未捕获的关系。如果答案是肯定的，我们将手动为它们制定模板，并从第一步开始重复。否则，APIGraph完成制定模板以提取所有api的关系。

在上述过程的指导下，模板集在手动查看5%的API文档后收敛。最后，我们总结了217个条件、备选、refers_to和uses_permission关系的模板。表2显示了每个关系的模板编 。整个模板构建过程需要两名安全专家大约三天左右。请注意，Android文档随着时间的推移是稳定的。例如，只添加了1.4%的（834）api，1.6%的（989）api将其描述从API_level28更改为29，并且所有新添加或更改的描述都不需要额外的模板。

nlp增强模板匹配 。APIGraph通过两个步骤将模板与非结构化的API文档进行匹配。首先，APIGraph将段落分成句子，然后通过以下方法对每个句子进行预处理：

• stemming。APIGraph将每个单词简化为它的基本形式，例如，“需要”和“需要”被定义为“需要”。
• 共同参考解决方案。APIGraph采用基于声明的共引用解析[25]，将所有的代词解析为基础实体。例如，句子“这个方法需要互联 许可”中的“这个方法”被解析为句子所属的方法。
• 实体名称规范化。APIGraph通过遵循到其原始定义的超链接来替换所有多态名称的精确值，以便APIGraph使实体的表示规范化。例如，这个名字是机器人。清单。权限。互联 和它的恒定价值”。文件中都使用：APIGraph用后者取代前者。

其次，APIGraph将所有模板与API描述中的每个预处理句子进行匹配。如果找到了与模板的匹配，那么APIGraph就会从模板指定的句子中提取关系。如果一个句子不能与任何模板匹配，APIGraph将删除该句子。

3.5利用API关系图

为了利用API关系图，APIGraph将把关系图中的每个API转换为一个嵌入表示，然后将这些嵌入分组到集群中。API嵌入的概念是受单词嵌入[36]和图嵌入的启发，是将关系图中的每个API转换为一个向量，表示其语义意义。我们的转换算法（见算法1），利用先前称为TransE[8]的算法，并将TransE拟合到我们的关系图问题中，描述如下：

(1) APIGraph提取权限实体，并基于公共权限添加新的关系（第3-5行）。这里的直觉是，Android中的权限保留语义，而APIGraph更关注权限。

(2)APIGraph将每个API实体∈（第6-7行）和每个关系∈（第8-9行）分别嵌入向量，∈R。

(3)APIGraph应用TransE算法（第10-14行），在三元组集中对每个三元组（，）的∥22进行最小化，其中是实体，是一个关系。这里的直觉是，如果两个头实体，与一个共同的尾实体有相同的关系，那么它们的嵌入物，应该很接近。

(4)APIGraph使用k-Means将API嵌入到不同的组中，并通过Elbow方法[43]确定集群数。

在APIGraph成功聚类api后，APIGraph采用聚类，特别是每个聚类中心的嵌入，来表示集群中独立api的语义。

结果：我们在表8中显示了应用APIGraph前后的四种评估分类器的结果。这里有两件事值得注意。首先，每个分类器带有APIGraph的AUT都高于没有APIGraph的AUT。这表明，APIGraph确实可以减缓四种不同分类器的模型老化，无论它们是否感知进化。其次，使用APIGraph增强的模型的老化减速是显著的：例如，在增强drovolver后，只有1%的应用的再训练比原始分类器的50%的再训练获得更好的性能。