第 3 章 事前調査 25
3.3 外部データを用いたマルウェア共通動作の解析
3.3.2 CCC DATAset を用いたマルウェア活動の分析
第3.3.1節で作成したモデルを検証するために，マルウェアによる通信データを調査した．
調査に利用したCCC DATAsetの通信データにはWindows 2000とWindows XPのホストをそ れぞれ1台ずつインターネットに接続し，攻撃活動に関する通信が含まれる．両ホストは定 期的にクリーンな状態にリセットされている．今回のモデルは正常状態からマルウェアへの 感染，マルウェアとしての活動開始までの遷移に着目するため，OSが初期状態に復元された 時刻を正確に把握しなければならない．一方の対象ホスト(以降、H1)はWindows XPであり，
起動時にtime.windows.com.への問い合わせ，およびNTPによる時間同期を実行する。その
ため，通信データからH1が送信元もしくは宛先ホストとなっているパケットを抽出し，前回 のリセット予想時刻から一定時間以上経過した後に発生するtime.windows.comを問い合わせ るDNSパケットと，NTPのパケットによって通信データを分割した．これによって144個 の通信データセットが生成された，
CCC DATAset2008を復元時刻によって分割した全てのデータセットについて，状態遷移を
調査した．調査した結果を表3.6に示す．複数のマルウェアに感染したと見られるデータセッ トもあるが，表の状態遷移では最初にマルウェアに感染した際の状態遷移を示している．そ れぞれのデータセット群をDNとして分類した．ただし，D0では注目すべき通信が発生せず，
D1は攻撃が成功しなかった可能性が高いため除外して議論する．また，状態遷移のモデルに 従わなかったものをDeとした．これはC&Cサーバとの通信をせずに自律的に感染活動を実 施しており，本論文におけるマルウェアの定義とは異なる．データセットの状態遷移では，各 データセットは図3.6で示したどの状態を遷移したのかを示している．結果の欄ではマルウェ アが最後の状態から最終的にどのような活動に至ったかを示している．最後の状態以降にマ ルウェアとしての活動と思われる通信が観測されなかった場合が終了，観測されたデータセッ トが継続，終了に加えて最後の状態での活動に不備があったと見られる痕跡が観測されたデー タセットが失敗としている．
状態遷移に基づいた分析
表3.7では各状態が遷移する際の時間間隔として，各状態遷移のサンプル数，平均時間，標 準偏差，サンプル中の最小時間，サンプル中の最大時間を示している．今回の分析では状態遷 移の時間を，遷移前の状態における最後の動作の時刻と遷移後の状態における最初の動作の 時刻の差としている．これは各状態では複数回類似した動作が繰り返される場合があり，通 信データだけではどの動作が次の状態遷移へのきっかけになったかを判別するのが難しいた めである．例えば，実行ファイルがダウンロードされる前に攻撃コードの受信する回数は，各 データセットにおいて平均3.2回発生しており，成功した攻撃コードを特定するのは難しい．
表3.6:分割したデータセットの分類 データセットの状態遷移 結果 件数
D0 S0 終了 11
D1 S0→S1 終了 9
D2 S0→S1→S2 失敗 26
D3 S0→S1→S2 終了 5
D4 S0→S1→S2→S4 失敗 1 D5 S0→S1→S2→S4 継続 13 D6 S0→S1→S2→S4→S5 継続 51 D7 S0→S1→S2→S3→S4→S5 継続 27 De モデルから外れたデータセット ---- 1 合計 144
そのため，このような状態遷移を分析する場合には今後も検討が必要となる点に留意するべ きである．
表ではS1→S2，S2→S3，S2→S4，S3→S4の状態遷移はそれぞれ平均時間が15秒未満 となっており，最大時間もそれぞれ60秒程度である．これは，マルウェアがあらかじめ定め られたアルゴリズムに従って単独で動作しているため，次の状態に遷移するための待ち時間 を設ける必要がないためだと考えられる．各遷移において遷移時間が比較的長いサンプルが いくつか存在した．これらはホスト内部における情報の検索にかかる時間か，もしくは通信 の間隔を長くしセキュリティ管理者に発見されにくくしていると予想される．
一方S4→S5は平均遷移時間が137.091秒，最大遷移時間が489.683秒であり，他の状態遷 移と比較して間隔が長い．これは単独で実行しているプログラムに従った動作ではなく，IRC プロトコルによってC&Cサーバから非同期的に送信されるコマンドに従っているためであ る．IRCによる他ホストへの感染活動の実行命令例は[34]などに示されている．今回のデー タセットでは活動時間が限られていたため，長期間の観測では遷移までの時間が長くなる可 能性がある．
表3.7:各状態開始から遷移までの所要時間
状態遷移 数 平均遷移時間 標準偏差 最小遷移時間 最大遷移時間
S1→S2 96 5.116 11.401 0.041 66.416
S2→S3 27 2.688 9.765 0.219 51.451
S2→S4 63 4.618 11.050 0.282 66.416
S3→S4 27 11.334 16.190 0.006 59.280
S4→S5 78 137.091 147.392 1.096 489.683
(遷移時間の単位は秒，各計算結果の小数点第4位以下は切り捨て)
各状態における観測事象
第3.3.1節で述べたとおり，S1,2,3,4,5の各状態は具体的な通信内容を限定しない．そのため，
CCC DATAsetにおいて観測された具体的な通信内容について述べる．
まず，S1ではWindows OSで標準的に備わっているNetBIOSやDCERPCの脆弱性を利用 した攻撃コードが送信され，感染している．ただし，CCC DATAsetの通信データではホスト の状態変化を知るためのデータがないため，どの攻撃によって感染したかを特定するのは難 しい．そのため，S2へ遷移する直前の攻撃をS1の成功と見なした．
S2の通信内容について解析した結果を表3.8に示す．実行ファイルのダウンロードを発見 するためにはWindowsで利用される実行ファイルのフォーマット[28]のパターンを検知する ルールを作成し，検査した．このルールによってTCPおよびUDPによる通信のペイロード を全て検査したため，暗号化されていない通信中の実行ファイルを検知できる．また，実行 ファイルが検知されなかったデータセットについても目視で確認したが，暗号化などによっ て検知を回避した形跡は発見されなかった．独自プロトコルによるダウンロードおよびアッ プロードは全て同一のプロトコルであると見られる．バックドアによる実行ファイルのダウ ンロードでは，Windowsのコマンドプロンプトを利用してFTPコマンドを発行しているが，
実行ファイルのダウンロードは確認されなかった．TFTPによる実行ファイルのダウンロード 失敗では，サーバ側のホストが応答せず通信が終了していた．
S3では著名なWebサイトやメールサーバに接続を試み，インターネットへの到達性を確認 していると予想される．観測された確認方法は主に2種類ある．1つは著名なメールサービス のMXレコードを問い合わせた後，DNSの応答に含まれるメールサーバに対してSMTP[35]
の標準ポート番号である25番へ接続を試みている．ただし，CCC DATAsetの環境では内部 から外部へのTCPポート25番がフィルタリングされていたと見られ，全てのメールサーバ から応答が観測されなかった．もう1つの確認方法はWebサイトから特定のファイルをダウ
表3.8:S2における通信内容の内訳
ダウンロード方法 結果 件数
独自プロトコルによる攻撃元ホスト 成功 83 からの実行ファイルのダウンロード 失敗 0 独自プロトコルによる攻撃元ホスト 成功 7 からの実行ファイルのアップロード 失敗 5 DNSによる名前解決およびHTTP 成功 7 による実行ファイルのダウンロード 失敗 0 バックドアによって攻撃元ホストが 成功 0 指示した実行ファイルのダウンロード 失敗 20 TFTPによる実行ファイルの 成功 1
ダウンロード 失敗 1
ンロードする手法である．HTTPによるインターネットへの到達性確認にはAOLのインスタ ントメッセンジャーやICQのインストールファイルが利用されていた．筆者が独自に観測し たマルウェアの活動では，ポート25番への到達性がある場合に迷惑メールの配信を開始した ものがあるため，到達性確認後の活動にも影響していると推測される．
S4におけるC&Cサーバとの通信は全てIRCプロトコルを利用していた．データセット
D4,5,6,7においてIRC接続は合計216件発生していたが，TCPのサーバ側ポート番号はIANA で定められている標準のポート番号[36]を利用していたのは29件のみであった．D4での接 続失敗はDNSによって問い合わせたIRCサーバのアドレスから応答が無かったためである．
ただし，別のデータセットでは同一のサーバとポート番号に対してIRCの接続が確立してい たことから，サーバ側ホストの一時的な問題によって接続が失敗したと見られる．
S5における他ホストへの感染活動はS1での攻撃と同様に，WindowsのNetBIOSやDCERPC の脆弱性を利用するためポート開放の確認と攻撃となっている．最初に観測されたスキャン の宛先ポート番号はTCPの135番が71件，139番が2件，445番が6件であった．