EDRを使った分析の課題とSOCでの取り組みについて

NTTセキュリティ・ジャパン SOCアナリスト 林です。

私たちSOCでは５年程前からEDR（Endpoint Detection and Response）製品を利用したリアルタイム分析を行ってきました。現在、複数のEDR製品にて数十万台のホストから発生するアラートをリアルタイム(24/365)で分析し、レポートしています。

ここ数年でお客様環境でのEDRの導入事例は急増しており、SOCで分析しているお客様も右肩上がりで増えております。その中で、お客様からEDRをお客様のセキュリティ対応組織で分析しようという声も多く聞こえてきております。

しかし、EDRを使った分析を行うには様々な課題があります。そこで、今回の記事ではお客様のセキュリティ対応組織でEDRを分析する際の代表的な３つの課題を取り上げて、それぞれの課題の具体的な解説とSOCにおける取り組みを紹介します。

主な課題

• EDRからのアラートは非常に多く分析には大きな労力がかかるが、実際にインシデントが発生している確率は高くない
• EDRアラートのSeverity(危険度)は実際に起きている事象の危険度を示さないことが多く、そのまま信じてはならない
• EDRを導入しても見つけることが困難なサイバー攻撃があり、それだけではインシデント発生を見逃してしまう場合がある

課題１

EDR製品はプロセス・ファイル・レジストリ・ネットワークなどの挙動をログとして出力します。例えば、「プロセスが起動した」、「ファイルが作成された」といった挙動がログ化されますが、1ホストにて1日でおよそ10,000件以上のログ数となります(図１)。これは、1,000台のホストにEDR製品を導入している環境では、単純に計算すると1日でおよそ10,000×1000件という膨大なログ数が生成されることを意味します。

一般的にマルウェア感染の痕跡はネットワークログよりもEDRログの方が多く残されるため痕跡が見つけやすく、また感染の影響範囲などの特定もしやすいというメリットがあります。しかしながら、ログ数自体が多いため、分析には非常に時間がかかるのがデメリットの一つと言えます。

図1 ホスト1台から出力されるログ数

EDR製品は、単純なログ化だけでなく、そこからパターンマッチや機械学習によってマルウェア感染の挙動と思われるものをアラートとして生成します。表1は1か月間のインシデント発生件数、アラート数、ホスト数 、1ホストあたりのアラート数と示したものです。

この表からわかるように、アラート数と比較してインシデント発生件数は非常に少なくなります。これは、EDR製品で生成されたアラートのほとんどが、過検知であること示しています。ＳＯＣで観測される過検知の内容は、社内システムのリソース監視ツール、業務用の独自ソフトウェア、その他一般的なソフトウェアのインストール挙動などです。

もう一つの観点として、1ホストあたりのアラート数がお客様環境ごとに大きく違うという点があります。これは利用しているEDR製品やホスト環境の違いによって、大きく変動してしまうことを示しています。ユーザーにソフトウェアのインストール権限を与えている環境の場合、特にアラート数が多い傾向にあります。

表1 アラート数におけるインシデント発生件数

このように実際にEDRを導入した後に過検知を多く含んだアラートを膨大なログから分析することになるため、非常に多くの労力がかかってしまうという課題に直面します。

課題２

SOCでは、EDR製品が生成するアラートをSeverityに関係なく全てを分析対象としています。その理由は、SOCでの長年の分析において、アラートのSeverityが低いにもかかわらずマルウェア感染であった、一方で、SeverityがHighにもかかわらず、実際には社内作業であったといったことが数多く確認されてきた経緯があるためです。

図２はSOCで直近3か月間にマルウェア感染やリモート攻撃の成功などインシデントが発生した際のトリガーとなったEDRアラートのSeverityの割合を示しています。SeverityがHigh(危険度が高)のアラートは全体の50％であり、SeverityがMedium(危険度が中)のアラートは全体の21％、SeverityがLow(危険度が低)のアラートは全体の29％となっています。したがって、日々大量に発生するアラートをフィルタリングして分析対象を減らそうとする際、Severityだけで判断し、例えばLowアラートはフィルタリングするといった方法をとった場合はインシデント発生を見逃してしまうリスクが大きくなります。

図2 インシデント発生時のEDRアラートのSeverity割合

このことが象徴的に表れた事例として、アラートのSeverityがMedium（中）だったにもかかわらず、実際には標的型攻撃によるマルウェア感染だったという例を紹介します。

検知したアラートは、署名のない不審なファイル名をもつDLLが生成されたというアラートであり、普段から頻繁に検知するアラートでした。DLLのhash値は当時、外部の評価サイトでも判定されておらず未知のものでしたが、このような状況は比較的よくあるパターンであり、確認しても一般的なソフトウェアのインストール挙動であったという事例ばかりでした。しかしながら、今回の件は深く調査していくと標的型攻撃に利用されるマルウェア感染ということが判明しています。以下にEDR分析で判明したマルウェア感染フローを示します(図3)。

