Twiti：一种从社交网络中提取威胁情报IOC的工具 - 安全客

Twitter 是一个流行的威胁追踪公共资源，许多安全供应商和安全专家在实践中使用Twitter 来收集入侵指标(IOC, Indicators of Compromise)。

首页 安全知识 安全资讯 招聘信息 安全活动 APP下载 Twiti：一种从社交网络中提取威胁情报IOC的工具 阅读量   223905 | 分享到： 发布时间：2021-07-3016:30:11 译文声明 本文是翻译文章，文章原作者HyejinShin，WooChulShim，SaebomKim，SolLee，YongGooKang，YongHoHwang，文章来源：dl.acm.org 原文地址：https://dl.acm.org/doi/10.1145/3442381.3449797 译文仅供参考，具体内容表达以及含义原文为准 ×   Twitter是一个流行的威胁追踪公共资源，许多安全供应商和安全专家在实践中使用Twitter来收集入侵指标(IOC,IndicatorsofCompromise)。

然而，在Twitter上对IOC的研究甚少。

它们的重要特征从未被研究过，如早期性、唯一性和准确性。

而且，如何从Twitter中高精度地提取IOC并不明显。

在本文中介绍了Twiti，这是一个从Twitter自动提取各种形式的恶意软件IOC的系统，Twiti的源代码可在https://github.com/Samsung/Twiti获得。

基于收集到的IOC，对Twitter上的恶意软件IOC进行了首次实证评估和彻底分析。

Twiti通过利用自然语言处理和机器学习技术从被识别为具有恶意软件IOC信息的推文中提取IOC。

通过广泛的评估，证明Twiti不仅可以准确地提取恶意软件IOC，而且提取的IOC是唯一且早期的。

通过从各个方面分析Twiti中的IOC，发现Twitter比其他公共威胁情报(TI)反馈更好地捕获持续的恶意软件威胁，例如Emotet变体和恶意软件分发站点。

还发现Twitter上只有一小部分IOC来自商业供应商帐户、个人Twitter用户是早期发现或独家IOC的主要贡献者，这表明Twitter可以提供许多在商业领域发现的有价值的IOC。

  0x01Introduction 恶意软件攻击每年都在增加。

特别是，通过网站传播的恶意软件正在迅速增加。

正如在Dyn攻击和Garmin勒索软件攻击中所见，恶意软件可以迅速传播，其破坏可能是灾难性的。

考虑到其风险，预防是最好的防御。

尽管存在一些基于预测的恶意软件检测解决方案，但入侵指标(IOC)是防御恶意软件的关键。

IOC是网络攻击的取证工件，因此它们能够检测系统或网络上的入侵企图或任何其他恶意活动。

当及时提供最新的IOC时，它们在保护系统或网络免受未来攻击方面发挥着关键作用。

IOC的示例包括恶意文件的MD5哈希值、IP地址、僵尸网络的URL或域以及文件名。

大多数组织订阅威胁情报(TI)源以接收恶意软件IOC，但单个源是不够的。

许多tivirus解决方案和商业TI源通常不会立即反映新的或正在进行的攻击的IOC。

由于这些原因，许多行业和安全专业人士通过开源威胁情报丰富了IOC。

根据2019年对北美和英国1,908名IT和安全从业人员的调查，至少37%的受访者表示他们的组织将公共TI订阅源与商业订阅源一起使用（41%的受访者表示他们的组织使用一个付费TI反馈，而78%的人回应使用多个TI反馈）。

有很多公共资源可以收集恶意软件IOC。

最容易访问的来源是公共恶意软件黑名单列表，例如Feodotracker和AlienVaultIP声誉。

安全供应商博客是IOC挖掘的另一个常见来源。

安全邮件列表、安全论坛和暗网也经常用于IOC搜索。

在众多公共资源中，Twitter保证攻击的数量、及时性和多样性。

它通过将推文链接到外部站点来从整个网络带来大量内容，这使Twitter能够涵盖来自各种来源的大量新IOC，例如安全供应商博客、蜜罐和恶意软件沙箱。

这使得许多安全供应商在实践中利用Twitter进行IOC搜索。

然而，由于Twitter的独特特性，如文本短、非标准语言以及与推文相关的外部来源多样，从Twitter中挖掘出高精度的IOCs并不明显。

有一些开放系统从Twitter收集IOC。

但是，正如稍后展示的那样，实验表明在Twitter上使用IOC时，两个系统的覆盖率和准确性都不令人满意。

因此开发了Twiti，一个用于Twitter的自动IOC提取系统。

Twiti使用推文分类器和选定的外部源列表识别可能包含恶意软件IOC的推文。

然后它从推文和推文中的外部链接中提取IOC。

这种方法使Twiti能够以高精度收集大量IOC。

此外，尽管Twitter作为IOC的数据源广受欢迎，但人们对从中收集的IOC知之甚少——Twitter上有多少IOC、它们有多新、多准确、与其他公共或商业机构相比有多独特TI反馈、报告了哪些恶意软件IOC、谁报告了独家IOC、Twitter上有多少IOC可以用于任何目的、可以从外部链接获取多少IOC等等。

为了回答这些问题，通过Twiti收集恶意文件哈希以及与恶意软件相关的IP地址、域和URL。

然后评估数量、延迟、准确性和排他性。

最终从数据源、文件类型到恶意软件类型等各个方面分析了收集到的IOC的特征，以提供有关Twitter上IOC的见解。

  0x02TWITI：DesignandImplementation 下图说明了Twiti的架构。

Twiti由三个步骤组成——数据收集、相关推文选择和IOC提取。

Twiti旨在以高精度收集尽可能多的与恶意软件相关的IOC。

为了实现这一目标，在2019年11月进行了一项试点研究，精心设计了数据收集器和IOC提取器。

A.推文收集器 为了最大化要收集的IOC的数量，Twiti主要通过使用Twitter搜索API的关键字跟踪来收集数据，其次是使用时间线API通过用户跟踪来收集数据。

跟踪了35个可能与恶意软件IOC一起出现的关键字。

关键字的示例包括“malware”、“ransomware”、“botnet”、“spyware”、“adware”、“malspam”、“iocs”和“virustotal.com”。

此外，还跟踪了146名Twitter用户，其中包括86%的安全专家、12%的安全供应商和2%的其他安全组织。

