Twitter 是一個流行的威脅追蹤公共資源，許多安全供應商和安全專家在實踐中使用 Twitter 來收集入侵指標 (IOC, Indicators of Compromise)。然而，在 Twitter 上對 IOC 的研究甚少。它們的重要特征從未被研究過，如早期性、唯一性和準確性。而且，如何從 Twitter 中高精度地提取 IOC并不明顯。在本文中介紹了 Twiti，這是一個從 Twitter 自動提取各種形式的惡意軟件 IOC 的系統(tǒng)，Twiti 的源代碼可在 https://github.com/Samsung/Twiti 獲得?；谑占降?IOC，對 Twitter 上的惡意軟件 IOC 進行了首次實證評估和徹底分析。Twiti 通過利用自然語言處理和機器學習技術從被識別為具有惡意軟件 IOC 信息的推文中提取 IOC。通過廣泛的評估，證明 Twiti 不僅可以準確地提取惡意軟件 IOC，而且提取的 IOC 是唯一且早期的。通過從各個方面分析 Twiti 中的 IOC，發(fā)現(xiàn) Twitter 比其他公共威脅情報 (TI) 反饋更好地捕獲持續(xù)的惡意軟件威脅，例如 Emotet 變體和惡意軟件分發(fā)站點。還發(fā)現(xiàn) Twitter 上只有一小部分 IOC 來自商業(yè)供應商帳戶、個人 Twitter 用戶是早期發(fā)現(xiàn)或獨家 IOC 的主要貢獻者，這表明 Twitter 可以提供許多在商業(yè)領域發(fā)現(xiàn)的有價值的 IOC。

1

Introduction

惡意軟件攻擊每年都在增加。特別是，通過網(wǎng)站傳播的惡意軟件正在迅速增加。正如在 Dyn 攻擊和 Garmin 勒索軟件攻擊中所見，惡意軟件可以迅速傳播，其破壞可能是災難性的。考慮到其風險，預防是最好的防御。盡管存在一些基于預測的惡意軟件檢測解決方案，但入侵指標 (IOC) 是防御惡意軟件的關鍵。IOC 是網(wǎng)絡攻擊的取證工件，因此它們能夠檢測系統(tǒng)或網(wǎng)絡上的入侵企圖或任何其他惡意活動。當及時提供最新的 IOC 時，它們在保護系統(tǒng)或網(wǎng)絡免受未來攻擊方面發(fā)揮著關鍵作用。IOC 的示例包括惡意文件的 MD5 哈希值、IP 地址、僵尸網(wǎng)絡的 URL 或域以及文件名。

大多數(shù)組織訂閱威脅情報 (TI) 源以接收惡意軟件 IOC，但單個源是不夠的。許多 tivirus 解決方案和商業(yè) TI 源通常不會立即反映新的或正在進行的攻擊的 IOC。由于這些原因，許多行業(yè)和安全專業(yè)人士通過開源威脅情報豐富了 IOC。根據(jù) 2019 年對北美和英國 1,908 名 IT 和安全從業(yè)人員的調(diào)查，至少 37% 的受訪者表示他們的組織將公共 TI 訂閱源與商業(yè)訂閱源一起使用（41% 的受訪者表示他們的組織使用一個付費 TI 反饋，而 78% 的人回應使用多個 TI 反饋）。

展開全文

有很多公共資源可以收集惡意軟件 IOC。最容易訪問的來源是公共惡意軟件黑名單列表，例如 Feodo tracker 和 AlienVault IP 聲譽 。安全供應商博客是 IOC 挖掘的另一個常見來源。安全郵件列表、安全論壇和暗網(wǎng)也經(jīng)常用于 IOC 搜索 。在眾多公共資源中，Twitter 保證攻擊的數(shù)量、及時性和多樣性。它通過將推文鏈接到外部站點來從整個網(wǎng)絡帶來大量內(nèi)容，這使 Twitter 能夠涵蓋來自各種來源的大量新 IOC，例如安全供應商博客、蜜罐和惡意軟件沙箱。這使得許多安全供應商在實踐中利用 Twitter 進行 IOC 搜索。

然而，由于 Twitter 的獨特特性，如文本短、非標準語言以及與推文相關的外部來源多樣，從 Twitter 中挖掘出高精度的 IOCs 并不明顯。有一些開放系統(tǒng)從 Twitter 收集 IOC。但是，正如稍后展示的那樣，實驗表明在 Twitter 上使用 IOC 時，兩個系統(tǒng)的覆蓋率和準確性都不令人滿意。因此開發(fā)了 Twiti，一個用于 Twitter 的自動 IOC 提取系統(tǒng)。Twiti 使用推文分類器和選定的外部源列表識別可能包含惡意軟件 IOC 的推文。然后它從推文和推文中的外部鏈接中提取 IOC。這種方法使 Twiti 能夠以高精度收集大量 IOC。

此外，盡管 Twitter 作為 IOC 的數(shù)據(jù)源廣受歡迎，但人們對從中收集的 IOC 知之甚少——Twitter 上有多少 IOC、它們有多新、多準確、與其他公共或商業(yè)機構(gòu)相比有多獨特TI 反饋、報告了哪些惡意軟件 IOC、誰報告了獨家 IOC、Twitter 上有多少 IOC 可以用于任何目的、可以從外部鏈接獲取多少 IOC等等。為了回答這些問題，通過 Twiti 收集惡意文件哈希以及與惡意軟件相關的 IP 地址、域和 URL。然后評估數(shù)量、延遲、準確性和排他性。最終從數(shù)據(jù)源、文件類型到惡意軟件類型等各個方面分析了收集到的 IOC 的特征，以提供有關 Twitter 上 IOC 的見解。

2

TWITI:Design and Implementation

