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

1

Introduction

恶意软件攻击每年都在增加。特别是，通过网站传播的恶意软件正在迅速增加。正如在 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。最容易访问的来源是公共恶意软件黑名单列表，例如 Feodo tracker 和 AlienVault IP 声誉 。安全供应商博客是 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 的见解。

2

TWITI:Design and Implementation

下图说明了 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 模式匹配（例如，Tuleap 9.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 句柄和 CVE ID 也被替换为“[username]”和“[cve]”。所有数字都替换为“[num]”。

(2) 命名实体识别 (NER) 应用于每条推文。标记为恶意软件的词被替换为“[malware_name]”。

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

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

(5) 推文是小写的。跟踪的关键字及其别名由单个标记形式的单个代表性术语替换。例如，“c&c”、“cnc”和“command and-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推文。

特征：认为以下是初始特征：

• Defanged IOCs：此功能检查每条推文中是否至少有一个defanged IOC。在推特上发布 IOC 时，defang 技术通常应用于 IP 地址、URL 和域，以防止意外暴露于恶意活动内容。此类推文的示例包括“#gandcrab @ hxxp://92.63.197.106/c.exe”、“#Roam ingMantis new landing pages：67[.] 198.129.27 …”、“#darkcomet /elumadns.eluma101 .com …”，“This app impersonate…#c2 hold[.]jcgloball[.]org:11880”。