请注意，在125位安全专家中，67%的人在他们的个人资料中将自己介绍为恶意软件分析师、恶意软件研究员、威胁猎人d或威胁情报研究员。

另请注意，Twiti会收集转发的原始推文并从中提取IOC。

B.相关推文选择器 使用模式匹配简单提取IOC会导致许多误报。

大多数推文都包含他们自己的推文或参考的链接（例如，https://t.co/qQdme1Buxh）。

一些推文提到软件版本与IP模式匹配（例如，Tuleap9.17.99.189）。

一些推文提到了用于引用提交ID或区块链交易的哈希值。

为了减少这种误报，Twiti首先处理推文中的链接，然后对推文进行分类以过滤掉那些没有IOC的推文。

（1）推文预处理器 短URL移除器：Twitter的t.co服务会自动缩短推文中发布的所有链接（URL）。

由于Twitter转换的链接会针对潜在危险站点进行检查，因此会从文本中删除“http://t.co”链接，以避免将推文中的良性URL错误地检测为IOC。

尽管在此过程中，由其他URL缩短器缩短的某些链接有时仍会保留在推文中。

因此还会删除域名为“bit.ly”、“tinyurl.com”、“buff.ly”、“goo.gl”、“youtu.be”或“ow.ly”的短URL。

正则表达式检查器：删除短URL后，会检查每条推文中是否有与哈希、IP地址、域和URL的正则表达式匹配的术语。

文本预处理器：对于通过正则表达式检查器的每条推文，应用以下自然语言处理(NLP)为分类器提取特征： (1)所有类型的hash都替换为“[hash]”。

IP地址、URL、域、文件名、文件路径和电子邮件的术语也替换为“[ip]”、“[url]”、“[domain]”、“[filename]”、“[filepath]”，和“[email]”，分别。

请注意，所有经过修改的URL、IP地址和域都被转换为它们的代表标记，例如“[url]”。

Twitter句柄和CVEID也被替换为“[username]”和“[cve]”。

所有数字都替换为“[num]”。

(2)命名实体识别(NER)应用于每条推文。

标记为恶意软件的词被替换为“[malware_name]”。

(3)删除了前文和后文中的Twitter句柄。

(4)删除了IOC中未使用的Unicode字符和符号。

(5)推文是小写的。

跟踪的关键字及其别名由单个标记形式的单个代表性术语替换。

例如，“c&c”、“cnc”和“commandand-control”被替换为“c2”。

(6)对推文进行标记化并对每个单词应用词形还原，以将单词的屈折形式表示为单个单词。

停用词被删除。

删除由单个字符“[username]”和“[num]”组成的词。

请注意，现有的NER工具如NLTK、CoreNLP和twitter_nlp未在网络安全领域接受过训练。

因此，使用提及网络安全事件的推文训练了Bert模型，并在步骤(2)中使用了它。

基于Bert的NER的详细信息可以在https://github.com/Samsung/Twiti上找到。

（2）推文分类器 开发了一种高性能推文分类器，用于确定推文是否包含IOC。

在下文中根据是否包含IOC将推文称为IOC推文或非IOC推文。

数据集：为了构建IOC推文分类器，收集了2019年1月至9月包含IOC模式的推文。

在此期间，可以收集21,937条推文。

去除Jaccard相似度大于0.70的相似推文后，剩余5675条推文。

三位安全专家手动注释每条推文是否包含任何IOC。

有3,007条IOC推文和2,668条非IOC推文。

特征：认为以下是初始特征： •DefangedIOCs：此功能检查每条推文中是否至少有一个defangedIOC。

在推特上发布IOC时，defang技术通常应用于IP地址、URL和域，以防止意外暴露于恶意活动内容。

此类推文的示例包括“#gandcrab@hxxp://92.63.197.106/c.exe”、“#RoamingMantisnewlandingpages：67[.]198.129.27…”、“#darkcomet/elumadns.eluma101.com…”，“Thisappimpersonate…#c2hold[.]jcgloball[.]org:11880”。

•上下文n-gram：这些是围绕IOC关键词的上下文词。

使用的关键词是被跟踪的关键字（例如，“malware”,“ransomware”,“botnet”）、“[hash]”、“[ip]”、“[url]”、“[domain]”和“[malware_name]”。

很明显，在IOC和非IOC推文中，有关感兴趣模式的词会大不相同。

例如，“version[ip]”、“upto[ip]”、“before[ip]”、“preorto[ip]”和“commit[hash]”清楚地出现在关于软件漏洞的推文中，而“hash[hash]”、“c2[url]”、“c2[ip]”、“botnetc2”、“from[ip]”、“ransomware[hash]”、“[filename][hash]”、和“[malware_name]md5s[hash]”绝对属于IOC的推文。

为了提取这样的上下文特征，首先将文本预处理(1)-(5)应用于每条推文。

然后提取由目标词及其左右两侧的1-2个词组成的二元词组和三元词组。

•词袋：与IOC共同出现的词也不同于非IOC推文中的词。

例如，“c2”、“md5s”、“yara”、“botnet”、“[malware_name]”、“ransomware”显然更多地出现在IOC的推文中。

相反，在IOC推文中不太可能观察到“[cve]”、“csrf”、“0daytoday”、“vulnerability”、“xss”和“sql”。

文本预处理（1）-（6）用于提取单词。

然后删除常见的英语单词。

通过将词形还原词视为特征，可以考虑在上下文特征中无法考虑的词变异。

请注意，这里的所有特征都是二元特征。

也就是说，如果每个特征在推文中，则取值为1，否则取值为0。

特征选择：并非所有特征对分类都很重要。

选择了使用互信息(MI)将IOC推文与非IOC推文区分开来的特征。

对于特征X和类标签Y∈{IOCtweet,non-IOCtweet}，X和Y的互信息计算如下： 其中PX,Y是X和Y的联合分布，PX,PY分别是X和Y的边际分布。

MI衡量知道X减少了关于Y的不确定性的程度，反之亦然。

例如，如果X和Y是独立的，那么知道X并不会给出关于Y的任何信息，因此它们的MI为零。

因此，MI能够选择有助于区分IOC推文和非IOC推文的特征。

取MI大于0.0002的词和n-gram。

选择阈值是为了最大化分类器的预测性能。

分类器：有22,316个初始特征。

