スレットハンティングのネタ切れ解決策｜IOC依存から仮説（IOB）ベースへ移行する実践ガイド

スレットハンティングとは、セキュリティ製品による自動検知をすり抜けて組織内に潜伏している可能性のある未知の脅威を、プロアクティブ（能動的）に探し出す活動のことです。インシデントの発生を待つのではなく、攻撃者の存在を前提として、その痕跡を積極的に見つけ出し、被害を未然に防ぐ、あるいは最小化することを目的とします。

多くの組織でスレットハンティングが導入されていますが、その運用が形骸化し、「ネタ切れ」に陥るケースは少なくありません。その根本的な原因は、多くの場合「IOC（Indicators of Compromise）」に過度に依存した運用体制にあります。

IOC、すなわち「侵害の痕跡」とは、IPアドレス、ドメイン名、ファイルのハッシュ値といった、過去にサイバー攻撃で観測された静的な指標です。脅威インテリジェンスから提供されるIOCリストを自社のSIEMやEDRに入力し、ログと照合するのが典型的な手法です。

この手法は既知の脅威の検出には有効ですが、本質的には「過去に起きたこと」を後追いで調査しているに過ぎません。これは攻撃者が残した「点」の情報を探すアプローチであり、非常に受動的なセキュリティ運用と言えます。攻撃者は常にIOCを変化させるため、このアプローチだけでは限界があります。

近年のサイバー攻撃は高度化・巧妙化しており、攻撃者は自身の活動を隠蔽するために、IOCを頻繁に変更します。

• C2サーバーのIPアドレスを次々と変更する
• ハッシュ値が毎回異なるポリモーフィック型・メタモーフィック型マルウェアを使用する
• ファイルレスマルウェアのようにディスクに痕跡を残さずメモリ上のみで活動する
• PowerShellなどOS標準ツールを悪用する「環境寄生型（Living off the Land）」攻撃

これらの攻撃は明確なIOCを残しにくいため、後追いのアプローチでは攻撃が深刻化するまで気づけないリスクが高まります。

IOCリストとのマッチング作業は、単純なルーチンワークになりがちです。毎日膨大なIOCをチェックしても、ほとんどが空振りに終わることも珍しくありません。このような状況が続くと、セキュリティアナリストはモチベーションの低下に繋がります。

結果として、スレットハンティングは「何かを見つけるための能動的な活動」ではなく、「IOCリストをチェックするだけのタスク」へと形骸化してしまうのです。これが、多くの現場で聞かれる「ネタ切れ」の正体です。

IOC依存の限界を克服し、スレットハンティングを次のレベルへ引き上げる鍵、それが「IOB（Indicators of Behavior）」、すなわち「振る舞いの痕跡」に着目したアプローチです。

IOBとは、攻撃者が目的を達成するために実行する一連の行動やそのパターンを指します。IOCが攻撃の「結果」として残る静的なアーティファクト（点）であるのに対し、IOBは攻撃の「プロセス」で観測される動的な振る舞い（線）です。

• IOCの例: 不審なIPアドレス 198.51.100.10
• IOBの例: PowerShellが、普段は通信しない海外のIPアドレス(198.51.100.10)に対し、暗号化された通信を定期的に開始した

IOCが「What（何）」に焦点を当てるのに対し、IOBは「How（どのように）」に焦点を当てる点が決定的な違いです。

攻撃者は使用するツールやIPアドレス（IOC）を容易に変更できますが、その目的（情報窃取、ランサムウェア展開など）を達成するための一連の行動パターン（IOB）を大きく変えることは困難です。

攻撃の大きな流れ（侵入→権限昇格→横展開→情報窃取）は、使用するツールが変わっても本質的には同じです。この「振る舞い」に着目することで、未知のマルウェアやゼロデイ攻撃など、IOCベースでは検出困難だった脅威の兆候を捉えることが可能になります。

IOBを検出するためには、まず「攻撃者であれば、このような振る舞いをするのではないか？」という「仮説」を立てることが出発点となります。これが「仮説ドリブン・スレットハンティング」です。

