【ITニュース解説】Catching ransomware with eBPF: what execve/openat tracing taught me about false positives

talus-process-monitorは、Linuxシステム上で活動するランサムウェアを検出するために開発された革新的な監視ツールである。このツールは、eBPF（extended Berkeley Packet Filter）というLinuxカーネルの機能を利用し、システム内部の活動を深く監視することで、ランサムウェアの不正な振る舞いをリアルタイムで捉えようと試みている。この検出器の最大の特徴は、一般的なウイルス対策ソフトのように既知の脅威パターン（シグネチャ）に依存するのではなく、ファイルの操作やプロセスの起動といったシステムの「行動」から異常を判断する点にある。

ランサムウェア対策において、なぜこのような振る舞い検出が必要なのか。従来のシグネチャ検出は、既知の脅威に対しては効果的だが、新しい種類のランサムウェアや、既存の正規ツールを悪用するタイプのランサムウェアには対応が難しい。特にLinuxを標的とするランサムウェアは、find、mv、gzipといったシステムに標準で備わっているコマンドを組み合わせて使われることが多く、そのスクリプトは非常に短命で内容も変化するため、特定のコードパターンで検出することは困難である。そこでtalus-process-monitorは、ランサムウェアが引き起こす「被害の痕跡」に着目する。具体的には、短時間で大量のファイルが開かれ、中身が書き換えられ、ファイル名が変更されたり、拡張子が一括で変更されたりといった、通常では見られない異常なファイル操作のパターンを監視する。

この異常な振る舞いを検出するために、talus-process-monitorはLinuxカーネルの内部から特定のシステムコールをトレース（追跡）する。システムコールとは、プログラムがオペレーティングシステム（カーネル）に何らかの処理を依頼する際の窓口のようなものである。監視される主なシステムコールは以下の通りだ。

まず、execveやexecveatは、どのプロセスがプログラムを実行しているか、そしてそのプロセスが他のプロセスを起動したのかどうか、つまり「誰が何をしているか」というプロセスの実行状況を把握するために使われる。ランサムウェアは、ファイルを暗号化するために複数のプロセスを生成し、並行して作業を進めることが多いため、プロセスの実行を監視することは重要である。

次に、openatやopenat2は、ファイルがどのような目的で開かれたかを監視する。特に、ファイルを書き込み専用で新規作成するフラグ（O_WRONLY|O_CREAT）が短時間に大量に発生する場合、これはランサムウェアが元のファイルを暗号化して新しいファイルとして書き出している可能性が高いと判断される。ランサムウェアは通常、元のファイルを読み込み、それを暗号化してから新しいファイルとして書き出し、その後元のファイルを削除するという手順を踏むため、書き込みフラグの頻度は重要な手がかりとなる。

さらに、unlinkやrenameは、ファイルの削除や名前の変更パターンを監視する。ランサムウェアは、元のファイルを削除したり、暗号化後のファイルに「.locked」のような特定の拡張子を付与するためにファイル名を変更したりする。これらの操作の頻度やパターンも、ランサムウェアの活動を示す強力な兆候となる。これらのシステムコールはすべて、データが実際にディスクに書き込まれる前の、カーネルレベルで取得されるため、より迅速な検知が可能となる。

このような大量のイベントデータを効率的に収集するためには、技術的な工夫が必要となる。開発者が当初直面した問題は、すべてのイベントを一つの共有メモリ領域（グローバルなリングバッファ）に集約しようとしたことだった。しかし、ランサムウェアが高速にファイルを処理しようと並行処理を行うと、イベントが衝突したり、消失したりしてしまう問題が発生した。この問題を解決するために、システム内の各CPUごとに専用のperfバッファというメモリ領域を用意する方法が採用された。これにより、並列負荷が高い状況でもイベントの衝突を避け、確実にデータを収集できるようになった。ユーザー空間で動作するプログラムは、各CPUのバッファからイベントを読み取り、プロセスごとにイベントの順序を再構築して、正しく解析できるようにする。

技術スタックとしては、ユーザー空間のコンポーネントはRust言語で記述され、eBPFプログラム自体はlibbpf/CとCO-RE（Compile Once – Run Everywhere）技術を用いて開発されている。CO-REは、eBPFプログラムを一度コンパイルすれば、異なるカーネルバージョンでも動作させられるという利点があるが、実際にはカーネルのバージョンによって構造体の内部レイアウトが微妙に異なる場合があるため、メモリ上の位置（フィールドオフセット）を正確に検証することが重要だ。開発者はこの点に関して何度か問題に直面したと述べている。

