Cisco Japan Blog > セキュリティ

セキュリティ

暗号化されたマルウェア トラフィックを復号化せずに検出

西 豪宏
2017年7月12日

この記事は、アドバンスト セキュリティ リサーチ グループのシステム エンジニア Blake Anderson によるブログ「Detecting Encrypted Malware Traffic (Without Decryption)」（2017/6/23）の抄訳です。

はじめに

この 2 年間、シスコはマルウェアによって生成されたパケット キャプチャを系統的に収集し、分析してきました。その間にも、TLS ベースの暗号化を使用して検出を回避するマルウェア サンプルの割合が着実に増加しています。TLS を使用したマルウェア サンプルは、2015 年 8 月には 2.21 % でしたが、2017 年 5 月には 21.44 % に増えています。同じ期間に、TLS を使用しながらも HTTP での非暗号化接続は行わなかったマルウェア サンプルの割合は、0.12 % から 4.45 % に増加しています。

暗号化されたネットワーク トラフィックに含まれている脅威を特定することは非常に困難です。また、暗号化トラフィックの脅威やマルウェアをモニタリングすることは重要ですが、ユーザのプライバシーを保護することも必要です。TLS セッションが存在する場合にはパターン マッチングがあまり効果的ではないため、マルウェア通信を正確に検出できる新たな方法を開発する必要がありました [1,2,3]。そのために、フローの個々のパケット長と到着時間間隔に基づいて、送信データの動作特性を把握しました。また ClientHello に含まれている TLS メタデータによって、送信元の TLS クライアントを特定しました。監視された機械学習フレームワークの中でこれら両方の視点を組み合わることにより、TLS 通信内の既知および未知の脅威を検出することが可能になります。

概要として、図 1 に TLS セッションを簡略化して示します。TLS 1.2 [4] では、ほとんどのインタレスティング TLS ハンドシェイク メッセージが暗号化されていません。図 1 ではそれを赤い色で表しています。分類に使用する TLS 固有の情報はすべて ClientHello から取得され、TLS 1.3 でもアクセスできます [7]。

データ

このプロジェクト全体を通じて、シスコは成否の鍵がデータにあることを意識しました。そして Cisco Threat Grid および Cisco Infosec と連携して、悪意のあるパケット キャプチャとライブ エンタープライズ データを取得しました。それらのデータ フィードは、分析の方向を判断して最も情報量の多いフロー特性を確立するために役立ちました。シスコが分析したデータ フィーチャが興味深いと思われた理由をわかりやすく示すために、まず、キーロギングとデータ漏洩で知られる bestafera というマルウェア サンプルに注目してみます。

パケット長と時間による振る舞い分析

図 2

図 2 は、異なる 2 つの TLS セッションのパケット長と到着時間間隔を示しています。図 2a は Google 検索、図 2b は bestafera によって開始された接続を示します。x 軸は時間を表し、上方向の線はクライアント/送信元からサーバ/宛先に送信されるパケット サイズを示し、下方向の線はクライアントからサーバに送信されるパケットのサイズを表します。この図でも、赤い線は暗号化されていないメッセージを表します。黒い線は暗号化されたアプリケーション データ レコードのサイズを表します。

Google 検索は典型的なパターンを描いています。クライアントの最初の要求は小さな発信パケットによって行われ、その後、MTU サイズの多数のパケットにわたる、サイズの大きな応答が続きます。いくつかのパケットが往復しているのは、文字の入力中に Google がオートコンプリートを試みていたためです。Google が検索対象の言葉を最終的に判断したところで、更新された検索結果が送信されています。bestafera と通信したサーバは、自己署名証明書が含まれたパケットの送信によって動作を開始しました。それが、図 2b の最初の下方向の赤い線になります。ハンドシェイクが確立されると、クライアントはただちにデータをサーバに盗み出します。一旦停止した後で、サーバはスケジュールされたコマンドと制御メッセージを送信しています。パケット長と到着時間間隔では、セッションの詳細な内容はわかりませんが、セッションの振る舞いを推測するためには役立ちます。

TLS メタデータによるアプリケーションのフィンガープリント

図 3

