ここから本文です

Cuckoo Sandbox、Selenium WebDriver、bson解析――独自マルウェア解析環境を自動化した際に施した2つの工夫

7/31(月) 8:10配信

@IT

 本記事では、さまざまな企業が頭を悩ませる問題について、リクルートグループのコンピュータインシデント対応チーム「Recruit-CSIRT」の発想と技術をお伝えしています。

「オートシステム」になったOdoribaのシステム全体像

 「未知のマルウェアへの対応」と「マルウェアによる情報漏えい経路のブロック」を内製化するに当たっては、マルウェアの挙動ログが必要になる、という課題が残ります。

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

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

●自動化を行った背景

 研究機関AV-TESTによると、2016年には1億を超えるマルウェアが新しく作成されたそうです。

 リクルートテクノロジーズも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を使うときは日々バグフィックスや追加拡張のソースコード修正を継続的に見つつ、柔軟に自分のシステムにカスタマイズ適用できる応用力が大事だ」ということです。

●【工夫その2】リアルタイム可視化の自動化

 いわゆるサンドボックスでの振る舞い解析では、解析が終了するまで振る舞いが可視化されません。しかしながら一般的な解析は数十秒から数分であり、それくらいであれば解析終了を待つことも可能です。しかし、昨今の標的型攻撃で利用されるマルウェアには、感染後にすぐに動作せず長期潜伏するものや時刻指定で起動するもの、そして攻撃者に遠隔操作され継続的に動作するものも存在します。そのため、リバースエンジニアリングによる静的解析が難しい場合、長期的に観測する必要がある検体もあります。

 それを可能にするための工夫として、解析中の状態がリアルタイムに可視化されるエンジンとWebのUIを開発しました。サンドボックスを“電子レンジ”に例えると、“電子レンジ”のように温めている“皿”のどの“具材”がどれくらい温まっているかを測れる仕組みです。

 大きな違いは、現在のOdoribaシステムでは、近年の賢い電子レンジのように“温度”という自動終了条件を持たせていないことです。マルウェアの振る舞いには上限がないため、時間以外の条件で自動終了はできません。この部分はアナリストが状況を見て「解析終了ボタン」を押すことで判断します。

 このとき、表示が遅かったりログ量が増えて確認に時間がかかったりしては、自動化のうまみが減少してしまいます。そのため、アナリストが素早く正確に判断できるよう、いかにリアルタイムに情報を絞って表示するかを検討しました。

 可視化対象は、Cuckoo Sandboxで取得されるProcess Behaviorログ(bson形式=バイナリJSON形式)とPacket Captureファイル(pcap形式)です。

 Cuckoo SandboxではNoSQLの「MongoDB」がデータベースとして一般的に利用されますが、そのMongoDBに振る舞い結果(bson)が保存されるタイミングは解析終了後の逐次バッチ処理です。そのため、このbsonファイルを解析し、リアルタイムの可視化を実現しました。

 通信ログに関してはpcapファイルを解析しますが、ここでマルウェアでないOSの定期通信などは事前にキャプチャーフィルタリングで除外しています。

 これらの中から、われわれの観測に必要な最低限の情報カラムに絞って、新しく作った「Real-timeDB」に格納しました。通信先となるドメインやIPアドレスが確認できたらすぐにマルチスレッドで以下の3つの分析が走るようになっています。


1. 通信先がホスティングサーバかどうかの分析
2. Whois情報の調査
3. 「VirusTotal」を使った、既知の悪性かどうかの分析

 これらは当該通信先をファイアウォールやProxyで遮断可否の判断をするのに有益です。この分析結果が独自に作った「IntelligenceDB」に格納され、また必要最低限の情報カラムをリアルタイムに提示してくれます。Webブラウザ画面はデフォルト1分でリロードされ1分前からのアップデートは赤く反転して表示されます。

 当初は全てのログをバッチで読み込み表示していたため、長期的に解析しているとログが多量にたまり、遅延になることがありました。そこで、各ページにjsonファイルを事前に作成しておき、それをAjaxでJavaScriptから読み込む仕様に変えました。結果、シームレスに表示ができ差分強調ができる可視化ビューを開発できました。

●FIRST T.Cカンファレンスでの評価

 2017年1月に、本OdoribaシステムをCSIRTの国際カンファレンスFIRST Technical ColloquiumでのCall for Speakersにて応募し、3月初めにAcceptされ発表の機会を頂きました。4月にオランダで発表してきた内容が、こちら(https://www.first.org/events/colloquia/amsterdam2017/program#precruit-csirt)です。


 本稿で書けなかった部分も幾つか含まれているので、ご興味あればご覧いただければと思います。

 現地での評価はおおむね好評で、下記のような感想や質問を多く頂きました。

・なぜインターネットに、このシステムを公開しないのか?
・Cuckoo Sandboxオリジナルからの変更ログが欲しい
・開発予算もほとんど持たずにインシデントレスポンスの合間にどうやれば開発できたのか?
・社内LANとの隔離・接続はどのようにやっているのか?

 国際的なCSIRTカンファレンスにおいても、やはりOSSベースの取り組み共有事例は需要が高いことが分かりました。

 今回のOdoribaの取り組みは、インシデントレスポンスの合間に1人でやっていたため、1年もの開発期間がかかりました。その間にもマルウェアは時々刻々と進化し、「あれも実装しなきゃ。これも実装しなきゃ」の要件は増える一方でした。そんな中、優先度を立てて、必要な部分だけを抜き出す手法はリクルートのプロジェクト管理がとても参考になりました。例えばVMを検知するマルウェアについては、VMと分からないように細かい工夫を施し続けるのが一般的ですが、リクルートテクノロジーズの環境はVDI化が進んでおり仮想環境での業務が標準化しつつあるため、そこの開発要件は軽減させることができました。

 世界からのソースコードの公開需要に応えるため、急ぎソースコードを公開しました(https://github.com/Recruit-CSIRT/odoriba/)。Cuckoo Sandbox 2.0 rc1をどのように変更してカスタマイズしたかの変更点も強調して残しているので、同じようなことをされたい方の参考になれば幸いです。Cuckoo Sandboxと同じGPL v3ライセンスで公開しています。自由に改変、拡張して利用することも可能ですが、利用によって生じた損害については一切責任を負いかねますことをご了承ください。
 Recruit-CSIRTでは、皆で自分たちの解析ツール、分析システムを作れるCSIRTになろうと内製化に拍車が掛かっています。ご一読ありがとうございました。

●筆者紹介

○市田達也

リクルートテクノロジーズ ITソリューション統括部 サイバーセキュリティエンジニアリング部 インシデントレスポンスグループ

大手通信事業者のセキュリティオペレーションセンターを経て2015年から現職。前職ではマルウェア感染インシデント対応に従事。リクルートグループでは各種インシデント対応に加え、セキュリティ対策基盤の設計、開発も担当。Recruit-CSIRT所属。

最終更新:7/31(月) 8:10
@IT