Acing the IOC Game:Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence

论文作者：Xiaojing Liao , Kan Yuan , XiaoFeng Wang , Zhou Li , Luyi Xing , Raheem Beyah

引用格式：Liao, Xiaojing, et al. "Acing the ioc game: Toward automatic discovery and analysis of open-source cyber threat intelligence." Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016.

论文链接：Acing the IOC Game: Toward Automatic Discovery and Analysis of Open-Source Cyber Threat Intelligence

摘要

为了应对迅速发展的网络威胁，安全专家们正在通过公共资源(如博客、论坛、推特等)积极交换IOC(如恶意软件签名、僵尸网络ip)。将这些IOC信息转化为机器可读的格式并部署到各种安全机制中，将为网络防御提供一定的情报支持。但由于在真实环境中IOC的来源成千上万，速度和数量的增长速度都十分恐怖，这给人们的管理造成了巨大的挑战。此外，网络安全领域新名词、新领域出现速度快，且不以常规构词方式出现，使得现有的NLP技术无法直接应用到的该领域，即使可实现部分应用，也无法满足IOC直接作为防御系统输入的高标准。

论文提出一种可以实现IOC全自动提取的解决方案，名为iACE。该方案基于技术文章中的IOC常以可预测的方式加以描述这样一种观察，即：IOC常通过固定的语法关系与一系列上下文 term连接。利用上述观察，iACE的设计思路是：首先在一篇文章中定位一些句子，这些句子都将包含一个假定的token（如：一个zip文件）及其上下文（如“malware”、“download”），然后应用一种新的图形挖掘技术进一步分析两者间的关系。一旦发现token间的语法连接与IOC通常的呈现方式一致，就提取这些token来生成OpenIOC item，这些item的描述将不再单单只是indicator，还包括其上下文。

从45个技术博客上收集了71000篇文章，iACE以95%的精确率和超过90%的召回率生成了900K个OpenIOC item，这已经远超出当前最先进的NLP技术和行业IOC工具可以达到的性能，而且其速度是每小时数千篇。通过对过去13年发布文章的提取结果进一步分析发现，数百个看似无关的攻击实例之间实际是有关联的。

1、引言

根据Gartner的对网络威胁情报（CTI）的定义：evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject’s response to that menace or hazard。威胁情报情报所携带的信息对于组织获得对快速演变威胁的可见性、及时识别攻击的早期迹象以及对手的TTP、有效使用适当遏制攻击的手段都是至关重要的。

CTI常以IOC的形式的出现，主要表现为：病毒签名、僵网的ip/域名、攻击文件的MD5 hash等。一旦收集到这些IOC就可以根据相关情报共享标准（OpenIOC、STXII等）进行格式化，进而完成对各类复杂攻击的描述。完成IOC转换后再将其放入各种防御机制以提升其防御性能。

但是在线发现IOC存在诸多挑战，主要包括以下几点：

（1）传统的IOC可以从一些网站(如：CleanMX和PhishTank)提供的黑名单中获得，但这些IOC所携带的信息相当有限，且无法直接应用于分析网络攻击活动；

（2）IOC向标准化格式转化多由分析师手动完成，但随着多源信息数量及速度的增长，管理和分析成本已超出人们的可接受效益范围；

（3）在自然语言文本中自动收集IOC也是一个挑战，因为如网站提供的IOC那样去获取一个“类IOC”的字符串，而不考虑其所处上下文，常常会导致假阳性；

（4）现有的NLP技术要直接应用于IOC及其上下文地发现是很困难的，这个过程主要使用的技术有NER和RE，而NER系统是具有高度领域依赖的，即在某一领域训练的模型很难在另一个领域上很好地工作。

（5）当前研究两个实体间的关系常常是共通的，但是IOC及其上下文item之间的关系是更加复杂的。

（6）当前没有专门用于IOC识别的NER工具，而直接使用现成的工具会导致较低的精确率和召回率。

上述问题都是IOC当前所面临的现实问题，iACE（IOC Automatic Extractor）根据发现IOC过程中的一些特性对NLP技术进行裁剪，实现ioc的自动提取。一个从开源情报信息生成高质量IOC的重要观察是：技术文章或推送趋向于用一种简单、直接的方式来描述IOC，使用一系列固定的上下文词汇（如：“download”，“attachment”，“PE”，“Registry”等），这些词汇都与OpenIOC中用于标签IOC类型的iocterm有关，而且这些术语与它们相应的IOC之间的语法联系相当稳定。这样的语法关系就可以让我们来标识IOC及其上下文token，并将NER和RE进行组合，也就提出了iACE。

iACE的设计思路是：使用topic-term分类找到那些可能涉及IOC的主题并将图表转换为文本后，利用一组正则表达式和常的上下文term提取文章中包含明显IOC token的句子。在这些句子中建立一个IOC token与上下文term之间的关系，具体方式是：将每个句子转换为一个依赖图来描述其语法结构，提取连接每一对上下文token和明显IOC token的最短路径，在每一条路径上应用图形挖掘技术来分析token之间的关系以确定它们是否确实包含IOC及其上下文。这样的方法是利用已知的“锚”来定位潜在携带IOC的句子及其可预测的关系来最终获取IOC，这避免了使用NLP技术时要实现NER任务才能完成RE任务的复杂操作。

