Incident Response において実施すべき調査（EDR vs Forensic State Analysis）

17 min readNov 11, 2020

私はとある企業で Incident Response サービスを提供しています。その中で、安全宣言発出のサポートを行うため、お客様が導入している EDR 製品のログを使って分析を行うことがあります。複数の EDR 製品のログを分析してきた経験から得た、 私が考える Incdient Response における網羅的調査のあるべき論を紹介します。

EDR はビジネス的思惑が強く働いており、過大評価されている側面があり、 EDR の有用性について本音で語られていないのではないでしょうか。そういったビジネス的側面を排除しフラットに語るため、個人ブログに記したいと思います。あくまで個人的見解であり、所属企業とは無関係ですし、特定のセキュリティ企業や製品を批判する意図はまったくありません。純粋に、世の中をより良くしたい、日本の産業を守りたいという想いのみで書いています。間違っている、議論の余地がある部分も多くあるかもしれません。その際はぜひコメントいただければと思います。

要約

EDR を使った調査は Behavior Analysis という調査手法になります。これは、MITRE ATT&CK などをベースに定義した不審な挙動や Anormaly な挙動を捉えるための分析です。一方、Compromise Assessment と呼ばれる調査は、一般に Forensic State Analysis(FSA) という調査手法を採用します。これは NW 内の全システムの「状態」を調査し、マルウェアに感染している（していた）状態かどうかを捉えるための分析です。

Behavior Analysis では潜んでいる(= C2 Beacon のみで不審な活動をしていない) RAT を捉えるのは困難です。一方で、FSA は「状態」に着目するため、潜んでいる RAT でも捉えやすいといえます。

そのため、インシデントレスポンスにおいて安全宣言を出すためには、両者を並行して実施する必要があります。EDR の調査を行うだけでは安全宣言を出すまでに至らないということに注意が必要です。

背景

Incident Response で実施すべきことは、1. 侵入経路の特定、2. 感染拡大状況の特定、3. 情報漏洩の特定の3つが基本かと考えます。そのうちの 1,2 は「安全宣言」を行うために非常に重要な作業になります。

最初の侵入経路を特定し根本原因に対策を打つ
感染拡大状況を特定し、その範囲に攻撃者が設置した新たな侵入口(downloader, stager, RAT など) のすべてを排除する

このうち「1. 最初の侵入経路の特定」は明らかにならないケースが多いといえます。多くの標的型攻撃事案では、侵入から数ヶ月後にようやく検知できるのが現状であり、対応を始めた時には有効なログが失われていることが多いためです。また、脆弱性攻撃で侵入したとしても、以降は別途設置した RAT などを使用するため、侵入経路の利用痕跡がわずかであるということもあります。（脆弱性は、パッチを適用されれば使用できなくなるため、RAT などにより新たな侵入口を作成することが通常です）

しかし、すべての公開サーバのパッチを見直す、webサーバにwebshellが設置されていないか確認する、リモートアクセスサーバのパスワードを変更しパスワードポリシーを強固にする、Cloud Hopper の類の攻撃を考慮して協力会社・委託ベンダからのアクセス経路を見直す、などの対応を行うことで、侵入経路の排除が期待できます。

一方で、「2. 感染拡大状況を特定し、攻撃者が作成した侵入口をすべて駆除する」は非常に厄介です。公開サーバのみならず、あらゆるシステムをすべて調査する必要があるため、いかに確実に効率的に調査を行うかが鍵となります。

では、このミッションを実施するにはどうすべきでしょうか。特に、NW 内の端末台数が数千〜数万台ある大規模 NW が侵害された場合、集中管理された方法で網羅的に調査を行う必要があります。この網羅的調査について、2大手法とそれぞれのメリット／デメリットをまとめることが今回のテーマになります。

網羅的調査の2大手法

この記事を読んでいる方であれば言うまでもないと思いますが、近年の洗練された攻撃は Network Analysis ですべての RAT を特定することは極めて困難です。RAT の特定にはエンドポイントの調査が必要ですが、その調査手法として2種類の手法があることはあまり意識されていません。それは、Behavior Anlaysis と Forensic State Analysis(FSA) です。

