Summiting the Pyramid v3.0.0 とは 1: Summiting Levels

fiord Advent Calendar 2025 10 日目の内容となります。

セキュリティ攻撃を検知、防止する仕組みがあると共に、攻撃者はそれを回避する手法や技術といったものも数多く存在しています。
これに対してどのように判断を行っていくか、という問題に対して、とある研究プロジェクトを紹介します。

注意 : 現在時点での私個人の理解に基づく記事であり、正しいことを保証しません。

目次

1. Summiting Levels ←ココ
2. データの組み合わせ
3. 堅牢な検知ルールを作る

Summiting the Pyramid とは

MITRE Center for Threat-Informed Defense による研究プロジェクトです。実際に存在する下記ページの情報にこの記事は基づきます。

ATT&CK フレームワークなどを活用し、攻撃者による回避手法をより実現困難にすることが目的です。

何が回避困難なのか？

「Robust Detection（堅牢な検知）」といい、回避ロジックがあったとしても悪意のある行動を正確に検知できるアナリティクスを指します。攻撃者の行動パターンの本質を捉えることで、攻撃手法の変化に対して耐性を持ちます。

Pyramid of Pain と Summiting Levels

David J Bianco 氏により提唱されたモデルであり、より上の階層の対策を行なえば攻撃者に対して痛手を与えるとされています。

• Hash Values: マルウェアのハッシュ値。攻撃者視点では再ビルドすればOKですね。
• IP Address: C2 サーバーなど、通信先。ドメインは対象外なので、マルウェアはそのまま、サーバーを新規に立ててドメインの A レコードの先を変えればよさそうです。
• Domain Names: ドメイン情報。マルウェアの再配布とドメインの更新が必要です。
• Network/Host Artifacts: ネットワーク通信/端末に関する情報です。マルウェアを少し弄る必要があります。
  • Network: 利用されるネットワークプロトコル、URI、User Agent 等
  • Host Artifacts: 攻撃対象の端末にて残されるレジストリやサービス、ファイル等
• Tools: どのようなツールを利用しているか。このレイヤーで対策されると、攻撃者は下記の作業が必要です。
  1. 代替ツールで同じ攻撃が出来ないか調査を行う
  2. 1 が難しい場合、新しくツールの開発を行う必要がある
  3. 新しいツールの利用方法を学ぶ必要がある
• TTPs: ツールよりさらに抽象的に「攻撃者が目的達成のために利用する手法」となります。例えば「侵入のために社内の人になりすましたフィッシングメールを送信する」といったものになります。
  このレイヤーで対策をされてしまうと、攻撃者は全く異なる別の手法を考える必要があります。

（恐らく）このピラミッドを登る（上のレイヤーで検知・対策する）ために、このピラミッドの概念を細分化し、Summiting Levels という概念を定義しています。

Summiting Levels

解析における堅牢性（Analytic Robustness）に関する 5 段階の行と、端末で観測できるイベントの堅牢性（Host-Based Event Robustness）に関する 3 段階の列、もしくはネットワークトラフィックに関する堅牢性（Network Traffic Robustness）に関する 2 段階の列からなる行列で定義をしています。

解析における堅牢性（Analytic Robustness）

5 段階のレベルで評価され、数値が大きくなるほど堅牢なものとなります。下記はレベルの低い順です。

• [Level 1] Ephemeral Values: ハッシュ値/IP/Port/ファイル名/ドメイン名など。
• [Level 2] Core to Adversary-Brought Tool or Outside Boundary: コマンドライン引数の使い方やバイナリにおけるメタデータ/OriginalFileName など。攻撃者が外部から持ち込んだものであることが前提です。
• [Level 3] Core to Pre-Existing Tools or Inside Boundary: 事前に端末内にあったツールを利用したもの（他は 2 と同じ）。
  解析の際、元からあるツールなので「元からあるよね」と見逃されてしまったり、良性の利用と判別が困難、という問題があります。故に攻撃者はこちらが使えるなら使いたいですし、使えないと「防御されやすい攻撃手法になってしまう」とも言えます。
• [Level 4] Core to Some Implementations of (Sub-)Technique: ATT&CK における分類のサブテクニック。著名なツールがここに入ります。
• [Level 5] Core to Sub-Technique or Technique: ATT&CK におけるテクニック/サブテクニックで、攻撃手法の本質を示すものです。例えば「～というサービス」ではなく、「サービスによる永続化」がここに入ります。

端末で観測できるイベントの堅牢性（Host-Based Event Robustness）

下記では堅牢さが低い順です。ただ、個人的には Application と User-Mode のレベルの違いは抽象的には理解できるものの、具体的な分類が綺麗に出来ていないと感じています。

• Application: アプリケーション層におけるイベントです。例えばスケジュールタスクの設定・変更（これ書かれていますが、本当に UI か？とは思います）など、UI レベルで何が起きているかを指します。
• User-Mode: ユーザースペースでのイベントで、プロセスへのアクセス/削除やドライバーの読み込み、ファイル作成日時の変更など、ぱっと分からないものが対象だと思っています。
• Kernel-Mode: 文字通り OS カーネルレベルのイベントです。

ネットワークトラフィックに関する堅牢性（Network Traffic Robustness）

下記では堅牢さが低い順です。

• Payload Visibility: ペイロード本体の観測データです。攻撃者により暗号化されてしまう可能性があります。
• Header Visibility: パケットヘッダ情報によるもので、ペイロード本体よりは堅牢だと思います。

例

いくつか元ページに例があるので、貼っておきます。

T1003.001: LSASS Memory

HTTP

Summiting Levels の計算

とある yara 検知ルールを作成したとします。このルールについて、スコアリングをしていきましょう。

1. センサーデータのスコアリング: データの元がどのように取得されているかにより、「端末で観測できるイベントの堅牢性」の評価（Application/User Mode/Kernel Mode）をします。
2. 観測可能な個別の値（各条件・文字列や正規表現）のスコアリングをします。多くは Level 1 もしくは Level 2 に該当しそうです。
   フィルターについても評価します。誤検知を減らすために利用され、例えば Windows/Mac/Linux の既知の正規プロセスを除外することで、Level 3 のスコア付けが可能です。
3. 分析ロジック/条件を 2 で評価した各スコアを元に評価します。これで算出されたスコアがルール全体のスコアとなります。

具体例が原文に複数上がっており、参考がてら読んでみるといいかもです。

（上記の画像、元のページから引用してますが、filter 部分のスコアは Level 3 だと思います。ただし、yara の条件で 1 of selection_malleable_profile に引っ張られてしまうので、トータルでは 1K です）

まとめ

• より回避が難しい検知ルールを作成するには？というプロジェクト
• Pyramid of Pains を再編し、マトリックスとして評価を行っている

今回はなるべく具体的な話をしましたが、次回は抽象的な話で続いていきます。