利用iACE对45个博客收集的71000篇文章进行分析，总共提取了900K的IOC token,作者还有几个重要发现:（1）一些看似不相关的攻击实例实际上是连接在一起的，共享室内外的攻击资产和基础设施；（2）攻击者会根据IOC的发布调研其策略，例如密集报告的IOC往往生存期很短；（3）官方组织对发布的IOC反应不迅速，AV扫描仪需要2天才将恶意软件的hash包含进去，web扫描仪超过12天才更新其域名和IP黑名单，而这些操作都是在信息被博客公布后进行的；（4）就开源情报的质量而言，Hexacorn和Naked Security经常会提供关于新攻击及时而全面的信息。

2 背景

2.1 网络威胁情报

2.1.1 CTI

关于CTI的相关定义在引言部分进行说明，本部分主要涉及CTI的收集。CTI的来源可以是封闭的（如：内部网络IDS），也可以公开的（如：技术博客、论坛、开源网站）。本文所做研究的数据来源，是联系一家安全公司获得的45个博客列表，对这些博客进行监控并下载多达71000篇文章。使用的IOC标准框架是OpenIOC框架。

2.1.2 OpenIOC框架

OpenIOC是一个可扩展的XML模式，由Mandiant创建，用于记录识别已知威胁、攻击者的方法或其他攻击证据的技术特征。下图就是一个使用OpenIOC来描述Alina的例子。

OpenIOC的描述包括两个组件:一个头部和一个定义部分。报头部分有攻击的摘要(在description标签下)和信息来源(在authored_by和authored_date下)。定义部分包含一组Indicator term(在Indicator Item下)，每个Indicator item表示一个IOC(content)及其上下文(context)。其中，context下的document属性给出了IOC的主要类别(例如，进程、事件、文件、注册表等)，而search使用iocterm详细说明了它的子类别，本质上是安全专业人员用来描述IOC的通用术语(例如，进程、名称等)的连接。

2.2 信息抽取

本文为实现IOC的自动收集，利用了一套NLP技术。但据在线发现IOC挑战章节的介绍以及开放问题的特殊性，一般的信息提取技术不能很好地完成该任务，因此本文采用了图挖掘技术来分析上下文item与IOC锚点间的关系。使用到的技术主要有依存解析、内容项提取、图挖掘。

依存解析：是一种描述句子中词语之间语法关系的自然语言技术，关系包括 direct object, determinant, noun compound modifier等。此外，还将进一步分析关系子句的内容以确定子句包含的单词间的依存关系。使用“type(word1-index1,word2-index2)”的形式表示词语之间的二元关系，type表示两个词之间的关系，index1和index2分别表示单词在句子中的位置。将一个句子中的依赖关系可以形成一个有向加权图(V,E,W)，每个token是一个顶点，token间的关系由一组边表示，为连接两个token间的边分配一个权重来区分不同边之间的关系。图2给出了句子的依存解析例子。

内容项提取：本技术的主要应用是自动确定给定文本段中的重要术语，主要包括词性标注（标记与特定词性对应的单词）和短语解析（将句子划分上逻辑上属于一起的短语）。从给定的内容中解析短语后，POS标记器会给它的假选术语贴上标签，然后使用统计方法对候选项进行分析以找出重要术语。

图挖掘：本文通过裁剪图挖掘技术来分析由感兴趣的句子组成的依存关系图，其目的是识别图的可区分特征。将本文的问题当做一个分类问题，那么图分类问题的目标就是学习模型f: D->c来预测任何图的类标签，即：根据与其他图的相似性进行分类。

3 iACE的设计与实现

iACE利用iocterms及一组高置信度上下文术语下的正则表达式下来定位包含IOC的句子，然后根据离线学习的模型分析这些锚（上下文术语和假定的IOC token）之间的关系，从而准确、有效地获取IOC。图三说明了iACE的结构构架。

结构及流程说明：

（1）BS从不同的技术博客中自动收集技术文章，从单个博客页面中删除不相关的信息(如广告)；

（2）BP对这些文章进行检查，使用NLP技术过滤掉那些不太可能含有IOC的文章；

（3）此时文本认为都是IOC-relevent的文章，RCP将其所有内容（包括图片）转换为文本，把文本内容分为句子和其他（表格、列表等），使用一组上下文term和正则表达式来搜索那些可能涉及IOC的句子。【注意：上下文term可以是自动从iocterm中提取的，也可以是来自其他手动标注的来源；正则表达式是专门为各种IOC类型构建的】；

（4）对于每个句子，RC分析其连接上下文term和IOC锚点的语法结构，通过使用学习好的模型来确定后者是否确实是IOC，如果是则标注IOC和上下文术语；

