株式会社ココナラの情報システムグループ CSIRTチームのテトロドナです。
本記事では、EDRはどのようにして敵対的な行動を見つけるのかを解説していきます。

はじめに

EDRとは、EDRはEndpoint Detection and Responseの頭文字をとった語で、従来の（とはいってもEDRの概念が初めて世に出たのがすでに結構前の話ではありますが）アンチウイルスソフトウェアと異なり、各エンドポイントの詳細なログを収集・分析することで、脅威が侵入した際の被害拡大を防ぐセキュリティソリューションの総称です。

従来のセキュリティ製品との違いとしては、既知のマルウェアのシグネチャや挙動パターンをもとに検知するような静的な動作のみではなく、任意のエンドポイントにあるプロセスがどのような動きをしているのかを、機械学習や振る舞い分析を取り入れ、未知のマルウェアも含めた包括的な悪意のある行動への対策を主眼に据え置いたセキュリティソフトウェアです。

では、具体的にはEDRはどのように敵対行動を検知しているのでしょうか？

EDRの構成要素

以下の説明は一般的な概念としてのEDRの説明を行なっており、特定の製品を指しているものではないことをご了承ください。
まずはEDRの全体像から説明します。

EDRはざっくりと

• センサー
• テレメトリ
• 検知
• エージェント

の４つの構造から成り立っています。

センサー

文字通り、対象物を検知する役割を担う部分です。具体的には

• 内部プロセスを通過するデータを傍受
• 必要な情報を抽出
• 中央のエージェントに転送

などを行います。
EDRが動作する上での判断材料になりますので、センサーはシステムプロセスの流れを直接監視する必要があります。
そのため、各システムプロセスの動作を妨害しないように、実装の際には動作速度が重要視されます。

例えば、Windowsで動作させるにしても監視対象になりうる値や動作は数多く存在しますが、EDRはそれらすべてを使用するわけではありません。
十分な精度や情報量を提供できない値である、ホストの環境との関連性が低く、必ずしも脅威検知に直接役立つとは限らない、技術的にアクセスしづらいなどの理由により、一部の情報に焦点を絞って活用されています。
具体的には、WindowsのイベントログやEDRが独自に導入する動作・値・プロセス（ドライバや関数フックDLL）等を監視対象としています。

テレメトリ

EDRのセンサーは、値（テレメトリ）の収集を目的に設計されています。
テレメトリはセンサや各エンドポイントのホストによって生成されるデータであり、防御側がこれを解析することで悪意のある活動が発生したかどうかを判断します。
システム上のすべてのアクション（ファイルのオープン、新しいプロセスの作成など）は、何らかのテレメトリを生成します。
センサー同様、脅威の判定に利用されることになりますので、EDRに入力されるテレメトリはできる限り完全でなくてはなりません。

検知

EDRは収集したテレメトリを検知ロジックに渡します。
これは、読んで字の如くテレメトリの個別データとシステム上で実行された動作を関連付けるロジックやアルゴリズムのことを指し、単純な条件をチェックするものから、複数のデータソースからの複雑なイベントシーケンスを評価するものまで、さまざまな形式があります。

エージェント

センサーからデータを管理・収集、それをもとに分析を行い、一連のイベントが攻撃者の行動パターンに一致するかどうかを判断する部分です。

その後、テレメトリ（収集したデータ）をメインサーバーに送信します。このメインサーバーでは、環境内に展開されたすべてのエージェントから送られたイベントをさらに解析し、結果に応じてアラートの発出や動作のブロックなどを行います。
おおむね、アラートを出すために動いている部分と考えて良いかと思います。

どのように悪意ある行為を特定するのか？

単純に新しいプロセスが作成された場合、攻撃者がマルウェアを永続化するためにサービスをインストールした可能性がある一方、多くの場合はユーザーが正当な理由で新しいソフトウェアをインストールしただけである可能性が非常に高いでしょう。
しかしインストールイベントがあったのが真夜中だったとしたらどうでしょうか？

少し怪しくなりましたが、ユーザーが大きなプロジェクトで夜遅くまで作業している可能性もあれば、単純に気まぐれでそのタイミングで作業を行っただけの可能性も考えられます。
では、rundll32.exeによってサービスがインストールされた場合は？
かなり疑わしいですが、ソフトウェアのインストーラが不適切に実装されているだけかもしれません。

このように、特定のイベントからその意図を推測することは非常に難しく、一見不審に見えるアクティビティであっても、必ずしも悪意を持ったものとは限りません。
単一のデータポイントやイベントに基づいて判断するのではなく、複数のデータを関連付け、任意のアクティビティからの連続的な動作をまとめて理解する必要があります。
仮に、深夜4時にアプリケーションがインストールされたのを確認したとしても、監視対象のPCのIPがニューヨークであった場合、これは時差のために問題のないインストールと言えるでしょう。
しかしながら、このアプリケーションが事前に周知されているC＆Cサーバと通信を開始した場合、これは間違いなく黒です。
この判断をEDRは行っています。ゆえに、「Threat Detection(脅威検出)なのです」

注意するべき点として、インストールから通信の開始までの間には怪しいイベントからそうでないものまで、グラデーションでイベントが発生しています。

