私は定期的に、お客様から「Cybereason Defense Platformで、特定の手法によりMalop™が生成されない理由」に関して説明を求められます。このような質問があるということは、セキュリティ業界全体において、今でもなおEDRの性質について多くの教育が必要であることを示しています。

これは、判断を伴わない事実の表明です。私の同僚のアナリストの多くは、自分の技術的理解を超えた方法で動作する製品を想像できないようです。たとえば、私はある人から次のようなPowershellコマンドに関する質問を受けました。その人は、そのコマンドが疑わしい使われ方をしている可能性があるのに、なぜシステムはMalopを生成しないのか、なぜ少なくともそのコマンドを疑わしいものとしてマークしないのか、と私に尋ねました。

PowerShell: Command sleep(60)

これは良い質問です。なぜなら、コマンドパラメータは悪意あるコードで使われる可能性があるためです。しかし、単独では、このパラメータ自体は悪意ある行動を示すインジケーターとしては、あまり役に立ちません。しかし、この質問自体は、我々の業界におけるいくつかの根本的な問題を露わにします。

まず、多くのアナリストは、基本的なシグネチャーの概念から離れられないようです。これは、攻撃者が（テレビドラマの）「CSI」シリーズのエピソードに出てくるような、ごく微細なディテールによって識別可能であり、アナリストは、それらをすべて確認した上で、それらのIOC（Indicators of Compromise、侵害の痕跡）を十分に相関させることができるならば、悪者を見つけられるという考え方です。

第二に、多くのアナリストは、見たこともないテクノロジーを理解したつもりになっています。彼らは時にはそれらを理解できることもありますが、たとえ理解できた場合であっても、彼らはそのテクノロジーの根本的なニュアンスを見逃していることがあります。

最後に、これは当社に先行する大手セキュリティ企業の責任でもありますが、人々は自分に理解できないものを信用しません。正直なところ、誰がセキュリティベンダーを信用しようと思うでしょうか。Symantec、McAfee、Trend Microのような大企業から「私たちはあなたのネットワークを保護できます」と言われて、それを何年も信じてきたにもかかわらず、多くの企業や組織は、結果的に何度も繰り返し侵入されてしまったのですから。何かが失敗すると、人々はライセンス契約書の注意事項を忘れてしまい、責任逃れをすることが良くあります。これは、悪いことが起こる以前に、その注意事項がどの程度重要であると思われていたかには関係なく起こることです。

人々が徹底的にテストしていないツールを使いたくないと思うのは、この業界の歴史を考えれば当然のことです。残念ながら、EDRを中心としたテストを本格的に実施するとなると、多くの費用がかかるほか、レッドチーミングのような専門的な技術も必要になります。しかし、アマチュアのテスターは、評価を実行するために十分に洗練されていると思われるツールであれば何でも使おうとします。彼らは、そのようなツールの作成者が仕込んだ機能が、自分に不足している専門知識を補ってくれると信じています。

これらの「テスト」は、多くの場合、先に述べたものと同様に、異なるアクティビティを単独で実行するスクリプトの形を取ります。これらのテストの結果は、しばしばユーザーを失望させ、大きな不安をもたらすほか、時には怒りや不満を引き起こします。しかし、ここで非難されるべきはEDR業界ではありません。彼らは当然ながら、行動分析にできるだけ厳しい姿勢で臨んでおり、扱いにくく、場合によっては使い物にならない偽陽性のインジケーターが量産されることなく、自分たちのシステムが価値あるものであることを確証しようと試みます。

下記のセクションでは、EDRの方法論の一部を紹介した後、そのような「テスト」ツールの1つを完全に分析することで、同ツールの使用上の欠陥を示します。続いて、モダンなEDRシステムと比較した場合に、そのようなツールが生成する結果が信頼できない理由を説明します。

EDRの方法論

私の経験では、アナリストとの対話において、彼らがEDRの仕組みについていくつかの興味深い先入観を持っているように感じられることがよくあります。そこで、EDRが動作する仕組みを少なくとも概念的に理解するために、EDRを構築するためには何が必要となるかを調べてみましょう。

まずは目標を定め、KISS原則（”keep it simple, stupid”の略、できるだけ簡単にするという原則）を採用することから始めましょう。何よりもまず（映画『エイリアン2』の登場人物である）ヒックス伍長の言葉を借りて言うならば、私たちは「施設に入り込むためには彼らに頼る（Count on them getting into the complex）」必要があるのです。私たちは、過去の多層防御手法がすべて失敗することを想定しなければなりません。