特征选择后，保留了1,456个特征。

它们包含483个单词（unigrams）和972个二元词和三元词。

考虑了3个分类器——逻辑回归、随机森林和XGBoost。

使用由3,007条IOC推文和2,668条非IOC推文组成的数据集使用5折交叉验证评估了这些分类器。

选择了随机森林分类器，因为它表现出最好的性能——精度为0.95，召回率为0.96。

在下图中展示了3个分类器的ROC曲线，在下表中展示了随机森林分类器的重要特征示例。

（3）外部链接检查器 由于推文文本简洁（280个字符限制），用户经常通过外部链接分享详细信息。

因此通过分析试点研究中推文中的外部链接，构建了一个外部来源列表，这些来源为大量IOC提供了较小的误报。

由于推文中的所有链接都被Twitter缩短，Twiti从TwitterAPI检索“http://t.co”链接的完整URL。

然后检查完整的URL是否来自选定的外部源。

C.IOC提取器 在Twitter上，有各种与威胁相关的信息，从漏洞、漏洞利用和恶意软件到异常网络活动。

但是，此类信息的详细程度因作者而异。

一些Twitter用户发布C&C服务器或其他有价值的IOC信息，如IP地址、URL和文件哈希。

另一方面，其他用户在没有太多细节的情况下分享他们的发现或经验。

根据信息的详细程度，从Twitter寻找IOC的方法有所不同。

在Twiti中，IOC提取器会遇到以下两种情况： •例1：推文中的IOC。

•例2：推文中没有IOC，但外部链接中有IOC 从推文中提取IOC：Twiti首先通过正则表达式的模式匹配在推文文本中查找IOC。

但是，某些类型的IOC（例如URL和IP地址）通常会被破坏，以避免无意中点击恶意链接。

从评估中发现38%的收集到的IP被篡改，73%的收集到的URL被篡改。

这表明Twitter在处理defang技术方面比在安全博客、论坛和邮件列表中面临更多挑战。

Twiti通过在开源IOC提取器中使用各种去污技术以及为扩展检测范围而添加的更多脱移URL模式来检测脱移IOC。

Twiti还从链接文本本身收集文件哈希、IP地址和域。

回想一下，Twiti在模式匹配之前从文本中删除了“http://t.co”链接，尽管它们是推文的一部分。

但是，从外部链接分析中，观察到某些类型的IOC嵌入在恶意软件分析服务的给定链接文本中。

例如，“https://www.virustotal.com/gui/ip-address/78.155.199.119/detection”。

因此，Twiti直接从给定的链接中提取这些IOC。

从外部来源提取IOC：当推文中的链接位于选定列表中时，Twiti从外部来源收集IOC。

为了选择提供大量IOC且误报较小的外部来源，分析了2019年11月收集的推文中嵌入的链接。

从分析发现，安全供应商博客、恶意软件分析服务和Pastebin.com是IOC的主要来源。

针对不同类型的数据源分别开发IOC提取器如下： •Pastebin.com：观察到Pastebin.com是推文中给出的顶级外部链接之一。

这是一个用户可以在线存储文本的网站。

正如稍后展示的，Twiti收集的许多IOC都来自它。

在Pastebin中，有来自源代码片段、泄露到IOC的凭据的各种类型的信息。

因此，对于IOC集合，在推文中搜索Pastebin.com的所有链接并不是一个好主意。

因此，分析了与Pastebin.com共现的词，并在应用文本预处理(1)-(6)后提取了前50个词。

经过人工审核，最终选择了18个词。

此类词的示例包括“恶意软件”、“malware”,“ransomware”,“trojan”,“botnet”、“[malware_name]”、“c2”、“ioc”和“payload”。

当这些词与Pastebin.com链接一起出现时，Twiti从Pastebin收集IOC。

•恶意软件分析服务：观察到推文中的IOC通常与分析报告的链接一起提供。

从外部链接分析中，观察到推文中发布的57%的分析报告来自VirusTotal，33%来自Any.Run，7%来自urlscan.io，3%来自其余恶意软件分析服务.其中许多在给定的链接文本中包含IOC，但有些在其站点中提供IOC。

在后一种情况下，Twiti使用他们的API收集IOC。

请注意，虽然观察到许多早于VirusTotal的恶意文件哈希经常通过app.any.run报告，但Twiti无法从Any.Run收集IOC，因为它没有提供公共API。

•安全供应商博客：从外部链接分析中观察到100多个安全供应商博客。

每个供应商在提供IOC时都有自己的格式。

因此，需要为每个博客开发专用的解析器。

•除了上面提到的那些，Twiti使用API从AlienVaultOTX收集IOC。

请注意，几乎所有安全供应商博客都在其服务条款中严格限制对其数据的使用。

因此，Twiti从数百个供应商博客中的IOC数量中收集了10个主要安全供应商博客的数据，仅供参考，以提供有关从安全供应商收集的IOC数据的见解。

  0x03DesignChoice 以下是对Twiti的设计选择，以尽可能多地收集恶意软件IOC，并具有较小的误报。

数据收集方法：有两种方法可以从Twitter收集数据——(i)关键字跟踪和(ii)用户跟踪。

为了确定Twiti的数据收集方法，试验了两种方法之间IOC数量的差异。

在实验中，在2019年11月跟踪了35个关键字和82个Twitter用户。

观察到，收集的IOC中有36.2%来自关键字跟踪，25.6%来自用户跟踪，38.2%来自两者。

因此决定利用这两种方式来最大化IOC收集。

由于关键词追踪对IOC的拉动更大，更容易扩展，所以Twiti使用关键词追踪作为主要的数据收集方法，用户追踪作为辅助方法。

关键词的选择：选择了可能与IOC共同出现的关键字，但不要制造太多噪音。

使用数据集提取了在IOC推文中比非IOC推文中出现次数更多的前100个单词。

应用了文本预处理(1)-(6)，然后删除了Twitter中的常用词和规范化的词，如“[malware_name]”和“[cve]”。

删除可能导致很多误报的一般词后，得到了35个词。

