【中級〜上級者向け】gkape/KAPE 徹底活用ガイド|カスタムTarget・Module作成からバッチ自動化・SIEM連携まで

解析

KAPEの基本操作をひと通り習得した方へ向けて、本記事では カスタムTarget・Moduleの作成、フラグの詳細制御、複数端末への一括展開、Timeline Explorerを超えた可視化手法、SIEM・SplunkへのCSV取り込みパイプライン まで、実務で差がつくテクニックを体系的に解説します。


1. KAPEのアーキテクチャを深く理解する

1-1. Target処理の内部フロー

gkapeを使い込むには、裏側で何が起きているかを把握しておくことが重要です。kape.exeがTargetを処理する際のフローは以下の通りです。

  1. 解析フェーズ:指定した .tkape ファイルを読み込み、Path・FileMask・Recursive の各フィールドからコピー対象のルールセットを構築する
  2. ロック回避フェーズ:VSS(ボリュームシャドウコピー)経由、またはRawコピーエンジンを使って、OSがロックしているファイル(イベントログ、NTUSERなど)を直接読み取る
  3. コピーフェーズ:ファイルを Target destination に元のフォルダ構造を維持した形でコピーし、ソースのMACタイムスタンプをそのまま保持する
  4. ハッシュ記録フェーズ--hash フラグが有効な場合、MD5/SHA-1/SHA-256をコピー後に記録し、整合性証明のためのCSVを生成する

Module処理は Target とは完全に独立しており、Module source に任意のパスを指定することで、過去に収集済みの tout フォルダに対して後から再パースすることも可能です。この「収集と解析の分離」は、現場ではデータを持ち帰り、解析は後でオフラインで行うというシナリオで特に有用です。

1-2. VSS(ボリュームシャドウコピー)の活用

kape.exe には --vss フラグがあり、有効にするとシステムに存在するすべてのVSSスナップショットからもアーティファクトを収集します。gkapeでは左側エリアの「Process VSS」チェックボックスに相当します。これにより、現在のファイルシステムから削除済みでも、スナップショット時点に存在していたファイルを収集できる場合があります。ランサムウェアや痕跡消去を行った攻撃者の調査で特に有効です。

ただし、VSSの処理は時間とディスクI/Oを大幅に増やすため、トリアージ目的での初動対応では無効にし、精査フェーズで再収集するという運用が現実的です。


2. カスタムTarget(.tkape)の作成

既存のTargetでカバーされていないアーティファクトを収集したい場合、独自の .tkape ファイルを作成します。ファイル形式はYAMLに似た構造で、テキストエディタで直接記述できます。

2-1. .tkape ファイルの基本構造

Name: CustomBrowserHistory
Description: Chrome・Edgeのブラウザ履歴を収集するカスタムTarget
Author: YourName
Version: 1.0
Id: 12345678-abcd-efgh-ijkl-0123456789ab
RecreateDirectories: true

Targets:
  -
    Name: Chrome Default Profile
    Category: Browsers
    Path: C:\Users\%user%\AppData\Local\Google\Chrome\User Data\Default
    FileMask: "History,History-journal,Login Data,Cookies,Top Sites"
    Recursive: false
    IsDirectory: false
  -
    Name: Edge Default Profile
    Category: Browsers
    Path: C:\Users\%user%\AppData\Local\Microsoft\Edge\User Data\Default
    FileMask: "History,History-journal,Login Data,Cookies"
    Recursive: false
    IsDirectory: false

主要なフィールドの意味は次の通りです。

  • Path:収集対象のフォルダパス。%user% はKAPEが自動展開するワイルドカードで、すべてのユーザープロファイルを対象にできる
  • FileMask:収集するファイル名のフィルタ。カンマ区切りで複数指定可能。* で全ファイル
  • Recursive:true にするとサブディレクトリも再帰的にコピー
  • IsDirectory:ディレクトリ全体をコピーする場合は true

作成したファイルは KAPE\Targets\Custom\ などの任意のサブフォルダに保存すると、gkapeのTarget一覧に自動で表示されます。

2-2. 複合Target(Compound Target)の作成

複数の既存Targetをまとめて呼び出す「複合Target」も作成できます。Targets: フィールドに既存Targetの Name を参照させるだけです。

