Hayabusa-Bulk-Runner

KAPEコレクションのフォルダに対して、Hayabusaをホストごとに1回実行し、結果を単一のクロスホストトリアージビューに集約するPowerShellラッパーです。

Hayabusaはすでに-dでディレクトリ全体を受け取り、そのHTMLサマリーは結果をコンピューターごとに分類します。しかしKAPEコレクションのフォルダでは、まだ2つの作業を手動で行う必要があります。Hayabusaが読み取る前に、各ZIPを展開し、各ディスクイメージをマウントする必要があり、すべてを対象にした実行では1つの統合出力が得られるだけで、ホストごとのレポートやタイムラインはありません。このツールはその部分を担当します。ホストごとに1つのエントリを持つフォルダを指定すると、各ホストについてHayabusaのHTMLアラートレポート、CSVタイムライン、ログが得られ、さらにどのホストが最も深刻か、どのルールがどこで発火したかを示すダッシュボードも得られます。

完全な使用法リファレンス: docs/USAGE.md

スクリーンショット

8つのホストに対する実行後のダッシュボード(重大度の下限をmediumに設定):

同じ実行中のコンソール:

機能

• ホストごとにHayabusaを1回実行するため、統合出力ではなく、各ホストが独自のHTMLレポート、CSVタイムライン、ログを取得します。
• 各KAPE ZIPを展開し、各ディスクイメージをマウントし、ホストの処理が完了したらすべてを元に戻します。
• クロスホストダッシュボードを構築します: 重大度別の合計、発火したルールとそれぞれが影響したホスト、そしてすべてのホストを最も深刻な順にランク付けします。
• ホスト名をHayabusa自身のComputerフィールドから読み取るため、KAPEがドライブ名を付けた緩い出力でも正しいホストの下に配置されます。
• ケースを再開できます。同じコマンドを再度実行すると、すでに完了したホストをスキップし、残りを引き継ぎます。
• 証拠を最後まで読み取り専用として扱い、各イメージの前後のハッシュでそれを証明します。
• エンゲージメント設定を受け取るため、ケース内のすべてのホストが同じ設定で実行されます。

ステータス

プレリリース。Windows上の実際のHayabusa 4.1.0とKAPEイメージおよびZIPに対して実行されており、テストスイートはCIでWindows PowerShell 5.1、Windows上のPowerShell 7、Linux上のPowerShell 7で実行されています。2つの動作は確認するための適切な証拠がまだ必要で、Windows上で未確認に記載されています。レポートでそれらのいずれかに依存する前に、そのリストを確認してください。

要件

• Windows。このツールはWindows上でのみHayabusaを実行し、ディスクイメージをマウントします。ロールアップはPowerShellが動作する場所ならどこでも再構築できます。
• Windows PowerShell 5.1またはPowerShell 7。
• ルールを含むHayabusa 4.1.0。エンゲージメントの開始時に一度hayabusa.exe update-rulesを実行し、完了するまでルールをそのままにしておいてください。そうすることで、すべてのホストが同じセットに対してチェックされます。
• いずれかのコレクションがディスクイメージの場合(ZIP内のディスクイメージを含む)、昇格したセッション。

入手方法

リポジトリをクローンするか、GitHubからZIPとしてダウンロードして展開します:

git clone https://github.com/rorywag/Hayabusa-Bulk-Runner.git

2つのスクリプトの隣にlibフォルダを置いてください。スクリプトはそこからすべてを読み込みます。WindowsはダウンロードしたZIPからのファイルをインターネット由来としてマークします。以下に示すProcessスコープの実行ポリシーはすでにそれらを許可しているため、ブロックを解除する必要はありません。

クイックスタート

.\Invoke-BulkHayabusa.ps1 -InputRoot D:\Cases\Case01\KAPE -OutputRoot D:\Cases\Case01\Output -HayabusaPath D:\Tools\hayabusa\hayabusa.exe

実行中はホストごとに1行を出力し、その後短いサマリーと参照先を表示します:

[1/4] DC01 ... Completed, 12 detections
[2/4] FS02 ... Completed, 6 detections
WARNING: [3/4] WS03 ... Failed: Hayabusa exited with code 2. See D:\Cases\Case01\Output\WS03\WS03_hayabusa.log. No CSV was written.
[4/4] WS04 ... skipped, already Completed
Done: 3 processed, 2 completed, 0 completed with errors, 1 failed, 1 skipped.
Output is in D:\Cases\Case01\Output. Open triage_dashboard.html there to start triage.

新しいPowerShellウィンドウでは、スクリプトが実行ポリシーによってブロックされる場合があります。これはそのウィンドウのみで許可し、マシン上の何も変更しません:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

.\Invoke-BulkHayabusa.ps1 -Helpまたは-hで短い使用法のサマリーが表示されます。完全なパラメーターリスト、実例、入力と出力のモデル、エンゲージメント設定については、docs/USAGE.mdを参照してください。

証拠の完全性

証拠は読み取りのみです。

• ディスクイメージは直接マウントされません。KAPEイメージは作成時にダーティであるため、読み取り専用マウントではボリュームがまったく表示されません。代わりに、ツールは証拠イメージを親とする差分ディスクをOutputRoot\_diffの下にマウントします。Windowsはジャーナルを子に再生し、親は読み取りのみで、KAPE出力で親のハッシュが前後で同じであることを確認済みです。
• すでにアタッチされているイメージは拒否されます。再利用やアンマウントは行いません。この実行がアタッチしたものではないためです。
• ZIPはOutputRoot\_workの下の作業コピーに展開されます。ZIP自体は読み取りのみです。
• 各ホストの後、何が起きたとしても、ティアダウンは固定された順序で実行されます: フォルダマウントポイントが使用された場合は削除し、子をアンマウントし、空のマウントフォルダを削除し、子を削除し、展開物を削除します。マウントポイントである可能性のあるフォルダを通じて再帰的に削除されることはありません。ツールは自身の_work、_mnt、_diffフォルダ内、およびそのホストが再実行される直前のホスト自身の以前のレポートとタイムラインのみを削除します。アンマウントが失敗した場合、それ以降のすべてはそのまま残され、エラーは何がまだ残っているかを示します。
• OutputRootのパスがInputRoot内にある場合は拒否されるため、出力が証拠の隣に配置されることはありません。
• 証拠から何かが実行されることはありません。ルールタイトルやコンピューター名など、証拠からの値は、書き出される場所すべてでエンコードされます。

ドキュメント

docs/USAGE.mdが残りをカバーします:

• すべてのコマンドラインパラメーターと実例
• InputRootエントリの読み取り方法: フォルダ、ディスクイメージ、ZIP
• ZIPの処理、およびサイズと長いパスの制限
• 出力の完全なリストとツールの作業フォルダ
• 再実行、再開、および各ステータスの意味
• エンゲージメント設定とそれが受け取るすべての設定
• テストの実行

セキュリティ

脆弱性を非公開で報告する方法については、SECURITY.mdを参照してください。

ライセンス

MIT。LICENSEを参照してください。

このツールは独立しており、Yamato Securityと提携しておらず、承認も受けていません。Hayabusaを別の外部プログラムとして実行し、そのコードは一切含まれていません。HayabusaはYamato SecurityによってGNU AGPL-3.0の下で公開されており、その検出ルールはそれぞれ独自のライセンスの下にあります。HayabusaとそのルールはYamato Securityからダウンロードしてください。