推特用户的选择：为了使基于用户的数据收集与基于关键字的数据收集相辅相成，选择了满足以下任一条件的Twitter用户： (1)用户是否经常在没有上述关键词的情况下提及IOC？ (2)用户是包含IOC的转推的原始推文作者还是在有关IOC的讨论中？ (3)用户是否是IOC的贡献者？ (4)用户的个人资料中是否包含“malware”,“ransomware”,“threathunter”,“threatintel”等词？ 通过分析数据集及其个人资料来收集此类用户，提取了至少创建了一条没有关键字的IOC推文并且其帐户处于活动状态的作者。

此外，在IOC推文的前后文本中提取用户，因为观察到位于IOC推文开头和结尾的用户属于条件（2）-（3）。

然后保留了在IOC推文中出现统计显着大于非IOC推文的用户。

最后分析了收集到的用户的帐户资料，发现其中许多人自我介绍为恶意软件分析师、恶意软件研究人员、威胁猎人或威胁情报研究人员。

从他们的个人资料中提取了一些重要的词，然后收集了更多的Twitter用户，包括这些词。

经过以上所有流程和人工审核，最终选出了146位Twitter用户。

外部源的选择：分析了2019年11月收集的IOC推文中嵌入的链接。

获得了25,437个唯一参考URL，其中包含5,605个唯一域。

其中，选择了IOC收藏的顶级站点。

请注意，在25,437个外部链接中，6.2%来自恶意软件分析服务，4.2%来自安全供应商博客，1.4%来自Pastebin.com，0.15%来自AlienVaultOTX。

  0x04Evalution A.评估设置 评估指标：为了评估Twiti的性能，通过将Twiti收集的IOC与选定的参考源进行比较来测量数量、排他性、延迟和准确性。

对于每种类型（例如文件哈希）的指标，定义了： •数量，作为评估期间饲料中指标的总数。

•排他性，即Twiti中指标在其生命周期内不在参考源中的比例。

它的正式形式为|Twiti\A|/|Twiti|。

•延迟是指Twiti首次检测到指标与其生命周期内首次出现在参考源之间所经过的时间。

•准确度是指反馈中真正恶意的指标的比例，它对应于准确度。

覆盖率（反馈捕获的预期指标的比例）是一个重要的性能指标。

然而，在缺乏所有持续威胁的真实情况的情况下，很难衡量覆盖率。

所以，改为测量当反馈中的整套指标可用时，Twiti捕获的反馈中指标的比例。

参考来源。

下表总结了用于评估的参考来源。

使用VirusTotal作为一个基本事实来衡量哈希和URL的准确性。

还使用VirusTotal来衡量所有IOC类型的独占性和延迟。

VirusTotal不仅是一项分析可疑文件和URL以检测恶意软件的服务，而且还是最大的TI反馈，由72个防病毒引擎和68个网站/域扫描引擎和黑名单列表支持。

与VirusTotal相比，高排他性和低延迟将是Twiti作为TI反馈实力的一个很好的指标。

请注意，使用VirusTotal私有APIv3.0来获取有关文件哈希、URL、IP地址和域的报告，以用于研究目的。

还使用了以下参考： (i)对于文件哈希，将Twiti与AlienVaultOTXPulse和MalwareBazaar进行了比较。

他们都不是VirusTotal的贡献者。

AlienVaultOTX是最大的开放威胁交换平台，任何人都可以通过脉冲订阅来订阅IOC。

MalwareBazaar声称其三分之二的样本未被VirusTotal检测到。

(ii)对于域，使用Alexatop1M、CiscoUmbrellatop1M和Majestic1M数据中的前25k域来检查有多少良性域被报告为恶意。

对于每个25k域集，们在评估期间连续出现的域，因为列表中可能存在一段时间的恶意域。

(iii)对于IP地址，将Twiti与一些与恶意软件相关的公共IP黑名单列表进行了比较。

选定的公共IP黑名单列表包括AlienVaultIPReputation、Bambenek_c2、FeodoTracker、SSL黑名单和Mirai相关反馈。

为了衡量准确性，使用上述顶级25k域数据和主要内容交付网络(CDN)服务（AWSCloudFront、CloudFlare、Fastly、EdgeCast和MaxCDN）构建了一个IP地址许可列表。

由于VirusTotal包含几乎所有向公众开放的流行URL和域黑名单列表，因此仅将Twiti中的URL和域与VirusTotal进行了比较。

用于评估的数据集和IOC。

从2020年2月到2020年4月，通过跟踪35个关键字和146个用户收集到的978,414条推文每天运行Twiti。

通过正则表达式、推文分类器和外部链接检查器删除重复和过滤后，17,904条推文归类为IOC推文和9,372条推文，包括观察列表中的外部链接。

从这些推文中，Twiti收集了32,200个唯一文件哈希值、18,718个唯一URL、70,515个唯一IP地址和11,060个唯一域。

评估收集了3个月的所有文件哈希。

同时只评估了4月份的URL、IP和域，因为每天跟踪的大量URL、IP和域很容易超过VirusTotalAPI的每日查询限制。

出于同样的原因，仅针对文件哈希将Twiti与AlienVaultOTXPulse进行了比较。

B.评价结果 （1）文件哈希 每天Twiti都会收集以前从未见过的文件哈希值。

上表显示了Twiti3个月收集的文件哈希的评估结果。

数量：Twiti在3个月内收集了32,200个文件哈希，其中2月份收集了20,837个哈希，3月份收集了5,306个哈希，4月份收集了6,057个哈希。

它们由10,022个MD5哈希（31.1%）、2,024个SHA1哈希（6.3%）和20,154个SHA256哈希（62.6%）组成。

通过向VirusTotal查询它们，发现VirusTotal中存在Twiti中的30,207个哈希值，它们对应于22,824个唯一文件。

其中，Android应用程序有982个哈希值，ELF文件有320个哈希值，iOS应用程序有33个哈希值，分别对应712、227和31个文件。

上图显示了Twiti每天收集的文件哈希数。

Twiti可以在3个月内稳定收集足够的IOC，除非一堆文件哈希来自Pastebin.com。

请注意，在2月的前几天，2-3名用户通过Pastebin.com链接共享了数百到数千个IOC。

除了那几天，平均每天提到421个文件哈希，在评估期间，Twiti平均每天可以收集200个新文件哈希。

排他性：使用它们的API将所有收集的哈希值与VirusTotal和AlienVaultOTXPulse进行了比较。

查询每个源的哈希值，然后检查是否在每个源中找到它们。