例えば、「攻撃者は持続化のため、レジストリのRunキーに不正なプログラムを登録するだろう」という仮説を立てます。そして、その仮説を検証するためにEDR等のログを分析し、「予期せぬプロセスの登録」といった振る舞いの痕跡（IOB）を探します。この仮説検証のプロセスこそが、スレットハンティングを能動的で知的な活動へと変え、アナリストのスキルアップにも繋がるのです。

「仮説を立てろと言われても、何から手をつければいいのか分からない」という場合に強力な武器となるのが、サイバー攻撃の戦術や技術を体系的にまとめたフレームワーク「MITRE ATT&CK」です。

MITRE ATT&CKは、サイバー攻撃者が用いる戦術（Tactics）、技術（Techniques）、手順（Procedures）をまとめたナレッジベースです。偵察から初期アクセス、持続化、権限昇格、横展開、情報窃取に至るまで、攻撃のライフサイクルがマトリックス形式で整理されています。

このフレームワークは、攻撃者の行動を理解するための共通言語として機能し、スレットハンティングの仮説を立てる際の強力な羅針盤となります。

ATT&CKのマトリックスは膨大ですが、すべてを一度にハンティングする必要はありません。自組織の環境やビジネスリスクを考慮し、優先順位をつけることが重要です。

• 例1: 重要な顧客情報を扱うDBサーバーがある場合、「データ暗号化によるインパクト（T1486）」や「外部へのデータ持ち出し（T1567）」の優先度が高くなります。
• 例2: 業界で流行している攻撃グループのレポートを参考に、彼らが多用するTTP（戦術、技術、手順）に焦点を当てるのも効果的です。

脅威インテリジェンスを活用し、自組織が標的となる可能性の高い攻撃手法を分析することで、ハンティングの仮説はより現実的になります。

MITRE社が提供する無料ツール「ATT&CK Navigator」を使えば、ATT&CKマトリックスを視覚的に操作できます。対策済みの技術を色分けしたり、特定の攻撃グループが使う技術をハイライトしたり、ハンティング対象に優先度を付けたりすることが可能です。

このツールを活用して、SOCチーム内で「今週はこのTTP（例: T1059.001 PowerShell）に関する仮説を立ててハンティングしよう」といった具体的な計画を立て、進捗を可視化できます。

ここからは、MITRE ATT&CKの主要な戦術に基づいたハンティングの「仮説テンプレート」を質問集形式でご紹介します。これらの質問を起点に、自社のEDRやSIEMのログをどう分析するか、具体的な調査クエリを組み立ててみましょう。

仮説：攻撃者がOSの脆弱性や設定不備を悪用し、一般ユーザーから管理者（SYSTEM/root）権限を取得しようとしているのではないか？

質問リスト：

• 通常では考えられないプロセス（例: notepad.exe）がSYSTEM権限で動作していないか？
• 特権アカウントのパスワード変更やグループ追加が、承認された変更管理プロセス外で行われていないか？
• Sudoersファイルやsudoコマンドのログに、正当な理由のない編集や、一般ユーザーによる特権コマンド実行履歴はないか？ (Linux)
• UAC（ユーザーアカウント制御）バイパスを試みるような挙動（特定のWindowsプロセスからの予期せぬ子プロセスの生成など）はないか？
• Sticky Keysなど、アクセシビリティ機能を悪用した権限昇格の兆候（関連レジストリキーの変更など）はないか？

仮説：攻撃者が正規のリモート管理ツールやプロトコルを悪用し、他の端末へ認証情報を使いまわして侵入を試みているのではないか？

質問リスト：

• 管理者共有（C$, ADMIN$）へのアクセスが、IT管理者ではない一般ユーザーの端末から、または業務時間外に発生していないか？
• PsExecやPowerShell Remoting、WMIといったリモート実行ツールが、正規の用途以外で異常な頻度・態様で使用されていないか？
• RDP接続ログにおいて、短時間に多数のホストへの接続試行や、失敗と成功を繰り返す不審なログインパターンはないか？
• ドメインコントローラーのセキュリティログに、Kerberoasting等に繋がるイベント（イベントID 4769など）が記録されていないか？
• ネットワークセグメントを越えた、通常ではありえない通信（例：開発セグメントから経理セグメントへのSMB通信）は発生していないか？