Name: IncidentResponse_Full
Description: インシデント対応用の総合収集セット
Author: YourName
Version: 1.0
Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Targets:
  -
    Name: KapeTriage
    Category: Triage
  -
    Name: WindowsEventLogs
    Category: EventLogs
  -
    Name: RegistryHives
    Category: Registry
  -
    Name: CustomBrowserHistory
    Category: Browsers

これにより、案件ごとや組織のポリシーに合わせた収集セットをワンクリックで実行できるようになります。


3. カスタムModule(.mkape)の作成

3-1. .mkape ファイルの基本構造

ModuleはExternalProcessesフィールドに実行コマンドを記述し、収集済みのファイルに対して任意の処理を行います。

Name: RegRipper_NTUSER
Description: NTUSERハイブをRegRipperで解析してテキストレポートを生成する
Author: YourName
Version: 1.0
Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

ExternalProcesses:
  -
    Executable: rip.exe
    CommandLine: "-r %sourceDirectory%\C\Users\*\NTUSER.DAT -f ntuser -l"
    ExportFormat: txt
    ExportPath: RegRipper
    Recursive: false
    FileMask: "NTUSER.DAT"

%sourceDirectory% はModule sourceのパスに、%destinationDirectory% はModule destinationのパスに自動展開されます。外部ツール(rip.exe など)は KAPE\Modules\bin\ に配置する必要があります。

3-2. PowerShellスクリプトをModuleとして組み込む

EXE形式でないPowerShellスクリプトも、以下のようにModuleとして実行できます。

ExternalProcesses:
  -
    Executable: powershell.exe
    CommandLine: "-ExecutionPolicy Bypass -File %sourceDirectory%\Scripts\ParsePrefetch.ps1 -OutputPath %destinationDirectory%\Prefetch"
    ExportFormat: csv
    ExportPath: PrefetchParsed

この仕組みを利用すると、組織内で開発した独自のパースロジックや、YARAスキャン、IoC(侵害指標)照合スクリプトなどをKAPEのワークフローに統合できます。


4. kape.exe の主要フラグ詳細とgkapeとの対応

gkapeのコマンドプレビューで表示されるオプション群を理解することで、スクリプトによる自動化やリモート展開に応用できます。代表的なフラグを整理します。

フラグgkape上の対応項目説明
--tsourceTarget source収集元ドライブ(例:C:)。複数指定不可
--tdestTarget destination収集先フォルダ
--targetTargetsチェックリスト使用するTarget名をカンマ区切りで指定
--msourceModule sourceパース対象フォルダ(省略時は –tdest を使用)
--mdestModule destinationパース済み出力フォルダ
--moduleModulesチェックリスト使用するModule名をカンマ区切りで指定
--vssProcess VSS チェックボックスボリュームシャドウコピーも収集対象に含める
--hashHash Files チェックボックス収集ファイルのハッシュ値を記録する
--zv falseZip Files チェックボックス(無効化)デフォルトではZIP圧縮される。falseで無効化
--debugDebug チェックボックス詳細なデバッグログを出力(問題切り分けに使用)
--syncSync with GitHub ボタンGitHubからTarget・Moduleの定義を最新化する

実用的なコマンドライン例

以下は自動化スクリプトに組み込む際の実例です。

kape.exe --tsource C: --tdest D:\output\tout --target KapeTriage,WindowsEventLogs ^
         --msource D:\output\tout --mdest D:\output\mout --module !EZParser ^
         --hash --vss --zv false --debug

このコマンドをバッチファイル(.bat)またはPowerShellスクリプト(.ps1)に組み込み、USB起動媒体に入れておくことで、現場端末での初動収集を標準化できます。


5. 複数端末への一括展開とリモート収集

5-1. PSExec を使ったリモート実行

SysInternals の PSExec と組み合わせることで、ネットワーク上の複数端末に対してKAPEをリモート実行できます。前提として、対象端末の管理者共有(C$)へのアクセス権限が必要です。

# 対象端末のC$にKAPEを配置してリモート実行する例(PowerShell)
$targets = @("192.168.1.10", "192.168.1.11", "192.168.1.12")
foreach ($ip in $targets) {
    Copy-Item -Path "C:\KAPE" -Destination "\\$ip\C$\KAPE" -Recurse -Force
    .\PsExec.exe \\$ip -s -accepteula cmd /c ^
        "C:\KAPE\kape.exe --tsource C: --tdest \\FileServer\KAPE_Output\$ip\tout --target KapeTriage --mdest \\FileServer\KAPE_Output\$ip\mout --module !EZParser --hash"
}