下圖說明了 Twiti 的架構(gòu)。Twiti 由三個步驟組成——數(shù)據(jù)收集、相關推文選擇和 IOC 提取。Twiti 旨在以高精度收集盡可能多的與惡意軟件相關的 IOC。為了實現(xiàn)這一目標，在 2019 年 11 月進行了一項試點研究，精心設計了數(shù)據(jù)收集器和 IOC 提取器。

A.推文收集器

為了最大化要收集的 IOC 的數(shù)量，Twiti 主要通過使用 Twitter 搜索 API 的關鍵字跟蹤來收集數(shù)據(jù)，其次是使用時間線 API通過用戶跟蹤來收集數(shù)據(jù)。跟蹤了 35 個可能與惡意軟件 IOC 一起出現(xiàn)的關鍵字。關鍵字的示例包括 “malware”、“ransomware”、“botnet”、“spyware”、“adware”、“malspam”、“iocs” 和“virustotal.com”。此外，還跟蹤了 146 名 Twitter 用戶，其中包括 86% 的安全專家、12% 的安全供應商和 2% 的其他安全組織。請注意，在 125 位安全專家中，67% 的人在他們的個人資料中將自己介紹為惡意軟件分析師、惡意軟件研究員、威脅獵人d或威脅情報研究員。另請注意，Twiti 會收集轉(zhuǎn)發(fā)的原始推文并從中提取 IOC。

B.相關推文選擇器

使用模式匹配簡單提取 IOC 會導致許多誤報。大多數(shù)推文都包含他們自己的推文或參考的鏈接（例如，https://t.co/qQdme1Buxh）。一些推文提到軟件版本與 IP 模式匹配（例如，Tuleap 9.17.99.189）。一些推文提到了用于引用提交 ID 或區(qū)塊鏈交易的哈希值。為了減少這種誤報，Twiti 首先處理推文中的鏈接，然后對推文進行分類以過濾掉那些沒有 IOC 的推文。

（1）推文預處理器

短URL移除器：Twitter 的 t.co 服務會自動縮短推文中發(fā)布的所有鏈接（URL）。由于 Twitter 轉(zhuǎn)換的鏈接會針對潛在危險站點進行檢查，因此會從文本中刪除“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]”，分別。請注意，所有經(jīng)過修改的 URL、IP 地址和域都被轉(zhuǎn)換為它們的代表標記，例如“[url]”。Twitter 句柄和 CVE ID 也被替換為“[username]”和“[cve]”。所有數(shù)字都替換為“[num]”。

(2) 命名實體識別 (NER) 應用于每條推文。標記為惡意軟件的詞被替換為“[malware_name]”。

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

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

(5) 推文是小寫的。跟蹤的關鍵字及其別名由單個標記形式的單個代表性術語替換。例如，“cc”、“cnc”和“command and-control”被替換為“c2”。

(6) 對推文進行標記化并對每個單詞應用詞形還原，以將單詞的屈折形式表示為單個單詞。停用詞被刪除。刪除由單個字符“[username]”和“[num]”組成的詞。

請注意，現(xiàn)有的 NER 工具如 NLTK、CoreNLP和 twitter_nlp未在網(wǎng)絡安全領域接受過訓練。因此，使用提及網(wǎng)絡安全事件的推文訓練了 Bert 模型，并在步驟 (2) 中使用了它?；?Bert 的 NER 的詳細信息可以在 https://github.com/Samsung/Twiti上找到。

（2）推文分類器

開發(fā)了一種高性能推文分類器，用于確定推文是否包含 IOC。在下文中根據(jù)是否包含 IOC 將推文稱為 IOC 推文或非 IOC 推文。

數(shù)據(jù)集：為了構(gòu)建 IOC 推文分類器，收集了 2019 年 1 月至 9 月包含 IOC 模式的推文。在此期間，可以收集 21,937 條推文。去除Jaccard相似度大于0.70的相似推文后，剩余5675條推文。三位安全專家手動注釋每條推文是否包含任何 IOC。有 3,007 條IOC推文和 2,668 條非IOC推文。

特征：認為以下是初始特征：

? Defanged IOCs：此功能檢查每條推文中是否至少有一個defanged IOC。在推特上發(fā)布 IOC 時，defang 技術通常應用于 IP 地址、URL 和域，以防止意外暴露于惡意活動內(nèi)容。此類推文的示例包括“#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]”清楚地出現(xiàn)在關于軟件漏洞的推文中，而“ hash [hash]”、“c2 [url]”、“c2 [ip]”、“botnet c2”、“from [ip]”、“ransomware [hash]”、“[file name] [hash]”、和“[malware_name] md5s [hash]”絕對屬于IOC的推文。為了提取這樣的上下文特征，首先將文本預處理 (1)-(5) 應用于每條推文。然后提取由目標詞及其左右兩側(cè)的 1-2 個詞組成的二元詞組和三元詞組。

? 詞袋：與IOC 共同出現(xiàn)的詞也不同于非IOC 推文中的詞。例如，“c2”、“md5s”、“yara”、“botnet”、“[malware_name]”、“ransomware”顯然更多地出現(xiàn)在IOC的推文中。相反，在 IOC 推文中不太可能觀察到“[cve]”、“csrf”、“0daytoday”、“vulnerability”、“xss”和“sql”。文本預處理（1）-（6）用于提取單詞。然后刪除常見的英語單詞。通過將詞形還原詞視為特征，可以考慮在上下文特征中無法考慮的詞變異。

請注意，這里的所有特征都是二元特征。也就是說，如果每個特征在推文中，則取值為 1，否則取值為 0。

特征選擇：并非所有特征對分類都很重要。選擇了使用互信息 (MI) 將 IOC 推文與非 IOC 推文區(qū)分開來的特征。對于特征 X 和類標簽 Y ∈ {IOC tweet, non-IOC tweet}，X 和 Y 的互信息計算如下：