図3 マルウェア感染のフロー

① Downloaderを実行することで、ProgramDataフォルダに署名された正規の実行ファイル(legitimate.exe)と不審なDLL(malicious.dll)が作成(EDRはこのDLLの生成を検知)

② Downloaderがlegitimate.exeを実行することで、同じフォルダにいるmalicious.dllがロード（DLL Sideload）

③ malicious.dllによって、正規の実行ファイルのプロセスにてC&Cサーバへ通信

④ レジストリキー(HKCU\Software\Classes\Folder\shell\open\command)を利用しUAC Bypassを実行

⑤ schtasksコマンドを利用して、10分間隔で不審なDLLが実行されるようスケジュール登録

このようにEDR分析において、アラートのSeverityに頼った判断は、インシデント発生の見逃しや過検知による不要な対応をおこなってしまうという課題に直面します。

課題3

EDR製品は、主にプロセス・ファイル・レジストリ・ネットワーク挙動を監視し、ログとして出力します。しかしながら、これらすべてのログを監視し、出力すると膨大なログ数となり、製品やそれを動かしているホストへの負荷が大きくなることから、一部挙動は監視及びログ出力の対象外とされています。製品によって多少異なりますが、例えば、ファイルアクセス挙動、レジストリの一部のキー、ファイルタイプなどによって出力が抑制されいます。これ以外にも、メモリ内で実行される挙動やインタラクティブシェル上でのコマンドなどについても監視・ログ出力の対象外となっているものが多くみられます。

したがって、EDR製品では監視・ログ出力の対象外となっている部分を利用したサイバー攻撃は、検知が困難となります。具体的にどのような攻撃がEDR製品において検知困難となるのか代表的なものを列挙し、それぞれについて解説します。

・Info Stealerマルウェア

情報窃取を目的としたマルウェアは、マルウェア本体のプロセス起動、ファイルへのアクセス挙動とファイルを外部へ持ち出すネットワーク挙動がメインとなります。例えばブラウザに保存されているパスワード情報を窃取し、C＆C通信を使って外へ持ち出すといったものです。

このマルウェアの特徴はパスワードが保存されたファイルへのアクセス挙動です。しかし、上記で説明した通り、EDR製品ではこの挙動は見えないことが多く検知が困難となります。詳細については、ブログをご覧ください。

・RATマルウェア

RATには、キーロギング、画面・音声キャプチャ、ファイルの検索・閲覧・ダウンロード・アップロード、Windowsコマンドの実行などさまざまな機能があります。これら機能を利用する前のRATの感染挙動は、ホスト上でRATのプロセス起動とC＆C通信の挙動しかなく、この少ない挙動だけRATを特定し、検知することは困難となります。

また、RATの中にはこれらの機能をモジュールとして細分化し、RATのオペレーターがその機能を必要な時にだけ、C＆Cサーバからモジュールをダウンロードし、メモリ上で実行するといったものもあります。この場合もやはりEDRで見える挙動はプロセスの起動とネットワーク挙動のみであるため、検知が困難となります。

・インタラクティブシェルを使った攻撃

MetasploitやMimikatzなど攻撃者が悪性コマンド実行する際に対話型(インタラクティブ)で実行する機能をもった攻撃ツールが数多く存在しています。これらツールを利用した攻撃は、ホスト上でツールが実行されると、その後に対話型で実行されたコマンドはEDR製品ではほとんどの場合ログに残りません。したがって、上記のRATと同じようにプロセス起動とC＆C通信の挙動しか残らないため、検知が困難となります。

・脆弱性を利用した攻撃

製品の脆弱性を利用した攻撃では、攻撃者は脆弱性を利用してシェルコードを使って任意のコードを実行します。このシェルコードは、製品のプロセス内(メモリ上)で実行されるため、多くのEDR製品ではログに残らないため検知が困難となります。

念のため申し上げますと、上記攻撃全てがEDR製品で検知できないというわけではありません。EDR製品によっては、これらの攻撃手法に着目して検知できるような機能を有しているものも一部あります。

最後にEDRを導入しても見つけることが困難なサイバー攻撃として、EDR検知回避を狙った攻撃について取り上げます。これはサイバー攻撃の一連のオペレーションの中で、攻撃の特性上どうしてもEDR製品によってログとして出力される部分を正規の製品挙動などに見せかけるなど、検知されないように工夫した攻撃を指します。現在では、標的型攻撃だけでなく、ばらまき型の攻撃でも当たり前のように利用されています。以下にいくつかの例を列挙します。

EDRに検知回避テクニック

・Windows標準コマンドの多用

・Windows標準コマンドを別名にコピーして利用

・マルウェア本体のファイル名によく利用される製品のファイル名を利用

・コマンドラインの難読化

・署名されたマルウェアの利用