（5）IG根据OpenIOC框架自动创建head和define部分。

iACE的设计主要是分析技术博客，因此存在这样一个假设：假设博客作者以专业的方式呈现他们的发现。这种假设在直觉上是合理的，因为这些博客是由安全专业人员编写的，它们的目的是快速地向同行共享技术细节。

3.1 相关内容识别

3.1.1 博客爬虫

首先确定采集的45个博客站点后长期进行监控，然后执行广度优先，从主页开始探索其发现的每个链接，直至找不到链接为止。

3.1.2 预处理

使用爬虫采集所有链接的内容可能会包含登陆页面、广告、联系页面等内容。作者为自动删除这些不相关的页面，利用以下两个观察：（1）博客上发布的文章都是在相同的HTML模版中框起的，这与其他页面使用的非常不同；（2）与其他类型相比，博客页面承载了更多的文字。基于上述观察，BS模型将每个页面的DOM树与其他页面的DOM树进行比较，发现一小组页面与大多数页面的使用都不同，这些页面就被认为是异常的并从数据集中删除。[使用Beautifulsoup实现]

上述是针对模版组的不同进行操作的，此外还有一些与IOC无关的内容，包括博主图片、广告等，因此BS采取了进一步的预处理。所采取的方法是：比较所有页面的DOM树，如果是与用户生成内容无关的节点在内容上基本没什么变化（如：博主照片基本不会变），如果是与而已体内生成内容相关的节点在内容上的差异是很大的。节点之间的区别可以通过 composite importance (CI)来度量。

经过第二层“过滤”后，还存在一些内容是不能通过基于文本的方法直接分析的，主要包括图像和嵌入的PDF文件，因此BS采取了第三步的预处理。所采取的方法是：预先打算使用Tesseract识别图像中的文字，但由于博客中的图片质量较差，而且图片中常有非字典词，使得识别准确率只有70%左右。为解决这个问题，先使用Gimp来调整图像的大小以获得更好的图像质量，交将从文章中发现的新单词添加到Tesseract中，抽样结果发现，此时Tesseract的精准确率达到了95%以上。

3.1.3 主题筛选

经过上述预处理后，将首先删除那些不包括任何IOC的文章，如：产品推广、新闻、软件更新等。iACE运行TC（Topic Classifier）模块实现主题筛选，这是一个由如下特征组成的分类器：

主题词：由于IOC的一篇文章关注的是安全风险和漏洞，其主题也反映在主题术语上（如：恶意软件、漏洞利用等），而这些主题术语也不太可能是非IOC文章的主题术语。TC使用topic.termextract来收集每篇文章的术语，前20个术语及其频率都是分类的特征之一。

文章长度：由于IOC的博客往往是对IOC的详细描述，因此包含IOC的文章往往较长，而非IOC的文章往往长度较短。

字典词密度：与非IOC文章相比，IOC文章的字典词密度更低，因为大多数IOC是非字典词。TC使用enchant库来查找文章中的字典词，计算这些字典词与文章总词量的比例做为其密度。

确定上述特征后构建一个SVM分类器，在DS-Labeled数据集上进行训练，包括150篇IOC文章和300篇非IOC文件【DS-Labeled数据集将在后续进行介绍】。通过10倍交叉验证对模型进行评估，精确率达到98%、召回率达到100%；将TC用于分析未知集合中的所有71000篇文章，并随机选择500个实例进行人工验证，表明该分类器的精确率为96%、召回率为99%。

3.1.4 IOC句子的识别

每一篇IOC文章中，RCP在RC进一步评估之前需要识别可能包含IOC的语句、表和列表。而这些内容都是根据文章中包含的锚点来选择的，即：上下文term和常见的IOC token。RCP解析每篇文章的HTML内容后，将文本分解成句子并检测表和列表。在每个句子中，查找与正则表达式相匹配的字符串及其上下文term，例如：“hash”就与MD5校验和一起出现。在表和列表中，还将上下文term匹配范围扩大到表头、标题和最相邻的句子。

OpenIOC标准使用一系列的iocterms来指定了600个类的IOC，进一步可归纳为IP、hash等19个类别，并为每一个类别手动构建正则表达式。但如前所述，只看正则式而不注意上下文term是很容易引入假阳性的。这些上下文term是通过标记每个iocterm包含的字典词元素并移除普通词（如：“item”）的方式自动从600个iocterm中收集的。进一步使用Semanticlink来发现其他语义相关的term，如：“portable executable” （related to PE)。最后收集到了5283个可以很好涵盖技术博客常见术语的上下文term。

3.2 关系检查和IOC生成

