不解密識別惡意流量

簡介

在過去的兩年中，我們一直在系統的收集和分析惡意軟體生成的數據包捕獲。在此期間，我們觀察到，有一種惡意軟體是使用基於TLS的加密來逃避檢測，而這種惡意軟體的樣本百分比正在穩步增加。2015年8月，2.21％的惡意軟體樣本使用TLS，而到了2017年5月，數據增加到21.44％。在同一時間段內，使用TLS但是沒有和HTTP進行未加密連接的惡意軟體，從0.12％增加到4.45％。

識別加密網路流量中包含的威脅會帶來一系列獨特的挑戰。監控這些流量，使他們不受惡意軟體威脅和侵害是非常重要的，這樣做也是為了維護用戶的隱私。由於在TLS會話時，模式匹配效果較差，因此我們需要開發一種新方法，即能夠準確檢測惡意軟體的通信。為此，我們利用使用流的各個數據包長度，以及到達時間間隔來了解傳輸數據的行為特徵，並使用ClientHello中包含的TLS元數據，來理解傳輸數據的TLS客戶端。 我們將這兩種視圖結合在一個受監督的機器學習框架中，這樣我們便能夠在TLS通信中檢測已知和未知的威脅。

為了更直觀的了解，圖1提供了TLS會話的簡化視圖。在TLS 1.2中，大多數有趣的TLS握手消息都未加密，在圖1中我們用紅色標記。我們用於分類的所有TLS特定信息都來自ClientHello，它也可以在TLS 1.3中訪問。

數據

在這個項目的整個生命周期中，我們一直認為數據是我們成功的核心。我們與ThreatGrid和Cisco Infosec合作，獲取惡意包捕獲和實時企業數據。這些數據反饋對我們的幫助是巨大的，它能夠引導我們的分析，並且發展出最具信息量的流動特徵。我們所分析的數據特性是十分有趣的，為了讓大家理解有趣在那裡，我們首先關注一個特定的惡意軟體樣本，bestafera，它是著名的鍵盤記錄和數據泄露軟體。

通過數據包長度和時間進行行為分析

圖2顯示了兩個不同TLS會話的數據包長度和到達間隔：圖2a中的谷歌搜索和圖2b中的bestafera啟動連接。 x軸表示時間，向上的線表示從客戶端（源）發送到伺服器（目的地）的數據包大小，向下的線表示從伺服器發送到客戶端的數據包大小。紅線表示未加密的消息，黑線是加密的應用程序數據記錄的大小。

谷歌搜索遵循一種典型模式：客戶端的初始請求位於一個小的出站數據包中，然後是大量響應，它跨越許多MTU大小的數據包。這幾個來回的數據包是谷歌在我還在輸入時，自動完成的搜索。 最後，谷歌認為它對我輸入的內容有自己想法，所以發送了一組更新的結果。 bestafera與之通信的伺服器首先發送一個包含自簽名證書的數據包，這可以看作是圖2b中第一個向下的細紅線。握手後，客戶端立即開始將數據泄露到伺服器。然後是暫停，伺服器定期發送計劃命令和控制消息。針對會話內容，數據包長度和到達時間間隔無法提供更深入的見解，但它們確實有助於推斷會話的行為方面。

使用TLS元數據對應用程序進行指紋識別

TLS ClientHello消息提供了兩個特別有趣的信息，他們可以用來區分不同的TLS庫和應用程序。客戶端向伺服器提供了一個列表，這其中包括在客戶端的優先順序中訂購的合適密碼套件的列表。每個密碼套件定義了一組方法，例如加密演算法和偽隨機函數，這些方法將使用TLS建立連接和傳輸數據。客戶端還可以發布一組TLS擴展，它可以向伺服器提供密鑰交換所需的參數，例如ec_point_formats。