仮説：攻撃者がOSの自動実行機能を悪用し、不正なプログラムやスクリプトを登録して潜伏を試みているのではないか？

質問リスト：

• レジストリのRun/RunOnceキーに見慣れないプログラムや難読化されたコマンドが登録されていないか？
• スタートアップフォルダに、正規インストーラ以外によって作成された不審なファイルやショートカットはないか？
• スケジュールタスクに、発行元が不明、またはSYSTEM権限で異常なタイミング（例: 毎分実行）で起動するタスクが登録されていないか？
• WMIイベントサブスクリプションに、特定のイベントをトリガーとして悪意のあるスクリプトを実行するような不審な設定はないか？
• 正規サービスに偽装した悪意のあるサービス（例: svchost.exeという名前だがパスが異なる）が登録・実行されていないか？

これらの仮説と質問リストを手にしたら、次に行うのは実際のデータ分析です。効果的なIOBハンティングには、適切なデータソースとその分析能力が不可欠です。

仮説を検証するには、エンドポイントやネットワークで何が起きているかを詳細に記録した「テレメトリーデータ」が必要です。

• EDR (Endpoint Detection and Response): プロセス生成、コマンドライン、ファイル操作、レジストリ変更、ネットワーク接続など、エンドポイントの詳細な挙動ログ。IOBハンティングの最重要データソースです。
• SIEM (Security Information and Event Management): ファイアウォール、プロキシ、Active Directoryなど多様なソースからログを収集・相関分析するプラットフォーム。
• XDR (Extended Detection and Response): EDRを拡張し、エンドポイント、ネットワーク、クラウド、メールなど複数レイヤーのデータを統合・分析するソリューション。

膨大なログから意味のあるIOBを見つけ出すには、データの関連性を分析する視点が重要です。

1. ベースラインの理解： まずは「正常な状態」を理解しましょう。平時にどのようなプロセスがどのような通信を行っているかを知ることで、「異常」を際立たせることができます。
2. イベントの関連付け： 一つのイベントだけでなく、複数のイベントを時系列で結びつけて「ストーリー」として考えます。「PowerShellが起動し（イベント1）→外部IPへ接続し（イベント2）→レジストリを書き換えた（イベント3）」といった一連の流れを追うことで、攻撃のシナリオが見えてきます。

仮説ドリブンハンティングは、一度きりのイベントで終わらせず、セキュリティ運用のプロセスに組み込み、継続的に改善していくことが重要です。

どのような仮説に基づき、何を調査し、何が発見できたか（あるいは何も見つからなかったか）を必ず記録に残しましょう。「何も見つからなかった」という結果も、「その仮説の範囲では、我々の環境はクリーンであった」という重要な知見です。定期的なミーティングで結果を共有し、次の計画を議論することで、チーム全体のスキルが向上します。

ハンティングで新たな脅威のIOBを発見した場合、それをSIEMやEDRのカスタム検出ルールとして実装し、今後の自動検出に繋げましょう。これにより、ハンティング活動がセキュリティ運用全体のレベルアップに直接貢献します。また、インシデントの兆候を発見した場合は、速やかにインシデントレスポンスプロセスへエスカレーションする体制を整えておくことも不可欠です。

仮説ドリブンハンティングは、アナリストに攻撃者の視点を持つことを要求する、知的好奇心を刺激する活動です。組織として、アナリストがATT&CKを学んだり、新しい分析手法を試したりする時間を確保し、その挑戦を評価する文化を醸成することが、プロアクティブなセキュリティ体制を構築する上で最も重要です。

本記事では、スレットハンティングにおける「ネタ切れ」問題を解決するため、従来のIOC依存から、攻撃者の振る舞い（IOB）に着目した仮説ドリブンなアプローチへの移行を提案しました。

IOCベースのハンティングは受動的になりがちですが、仮説を立ててIOBを探すアプローチは、未知の脅威にも対抗しうるプロアクティブなセキュリティ運用を実現します。ご紹介した質問集は、明日からのハンティング活動で即使えるはずです。

まずは一つの仮説からでも構いません。自組織の環境に潜むサイバー攻撃の兆候を探すという、価値ある一歩を踏み出しましょう。