其中 PX,Y 是 X 和 Y 的聯(lián)合分布，PX , PY 分別是 X 和 Y 的邊際分布。MI 衡量知道 X 減少了關于 Y 的不確定性的程度，反之亦然。例如，如果 X 和 Y 是獨立的，那么知道 X 并不會給出關于 Y 的任何信息，因此它們的 MI 為零。因此，MI 能夠選擇有助于區(qū)分 IOC 推文和非 IOC 推文的特征。取 MI 大于 0.0002 的詞和 n-gram。選擇閾值是為了最大化分類器的預測性能。

分類器：有 22,316 個初始特征。特征選擇后，保留了 1,456 個特征。它們包含 483 個單詞（unigrams）和 972 個二元詞和三元詞?？紤]了 3 個分類器——邏輯回歸、隨機森林和 XGBoost。使用由 3,007 條 IOC 推文和 2,668 條非 IOC 推文組成的數(shù)據(jù)集使用 5 折交叉驗證評估了這些分類器。選擇了隨機森林分類器，因為它表現(xiàn)出最好的性能——精度為 0.95，召回率為 0.96。在下圖中展示了 3 個分類器的 ROC 曲線，在下表中展示了隨機森林分類器的重要特征示例。

（3）外部鏈接檢查器

由于推文文本簡潔（280 個字符限制），用戶經(jīng)常通過外部鏈接分享詳細信息。因此通過分析試點研究中推文中的外部鏈接，構(gòu)建了一個外部來源列表，這些來源為大量 IOC 提供了較小的誤報。由于推文中的所有鏈接都被 Twitter 縮短，Twiti 從 Twitter API 檢索“http://t.co”鏈接的完整URL。然后檢查完整的 URL 是否來自選定的外部源。

C.IOC 提取器

在 Twitter 上，有各種與威脅相關的信息，從漏洞、漏洞利用和惡意軟件到異常網(wǎng)絡活動。但是，此類信息的詳細程度因作者而異。一些 Twitter 用戶發(fā)布 CC 服務器或其他有價值的 IOC 信息，如 IP 地址、URL 和文件哈希。另一方面，其他用戶在沒有太多細節(jié)的情況下分享他們的發(fā)現(xiàn)或經(jīng)驗。根據(jù)信息的詳細程度，從 Twitter 尋找 IOC 的方法有所不同。在 Twiti 中，IOC 提取器會遇到以下兩種情況：

? 例1：推文中的IOC。

? 例2：推文中沒有 IOC，但外部鏈接中有 IOC

從推文中提取 IOC：Twiti 首先通過正則表達式的模式匹配在推文文本中查找 IOC。但是，某些類型的 IOC（例如 URL 和 IP 地址）通常會被破壞，以避免無意中點擊惡意鏈接。從評估中發(fā)現(xiàn) 38% 的收集到的 IP 被篡改，73% 的收集到的 URL 被篡改。這表明 Twitter 在處理 defang 技術方面比在安全博客、論壇和郵件列表中面臨更多挑戰(zhàn)。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 月收集的推文中嵌入的鏈接。從分析發(fā)現(xiàn)，安全供應商博客、惡意軟件分析服務和 Pastebin.com 是 IOC 的主要來源。針對不同類型的數(shù)據(jù)源分別開發(fā)IOC提取器如下：

? Pastebin.com：觀察到 Pastebin.com 是推文中給出的頂級外部鏈接之一。這是一個用戶可以在線存儲文本的網(wǎng)站。正如稍后展示的，Twiti 收集的許多 IOC 都來自它。在 Pastebin 中，有來自源代碼片段、泄露到 IOC 的憑據(jù)的各種類型的信息。因此，對于 IOC 集合，在推文中搜索 Pastebin.com 的所有鏈接并不是一個好主意。因此，分析了與 Pastebin.com 共現(xiàn)的詞，并在應用文本預處理 (1)-(6) 后提取了前 50 個詞。經(jīng)過人工審核，最終選擇了18個詞。

此類詞的示例包括“惡意軟件”、“malware”, “ransomware”, “trojan”, “botnet”、“[malware_name]”、“c2”、“ioc”和“payload”。當這些詞與 Pastebin.com 鏈接一起出現(xiàn)時，Twiti 從 Pastebin 收集 IOC。

? 惡意軟件分析服務：觀察到推文中的IOC 通常與分析報告的鏈接一起提供。從外部鏈接分析中，觀察到推文中發(fā)布的 57% 的分析報告來自 VirusTotal，33% 來自 Any.Run，7% 來自 urlscan.io，3% 來自其余惡意軟件分析服務.其中許多在給定的鏈接文本中包含 IOC，但有些在其站點中提供 IOC。在后一種情況下，Twiti 使用他們的 API 收集 IOC。請注意，雖然觀察到許多早于 VirusTotal 的惡意文件哈希經(jīng)常通過 app.any.run 報告，但 Twiti 無法從 Any.Run 收集 IOC，因為它沒有提供公共 API。

? 安全供應商博客：從外部鏈接分析中觀察到 100 多個安全供應商博客。每個供應商在提供 IOC 時都有自己的格式。因此，需要為每個博客開發(fā)專用的解析器。

? 除了上面提到的那些，Twiti 使用 API 從 AlienVault OTX收集 IOC。

請注意，幾乎所有安全供應商博客都在其服務條款中嚴格限制對其數(shù)據(jù)的使用。因此，Twiti 從數(shù)百個供應商博客中的 IOC 數(shù)量中收集了 10 個主要安全供應商博客的數(shù)據(jù)，僅供參考，以提供有關從安全供應商收集的 IOC 數(shù)據(jù)的見解。

3

Design Choice

以下是對 Twiti 的設計選擇，以盡可能多地收集惡意軟件 IOC，并具有較小的誤報。