上述操作后可以发现可能涉及IOC的句子，但不足及准确地检测出真正的IOC。传统的IOC识别本质上是一个NER问题，而将其与上下文term进行连接则是一个RE问题。在NLP领域，这类问题的解决是管道化的：先识别句子中的命名实体（NER），再建立它们之间的关系（RE）。但这不适用于本文的问题，主要有两点：IOC及其token已经在一个句子中，需要做的只是检查它们之间的关系与在他们之间的预期关系是否一致；现有的RE技术无法直接适用，因为IOC及其上下文term之间的关系不具有共通性。此处提出的方法是将候选IOC及其上下文间的语法联系分析建模为图挖掘问题，同时处理NER和RE问题。主要工作分为以下几步：

3.2.1 关系表示

为分析IOC及其上下文term间的关系，首先使用依存关系解析将句子转换为依存关系图(dependency graph,DG)，用于描述不同语言token间的语法关系。DG是一个由Stanford依存解析器构建的有向加权图，表示为g =(V, E, W)，句子中的单词表示为节点V，两个相关的节点用边E相连，将它们连接起来的特定语法关系连被建模为一个边缘权重W。

一般都是在整个句子的DG上执行RE技术，而本文的方法是利用已知的锚点来关注最小的依赖图 $g_{ni,nc}$ ，这个依存图将一个IOC的候选项ni和一个上下文term nc连接在一起，因为这个子图所携带信息原则上是理解锚点间关系最相关的（如图4 所示）。需要注意的是，还添加否定依赖项作为核心节点的子节点或兄弟节点来捕获与IOC相关的负面描述。

3.2.2 相似度比较

在一个依存子图上，要建立一个上下文term和IOC候选项之间关系的模型，也要确定是否与另一个子图相似，这种相似性是对一个句子进行分类的基础。考虑到目前只需要处理带有几个标记节点的简单子图，则重点就是比较连接各个子图相应节点的路径，因此，论文制定了直接内积核（direct product kernel）的图数据挖掘技术。该函数通过对具有相同标签的序列进行变长随机游走来统计所有可能配对的数量，实现两个图相似性的度量。假设有两个有向加权图 $g_{1}=(v_{1},e_{1},w_{1}) ,g_{2}=(v_{2},e_{2},w_{2})$ ，其直接积也是一个有向加权图 $G=g_{1} \times g_{2}=(V,E,W)$ ，其中：

换句话说，对于图G中的每一对节点 $(u_{1} ,v_{1} ),(u_{2} ,v_{2})$ ，当且仅当 $g_{1}$ 中的 $(u_{1},v_{1} )$ 和 $g_{2}$ 中的 $(u_{2},v_{2} )$ 间边的指向和权重相同时，则认为这一对节点是相邻的。需要注意的是，作者将权重引入到乘积中来比较两个词之间语法关系的类型：只有当两个句子中相邻的单词对具有相同的语法关系时，这种关系才会保留在新的图中。通常来说，直积计算的时间复杂度为 $O(\vert V \vert ^4 )$ ,但是在移除上下文term和IOC候选项的方向而只考虑两者间路径的子图时，直积计算的时间复杂度就变为 $(\vert V \vert ^2 )$ 。在此时的直积图G上，计算两个子图的相似度为：

其中每一个 $A^l$ 的输入是直积图G中从 $v_{i}$ 到 $v_{j}$ 的跳数，因此 $A^l$ 可以使用G的邻接矩阵的L次幂来计算。 $\lambda$ 是衰减常数，且 $\lambda \preceq \frac{1}{min(d_{i}, d_{o})}$ ，其中 $d_{i} ,d_{o}$ 分别表示G的最大入度和出度。本文的设置是 $\lambda =\frac{1}{min(d_{i},d_{o} )}$ 。

3.2.3 分类

基于上述定制的直接内积核，运行一个分类器来确定一个上下文term和一个IOC候选词之间是否存在IOC关系。论文使用Logistic回归在DS-Labeled数据集上进行训练，包括1500个正样本和3000个负样本。该分类器将每一个样本分为正样本或负样本，其处理的内容是由子图的特征构成的核向量。

3.2.4 IOC生成

在识别了IOC及其相应的上下文term后，IG可以自动将技术博客的CTI内容转换为OpenIOC记录。其转换方式为：记录中的每个indicator item都通过带有上下文term的Context标签和相关IOC的Content标签来填充search属性来生成。这个item上的其他字段内容也可以从也可以这两个标签中派生出来。例如：Content标签的type属性和Context的tag属性实际上就是已经发现的IOC的iocterm。

对于记录的头部，IG使用开源的自动摘要工具Textrank来生成博客文章的总结，作为Descripition标签的内容。使用博客的原始地址来填充link标签，authored_by和authored_date标签则设置为原型的名称和文件生成时间。

4 论证

4.1 设置

本文实验硬件环境请详见论文。对数据集及参数设置进行说明：

4.1.1 数据集

本文主要使用了两个数据集，分别是用于训练主题分类器和关系检查器的标记数据集(DS-Labeled)和用于评估本文方法的未知数据集(DS-Unknown)。

