はじめに
- 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は2015年にSqrrl社が提唱した仮説検証型アプローチを中心としたフレームワークです
- 2018年にAWSに買収されてから今日までアップデートはありませんでした
- そのことについてDaivdが2024/6のRSAカンファレンスで謝罪しています
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で用意されているルールを適用する意義がハッキリしていきます
-
他にもホワイトペーパー内では、ベースライン脅威ハンティングとモデル支援(M-ATH)ハンティングの説明もありますので詳細は読んでみてください
脅威ハンティングのメトリクス（活動成果のまとめ方）
- Threat Hunting業務の見える化
- 特にHunting実施した回数よりも、Hunting活動によって得られた成果をまとめるのがポイントとのこと
- 行った作業 ＜ 行った作業の効果
たとえば、前者のメトリクスでわかるのは「今四半期は9回のハンティングを行った」ということであるのに対して、後者では「今四半期は12個の新しい自動検出を本番環境に導入し、以前は見逃していた、クラウドからのデータ窃取アクティビティを検出できるようになった」ということがわかります。
まとめ
- 米国CISAが中心となってまとめてLoTL対策ガイドラインでもThreat Huntingの必要性や方法論が語られています
- ベースラインハンティング、機械学習の利用などが語られています
- LoTL対策ガイドについては以下Webinarもご参考ください