Malware Analysis Operations(MAOps)の自動化

日々発生するインシデント調査を効率化するために、分析を自動化することは、すべてのマルウェア分析者が取り組んでいる課題ではないかと思います。クラウドを中心とした技術(CI/CDやサーバーレス、IaCなど)は、MAOpsを効率的に自動化することができる素晴らしいソリューションです。今回は、JPCERT/CCで行っているクラウド上でのマルウェア分析の自動化方法について、以下の事例をもとに紹介します。

  1. Malware C2 Monitoring
  2. Malware Hunting using Cloud
  3. YARA CI/CD system
  4. Surface Analysis System on Cloud
  5. Memory Forensic on Cloud

Malware C2 Monitoring

C2サーバーを監視することは、攻撃者の活動を理解する上で重要なため、多くのマルウェア分析者は日ごろから行っています。ただ、C2サーバーの監視には、必要以上にアクセスすると攻撃者にアクセスをブロックされてしまったり、自分自身が攻撃者のターゲットになってしまうかもしれないというリスクがあります。これらの問題は、クラウドサービスを使えば解決できます。

JPCERT/CCでは、クラウドサービスを使ってラッキービジター詐欺に使用されているC2サーバーを監視しています。攻撃者は、改ざんされたサイトにアクセスしてきたユーザーをラッキービジター詐欺サイトにリダイレクトするために、改ざんされたサイトに対してC2サーバーから命令を送っています。C2サーバーから送られるリダイレクト先URLは、定期的に変更されており、C2サーバーを監視していれば、新たなリダイレクト先URLを知ることが可能です。
この攻撃に対してJPCERT/CCでは、C2サーバーの発見およびリダイレクトURLの収集、Webブラウザーでラッキービジター詐欺サイトへのリダイレクトを遮断するためのリダイレクトURLのDenylistへ登録までの処理を自動化しています。具体的には、図1のようなフローで行っています。

ラッキービジター詐欺C2サーバー監視フロー
図1: ラッキービジター詐欺C2サーバー監視フロー

このシステムは、図2のとおりAWS上で動作しており、サーバーレスサービスであるLambdaでC2のスキャンを行い、その結果をGitHub ActionでGoogleセーフブラウジングにレポートしています。クラウド上でC2サーバーを監視すれば、もしもC2サーバーにてアクセス制限をかけられてしまった際も、別リージョンを使うことで簡単に回避することが可能になります。

ラッキービジター詐欺C2サーバー監視システム
図2: ラッキービジター詐欺C2サーバー監視システム

C2サーバーの監視結果(リダイレクト先URLリスト)については、以下のGitHubレポジトリに公開しています。
https://github.com/JPCERTCC/Lucky-Visitor-Scam-IoC

Malware Hunting using Cloud

マルウェア分析者は、日頃からIoC情報の収集などを目的に、マルウェアハンティングを行っており、VirusTotalなどからマルウェアをダウンロードしては、分析するという作業を繰り返しています。しかし、マルウェアは攻撃者によって日々大量に作成されており、すべてのマルウェアを手動で分析することは不可能です。このようなマルウェアをハンティングする際も、クラウドサービスを活用することで簡単に自動分析システムを構築することが可能です。

JPCERT/CCでは、Cobalt Strike Beaconをインターネット上から自動収集して、分析結果を蓄積するシステムを運用しています。図3は、本システムの動作フローです。Cobalt StrikeのC2サーバーは、インターネット上に多数存在し、VirusTotalなどオープンなプラットフォーム上に多数の研究者によって情報がインプットされています。その情報をもとにC2サーバーの調査を行い、検体の収集および分析を自動で行います。

Cobalt Strike Beacon自動収集・分析フロー
図3: Cobalt Strike Beacon自動収集・分析フロー

このシステムは、AWSのサーバーレスサービスとGitHub上で動作しています。ポイントとなる、C2サーバーへの接続とマルウェア分析はLambda上で行っています。また、自動でC2サーバーの情報を収集するだけでなく、手動でC2サーバーを調査するためにAPIも準備しています(API Gateway)。オープンソースのデータだけだと、すべてのC2サーバーを網羅できないため、未知のC2サーバーを発見した場合は、手動で分析する必要がありますが、このようにAPIを準備しておけば、C2サーバーのURLを与えるだけで検体をダウンロードすることなく、C2サーバーの調査が可能になります。

Cobalt Strike Beacon収集システム
図4: Cobalt Strike Beacon収集システム

Cobalt Strike Beacon収集システムの分析結果については、以下のGitHubレポジトリに公開しています。
https://github.com/JPCERTCC/CobaltStrike-Config

YARA CI/CD system

YARAルールの自動作成ツールは、さまざまなものが公開されているものの、決定的なツールは現状存在しません。そのため、YARAルールの作成は、マルウェア分析者が手作業で行う必要があり、時間がかかる作業となっていることから、YARAルール作成の自動化は課題となっています。ただ、すべてのマルウェアに共通したYARAルール自動作成の方法はないものの、検体のパターンによっては自動で生成できる可能性もあります。