攻撃者は、許可されているアウトバウンド通信を使用してファイアウォールを回避します。また、彼らは、ファイルレス型のマルウェアや新種のマルウェアを使用して、アンチウイルスの防御を回避します。攻撃者は、潜在的に「Living Off The Land（LOTL、環境寄生型）攻撃」を行うために、既知の管理ツールを使用して偵察や権限昇格などを実行します。通常、私たちは、攻撃者が最初の侵入に成功することを想定しなければならず、このようなアクティビティやそれに続くアクティビティを可能な限り検知できるようにする必要があります。これを念頭に置いて、いくつかのオプションを検討してみましょう。

最初の最も簡単なオプションは、手法のリストを作成し、悪意のあるものとして知られている手法にフラグを立てるようにすることです。MITRE ATT&CKフレームワークはかなり包括的なリストを提供しているため、これを選択すると良いでしょう。始めるにあたって、私たちは「偵察」というカテゴリーをスキップします。これは、EDRは悪者がシステムに侵入したときにそれを私たちに教えてくれるものであり、彼らが私たちのサーバーを見ながら通り過ぎる際に、それを教えてくれるものではないからです。その代わりに、私たちはまず「初期アクセス」に焦点を当てます。なぜなら、初期アクセスとは、攻撃者が環境において、彼らの実際の足跡を最初に残すアクティビティだからです。

私たちは即座に、手法番号T1078の「正規のクレデンシャル情報を使用して外部のリモートサービスにアクセス」という問題に遭遇します。残念ながら、私たちはこれに関してアラートを発行できません。というのも、リモートサービスにログインするたびにアラートが発生してしまうからです。顧客によっては、1日に何千件もの追加アラートが発行されることになります。これは使わないほうが良さそうです。これをスキップすることも可能ですが、ログインセッションは重要であり、そのデータを収集することはアナリストにとって非常に有益です。このため、私たちはそのようなデータを収集することで、それが後でその他のデータと共にアラート発行に役立つかどうか、または少なくともコンテキストの構築に役立つかどうかを確認することにします。

そして今回、私たちは、EDRの最初の大きなコンセプトである「イベントの相関性」を取り上げました。皆さんがどう思おうと、すべてのデータがアラートの構築に値するわけではありません。MITREは一般的なマッピングフレームワークであり、正常なものと（専門用語で言う）「検出可能なもの」を区別しません。この「検出可能性」という概念は、先に進むにつれて重要になってきます。

さて、私たちは、T1078はそれ自体ではアラートの良い候補にならないと判断しました。ここで、サブテクニックT1078.001である「有効なアカウント：デフォルトアカウント」を見てみましょう。これは良さそうですが、ちょっと待ってください、今度は、顧客向けに、すべての機器のデフォルトのクレデンシャルのリストを用意しなければならず、そしてその機器の中には競合他社製のものも含まれています。私見ですが、一般的に使用されている外部ネットワーク機器のすべてにリソースを投入し、それらのクレデンシャルを私たちのシステムにプログラムすることも可能だと思われます。

ちょっと待ってください、今何と言いましたか？ここには、数千通りもの可能性があります。ここで、私たちは、「アトミック」な手法を使用する（すなわち、各手法を個別のエンティティとして使用する）ことが、ほとんどの場合あまり役に立たない理由を明らかにし始めています。MITRE ATT&CKフレームワークには、拡張的な相関なしに十分な検知を生成する手法はほとんど含まれていません。これは、MITREが各手法を非常に一般的な方法で、かつ平易な言葉で定義しているためです。このような手法の識別をどう実装するかは、ベンダーの想像力に委ねられています。MITREは例を示すこともありますが、そのような例は非常に特殊であるため、膨大な数の動作を見逃してしまいます。この方法で有用なものを構築するには、かなりのバランス感覚が必要です。いずれにしろ、これは優れたアプローチではありません。なぜなら、これらの手法のほとんどは、コンテキストの中に置かれるまでは悪意のあるものにはならないからです。

ちょっと待ってください。もしかしたら異なる技術を組み合わせて１つの検知を生成すれば、適切な検知が得られるのではないでしょうか？それは大いに結構なことです。でも、あなたは、MITRE手法のあれやこれである「可能性がある」と主張するプロパティに一致するすべての振る舞いをタグ付けしたいと思いますか？おそらく、そう思う人は誰もいないでしょう。その理由は、これらのタグを使用して検知を生成すると、あなたは、ストレージスペース、処理能力、エンドポイントのサイクルのような、限界のあるすべてのものに関して、自分で自分の首を締めることになるからです。