出力先をファイルサーバーのUNCパスにすることで、各端末の調査結果を一元収集できます。

5-2. SCCM/Intune を使った企業規模展開

Microsoft Endpoint Manager(Intune)やSCCMが導入されている環境では、KAPEの実行をスクリプト配布ジョブとしてデプロイすることが可能です。この場合、対象端末のローカル管理者コンテキストで実行されるため、PSExecのような接続性の制約がなく、VPN経由のリモートワーク端末にも適用できます。

EDR(Endpoint Detection and Response)製品(CrowdStrike Falcon、Microsoft Defender for Endpointなど)のライブレスポンス機能を使う方法もあり、KAPEのバイナリをセッション経由でアップロードして実行するという構成が現場では取られることがあります。


6. 出力データの高度な分析:Timeline Explorerを超えた可視化

6-1. Splunk へのCSV取り込みパイプライン

!EZParser の出力CSVは、Splunkのmonitor stanzaを設定することでほぼそのまま取り込めます。inputs.conf に以下のように記述します。

[monitor://D:\KAPE_output\mout\...]
index = forensics
sourcetype = kape_ezparser
disabled = false

取り込み後は、SPL(Splunk Processing Language)で時系列ダッシュボードを構築できます。複数端末の調査結果を横断的に検索・相関分析できるため、大規模インシデント対応で特に威力を発揮します。

6-2. Elastic Stack(ELK)への取り込み

Logstashのfilebeat + CSV inputプラグインを使う方法もあります。以下はEventLog出力CSVを取り込むlogstash.conf の例です。

input {
  file {
    path => "/mnt/kape/mout/EventLogs/*.csv"
    start_position => "beginning"
    sincedb_path => "/dev/null"
  }
}
filter {
  csv {
    separator => ","
    columns => ["Channel","Computer","EventId","TimeCreated","UserName","MapDescription","Payload"]
  }
  date {
    match => ["TimeCreated", "yyyy-MM-dd HH:mm:ss"]
    target => "@timestamp"
  }
}
output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "kape-eventlogs"
  }
}

Kibana上でタイムラインビジュアライゼーションを構築すると、複数のアーティファクト種別を重ねて表示でき、攻撃のキルチェーン全体を一画面で把握できます。

6-3. Python + pandas による独自分析

KAPE出力を Python で処理する場合、!EZParser で生成されるCSVは列構造が整っているため、pandasと相性が良いです。以下はプリフェッチから不審な実行ファイルを抽出する簡易スクリプト例です。

import pandas as pd
import glob

# プリフェッチCSVを全て読み込む
files = glob.glob("mout/Prefetch/*.csv")
df = pd.concat([pd.read_csv(f) for f in files])

# 実行回数1回 かつ パスにTEMPを含むものを抽出
suspicious = df[(df["RunCount"] == 1) & 
               (df["SourceFilename"].str.contains("TEMP|TMP|AppData", case=False, na=False))]

suspicious[["SourceFilename", "LastRun", "RunCount", "Volume0Name"]].to_csv("suspicious_prefetch.csv", index=False)
print(f"疑わしいエントリ数: {len(suspicious)}")

同様の手法で、イベントログから特定のEventIDを集計したり、MFTから特定の時間帯に作成されたファイルを一覧化するなど、調査の観点に応じた自動フィルタリングが可能です。


7. フォレンジックイメージを対象とした精密調査

7-1. Arsenal Image Mounter との連携

E01やraw(dd)形式のディスクイメージを調査する場合、Arsenal Image Mounter(無料版あり)を使ってイメージを仮想ディスクとしてマウントします。マウント時に「Write temporary delta file」オプションを選択すると、元イメージへの書き込みを完全に防止しながらWindowsのすべての機能でアクセスできます。

マウント後に割り当てられたドライブレター(例:E:\)をgkapeのTarget sourceに指定するだけで、ライブシステムと同じ手順で調査できます。

7-2. オフラインシステムのレジストリを対象にしたModule実行

収集したレジストリハイブ(SYSTEM、SOFTWARE、NTUSERなど)をModuleで直接処理する場合、RECmd(EZTools)を使うことで、オフラインハイブからRunキー、サービス登録、ShellBag、UserAssistなどを抽出できます。