TLS ClientHello メッセージでは、異なる TLS ライブラリとアプリケーションの識別に使用できる、2 つの有益な情報が得られます。クライアントはサーバに対し、クライアントの優先順位によって配列された、適切な暗号スイートのリストを提供します。各暗号スイートは、接続を確立し TLS を使用したデータ送信を行うために必要な一連のメソッド（暗号化アルゴリズムや疑似乱関数など）を定義します。クライアントは、キー交換に必要なパラメータ（ec_point_formats など）をサーバに提供することなどが可能な、一連の TLS 拡張をアドバタイズすることもできます。

暗号スイート オファー ベクトルでは、提供される独自の暗号スイートの数とサブグループの種類が、それぞれ異なる場合もあります。同様に、拡張のリストも接続のコンテキストによって異なります。一般的にアプリケーション間の優先度は異なるため、こうしたリストには多数の実際的な識別情報が含まれています。たとえば、デスクトップ ブラウザでは、データが重くても安全性の高い暗号化アルゴリズムが優先される傾向がありますが、モバイル アプリケーションの暗号化アルゴリズムでは効率が重視されます。TLS ライブラリにバンドルされたクライアントのデフォルトの暗号スイート オファー ベクトルは、サーバの設定のテストに役立つように、より広範な暗号スイートを提供するのが一般的です。

ユーザ レベルのほとんどのアプリケーション、さらには一般的な多数の TLS 接続では、BoringSSL、NSS や OpenSSL などの普及している TLS ライブラリが使用されています。通常これらのアプリケーションでは、開発者がライブラリのデフォルト値を変更してアプリケーションを最適化するため、独自の TLS フィンガープリントが使用されています。具体的には、OpenSSL 1.0.1r から s_client の TLS フィンガープリントは大半が OpenSSL 1.0.1r を使用して通信するアプリケーションとは異なります。この点でも bestafera の TLS フィンガープリントは特徴的です。TLS 接続の確立に OpenSSL 1.0.1r のデフォルト設定を使用しているのです。

機械学習の応用

フィーチャ表現

このブログ記事では、わかりやすいフィーチャ表現として、従来の NetFlow、パケット長、そして TLS ClientHello から取得した情報という 3 つのデータ型に着目しました。これらのデータ型はすべて単一の TLS セッションから抽出されたものですが、シスコは複数のフローからのフィーチャを組み込むモデルも開発しました [1]。すべてのフィーチャを、トレーニングに先立ってゼロ平均と単位分散を持つよう正規化しました。

レガシー：従来の NetFlow にあった 5 つのフィーチャ、つまりフローの持続時間、クライアントから送信されたパケット数、サーバから送信されたパケット数、クライアントから送信されたバイト数、サーバから送信されたバイト数を使用しました。

パケット長シーケンス（SPL）：各エントリが双方向フローにおいて対応するパケット サイズとなる、長さが 20 のフィーチャベクトルを作成します。クライアントからサーバへのパケット サイズはプラスであり、サーバからクライアントへのパケット サイズはマイナスです。

TLS メタデータ（TLS）：提供された暗号スイート リストと、ClientHello メッセージに含まれるアドバタイズされた拡張リストの両方を分析します。このデータセットでは、176 の独自の暗号スイートと、21 の独自の拡張が観察され、長さが 197 のバイナリ フィーチャ ベクトルが生じました。その暗号スイートまたは拡張が ClientHello メッセージ内に現れた場合、該当するフィーチャは 1 に設定されます。

学習

提示された結果では、すべて scikit-learn ランダム フォレスト実装が使用されています [6]。以前行った長期的研究に基づき集合体のツリー数を 125 に設定し、ツリーの分岐ごとに考察されるフィーチャ数を合計フィーチャ数の平方根に設定しました。ランダム フォレスト モデルで使用したフィーチャ セットは、実験に応じて、レガシー、SPL や TLS フィーチャのサブセットで構成されます。

結果