• 上下文n-gram：这些是围绕IOC 关键词的上下文词。使用的关键词是被跟踪的关键字（例如， “malware”, “ransomware”, “botnet”）、“[hash]”、“[ip]”、“[url]”、“[domain]”和“[malware_name]”。很明显，在 IOC 和非 IOC 推文中，有关感兴趣模式的词会大不相同。例如，“version [ip]”、“up to [ip]”、“before [ip]”、“preor to [ip]”和“commit [hash]”清楚地出现在关于软件漏洞的推文中，而“ hash [hash]”、“c2 [url]”、“c2 [ip]”、“botnet c2”、“from [ip]”、“ransomware [hash]”、“[file name] [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 ∈ {IOC tweet, non-IOC tweet}，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 从 Twitter API 检索“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 从 AlienVault OTX收集 IOC。

请注意，几乎所有安全供应商博客都在其服务条款中严格限制对其数据的使用。因此，Twiti 从数百个供应商博客中的 IOC 数量中收集了 10 个主要安全供应商博客的数据，仅供参考，以提供有关从安全供应商收集的 IOC 数据的见解。

3

Design Choice

以下是对 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 中的常用词和规范化的词，如“[mal ware_name]”和“[cve]”。删除可能导致很多误报的一般词后，得到了 35 个词。

推特用户的选择：为了使基于用户的数据收集与基于关键字的数据收集相辅相成，选择了满足以下任一条件的 Twitter 用户：

(1) 用户是否经常在没有上述关键词的情况下提及 IOC？

(2) 用户是包含 IOC 的转推的原始推文作者还是在有关 IOC 的讨论中？

(3) 用户是否是 IOC 的贡献者？

(4) 用户的个人资料中是否包含 “malware”, “ransomware”, “threat hunter”, “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% 来自 AlienVault OTX。

4

Evalution

A.评估设置

评估指标：为了评估 Twiti 的性能，通过将 Twiti 收集的 IOC 与选定的参考源进行比较来测量数量、排他性、延迟和准确性。对于每种类型（例如文件哈希）的指标，定义了：

• 数量，作为评估期间饲料中指标的总数。

• 排他性，即 Twiti 中指标在其生命周期内不在参考源中的比例。它的正式形式为 |Twiti\A|/|Twiti|。

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

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

覆盖率（反馈捕获的预期指标的比例）是一个重要的性能指标。然而，在缺乏所有持续威胁的真实情况的情况下，很难衡量覆盖率。所以，改为测量当反馈中的整套指标可用时，Twiti 捕获的反馈中指标的比例。参考来源。下表总结了用于评估的参考来源。使用 VirusTotal 作为一个基本事实来衡量哈希和 URL 的准确性。还使用 VirusTotal 来衡量所有 IOC 类型的独占性和延迟。VirusTotal 不仅是一项分析可疑文件和 URL 以检测恶意软件的服务，而且还是最大的 TI 反馈，由 72 个防病毒引擎和 68 个网站/域扫描引擎和黑名单列表支持。

与 VirusTotal 相比，高排他性和低延迟将是 Twiti 作为 TI 反馈实力的一个很好的指标。请注意，使用 VirusTotal 私有 API v3.0 来获取有关文件哈希、URL、IP 地址和域的报告，以用于研究目的。还使用了以下参考：

(i) 对于文件哈希，将 Twiti 与 AlienVault OTX Pulse 和 Mal wareBazaar进行了比较。他们都不是 VirusTotal 的贡献者。AlienVault OTX 是最大的开放威胁交换平台，任何人都可以通过脉冲订阅来订阅 IOC。MalwareBazaar 声称其三分之二的样本未被 VirusTotal 检测到。

(ii) 对于域，使用 Alexa top 1M、Cisco Umbrella top 1M和 Majestic 1M数据中的前 25k 域来检查有多少良性域被报告为恶意。对于每个 25k 域集，们在评估期间连续出现的域，因为列表中可能存在一段时间的恶意域。

(iii) 对于 IP 地址，将 Twiti 与一些与恶意软件相关的公共 IP 黑名单列表进行了比较。选定的公共 IP 黑名单列表包括 AlienVault IP Reputation、Bambenek_c2、Feodo Tracker、SSL 黑名单和 Mirai 相关反馈。为了衡量准确性，使用上述顶级 25k 域数据和主要内容交付网络 (CDN) 服务（AWS CloudFront、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 和域很容易超过 VirusTotal API 的每日查询限制。出于同样的原因，仅针对文件哈希将 Twiti 与 AlienVault OTX Pulse 进行了比较。

B.评价结果（1）文件哈希

每天Twiti 都会收集以前从未见过的文件哈希值。上表显示了 Twiti 3 个月收集的文件哈希的评估结果。

数量：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 和 AlienVault OTX Pulse 进行了比较。查询每个源的哈希值，然后检查是否在每个源中找到它们。当 72 个防病毒引擎中的至少一个检测到它是恶意的时，将其视为存在于 VirusTotal 中。换句话说，不在 VirusTotal 中的哈希是那些未被任何引擎检测到或在 VirusTotal 中找不到的哈希。通过这样做，观察到，截至 5 月 1 日，在 Twiti 的 32,200 个文件哈希中，7.20% 不在 VirusTotal 中，62.74% 不在 AlienVault OTX Pulse 中。

延迟：将 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%）。为了与 AlienVault OTX Pulse 进行比较，可以使用 Twiti 中的 8,508 个文件哈希值。其中，Twiti 中出现 5,094 个文件哈希（59.87%）比 AlienVault OTX Pulse 平均早 3.5 天（最多 86.2 天）。下图显示了 Twiti 与 VirusTotal 和 OTX Pulse 相比的延迟分布。

准确性：由于 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 比 AlienVault OTX Pulse 早 1.8 天收集了 92.09% 的 Emotet 哈希值，并且比 MalwareBazaar 早 33.3 天收集了所有 Emotet 哈希值。还测量了 Emotet 恶意软件样本在 Twiti、AlienValut OTX Pulse 和 MalwareBazaar 之间的重叠情况。结果如下表所示。与 AlienVault OTX Pulse 和 MalwareBazaar 相比，Twiti 不仅可以高度独家地收集最多数量的 Emotet 恶意软件样本（77.06% 和 99.09%），而且可以覆盖其他恶意软件样本的三分之一公共 TI 反馈。

（2）URL

URL 的评估比文件哈希更复杂。URL 的所有者或内容随时间而变化，因此它可能在某一天是恶意的，但在另一天是良性的。根据早期的研究认为 30 天是与恶意软件相关的恶意 URL 的生命周期，例如恶意软件分发站点或 C&C URL。下表显示了 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 的最新扫描结果（last analysis result）是恶意的，并且其扫描日期（last analysis date）在最近 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。其中，Virust Total扫描结果中恶意网址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 黑名单列表中，AlienVault IP 声誉的数量最大，因为它报告了任何恶意 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 与 AlienVault IP 声誉的重叠度最高 (9.80%)。这表明，无论其数量如何，每个反馈对 IP 地址的贡献都非常独特。

延迟：将恶意 IP 地址的首次检测日期定义为它在 30 天窗口内在 Twiti 中出现的第一天。与 VirusTotal 相比，Twiti 平均可以提前 5.9上表到 813 个 IP 地址。请注意，VirusTotal API v3.0 不提供恶意 IP 的检测时间，因此只能计算首先在 Twiti 中检测到然后在 VirusTotal 中检测到的 IP 的延迟。计算了 Twiti 中首次检测日期与 30 天内每个黑名单列表之间的差异。Twiti 发现 274 个 IP 比 AlienVault IP 声誉早 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。Twiti 2 月份收集了 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 的现有系统进行了比较：InQuest IOC DB和 Twitter IOC Hunter。在许多其他类型的 IOC 中，通过它们的 API 从两个系统收集了 2 周的 URL。以与 Twiti 完全相同的方式检查所收集 URL 的准确性。评价结果如下表所示。观察到，Twiti 不仅可以比两个系统收集更多的 URL，而且 Twiti 的准确性也比现有系统高得多。

5

Measurement and Analysis

A.推特上的IOC数量

按数据源分类的 IOC：Twiti 从推文本身和推文中发布的链接中收集 IOC。上表显示了 Twiti 的数据来源以及每个来源中 IOC 的评估结果。请注意，上表中的排他性和延迟是根据与 VirusTotal 的比较计算得出的。观察到，推文、Paste bin.com 和 AlienVault OTX Pulse 是通过 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% 早于 Virus Total 的文件哈希和 80.88% 早于 Virustotal 的 URL 是通过 Pastebin.com 共享的。

(ii) 推文是恶意 IP 收集的最大和最独特的来源。较短的 IP 长度会鼓励用户直接在推文文本中报告 IP。此外，推文文本是恶意文件哈希的第二大来源。除了在带有 Pastebin.com 链接的推文中报告大量文件散列的日子外，近 50% 的文件散列来自推文文本。Twiti 每天可以从推文文本中提取 60 个新的恶意文件哈希。

(iii) AlienVault OTX Pulse 是与推文相关的顶级 IOC 来源之一，但它带来了大量延迟的 IOC。例如，16.94% 晚于 VirusTotal 的文件哈希来自 AlienVault OTX Pulse，与 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，发现Twiti 96%的IOCs可以用于非商业和商业用途，0.4%可以用于商业用途，有license可以使用，3.6%不允许用于商业用途任何商业目的。大部分没有数据使用限制的 IOC 表明 Twitter 是开源威胁情报的良好来源。

B.推特上IOC的特征（1）文件哈希

文件类型：对于在 VirusTotal 中找到的文件哈希，从 VirusTotal 中收集了它们的文件类型。将 VirusTotal 中未找到的哈希文件类型归类为“未知”。下图显示Twiti 中文件哈希的文件类型分布。尽管许多哈希是针对 PE 和 MS Office 文件的，但 Twitter 上报告了各种类型的恶意文件，从 Android、Linux、iOS 文件到图像、音频和视频文件。可以从 Twitter 获取一堆恶意 Android 应用程序的文件哈希值以及 Linux 恶意软件的哈希值。请注意，2 月初通过 Pastebin.com 获得了大量 MS Office 文件的哈希值，因此 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 链接、AlienVault OTX 链接、恶意软件沙箱链接或安全供应商博客文章报告文件哈希。下表显示了报告独占哈希的选定顶级用户。

在 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&C URL。还观察到，不在 VirusTotal co 中的 URL 出现在“c2”中的频率几乎是 VirusTotal 中的 2 倍，这表明 C&C URL 通常存活时间很短，因此 VirusTotal 可能经常无法检测到它们。这表明 Twitter 比 VirusTotal 在获取短期 C&C URL 方面更有优势。可下载的恶意软件。可下载的恶意软件样本对于进一步的恶意软件分析特别有用。通过分析 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%。

6

Discussion

其他类型威胁的 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) 由用户选择的自动反馈，类似于 AlienVault OTX 中的选择性脉冲订阅，以及 (ii) 其他协作安全系统（如多 IP 反馈聚合器）的初始来源或域拆卸系统。(iii)从外部链接收集IOC使得Twiti大量收集各种类型的IOC，但带来了对外部来源的额外依赖。因此，对于免费和开源威胁情报，Twiti 无法利用限制数据使用的外部来源。

7

Conclusion

在本文中提出了一种用于 Twitter 的高保真 IOC 提取系统。通过对收集到的 IOC 的广泛评估，证明所提议的系统能够比其他公共 TI 反馈更早地收集独特且准确的恶意软件 IOC。这使得 Twitter 成为一个有价值的开源威胁情报源。还展示了 Twitter 能够以高精度和早期的方式捕获大量正在进行的恶意软件攻击。通过从各个方面分析 IOC 的特征，可以更好地了解 Twitter 上的恶意软件 IOC，以及如何利用 Twitter 对抗恶意软件威胁的指南。

- 结尾 -

【技术分享】BrokenStrokes：针对无线键盘的三类攻击

【技术分享】Office文档安全：以ODF和OOXML为例

【技术分享】Horus：发现并分析对以太坊智能合约的攻击

戳“阅读原文”查看更多内容