パケットキャプチャからみた悪性通信に関する特徴の考察
田中 恭之 畑田 充弘 稲積 孝紀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 から取得するシステムコールログを組 み合わせ，特徴のある動作をグラフ化，クラス タリングし，テンプレート化し，機械学習を用
Computer Security Symposium 2013 21 - 23 October 2013
いることで，未知の悪性通信の識別に成功して いる．一方，このようなホストベースのログは， ユーザ PC にログを取得する仕組みを導入する必 要があり，特に運用の観点から，ログの入手の ハードルが上がるため，トラフィックログのみ から悪性通信を特定できることが望まれる． 2. 関連研究 近藤らは IRC プロトコルベースの C&C セッショ ンについて，トラフィックログのパケットヘッ ダ情報のみに着目し，機械学習を用いて識別を 行っている．機械学習では特徴ベクトルを何に するかが要となるが，セッション情報，パケッ トシーケンス，パケットヒストグラムを特徴ベ クトルとして定義し，評価を行い，パケットヒ ストグラムの有効性が確認されている．[3] Perdisci らは，C&C セッションを含む HTTP プ ロトコルベースのペイロード情報を用いて，定 義した特徴ベクトルに基づき，３ステップでク ラスタ化し，ネットワークシグネチャを作成， アンチウイルスソフトで検出できない未知検体 の検出を可能とする評価結果を出している．特 徴ベクトルとしては，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 に，プロトコル別に時系列表示したグラ フを示す．グラフより以下がわかる． ・定期的な DNS 通信，UDP 通信 ・TCP 通信は一定期間急激に減少 ・通信が無い期間の存在 ・5/22 未明を境に傾向が変化 図 1-1 ② HTTP 通信 HTTP 通信は，google と checkip.dyndns.org の 疎通確認と eclosion-media.net からの bc.exe の ダ ウ ン ロー ド があ っ た ． こ の ダウ ン ロー ドは 5/22 の未明に行われており，①の傾向の変化と 関連性が考えられる． ③ DNS 通信 DNS 通信の詳細を図 1-2 に示す．15 分間隔で規 則的に通信があることがわかる．またパケット キャプチャにより以下のドメインの名前解決を 繰り返し行っていることがわかった． eldvision.net donfinale.com despicableu.com
図 1-2 ④ UDP 通信 UDP 通信の詳細を図 1-3 に示す．30 分間隔で 規則的に通信があることがわかる．①で見た 5/22 未明のバイナリダウンロード前後で通信の 挙動が変化したことがわかる．1 分間程度で通信 が終了する傾向が．9 分間程度継続し，後半に通 信量が多くなる傾向が見られる． 図 1-3 また，UDP の通信先 IP アドレスについて，前半 は IP アドレスが徐々に減っていく傾向がみられ たが，後半の IP アドレス数は 27 個で増減な し，すべて同一アドレスであることがわかっ た． ⑤ TCP 通信 TCP 通信については，すべてコネクトしていな いことがわかった．また④の UDP 接続で応答が ある IP に対してのみ TCP 接続を試みていること がわかった． ⑥ パケットサイズ 図 1-4 のとおり，全パケットのうち，特定サ イズのパケットが約半数を占めることがわかっ た．また 1466byte,342byte,146byte を除けばい ずれも 100 バイト以下の比較的小さなパケット であることがわかった． 図 1-4（数字はバイト数） ⑦ ZeuSTracker との比較 Zbot は Zeus の亜種であるため， ZeuSTracker[8]で提供される IP アドレスとの比 較を行った． Practice_1.pcap:928 ユニーク IP アドレス ZeuSTracker:507 ユニーク IP アドレス (2013/8/1) 結果，マッチしたアドレスは 0 件であった． 5. Practice_2.pcap の解析 ① プロトコル別時系列 図 2-1 にプロトコル別に時系列表示したグラフ を示す．大半のトラフィックは 5/18 の TCP 通信 である．また一日一度（午前 3 時）の定期的な DNS 通信は検体のものでなく解析環境のノイズと 思われるので解析は行わない． 図 2-1 ② DNS 通信 以下のドメインの名前解決を 5/18 及び 5/25 に 行っていることがわかった． priv.gigaservice.it ③ TCP 通信 すべての通信が，IP アドレス:78.24.188.201， Port:55003 のものであった．このアドレスは② で 名 前 解 決 し て い た IP ア ド レ ス で あ り ， 2013/7/4 時 点 で 名 前 解 決 可 能 だ っ た が ， 2013/8/7 時点では名前解決できなくなっていた． 通信内容の一部を図 2-2 に示す．ユーザ名と ID を変化させログインを試みているようだが，い ずれも bann されていてログインができていない 様子である．この繰り返し以外のログは無かっ た．また図 2-3 に示すように，5 分に一度の定期 的な通信となっていることがわかった． 図 2-2 図 2-3 ④ パケットサイズ 全パケットをサイズ別にグラフにしたものを図 2-4 に示す．全体の 98%が特定サイズのパケットであるこ とがわかる．特に 66Byte のパケットが半数以上を占 める．また 7 割程度が 100 バイト以下のパケットにな
っている． 図 2-4 6. Practice_{3,4}.pcap の解析 Practice_3.pcap 及び Practice_4.pcap は類似の検体 であるため比較しながら解析を行った．解析に先立 ち，ZeroAccess について調査した．[9]によると，図 6 に示すように，感染マシンは P2P ネットワークでサー バ及びクライアント双方の役割を担い，ピアに接続し ファイルやノードリストを共有する．その際，ノードは SuperNodes と NormalNodes の 2 種類に分類される． SuperNode ｓ は ， SuperNodes 同 士 で 通 信 可 能 で ， NormalNodes からの通信も受け付けることができる一 方，NomalNodes は SuperNodes に接続することのみ 可能で，他の NomalNodes と直接通信することができ ない．NAT の制約下にある場合に，NomalNodes とし て動作する．尚，解析を進めると Practice_{3,4}.pcap は NomalNodes であることがわかる． 図 3-1([9]より抜粋) ① プロトコル別時系列 図 3-2 にプロトコル別時系列に表示したグラフを示 す．両者とも TCP 及び UDP パケットが全体の 99%以 上を占める．また TCP は段階的に減少していることが わかり，Practice_4.pcap では，5/18 遅くにほぼゼロに なることがわかる． ② DNS 通信 Practice_{3,4}.pcap について，観測期間の初期段 階に promos.fling.com の名前解決があった．他は， 解析環境のノイズと思われる通信だったので考察は 行わないこととした． 図 3-2（上が 3.pcap,下が 4.pcap） ③ 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 (ｂ) 接続先 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 アドレスはアクティブでない可能性あり）．ちなみに１７ 位以降のアドレスは応答があった． (ｃ) 受信元 IP アドレス時系列傾向 図 3-1 の よ う に ， 受 信 す る UDP パ ケ ッ ト は SuperNodes からのものと考えられるが，時系列でどの SuperNodes から通信があるか傾向を見るために，受
信パケットの上位 10 位の送信元 SrcIP アドレスにつ いて，グラフ化したものを図 3-3 に示す．一部の IP ア ドレスで特定の期間通信が無い傾向がみられたが， 上位 10 位の送信元 SrcIP アドレスについては，ほぼ まんべんなく通信を受信していることがわかる． 図 3-3（上が 3.pcap,下が 4.pcap） さらに，すべての送信元 SrcIP アドレスを対象にし て，一時間単位でのユニーク IP アドレス数を図 3-4 に示す．Practice_3.pcap が毎時 1600 ユニーク IP ア ドレス数程度，Practice_4.pcap が毎時 1500 ユニーク IP アドレス数程度を示すことがわかる．両者ともに観 測期間全体にわたりほぼ一定数でとなっている． 図 3-4（上が 3.pcap,下が 4.pcap） (ｄ) 送信元 IP アドレス国別 送信元 IP アドレス国別の上位 10 位を図 3-5 に示 す． 図 3-5（上が 3.pcap,下が 4.pcap） (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-6-2 3.pcap 国：ルーマニア 図 3-6-3 4.pcap 国：日本 図 3-6-4 4.pcap 国：スペイン ④ ICMP 通信 Practice_3.pcap については Port：16471 からの Practice_4.pcap につては Port：16474 からの到達不 能を示すパケットが到着していた．しかしながら対応 する該当ホストへのパケット送信はキャプチャデータ から観測されなかったため，一般に backscatter と考 えられる．両者ともに，送信元パケットの 4 割が同一 の特定アドレスであったことから，さらに踏み込んだ P2P ボットネット特有の考察もできる可能性がある． ⑤ TCP 通信 表 3-1 で示した UDP の接続先ポート番号に対して， UDP で接続が可能な場合に，TCP 通信を同じポート に 対 し て 発 行 し て い る こ と が わ か っ た ． こ れ は Practice_1.pcap の TCP 通信で見た傾向と同一であ る．TCP パケットのペイロードについては，平文でな いため有意な文字列等の情報は発見できなかった． ⑥ パケットサイズ 全パケットをサイズ別にグラフにしたものを図 3-7 に 示す．Practice_3.pcap について 97%，Practice_4.pcap に つ い て は 98% が ， 1466Byte ， 60Byte ， 66Byte ， 78Byte，74Byte 等の特定サイズのパケットであること がわかる．またそれぞれ半数以上が 100 バイト以下の サイズのパケットになっている．
図 3-7（上が 3.pcap,下が 4.pcap,数字はバイト数） 7. Practice_5.pcap の解析 ① プロトコル別時系列 図 5-1 に，プロトコル別に時系列表示したグラ フを示す．TCP が大半を占め，日々少量ながら HTTP 通信があることがわかる．また一日一度の スパイクは DNS 通信で解析環境のノイズと考え られる． 図 5-1 ② HTTP 通信 HTTP 通信は 2 個のホストへ接続し，以下の GET リクエストを行うものであった．応答パケットは無かっ た． GET /us2/gate.php HTTP/1.1 ホスト別の時系列リクエスト状況を図 5-2 に示す．一 定のリズムで 2 つのホストにリクエストをしていること， 2 ホスト間でリクエストの量に差異があることがわかる． ③ TCP 通信 ほぼすべての通信が IP アドレス: 89.149.253.239，ポート番号:4000 へのものであ り，SYN パケットのみでコネクトしていないこと がわかった．ある特定時間について，1 分単位で パケット数を示すヒストグラムにしたグラフを 図 5-3 に示す．一定のリズムがあることがわか る． 図 5-2 図 5-3 ④ パケットサイズ 全パケットをサイズ別にグラフ化したものを図 5-4 に 示す．62Byte，78Byte，60Byte，66Byte のパケットが 全体の 93%を示すことがわかった． 図 5-4 8. まとめと考察 これまでに見た特徴を再度考察する．以下に 列挙するこれらの特徴のうちいくつかは，正常 通信との差異を表す特徴量となりうる可能性と があると考えられる． ① 定期的な通信
1.pcap の 30 分間隔の UDP 通信，2.pcap の 5 分 間 隔 の TCP(55003) 通 信 ， {3,4}.pcap の 毎 時 {1500,1600}ユニーク IP のピアとの UDP 通信， 5.pcap の 一 定 リ ズ ム で の HTTP 通 信 及 び TCP(4000)通信が見られた．5 つの pcap すべてで 何らかの定期的なリズムの通信を見ることがで きた． ② パケットサイズ 全体パケット個数を母数とした，特定のサイ ズのパケット数及び 100Byte 以下のパケット数の 割合を表 6 に示す．5 つのすべての pcap において 特定サイズ，100Byte 以下両者ともに高い割合で あることがわかる．
表 6 対象 特定サイズ 100Byte 以下 1.pcap 49% 47% 2.pcap 98% 74% 3.pcap 97% 69% 4.pcap 98% 67% 5.pcap 93% 89% ③ 接続先 IP アドレス数 これは pcap 毎に特徴が分かれた．観測期間全 体で，{3,4}.pcap のように 3 万 IP アドレス数程 度の接続先が多いタイプ．一方，{2,5}.pcap で は，1 個及び 2 個の接続先である接続先限定タイ プ．1.pcap はその中間のタイプと考えられる． ④ コネクトしない TCP 通信
1.pcap の TCP 通信，2.pcap の Port:55003 以外 の一部の TCP 通信，5.pcap の TCP:4000 への通信 のように延々と SYN パケットのみでコネクトしな い TCP 通信がみられた． ⑤ UDP と TCP の関係 1.pcap の UDP 通信で応答のあった IP アドレス に対して TCP 通信を行う，{3,4}.pcap で同じく UDP 通信で応答があった IP アドレスに対して同一 ポートで UDP 通信を行う特徴が見られた． ⑥ ダウンロード後の挙動の変化 1.pcap で bc.exe ダウンロード後に通信挙動が変 化する事象が見られた． ⑦ 接続先タイムゾーン {3,4}.pcap で，通信先の各国のタイムゾーンで 日中帯にパケットが増加する傾向が見られた． ⑧ 亜種になると通信先がほぼ異なる {3,4.pcap}は類似の検体であるが，通信先の大 半が異なる． ⑨ 複数の特徴ある接続先 IP アドレス {3,4.pcap}での，*.253.254.253 に見られたよう に，第一オクテット以外が共通なもの． 9. おわりに 本稿では，PracticDataset2013 の 5 個のデータ セットについて特徴を解析し，正常通信との差 異の検出に効果がある可能性のある特徴を抽出 した．今後はこれらの特徴量の有効性を評価し， トラフィックログのみを情報源として悪性通信 が判定可能かを検証していく予定である． 参考文献
[1] Microsoft, financial services and others join forces to combat massive cybercrime ring
http://www.microsoft.com/en-us/news/Press/2013/Jun13/06-05DCUPR.aspx （参照 2013/8/22）
[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/en-us/medialibrary/PDFs/technical papers/Sophos_ZeroAccess_Botnet.pdf （参照 2013/8/22）