当72个防病毒引擎中的至少一个检测到它是恶意的时，将其视为存在于VirusTotal中。

换句话说，不在VirusTotal中的哈希是那些未被任何引擎检测到或在VirusTotal中找不到的哈希。

通过这样做，观察到，截至5月1日，在Twiti的32,200个文件哈希中，7.20%不在VirusTotal中，62.74%不在AlienVaultOTXPulse中。

延迟：将Twiti对文件哈希的首次检测时间定义为它在自2月以来收集的推文中的首次出现时间。

这意味着在2月1日收集的所有文件哈希都将其首次检测日期设为2月1日，尽管它们可能更早出现在Twitter上。

将此类文件散列的延迟与参考进行比较可能会错误地描述Twiti的性能。

因此，仅针对参考源中首次检测日期为2月1日或该日期之后的文件哈希计算了Twiti的延迟。

Twiti中有21,175个文件哈希值可用于与VirusTotal进行延迟比较。

其中，Twiti比VirusTotal平均早1.2天（最长27.5天）检测到814个文件哈希（3.84%），并且在VirusTotal首次检测后的24小时内检测到14,052个文件哈希（66.36%）。

为了与AlienVaultOTXPulse进行比较，可以使用Twiti中的8,508个文件哈希值。

其中，Twiti中出现5,094个文件哈希（59.87%）比AlienVaultOTXPulse平均早3.5天（最多86.2天）。

下图显示了Twiti与VirusTotal和OTXPulse相比的延迟分布。

准确性：由于VirusTotal可能存在误报并且检测可能会延迟，因此再次查询了5月底收集的所有哈希值。

然后，测量了被至少一个防病毒引擎和受信任软件标记为恶意的哈希值的比例。

在完成所有这些之后，到5月底，Twiti中92.86%的文件哈希是恶意的，0.03%是良性的，7.11%在VirusTotal中仍然未知。

在未知哈希中，10.5%来自安全供应商报告，6.6%来自恶意软件分析服务的分析报告，如混合分析和URLhaus，5.4%来自带有app.any.run结果的推文和1.9%是由蜜罐账户报告的。

这意味着它们足够可疑，尽管VirusTotal中的任何引擎都没有检测到它们。

Emotet哈希：Emotet恶意软件于2014年被发现，最近它通过分发和丢弃其他银行木马（如Trickbot、Ursnif和Ryuk有效负载），演变为充当恶意软件即服务的威胁分发者。

为了有效地抵御大量变体，TI反馈尽早收集大量Emotet哈希非常重要。

Twiti可以批量收集Emotet的恶意软件哈希。

它收集了3个月内与“emotet”一词同时出现的16,539个文件哈希（对应于11,761个恶意软件样本）。

通过向VirusTotal查询它们，观察到95.04%是恶意的，4.95%仍然未知，只有1个哈希是良性的。

与其他恶意软件哈希相比，Twiti对Emotet哈希显示出更高的准确性。

此外，Twiti比AlienVaultOTXPulse早1.8天收集了92.09%的Emotet哈希值，并且比MalwareBazaar早33.3天收集了所有Emotet哈希值。

还测量了Emotet恶意软件样本在Twiti、AlienValutOTXPulse和MalwareBazaar之间的重叠情况。

结果如下表所示。

与AlienVaultOTXPulse和MalwareBazaar相比，Twiti不仅可以高度独家地收集最多数量的Emotet恶意软件样本（77.06%和99.09%），而且可以覆盖其他恶意软件样本的三分之一公共TI反馈。

（2）URL URL的评估比文件哈希更复杂。

URL的所有者或内容随时间而变化，因此它可能在某一天是恶意的，但在另一天是良性的。

根据早期的研究认为30天是与恶意软件相关的恶意URL的生命周期，例如恶意软件分发站点或C&CURL。

下表显示了Twiti使用30天窗口收集一个月的URL的评估结果。

体积。

Twiti在4月份收集了6,873个恶意URL。

URL的平均每日数量为229。

请注意，Twiti在2月份收集了7,630个URL，在3月份收集了4,911个URL。

排他性：将收集到的URL与VirusTotal进行了比较。

每天向VirusTotal查询每个URL并检查它是否是恶意的。

为了判断一个URL是否为恶意，使用了VirusTotal的最新扫描结果。

如果VirusTotal中某个URL的最新扫描结果（lastanalysisresult）是恶意的，并且其扫描日期（lastanalysisdate）在最近30天内，则确定该URL是恶意的。

如果VirusTotal中最近一次扫描的URL是恶意的，但其扫描日期在最近30天之前，要求对该URL进行分析，当重新扫描结果为恶意时，会在VirusTotal中确定该URL是恶意的。

否则，确定URL不在VirusTotal中。

Twiti检测到2,368个不在VirusTotal中的URL，占收集到的URL的34.45%。

认为扫描更新间隔与恶意网址相对较短的生命周期之间的时间间隔使得网站扫描仪无法检测到短命的恶意网址，从而导致网址的排他率较高。

这种高度的排他性说明即使是最大的商业提要也是不完整的，因此将来自多个提要的URL聚合有利于防止恶意软件的传播。

延迟：恶意URL的延迟是通过其在Twiti中的首次检测日期与其在过去30天内有效的VirusTotal中的最新扫描日期之间的差异计算得出的。

与文件哈希类似，测量了VirusTotal中最新扫描日期为4月1日或该日期之后的URL的Twiti延迟。

Twiti中有4,229个URL可用于延迟比较。

Twiti平均比VirusTotal早1.7天发现2,191个URL(51.81%)，同一天发现1,741个URL(41.17%)，之后297个URL(7.02%)。

准确性：通过向VirusTotal发出分析请求来检查收集的URL是否真的是恶意的。

然而，这个分析请求修改了最新的扫描日期，所以上面的延迟计算结果被扭曲了。

因此进行了额外的实验。

从2020年5月1日到14日，要求VirusTotal在Twiti检测到收集到的URL后立即对其进行扫描，然后在扫描结果中测量其中有多少是恶意或可疑的。

在此期间，Twiti收集了2,386个URL。

其中，VirustTotal扫描结果中恶意网址1992个，可疑网址72个，干净网址317个，未发现网址站点5个。

由于VirusTotal中的网站扫描器无法始终提供最新结果，我们在5月底再次查询了干净的URL，发现2周后有142个干净的URL变为恶意。

