脆弱なドライバーではなく正規のEDRそのものを持ち込み、その保護機構をマルウェアの保護へ転用する手口「Bring-Your-Own-EDR」が公開されました。必要なのは出回っているインストーラーと管理者権限だけで、カーネルの脆弱性も悪意あるドライバーも使っていないと記されています。回避の対象はPPL(Protected-Process-Light)で、保護されていないプロセスからのメモリーアクセスと署名なしDLLの読み込みを拒む機構。EDRが登録するCOMインターフェースと改ざん防止機能が、保護境界を越える経路と、持ち込んだコードを守る仕組みの両方になる構図です。端末側の「SECURE」という状態表示と、管理コンソールへのテレメトリー到達が別だという点も、経路つきで示されています。 BYOVDが署名済みの脆弱なドライバーを持ち込むのに対し、ここで持ち込まれるのは端末防御そのものです。管理者権限を取られた後にPPLがどこまで保護境界として機能するのか、どの表示を信用の根拠にできるのかが、具体的な手順として書かれている内容になります。 【技術的な要点】 ・DEF-CON-34での発表で、SentinelOneのエージェント版26.1.1で修正済みとの記載 ・入口はCOMオブジェクトSentinelHelperのDumpメソッド。他のメソッドと異なり呼び出し元のベースパスを検証せず、診断用スクリプトから呼ばれる都合との説明。PsProtectedSignerAntimalware-Lightを継承するため、管理者権限で同等以下の保護レベルのプロセスのメモリーダンプを取得できたとの報告 ・先行研究PPLSystemへつなぎ、Defenderのダンプから得たCOMの秘密値で署名なしDLLを同プロセスへマップ。再配置も実行スレッドも作らない先行実装の限界を、保護属性の変更や静的リンクなどで解消したとの記述 ・出回っている正規インストーラーに自作のサイトトークンを渡すだけで、未導入の端末にも導入が通ったとの経緯。機能しないエージェントが「SECURE」と表示され、先行する保護製品は導入時の仕様で無効化。新しい版は宛先で所定のAPIを返すサーバーが要るとの補足 ・sentinelctl[.]exeで改ざん防止機能を切って戻すと、インストール先のペイロードが製品ドライバーに守られ、他プロセスが開けるのはPROCESS_QUERY_LIMITED_INFORMATIONのみとの説明 ・管理サーバーのURLはGetAgentStatusJSONから読め、hostsでループバックへ解決させればテレメトリーが止まる一方、保護状態の表示は変わらないとの記載 詳細は以下を参照： akamai.com/blog/security-res… (※可能な範囲でファクトチェックは実施済なものの、元記事の精度依存や速報・要約の性質上漏れもありうるため、正確な情報は一次情報を直接参照のこと)