# RECmd を使って RunキーのCSV出力を得るModule例
Executable: RECmd.exe
CommandLine: "-d %sourceDirectory%\C\Windows\System32\config --bn BatchMode.reb --csv %destinationDirectory%\Registry --csvf RunKeys.csv"

BatchModeファイル(.reb)を自分で作成すると、調査観点に応じたキーのみを効率よく抽出するカスタム解析フローを構築できます。


8. 品質管理とドキュメンテーション

8-1. ハッシュ値による証拠保全の記録

--hash フラグを有効にすると、tout フォルダ内に _CopyLog.csv と _HashLog.csv が生成されます。これらには収集ファイルのパス・サイズ・タイムスタンプ・ハッシュ値が記録されており、法的手続きや社内コンプライアンス報告に必要な「証拠の完全性証明」として使用できます。

8-2. ケースノートの構造化

大規模調査では、gkapeの実行ログ(_KapeLog.log)と併せて以下の情報をMarkdownまたはcaseファイルとして記録することを推奨します。

  • 調査開始日時と担当者名
  • 収集元デバイスの識別情報(ホスト名、IPアドレス、シリアル番号)
  • 使用したKAPEのバージョン(kape.exe --version で確認)
  • 使用したTarget・Module名と選択理由
  • ハッシュログのチェックサム(ログファイル自体のハッシュ)
  • 調査中に発見した注目点・仮説と次のアクション

9. トラブルシューティングとパフォーマンス最適化

9-1. よくあるエラーと対処法

  • 「Access Denied」エラー:管理者権限で実行しているか確認する。また、EDR製品がファイルアクセスをブロックしている場合は、除外設定を一時的に追加する
  • Moduleが実行されないModules\bin\ に必要なEXEが存在するか確認する。Get-ZimmermanTools.ps1 を再実行してEZToolsを最新化する
  • VSSが見つからないvssadmin list shadows でスナップショットの存在を事前確認する。Hyper-V仮想マシンやクラウドインスタンスではVSSが存在しないことがある
  • 出力CSVが空:Module sourceのパスが正しいか確認する。Target destinationとModule sourceは完全に一致している必要がある

9-2. パフォーマンスのチューニング

大量のファイルを収集する際、--zv false でZIP圧縮を無効にすると処理速度が向上します。また、出力先をネットワークドライブにする場合はローカルの高速SSDに一時出力してからコピーする方が、トータルの所要時間が短くなるケースが多いです。--debug フラグを有効にすると各ステップの所要時間がログに記録されるため、ボトルネックの特定に使えます。


まとめ:gkape/KAPEを「組織のスタンダード」にする

本記事で扱った内容を整理します。

  • アーキテクチャ理解:Targetの内部フロー、VSSの仕組みを把握することで、収集の網羅性と信頼性が高まる
  • カスタムTarget・Module:.tkape / .mkape を自作することで、組織固有の調査観点に対応したコレクションセットを構築できる
  • バッチ自動化・リモート展開:PSExec、Intune、EDRのライブレスポンス機能と組み合わせることで、大規模インシデント対応でも迅速な初動収集が可能になる
  • SIEM・ELK・Python連携:出力CSVを既存のセキュリティ基盤に取り込み、横断的な相関分析・可視化ダッシュボードを実現できる
  • 証拠保全とドキュメンテーション:ハッシュログとケースノートの標準化により、法的証拠能力を担保した調査フローを確立できる

KAPEはTargetとModuleの定義ファイルがOSSとしてGitHubで管理されており、コミュニティによって日々アップデートされています。自作の定義ファイルをプルリクエストで貢献することも可能で、組織内の知識を業界全体に還元できる点もこのエコシステムの魅力です。

gkapeをGUIの入門ツールとして捉えるのではなく、組織のインシデントレスポンスプロセスに組み込む標準プラットフォーム として設計・運用することで、その真価を発揮できます。


参考リソース

  • GitHub:EricZimmerman / KapeFiles(Target・Module定義の最新版)
  • Eric Zimmerman’s Tools(EZTools一覧・ダウンロード):ericzimmerman.github.io
  • SANS FOR508:Advanced Incident Response, Threat Hunting, and Digital Forensics(KAPE実践コース)
  • Arsenal Image Mounter 公式サイト
  • Splunk Add-on for KapeFiles(Splunkbase)
  • KAPE 公式ドキュメント(Kroll社)

コメント