はじめに

Splunkには、痛みのピラミッド(pyramid of pain)で有名なDavid Bianco氏が在籍している（2024/12/8時点）
DavidはSplunkにきてThreat Huntingのフレームワークを開発しホワイトペーパーをリリースした
PEAK Threat Huntingを理解して、Volt typhoonのようにThreatHuntingでないと検知するのが困難なLiving off the land(環境寄生型攻撃)攻撃に備えましょう JPCERT CC Blog

ThreatHunting

Threat Huntingについては過去の記事もご参考ください
- Threat HuntingとMITRE ATT&CKとSplunk
Threat Huntingは2015年にSqrrl社が提唱した仮説検証型アプローチを中心としたフレームワークです
2018年にAWSに買収されてから今日までアップデートはありませんでした
そのことについてDaivdが2024/6のRSAカンファレンスで謝罪しています
- I Screwed Up Threat Hunting a Decade Ago and Now We're Fixing it With PEAK

PEAKとは

2024年にSplunkのSURGeにJoinしたDavid Biancoは新しいThreat Huntingフレームワークを開発しました
上述したRSAカンファレンスにてPEAK Threat Huntingを発表しています
PEAKとは、Prepare(準備)、Execute(実行)、Action(対応)、Knowledge(ナレッジ）の頭文字をとっています
特にKnowledgeを貯めて属人性を排除し、再帰的な業務を目指すコンセプトに重点を置いています
ハンティング手法を大きく３つのパターンに分けています
仮説に基づいた脅威ハンティング
- 仮説はより具体的かつ検証可能なものをセットするのがポイント
ベースライン脅威ハンティング
- 正常な挙動のベースラインを設定して、逸脱する挙動を見張る
モデル支援脅威ハンティング
- 明確なトピック（「辞書ベースのDGAドメインを特定したい」）はあるが、具体的にどうすればいいのかわからない（暗黙の複雑性）
- M-ATHの主な利点は、違いを見分ける方法を見つけ出すという大変な作業をコンピュータに任せることができる点
３つの手法の最適な選択はまず対象範囲から分岐し、仮説ベース、ベースライン、モデル支援のいずれかに分類されます。

仮説に基づいた脅威ハンティング

例えば対象範囲のトピックを攻撃者による「データ窃取」をトピックにしてみましょう

例：データ窃取の仮説構築
1. トピックを選択する : たとえば、組織のネットワークから機密情報が盗み出されることを心配しているとします。この場合、トピックとして「データ窃取」を選択します。

2. 検証可能な形式で記述する：おそらく、想定される窃取技法をすべてハンティングするのは難しいので、特定の技法に絞って仮説を記述します。たとえば、「攻撃者がDNSトンネリングを使って機密データを盗み出している可能性がある」とします。

3. 必要に応じて見直す：大規模な組織の場合、攻撃者に狙われるデータの種類が非常に多いため、現在の仮説は検証が困難だと気づいたとしましょう。そこで範囲をさらに絞り込んで、「攻撃者がDNSトンネリングを使って機密性の高い財務データを盗み出している可能性がある」に書き換えます。盗み出されることを想定するデータの種類を限定したことで、より現実的な仮説になったと言えます。

次にABLE手法でハンティング方法を具体化します

例：DNS悪用によるデータ窃取をハンティングするときのABLEの使用方法

「PIFFLING PANGOLIN)がDNSトンネリングを使って機密性の高い財務データを盗み出している可能性がある」という仮説を立てたとします(「PIFFLING PANGOLIN」は架空の攻撃グループです)。ABLEフレームワークを使ってこの仮説を以下のように具体化できます。

• 攻撃者(Attack)：財務データは多くのサイバー攻撃者に狙われますが、この仮説ではグループを限定しています。この攻撃グループの典型的な手口を理解することで、既知のC2ドメインや、DNSトンネルに使われるツールなど、ハンティングの手がかりが得られます。

• 挙動(Behavior)：ハンティングする挙動は、DNSトンネリングを介したデータの窃取です。その具体的な戦術に重点を置くことで、調査対象を絞り込み、関連するIoCの検出に集中できます。

• 場所(Location)：仮説から、財務部門が標的になることが想定されます。そこから、ネットワーク内で重点的に調査する必要があるのは、財務データがある財務部門ネットワークと、インターネットを介した流出が起こるネットワーク境界だと判断できます。

• 証拠(Evidence)： DNSトンネリングを検出するには、DNSクエリーのログやパッシブDNSの詳細ログを調べます。サイズが異常に大きいDNSクエリー、やり取りが異常に多いDNSクエリー、普通は使われないDNSクエリータイプ、既知のDNSトンネリングツールで使われるIoCなどを探します。

ABLEが整理できれば、あとは必要なデータソースと検知方法の詳細化ができます

ハンティング仮説にABLEフレームワークを適用すれば、ハンティング計画の要点が明確化になり、実用性が高まります。

• DNSログを収集する：財務部門で使用されるホストのログを収集します(ユーザーのデスクトップ、財務アプリケーションを運用するサーバーなど)。

• サイズが異常に大きいクエリーや応答を探す：これらはDNSトンネリングの典型的なIoCです。

• 「正常」なトラフィックと判断できるDNSレコードタイプを特定する：それに基づいて、異常なレコードタイプを含むクエリーを調査します。

• 既存のDNSトンネリングツールを調査する：同時に、各ツール独自のネットワークアーティファクトやホストアーティファクトも調べます。ツールとそのアーティファクトの検出方法について詳しくは、「Pyramid of Pain (痛みのピラミッド)」を参照してください。

ここまで整理ができるとSplunkのSecurity Contentsで用意されているルールを適用する意義がハッキリしていきます
- Detection: Detection of DNS Tunnels
他にもホワイトペーパー内では、ベースライン脅威ハンティングとモデル支援(M-ATH)ハンティングの説明もありますので詳細は読んでみてください

脅威ハンティングのメトリクス（活動成果のまとめ方）

Threat Hunting業務の見える化
特にHunting実施した回数よりも、Hunting活動によって得られた成果をまとめるのがポイントとのこと
- 行った作業　＜　行った作業の効果

たとえば、前者のメトリクスでわかるのは「今四半期は9回のハンティングを行った」ということであるのに対して、後者では「今四半期は12個の新しい自動検出を本番環境に導入し、以前は見逃していた、クラウドからのデータ窃取アクティビティを検出できるようになった」ということがわかります。

まとめ

米国CISAが中心となってまとめてLoTL対策ガイドラインでもThreat Huntingの必要性や方法論が語られています

ベースラインハンティング、機械学習の利用などが語られています
LoTL対策ガイドについては以下Webinarもご参考ください
- Volt TyphoonによるLoTL（環境寄生型攻撃）嵐への備え ~ 次世代SIEMを使った監視のベストプラクティス ~

HAPPY HUNTING LIFE!!