JPCERT/CCでは、特定パターンのマルウェアに関しては、YARAを自動生成するシステムを運用しています。ここでは一例として、HUI Loaderと呼ばれるAPT10、Blue Termite、A41APTなどで使われているローダーのYARAルールを作成するCI/CDシステムについて紹介します。HUI Loaderは、本体となるエンコードされたマルウェアをロードして、デコードして、メモリ上実行します。詳しい仕組みについては、過去のJPCERT/CC Eyesで公開していますので、そちらをご覧ください。
HUI Loaderのようなローダー型マルウェアの共通した問題として、ローダーはマルウェアハンティングで発見できても、それが読み込むエンコードされたマルウェア本体を見つけることができないことがよくあります。ただし、このような場合、ローダーのエンコードアルゴリズムはわかっているので、エンコードされたマルウェアの検知するためのYARAルールを作成することが可能です。図5は、本システムの動作フローです。

HUI Loader YARA CI/CDフロー
図5: HUI Loader YARA CI/CDフロー

このシステムも、AWSのサーバーレスサービスとGitHub上で動しています。VirusTotalから検体を収集し、その検体を自動分析し、YARAルールを自動生成し、生成したYARAルールをVirusTotalに適用することで、新たな検体の収集が可能になります。ここまでの3つのシステムを紹介しましたが、マルウェア分析はAWS上だとLambdaとS3だけあれば、大体のことが実現可能です。

HUI Loader YARA CI/CDシステム
図6: HUI Loader YARA CI/CDシステム

HUI Loaderの自動分析結果については、以下のGitHubレポジトリに公開しています。
https://github.com/JPCERTCC/HUILoader-research

Surface Analysis System on Cloud

マルウェア分析者は、セキュリティベンダーから公開されるレポートやブログ記事等から最新のマルウェアに関する情報を収集しますが、それらレポートに載っているマルウェアの名称はベンダー独自の名前だったり、ハッシュ値のみしか掲載されていなかったりということが多いため、レポート内容だけでは自組織で認識しているマルウェアとの比較が難しいことがあります。レポートに載っているハッシュ値などからマルウェアの内容を瞬時に判別、例えば自組織のYARAルールを使ったスキャン結果をすぐに確認することができれば、そのレポートと自組織が集めている情報との関係性がわかり、リサーチのスピードを向上させることができます。

このような目的でもクラウドサービスは活用できます。具体的には、図7のようなフローで動作するシステムを構築することで、この問題を解決することができます。図7のフローのとおり、Webブラウザーのプラグインを使って、調べたいハッシュ値情報を分析システムに送信します。分析システムでは、VirusTotalからマルウェアをダウンロードし、YARAスキャンなど各種分析ツールを使った分析が行われて、結果が表示されます(図8)。

ベンダーレポートからマルウェア分析を行うフロー
図7: ベンダーレポートからマルウェア分析を行うフロー

マルウェア分析結果確認画面
図8: マルウェア分析結果確認画面

本システムはAWS上に構築することが可能であり、図9のような仕組みになっています。Webブラウザーのプラグインから送信されてきたハッシュ値をAPI Gatewayで受信し、それをトリガーとしてBatchでDockerを立ち上げて、マルウェア分析を行います。分析結果は、S3にHTMLとして保存しながら、分析結果をSNSでメール送信します。また、Twitterにも多数の研究者がマルウェアのハッシュ値を投稿しているので、その情報を収集・分析する機能を取り込むことで、情報収集の自動化も可能になります。

表層分析システム
図9: 表層分析システム

さらに、このような分析システムをIaC化しておけば、簡単に新たな分析ツールを組み込んで使用することも可能になります。例えば、特定のマルウェアの設定情報を抽出するスクリプトを作成し、IaCに組み込めば、クラウド上への反映も簡素化できます。

上記で説明した分析システムをTerraform化したものをGitHubレポジトリで公開しています。
https://github.com/JPCERTCC/SurfaceAnalysis-on-Cloud

Memory Forensic on Cloud

インシデント調査時には、多数の端末を同時に調査しないといけないケースがあります。多数の端末を同時にメモリフォレンジックする際は、1台の端末で行うことは難しく、調査を行う端末のスペックによっては時間がかかってしまいます。このような問題はクラウドサービスを活用することで解決できます。図10がAWS上に構築したメモリフォレンジックシステムです。

メモリフォレンジックシステム
図10: メモリフォレンジックシステム

S3にメモリイメージを保存すると、それをトリガーとしてBatchでDockerを立ち上げて、メモリフォレンジックツールであるVolatility Frameworkによってメモリイメージの分析が行われます。分析結果は、S3にHTMLとして保存しながら、分析結果をSNSでメール送信します。図11のように、分析結果を保存しておけば、再度同じ分析を繰り返す必要もなくなるため、分析作業の効率化につながります。本システムでは、メモリイメージの分析ごとにBatchでDockerが立ち上がる仕組みであるため、複数台の分析を同時並行することが可能です。

メモリフォレンジック分析結果確認画面
図11: メモリフォレンジック分析結果確認画面

上記システムを構築するためのTerraformコードをGitHubレポジトリで公開しています。
https://github.com/JPCERTCC/MemoryForensic-on-Cloud

おわりに

今回紹介したものは、MAOpsにクラウドサービスを活用する一例です。他にもさまざまなパターンの活用が考えられるかと思います。ぜひ、クラウドサービスを活用して日々のマルウェア分析の効率化に取り組んでみてはいかがでしょうか。

インシデントレスポンスグループ 朝長 秀誠

≪ 前へ
トップに戻る
次へ ≫