DS-Labeled：该数据集包括80个IOC文件及相应的博客文章，主要来自于iocbucket和openiocdb两个信息源，且都通过OpenIOC的形式提供情报。在这些item的description标签下，找到指向这些item来源的链接并从22个博客中找到了150篇文章，包括它们的HTML页面和图像文件。此外，还从相同的博客中手工收集300篇其他文章，每一个手工检查以确保它们没有任何IOC但包含一些IOC-like的字符串。从这些文章中进一步提取两种类型的句子，一种是带有IOC的句子，一种是没有IOC但包含ioc-like字符串的句子。带有IOC的句子是使用我们收集的特定OpenIOC item的上下文term和IOC token进行识别，3000个错误的IOC语句则是由iACE使用正则表达式和上下文term进行匹配，最后都进行了手工验证。

DS-Unknown：用于评估本文方法的数据集是从45个安全相关的技术博客中收集的。详细列表在文中补充资源中。

4.1.2 参数设置

本次实验的实现过程中，主要有几个参数进行设置：

（a）内核衰减参数 $\lambda$ ：3.2.2中已经对该参数的设置进行了说明。

（b）正则化的倒数(C)：文中使用Logistic回归建立分类模型并在DS-Labeled数据集上进行训练，为减小过拟合，则设置C=3。

（c）句子长度阈值(L)：当前的依存解析器受限于其处理长句的能力，当一个句子变长时，解析的准确性就会下降，开销也会增加。在本实验中，将句子的最大长度设置为200。鉴于IOC可能存在于句子长度大于200个单词的情况，则直接从其中提取IOC而不需要建立依存关系图。在本实验中，如果句子长度大于200的同时有两个连续的IOC token或有五个以上的IOC token，并且这些token都是由少于5个字符的短语分隔的，则直接从这些句子中提取IOC。

4.2 结果

精确率和召回率：作者首先在450个IOC和非IOC文章上对TC进行了评估，然后在包含1500个真实的IOC句子和3000个错误的IOC句子的DS-Labeled数据集中评估RCP和RC，两种评估均使用了5折交叉验证。本文的原型在发现IOC文章方面取得了98%的精确率和100%的召回率，在识别真实IOC句子及其上下文方面达到98%的精确率和92%的召回率。下图所示即为RCP和RC的ROC曲线：

然后在总共71k篇文章上运行整个系统，包括自动提取IOC token及其上下文term并进一步将其转化为OpenIOC item。作者采用对未知集采样的方式来说明提取信息精确率和召回率：（1）将未知集中文章根据其发布时间进行分组【连续四个月为一组】；（2）将45个类别的发布商分别分组，从每一组中选择少量文章。在这个验证过程中，总共手动验证了820篇文章、25k个报告的句子，iACE的精确率为95%【25k个报告的IOC的IOC中有23k个都是正确的】、召回率为90%【抽取的90%的IOC都被报道了】。

为了将iACE与最先进的方法进行比较，将iACE与NER工具（stanford NER）和AlienVault OTX集成的商业IOC 标识符进行比较。注意：目前还没有任何工具可以识别一个IOC的上下文，更不能产生机器可读的OpenIOC item。在本实验中，Stanford NER在标记好的真/假IOC 句子上进行训练（如4.1节所示，与iACE的训练设置一样）。对于AlienVault OTX，则通过其API提交文章至页面服务并返回识别出的IOC token。实验结果表明，在DS-Labeled数据集的25个博客中随机选择500篇文章运行这3个系统：iACE提取到了427个OpenIOC类别的IOC item，例如：FileDownloadHistoryItem/FileName,Email/ReceivedFromIP，精确率达到 98%，召回率达到93%；OTX只能提取到8个类别的IOC，精确率为72%，召回率为56%；Stanford NER的结果也是与这相近。由此可见，OTX和Stanford NER比较容易引入大量假阳性。下表为其结果总结：

性能：为了解iACE的性能，作者测量了其在未知集中每一篇真实文章所花费的时间，以及每个阶段开销的细分（BP,RCP,RC,IG）。实验条件为：R730xd服务器，40线程。平均来说，分析一篇文章的时间约为0.25秒左右【如表5】。这也表明iACE可以很容易地扩展到处理每天产生的大量CTI的水平。

此外，考虑到DG解析器很大程度上受句子长度的影响，测量了RC模型在不同句子长度时的性能，结果发现iACE的运行时间随着句子长度的增加而逐渐增加【如图6所示】。原因是：iACE只提取链接上下文token和IOC token的最短路径，从而减轻了句子长度的影响。

5 度量与分析

通过自动从45个博客的71000篇文章中提取IOC向大家全面展示了过去13年世界面临的网络威胁，通过分析这些IOC也表明了它们在一个大的时间框架内的关系和演变，也带来了对CTI的新见解。更发现了，一些看似无关的攻击由于共享唯一的IOC实际上是有关的，如：共享IP、email等。主要的发现有以下几点：（1）有一组C&C服务器被396篇文章报道，并在四年时间内链接到7000多个独立的IOC，这表明这些独立的攻击可能都来自一个大规模、以前不为人知的攻击活动的一部分；（2）通过将不同文章联系起来，同一漏洞已经被持续利用很长一段时间；（3）密集报道的IOC往往生存期很短；（4）防御方对IOC的反应不像人们期望的那样及时，需要好几天才能让IOC进入AV、黑名单等。