以降では、それぞれの調査手法について特徴をまとめていきます。結論からいいますと、それぞれが補完関係にありますが、RAT の特定という目的においては、FSA をより重視すべきと考えます。

Behavior Analysis (EDR) による網羅的調査

Behavior Analysis では、EDR製品などが記録した「挙動」ログを精査し、侵害と思われる挙動の有無を調査します。ここで、「挙動」ログとはどんなものなのか、また、「侵害と思われる挙動」とは、どんなものなのか例を挙げて紹介します。

挙動ログの例

EDRでは一般的に次のような挙動ログを取得しています。

プロセス生成ログ

プロセスに対応するイメージファイル
イメージファイルの署名、ハッシュ値などの属性情報
プロセスの親プロセス
プロセスID
プロセスを起動したユーザ名

ファイル操作ログ

生成、修正、削除されたファイル名とハッシュ値
ファイルを操作したプロセス情報

レジストリ操作ログ

生成、修正、削除されたレジストリ名
レジストリを操作したプロセス情報

ネットワークログ

コネクションを生成したプロセス情報
コネクション先IPアドレス、ポート番号
通信サイズ

これらは多くの製品で共通して取得されていますが、製品によってその深さが異なります。例えば、イメージファイルの属性情報では、internal name や compiled time などを取得している製品もあります。また、製品によって次のような発展的ログを取得している場合もあります。

LoadLibrary や CreateRemoteThread などのインジェクション関連 API
FindFirst などのディレクトリ列挙系 API など
サービス登録ログやスケジュールタスク登録ログ
DLL ローディング
Token Impersonate 情報

これらのログの中には不審な挙動を定義する上で非常に重要な役割を果たすものがあり、どのような発展的ログを取得しているかは製品選定の基準にすべきかと思います。

「侵害と思われる挙動」の例

一般に MITRE ATT&CK に記載がある Technique から定義します。例えば、

certutil.exe を使ってインターネットからバイナリをダウンロードする
msiexec.exe を使ってインターネット上のバイナリを実行する
regsrv32.exe を使ったスクリプトの実行(Squiblydoo)
cmstp.exe を使った UAC bypass
wdigest の有効化(レジストリ操作)

など様々な挙動が考えられます。

また、次のような挙動も不審な挙動として定義できますが、正規挙動も多くひっかかります。そのため、統計的 anormaly や他のイベントとの相関分析で悪性判定する必要があります。多くの EDR 製品の管理コンソールにはこのような機能がないため、SIEM が必要な場合もあります。

net user <username> <password> /add
net group <groupname> <username> /add
rundll32.exe による DLL の実行
WMI を使ったリモートコード実行
サービスの登録やスケジュールタスクの登録などのPersistence
svchost.exe が cmd.exe や powershell.exe を起動
rundll32.exe が不自然なプロセスを起動

当然攻撃者は、このような正規挙動とも攻撃とも取れる挙動を利用してきます。

注意すべき EDR 製品の制限事項

取得しているログの例を見る限り、十分なログが取得されており、あらゆる侵害を特定することができるように思うかもしれません。しかしそんなに単純な話ではありません。私が経験した EDR の制限事項を紹介します。

①ログとして取得する挙動は、一部に制限されている。例えば・・・

レジストリ操作は、対象レジストリキー・バリュー情報は取得しているが、設定したデータは記録しない
レジストリ操作のロギング対象はかなり絞られている
ファイル操作では、.txt や .zip などの拡張子を持つものは除外されている
長いコマンドラインは、先頭から数百文字のみ記録される

②一部の EDR 製品では、RDP のユーザ名などが明示的に記録されておらず、svchost.exe -termsvcs とその直後に生成された explorer.exe の起動ユーザ名などから推測する必要がある。そのため、効率的な検索ができない

③イベントログに相当する、よりハイレベルな情報が記録されていない。多くの Hunting はイベントログ(ETW)に依存している。

④そもそも、ログ取得が安定しておらず、取りこぼしが多い

⑤バグが多い。ひどいものでは、15–20%のプロセスの親子関係の紐付けがずれている製品に遭遇した

⑥ログの保存期間が非常に短い

生ログは1週間程度で、アラートログは1ヶ月、など
アラートログだけ見ても前後の挙動を示す生ログがないため、背後にある脅威を特定できない