數(shù)據(jù)收集方法：有兩種方法可以從 Twitter 收集數(shù)據(jù)——(i) 關鍵字跟蹤和 (ii) 用戶跟蹤。為了確定 Twiti 的數(shù)據(jù)收集方法，試驗了兩種方法之間 IOC 數(shù)量的差異。在實驗中，在 2019 年 11 月跟蹤了 35 個關鍵字和 82 個 Twitter 用戶。觀察到，收集的 IOC 中有 36.2% 來自關鍵字跟蹤，25.6% 來自用戶跟蹤，38.2% 來自兩者。因此決定利用這兩種方式來最大化 IOC 收集。由于關鍵詞追蹤對IOC的拉動更大，更容易擴展，所以Twiti使用關鍵詞追蹤作為主要的數(shù)據(jù)收集方法，用戶追蹤作為輔助方法。

關鍵詞的選擇：選擇了可能與 IOC 共同出現(xiàn)的關鍵字，但不要制造太多噪音。使用數(shù)據(jù)集提取了在 IOC 推文中比非 IOC 推文中出現(xiàn)次數(shù)更多的前 100 個單詞。應用了文本預處理 (1)-(6)，然后刪除了 Twitter 中的常用詞和規(guī)范化的詞，如“[mal ware_name]”和“[cve]”。刪除可能導致很多誤報的一般詞后，得到了 35 個詞。

推特用戶的選擇：為了使基于用戶的數(shù)據(jù)收集與基于關鍵字的數(shù)據(jù)收集相輔相成，選擇了滿足以下任一條件的 Twitter 用戶：

(1) 用戶是否經(jīng)常在沒有上述關鍵詞的情況下提及 IOC？

(2) 用戶是包含 IOC 的轉(zhuǎn)推的原始推文作者還是在有關 IOC 的討論中？

(3) 用戶是否是 IOC 的貢獻者？

(4) 用戶的個人資料中是否包含 “malware”, “ransomware”, “threat hunter”, “threatintel”等詞？

通過分析數(shù)據(jù)集及其個人資料來收集此類用戶，提取了至少創(chuàng)建了一條沒有關鍵字的 IOC 推文并且其帳戶處于活動狀態(tài)的作者。此外，在IOC推文的前后文本中提取用戶，因為觀察到位于IOC推文開頭和結(jié)尾的用戶屬于條件（2）-（3）。然后保留了在 IOC 推文中出現(xiàn)統(tǒng)計顯著大于非 IOC 推文的用戶。最后分析了收集到的用戶的帳戶資料，發(fā)現(xiàn)其中許多人自我介紹為惡意軟件分析師、惡意軟件研究人員、威脅獵人或威脅情報研究人員。從他們的個人資料中提取了一些重要的詞，然后收集了更多的 Twitter 用戶，包括這些詞。經(jīng)過以上所有流程和人工審核，最終選出了 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 與選定的參考源進行比較來測量數(shù)量、排他性、延遲和準確性。對于每種類型（例如文件哈希）的指標，定義了：

? 數(shù)量，作為評估期間飼料中指標的總數(shù)。

? 排他性，即 Twiti 中指標在其生命周期內(nèi)不在參考源中的比例。它的正式形式為 |Twiti\A|/|Twiti|。

? 延遲是指Twiti 首次檢測到指標與其生命周期內(nèi)首次出現(xiàn)在參考源之間所經(jīng)過的時間。

? 準確度是指反饋中真正惡意的指標的比例，它對應于準確度。

覆蓋率（反饋捕獲的預期指標的比例）是一個重要的性能指標。然而，在缺乏所有持續(xù)威脅的真實情況的情況下，很難衡量覆蓋率。所以，改為測量當反饋中的整套指標可用時，Twiti 捕獲的反饋中指標的比例。參考來源。下表總結(jié)了用于評估的參考來源。使用 VirusTotal 作為一個基本事實來衡量哈希和 URL 的準確性。還使用 VirusTotal 來衡量所有 IOC 類型的獨占性和延遲。VirusTotal 不僅是一項分析可疑文件和 URL 以檢測惡意軟件的服務，而且還是最大的 TI 反饋，由 72 個防病毒引擎和 68 個網(wǎng)站/域掃描引擎和黑名單列表支持。

與 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數(shù)據(jù)中的前 25k 域來檢查有多少良性域被報告為惡意。對于每個 25k 域集，們在評估期間連續(xù)出現(xiàn)的域，因為列表中可能存在一段時間的惡意域。

(iii) 對于 IP 地址，將 Twiti 與一些與惡意軟件相關的公共 IP 黑名單列表進行了比較。選定的公共 IP 黑名單列表包括 AlienVault IP Reputation、Bambenek_c2、Feodo Tracker、SSL 黑名單和 Mirai 相關反饋。為了衡量準確性，使用上述頂級 25k 域數(shù)據(jù)和主要內(nèi)容交付網(wǎng)絡 (CDN) 服務（AWS CloudFront、CloudFlare、Fastly、EdgeCast 和 MaxCDN）構(gòu)建了一個 IP 地址許可列表。由于 VirusTotal 包含幾乎所有向公眾開放的流行 URL 和域黑名單列表，因此僅將 Twiti 中的 URL 和域與 VirusTotal 進行了比較。

用于評估的數(shù)據(jù)集和 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.評價結(jié)果（1）文件哈希

每天Twiti 都會收集以前從未見過的文件哈希值。上表顯示了 Twiti 3 個月收集的文件哈希的評估結(jié)果。