5.1 Landscape

研究表明，技术博客包含了丰富的威胁情报信息：从71000篇文章（20K IOC文章）中发现了900k IOC及其上下文，包括20K的攻击hash值、55K的注册表键值、58K的恶意IPs、180K的FQDNs等。表6给出了iACE发现的10种最多实例的IOC类型(由相应的iocterms描述)。结果最多的IOCs类型为PortItem/remoteIP，因为这与drive-by-download、Phishing和其他网络攻击的流行有关。

对IOC在不同文章和博客中的分布情况进行研究，平均每篇文章有52个IOC，70%的文章有超过10个IOC。（如图7（a）所示）【hpHost博客每篇文章有350个IOC，这是检查的博客中最大的一个；CyberCrime上的一篇文章谈到google重定向垃圾邮件时，报道了3417个IOC】。当考虑到IOC上下文的多样性时，平均每篇文章包含6个不同的iocterm，30%的文章有超过10个不同的iocterm。有更多IOC的博客不一定有有更多样的IOC类型，例如：尽管hpHost单篇文章的IOC数量最多，但每篇文章只有8个iocterm

5.2 理解威胁

相关性分析。为了理解文章中所报道的不同攻击活动之间的关系，通过测量共同的与基础设施相关的IOC（如：ip、域名等）来研究这些活动中关键攻击资源的共享。具体来说，使用这些IOC可以将所有文章分组到527个集群中（每个集群中有超过3篇文章）：若两篇文章共享一个IOC ip、邮箱、域名，则将其放到同一个集群中。此外，还删除了私有地址范围内的IP段。为了找出是否在同一个集群中的点指向了一个公共资源，即本质上谈论的是相同的攻击实例，作者还查看每篇文章中的URL以识别那些指向45个博客和其他知名情报源的抽取结果。图7b说明了包含涉及此类引用的文章在不同百分比情况下集群的分布情况。结论就是许多集群都是很低的引用百分比；换名话说，文章的作者很显然没有意识到他们记录的攻击与其他实例有关。

作者甚至挑选了5个集群，每个集群至少25篇文章但最多5%的文章包含了对其他文章的引用。没有发现这些带引用的文章提到在同一个集群中由其他文章报道的攻击实例间的关系。同样的，对这些文件的采样没有显示不在我们列表范围内对其他博客的引用。这表明将所有攻击连接起来的基础设施关系之前从未报道过，这一点通过在Internet上搜索相关文献可以得到证实。表7也提供了关于这些集群的信息。有一个发现是，发现了一个IOC“132.248.49.112”，这个IOC由19个博客报道的共享IP指向了一个C&C服务器。作者认为，所有这些独立记录的攻击实质上都是属于一个规模未知的大型活动，只是其规模以前未知。值得注意的是，这种关联是十分重要的，因为它告诉了攻击者共享的关键资源，而这些资源可能是攻击者最薄弱的一环。

演化。通过对396篇文章报道涉及7000多个独立IOC的C&C活动进行调查，发现其已经持续了很长一段时间，并在不断调整其攻击策略和技术。具体来说，它通过向用户发送垃圾邮件、攻击合法网站等方式传播恶意软件，其利用的漏洞从CVE-2010-1885演变到CVE-2013-0422。与此同时，该活动为其C&C服务器使用了一小组ip，其中一些共享相同的注册电子邮件“gkook@checkjemail.nl”。显然，关闭这些服务器将会严重影响这种持久、大规模攻击的有效性。

对不同文章报道的攻击进行关联的另一个步骤是，根据其攻击向量的indicator(包括恶意软件hash、漏洞CVE和注册表的内容)对它们进行聚类。其目的是通过释放相关IOC以了解攻击向量的演变。为此，作者以连续几个月的时间为标准来考察最短的时间周期，在此期间某个特定的IOC(例如，132.248.49.112)连续被新文章覆盖，这段时间称为“衰减时间”，它演示了与IOC相关的攻击实例在能够被停止(至少是暂时停止)之前会持续多长时间。如表8所示，作者发现大量文章所报道的IOC往往会迅速消失，这表明要么相关问题得到迅速解决，要么对手对报道做出反应改变他们的战略。然而，有一些虽然是众所周知的但也很持久的IOCs:例如：缓冲区溢出漏洞CVE-2012-0158在博客文章中持续出现了四个月，在一些中断后继续出现在其他攻击中长达四年之久!更具体来说，它被用于军事和航空航天行业的APT攻击(2012/04)、用于政治组织(2012/09)，通用恶意软件传播(2013)，以及最近用于电影行业的鱼叉式钓鱼攻击(2014)和银行(2015)。这些都清楚地表明，组织没有尽其应有的努力对问题作出充分的反应。

