立ち上げ期の脅威ハンティングプログラムで最もよくある失敗の一つが、明確な仮説を持たないままハントを始めてしまうことです。アナリストはクエリ画面を開き、「異常なネットワークトラフィック」「不審なプロセス」「おかしなログイン」といった漠然としたものを検索し、結果の量に圧倒されるか、あるいは何も出なかったときにそれが環境がきれいだからなのか検索が狭すぎたからなのか判断できないまま終わります。
仮説駆動型のハンティングは、一つひとつのハントを検証可能な命題として扱うことでこれを解きます。すなわち、特定の攻撃者の挙動が自社環境に存在するとしたら、それはどのような具体的な痕跡を残し、それはどこで見つかるのか、という問いです。この枠組みによって、ハンティングは漠然とした探索作業から、範囲が定まり、データソースが明確で、結果がどちらであっても記録できる構造化された調査へと変わります。
良い脅威ハンティング仮説の条件
強い仮説には四つの要素があります。
特定の脅威の挙動を名指ししていること。 漠然と「マルウェア」ではなく、LSASSのメモリアクセスによる認証情報の窃取や、管理者以外が作成したスケジュールタスクによる永続化といった具体的な手法を指します。仮説を検証可能にするのは、この具体性です。曖昧な仮説は曖昧な検索しか生みません。
その挙動の痕跡が現れるデータソースを特定していること。 LSASSからの認証情報窃取を追うハントはエンドポイントのテレメトリ、具体的にはlsass.exeを対象としたプロセスアクセスイベントの中にあります。許可のないOAuthトークン付与を追うハントは、IDプロバイダーの監査ログの中にあります。始める前にデータソースを把握しておくことが、正しい場所を見に行くことを担保します。
その手法の痕跡がどう見えるかを定義していること。 その手法が存在することを示す、具体的なログのフィールド、プロセスの関係性、行動パターンです。これが検知ロジックにあたります。「lsass.exeは動いているか」ではなく（常に動いています）、「システム以外のプロセスが、認証情報の窃取と整合する形でlsass.exeのメモリにアクセスしているか」という問いです。
ベースラインまたはフィルターを含んでいること。 この環境での正常とは何かを定めることで、所見を無差別に拾うのではなく、文脈に照らして評価できるようになります。セキュリティ製品は正当にLSASSへアクセスします。どのプロセスがそうすることを想定されているのかを把握しておけば、所見を想定外のものだけに絞り込めます。
脅威ハンティングの仮説例
範囲についての注記： 以下の例はWindowsとオンプレミスに偏っており、IDプロバイダーを対象としたハントが一つ含まれます。意図的に対象外としたものについては、末尾のカバレッジに関する注記をご覧ください。
以下の例はMITRE ATT&CKのテクニックに紐づけています。それぞれ、対象のテクニック、範囲を定めた反証可能な仮説、主たるデータソース、想定されるベースライン、探すべき主要な指標、終了条件、そして求められる成果物を含みます。
反証可能性について。 ハントの仮説は、それを取り下げる根拠となる結果をあらかじめ明示していなければなりません。ハントを終わらせる結果が存在しないのであれば、行っているのは探索的分析であってハントではありません。それも正当な活動ですが、ハントとして範囲を定め、人員を割き、報告すべきものではありません。以下のすべての仮説が想定ベースラインと終了条件を示しているのは、まさに、何も出なかったという結果を「答えがない」ではなく「本物の答え」にするためです。
いずれを実行する場合でも、その前に、指定したデータソースが対象となる資産群を実際にカバーしていることを検証してください。エージェントのチェックイン率、ハント期間を通じたログ取り込みの連続性、そして実際に軸として使うフィールドの充足度を確認します。テレメトリのカバレッジが60%の状態で実行したハントがゼロ件を返しても、それは何も語っていません。測定したカバレッジは成果物の一部として記録してください。
角括弧で示した値は環境ごとに異なります。ハントを実行する前に必ず埋めてください。
認証情報の窃取、LSASSメモリアクセス（T1003.001）
仮説： [Tier-0およびTier-1資産]上で、許可リストにない一つ以上のプロセスが、メモリ読み取りを許すGrantedAccessマスクでlsass.exeへのハンドルを開いた。これはMimikatz、comsvcs.dllのMiniDump、ProcDump、あるいは独自のインジェクション手法による認証情報の抽出と整合する。
範囲と期間： [Tier-0およびTier-1のWindowsホスト、n=____]。直近[30]日。
データソース： エンドポイントのテレメトリ、具体的にはSysmon Event ID 10（ProcessAccess）またはEDRの同等のプロセスハンドルイベント。GrantedAccessおよびCallTraceフィールドが埋まっていることが前提です。
想定ベースライン： マスクによる絞り込みと除外を適用したあとは、ほぼゼロです。lsassに正当に触れるプラットフォーム側のプロセスとして、csrss.exe、wininit.exe、services.exe、[EDRエージェント名]、WerFault.exe、タスクマネージャー、[バックアップ／DLPエージェント名]など、小さく安定した残りが見込まれます。これらの多くはメモリ読み取りを含まないマスクを要求するため、マスクフィルターで除かれます。ハントの前に残る集合を洗い出して固定しておけば、新たに現れたものが際立ちます。
探すもの： PROCESS_VM_READを付与するGrantedAccessマスク。よく見られるのは0x1010、0x1410、0x143a、0x1438、0x1fffffです。署名の有無やパスではなく、まずマスクで絞り込んでください。現実的な侵入経路は署名済みかつ正当なものだからです。comsvcs.dllのMiniDumpを呼び出すrundll32、ProcDump、WerFault、タスクマネージャー、そして環境寄生型バイナリ全般が該当します。CallTraceの項目が、裏付けのないメモリ領域や、想定外の呼び出し元からのdbghelp.dll・dbgcore.dllに解決される場合は、そこを軸に掘り下げます。加えて、ハンドルを自ら開くのではなく間接的にlsassのハンドルを取得するハンドル複製のパターンと、素朴なProcessAccessフィルターをすり抜けるプロセスクローン（lsassに対するPROCESS_CREATE_PROCESS）も個別に探してください。
既知の死角： SysmonはObRegisterCallbacksを通じてカーネルのオブジェクトコールバックを登録するため、呼び出し元がどのようにカーネルへ到達したかに関係なく、ハンドル生成時にEvent ID 10が発火します。したがって直接システムコールを用いてもこのイベントは抑止されません。それが無効化するのはユーザーランドのインラインフックであり、SysmonではなくEDRの課題です。PPLも同様にイベントを抑止せず、要求されたアクセス権を削ぎ落とします。そのため通常はGrantedAccessの値が小さくなった状態でイベントが残り、それ自体が探す価値のある兆候になります。このハントを実際に盲目にするのは、脆弱なドライバーを悪用したカーネルコールバックの削除（BYOVD）、ノイズを理由にlsassを除外したSysmon設定、そしてエージェントへの改ざんです。ゼロという結果を信じる前に、Sysmonの設定がlsassを除外していないことを確認してください。
終了条件： 対象群全体で除外対象外のヒットがゼロであり、かつSysmon 10のカバレッジが[90]%以上であることが確認できれば、ハントを終了します。ヒットが一件でもあればIRへエスカレーションします。カバレッジが[90]%を下回る場合は、結論保留として終了し、可視性の空白としてチケットを起票します。
成果物： インシデントチケット、検知ルールに反映した正当なlsassアクセスプロセスの許可リスト、影響ホスト一覧を添えたSysmon 10のカバレッジ不足の記録、あるいはGrantedAccessマスクを軸とした新しい検知ルールのいずれか。
スケジュールタスクによる永続化（T1053.005）
仮説： 攻撃者が[対象範囲]内のホスト上で、ペイロードを定期的に実行するスケジュールタスクを作成または改変して永続化を確立した。その際、通常の作成ログや運用者の目を避けるために、リモートからのタスク作成、タスクファイルやレジストリの直接操作、あるいはセキュリティ記述子の削除を用いた。
範囲と期間： [すべてのWindowsサーバーおよびワークステーション、n=____]。直近[30]日。
データソース： エンドポイントのテレメトリ、具体的にはSysmon Event ID 1（プロセス生成）、C:\Windows\System32\Tasksに絞ったSysmon Event ID 11（ファイル作成）、TaskCacheハイブに絞ったSysmon Event ID 13（レジストリ値の設定）およびEvent ID 12（レジストリキーまたは値の削除）、Sysmon Event ID 17および18（名前付きパイプの作成と接続）、そしてWindows Event ID 4698と4702。
想定ベースライン： [パッチ管理、EDR配布、ソフトウェア配信の各アカウント名]による1日あたり[n]件のタスク作成。サービスアカウント以外による作成は1日あたり[n]件を想定します。
テレメトリに関する注記： Event ID 4698と4702は「その他のオブジェクトアクセスイベント」サブカテゴリの有効化を必要とします。これは既定では無効であり、多くの環境で存在しません。Sysmonの11、12、13という軸が効いてくるのはまさにこのためです。C:\Windows\System32\Tasks\にXMLが現れている、あるいはHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\にエントリが現れているのに対応する4698がないタスクは、通常どおり作成されたタスクより弱い兆候ではなく、むしろ強い兆候です。範囲を決める前に、これらのうちどれが実際に手元にあるのかを確認してください。
探すもの： セキュリティ記述子の削除は、最も価値が高く、そして最も見落とされがちな軸です。HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree[タスク名]からSD値を削除すると、そのタスクはschtasksやタスクスケジューラのUIから見えなくなる一方、スケジュールどおりに実行され続けます。これはHAFNIUMに関連づけられるTarrask手法です。SD値を持たないTreeサブキーは誤検知がほぼゼロの指標であり、Sysmon Event ID 12で直接探すべきものです。
作成だけでなく改変も、Event ID 4702を用いて探してください。既存の正当なタスクの向き先を変えるほうが、新規に追加するよりも静かだからです。リモートからのタスク作成は、/sフラグ付きのschtasks.exeとして、あるいはネットワークログオンセッションにたどり着くSysmon 1の親子関係として現れますが、ATSvcインターフェース経由のコマンドライン不要な作成は現れません。その経路を捉えるには、Sysmon 17と18で\PIPE\atsvc上の名前付きパイプの動きを探します。さらに、対応する4698がないままTasksディレクトリへ直接書き込まれたタスクのXMLファイル、TaskCacheのIndexおよびId値への直接書き込み、ユーザーが書き込み可能なディレクトリ（%TEMP%、%APPDATA%、%PUBLIC%、C:\ProgramData配下）の実行ファイルやスクリプトを指すタスク、そしてシステムタスクに似せた名前のタスクを押さえます。非特権ユーザーによるユーザーコンテキストのタスク作成は、多くの環境で件数が多く兆候としては弱いため、上記に比べて優先度を下げてください。
終了条件： ベースライン外のタスク作成および改変がすべて既知の持ち主に紐づけられ、かつTaskCacheのTree列挙でSD値を持たないエントリが出てこなければ、ハントを終了します。帰属が付かないタスクがあればエスカレーションします。4698/4702もSysmon 12/13も対象範囲で利用できない場合は、結論保留として終了し、可視性の空白を起票します。
成果物： インシデントチケット、定期的にタスクを作成する正当なアカウントの補強リスト、オブジェクトアクセス監査の有効化またはSysmon設定のTaskCacheへの拡張を求めるログ変更依頼、あるいは「4698を伴わないタスクファイル」および「SD値のないTreeキー」に対する検知ルールのいずれか。
コマンド＆コントロールのビーコン通信（T1071.001、T1102）
仮説： [対象範囲]内のホストが、機械的な間隔で攻撃者のインフラへ外向き接続を行っている。それは周期性だけでなく接続先によって正当な自動通信と区別できる。二つのテクニックに紐づけているのは意図的です。現在主流の手口は正当なWebサービスを経由してC2を成立させており、これはT1071.001ではなくT1102にあたります。ATT&CKに対するカバレッジを追うハントプログラムであれば、その両方を計上すべきです。
範囲と期間： [ユーザーサブネットおよびサーバーVLANからのすべての外向き通信]。長い間隔のビーコンは短い観測期間では分離できないため、最低でも直近[14]日。
データソース： ネットワークのフローデータ、または接続時刻・送受信バイト数・接続先を含むプロキシおよびファイアウォールのログ。後述するプロセスと接続先を突き合わせる軸はフローデータだけでは成立せず、Sysmon Event ID 3またはEDRのネットワークテレメトリを必要とします。この依存関係を明示的に範囲に含めるか、その軸を落とすかを決めてください。
想定ベースライン： どの企業環境でも、完全に周期的な外向き通信の圧倒的多数は正当なものです。EDRやテレメトリのエージェント、OSやアプリケーションの更新確認、SaaSのハートビート、監視プローブ、NTP、証明書失効確認などが含まれます。絞り込み前の周期的な接続先の組は[数千]件規模を見込んでください。既知の自動通信先リストをまず作成して差し引かなければ、このハントは実行不能です。
探すもの： ばらつきの小ささを検出の決め手にしてはいけません。現行のC2フレームワークはいずれも設定可能なジッターを備えており、分散のしきい値ではおおむね20%を超えて調整されたものを取り逃がします。代わりにジッターに強い手法を使ってください。到着間隔の中央絶対偏差、接続時系列の自己相関、あるいは間隔分布に対するFFTによって、ランダム化された間隔の下に潜む支配的な周波数を浮かび上がらせます。
観測期間だけでなく、最小サンプル数も定めてください。周波数領域の手法にはデータ点が必要で、24時間間隔のビーコンは14日間で14回しか観測されず、自己相関やFFTには足りません。周波数解析を適用する前に、接続先の組ごとに[30]回以上の接続を必須とし、サンプル数の少ない組は、タイミングの計算ではなく初出や希少性のロジックで別系統として扱ってください。そのうえで、リクエストサイズの規則性（ビーコンのチェックインはタイミングがばらついていても送信バイト数は密に集まります）と、セッション数に対するデータ量の比率を重ねます。
接続先のレピュテーションは、現在の手口に対しては弱いフィルターです。主流のC2は、Slack、Discord、Telegram、Google Drive、OneDrive、GitHub、Pastebin相当のサービス、そしてCDNやドメインフロンティングを用いたエンドポイントといった、評価の高い正当なインフラに相乗りします。新規登録ドメインやDGAのパターンも確認する価値はありますが、支配的なケースは捕まえられません。より価値が高いのは、企業として初めて観測された接続先、ただ一台のホストだけが接続している先、TLSフィンガープリントの希少性、そしてそのホストの役割から見て不自然なプロセスと接続先の組み合わせです。フィンガープリントにはJA3よりJA4を用いてください。ChromeがClientHelloの拡張順序を入れ替えるようになって以降、JA3は大きく劣化し、同一クライアントでもセッションごとに値が安定しなくなっています。
終了条件： 自動通信の差し引き後に残った周期的な接続先の組が、すべて名前の付いたアプリケーションに帰属するか、エスカレーションされていること。帰属不明の組がゼロであればハントを終了します。
成果物： インシデントチケット、拡充した既知の自動通信先の許可リスト、残ったビーコン判定ロジックに基づく新しい検知ルール、あるいは外向き通信のログ取得の不足を記録したもののいずれか。
WMIによるラテラルムーブメント（T1047）
仮説： 攻撃者が[対象範囲]内のリモートホスト上で、Windows Management Instrumentationを用いてプロセスを実行した。その際、正規の管理システムではない送信元ホストから、正当な管理機能を悪用した。
範囲と期間： [すべてのWindowsサーバー、n=____]。直近[30]日。
データソース： エンドポイントのテレメトリ、具体的には対象ホスト上のプロセス生成を示すSysmon Event ID 1またはWindows Security Event ID 4688、ネットワーク接続を示すSysmon Event ID 3、そして有効化されている場合はMicrosoft-Windows-WMI-Activity/Operational Event ID 5857（プロバイダーのロード）。RPCについてはネットワークのフローデータ。
イベントIDに関する訂正： Sysmon Event ID 19、20、21はそれぞれWmiEventFilter、WmiEventConsumer、FilterToConsumerBindingです。これらはWMIのイベントサブスクリプションによる永続化を記録するもので、T1546.003という別のテクニックであり、仮説も異なります。WMI-ActivityのEvent ID 5860と5861も同様で、一時的および恒久的なイベントコンシューマーの登録を記録するものであり、このハントではなく永続化のハントに属します。これらをリモート実行の目的で探しても何も出ず、誤った「異常なし」を生みます。リモートWMI実行は、WmiPrvSE.exeを親とするプロセス生成として現れます。
想定ベースライン： [管理サーバー名、SCCM基盤、監視プラットフォーム]を起点とするWMI由来のプロセス生成が1日あたり[n]件。それ以外の送信元からは0件を想定します。
探すもの： 親プロセスがWmiPrvSE.exeであり、かつ開始元ホストが正規の管理システム一覧に載っていないプロセス生成イベント。TCP 135への着信接続と、その直後に同一送信元から張られるエフェメラルな高位ポートのセッションを突き合わせます。対象ホストの役割から見て不自然な、WMI由来の子プロセスを優先してください。データベースサーバーやドメインコントローラー上でWmiPrvSEがPowerShell、cmd.exe、rundll32.exe、regsvr32.exeを起動していれば、送信元ホストが何であれ注目に値する異常です。あわせて、対象ホスト自身のイベントログに、直前に同じ送信元からのType 3ログオンが記録されているWMI実行も確認します。
別途実施する価値のある隣接ハント： Sysmonの19、20、21とWMI-Activityの5860、5861を用いた、WMIイベントサブスクリプションによる永続化（T1546.003）。CommandLineEventConsumerやActiveScriptEventConsumerのバインディングを探します。特定の管理ツールを除けば、これらが正当である場合はほとんどありません。
終了条件： WmiPrvSEを親とするすべての実行が、正規の送信元と既知の管理業務に帰属することが確認できればハントを終了します。帰属が付かない実行があればエスカレーションします。
成果物： インシデントチケット、正当なWMI管理元を記録した許可リスト、管理システム以外を送信元とするWmiPrvSE由来のプロセス生成に対する検知ルール、あるいはWMI-Activityのログ有効化依頼のいずれか。
許可されていないOAuthアプリケーションへの同意付与（T1528）
仮説： [テナント]内でユーザーの認証情報を入手した攻撃者が、悪意のあるアプリケーション、あるいは攻撃者が管理するOAuthアプリケーションへの同意付与を誘導または実行し、パスワードのリセットやMFAの再登録を経ても失われないクラウドリソースへのアクセスを獲得した。
範囲と期間： [Entra ID／Okta／Google Workspaceのテナント、全ユーザー]。OAuthによる永続化は長く生き残り、短い観測期間では最初の付与を取り逃がすため、直近[90]日。
データソース： IDプロバイダーの監査ログ。同意とアプリケーションに関するイベントが必要です。具体的には、Entra IDの「アプリケーションへの同意」「委任されたアクセス許可の付与の追加」「ユーザーへのアプリロール割り当ての付与の追加」「OAuth2PermissionGrantの追加」、Oktaのシステムログにおけるapplication.user_membershipおよびapp.oauth2.*のイベント、あるいはGoogle Workspaceのトークン監査ログです。
保持期間に関する警告： Entra IDの監査ログとサインインログの保持期間は、無償版で7日、P1またはP2で30日です。90日の観測期間が実行できるのは、診断設定によってこれらのログをLog Analytics、Sentinel、または同等のストレージへすでにエクスポートしている場合に限られます。このハントの範囲を決める前にエクスポートの設定と過去分の取り込みを確認するか、実際の保持期間まで窓を縮めて、その結果生じる空白を記録してください。Oktaはシステムログを90日、Google Workspaceは6か月保持するため、どちらもこの期間をそのまま扱えます。
想定ベースライン： 週あたり[n]件の同意付与。うち[n]件は承認済みカタログ上のアプリケーションに対するもの。
探すもの： 付与のタイミングではなく、危険なスコープの組み合わせです。offline_accessとMail.ReadまたはMail.ReadWriteの併用、Files.ReadWrite.All、full_access_as_user、Directory.ReadWrite.All、RoleManagement.ReadWrite.Directory、Application.ReadWrite.Allを優先してください。AppRoleAssignment.ReadWrite.AllとApplication.ReadWrite.Allの組み合わせは独立したルールを設ける価値があります。この二つが揃うと、アプリケーションが追加の同意なしに自らへ権限を付与し、グローバル管理者へ昇格できてしまうためです。
あわせて、発行元が未検証のアプリケーション、テナント内で初めて観測されたアプリケーションID、そして同意したユーザーの役割から見て要求されたスコープが妥当とは考えにくい付与を探します。業界横断で[5]テナント未満にしか出現しないアプリケーションIDという普及度の観点は強力な軸ですが、Microsoft Defender for Cloud Appsのアプリガバナンス、あるいは同等の第三者データセットを必要とします。そのテレメトリがない場合は、テナント内での初出に置き換え、普及度の基準は空欄のままにせず外してください。
業務時間外という付与のタイミングは、それ単体では弱い兆候です。付与はもともと件数が多く自動化されていることも多いためです。あくまで二次的な順位付けの材料として使ってください。
終了条件： 観測期間内のすべての付与が、名前の付いた持ち主と記録された業務目的に帰属すればハントを終了します。帰属が付かない付与があればエスカレーションします。
成果物： インシデントチケット、承認済みアプリケーションカタログの更新、条件付きアクセスまたは管理者同意ワークフローのポリシー変更、あるいは高リスクなスコープの組み合わせに対する検知ルールのいずれか。
既存のサービスプリンシパルへの認証情報の追加（T1098.001）
仮説： 攻撃者が[テナント]内の既存かつ承認済みのサービスプリンシパルまたはアプリケーション登録に、クライアントシークレット、証明書、またはフェデレーション資格情報を追加し、ユーザーのパスワードリセット、MFAの再登録、トークンの失効、そして多くのインシデント対応を経ても残る認証の永続化を確立した。
これを前項の同意付与のハントと分けているのは、データソースが異なり、ベースラインが異なり、対応上の意味合いも大きく異なるからです。そして二つのうち見落とされやすいのはこちらです。関係するアプリケーションが正当で事前に承認されているため、アイデンティティまわりに新しく見えるものが何もないからこそ、そうなります。
範囲と期間： [テナント内のすべてのサービスプリンシパルおよびアプリケーション登録]。直近[90]日。前項と同じ保持期間の注意が当てはまります。
データソース： IDプロバイダーの監査ログ。Entra IDでは「サービスプリンシパルの資格情報の追加」「アプリケーションの更新」「アプリケーションの更新 - 証明書とシークレットの管理」が該当します。フェデレーション資格情報の追加は「アプリケーションの更新」として現れるため、操作名だけでなく変更されたプロパティを確認する必要があります。
想定ベースライン： サービスプリンシパルへの資格情報追加は、[自動化および証明書ローテーションの処理名]から月あたり[n]件。フェデレーション資格情報の追加は、[CI/CDのワークロードID設定名]から四半期あたり[n]件。この二つの集合から外れるものはすべて調査対象です。
探すもの： 記録されたローテーション計画に帰属しない、サービスプリンシパルへの資格情報または証明書の追加すべて。前項で挙げた高権限スコープを保持するアプリケーションへの追加、普段アプリケーションを管理していないアカウントによる追加、そして資格情報の有効期間が異常に長い追加を優先してください。
フェデレーション資格情報には独立したルールを設けるべきです。外部の発行者がテナント内にシークレットを一切持たずにサービスプリンシパルのトークンを取得できてしまうため、シークレットと証明書だけを監査している防御側からは見えません。すべてのフェデレーション資格情報について、発行者とサブジェクトの値を、実際に運用しているCI/CDシステムと突き合わせて確認してください。
終了条件： 観測期間内のすべての資格情報およびフェデレーション資格情報の追加が、名前の付いた持ち主と、記録されたローテーションまたはワークロードIDの目的に帰属すること。帰属が付かない追加は、永続化の含意を踏まえ、直ちにエスカレーションします。
成果物： インシデントチケット、正当な資格情報の持ち主とローテーション計画を含むサービスプリンシパルの台帳、アプリケーションの資格情報を追加できる者を制限するポリシー変更、あるいはサービスプリンシパルの資格情報およびフェデレーション資格情報の追加に対する検知ルールのいずれか。
持ち出し前のデータ集約（T1074、T1560）
仮説： 攻撃者が[対象範囲]内で、持ち出しに先立ち、複数のソースからデータを一か所に集約している。集約先はローカルのディレクトリ、アーカイブファイル、あるいは攻撃者が管理するクラウドストレージのいずれか。
範囲と期間： [ファイルサーバー、機微な共有にアクセスできるエンドポイント、監視対象のSaaSストレージ]。直近[30]日。
データソース： エンドポイントのテレメトリ（Sysmon Event ID 11のファイル作成、ツール実行を捉えるSysmon Event ID 1、EDRのファイルイベント）、DLP、そしてクラウドの監査ログ（SharePoint、OneDrive、Google Drive、S3のアクセスログ）。
想定ベースライン： 対象範囲全体で、[バックアップおよびパッケージングのツール名]による1日あたり[n]件のアーカイブ作成イベント。ユーザーあたり1時間[n]件を超える大量のファイルアクセスは[アカウント名／システム名]からのみ想定されます。サーバー上での持ち出しユーティリティの実行は0件です。
探すもの： アーカイブの作成は最も兆候として強く、そして多くの集約ハントから抜け落ちている指標です。.rar、.7z、.zip、.cab、.tarファイルの作成を探してください。とりわけパスワード保護されたアーカイブ、とりわけrar.exe、7z.exe、あるいは紛れ込ませるために改名されたWinRAR系バイナリによるもの、そしてとりわけ%TEMP%、%APPDATA%、C:\ProgramData、ごみ箱のパス配下に作られたものです。作成したユーザーの履歴に比して異常に大きいアーカイブは、優先度を上げる価値があります。
拡張子による突合だけでは、ツールとその出力の両方が改名されているという典型的なケースを取り逃がします。使用中のツールが内容の検査に対応しているなら、ディスク上の拡張子にかかわらず、ファイルのマジックバイトで探してください。Rar!のシグネチャ、zipのPK、7-Zipの7zを確認します。
あわせて、本来そのようなものを動かす理由のないホスト上での転送ユーティリティの実行を加えます。ファイルサーバーやドメインコントローラー上に現れるRclone、MEGAsync、FileZilla、WinSCPは、ランサムウェアの侵入において集約から持ち出しへ至る最も兆候の強い指標の一つであり、アーカイブ作成の後ではなく前に現れることが少なくありません。特にRcloneは改名されていることが多いため、ファイル名によるハントと、特徴的なフラグを狙ったコマンドラインのハントを組み合わせてください。
さらに、単一のディレクトリへ集まっていく異常な量のコピーおよび移動操作を、財務、人事、ソースコード、顧客情報といった機微なデータ区分に該当する文書種別に重みを置いて探します。通常の担当範囲や通常の時間帯の外でファイル共有にアクセスしているアカウント、そしてエンドポイントのファイルシステムを一切経由しないクラウド内での集約も対象です。後者には、SharePointやDrive内での一括ダウンロードやサーバー側コピー、新規作成または外部共有されたバケットやフォルダーへの書き込みが含まれます。集約の動きがあった後[72]時間の外向き転送量と突き合わせてください。
終了条件： すべての大量アクセス、アーカイブ作成、転送ユーティリティの実行が、既知の業務プロセスに帰属すればハントを終了します。帰属が付かない集約パターンがあればエスカレーションします。
成果物： インシデントチケット、正当な大量アクセスのアカウントとアーカイブツールのベースライン、DLPポリシーの調整、あるいはユーザーが書き込み可能なパスでのパスワード保護アーカイブの作成と、ホストの役割に照らした転送ユーティリティの実行に対する検知ルールのいずれか。
列挙による探索（T1087、T1018）
仮説： [対象範囲]内で初期アクセスを得た攻撃者が、侵害後の初期段階に典型的な、システム、アカウント、ドメインに関する探索活動を短時間に集中して実行した。その手段はコマンドラインのツール、LDAPクエリ、ADWSクエリ、あるいはプロセス内のAPI呼び出しである。
範囲と期間： [すべてのWindowsサーバーおよびワークステーション、ならびにすべてのドメインコントローラー]。直近[30]日。
データソース： エンドポイントのテレメトリ（コマンドライン引数を含むプロセス実行）、ドメインコントローラーのディレクトリサービスログ（Event ID 1644）、LDAPクエリのログ、そしてTCP 9389に関するネットワークテレメトリ。
1644に関する注記： このイベントには、一つではなく二つの設定変更が必要です。HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnosticsの下でField Engineeringの診断レベルを5に設定し、そのうえでNTDS\Parametersキーの下のSearch Time Threshold (msecs)、Expensive Search Results Threshold、Inefficient Search Results Thresholdを引き下げます。診断レベルだけを上げてしきい値を既定のままにすると、ほとんど何も記録されず、テレメトリが揃っていると誤って結論づけることになります。頼りにする前に既知のテストクエリで検証してください。また、しきい値を過度に下げることは、負荷の高いドメインコントローラーでは相応のコストになる点にも留意してください。
想定ベースライン： 探索コマンドの集中実行は[管理者アカウント名および踏み台ホスト名]から週あたり[n]件。サーバー役割のホストおよび管理者以外のワークステーションからは0件を想定します。ADWSへの接続は[AD PowerShellモジュールを実行する管理ホスト名]からのみ想定されます。
探すもの： 単一のプロセスまたはシェルセッションから短時間のうちに連続して実行される探索コマンド。net user、net group、net localgroup、whoami、ipconfig、nltest、systeminfo、arp、quser、tasklistなどです。アナリストのワークステーションからのnet user一回は正常ですが、サーバー上で90秒以内に五つの探索コマンドが走るのは正常ではありません。個々のコマンドの有無ではなく、集中の密度とホストの役割でしきい値を設けてください。
既知の死角、そしてこのハントだけでは不十分な理由： 成熟した攻撃者は、コマンドラインによる列挙からおおむね離れています。SharpHound、LDAPやADSIの直接クエリ、.NETのリフレクション、プロセス内でのBOF実行は、プロセスを生成せずに同じ探索を行うため、探すべきコマンドラインが残りません。このハントには、単一の送信元からの異常なクエリ量、大量のオブジェクトを取得するクエリ、そしてBloodHound系の収集ツールが用いる特徴的なフィルターパターンを対象とする、LDAP側の検知を組み合わせてください。
LDAPを押さえてもなお穴が残ります。TCP 9389のActive Directory Web ServicesはSOAP経由で同じディレクトリ情報を露出させ、その経路での収集はLDAPのクエリログをまったく生成しません。SOAPHoundもMicrosoftのAD PowerShellモジュールも、これを使います。このハントに三つ目の柱として、正規の管理システム一覧に載っていないホストからのADWS接続を、ネットワークテレメトリまたはポート9389に絞ったSysmon Event ID 3で押さえてください。多くの環境でまるごと抜け落ちているのが、この軸です。
終了条件： すべての探索コマンドの集中実行が、名前の付いた管理者または自動棚卸し処理に帰属すれば、コマンドラインの柱は終了します。LDAPの柱は、異常なクエリ送信元の帰属が付いた時点で終了します。ADWSの柱は、9389のすべての送信元が正規の管理システム一覧に載っていることが確認できた時点で終了します。LDAPのログや9389の可視性がない場合は、部分的な終了として、対応する空白を起票してください。
成果物： インシデントチケット、正当な探索コマンドおよびADWSの送信元のベースライン、LDAP診断ログの有効化依頼、あるいはホストの役割ごとに範囲を定めた集中密度に対する検知ルールのいずれか。
カバレッジに関する注記： この一式はWindowsとオンプレミスに偏っており、IDプロバイダーを対象としたものが一組含まれます。ESXiやハイパーバイザーへの攻撃、Kubernetesやコンテナからの脱出、LinuxやmacOS、CI/CDとサプライチェーン、SaaS間のラテラルムーブメント、メールを起点とする初期アクセスは対象外です。また、ここで示しているのはテクニック起点のハンティングのみです。インテリジェンス起点、重要資産起点、異常検知起点のハントはそれぞれ異なる構造を持つため、別途文書化する価値があります。
脅威ハンティングの仮説プログラムを組み立てる
これらの例は、MITRE ATT&CKフレームワークのどのテクニックにも当てはめられる共通の構造を持っています。テクニック名、仮説の記述、データソース、探すべき指標、そして絞り込みの基準となるベースラインの文脈です。
仮説プログラムを組み立てる実務的な進め方は、カバレッジの空白から始めることです。MITRE ATT&CKに対してカバレッジ評価を行い、現在どのテクニックに検知が効いていて、どこが見えていないのかを洗い出します。既存の検知ルールがなく、かつ実際の攻撃で相応に使われているテクニックが、ハンティング仮説の最優先候補になります。
AI支援型の脅威ハンティングプラットフォームは、この工程の一部を自動化できます。ATT&CKのカバレッジ分析と最近の脅威インテリジェンスに基づいて仮説の候補を提示し、裏側のクエリを生成し、仮説の条件に合致する異常を、アナリストがすべての検索をゼロから書かなくても検出します。仮説のライブラリそのものは、その環境にとって何が最も重要かという人間の判断から生まれます。ツールが速めるのは実行の部分です。
このワークフローの変化はvibe huntingと呼ばれることがあります。アナリストが仮説を与え、機械的な実行、すなわちクエリの生成、複数ソースのテレメトリのつなぎ合わせ、所見の提示をAIが担うモデルです。その結果、仮説駆動型のハンティングは実行が速くなり、すべてのデータソースで深いクエリの知識を持つ人だけのものではなくなります。
完了したハントは、結果にかかわらず記録すべきです。何も出なかったハントであっても、設計がよければ価値があります。カバレッジを示すものとなり、特定のテクニックを能動的に探したという、コンプライアンスや監査のための証跡になるからです。ディテクションエンジニアリングはこのループを支え、ハントで得られた肯定的な所見を正式な検知ルールへと変換します。それによってカバレッジは持続的なものとなり、定期的にハントをやり直す必要がなくなります。
IBMの2026年 データ侵害のコストに関する調査によれば、外部からの通知ではなく自ら侵害を見つけられた組織、すなわち強い検知能力を持つ組織は、侵害にともなうコストが大幅に低く抑えられていました。仮説駆動型のハンティングは、その内製の検知能力をテクニック単位で体系的に積み上げていく、最も直接的な方法の一つです。