リクルートのCSIRTが、マルウェア対策の一部を内製化した理由：マルウェア対策“一部”内製化大解剖（1）（2/2 ページ）

内製化による対応速度向上

　内製化を実現した結果、セキュリティベンダーとの連絡応答も含め、従来は101分かかっていた分析時間が、32分まで短縮。自分たちで詳細な挙動ログを凝視しながら判断ポイントを抽出していたため、さすがに数分レベルまでは短縮できませんでしたが、自分たちでマルウェア分析している満足感と自信が培われたことで、メンバーのモチベーションも向上し職場の雰囲気も良くなりました。

　ちょうどそのころ、WordPressで構築された一般のWebサイトが改ざんされて、そのサイトを介してマルウェアが社内のダウンロードサーバに誘導される事象が多く検知されました。

　この事象についても、自分たちで通信ログを追って、改ざんされた一般Webサイトを特定。そこから「どのような条件で悪性サイトに誘導されるか」についても調査しました。さらには、その一般サイトが改修されるまで社内からの通信をブロック。これにより、マルウェアの流入を根本から防ぐ運用ができたといえるでしょう。発見した一般サイトは半年で50件を超え、全てJPCERT/CCに報告、共有しています。

　このように大きな成果が出た一方で、アンチウイルスソフトベースのソリューションでは対応できないマルウェアがいるという理解も進みました。

解析環境で挙動しなかったマルウェアがいた

　近年のマルウェアは感染させたいOSの種類や、そこにインストールされているアプリケーションの種類、またはそのバージョン情報を確認して、「感染させるか、させないか」を制御できます。そのため、解析マシンが「解析のための環境」であるとマルウェアにばれてしまうと、マルウェアは動作を終了します。

　マルウェアの解析にはVM（仮想マシン）を利用することが多いため、マルウェアは、仮想環境のMACアドレスや特殊な起動プロセス、レジストリキーの他、時刻とCPUのクロック数の差分から、「長期間動かし続けていたかどうか」を識別するなど、細かいレベルで「この環境は感染させるべきか否か」を確認してきます。

　もちろんセキュリティベンダーのマルウェア解析製品の多くは、そのような動きを察知してマルウェアに“偽”の情報を渡すことで、「マルウェア解析環境ではない」というシグナルをつかませるようになっています。よくベンダーによるマルウェアのパターンファイル生成と攻撃者による新しいマルウェアの生成は「いたちごっこ」と言われますが、マルウェア解析環境においても、マルウェアとベンダーとの間に、情報の読まれ合いの「いたちごっこ」が続いているようです。

　内製化で大きな成果が出た一方で、当時のRecruit-CSIRTでは、ベンダー製品の解析環境で挙動しなかったマルウェアの存在を認識していました。

　挙動ログがないと、マルウェアのソースコードを読む「静的解析」を行わなければ、影響範囲の調査および「マルウェアかどうか」の判断は困難です。しかし静的解析には時間がかかり、解析を行える人材も乏しいため、せっかく内製化で縮めることができたスピードが失われてしまうことが予想されました。

「Recruit-CSIRTならではのマルウェア解析への道」とは

　ここで、リクルートグループにおけるマルウェア感染インシデント対応の要件を整理します。

　1.については、既知のマルウェアであれば、複数のベンダー製品のスキャン結果で挙動ログの代用ができ、対応できます。3.についても、センサーの通信ログが残っているため、挙動ログがなくても問題ありません。

　しかし、1.の中でも「未知のマルウェアへの対応」と2.の「マルウェアによる情報漏えい経路のブロック」には、マルウェアの挙動ログが必要という課題が残ります。特に標的型攻撃に利用されるマルウェアは、標的企業用に改変されたマルウェアの亜種が利用されやすく、駆除できずに情報漏えいに至るリスクが高いため、セキュリティベンダーのパターンファイルを待つ前に早急に対応することが求められます。

　しかし、ベンダー製品の解析環境でも挙動しなかったマルウェアを、どう動かせばいいのでしょうか？

　われわれは、マルウェア解析に長けている人材をセキュリティベンダーほど多数は抱えておらず、「いたちごっこ」を戦い切れるタフネスもありません。よって、スコープを絞ることで対応の品質を上げようと考えました。

　具体的には「リクルートグループに特化した独自解析環境の構築」に取り組みました。次回は、その解析環境「Odoriba」を紹介します。