數(shù)量：Twiti 在 3 個月內(nèi)收集了 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 查詢它們，發(fā)現(xiàn) VirusTotal 中存在 Twiti 中的 30,207 個哈希值，它們對應于 22,824 個唯一文件。其中，Android應用程序有982個哈希值，ELF文件有320個哈希值，iOS應用程序有33個哈希值，分別對應712、227和31個文件。上圖顯示了 Twiti 每天收集的文件哈希數(shù)。Twiti 可以在 3 個月內(nèi)穩(wěn)定收集足夠的 IOC，除非一堆文件哈希來自 Pastebin.com。請注意，在 2 月的前幾天，2-3 名用戶通過 Pastebin.com 鏈接共享了數(shù)百到數(shù)千個 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 月以來收集的推文中的首次出現(xiàn)時間。這意味著在 2 月 1 日收集的所有文件哈希都將其首次檢測日期設為 2 月 1 日，盡管它們可能更早出現(xiàn)在 Twitter 上。將此類文件散列的延遲與參考進行比較可能會錯誤地描述 Twiti 的性能。因此，僅針對參考源中首次檢測日期為 2 月 1 日或該日期之后的文件哈希計算了 Twiti 的延遲。Twiti 中有 21,175 個文件哈希值可用于與 VirusTotal 進行延遲比較。其中，Twiti 比 VirusTotal 平均早 1.2 天（最長 27.5 天）檢測到 814 個文件哈希（3.84%），并且在 VirusTotal 首次檢測后的 24 小時內(nèi)檢測到 14,052 個文件哈希（66.36%）。為了與 AlienVault OTX Pulse 進行比較，可以使用 Twiti 中的 8,508 個文件哈希值。其中，Twiti 中出現(xiàn) 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結(jié)果的推文和 1.9% 是由蜜罐賬戶報告的。這意味著它們足夠可疑，盡管 VirusTotal 中的任何引擎都沒有檢測到它們。

Emotet 哈希：Emotet 惡意軟件于 2014 年被發(fā)現(xiàn)，最近它通過分發(fā)和丟棄其他銀行木馬（如 Trickbot、Ursnif 和 Ryuk 有效負載），演變?yōu)槌洚攼阂廛浖捶盏耐{分發(fā)者。為了有效地抵御大量變體，TI 反饋盡早收集大量 Emotet 哈希非常重要。Twiti 可以批量收集 Emotet 的惡意軟件哈希。它收集了 3 個月內(nèi)與“emotet”一詞同時出現(xiàn)的 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 之間的重疊情況。結(jié)果如下表所示。與 AlienVault OTX Pulse 和 MalwareBazaar 相比，Twiti 不僅可以高度獨家地收集最多數(shù)量的 Emotet 惡意軟件樣本（77.06% 和 99.09%），而且可以覆蓋其他惡意軟件樣本的三分之一公共 TI 反饋。

（2）URL

URL 的評估比文件哈希更復雜。URL 的所有者或內(nèi)容隨時間而變化，因此它可能在某一天是惡意的，但在另一天是良性的。根據(jù)早期的研究認為 30 天是與惡意軟件相關的惡意 URL 的生命周期，例如惡意軟件分發(fā)站點或 CC URL。下表顯示了 Twiti 使用 30 天窗口收集一個月的 URL 的評估結(jié)果。體積。Twiti 在 4 月份收集了 6,873 個惡意 URL。URL 的平均每日數(shù)量為 229。請注意，Twiti 在 2 月份收集了 7,630 個 URL，在 3 月份收集了 4,911 個 URL。

排他性：將收集到的 URL 與 VirusTotal 進行了比較。每天向 VirusTotal 查詢每個 URL 并檢查它是否是惡意的。為了判斷一個 URL 是否為惡意，使用了 VirusTotal 的最新掃描結(jié)果。如果 VirusTotal 中某個 URL 的最新掃描結(jié)果（last analysis result）是惡意的，并且其掃描日期（last analysis date）在最近 30 天內(nèi)，則確定該 URL 是惡意的。如果 VirusTotal 中最近一次掃描的 URL 是惡意的，但其掃描日期在最近 30 天之前，要求對該 URL 進行分析，當重新掃描結(jié)果為惡意時，會在 VirusTotal 中確定該 URL 是惡意的。否則，確定 URL 不在 VirusTotal 中。Twiti 檢測到 2,368 個不在 VirusTotal 中的 URL，占收集到的 URL 的 34.45%。認為掃描更新間隔與惡意網(wǎng)址相對較短的生命周期之間的時間間隔使得網(wǎng)站掃描儀無法檢測到短命的惡意網(wǎng)址，從而導致網(wǎng)址的排他率較高。這種高度的排他性說明即使是最大的商業(yè)提要也是不完整的，因此將來自多個提要的 URL 聚合有利于防止惡意軟件的傳播。

延遲：惡意 URL 的延遲是通過其在 Twiti 中的首次檢測日期與其在過去 30 天內(nèi)有效的 VirusTotal 中的最新掃描日期之間的差異計算得出的。與文件哈希類似，測量了 VirusTotal 中最新掃描日期為 4 月 1 日或該日期之后的 URL 的 Twiti 延遲。Twiti 中有 4,229 個 URL 可用于延遲比較。Twiti 平均比 VirusTotal 早 1.7 天發(fā)現(xiàn) 2,191 個 URL (51.81%)，同一天發(fā)現(xiàn) 1,741 個 URL (41.17%)，之后 297 個 URL (7.02%)。

準確性：通過向 VirusTotal 發(fā)出分析請求來檢查收集的 URL 是否真的是惡意的。然而，這個分析請求修改了最新的掃描日期，所以上面的延遲計算結(jié)果被扭曲了。因此進行了額外的實驗。從 2020 年 5 月 1 日到 14 日，要求 VirusTotal 在 Twiti 檢測到收集到的 URL 后立即對其進行掃描，然后在掃描結(jié)果中測量其中有多少是惡意或可疑的。在此期間，Twiti 收集了 2,386 個 URL。其中，Virust Total掃描結(jié)果中惡意網(wǎng)址1992個，可疑網(wǎng)址72個，干凈網(wǎng)址317個，未發(fā)現(xiàn)網(wǎng)址站點5個。由于 VirusTotal 中的網(wǎng)站掃描器無法始終提供最新結(jié)果，我們在 5 月底再次查詢了干凈的 URL，發(fā)現(xiàn) 2 周后有 142 個干凈的 URL 變?yōu)閻阂?。因此，Twiti 從 5 月 1 日到 14 日檢測到的 2,386 個 URL 中有 89.44% 是真正惡意的。包括可疑 URL 在內(nèi)，Twiti 的整體準確率為 92.45%。盡管實時掃描精度很高，但 Twiti 收集了 7.33% 的干凈 URL，這使得 Twiti 難以用作自動提要。由于 VirusTotal 中的實時網(wǎng)絡掃描程序可能會產(chǎn)生誤報，對 VirusTotal 確定為干凈的 175 個 URL 進行了誤報 (FP) 分析。FP 分析結(jié)果可以在GitHub 存儲庫中找到。發(fā)現(xiàn) (i) Twiti 的實際誤報為 98 個 URL，即準確率為 95.89%，以及 (ii) 當用戶發(fā)布帶有參考鏈接的 IOC 時，98 個干凈 URL 中有 50% 來自 Pastebin.com。因此，由網(wǎng)絡安全領域的可信域（例如，virustotal.com、app.any.run、urlhaus、abuse.ch）組成的許可名單最終可以將 Twiti 的準確率提高到 97.53%。

