Computer Security Symposium 2013 21-23 October 2013 パケットキャプチャからみた悪性通信に関する特徴の考察 田中恭之畑田充弘稲積孝紀 NTT コミュニケーションス 株式会社 108-8118 東京都港区芝浦 3-4-1 ク ランパークタワー 16F {yasuyuki.tanaka, m.hatada, t.inazumi}@ntt.com あらまし感染端末をコントロールし, スパムメール送信や DDOS 攻撃等他のホストの攻撃や, キーロガーやフィッシンク サイト構築などの情報搾取等を行うボットネットは, 現在も大きな脅威となっている. ボットネットを把握するには, 対象 PC が行う通信が正常なものか,C&C セッション等の悪性なものかを判定する必要があり, トラフィックロク とホストロク を組み合わせて検出を行う先行研究が有力である. 一方, ホストロク 入手の困難性から, トラフィックロク のみから悪性通信を特定できることが望まれるため, 本稿では,Practice2013 データを解析し, 悪性通信判定に繋げることを可能とする特徴を考察する. キーワードボットネット,C&C 通信 A study of characteristic of malignant communication as seen from the packet capture data Yasuyuki TANAKA Mitsuhiro HATADA Takanori INAZUMI NTT Communications Corporation Gran Park Tower 16F, 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118, Japan Abstract Botnet to control the infection PC, perform attacks other PC or DDOS attacks, send spam mail, information exploitation, etc., such as phishing sites and building key logger is a significant threat today. To detect a botnet, it is necessary to determine whether those communications target PC to do is normal, or something malignant C&C session, previous studies for detecting a combination of host and log traffic log is a leading some. On the other hand, since it the difficulty of the host logs available, it is possible to identify malignant communication only from the traffic log is desired. In this paper, we analyze the Practice2013 data, we study the feature that can allow the determination of malignant communication. 1. はじめに大規模なボットネットを摘発し撲滅したという発表が見られるようになったが, ボットネットはより巧妙に複雑になっており, 依然として大きな脅威となっている. 今年 6 月には, Microsoft 社が FBI や金融機関と連携して, Citadel ボットネットを一斉摘発したと発表した. [1] 発表によると,Microsoft は Citadel ボットネット 1462 台と, そのボットネットに操られていた感染 PC 数百万台との接続を一斉に解除させた. Citadel の感染は世界 90 カ国あまりに広がっており, 被害者は約 500 万人, 被害額は 5 億ドルに上 ると見積もっている. しかしながら,Citadel マルウェアの規模や複雑性から考えると Citadel を使った世界のボットネットを完全に壊滅させられたとは考えていないと Microsoft 社は説明している. ボットネットを把握するには, 対象 PC が行う通信が正常なものか,C&C セッション等の悪性なものかを判定する必要があり, 多数の先行研究が行われている.Jacob らは [2], トラフィックロク と PC から取得するシステムコールロク を組み合わせ, 特徴のある動作をク ラフ化, クラスタリンク し, テンプレート化し, 機械学習を用 - 118 -
いることで, 未知の悪性通信の識別に成功している. 一方, このようなホストベースのロク は, ユーザ PC にロク を取得する仕組みを導入する必要があり, 特に運用の観点から, ロク の入手のハードルが上がるため, トラフィックロク のみから悪性通信を特定できることが望まれる. 2. 関連研究近藤らは IRC プロトコルベースの C&C セッションについて, トラフィックロク のパケットヘッダ情報のみに着目し, 機械学習を用いて識別を行っている. 機械学習では特徴ベクトルを何にするかが要となるが, セッション情報, パケットシーケンス, パケットヒストク ラムを特徴ベクトルとして定義し, 評価を行い, パケットヒストク ラムの有効性が確認されている.[3] Perdisci らは,C&C セッションを含む HTTP プロトコルベースのペイロード情報を用いて, 定義した特徴ベクトルに基づき,3 ステップでクラスタ化し, ネットワークシク ネチャを作成, アンチウイルスソフトで検出できない未知検体の検出を可能とする評価結果を出している. 特徴ベクトルとしては,HTTP リクエスト総数,GET 数,POST 数,URL 長, パラメータ数, データ量, レスポンス長である.[4] 大月らは, マルウェア感染後の HTTP 通信のペイロード情報を対象とし, 特徴ベクトルとして, ASCII 文字コードの出現頻度を定義し, マルウェア種別ごとの有効性を評価している.[5] 桑原らは, 未知のマルウェアの特定を目的として,CCC Data set 2009 の攻撃通信データを解析し, マルウェアのダウンロード, 感染, ポートスキャン等の特徴を発見的手法により見つけルールとして纏めている.[6] [3] のようにパケットヘッダ情報のみを情報源とする場合, パケットヘッダ情報はペイロードと比較して, 攻撃者が意図的にその特徴を変更しづらい点, また, セッション確立時にはアプリケーション毎の特徴が現れやすい点に優位性があると考えられる. 一方, 扱える情報に限りがあるので十分な特徴を捉えられない可能性がある. [4][5] のようにペイロード情報まで含めて情報源とする場合, 多様な特徴量を抽出できる可能性が広がる. 一方, 特徴量のとり方によっては, 攻撃者が容易に回避を行える可能性がある点, また, 実運用での入手の困難さ, 入手できたとしても内容を見てよいかについて考慮する必要がある. 3. Practice データセット Practice データセット 2013[7] は, マルウェア 5 検体を長期観測 ( 最大 1 週間 ) した際のパケットキャプチャデータ及びアンチウイルスソフトのスキャン結果である ( 表 1) 表 1 データセット名スキャン結果 Practice_1.pcap Zbot Practice_2.pcap Spybot Practice_3.pcap ZeroAccess.hj Practice_4.pcap ZeroAccess.hg Practice_5.pcap Spyeye 以下,5 個のデータセットについて, 有効な特徴量を抽出することを目的としてデータ解析を行った. また本稿で用いる図について特に標記をしない限り, 横軸が日時, 縦軸がパケットの個数である. 4. Practice_1.pcap の解析 1 プロトコル別時系列図 1-1 に, プロトコル別に時系列表示したク ラフを示す. ク ラフより以下がわかる. 定期的な DNS 通信,UDP 通信 TCP 通信は一定期間急激に減少 通信が無い期間の存在 5/22 未明を境に傾向が変化 図 1-1 2 HTTP 通信 HTTP 通信は,google と checkip.dyndns.org の疎通確認と eclosion-media.net からの bc.exe のダウンロードがあった. このダウンロードは 5/22 の未明に行われており,1の傾向の変化と関連性が考えられる. 3 DNS 通信 DNS 通信の詳細を図 1-2 に示す.15 分間隔で規則的に通信があることがわかる. またパケットキャプチャにより以下のドメインの名前解決を繰り返し行っていることがわかった. eldvision.net donfinale.com despicableu.com - 119 -
図 1-2 4 UDP 通信 UDP 通信の詳細を図 1-3 に示す.30 分間隔で規則的に通信があることがわかる.1で見た 5/22 未明のバイナリダウンロード前後で通信の挙動が変化したことがわかる.1 分間程度で通信が終了する傾向が.9 分間程度継続し, 後半に通信量が多くなる傾向が見られる. 7 ZeuSTracker との比較 Zbot は Zeus の亜種であるため, ZeuSTracker[8] で提供される IP アドレスとの比較を行った. Practice_1.pcap:928 ユニーク IP アドレス ZeuSTracker:507 ユニーク IP アドレス (2013/8/1) 結果, マッチしたアドレスは 0 件であった. 5. Practice_2.pcap の解析 1 プロトコル別時系列図 2-1 にプロトコル別に時系列表示したク ラフを示す. 大半のトラフィックは 5/18 の TCP 通信である. また一日一度 ( 午前 3 時 ) の定期的な DNS 通信は検体のものでなく解析環境のノイス と思われるので解析は行わない. 図 1-3 また,UDP の通信先 IP アドレスについて, 前半は IP アドレスが徐々に減っていく傾向がみられたが, 後半の IP アドレス数は 27 個で増減なし, すべて同一アドレスであることがわかった. 5 TCP 通信 TCP 通信については, すべてコネクトしていないことがわかった. また 4 の UDP 接続で応答がある IP に対してのみ TCP 接続を試みていることがわかった. 6 パケットサイス 図 1-4 のとおり, 全パケットのうち, 特定サイス のパケットが約半数を占めることがわかった. また 1466byte,342byte,146byte を除けばいずれも 100 バイト以下の比較的小さなパケットであることがわかった. 図 2-1 2 DNS 通信以下のドメインの名前解決を 5/18 及び 5/25 に行っていることがわかった. priv.gigaservice.it 3 TCP 通信すべての通信が,IP アドレス :78.24.188.201, Port:55003 のものであった. このアドレスは2 で名前解決していた IP アドレスであり, 2013/7/4 時点で名前解決可能だったが, 2013/8/7 時点では名前解決できなくなっていた. 通信内容の一部を図 2-2 に示す. ユーザ名と ID を変化させロク インを試みているようだが, いずれも bann されていてロク インができていない様子である. この繰り返し以外のロク は無かった. また図 2-3 に示すように,5 分に一度の定期的な通信となっていることがわかった. 図 2-2 図 1-4( 数字はバイト数 ) 図 2-3 4 パケットサイス 全パケットをサイズ別にグラフにしたものを図 2-4 に示す. 全体の 98% が特定サイズのパケットであることがわかる. 特に 66Byte のパケットが半数以上を占める. また 7 割程度が 100 バイト以下のパケットにな - 120 -
っている. 行わないこととした. 図 2-4 6. Practice_{3,4}.pcap の解析 Practice_3.pcap 及び Practice_4.pcap は類似の検体であるため比較しながら解析を行った. 解析に先立ち,ZeroAccess について調査した.[9] によると, 図 6 に示すように, 感染マシンは P2P ネットワークでサーバ及びクライアント双方の役割を担い, ピアに接続しファイルやノードリストを共有する. その際, ノードは SuperNodes と NormalNodes の 2 種類に分類される. SuperNodes は,SuperNodes 同士で通信可能で, NormalNodes からの通信も受け付けることができる一方,NomalNodes は SuperNodes に接続することのみ可能で, 他の NomalNodes と直接通信することができない.NAT の制約下にある場合に,NomalNodes として動作する. 尚, 解析を進めると Practice_{3,4}.pcap は NomalNodes であることがわかる. 図 3-1([9] より抜粋 ) 1 プロトコル別時系列図 3-2 にプロトコル別時系列に表示したグラフを示す. 両者とも TCP 及び UDP パケットが全体の 99% 以上を占める. また TCP は段階的に減少していることがわかり,Practice_4.pcap では,5/18 遅くにほぼゼロになることがわかる. 2 DNS 通信 Practice_{3,4}.pcap について, 観測期間の初期段階に promos.fling.com の名前解決があった. 他は, 解析環境のノイズと思われる通信だったので考察は 図 3-2( 上が 3.pcap, 下が 4.pcap) 3 UDP 通信 (a) 接続先ポート番号表 3-1 に接続先 UDP ポート番号を示す.[5] によると, ボットの主な活動として Port:16471 は,Bitcoin mining( 仮想通貨である Bitcoin を稼ぐ手法 ) を, Port:16474 は,Click fraud( クリック報酬型広告を不正にクリックすることで広告料を騙し取る手法 ) とあり, データ解析により傾向を見ることを期待したが, 本稿では傾向を見ることはできなかった. 表 3-1 対象 UDP ポート番号 Practice_3.pcap 16471 Practice_4.pcap 16474 (b) 接続先 IP アドレスユニーク数及び重複表 3-2 に接続先ユニーク IP 数及び一致 IP 数を示す. 両者とも接続先 IP アドレス数は 3 万個程度であるが一致するものは 52 個と少ない. これはボットネットのバージョンが異なるとまったく別のネットワークを構築していることが推定される. 表 3-2 対象接続先 IP 数 Practice_3.pcap 29758 Practice_4.pcap 30319 上記で一致したもの 52 次に重複した 52 個のアドレスを分析したところ, アクセス数の多い上位 16 位までの IP アドレスが以下の特徴があることがわかった. *.253.254.253 ( 第一オクテットは, 116,113,206,197,190,135,158,184,183,134,182,119, 180,117,222,115. グローバルアドレスではあるが国, AS 番号はバラバラとなる ) すべて送信パケットで着信パケットがない ( 当該 IP アドレスはアクティブでない可能性あり ). ちなみに 17 位以降のアドレスは応答があった. (c) 受信元 IP アドレス時系列傾向図 3-1 のように, 受信する UDP パケットは SuperNodes からのものと考えられるが, 時系列でどの SuperNodes から通信があるか傾向を見るために, 受 - 121 -
信パケットの上位 10 位の送信元 SrcIP アドレスについて, グラフ化したものを図 3-3 に示す. 一部の IP アドレスで特定の期間通信が無い傾向がみられたが, 上位 10 位の送信元 SrcIP アドレスについては, ほぼまんべんなく通信を受信していることがわかる. (e) 国別受信パケット数時系列国別の受信パケット数を時系列で表したグラフを図 3-6-{1,2,3,4} に示す.30 分単位の棒グラフとなっている.Practice_3.pcap について,(d) で上位 :2 位の日本と, 上位 :3 位のルーマニアが発信国のパケット数について示す.Practice_4.pcap について,(d) で上位 :2 位に日本と上位 :9 位のスペインについて示す. これらから, 各国のタイムゾーンで日中帯にパケット数が増加する傾向わかる. 図 3-6-1 3.pcap 国 : 日本 図 3-3( 上が 3.pcap, 下が 4.pcap) さらに, すべての送信元 SrcIP アドレスを対象にして, 一時間単位でのユニーク IP アドレス数を図 3-4 に示す.Practice_3.pcap が毎時 1600 ユニーク IP アドレス数程度,Practice_4.pcap が毎時 1500 ユニーク IP アドレス数程度を示すことがわかる. 両者ともに観測期間全体にわたりほぼ一定数でとなっている. 図 3-6-2 3.pcap 国 : ルーマニア 図 3-6-3 4.pcap 国 : 日本 図 3-6-4 4.pcap 国 : スペイン 図 3-4( 上が 3.pcap, 下が 4.pcap) (d) 送信元 IP アドレス国別送信元 IP アドレス国別の上位 10 位を図 3-5 に示す. 図 3-5( 上が 3.pcap, 下が 4.pcap) 4 ICMP 通信 Practice_3.pcap については Port:16471 からの Practice_4.pcap につては Port:16474 からの到達不能を示すパケットが到着していた. しかしながら対応する該当ホストへのパケット送信はキャプチャデータから観測されなかったため, 一般に backscatter と考えられる. 両者ともに, 送信元パケットの 4 割が同一の特定アドレスであったことから, さらに踏み込んだ P2P ボットネット特有の考察もできる可能性がある. 5 TCP 通信表 3-1 で示した UDP の接続先ポート番号に対して, UDP で接続が可能な場合に,TCP 通信を同じポートに対して発行していることがわかった. これは Practice_1.pcap の TCP 通信で見た傾向と同一である.TCP パケットのペイロードについては, 平文でないため有意な文字列等の情報は発見できなかった. 6 パケットサイズ全パケットをサイズ別にグラフにしたものを図 3-7 に示す.Practice_3.pcap について 97%,Practice_4.pcap については 98% が, 1466Byte, 60Byte, 66Byte, 78Byte,74Byte 等の特定サイズのパケットであることがわかる. またそれぞれ半数以上が 100 バイト以下のサイズのパケットになっている. - 122 -
図 5-2 図 3-7( 上が 3.pcap, 下が 4.pcap, 数字はバイト数 ) 7. Practice_5.pcap の解析 1 プロトコル別時系列図 5-1 に, プロトコル別に時系列表示したク ラフを示す.TCP が大半を占め, 日々少量ながら HTTP 通信があることがわかる. また一日一度のスパイクは DNS 通信で解析環境のノイス と考えられる. 図 5-3 4 パケットサイス 全パケットをサイズ別にグラフ化したものを図 5-4 に示す.62Byte,78Byte,60Byte,66Byte のパケットが全体の 93% を示すことがわかった. 図 5-4 図 5-1 2 HTTP 通信 HTTP 通信は 2 個のホストへ接続し, 以下の GET リクエストを行うものであった. 応答パケットは無かった. GET /us2/gate.php HTTP/1.1 ホスト別の時系列リクエスト状況を図 5-2 に示す. 一定のリズムで 2 つのホストにリクエストをしていること, 2 ホスト間でリクエストの量に差異があることがわかる. 3 TCP 通信ほぼすべての通信が IP アドレス : 89.149.253.239, ポート番号 :4000 へのものであり,SYN パケットのみでコネクトしていないことがわかった. ある特定時間について,1 分単位でパケット数を示すヒストク ラムにしたク ラフを図 5-3 に示す. 一定のリス ムがあることがわかる. 8. まとめと考察これまでに見た特徴を再度考察する. 以下に列挙するこれらの特徴のうちいくつかは, 正常通信との差異を表す特徴量となりうる可能性とがあると考えられる. 1 定期的な通信 1.pcap の 30 分間隔の UDP 通信,2.pcap の 5 分間隔の TCP(55003) 通信, {3,4}.pcap の毎時 {1500,1600} ユニーク IP のピアとの UDP 通信, 5.pcap の一定リス ムでの HTTP 通信及び TCP(4000) 通信が見られた.5 つの pcap すべてで何らかの定期的なリス ムの通信を見ることができた. 2 パケットサイス 全体パケット個数を母数とした, 特定のサイス のパケット数及び 100Byte 以下のパケット数の割合を表 6 に示す.5 つのすべての pcap において特定サイス,100Byte 以下両者ともに高い割合であることがわかる. - 123 -
表 6 対象特定サイス 100Byte 以下 1.pcap 49% 47% 2.pcap 98% 74% 3.pcap 97% 69% 4.pcap 98% 67% 5.pcap 93% 89% 3 接続先 IP アドレス数これは pcap 毎に特徴が分かれた. 観測期間全体で,{3,4}.pcap のように 3 万 IP アドレス数程度の接続先が多いタイプ. 一方,{2,5}.pcap では,1 個及び 2 個の接続先である接続先限定タイプ.1.pcap はその中間のタイプと考えられる. 4 コネクトしない TCP 通信 1.pcap の TCP 通信,2.pcap の Port:55003 以外の一部の TCP 通信,5.pcap の TCP:4000 への通信のように延々と SYN パケットのみでコネクトしない TCP 通信がみられた. 5 UDP と TCP の関係 1.pcap の UDP 通信で応答のあった IP アドレスに対して TCP 通信を行う,{3,4}.pcap で同じく UDP 通信で応答があった IP アドレスに対して同一ポートで UDP 通信を行う特徴が見られた. 6 ダウンロード後の挙動の変化 1.pcap で bc.exe ダウンロード後に通信挙動が変化する事象が見られた. 7 接続先タイムゾーン {3,4}.pcap で, 通信先の各国のタイムゾーンで日中帯にパケットが増加する傾向が見られた. 8 亜種になると通信先がほぼ異なる {3,4.pcap} は類似の検体であるが, 通信先の大半が異なる. 9 複数の特徴ある接続先 IP アドレス {3,4.pcap} での,*.253.254.253 に見られたように, 第一オクテット以外が共通なもの. [2] G. Jacob, R. Hund, C. Kruegel, and T. Holz, Jackstraws:Picking Command and Control Connections from BotTraffic., USENIX Security, 2011. [3] S. Kondo, N. Sato, Botnet Traffic Detection Techniques by C&C Session Classification Using SVM, IWSEC 2007, LNCS 4752, pp.91-104, 2007. [4] R. Perdisci, W. Lee, and N. Feamster, Behavioral Clustering of HTTP-based Malware and Signature Generation using Malicious Network Traces, USENIX Security, 2010. [5] 大月ら, マルウェア感染検知のためのトラヒックデータにおけるペイロード情報の特徴量評価, MWS2012. [6] 桑原ら, パケットキャプチャーから感染種類を判定する発見的手法について, MWS2009. [7] 神園ら, マルウェア対策のための研究用データセット ~MWS Datasets 2013~, MWS2013. [8] ZeuS Tracker, https://zeustracker.abuse.ch/monitor.php ( 参照 2013/8/22) [9] The ZeroAccess Botnet Mining and Fraud for Massive Financial Gain, http://www.sophos.com/enus/medialibrary/pdfs/technical papers/sophos_zeroaccess_botnet.pdf ( 参照 2013/8/22) 9. おわりに本稿では,PracticDataset2013 の 5 個のデータセットについて特徴を解析し, 正常通信との差異の検出に効果がある可能性のある特徴を抽出した. 今後はこれらの特徴量の有効性を評価し, トラフィックロク のみを情報源として悪性通信が判定可能かを検証していく予定である. 参考文献 [1] Microsoft, financial services and others join forces to combat massive cybercrime ring http://www.microsoft.com/enus/news/press/2013/jun13/06-05dcupr.aspx ( 参照 2013/8/22) - 124 -