Singularity Rootkit、Elastic DefendのeBPFモジュールロード検知を回避

セキュリティ研究者は、Linux向けrootkit「Singularity」がElastic Defendの検知を回避するために用いている手法を公開しました。この手法は複数の防御レイヤーにわたってモジュールロードのテレメトリを抑制することで検知を逃れるものです。

SecurityProducts & Services

今回の研究は、エンドポイントのeBPF監視における「信頼済みプロセス」の除外設定が、高度なカーネルレベルの脅威にとって格好の標的となり得ることを浮き彫りにしています。

報告によると、Elastic Defendはバージョン8.14前後から、BPFベースのイベント機構を通じてLinuxカーネルモジュールのロードを監視してきました。

Elastic Defend 9.5のリリースでは、モジュールロードイベントに「taint_flags」フィールドが追加され、実行中のカーネルを汚染する可能性のある、安全性が確認できない・署名されていない・外部でビルドされたカーネルモジュールを特定するルールが導入されました。

Singularity RootkitによるElastic Defend回避

研究者は、rootkitのカーネルオブジェクトがコンパイル・ディスクへの書き込み・ロードのいずれかの段階でアラートを発生させ得る、複数の異なる検知制御を特定しました。

Ubuntu上でカーネルバージョン6.8、Elastic Defend 9.5.2を稼働させたテスト環境において、Singularityを何の手も加えずにロードしたところ、76件のアラートが発生したと報告されています。その大半はディスク上のrootkitモジュールに対するYARA検知によるものでしたが、一部はElasticのランタイムBPF監視に起因していました。

今回のバイパス手法の核心は、Elasticの「信頼済みプロセス」の扱いを悪用する点にあります。Elasticに組み込まれているmodule_load用のeBPFプログラムは、モジュールロード情報を収集する前に、現在のプロセスIDが信頼済みプロセスIDを保持するマップに存在するかどうかを確認します。

ロード元のプロセスが信頼済みと判定された場合、このBPFプログラムは早期に処理を終了し、Elasticのtaint-flag検知ルールに必要なエンドポイントイベントが生成されなくなります。この欠落により、ロードされたモジュールがカーネルを汚染したかどうかを評価するために必要なテレメトリが、該当の検知機能に届かなくなってしまいます。

研究者の0xMatheuZ氏によると、rootkitのローダーは固定のIDに依存せず、適切なBPFマップを動的に特定するとのことです。これは、Elasticエージェントの再起動時にマップIDが変わり得るためです。この手法により、ローダーはモジュールロードを開始する前に一時的に自身を信頼済みとして登録し、処理後にそのエントリを削除することが可能になります。

この設計が特に注目に値するのは、Elastic Defendを完全に無効化しようとするのではなく、正規プロセスから不要なテレメトリが生成されるのを防ぐために設けられた内部的な信頼メカニズムを悪用している点です。

Singularity Rootkitの回避戦略には、YARAによる検知を減らすためのソースコード難読化も含まれているとされています。この難読化ツールは関数名やファイル名をランダム化し、生成されるモジュール名を変更するとともに、防御側がシグネチャに利用しかねない特徴的な文字列を変換します。

報告書ではさらに、Elasticのカーネルモジュール作成検知ルールにある広範な除外設定を悪用する手法についても説明されています。このルールは、サードパーティ製ドライバのビルドに広く使われているLinuxフレームワーク「DKMS」に関連するパスを除外対象としています。

Exploitdatabase access

生成したカーネルオブジェクトをDKMS関連のディレクトリに配置することで、rootkitは不審な.koファイル作成に対する挙動検知アラートを回避できる可能性があります。

さらにSingularityは、カーネルログの出力をフィルタリングし、`lsmod`や`/proc/modules`、`/sys/module`といったLinuxの一般的なインターフェースから自らのモジュールを隠蔽するとされています。

今回の調査結果は、信頼済みプロセスの状態を誰が変更・操作できるかを十分に制限しないままテレメトリの除外設定に頼ることのリスクを浮き彫りにしています。組織は、BPFマップ、信頼済みプロセスの判定処理、カーネルモジュールロードの制御、そしてDKMSのビルドディレクトリを取り巻くエンドポイントエージェントの保護策を見直す必要があります。

防御側は、モジュールロードの活動をカーネルの整合性シグナルと突き合わせ、`finit_module`をはじめとする関連システムコールを監査し、想定外のBPFオブジェクトへのアクセスを監視するとともに、エンドポイントセキュリティのBPFマップにアクセスするプロセスに対してアラートを発する必要があります。

検知エンジニアリングにおいては、特に攻撃者がすでにroot権限レベルのアクセスを掌握している可能性があるシステムでは、除外対象のビルドパスを自動的に無害と見なすことを避けるべきです。

SOCを常に最新の状態に保ち、活発化するマルウェアやフィッシングの脅威を発生から24時間以内に把握しましょう。 ANYRUNを試して早期検知でインシデントを未然に防ぎましょう。