（3）IP 地址

IP 地址具有像 URL 一樣隨時間變化的屬性。許多最近的研究假設惡意 IP 的生命周期為 30 天。還使用 30 天的窗口進行評估。下表顯示了 Twiti 一個月收集的 IP 地址的評估結(jié)果。

數(shù)量：Twiti 在 4 月份收集了 12,765 個惡意 IP 地址。Twiti 平均每天可以收集的惡意 IP 地址數(shù)為 426。請注意，Twiti 在 2 月份收集了 16,668 個 IP 地址，在 3 月份收集了 45,683 個 IP 地址。還調(diào)查了同期其他公共 IP 黑名單列表的數(shù)量。雖然公共 IP 黑名單列表的數(shù)量大多很少，但 Twiti 可以提供大量惡意 IP 地址。在公共 IP 黑名單列表中，AlienVault IP 聲譽的數(shù)量最大，因為它報告了任何惡意 IP，不僅限于惡意軟件。

排他性：判斷 Twiti 檢測到的 IP 地址在 VirusTotal 中，當該 IP 地址在 Twiti 中的第一次檢測日期和考慮的 IP 黑名單列表中的 30 天內(nèi)在 VirusTotal 中被標記為惡意時。同樣，檢查了 Twiti 中的 IP 是否在 30 天窗口內(nèi)的每個 IP 黑名單列表中。在上表中，為 VirusTotal 和每個 IP 黑名單列表提供了獨占 IP 地址的比例。與 VirusTotal 相比，Twiti 中超過一半 (53.63%) 的 IP 地址是獨占的。Twiti 對公共 IP 黑名單列表顯示出更高的排他性 (90%)。在公共 IP 黑名單列表中，Twiti 與 AlienVault IP 聲譽的重疊度最高 (9.80%)。這表明，無論其數(shù)量如何，每個反饋對 IP 地址的貢獻都非常獨特。

延遲：將惡意 IP 地址的首次檢測日期定義為它在 30 天窗口內(nèi)在 Twiti 中出現(xiàn)的第一天。與 VirusTotal 相比，Twiti 平均可以提前 5.9上表到 813 個 IP 地址。請注意，VirusTotal API v3.0 不提供惡意 IP 的檢測時間，因此只能計算首先在 Twiti 中檢測到然后在 VirusTotal 中檢測到的 IP 的延遲。計算了 Twiti 中首次檢測日期與 30 天內(nèi)每個黑名單列表之間的差異。Twiti 發(fā)現(xiàn) 274 個 IP 比 AlienVault IP 聲譽早 10.6 天，這是最大的公共 IP 黑名單列表之一。與其他 IP 黑名單列表相比，Twiti 最多可以提前 25 天檢測到惡意 IP，但它們與 Twiti 的重疊太小，無法討論延遲。

準確性：與 URL 不同，沒有掃描方法來檢查 Twiti 檢測到的 IP 地址是惡意的還是良性的。因此們只測量了 Twiti 中有多少 IP 地址在使用第 4.1 節(jié)中列出的頂級流行域和主要 CDN 構(gòu)建的 IP 許可名單中。觀察到 Twiti 中只有 4 個 (0.03%) 的 IP 被錯誤地報告為惡意。

（4）域

域的評估方式與 IP 地址完全相同。Twiti 在 4 月份收集的域的評估結(jié)果如下表所示。

數(shù)量、排他性和延遲：Twiti 在 4 月份收集了 3,302 個惡意域名。惡意域的平均每日數(shù)量為 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.與現(xiàn)有系統(tǒng)的比較

將 Twiti 與從 Twitter 收集 IOC 的現(xiàn)有系統(tǒng)進行了比較：InQuest IOC DB和 Twitter IOC Hunter。在許多其他類型的 IOC 中，通過它們的 API 從兩個系統(tǒng)收集了 2 周的 URL。以與 Twiti 完全相同的方式檢查所收集 URL 的準確性。評價結(jié)果如下表所示。觀察到，Twiti 不僅可以比兩個系統(tǒng)收集更多的 URL，而且 Twiti 的準確性也比現(xiàn)有系統(tǒng)高得多。

5

Measurement and Analysis

A.推特上的IOC數(shù)量

按數(shù)據(jù)源分類的 IOC：Twiti 從推文本身和推文中發(fā)布的鏈接中收集 IOC。上表顯示了 Twiti 的數(shù)據(jù)來源以及每個來源中 IOC 的評估結(jié)果。請注意，上表中的排他性和延遲是根據(jù)與 VirusTotal 的比較計算得出的。觀察到，推文、Paste bin.com 和 AlienVault OTX Pulse 是通過 Twitter 收集 IOC 的主要來源——收集的文件哈希的 93.26%、收集的 URL 的 94.99%、收集的 IP 地址的 98.75% 和 93.55 % 的收集域來自這 3 個數(shù)據(jù)源。具體來說，發(fā)現(xiàn)：

