fiord Advent Calendar 2025 12 日目の内容となります。
また、Summiting the Pyramid v3.0.0 とは 2: データの組み合わせ の続きの内容となります。
注意 : 現在時点での私個人の理解に基づく記事であり、正しいことを保証しません。
目次
堅牢な検知を作成するには
文脈を利用して、FP/FN のバランスを取りつつも、攻撃者によって長期的に回避が難しい検知（堅牢な検知）を作成すること、これが Summiting the Pyramid の目的です。
ここでは、その手順について触れていきます。
悪性のアクティビティを観測・分析できる環境を作る
攻撃の途中では一時的なファイルに留まらず、特定の OS の関数呼び出しを行うことも考えられます。なるべく多くの実装（可能ならすべての実装）に対してデータが観測可能になるようにすることです。
その結果として、多くの検知したいアクティビティに対して「データ A、B、C からこのアクティビティは悪性です」と判断できるようにする必要があります。
では今の状態で大丈夫か？と視覚化する方法として D3（Detection Decomposition Diagram）というものがあります。これについては後述します。
悪意のあるアクティビティに対して、それに特化したデータセットを取り出す
前述のデータが取り出せるようになったら、その中でどのデータセットを用いて良性/悪性の判断を行うかを決めます。
再度ですが、FN を低くすれば悪質な実装全てを検知するデータに重きを置き、FP を低くすると検知時の信頼性に重きが置かれます。
状況及び後述のステップを踏まえて、バランスよく選ぶ必要があります。
誤検知（FP）を減らすため、除外を追加する
FN が低い、攻撃者にとって回避が困難な検知が作成できる状態にあると思います。フィルタリングを行い、既知の良性のアクティビティを除外することで FP を減らしていきます。適切に設定することで、再現率を維持し、FN が低いまま FP を減らすことが可能です。
ただし、この除外は攻撃者にとって隠れ蓑になってしまう可能性があります。このため、除外は可能な限り具体的な値で、小さなものでありつつも、攻撃者による利用が困難であることが必要です。
ファイルパス全体ではなく、ファイル名や特定のツール名など、安全な実装であることが知られている特定の値を利用することが望ましいです。
攻撃者にとって、変更が困難なフィールド・値を探す
イベントデータの各フィールドには攻撃者にとって変更が困難なものが存在します。各フィールドを評価し、攻撃者にとって検知回避が容易なもの、攻撃の本質であり、回避が困難なフィールドを識別する必要があります。
良性/悪性の識別のために、どのようなイベントが含まれているか？
自分の環境における良性のアクティビティを理解し、その固有の値を除外として利用することが望ましいです。
ただし、大きな除外を設定してしまうと攻撃者がそこを利用してしまうリスクがあります。そのために、一意かつ無害なアクティビティを特定し、それのみを除外することが望ましいです。
そのために、下記の問いが有効そうです。
- フィルターを外してみた際に、明らかに良性のアクティビティが大量に混ざってないか？（アナリストの負荷低減のため、除外を作成する価値がありそう）
- そのアクティビティについて調査したことがあるか？ツールによるものか、ユーザーによるものか、特定のユーザーロールに基づくものであるか。
- 除外（フィルター）により、正確性に影響を与えるか（どの程度 FN が出てきてしまうか）
- 攻撃者がこの除外を隠れ蓑に出来るか？出来るなら緩和策はあるか？
この除外の例として「Scheduled Task」が挙げられて、下記の 2 種類の除外が考えられます。
- タスク名に基づいて除外する: 攻撃者が書き換えに成功すれば任意コマンドの実行が可能。Summiting Level では一時的な値（Level 1）に該当します。
- タスクのコマンドや CLSID に基づいて除外する: 攻撃者による改ざんが難しく、Summiting Level ではテクニックの一部実装の中核（Level 4）に該当します。
除外に追加する固有の値を特定
下記の問いが値の特定に有用です。
- どのユーザ/アプリケーションによるアクティビティか？
- どのアクティビティが調査され、良性と判断されたか？
- 既にフィルタリングとして除外されていないか？
- 攻撃者が最も利用しそう（使い続けなければならない）行動はどれか？
また、値を除外する際は攻撃者により難読化を行われ、検知を回避される可能性があることに注意する必要があります。
そのため、前のステップで堅牢なフィールドを選択しましたが、ここでは既知の良性なアクティビティを指す具体的な値を指す必要があります。
検知の変化を観察、調整する
フィルターが完成したら、検知精度がどのように変わるかを観察し、必要な調整を行いましょう。
- 今まで発生していた誤検知（FP）はどの程度発生するようになったか（1h/1d/1w/1mごとに）
- 予想していなかった良性のアクティビティがあるか
- 過去の調査の際に補足できなかった、悪性のアクティビティがあるか
このプロセスは一度で完了するものではなく、定期的に新規・既存ユーザー、ツール、あるいは新しい攻撃の TTP を考慮して見直す必要があります。
統合分析フレームワーク（Fused Analytic Frameworks）への組み込み
複数のアナリティクスを統合することで、検知精度を向上させることが追加で考えられます。
- リスクベースアラート（RBA）: 観測した複数のデータに基づきリスクを算出するフレームワーク
- グラフ分析/統計分析: 複数のアナリティクスの関係性を理解することで 連鎖アナリティクス に利用できます（個人の認識で、違うかも）
- 手法推論エンジン(TIE）: MITRE Center for Threat-Informed Defense 自身が出しているサービスで、観測できたテクニックから、攻撃者が利用した可能性のあるテクニックを提案してくれます。
Detection Decomposition Diagram(D3)
D3 は重要な観測対象を見つけるために設計された視覚的な補助ツールです。
機能抽象化
D3 の元となるものとして、Capability Abstraction という概念があります。
ある手法にフォーカスして、それに関連する複数のツール（なるべく網羅したい）にて観測されたデータを比較、マッピングするといいものが見れます。
T1208 - Kerberoasting について、複数のツール（青色）で観測されたデータをまとめ、左側のManaged Code/Windows API Function/RPC/Network Protocol に分解します（分解先はテクニック毎に異なります）
すると、Network Protocol における Kerberos TGS-REQ/REP はすべてのツールで共通して使っており、これをベースとした検知は回避が非常に困難です。
他の例として T1050 - New Service もありましたので、記載します。
最終的には同じ HKLM\SYSTEM\CurrentControlSet\Services というレジストリ値（濃いオレンジ）を利用していることが分かります。
この機能抽象化は Summiting Levels にマッピングすることが可能です。
D3 をベースとした検知ルールの作成
例として、T1003.001: OS Credential Dumping: LSASS Memory を取り上げ、検知ルールの作成をしてみましょう。
Capability Abstraction を元に D3 を作成
観測されているデータから、良性/悪性のツールを可能な限り列挙し、各ツールで発生した挙動を Capability Abstraction の表にまとめ、下記のようなダイアグラムに変換します。
D3 から「悪意のあるアクティビティに対して、それに特化したデータセットを取り出す」
FN を減らすため、Sysmon EID 10 かつ TargetImage=lsass.exe に着目することがよさそうです。
しかし、一方で非常に多くの良性のアクティビティでも lsass.exe は使われています。
そこで、もう少し調査をしたところ、悪性のアクティビティでは GrantedAccess が通常ではあまり設定されない 0x1010 や 0x1410 になっていることが判明しました。
勿論これにより、GrantedAccess が他の値である場合に悪性でないと断言できるかは怪しいです。そのため、Summiting Level ではテクニックの一部実装の中核（Level 4）に該当します。
FP を減らすため、除外を追加する
更に除外の追加をしていきましょう。確認したところ、この環境ではユーザー NT AUTHORITY\SYSTEM による LSASS の利用が良性の物であることが分かりました。
ということで、これを除外ルールに加えましょう。これにより、 1 つ Summiting Level が下がりますが、今回は堅牢性よりも FP を減らす方が大事だと判断しました。
ということでルールとしては下記のようになります。
`sysmon` EventCode=10 TargetImage=*lsass.exe
(GrantedAccess=0x1010 OR GrantedAccess=0x1410)
AND SourceUser!='NT AUTHORITY\SYSTEM'
Sysmon Event ID 10 は Uesr-Mode であること、また、最後の NT AUTHORITY\SYSTEM を理由に Summiting Level は 3U に分類されます。
まとめ
- 検知ルールを作成する際には、FP/FN のバランスを取りながら作成する必要がある。ただし、FP は除外により抑えることが可能。
- ただし、検知ルールの評価は「フィルタリング後」の評価であり、除外により検知ルールのレベルが下がる可能性があることに留意する必要がある
- 検知ルール作成の際に D3 といったものを利用するとよいかも。