課題

前述した制限事項とは別に、Behavior Analysis というコンセプトには次のような課題があります。

①攻撃者が活動しなければ不審な挙動が発生しないため、RAT の存在に気付くことができない。特別監視体制が解除されたであろうタイミングで再度活動を開始する

②大規模な環境になればなるほど、EDR を導入できないシステムやシャドウ IT が存在する。攻撃者はそのような EDR 監視対象外を起点に不正行為を行う傾向がある

③攻撃者にとって正規挙動に紛れ込むのはそこまで難しくない。特に、アノーマリ分析を行っていない場合は、比較的容易である。例えば・・・

RDP で他のホストにログインすること自体は正規挙動に見える
RDP 先で、Powershell console を起動することも正規挙動に見える
Powershell console で様々なモジュールを import して実行することも正規挙動に見えるし、どのようなモジュールを import したかは EDR の挙動ログでは特定困難（イベントログが必要）
Domain Controller への攻撃や、RDP Sweep, Remote WMI, Powershell Remoting なども意外と検知しない。検知していたとしても誤検知が多く対応が困難

④挙動そのものを隠すことができる。例えば・・・

あらゆる行為を Win32 API 経由でメモリ内で実行させることが可能(cmd.exe を子プロセスとして立ち上げることなく、cmd.exe コマンドラインを実行できる、など）
プロセスの親子関係は、攻撃者が任意に設定することができる。これは多くの Behavior Analysis がプロセスの親子関係のアノーマリに依存しているため、大きな問題である

⑤ログの保存期間の制限、ログの取りこぼし、ログ取得対象制限のため、調査できない項目がある。例えば・・・

レジストリの設定内容が記録されないため、Persistence の設定挙動の網羅的な調査ができない
初期侵入がログの保存期間より前に始まっていた

課題①に記載の通り、安全宣言のための RAT の特定という観点では適した調査手法ではないと考えます。

Forensic State Analysis(FSA) による網羅的調査

FSA は端末の「状態」を精査し、「侵害されたと思われる状態」の有無を調査します。ここで「状態」とはどんなものなのか、また、「侵害されたと思われる状態」とはどんなものなのか、例を挙げて紹介します。

「状態」の例

FSAでは次のような「状態」を収集し調査を行います。

自動起動設定（永続化、persistence とも呼ばれる）
インシデント発生期間に生成された実行ファイルとその設置場所などの特徴
すべてのアクティブなプロセス情報
すべてのロードされたモジュールとドライバ
メモリにインジェクトされたモジュール情報
API Hook などのプロセス操作
無効化（弱体化）されたセキュリティ設定（AVの停止、Wdigestの有効化、NLAの無効化、sethc.exe の置換など）
プログラム実行痕跡（Prefetch, Shimcache, UserAssist）
不審なプログラムの生成（Webshell, 情報収集ツールなど）
ログオン履歴(RDP, Network Logon のタイミングや使用されたドメイン名／ユーザ名)
Powershell 履歴(Powershell Script Block Logging
ネットワークコネクションの状態

また、情報収集ツールによっては、次のような発展的な状態情報を取得します。

handle 情報(file handle, named pipe, event)
Token の Impersonate 状況
mutex
実行ファイルの IAT 情報

これらのデータは、海外では Forensic Triage／Triage Anlaysis、日本ではファストフォレンジックと呼ばれる調査を行うために収集されるデータとほぼ同等です。 FSA の大きな違いは、Enterprise レベルで数千〜数万台を同時に調査を行うところにあります。そのため FSA においては、これらのデータを一つ一つ入念に見るわけではなく、anormaly detection などの統計的調査をベースとした調査が行われます。

「侵害されたと思われる状態」の例

「侵害されたと思われる状態」の例を紹介します。

ネットワーク全体で見た時に、世の中に出回っていない、かつ対象 NW 内でもレアなプログラムが自動起動設定されている
VMware, DELL, HP などを模したファイル名だが、当該企業の署名のないプログラムが自動起動設定されている
通常存在するディレクトリとは異なる場所に設置された DLL が自動起動設定（または、自動起動設定されたプログラムにロード）されている
プロセスの親子関係の異常
メモリに含まれる不審な文字列（meterpreter, cobaltstrike の config や mimikatz の典型的な文字列など）
レアな named pipe 名
特定のディレクトリに複数設置されたバイナリが実行された痕跡がある、かつ、すでに削除されている
特定のシステムでのみロードされている DLL
無害化・弱体化されたセキュリティ設定
レアなドメイン名を使用してログインされた痕跡（ドメイン名が a など）
Powershell の Script Block Logging に含まれる不審な文字列
一般システムで高権限ユーザに Impersonate された Token が存在する
イベントログが削除された状態である

多くの項目に「異常な」、「レアな」、「通常とは異なる」といったキーワードが入っています。もちろん、それだけでは正規挙動も多くヒットするため、様々な要素を組み合わせ相関的に分析します。

悪性プログラムが動く以上、「挙動」は隠せても、潜んでいるという「状態」を隠すことは困難です。特に RAT のような新たな侵入口作成を目的とする場合、自動起動設定（Persistence）は必須です。当然、攻撃者も DLL Order Hijack などの見つけにくい自動起動設定を使用しますが、FSA による「不審な状態」を複数組み合わせれば、隠しきるのは難しいといえます。

制限事項・課題

FSA にも考慮すべき制限事項があります。

あくまで「状態」であるため、その瞬間の情報しか調査できない。その瞬間 RAT がいなくてもその後すぐに RAT が仕掛けられる可能性がある。そのため、封じ込めをしっかりと行っていることが前提となる
Realtime Monitoring を前提としていないため、Agent が常駐しているわけではない。インシデント発生の都度、NW 全体にツールをばらまいて実行する必要がある
ツール実行時に、高権限アカウントが必要だが、高権限アカウントを保護しながら全システムでツールを実行するには Windows セキュリティの知識が必要
漏れなく NW 内の全システムで情報収集ツールを実行するのが困難な場合がある。これは EDR でも言えることだが、シャドウ IT が問題となることがある
「挙動」ログではないため、過去に何が行われたか、については比較的「歯抜け」になりやすい。ただし、EDR ログの保存期間が短いため、EDR ログより過去の情報が残っていることは期待できる。（イベントログなどは1年以上前のデータが残っていることもあるし、ファイルのタイムスタンプは、MFT のエントリが存在する限り残る）
アンチフォレンジックテクニックを利用されている場合、検知が困難な場合がある

EDR vs FSA まとめ

これまで説明した通り、EDR (挙動ログ) は不審な動きを捉えるカメラのようなものであり、ログとして一定期間保存することができます。一度不審な挙動が見つかれば、ログをトレースすることで RAT を特定することができるかもしれません。ただし、制限事項や課題で述べた通り、すべての RAT の特定という観点ではうまくいかないケースが多いのが実情です。

一方で、FSA (状態) は、システムの健康診断のようなものであり、不審な挙動がなくても不審な内部状態を捉えることができます。RAT が動いている、RAT が自動起動設定を施しているという状態は隠すことが難しいため、FSA は RATの特定に向いているといえます。ただし、ツール実行時の状態に着目しているため、過去に何が起きたのかをトレースという点では物足りなさがあります。

安全宣言を発出するためには、環境内に新たな侵入口ができていないことを担保する必要があります。そのためには FSA が必要です。一方で、何が行われたのかをトレースするには EDR が向いています。つまり、これらは補完関係にあるといえます。

最後に、もし EDR が入っていない環境でインシデントが発生し安全宣言を急ぎ発出する必要がある場合、EDR を慌てて導入するより FSA を実施する方が優先度が高いと私は考えます。なぜなら、安全宣言を行うためには、再侵入される可能性を最小化することが重要だからです。

以上、EDR(Behavior Analysis) と Forensic State Analysis の違いについて説明しました。あくまで私の経験を通して感じた私見であり、様々な意見があるのは承知しています。ただ、何でもかんでも EDR、インシデントが発生したら EDR、という風潮が少なからず世の中にあるように感じるため、本当にそうでしょうか？もっと適切な、より優先度の高いやるべきことがあるのではないでしょうか？というメッセージを伝えたく本記事を書きました。少しでも世の中のセキュリティに携わる方の考えるきっかけになれば幸いです。