(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，數(shù)量很少，但 IOC 的質(zhì)量可以高于其他接受匿名提交的 feed。(v) 安全廠商博客是惡意文件散列和 URL 的最早來源，但同時也是最遲的來源。觀察到，來自供應商全面分析報告的 IOC 導致顯著延遲。

通過數(shù)據(jù)采集進行 IOC：Twiti 通過跟蹤關鍵字和用戶來收集推文，以最大化要收集的 IOC 數(shù)量。觀察到，Twiti 收集的 IOC 中有 31.1% 完全來自關鍵字跟蹤，16.3% 完全來自用戶跟蹤，52.6% 來自這兩種方法。有趣的是，對于文件哈希，95.9% 是通過關鍵字跟蹤獲得的，只有 4.1% 是專門通過用戶跟蹤獲得的。另一方面，用戶跟蹤數(shù)據(jù)收集對惡意 URL、IP 和域收集的貢獻要大得多。觀察到，23.9% 的收集 URL、38.6% 的收集 IP 地址和 31.8% 的收集域完全來自用戶跟蹤。

來自商業(yè)領域的 IOC：大多數(shù)安全供應商通過博客或 Twitter 分享他們的一小部分報告以進行營銷。安全研究人員也經(jīng)常發(fā)布或轉(zhuǎn)發(fā)此類信息。這些活動使得一些商業(yè)領域的 IOC 數(shù)據(jù)進入了公共領域。測量了 Twiti 中來自商業(yè)領域的 IOC 的比例。如果 IOC 來自安全供應商運營的帳戶，或者來自與安全博客對應的外部鏈接，認為 IOC 來自商業(yè)領域。觀察到 Twiti 中 6% 的文件哈希、5% 的 URL、1.2% 的 IP 和 7.5% 的域來自商業(yè)域。

受數(shù)據(jù)使用限制的 IOC：Twiti 從與推文相關的各種來源收集 IOC。每個來源都有不同的數(shù)據(jù)使用條件。例如，URLhaus 是在 CC0 下獲得許可的，這甚至允許將其數(shù)據(jù)用于商業(yè)用途。通過分析各個來源的license，發(fā)現(xiàn)Twiti 96%的IOCs可以用于非商業(yè)和商業(yè)用途，0.4%可以用于商業(yè)用途，有l(wèi)icense可以使用，3.6%不允許用于商業(yè)用途任何商業(yè)目的。大部分沒有數(shù)據(jù)使用限制的 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 檢測結(jié)果分析了它們的惡意軟件類型。在多個反病毒引擎的不同檢測結(jié)果中選擇了一個主導標簽作為惡意文件哈希的惡意軟件類型。下圖顯示了 VirusTotal 檢測到的文件哈希的惡意軟件類型分布。特洛伊木馬是 3 個月內(nèi)報告的最主要的威脅類型。除了 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 上下文的這些散列的惡意軟件類型分布。雖然大多數(shù)文件哈希是在沒有任何惡意軟件類型信息的情況下共享的，但 22.6% 的文件哈希與惡意軟件類型有關。不在 VirusTotal 中的主要惡意軟件文件哈希類型是遠程訪問木馬 (RAT) (5.5%)、網(wǎng)絡釣魚 (5.4%) 和僵尸網(wǎng)絡 (4.6%)。

惡意軟件家族：在解析 VirusTotal 中的防病毒檢測結(jié)果后，為惡意軟件家族取了一個主導標簽。在下圖中按操作系統(tǒng)顯示了 Twiti 中文件哈希的前 30 個惡意軟件系列。Emotet 是 Twitter 上報告的最大的惡意軟件，這與 Emotet 是最普遍的威脅之一的事實一致。在 Twitter 上觀察到一些 Emotet 跟蹤帳戶，但 Emotet 哈希值主要是通過關鍵字跟蹤收集的，這表明各種用戶組報告 Emotet 并且 Emotet 是一個嚴重的持續(xù)威脅。

WannaCry 是 Twitter 上第二大惡意軟件。Mirai 和 Gafgyt 等物聯(lián)網(wǎng)僵尸網(wǎng)絡是 Twitter 上最主要的 Linux 惡意軟件，而 Lady 和 CoinMiner 等加密貨幣挖掘惡意軟件是第二大 Linux 惡意軟件。Cerberus、Hqwar、Anubis 和 Asacub 等銀行木馬是 Twitter 上最主要的 Android 惡意軟件，而 HiddenAds 和 IconHider 等廣告軟件是第二大 Android 惡意軟件。從 2 月 3 日到 4 月底，報告了使用冠狀病毒網(wǎng)絡釣魚電子郵件的 Netwalker 勒索軟件的幾個文件哈希值。從 3 月 26 日起，許多用戶就已經(jīng)提到了針對 iPhone 的間諜軟件 LightRiver 超過 2 周。

早期檢測到的哈希值：分析了 Twiti 檢測到的文件哈希值早于 VirusTotal 用戶。有 74 個用戶，其中大部分是個人惡意軟件分析師。下表給出了報告早期檢測到的哈希值的頂級用戶。

Hash不在 VirusTotal 中：分析了誰生成了獨占文件哈希。有 33 名用戶在 3 個月內(nèi)報告了 20 次以上的獨占哈希。其中 70% 是個人惡意軟件分析師，15% 是安全公司，其中近 80% 通過 Pastebin.com 鏈接、AlienVault OTX 鏈接、惡意軟件沙箱鏈接或安全供應商博客文章報告文件哈希。下表顯示了報告獨占哈希的選定頂級用戶。

在 Twitter 上提及的持續(xù)時間：下圖顯示了在 Twitter 上提及文件哈希的天數(shù)。大多數(shù)文件哈希已經(jīng)被提及了 1-2 天。僅一天就提到了近 50% 的文件哈希。同時，有 0.8% 的文件哈希被提及超過一周，特別是 NetWalker 勒索軟件的一個文件哈希被連續(xù)提及了 35 天。惡意行為者以醫(yī)療保健部門為目標，以利用 COVID-19 大流行，因此許多安全專家從 3 月初開始在 Twitter 上反復警告。

（2）URL

攻擊類型：對于 Twiti 中在 VirusTotal 中被檢測為惡意的 URL，分析了它們的 VirusTotal 檢測結(jié)果并觀察到，其中 75.5% 是惡意軟件站點，16.5% 是釣魚站點，8% 是包含漏洞或其他漏洞的惡意站點。對 5 月 1 日至 15 日收集的 URL 獲得了類似的結(jié)果，其中 75.8% 的惡意 URL 是與惡意軟件相關的站點，19.6% 是釣魚站點，4.6% 是惡意站點。請注意，65% 的網(wǎng)絡釣魚站點完全來自用戶跟蹤收集的推文。此外分析了推文文本，因為它們具有有用的上下文詞，例如“c2”。觀察到 5.6% 的收集到的 URL 與單詞“c2”同時出現(xiàn)，這表明 Twiti 中至少 5.6% 的 URL 是 CC URL。還觀察到，不在 VirusTotal co 中的 URL 出現(xiàn)在“c2”中的頻率幾乎是 VirusTotal 中的 2 倍，這表明 CC URL 通常存活時間很短，因此 VirusTotal 可能經(jīng)常無法檢測到它們。這表明 Twitter 比 VirusTotal 在獲取短期 CC URL 方面更有優(yōu)勢?？上螺d的惡意軟件?？上螺d的惡意軟件樣本對于進一步的惡意軟件分析特別有用。通過分析 URL 末尾給出的擴展名，觀察到 32.3% 的收集 URL 包含可下載的文件擴展名，例如“pdf”、“zip”、“exe”、“apk”、“sh”、“jar” ”和“bin”。

（3）域

DGA（域生成算法）域：DGA 域往往會在短時間內(nèi)（1-3 天）處于活動狀態(tài)。因此，早期檢測 DGA 域?qū)τ诤诿麊瘟斜碛行Ш苤匾?。觀察到 Twiti 中 2% 的域在推文中出現(xiàn)了“dga”一詞，并且它們都比 VirusTotal 提前一天檢測到。此外應用了基于 LSTM 的 DGA 檢測算法，并觀察到 Twiti 中 5.4% 的域被歸類為 DGA 域。Twiti 平均比 VirusTotal 提前 1.9 天檢測到 64% 的 DGA 域，并且在同一天檢測到 18%。