IOC的影响。此外，作者还研究了此类开源情报对安全保护的影响:安全行业(例如反病毒服务提供商)是否对IOC的报告做出了快速反应。为此，估计了IOCs第一次发布到它们被反病毒(AV)工具和web扫描器采用之间可能的时间间隔。在本研究中，向VirusTotal[11]和CleanMX提交了一组IOCs，包括恶意来源的IP和域名，以及恶意软件的哈希表。VirusTotal[11]是一个有56个主流的反病毒扫描程序的平台，而CleanMX[22]是一个IP/URL扫描程序平台。在VirusTotal中，当提交的IOCs至少出现在一个AV系统中，就第一次收集其时间戳。对于CleanMX，则获取2009/01到2015/04年间存档的IP/URL黑名单数据库。结果发现47%的IOC在被博客报道之前就在这些系统中更新了。对于其余部分，图8a显示了在IOC发布之后和首次用于扫描之前的持续时间分布。如果上传时间(或IOCs第一次被用于扫描的时间)确实接近于IOCs (IP、域、散列)被添加到系统的那一刻，可以观察到IOCs被放置到位之前有多天的延迟。特别是对于ip和域名，整个过程通常需要超过12天。另一方面，恶意软件哈希经常很快被添加，大多数情况下在2天内。

5.3 理解情报源

纵向数据的可视化使得人们能够调查不同来源indicator的质量及其对新威胁的及时性。

Timeliness。使用前面提到的攻击集群，分析了不同博客上首次对攻击进行报道的文章的分布，如图8b。而且60%的集群中的第一次报告都是由10个博客负责的。例如，Dancho Danchev博客第一次报告了12个集群，平均每次涉及45个IOC，这些IOC后来也在其他博客上出现了。

表9显示了首次报告的IOCs在所有最终从集群中发现的IOCs中的平均百分比(即，第一次报告的IOCs的数量和那些只报告一次与一个集群中所有IOCs的数量之比)。发现大多数IOC首先被Hexacorn和Naked Security报道，随后也被其他博客提到，此外，还提供了大量没有被其他博客记录的IOCs。还观察到，即使Webroot平均只包含监测集群中最早报告IOC的13%，但其84%的IOCs没有被其他来源报告。

Completeness。早期的报告往往只包含IOC的一小部分。在本文的研究中，测量了包含在不同攻击集群下第一次报告中的IOC token及其iocterms的百分比:平均每个集群中，6个博客报告了超过40%的IOC token，9个博客报告了超过50%的iocterms(与攻击行为相关)。进一步检查对攻击集群进行了最完整的描述文章的博客，TaoSecurity被发现有最多的这类文章。

Robustness。本文研究中还比较了不同IOC token的鲁棒性,即在一个攻击集群中、在整个时间段上考查其稳定性(集群在表7)。从上述数据中发现域名服务器、C&C服务器、注册电子邮件是最可靠的indicator,在分析的集群中保持10到30%的不变(见表9)。使用这些信息,进一步测量可能会报告这些token的博客:质量越高的博客提供越多这样的token(即，鲁棒IOCs的数量与集群中总IOCs的数量之比)见表9。有趣的是，在研究这些服务器的IP时，发现它们中的许多实际上共享相同的IP前缀，这使作者相信它们可能都来自一小部分恶意自治系统。

6 讨论

研究表明，iACE在实现完全自动化的网络威胁情报收集方面迈出了重要一步。测量研究也表明，这不仅对信息的方便收集有重要意义，而且对这类信息的有效分析也有重要意义。随着大量的IOCs自动从真实环境中发掘出来并转换成机器可读的形式，它们之间的内在关系可以很快被发现，并有效地用于对抗即将出现的威胁。例如，了解C&C服务器在多个攻击实例之间的共享可以使防御者禁用或阻止服务器来停止攻击。另一方面，本文目前的设计还处于初级阶段，因此，作者讨论了iACE的局限性和潜在的后续研究。

错误分析。研究表明iACE具有很高的精度和覆盖率，远远超出了标准的NLP技术所能达到的水平。然而，本文的技术仍然引入了一些错误的发现并遗漏了一些IOCs。这些问题主要来自使用的底层工具的局限性和不正常的表示方式。具体来说，光学字符识别器Tesseract存在一些不足之处，其准确性直接影响到最终分析结果。此外，当句子变得太长时，最先进的依赖解析器仍然无法保持其准确性。尽管iACE只在IOC及其上下文标记之间的最短路径上工作从而缓解了这个问题，但是仍然有一些句子太长，解析器无法正确理解单词之间的依赖关系。此外，打字错误也增加了问题的复杂性:例如，如果一个人忘记在句号后面加上空格，一个句子就会被后面的句子卡住，这可能会导致IOC句子识别错误。另一个有趣的发现是，在一些文章中作者故意拼错URL以防止读者无意中点击它们:例如，将“http”更改为“hxxp”或在URL中的dot中添加“[]”。iACE包括一系列识别此类传输的典型混淆技巧。然而，总是有一些不认识的方法使IOC token被漏掉。此外，大量被污染的原始文章内容也可能导致错误的发现。例如，一个活跃的攻击者可以入侵博客网站并在文章中注入虚假的IOCs，从而触发iACE报告虚假的IOCs。为了更好地解决这些问题，还需要作出进一步的努力。