因此，Twiti从5月1日到14日检测到的2,386个URL中有89.44%是真正恶意的。

包括可疑URL在内，Twiti的整体准确率为92.45%。

尽管实时扫描精度很高，但Twiti收集了7.33%的干净URL，这使得Twiti难以用作自动提要。

由于VirusTotal中的实时网络扫描程序可能会产生误报，对VirusTotal确定为干净的175个URL进行了误报(FP)分析。

FP分析结果可以在GitHub存储库中找到。

发现(i)Twiti的实际误报为98个URL，即准确率为95.89%，以及(ii)当用户发布带有参考链接的IOC时，98个干净URL中有50%来自Pastebin.com。

因此，由网络安全领域的可信域（例如，virustotal.com、app.any.run、urlhaus、abuse.ch）组成的许可名单最终可以将Twiti的准确率提高到97.53%。

（3）IP地址 IP地址具有像URL一样随时间变化的属性。

许多最近的研究假设恶意IP的生命周期为30天。

还使用30天的窗口进行评估。

下表显示了Twiti一个月收集的IP地址的评估结果。

数量：Twiti在4月份收集了12,765个恶意IP地址。

Twiti平均每天可以收集的恶意IP地址数为426。

请注意，Twiti在2月份收集了16,668个IP地址，在3月份收集了45,683个IP地址。

还调查了同期其他公共IP黑名单列表的数量。

虽然公共IP黑名单列表的数量大多很少，但Twiti可以提供大量恶意IP地址。

在公共IP黑名单列表中，AlienVaultIP声誉的数量最大，因为它报告了任何恶意IP，不仅限于恶意软件。

排他性：判断Twiti检测到的IP地址在VirusTotal中，当该IP地址在Twiti中的第一次检测日期和考虑的IP黑名单列表中的30天内在VirusTotal中被标记为恶意时。

同样，检查了Twiti中的IP是否在30天窗口内的每个IP黑名单列表中。

在上表中，为VirusTotal和每个IP黑名单列表提供了独占IP地址的比例。

与VirusTotal相比，Twiti中超过一半(53.63%)的IP地址是独占的。

Twiti对公共IP黑名单列表显示出更高的排他性(>90%)。

在公共IP黑名单列表中，Twiti与AlienVaultIP声誉的重叠度最高(9.80%)。

这表明，无论其数量如何，每个反馈对IP地址的贡献都非常独特。

延迟：将恶意IP地址的首次检测日期定义为它在30天窗口内在Twiti中出现的第一天。

与VirusTotal相比，Twiti平均可以提前5.9上表到813个IP地址。

请注意，VirusTotalAPIv3.0不提供恶意IP的检测时间，因此只能计算首先在Twiti中检测到然后在VirusTotal中检测到的IP的延迟。

计算了Twiti中首次检测日期与30天内每个黑名单列表之间的差异。

Twiti发现274个IP比AlienVaultIP声誉早10.6天，这是最大的公共IP黑名单列表之一。

与其他IP黑名单列表相比，Twiti最多可以提前25天检测到恶意IP，但它们与Twiti的重叠太小，无法讨论延迟。

准确性：与URL不同，没有扫描方法来检查Twiti检测到的IP地址是恶意的还是良性的。

因此们只测量了Twiti中有多少IP地址在使用第4.1节中列出的顶级流行域和主要CDN构建的IP许可名单中。

观察到Twiti中只有4个(0.03%)的IP被错误地报告为恶意。

（4）域 域的评估方式与IP地址完全相同。

Twiti在4月份收集的域的评估结果如下表所示。

数量、排他性和延迟：Twiti在4月份收集了3,302个恶意域名。

恶意域的平均每日数量为110。

Twiti2月份收集了4,737个域名，3月份收集了4,633个域名。

与VirusTotal相比，Twiti在4月份仅收集了1,888个域（57.18%）。

在延迟比较有效的1,414个域中，Twiti比VirusTotal提前2.5天检测到452个域（38.40%），在同一天检测到463个域（39.34%）。

准确性：与IP地址类似，仅使用Alexa、Umbrella和Majestic前25k域列表测量了Twiti中有多少良性域。

观察到，在Twiti中总共有2.57%的域在许可名单中。

C.与现有系统的比较 将Twiti与从Twitter收集IOC的现有系统进行了比较：InQuestIOCDB和TwitterIOCHunter。

在许多其他类型的IOC中，通过它们的API从两个系统收集了2周的URL。

以与Twiti完全相同的方式检查所收集URL的准确性。

评价结果如下表所示。

观察到，Twiti不仅可以比两个系统收集更多的URL，而且Twiti的准确性也比现有系统高得多。

  0x05MeasurementandAnalysis A.推特上的IOC数量 按数据源分类的IOC：Twiti从推文本身和推文中发布的链接中收集IOC。

上表显示了Twiti的数据来源以及每个来源中IOC的评估结果。

请注意，上表中的排他性和延迟是根据与VirusTotal的比较计算得出的。

观察到，推文、Pastebin.com和AlienVaultOTXPulse是通过Twitter收集IOC的主要来源——收集的文件哈希的93.26%、收集的URL的94.99%、收集的IP地址的98.75%和93.55%的收集域来自这3个数据源。

具体来说，发现： (i)Pastebin.com是推文中链接的最大IOC来源。

如上表所示，Twiti中30-70%的文件哈希、URL、IP地址和域来自Pastebin.com。

它还提供了大量新鲜的IOC。

例如，33.54%早于VirusTotal的文件哈希和80.88%早于Virustotal的URL是通过Pastebin.com共享的。

(ii)推文是恶意IP收集的最大和最独特的来源。

较短的IP长度会鼓励用户直接在推文文本中报告IP。

此外，推文文本是恶意文件哈希的第二大来源。

除了在带有Pastebin.com链接的推文中报告大量文件散列的日子外，近50%的文件散列来自推文文本。

Twiti每天可以从推文文本中提取60个新的恶意文件哈希。

(iii)AlienVaultOTXPulse是与推文相关的顶级IOC来源之一，但它带来了大量延迟的IOC。

例如，16.94%晚于VirusTotal的文件哈希来自AlienVaultOTXPulse，与VirusTotal相比，它们平均导致11天的延迟。

(iv)URLhaus是文件哈希的一个小来源，但它是新文件哈希的最大来源。