6

Discussion

其他類型威脅的 IOC：盡管專注于惡意軟件 IOC，但通過添加“phishing” 和 “spam” 等關鍵字并重新訓練推文分類器，Twiti 可以輕松擴展為收集任何類型的攻擊（例如，網(wǎng)絡釣魚、垃圾郵件、掃描）的 IOC。

局限性：

(1) 由于 Twitter 是一個任何人都可以生成數(shù)據(jù)的社交媒體平臺，因此存在大量新的威脅信息，但同時也可能存在虛假信息。因此盡管在評估中觀察到 Twiti 的高精度，但 Twiti 容易受到數(shù)據(jù)投毒攻擊。為了克服這一弱點，可以利用 VirusTotal 和 IP 許可名單來驗證 Twiti 收集的 IOC。

(2) 由于 Twiti 從 Pastebin.com 收集 IOC 僅使用詞過濾器，因此當將一些良性指標與惡意指標一起發(fā)布時，無法保證從中獲取的 IOC 的準確性，正如對 URL 的誤報分析所觀察到的那樣，盡管觀察到 Twiti 的準確率很高（文件哈希為 92.86% 真陽性和 0.03% 假陽性，URL 為 95.89% 真陽性和 4.1% 假陽性），但它的假陽性率不足以用作自動反饋。

然而，大多數(shù)公共 TI 反饋都存在誤報率高的限制。出于這個原因，公共 IOC 反饋在使用之前需要一個驗證過程。為了進一步減少 Twiti 中的 FP，可以將 Twiti 用作 (i) 由用戶選擇的自動反饋，類似于 AlienVault OTX 中的選擇性脈沖訂閱，以及 (ii) 其他協(xié)作安全系統(tǒng)（如多 IP 反饋聚合器）的初始來源或域拆卸系統(tǒng)。(iii)從外部鏈接收集IOC使得Twiti大量收集各種類型的IOC，但帶來了對外部來源的額外依賴。因此，對于免費和開源威脅情報，Twiti 無法利用限制數(shù)據(jù)使用的外部來源。

7

Conclusion

在本文中提出了一種用于 Twitter 的高保真 IOC 提取系統(tǒng)。通過對收集到的 IOC 的廣泛評估，證明所提議的系統(tǒng)能夠比其他公共 TI 反饋更早地收集獨特且準確的惡意軟件 IOC。這使得 Twitter 成為一個有價值的開源威脅情報源。還展示了 Twitter 能夠以高精度和早期的方式捕獲大量正在進行的惡意軟件攻擊。通過從各個方面分析 IOC 的特征，可以更好地了解 Twitter 上的惡意軟件 IOC，以及如何利用 Twitter 對抗惡意軟件威脅的指南。

- 結(jié)尾 -

【技術分享】BrokenStrokes：針對無線鍵盤的三類攻擊

【技術分享】Office文檔安全：以ODF和OOXML為例

【技術分享】Horus：發(fā)現(xiàn)并分析對以太坊智能合約的攻擊

戳“閱讀原文”查看更多內(nèi)容