Cuckoo Sandbox、Selenium WebDriver、bson解析――独自マルウェア解析環境を自動化した際に施した2つの工夫：マルウェア対策“一部”内製化大解剖（終）（1/2 ページ）

本連載では、ランサムウェアを含む「マルウェア感染」という、さまざまな企業が頭を悩ませる問題について、リクルートグループのコンピュータインシデント対応チーム「Recruit-CSIRT」の発想と技術をお伝えする。最終回は、独自マルウェア解析環境を自動化した際の技術的な工夫を紹介する。

[市田達也，リクルートテクノロジーズ]

　本連載「マルウェア対策“一部”内製化大解剖」では、ランサムウェアを含む「マルウェア感染」という、さまざまな企業が頭を悩ませる問題について、リクルートグループのコンピュータインシデント対応チーム「Recruit-CSIRT」の発想と技術をお伝えしています。

　連載初回の「リクルートのCSIRTが、マルウェア対策の一部を内製化した理由」では、「未知のマルウェアへの対応」と「マルウェアによる情報漏えい経路のブロック」を内製化するに当たっては、マルウェアの挙動ログが必要になる、という課題が残ることを説明しました。

　そして前回は、「未知のマルウェアへの対応」と「マルウェアによる情報漏えい経路のブロック」を内製化するに当たり、マルウェアの挙動ログが必要と考え、自社に特化したマルウェア解析環境「Odoriba」を構築し、2016年からマルウェアの悪性通信を分析できるようになったことをお伝えしました。

　しかし昨今のマルウェアの流通数をさばくには、手作業を減らして運用自動化が必要です。最終回では、どこをどのように自動化したかを紹介します。

自動化を行った背景

　研究機関AV-TESTによると、2016年には1億を超えるマルウェアが新しく作成されたそうです（参考：The AV-TEST Security Report 2016/2017）。

　リクルートテクノロジーズも2016年にランサムウェアの大量送付キャンペーンを受け、対応件数もマルウェアの数に応じて増加しました。さらに100MBを超える巨大なマルウェアが発見されて1体当たりにかかる解析時間も増えました。2015年は「Odoriba」という解析環境を作っただけで、出力されたログの取得や分析は人力でした。そこから、人力のコストを少しでも減らすために自動化を取り入れ、2016年には1年をかけOdoribaを「解析環境」から「オートシステム」に進化させました。

　こちらがそのシステム概要図です。

システム全体像

　「オートシステム」化をするに当たり、解析をコントロールする「Manage Server」をどう構築するかが肝心でした。低コストにしつつ、ある程度定評があるものという理由でオープンソースソフトウェア（OSS）の「Cuckoo Sandbox」を選定しました。カスタマイズする気でいたので、「何が取得できるか／できないか」「使いやすいかどうか」では選ばず、筆者が得意とするプログラム言語（Python）で書かれているかが重要でした。

　Cuckoo Sandboxの詳細は、ここでは割愛しますが、2.0系からメモリ解析や各種IOC（Indicator of Compromise）シグネチャの追加もあり、ただマルウェアを振る舞い解析するだけではなく、ある程度「マルウェアかどうか」の判定も自動で実施してくれます。かつては手動で多数のコンポーネントをインストールする必要があり手作業の多い構築作業でしたが、2017年の4月にリリースされたバージョンからは「Cuckoo Package」としてPythonパッケージ化され、インストールも容易になりました。

　次に、筆者が実装したシステムの主な部分を以下の図に抜き出しました。

　概要としては一般的な解析システムと同様に、マルウェア検体の「自動収集」→「自動投入」→「振舞のWeb可視化」です。これだけでもいくらか稼働を削減できますが、さらにこのシステムではリクルートテクノロジーズならではの仕様として、アンチウイルスソフトとの同居管理、「振舞変化のリアルタイム可視化」を実装しました。また、マルウェアがインターネットにつながった状態で実行されるため、インターネットに対して外部攻撃し、無関係な他人に悪影響がないように、トラフィックを見ながら全疎通を切る自動遮断スイッチも実装しました。

　ここからは、工夫したポイントを2つに絞ってお伝えします。

【工夫その1】マルウェア収集／投入と解析における自動化

　当初、解析システムへのマルウェアの投入は手動でWebのUIからSubmit（投入）していました。投入の際にパラメータの設定なども都度必要であり、量が多いと手作業が煩わしいものでした。そこで、まずインターネット上に公開されているマルウェア解析サービス「Malwr」やリクルートテクノロジーズの検知センサー製品のWebサーバからマルウェアを「収集」します。その収集はWebスクレイピング技術を用いて、Python（Requestsモジュール）で自動化しました。続く検体の「投入」プロセスも、事前設定時間後もしくは解析終了ボタンを押すことで、前の解析が終了したとして次を投入するように自動化しました。

　工夫した点として、Webブラウザ操作の自動化があります。前述の検知センサー製品から自動取得、投入するに当たり、検体のダウンロードリンクを入手するためには、マウスクリックでJavaScriptを実行する必要がありました。そこで、Webブラウザ操作を自動化できる「Selenium WebDriver」を使って一部補いました。実際にブラウザを起動して画面遷移を自動化するため動作速度は遅くなりますが、どこまで処理が届いているかのデバッグも容易になります。

　偶然にも、2017年2月末に200MBを超える巨大なマルウェアを解析できる必要がありました。当時利用していたCuckoo Sandbox 2.0 rc1ベースではWebのUI経由で投入できる最大サイズは25MBだったので、デフォルトで解析できないものでした。

　そこで、設定ファイルで1GBを上限に明示し、コマンドラインから投入してみましたが、「Guest VM」（仮想環境）のエージェントプログラムで検体を受け取る際にメモリエラーが起きてアップロードできませんでした。

　次に、エージェントプログラムのXML-RPCのデータチャンクサイズを拡張指定し実施したところ、エラーは出ず、エージェントプログラムがダウンしていました。従来のエージェントは検体のやりとりがXML-RPCであり、メモリリークを起こしたためです。

　そこで筆者は、インターネット上で他にもこの問題で困っている人がいないかを探し、開発中のCuckoo Sandboxの中に、XML-RPCではなく単にHTTPで検体をやりとりするものがあることを知りました。

　さらに偶然が重なり、ちょうどその1日前にCuckoo Sandboxの開発プロジェクトの方がUnicode対応の0.7版をアップロードしてくれており、そのソースコードを熟読しカスタマイズして即座に実装したことで、200MB超えの検体の解析ができるようになりました。その日はタイムリーに修正アップロードしてくれたjbremerさんに感謝でした。その後、2017年4月にリリースされたCuckoo Sandbox 2.0.0版では、デフォルトで1GBまでのファイル解析対応になりましたが、それより前にインシデント時の内製解析ができたため、自らシステムを開発していたかいがありました。

　ここで伝えたいのは、当たり前のことかもしれませんが、「OSSを使うときは日々バグフィックスや追加拡張のソースコード修正を継続的に見つつ、柔軟に自分のシステムにカスタマイズ適用できる応用力が大事だ」ということです。