其他情报来源及标准。iACE目前的设计是从技术博客中收集威胁情报，基于IOC独特的描述方式。此外，它也将工作在其他同样或更正式的来源，如白皮书和其他技术文章(例如，研究论文)，这里肯定需要进一步的研究。不太清楚的是这项技术在不太正式的情报来源上的有效性，比如技术论坛(例如，google group[5]，SecurityFocus[7])。其写作风格略有不同，尤其是使用了更为多样化的语境术语和语法结构不规则的句子。将iACE扩展到此设置需要进一步的努力。此外，用来训练iACE的情报来源都是英文文章。考虑到其他语言的情报来源，iACE应该引入新的上下文term语言翻译模块并训练不同语言的依赖解析器。此外，正如前面提到的，iACE支持的是OpenIOC CTI模型。虽然还有其他的模型，如STIX[8]和yara[12]，但是也有一些工具可以跨这些标准转换信息。

7 相关工作

威胁情报交换。为了帮助组织和安全社区抵御快速发展的网络攻击，在威胁情报共享方面做出了巨大努力。Facebook ThreatExchange[25]和dibnet[3]是为在认证通过的参与者之间交换IOCs而开发的平台。同时，AlienVault OTX [17]、OpenIOC DB [1]、IOC Bucket[29]被建立来共享公共(非机密)IOCs。不管哪种平台，博客等公共资源仍然为IOC贡献了很大一部分。iACE将有助于在这些公共资源和交流平台之间建立一个快速通道，并帮助参与组织及时获得IOC的最新信息。据目前所知，AlienVault[17]和Recorded Future[13]是仅有的两家支持IOC自动提取的IOC提供商。尽管Recorded Future(不提供公共服务)使用了NER技术[40]，但这两个工具都只是在寻找IOC实体，而没有将它们链接到攻击上下文，因此不能生成机器可读的OpenIOC term。相反，iACE定制了图形挖掘技术来捕获实体之间的关系，从而生成高质量的IOCs和它们的攻击上下文，而且具有很高的准确性。最近也对从其他来源提取IOC进行了研究。Catakoglu等人的[19]演示了一个从蜜罐中提取外部组件(web IOCs)的框架，与本文们的方法相比，而且它更符合自动签名生成的工作。Sabottke et al.[43]开发了一个警告系统，通过tweet报告提醒用户正在进行的攻击(寻找带有“CVE”的tweet)。这与本文的工作不同，本文的工作是根据攻击报告生成机器可读的IOCs。

NER/RE。今天的NER主要依靠一系列的单词来识别预先定义的实体(如PERSON、LOCATION)的存在。例如，Stanford NER[26]利用隐马尔可夫模型从非结构化文本中找到最有可能的实体序列。其他的例子包括Illinois NER[21](基于监督学习)和LIPI[16](基于n-gram字符语言模型等)。当涉及到RE时，目前的方法是使用tree核的支持向量机[24]、自监督学习[46]的启发式匹配、开放模式模板[44]和其他技术来检测两个已知实体之间的特定关系。通过比较，iACE利用ioc-related文章的独特特性，使用关系检测来帮助识别真正的IOCs及其上下文。这种将NER和RE步骤结合在一起是以前从未有过的。本文定制的图数据挖掘算法也丰富了RE技术。

应用于安全和隐私的NLP。相对于NLP在其他领域(如生物信息学)的应用，NLP只是最近才被用于安全和隐私研究。之前的工作利用NLP分析web隐私政策(提取其关键字)[49]，生成Android应用程序的隐私政策[48]，分析应用程序描述推断Android应用程序需要的权限[38,36]，检测被入侵的网站[31]，识别来自应用程序的敏感用户输入[28,34]。本文的工作展示了NLP的一个新应用，表明需要开发创新的NLP技术来应对现实世界的安全挑战。

8 结论

本文提出了一种从非结构化文本中自动提取IOCs的新技术——iACE。iACE是基于IOC独特的特征以及技术文章对其的描述将NER和RE步骤融合起来，来专用于收集威胁情报的NLP技术。通过使用假定的IOC标记和上下文term来锚定一个句子，本文的方法可以通过一个图相似度比较的新应用，有效地利用这些元素之间的关系来验证它们的正确性。这个简单的技术是非常有效的，在精确率和召回率方面远远超过了行业顶级的IOC分析器和NER工具。对过去13年发表的71,000多篇文章的评估也进一步揭示了数百个看似无关的攻击实例之间的内在联系，以及开源IOCs对防范新出现威胁的影响，这突出了迈向完全自动化收集网络威胁情报的第一步的重要性。