ここで、手法T1059.001「PowerShellの使用」を取り上げましょう。たとえば、私がWindowsのLocalSystemアカウントのような特権アカウントを使用しているとします。これではおそらくまだ十分ではありません。なぜなら、スケジュールされたタスクとして設定されたすべてのPowerShellスクリプトはアラートを生成するからです。多くの管理者やソフトウェアベンダーがこれを行っています。さて、ここで、インターネットからのダウンロードを加えてみましょう。残念ながら、またしても多くのベンダーがこれを行っています。私たちはPowerShellによりソフトウェアにパッチが適用されるたびに警告を発行しようとは思わないこと、これを忘れないでください。

これで、クリーンなアラートを生成することがいかに難しいかを、私たちは理解し始めました。しかし、ここで、少なくとも信頼できる何かを得るために、イベントチェーンにもう1つの値を追加してみましょう。特権アカウントにより実行されたPowerShellにより、外部IPアドレス（VirusTotalにより悪意あるものとしてリストされているアドレス）からペイロードがダウンロードされたとします。

やれやれ、これで最初の検知を生成できました。完璧には程遠いですが、開始した時よりは良くなっています。さて、この検知をどのMITRE手法にタグ付けすべきでしょうか？ここでは、この検知を複数の手法にタグ付けすることにします。これらの手法には、特権アカウントの悪用、PowerShellスクリプトの悪用、悪意あるダウンロード、悪意あるネットワークアクセスが含まれています。しかし今や私たちは、自動化されたスクリプティングを行う「テスト」ツールの多くが、突然、信頼性の低いデータを提供する理由を理解できます。私たちは、入手可能な情報に基づいて検知を設計しましたが、相関の「後」に、それらを疑わしいものとしてタグ付けする必要があったのです。

私たちは、その理由を理解するために、EDRの構築さらに進める必要はありません。なぜなら第一に、これは本当に難しいことだからです。第二に、最初は簡単そうに見えても、これは見た目よりずっと複雑だからです。多くの人は、疑惑のタグ付けのほとんどが1つ以上の相関層の後に実施されていることを知らないでしょう。これは、単独で実行されたものにはMITREフレームワークでタグ付けされない可能性があることを意味します。このことを念頭に置いて、テスト用スクリプトの例に移りましょう。

EDRソリューションのテスト

ここでは、GitHubに公開されている「OP7IC EDR Testing」スクリプトを取り上げます。まず私は、よく考えられており非常に上手く構成されたこのスクリプトについて、その作者を褒め称えたいと思います。このスクリプトは、注目すべき振る舞いを持ち、警告に値する各種の手法を実行します。この作者は、手法の本質を本当に理解しています。しかし、この作者が安全性について述べている様々な理由により、これらの手法は実際には悪意ある行動の一部としては使用されていません。それらの一部は警告に値するものもあり、ほとんどのEDRがそれらに関して警告を発しますが、多くはそうではありません。先ほどのPowerShellの例を思い出してみてください。警告を出すのに十分な強度を持ちながらも、悪意ある行動を特定するのに十分な汎用性を持つ検知を生成するためには、どれほど複雑な作業が必要だったでしょうか。

ここで、OP7ICのスクリプトが、いかにしてこの機能を最初にテストするか見てみましょう。最初の実行は、下記に示すように、bitsadminを使って転送ジョブを作成するものです。私たちのターゲット顧客である大企業では、このようなことは日常茶飯事です。このため、これが管理者アカウントで実行されたとしても、これは警告に値しません。私たちのルールはここでは適用されません、これはbitsadminであり、PowerShellではないからです。

次に、同スクリプトは、下記に示すコマンドを実行します。

この実行により、PowerShellによるビット転送が開始されます。この時点で、私たちは自分たちのルールに近づきましたが、いくつか問題があります。Githubは悪意あるものではなく、最悪の場合でも、それは中立的なホストです。また、IPアドレスは常に変化しています。では、これを正確に検出するにはどうすればよいのでしょうか？ダウンロードして実行されるスクリプトは、「Mimikatz」という単語を含むシンプルなものです。つまり、このスクリプトを検査して「Mimikatz」という単語が含まれているかどうかを確認すればよいのです。

このやり方は上手く機能するはずです。しかし、これはMimikatzを検出するには非常に悪いやり方です。Mimikatzという単語が含まれていなくても、Mimikatzを実行するペイロードには、文字通り何千もの種類があります。このため、Mimikatzによるクレデンシャルの窃盗を検知するには、lsassメモリ空間を通じたメモリの変更やメモリの読み取りを調べる必要があります。私たちも、自分のツールにこの機能を組み込んでいます。これで、何とか目的を達成できそうです。