在提供的唯一密碼套件的數量和提供的不同子組中，密碼套件提供的向量是可以變化。類似的擴展列表也會根據連接的上下文而變化。因為大多數應用程序通常有不同的優先順序，所以，在實踐中，這些列表可以而且確實包含大量歧視性信息。例如，桌面瀏覽器傾向於更重的重量，更安全的加密演算法，移動應用程序傾向於更高效的加密演算法。他默認的密碼套件提供與TLS庫捆綁的客戶向量，而且他通常提供更廣泛的密碼套件，這樣可以幫助測試伺服器配置。

大多數用戶級應用程序，以及在野外看到的大量TLS連接，都使用流行的TLS庫，如BoringSSL，NSS或OpenSSL。這些應用程序通常具有唯一的TLS指紋，因為開發人員會修改庫的默認值，這樣便能優化它的應用程序。更明確地說，OpenSSL 1.0.1r中s_client的TLS指紋很可能與使用OpenSSL 1.0.1r進行通信的應用程序不同。這也是為什麼bestafera的TLS指紋既有趣又獨特的原因——它使用OpenSSL 1.0.1r的默認設置來創建其TLS連接。

應用機器學習

特徵表示

對於本文，我們關注的是三種數據類型的簡單特性：傳統的NetFlow、數據包長度以及從TLS ClientHello獲取的信息。這些數據類型都是從單個TLS會話中提取的，但我們還開發了包含多個流的特徵模型。在訓練之前，將所有特徵都歸一化為具有零均值和單位方差。

Legacy

我們使用了傳統NetFlow中存在的5個功能：流的持續時間、從客戶端發送的數據包數、從伺服器發送的數據包數、從客戶端發送的位元組數以及從伺服器發送的位元組數。

SPL

我們創建一個長度為20的特徵向量，其中每個條目都是雙向流中相應的數據包大小。從客戶端到伺服器的數據包大小是正數，從伺服器到客戶端的數據包大小是負數。

TLS

我們分析了提供的密碼套件列表，以及ClientHello消息中包含的廣告擴展列表。在我們的數據中，我們觀察到176個獨特的密碼套件和21個獨特的擴展，這導致了長度為197的二進位特徵向量。如果密碼套件或擴展名出現在ClientHello消息中，則相應的功能設置為1。

學習

所有的結果都使用了scikit-learn隨機森林實現。基於我們之前進行的縱向研究，我們將集合中樹木的數量設置為125棵，並且將樹的每一次分裂所考慮的特徵數量設置為特徵總數的平方根。隨機森林模型使用的特性集由遺留特性、SPL、TLS特性的某些子集組成，具體需要看實驗情況。

結果

我們從ThreatGrid的一個企業網路Site1和324,771流量中抽取了1,621,910個TLS流量，然後訓練我們的隨機森林模型。然後，我們模擬了從單獨的企業網路Site2中看不見的數據部署模型，以及在上一個數據集之後的兩個月內，收集的惡意軟體數據。表1顯示了該實驗在不同閾值下的結果。0.5是分類器的默認閾值，並且閾值越高，訓練的模型就越確定TLS流是由惡意軟體生成的。惡意軟體/良性的準確性是分開的，這樣便能證明特徵子集超過了一個特定的類。例如，Legacy可以在良性集上實現接近完美的準確性，但這些功能無法推廣到惡意軟體數據集。

在0.99的閾值處，使用Legacy / SPL特徵的分類器正確的分類了98.95％的良性樣本和69.81％的惡意樣本。如果我們將有關應用程序（TLS）的信息與網路流量（SPL）的行為特徵相結合，這些結果將得到顯著改善。Legacy / SPL / TLS的組合是良性和惡意軟體樣本上性能最佳的模型。 在0.95的閾值下，該模型分別對於良性和惡意保持數據集實現了99.99％和85.80％的準確度。

結論

由於涉及隱私、法律義務、費用或不合作的端點，解密解決方案在所有設置中都不理想。思科投入了大量時間來開發研究產品，以填補這些空白，並且完善現有的解決方案。我們對真實網路數據的驗證研究表明，我們可以在最小誤報的情況下實現可靠的檢測。除了讓思科的產品團隊進一步開發這項工作外，我們還通過開源和學術論文吸引了更廣泛的外部受眾。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！