インストールのために特定の署名のないdllファイルをロードしているかもしれませんし、疎通確認のために定期的にポーリングを行うかもしれません。
何か重大な問題が発生していない限り、システム上のアクティビティの大半は無害と言えますし、これはEDRの検出感度をどの程度に設定するべきかを、それぞれの組織が許容できる範囲に収まっているかどうかは（製品によるかもしれませんが）組織で判断する必要があります。

もう少し深入りすると、前述の通りEDRは既知のマルウェアに一般的に関連付けられるシンプルな文字列やハッシュベースのシグネチャなどにより行動を検出する機能と、環境に適した機械学習モデルによって行動を検出する機能を併せ持ちます。
例えば、悪意のあるファイルのハッシュに基づいた検出は、そのファイルの特定のバージョンを効果的に検出できますし、仕組みもシンプルで分かりやすいという長所があります。

しかし、ファイルにわずかな変更が加えられるとハッシュが変わり、検出ができなくなります。
仮にmalware.exeというファイル名を検出するルールがある場合、攻撃者は単にファイル名をsoftware.exeに変更することで検知を回避できます。
このため、シグネチャによる検知は、変更不可能または変更が困難な属性を対象とする必要があります。

一方、機械学習モデル等によってサポートされるルールセットは、特定の動作やシグネチャによる検知だけではなく、非定型的な挙動を検知できる可能性があります。
しかし、一般的と想定される環境ではない場合など、検知ロジックが重要視した属性を重点的に監視するため、個々の状況に合わせて調整された通常とは異なる挙動や仕様を持つファイルを疑わしいものとして処理する可能性もあります。

また、機械学習等による検知ルールはその複雑さゆえに開発や調整がはるかに困難で、フォールスポジティブとフォールスネガティブのバランスが崩れると、検知を失敗することもあります。

このため、 EDR は両方のアプローチを採用しており、明白な脅威を検出するためにシグネチャを使用し、攻撃者の技術をより一般的に検出するために振る舞いによる検知を使用します。
ちなみに、EDRベンダーの中で、検知ルールを公開している数少ない企業の1つがElasticです。
同社はSIEMルールをGitHubリポジトリで公開しています。

他にも具体的な行動の検知方法としては、コードフックを使用しています。

Win32 APIを使用してホスト上で特定の機能を実行しようとする場合、ざっくりと「アプリ → Win32 API → ntdll.dll（syscall）→ カーネル」という流れになっており、悪意のある行動を検出するために、EDRはこのどこかにフックをかけることで動きをチェックしています。
ntdll.dll内のsyscallを実行する関数は、ユーザーモードでAPI呼び出しを監視できる最後のポイントであるため、EDRはこれらの関数をフックしてその呼び出しや実行を検査することがよくあります。

具体的にはNtOpenProcess関数やNtCreateSection関数などです。

これらのAPIへの呼び出しを強制的に自身の用意した関数へ移動させる処理を挟み込んだり、処理を傍受することで、EDRは元の関数に渡されたパラメータや、APIを呼び出したコードに返された値を観察することができます。
エージェントはこのデータを調査し、活動が悪意のあるものであったかどうかを判断することができます。

あるいは、イベントやプロセスから疑わしい行動を検出することもあります。
たとえば、Microsoft Word が powershell.exe を子プロセスとして生成した場合などは、まず悪意のある行動と見て良いでしょう。

EDRの回避

Jonathan Johnsonは「Evadere Classifications」でEDRの回避方法の分類を行っています。
詳細な解説は割愛しますが、EDRによる監視を掻い潜るには、どのような手段が考えられるでしょうか？

正攻法としてセンサーのギャップ（ルールの設定ミスなど）を悪用して、EDRがアラートを生成したり防御的な行動を取る閾値を下回るように活動しようとするでしょう。
深刻な侵害行為と見なされるようなことは行わず、正規のプロセスを悪用し、少しずつ疑わしい行動を重ねていくものの、尻尾を掴ませるような行動は取らない、といった方針が考えられます。

エクスプロイトツールを実行し、検出されることを承知の上で攻撃を仕掛けてくるかもしれません。
アラートの発生後、迅速に行動し、対応を上回るスピードで進めるか、防御者が効果のない対応で時間を浪費するようにするかもしれません。攻撃が露見しても問題ないと割り切り、必要であれば再度やり直すのです。

あるいは、ツールの実行を一定期間待つかもしれません。エージェントは特定の時間枠内で発生するイベントのみを関連づけて監視するため、警戒が初期化されリスクがゼロにリセットされるまで待機し、その後作戦を再開するという手も考えられます。

確かにEDRは便利な道具ですが、完璧ではないのです。

まとめ

今回の記事では、EDR製品がどのように動作するのか、その概要を解説しました。
こうしたメカニズムを把握しておくことで、いつか何かの役に立つことがあれば幸いです。
最後までお読みいただきありがとうございました。

さいごに

ココナラに興味をもっていただいた方やもっと詳細に話を聞いてみたい方がいましたら、以下よりご連絡ください。

ブログの内容への感想、カジュアルにココナラの技術組織の話をしてみたい方はこちら
　https://open.talentio.com/r/1/c/coconala/pages/70417

エンジニアの募集職種一覧はこちら
　https://coconala.co.jp/recruit/engineer