さて、今や私たちは、Mimikatzの実際の動作を通じてエンドポイント上で確実にMimikatzを検知する手段を確保したので、すべてのPowerShellスクリプトに「mimikatz」という単語があるかどうかを検査することにはあまり意味がありません。このような理由から、私はベンダーとして、「Mimikatz」という単語を見つけるためにPowerShellscriptsを検査することに、エンドポイントサイクルを消費することには価値がないという経営判断を下すつもりです。ベンダーの中には、実際のWindowsクレデンシャルの窃盗を検知する機能を構築する際に、初期の検知機能としてこれを搭載していたものもあります。そのような検知は今もなお存在するかもしれませんが、今日新しい検知を生成している場合、そのような過去の検知を気にする必要はないでしょう。

これが「テストスクリプト」が失敗する原因です。スクリプトが、実際にリモートロケーションからダウンロードしたMimikatzのような悪意あるプログラムを実行しない場合、あなたはアラートを期待するべきでしょうか？いいえ、決して期待すべきではありません。

私は、OP7ICテストスクリプトの異なる実行例をすべて調べることで、どれが正当であり、どれが変更を必要とするものであるかを示すことができます。しかし、この記事の目的は、どこから見ても非常に知的で有能に見える、この特定の作者を非難することではありません。いずれにせよ、問題は、作者やスクリプト自体にはありません。問題は、そのアプローチにあります。悪意ある行動を実際に行うことなしに、悪意ある行動を模倣しようとすることは、私の知る限り、誰も成功したことがない芸当だと思われます。

先述したスクリプトを使って、あるベンダーのパフォーマンスが悪いように見えたとしても、そのベンダーの検知機能が良いか悪いかは実際には判断できません。同様に、あるベンダーのパフォーマンスが高いからといって、その検出機能が良いか悪いかを判断することは不可能です。では、このテストスクリプトは、EDRテストツールとして現在のところ有用なのでしょうか？いいえ、そうではありません。唯一の良い点は、テレメトリを生成して、特定のEDRツールがアクティビティを記録したかどうかを確認できることです。では、どうすれば良いのでしょう？私たちが必要としているのは、これらのツールを私たちのためにテストし、私たちが利用できる詳細な結果を提供してくれるような、特定のベンダーに関係のない外部グループです。

MITRE ATT&CK評価

調査した結果、MITRE ATT&CKフレームワークを使って、攻撃者に対するEDRシステムの能力テストを実施している団体が見つかりました。それがMITREです。MITREは業界から独立した組織であり、特定の攻撃者の手法の完全なエミュレーションを実行する中で、ベンダーが各自の最高のパフォーマンスを発揮できるようにします。

現在までにMITREは3回の評価を行っており、その結果は明白です。これは、あらゆるEDRが持つ検知能力を測定できる極めて優れた指標となります。本稿執筆時点での最新の評価では、防止機能を含んでいるほか、EDRに搭載されているエンドポイント防止スタックもカバーしています。何より、結果を得るためにお金を支払う必要は一切なく、結果はすべて公開されています（サイバーリーズンが最新のMITRE ATT&CK評価でいかなる成績を収めたかに関する詳細は、こちらをご覧ください）。

レッドチームによるテスト

また、ある組織に、選択したEDRを搭載したシステムに対する完全な攻撃シミュレーションを行わせることや、異なるEDRツールを搭載したシステムに対する攻撃シミュレーションを繰り返し行わせることもできます。これにより、EDRが効果的に警告を発するかどうかを判断できます。これは、利用するレッドチームが偏りなく有能であることを前提としています。

結局、GitHubやインターネット上に公開されているEDRテストツールを使用することが最善の方法ではないことは明らかです。これらのツールは一般的に、第三者による検証が行われておらず、「アトミック」なアプローチで運用されており、実際の攻撃手法を反映していません。それらのツールよりも、もっと優れた方法が存在しています。そして、多くの場合、テストは専門家に任せることをお勧めします。

ホワイトペーパー「MITRE ATT&CKを使用してクローズドループ式のセキュリティプロセスを作成する5つの段階」

このホワイトペーパーでは、MITER ATT&CKを使用してクローズドループの戦術的なセキュリティ対策を実施するために参考にすべき、重要な5つの段階について説明します。
https://www.cybereason.co.jp/product-documents/white-paper/3259/