ランダム フォレスト モデルをトレーニングするために、1 つのエンタープライズ ネットワーク Site1 から 1,621,910 の TLS フローをサンプリングし、ThreatGrid から 324,771 のフローをサンプリングしました（2015 年 8 月から 2016 年 12 月の期間に収集）。次に、別個のエンタープライズ ネットワーク Site2 からの未知のデータでモデルの導入をシミュレートし、前のデータ セットの後の 2 ヵ月間に収集されたマルウェア データをシミュレートしました。2017 年 1 月から 2 月の期間に、Site2 からは 2,638,559 の TLS フローがサンプリングされ、ThreatGrid からは 57,822 の TLS フローがサンプリングされました。表 1 は、この実験の結果をしきい値別に示したものです。分類子のデフォルトのしきい値は 0.5 です。しきい値が高くなるほど、学習されたモデルは、その TLS フローがマルウェアによって生成されたものかどうかを正確に判断できるようになるはずです。特定のクラスに過剰適合するフィーチャ サブセットを示すため、マルウェア/クリーンの精度は分けて記載しています。たとえばレガシーでは、クリーンなデータセットではほぼ完璧な精度が得られますが、これらのフィーチャはマルウェア データセットには汎化できていません。

0.99 のしきい値で、レガシー/SPL フィーチャを使用した分類子は、クリーンなサンプルの 98.95 % と悪意あるサンプルの 69.81 % を正確に分類しました。これらの結果は、アプリケーション（TLS）に関する情報とネットワーク トラフィックのふるまい特性（SPL）を組み合わせることで、大幅に向上します。クリーンなサンプルとマルウェア サンプルに対して最も優れた結果を出したのは、レガシー/SPL/TLS の組み合わせでした。このモデルは、0.95 のしきい値で、クリーンなホールド アウト データセットには 99.99 %、悪意あるセットには 85.80 % の精度を達成しました。

まとめ

復号ソリューションは、プライバシー上の問題、法的義務、経費、あるいは連携のないエンドポイントなどの理由により、必ずしも固有の状況に適するわけではありません。シスコは時間を費やして研究を重ね、製品を開発し、これらのギャップを解消して現行のソリューションを補完してきました。現実のネットワーク データの検証研究から、誤検出を最小にしながら信頼性の高い検出を実現できることが示されました。シスコ製品チームと協力してこの作業を進める一方で、私たちはオープン ソース [5] と学術論文 [1,2,3] を通じて、より広範な外部の対象者への働きかけに時間を費やしています。

参考資料

[1] B. Anderson、D. McGrew。『Identifying Encrypted Malware traffic with Contextual Flow Data.In

Proceedings of the 2016 ACM Workshop on Artificial Intelligence and Security（コンテキスト フロー データによる暗号化マルウェアトラフィックの特定。人工知能およびセキュリティに関する 2016 年 ACM ワークショップの議事録において）』、AISec ’16、35 ～ 46 ページ

（2016 年）

[2] B. Anderson、D. McGrew。『Machine Learning for Encrypted Malware Traffic Classification: Accounting for Noisy Labels and Non-Stationarity.In ACM SIGKDD International Conference on Knowledge

Discovery and Data Mining (KDD)（暗号化マルウェアトラフィック分類のための機械学習：ノイジーなラベルと非定常性の考慮。ACM SIGKDD 国際知識会議において）』（2017 年掲載予定）

[3] B. Anderson、S. Paul、D. McGrew。『Deciphering Malware’s use of TLS (without Decryption) マルウェアの TLS 使用の解読』。ArXiv e-prints（2016 年 7 月）

[4] T. Dierks、E. Rescorla。『The Transport Layer Security (TLS) Protocol Version 1.2.RFC 5246

(Proposed Standard)（トランスポート レイヤ セキュリティ（TLS）プロトコル バージョン 1.2 RFC 5246(標準化提案)）』（2008 年）

[5] D. McGrew, B. Anderson, B. Hudson, and P. Perricone.Joy。https://github.com/cisco/joy（2017 年）

[6] F. Pedregosa、G. Varoquaux、A. Gramfort、V. Michel、B. Thirion、O. Grisel、M. Blondel、P. Prettenhofer、

1. Weiss、 Dubourg、J. Vanderplas、A. Passos、D. Cournapeau、M. Brucher、M.Perrot、E. Duch-esnay。『Scikit-learn: Machine Learning in Python.Journal of Machine Learning Research, 12:2825-2830（Scikit-learn：Python における機械学習。機械学習研究ジャーナル）』

（2011 年）

[7] E. Rescorla。『The Transport Layer Security (TLS) Protocol Version 1.3 (draft 20)（トランスポート レイヤ セキュリティ（TLS）プロトコル バージョン 1.3（ドラフト 20））』。https://tools.ietf.org/html/draft-ietf-tls-tls13-20（2017 年）

• #CiscoDNA
• #NetworkIntuitive