しかし、これらのイベントを監視するだけでは十分ではない。最も困難な課題は、「何をランサムウェアと判断し、何を正常な活動と判断するか」というスコアリングの問題である。単純に「N秒間にMファイルを書き込んだらランサムウェア」というルールを設定してしまうと、誤検知が頻発してしまう。例えば、プログラミングプロジェクトのコンパイル作業（cargo buildなど）、カーネルモジュールのコンパイル、あるいはテストスイートの実行といった一般的な開発活動でも、数千ものファイルが短時間に生成・更新されることがある。これらをすべてランサムウェアと誤って判断してしまうと、システムは使い物にならなくなる。

この誤検知の問題を解決するために、talus-process-monitorは以下の3つのヒューリスティック（経験則に基づく判断基準）を導入している。

第一に、「拡張子変更の頻度」である。ランサムウェアは、ファイルを暗号化した後にそのファイル名を変更したり、一括で拡張子を「.locked」のように変えることが多い。一方、ソフトウェアのビルドプロセスは新しいファイルを生成するが、既存のファイルを大量にリネームしたり、拡張子を一括で変更したりすることは稀である。この違いに着目することで、ランサムウェア特有の振る舞いをより正確に捉えることができる。

第二に、「読み込み後の書き込み密度」である。ファイルを暗号化するプロセスは、まず元のファイルを読み込んでから、その内容を暗号化し、そして暗号化された内容を新しいファイルとして書き込む必要がある。つまり、読み込みと書き込みがセットで発生する頻度が高い。対照的に、ビルドプロセスは、多くの場合、既存のファイルを読み込むことなく、コンパイル結果などの新しい出力ファイルを直接書き出す傾向にある。この読み込みと書き込みの関係性を分析することで、ランサムウェアの挙動を識別する。

第三に、「ディレクトリの広がりと深さ」である。ソフトウェアのビルドディレクトリ（例えばtarget/ディレクトリ）は、通常、特定のプロジェクトのサブツリー内に深くファイルを生成する傾向がある。これに対し、ランサムウェアはユーザーのホームディレクトリ全体や、複数の異なるディレクトリにわたって、広範囲にファイルを暗号化しようとする。ファイル操作が特定の深いツリーに集中しているのか、それとも広範囲に拡散しているのかを判断することで、正常なビルド活動とランサムウェアの活動を区別する。

これらのヒューリスティックはそれぞれが完璧な解決策ではないが、talus-process-monitorはこれらを組み合わせて、重み付けされたスコアを算出することでランサムウェアかどうかを判断している。この重み付けのバランスこそが、検出器の性能を決定する重要な要素となる。

最後に、開発者が将来的に改善したいと考えている点や、今回の開発を通じて得られた教訓がいくつかある。まず、いきなり検出とブロックを行うのではなく、まずは「監査モード」として何週間もシステムでログを収集する期間を設けるべきだったという反省点がある。実際にシステムで運用してみないと、予測していた誤検知率がいかに現実と異なるかがわかる。次に、検出のしきい値をグローバルに設定するのではなく、ディレクトリのタイプ（ビルドディレクトリ、ホームディレクトリ、メディアディレクトリなど）ごとに細かく設定できるようにすべきだという点。これにより、特定の環境に合わせたより柔軟で正確な検出が可能になる。また、eBPFプログラムを開発する際には、カーネルが提供するeBPFベリファイアの制限（例えば、ループに明確な上限を設ける必要がある、マップの要素を無限にイテレーションできないなど）を、設計の初期段階から厳密に考慮する必要がある。これを怠ると、検出ロジックを何度も再設計することになる。

talus-process-monitorは、eBPFという強力なカーネル技術を活用し、ランサムウェアの振る舞いをリアルタイムで検出するという先進的なアプローチを試みている。特に、誤検知を減らすための工夫は、実際のシステムで検出器を運用する上で非常に重要な課題であり、その解決策として提示されたヒューリスティックは、今後同様のシステムを開発する上での貴重な知見となるだろう。