こんにちは。
コーポレートエンジニアの宮崎です。
弊社ではSOC機能を自社で運用しており、EDR製品として Microsoft Defender for Endpoint(以降MDE) を導入してから約2年が経過しました。
今回は、2025年5月時点の弊社なりのインシデント対応の流れや考慮ポイントをご紹介いたします。 MDEを導入している方、導入を検討されている方のご参考になれば幸いです。
前提
スコープ
インシデント対応において必要なことは多岐にわたりますが、今回においてはMDEを利用した対応のみをスコープとします。
環境
Microsoft Defender for Endpoint P2 ライセンスを利用しています。
また、Microsoft Sentinel等のSIEM/SOAR製品は導入検討中です。
検出と通知
MDEでは端末のインシデントを自動で検知してくれます。
検知したインシデントの通知方法は、MDE単体では「メール通知のみ」です。
※メール通知の詳細な設定方法は公式ドキュメントをご参照ください。
インシデント発生時には、いかに早く影響を止められるかがまずは一番重要になるので、インシデント対応者がすぐに気付けることが重要です。
そこで、弊社ではZapier(iPaaS)を併用してSlackの専用チャンネルにインシデントを通知しています。
暫定対応
インシデントを検知した際の、「被害の最小化」を主目的として急ぎ対応していることを下記にてご紹介します。
インシデントの評価
対象のインシデントがざっくり「どれくらい危ないのか」を確認します。
ただし、この段階であまり時間を使ってしまうと、攻撃の実行時間を引き延ばしてしまい「被害の最小化」の目的から外れてしまいます。
そのため、下記の分類のみ行うのが良いかと考えています。
- 影響がない可能性が非常に高い：誤検知やMDEにより完全にブロックされている等
- 影響がありそう：上記以外のすべて
こちらの要件は、各社の考え方により大きく変わってくるので会社ごとに条件や判定基準を予め策定するのが望ましいと考えます。
また、評価にはMDEで教えてくれる下記情報が役立ちます。
- インシデント及び関連するアラートの「重要度(Severity)」ステータス
- 関連するアラートの「アラートの説明」と「状態」
- 「証拠と対応」タブでの疑わしいプロセスやIPアドレス・ファイル等の一覧とMDEでの修復状態のステータス
ネットワークからの分離
影響がありそうだと判定した場合は、対象の端末をすぐにネットワークから分離することが望ましいです。ネットワークから分離することにより、以降の情報の流出を防ぐことが出来ます。
この時、端末をシャットダウンしてしまうと攻撃者が証拠隠滅の動作を行う可能性や詳細調査に役立つメモリイメージ等の揮発性データが失われてしまう可能性があるため、あくまでネットワークから分離する対応が望ましいです。
「被害の最小化」において本項目が最重要ポイントです。迅速かつ対応の平準化のためインシデント発生時のネットワーク分離対応は予め条件やフローを定め、会社(経営層)と合意を取っておくのが良いと思います。
また、ネットワークからの分離はMDEの「デバイスの分離」機能が便利です。
MDEの対象デバイスの画面から、デバイスをネットワークから分離できます。
本機能で分離を行った場合、端末とMDEとの通信は維持されます。
弊社が確認している動作では、「デバイスの分離」を行うとネットワーク接続はもちろん外付け記憶媒体の接続もできなくなります。そのため、分離中に端末からデータを抜き出すことは難しいことを留意しておく必要があります。
※「デバイスの分離」機能の詳細は公式ドキュメントをご参照ください。
揮発性データの抽出
次項でご説明する詳細調査・分析のために、インシデント発生時の状態(攻撃の状況を含む)のログを出来るだけリアルタイムに近い状態で保存します。
特に下記のような、端末のシャットダウンや時間経過で失われてしまう揮発性のデータを抽出・保存します。
- 実行中のプロセス
- ネットワークの接続状況
- メモリイメージ
- etc…
MDEの「調査パッケージの収集」機能では揮発性データを含め様々なデータをパッケージとして収集してくれます。
上述したように、様々なデータが収集されていることが分かるかと思います。しかし、「メモリイメージ」をそのまま提供してくれるわけではありません。
弊社において「メモリイメージで分かる内容」が「調査パッケージで収集されるデータ」で完全に補完できることをまだ確認できていないです。(有識者の方、是非分かればご教示お願いします)
また、外部のフォレンジック調査を依頼した際に業者からメモリイメージの提供を要請される可能性があるため、念には念を、メモリイメージも保管することにします。
詳細調査・分析
暫定対応にてインシデントの影響を止めたら、落ち着いて何が起きたか・どんな影響がありそうかを調査します。
1.アラートの内容を把握する
前項でご説明した「インシデントの評価」の際に既にある程度は把握できていると思いますが、もう少しだけ詳細に、発生したインシデントのアウトラインを確認していきます。
アラートの内容把握では、基本的にインシデントに関連する各アラートの「アラートのストーリー」の「プロセス ツリー」をメインに確認していきます。下記は、弊社環境で発生した誤検知のアラートの「プロセス ツリー」です。
視覚的に分かりやすく、関係のあるプロセスの実行順序と時系列を表示してくれます。
この時に、OS標準のプロセスが表示されることが多く、プロセスそのものが悪意のあるものではない可能性も高いです。そのため、プロセスツリーの確認時には各プロセスの下記の詳細情報を併せて確認し、そのプロセスを通じて何が行われたかを意識して確認します。
- コマンドライン
- MDEが行った対応内容と状態
- ファイルの署名者
- 対合計検出率(VirusTotalでの検出)
- etc…
2.タイムラインを一つ一つ根気強く確認していく
MDEは強力なツールで信頼性も非常に高いと考えています。しかしEDRの特性上、悪意のあるアクティビティを漏れなく完璧に検出される保証はございません。
漏れなく発生したことを正確に把握するために、インシデント発生前後の端末のタイムラインを一つ一つ根気強く確認します。この時事前に、対象端末の所有者にインシデント発生前後に行った内容とその時間をヒアリングしておくことをお勧めします。確認する必要があるログの起点と終点を見つけやすくなります。
参考画像ではログの内容を白塗りさせていただいたので分かりづらくなってしまっていますが、出力されているログが一般的な(問題のない)動作なのか、疑わしい動作なのかパッとは判断がつかないです。タイムラインで表示される内容の理解に、OSや導入しているシステム等の環境での振る舞いに対する深い理解が必要だからです。私はお恥ずかしながらそこまでの理解を現状持ち合わせていないので、インシデント発生時にはログの内容の分からないところを一つ一つ調べていく必要があります。(結構根気のいる作業です。)
本ブログでは詳細には言及しませんが、タイムラインの確認と並行して、下記の対応を行うと調査・分析から会社への報告までスムーズに行えると思います。
- 端末のイベントログやネットワーク関連のログ等を含めた相関分析
- 正確な時間を含めたインシデントに関連するログのメモ
3.便利な機能
調査・分析に役立つMDEの機能をご紹介します。
ライブ応答セッション
ライブ応答セッションでは、MDE管理画面から端末にリモートシェル接続を行い、サポートされるコマンドを実行することが出来ます。
※実行できるコマンドの一覧は公式ドキュメントをご参照ください。
個人的には特に「getfile」コマンドが便利だなと思っています。タイムライン確認時に、疑わしいファイルを見つけた際に、対象のファイルをダウンロードし解析することが出来るからです。(攻撃者がすでに削除してしまいダウンロードできない可能性もありますが、、、)
感染リスクがあるため、「getfile」コマンドの実行は会社環境から隔離されたデバイスで実行することを強くお勧めします。
高度な追及(Advanced Hunting)
高度な追及では、MDEに保存されているログを、Kusto 照会言語 (KQL)という言語を利用してクエリを実行することが可能です。
※高度な追及がサポートされているログは、30日前までのログです。
※その他高度な追及の概要や、クエリの書き方は公式ドキュメントをご参照ください。
高度な追及を利用することで、様々な調査を素早く実行することが可能です。例えば下記のようなケースが考えられます。
- 特定の端末で発見された疑わしいプロセスのログを一覧表示したい
- ログが問題ないものなのか、疑わしいものなのか判断するために他の端末で同様の挙動がないか確認する
おわりに
以上、MDEのインシデント対応における現時点での対応方法をご紹介させていただきました。 いかがでしたでしょうか。
今後は本ブログにおける検知→暫定対応の自動化や相関分析のスピード向上を目指し、SIEM・SOAR製品(おそらくSentinel)を検証していきたいと考えてます。
また、アップデートがあればブログにてご紹介できればと思います。