59.21%早于VirusTotal检测到的文件哈希是通过URLhaus链接报告的。

由于URLhaus不接受匿名用户的IOC，数量很少，但IOC的质量可以高于其他接受匿名提交的feed。

(v)安全厂商博客是恶意文件散列和URL的最早来源，但同时也是最迟的来源。

观察到，来自供应商全面分析报告的IOC导致显着延迟。

通过数据采集进行IOC：Twiti通过跟踪关键字和用户来收集推文，以最大化要收集的IOC数量。

观察到，Twiti收集的IOC中有31.1%完全来自关键字跟踪，16.3%完全来自用户跟踪，52.6%来自这两种方法。

有趣的是，对于文件哈希，95.9%是通过关键字跟踪获得的，只有4.1%是专门通过用户跟踪获得的。

另一方面，用户跟踪数据收集对恶意URL、IP和域收集的贡献要大得多。

观察到，23.9%的收集URL、38.6%的收集IP地址和31.8%的收集域完全来自用户跟踪。

来自商业领域的IOC：大多数安全供应商通过博客或Twitter分享他们的一小部分报告以进行营销。

安全研究人员也经常发布或转发此类信息。

这些活动使得一些商业领域的IOC数据进入了公共领域。

测量了Twiti中来自商业领域的IOC的比例。

如果IOC来自安全供应商运营的帐户，或者来自与安全博客对应的外部链接，认为IOC来自商业领域。

观察到Twiti中6%的文件哈希、5%的URL、1.2%的IP和7.5%的域来自商业域。

受数据使用限制的IOC：Twiti从与推文相关的各种来源收集IOC。

每个来源都有不同的数据使用条件。

例如，URLhaus是在CC0下获得许可的，这甚至允许将其数据用于商业用途。

通过分析各个来源的license，发现Twiti96%的IOCs可以用于非商业和商业用途，0.4%可以用于商业用途，有license可以使用，3.6%不允许用于商业用途任何商业目的。

大部分没有数据使用限制的IOC表明Twitter是开源威胁情报的良好来源。

B.推特上IOC的特征 （1）文件哈希 文件类型：对于在VirusTotal中找到的文件哈希，从VirusTotal中收集了它们的文件类型。

将VirusTotal中未找到的哈希文件类型归类为“未知”。

下图显示Twiti中文件哈希的文件类型分布。

尽管许多哈希是针对PE和MSOffice文件的，但Twitter上报告了各种类型的恶意文件，从Android、Linux、iOS文件到图像、音频和视频文件。

可以从Twitter获取一堆恶意Android应用程序的文件哈希值以及Linux恶意软件的哈希值。

请注意，2月初通过Pastebin.com获得了大量MSOffice文件的哈希值，因此Office文件在该月占主导地位。

恶意软件类型：对于Twiti中在VirusTotal中被检测为恶意的文件哈希，使用VirusTotal检测结果分析了它们的恶意软件类型。

在多个反病毒引擎的不同检测结果中选择了一个主导标签作为恶意文件哈希的恶意软件类型。

下图显示了VirusTotal检测到的文件哈希的恶意软件类型分布。

特洛伊木马是3个月内报告的最主要的威胁类型。

除了2月，Twiti中近30%的文件哈希是勒索软件。

通过按文件类型分析Twiti中文件散列的恶意软件类型分布，观察到(i)Office文件的近90%的散列是木马下载程序，(ii)28%的PE文件散列运行了软件，15%是木马银行，8%是后门，(iii)30%的Android应用程序哈希是木马银行，17%是间谍软件，12%是后门，4%是广告软件，以及(iv)64%Linux恶意软件的哈希是后门，24%是木马。

对于VirusTotal未检测到的文件哈希，分析了Twitter上下文。

上图)显示了基于Twitter上下文的这些散列的恶意软件类型分布。

虽然大多数文件哈希是在没有任何恶意软件类型信息的情况下共享的，但22.6%的文件哈希与恶意软件类型有关。

不在VirusTotal中的主要恶意软件文件哈希类型是远程访问木马(RAT)(5.5%)、网络钓鱼(5.4%)和僵尸网络(4.6%)。

恶意软件家族：在解析VirusTotal中的防病毒检测结果后，为恶意软件家族取了一个主导标签。

在下图中按操作系统显示了Twiti中文件哈希的前30个恶意软件系列。

Emotet是Twitter上报告的最大的恶意软件，这与Emotet是最普遍的威胁之一的事实一致。

在Twitter上观察到一些Emotet跟踪帐户，但Emotet哈希值主要是通过关键字跟踪收集的，这表明各种用户组报告Emotet并且Emotet是一个严重的持续威胁。

WannaCry是Twitter上第二大恶意软件。

Mirai和Gafgyt等物联网僵尸网络是Twitter上最主要的Linux恶意软件，而Lady和CoinMiner等加密货币挖掘恶意软件是第二大Linux恶意软件。

Cerberus、Hqwar、Anubis和Asacub等银行木马是Twitter上最主要的Android恶意软件，而HiddenAds和IconHider等广告软件是第二大Android恶意软件。

从2月3日到4月底，报告了使用冠状病毒网络钓鱼电子邮件的Netwalker勒索软件的几个文件哈希值。

从3月26日起，许多用户就已经提到了针对iPhone的间谍软件LightRiver超过2周。

早期检测到的哈希值：分析了Twiti检测到的文件哈希值早于VirusTotal用户。

有74个用户，其中大部分是个人恶意软件分析师。

下表给出了报告早期检测到的哈希值的顶级用户。

Hash不在VirusTotal中：分析了谁生成了独占文件哈希。

有33名用户在3个月内报告了20次以上的独占哈希。

其中70%是个人恶意软件分析师，15%是安全公司，其中近80%通过Pastebin.com链接、AlienVaultOTX链接、恶意软件沙箱链接或安全供应商博客文章报告文件哈希。

下表显示了报告独占哈希的选定顶级用户。

在Twitter上提及的持续时间：下图显示了在Twitter上提及文件哈希的天数。

大多数文件哈希已经被提及了1-2天。

仅一天就提到了近50%的文件哈希。

同时，有0.8%的文件哈希被提及超过一周，特别是NetWalker勒索软件的一个文件哈希被连续提及了35天。