・正規プロセスへのInjection

・DLL Sideload(DLL Hijack)

・Process Herpaderping

EDR製品の検知回避を狙った攻撃について、具体的な事例を紹介します(図4)。

図4 EDR検知回避を狙った攻撃フロー

① docファイルを開き、マクロを有効化することでマルウェア設置サイトから2つのエンコードされたファイルをダウンロードします。

② マクロによってcopyコマンドを利用して、Microsoft Windowsの標準プログラムであるcertutil.exeを別名にコピーします。

③ マクロによってダウンロードした2つのファイルを結合し、一つのファイルを生成します。

④ コピーしたcertutil.exeを利用して、上記で結合したデータをデコードします。これがマルウェア本体です。

⑤ Microsoft Windowsの標準プログラムであるmavinject.exeを利用して、すでに起動している正規プロセスであるsvchost.exeにマルウェアをインジェクションします。

⑥ マルウェアは、インジェクションされたsvchost.exeを利用してC&C通信を行います。

上記の攻撃例では、以下のEDR検知回避テクニックが利用されています。

• マクロを利用して、エンコードされたデータをホストにダウンロード
• Microsoft Windowsの標準プログラムであるcertutil.exeをコピーして、別ファイル名で起動
• 攻撃でよく利用されるcertutil.exeのコピーに[*]を利用して、コピー対象ファイル名を隠蔽
• Microsoft Windowsの標準プログラムであるmavinject.exeを利用して、正規プロセスにインジェクション

このように実際にEDRをただ導入するだけでは、検知回避などを狙ったサイバー攻撃によるインシデント発生を見逃してしまうという課題に直面します。

SOCにおける取り組み

これまでEDR分析における課題を3つ紹介してきましたが、ここではこれら課題に対してSOCではどのような取り組みを行っているか紹介します。

・自動分析ツール

アラートを分析し、それがインシデント発生を示すものなのか、それともお客様の作業や正規ソフトウェアのインストール挙動なのか判断するには、アラートに関連した情報を膨大なログから検索し、分析していく必要があります。

たとえば、アラートが不審なファイル作成であった場合は、ファイル情報(ファイル名、パス情報、hash値など)を確認し、さらに関連情報としてファイルを作成したプロセス情報、そのプロセスを呼んだ親プロセス情報などを取得し、不審な点がないかを総合的に判断していきます。

一部EDR製品ではこれら情報を自動で抽出してグラフィカルに情報を表示してくれる機能がありますが、そこでは足りない情報なども含めてSOCアナリストが必要な情報を表示してくれるツールを独自に開発し、利用することで分析の効率化アップを図っています。

・アラートのフィルタリング

SOCでは、アラート情報をAPIで取得していますが、1回のAPIクエリではアラートに関する情報を十分に取得できません。そこで、1アラートに対して関連する情報を得るために複数回のAPIクエリを実行し、アラートに関する情報をできるだけ詳細に取得しています。これら情報を利用して作業などで発生するアラートをSeverityに頼らずにフィルタリングすることで、見るべきアラートと見る価値のないアラートを選別しています。具体的には、不審なプロセス起動に関するアラートであれば、プロセス名、パス、コマンドライン、親プロセス、子プロセス、コード署名の有無などを使って、フィルタリングしています。

・カスタムシグネチャ

SOCでは国内外の多くのお客様が利用しているセキュリティ機器からログを収集し、分析を行っております。また、それとは別に独自のサンドボックスを利用しサイバー攻撃の情報を集めています。これら情報からカスタムシグネチャを作成することで、EDR製品独自のIOCでは検知できない攻撃を検知することが可能になります。詳細はブログをご覧ください。

・ネットワークログ

SOCでは、エンドポイントだけでなくネットワークのログも分析に活用しています。ProxyログやIPS/IDSのアラートを活用することで、上記で紹介したようなEDR製品の仕様により検知困難な攻撃を検知することが可能になります。

・EDR SIEM

EDRでは、基本的に一つの挙動、例えばファイル作成、プロセスの起動といったものに対して、IOCでマッチングさせアラートをあげます。しかしながら、サイバー攻撃の巧妙化により、このような一つの挙動だけでサイバー攻撃を検知することは日々難しくなっています。そこで、SOCでは監査系のログも集めて、EDRで検知したアラートと組み合わせてSIEMルールを作成し、検知困難なサイバー攻撃を検知させることを実現しています。

この他にもサンドボックス環境にEDRエージェントを導入し、どのようなログが出力されるかを調査し、それらログを使ったトレーニングやナレッジの蓄積、EDR製品ごとの独自の分析ノウハウなどをまとめて、アナリスト間で共有するなど分析に関する様々な取り組みを行っております。SOCでは、高度化するサイバー攻撃からお客様環境を守るために、今回紹介したような取り組みを考え、また改善していくことで精度の高い脅威特定を実現しています。