恶意行为者以医疗保健部门为目标，以利用COVID-19大流行，因此许多安全专家从3月初开始在Twitter上反复警告。

（2）URL 攻击类型：对于Twiti中在VirusTotal中被检测为恶意的URL，分析了它们的VirusTotal检测结果并观察到，其中75.5%是恶意软件站点，16.5%是钓鱼站点，8%是包含漏洞或其他漏洞的恶意站点。

对5月1日至15日收集的URL获得了类似的结果，其中75.8%的恶意URL是与恶意软件相关的站点，19.6%是钓鱼站点，4.6%是恶意站点。

请注意，65%的网络钓鱼站点完全来自用户跟踪收集的推文。

此外分析了推文文本，因为它们具有有用的上下文词，例如“c2”。

观察到5.6%的收集到的URL与单词“c2”同时出现，这表明Twiti中至少5.6%的URL是C&CURL。

还观察到，不在VirusTotalco中的URL出现在“c2”中的频率几乎是VirusTotal中的2倍，这表明C&CURL通常存活时间很短，因此VirusTotal可能经常无法检测到它们。

这表明Twitter比VirusTotal在获取短期C&CURL方面更有优势。

可下载的恶意软件。

可下载的恶意软件样本对于进一步的恶意软件分析特别有用。

通过分析URL末尾给出的扩展名，观察到32.3%的收集URL包含可下载的文件扩展名，例如“pdf”、“zip”、“exe”、“apk”、“sh”、“jar””和“bin”。

（3）域 DGA（域生成算法）域：DGA域往往会在短时间内（1-3天）处于活动状态。

因此，早期检测DGA域对于黑名单列表有效很重要。

观察到Twiti中2%的域在推文中出现了“dga”一词，并且它们都比VirusTotal提前一天检测到。

此外应用了基于LSTM的DGA检测算法，并观察到Twiti中5.4%的域被归类为DGA域。

Twiti平均比VirusTotal提前1.9天检测到64%的DGA域，并且在同一天检测到18%。

  0x06Discussion 其他类型威胁的IOC：尽管专注于恶意软件IOC，但通过添加“phishing”和“spam”等关键字并重新训练推文分类器，Twiti可以轻松扩展为收集任何类型的攻击（例如，网络钓鱼、垃圾邮件、扫描）的IOC。

局限性： (1)由于Twitter是一个任何人都可以生成数据的社交媒体平台，因此存在大量新的威胁信息，但同时也可能存在虚假信息。

因此尽管在评估中观察到Twiti的高精度，但Twiti容易受到数据投毒攻击。

为了克服这一弱点，可以利用VirusTotal和IP许可名单来验证Twiti收集的IOC。

(2)由于Twiti从Pastebin.com收集IOC仅使用词过滤器，因此当将一些良性指标与恶意指标一起发布时，无法保证从中获取的IOC的准确性，正如对URL的误报分析所观察到的那样，尽管观察到Twiti的准确率很高（文件哈希为92.86%真阳性和0.03%假阳性，URL为95.89%真阳性和4.1%假阳性），但它的假阳性率不足以用作自动反馈。

然而，大多数公共TI反馈都存在误报率高的限制。

出于这个原因，公共IOC反馈在使用之前需要一个验证过程。

为了进一步减少Twiti中的FP，可以将Twiti用作(i)由用户选择的自动反馈，类似于AlienVaultOTX中的选择性脉冲订阅，以及(ii)其他协作安全系统（如多IP反馈聚合器）的初始来源或域拆卸系统。

(iii)从外部链接收集IOC使得Twiti大量收集各种类型的IOC，但带来了对外部来源的额外依赖。

因此，对于免费和开源威胁情报，Twiti无法利用限制数据使用的外部来源。

  0x07Conclusion 在本文中提出了一种用于Twitter的高保真IOC提取系统。

通过对收集到的IOC的广泛评估，证明所提议的系统能够比其他公共TI反馈更早地收集独特且准确的恶意软件IOC。

这使得Twitter成为一个有价值的开源威胁情报源。

还展示了Twitter能够以高精度和早期的方式捕获大量正在进行的恶意软件攻击。

通过从各个方面分析IOC的特征，可以更好地了解Twitter上的恶意软件IOC，以及如何利用Twitter对抗恶意软件威胁的指南。

本文翻译自dl.acm.org， 原文链接 。

如若转载请注明出处。

恶意软件威胁情报 赞( 37) 收藏 CDra90n认证 分享到： |推荐阅读 Nomad跨链桥被盗1.8亿美元事件分析 2022-08-0514:30:06 CVE-2022-26138ConfluenceServer硬编码漏洞分析 2022-08-0510:30:08 补丁分析发现Zyxel认证绕过(CVE-2022-0342) 2022-08-0414:30:52 无文件恶意软件攻击 2022-08-0410:30:56 |发表评论 发表评论 |评论列表 还没有评论呢，快去抢个沙发吧~ 加载更多 CDra90n "Thisisonlyaforetasteofwhatistocome,andonlytheshadowofwhatisgoingtobe." 文章 119 粉丝 29 关注 TA的文章 针对社交网络中恶意滥用账户的分类检测 2022-02-2310:30:00 针对Cookie同意和GDPR违规的自动化检测工具 2022-02-2110:30:39 SocialHEISTing：针对Facebook被盗账户的统计数据研究 2022-02-1614:30:39 电动汽车充电站管理系统安全深度分析 2022-02-0710:00:51 苹果无线生态系统安全性指南 2022-01-2010:00:30 相关文章 “验证器”（Validator）—美国国家安全局NSA（APT—C—40）的木马尖兵 PBot挖矿僵尸网络正利用新漏洞发起攻击 特洛伊学院的高材生 会“说话”的银行木马 疑似蔓灵花APT组织伪装多国身份攻击孟加拉国 美国中央情报局（CIA）“蜂巢”恶意代码攻击控制武器平台分析报告 2022年3月勒索病毒态势分析 热门推荐 文章目录 0x01Introduction0x02TWITI：DesignandImplementation A.推文收集器B.相关推文选择器C.IOC提取器 0x03DesignChoice0x04Evalution A.评估设置B.评价结果C.与现有系统的比较 0x05MeasurementandAnalysis A.推特上的IOC数量B.推特上IOC的特征 0x06Discussion0x07Conclusion