Hayabusaは、日本のYamato Securityグループによって作られたWindowsイベントログのファストフォレンジックタイムライン作成および脅威ハンティングツールです。 Hayabusaは日本語で「ハヤブサ」を意味し、ハヤブサが世界で最も速く、狩猟(hunting)に優れ、とても訓練しやすい動物であることから選ばれました。 Rust で開発され、マルチスレッドに対応し、可能な限り高速に動作するよう配慮されています。 Hayabusaはupstream Sigma ルールの解析に対応しています。ただし、hayabusa-rules repositoryで使用およびホストしているSigmaルールは、ルールの読み込みをより柔軟にし、誤検知を減らすために一部の変換が施されています。 詳細については、sigma-to-hayabusa-converter repository リポジトリのREADMEファイルをご参照ください。 稼働中のシステムで実行してライブ調査することも、複数のシステムからログを収集してオフライン調査することも可能です。 また、 VelociraptorとHayabusa artifactを用いることで企業向けの広範囲なスレットハンティングとインシデントレスポンスにも活用できます。 出力は一つのCSVタイムラインにまとめられ、LibreOffice、Timeline Explorer、Elastic Stack、Timesketch等で簡単に分析できるようになります。
- EnableWindowsLogSettings - Sigmaベースの脅威ハンティングと、Windowsイベントログのファストフォレンジックタイムライン生成ツール。
- Hayabusa Encoded Rules - Hayabusa Rulesリポジトリと同じだが、ルールと設定ファイルは1つのファイルに保存され、アンチウイルスによる誤検知を防ぐためにXORされる。
- Hayabusa Rules - Hayabusaのための検知ルール。
- Hayabusa EVTX -
evtxクレート
のよりメンテナンスされたフォーク。 - Hayabusa Sample EVTXs - Hayabusa/Sigma検出ルールをテストするためのサンプルevtxファイル。
- Presentations - ツールやリソースについて行った講演のプレゼンテーション。
- Sigma to Hayabusa Converter - 上流のWindowsイベントログベースのSigmaルールを使いやすい形式にキュレーションする。
- Takajo - Hayabusa結果の解析ツール。
- WELA (Windows Event Log Analyzer) - PowerShellで書かれたWindowsイベントログの解析ツール。(非推奨となり、Takajoに置き換えられた)
- AllthingsTimesketch - PlasoとHayabusaの結果をTimesketchにインポートするNodeREDワークフロー
- LimaCharlie - ニーズに合わせたクラウドベースのセキュリティツールとインフラを提供
- OpenRelik - デジタル・フォレンジックの共同調査を効率化するために設計されたオープンソース(Apache-2.0)のプラットフォーム
- Splunk4DFIR - Dockerでsplunkインスタンスを素早く立ち上げ、調査中に出力されるログやツールを閲覧するためのツール
- Velociraptor - Velociraptor Query Language (VQL)クエリを使用したホストベースの収集ツール
- Hayabusa について
- 関連プロジェクト
- Hayabusaを利用したサードパーティプロジェクト
- スクリーンショット
- タイムライン結果のインポートと解析について
- jqによるJSON形式の結果の解析
- 特徴&機能
- ダウンロード
- Gitクローン
- アドバンス: ソースコードからのコンパイル(任意)
- Hayabusaの実行
- コマンド一覧
- コマンド使用方法
- 分析コマンド
- DFIRタイムラインコマンド
update-rules
コマンド
- タイムライン出力
- Hayabusaルール
- その他のWindowsイベントログ解析ツールおよび関連リソース
- Windowsイベントログ設定のススメ
- Sysmon関係のプロジェクト
- コミュニティによるドキュメンテーション
- 貢献
- バグの報告
- ライセンス
Hayabusaには現在、4000以上のSigmaルールと170以上のHayabusa検知ルールがあり、定期的にルールが追加されています。 VelociraptorのHayabusa artifactを用いることで企業向けの広範囲なスレットハンティングだけでなくDFIR(デジタルフォレンジックとインシデントレスポンス)にも無料で利用することが可能です。 この2つのオープンソースを組み合わせることで、SIEMが設定されていない環境でも実質的に遡及してSIEMを再現することができます。 具体的な方法はEric Capuanoのこちらの動画で学ぶことができます。
Windowsのイベントログは、1)解析が困難なデータ形式であること、2)データの大半がノイズであり調査に有用でないことから、従来は非常に長い時間と手間がかかる解析作業となっていました。 Hayabusaは、有用なデータのみを抽出し、専門的なトレーニングを受けた分析者だけでなく、Windowsのシステム管理者であれば誰でも利用できる読みやすい形式で提示することを主な目的としています。 Hayabusaは従来のWindowsイベントログ分析解析と比較して、分析者が20%の時間で80%の作業を行えるようにすることを目指しています。
CSVのタイムラインをExcelやTimeline Explorerで分析する方法はこちらで紹介しています。
CSVのタイムラインをElastic Stackにインポートする方法はこちらで紹介しています。
CSVのタイムラインをTimesketchにインポートする方法はこちらで紹介しています。
JSON形式の結果をjq
で解析する方法については、こちらを参照してください。
- クロスプラットフォーム対応: Windows, Linux, macOS。
- Rustで開発され、メモリセーフでハヤブサよりも高速です!
- マルチスレッド対応により、最大5倍のスピードアップを実現。
- フォレンジック調査やインシデントレスポンスのために、分析しやすいCSVタイムラインを作成します。
- 読みやすい/作成/編集可能なYMLベースのHayabusaルールで作成されたIoCシグネチャに基づくスレットハンティング。
- SigmaルールをHayabusaルールに変換するためのSigmaルールのサポートがされています。
- 現在、他の類似ツールに比べ最も多くのSigmaルールをサポートしており、カウントルール、新しい機能の
|equalsfield
や|endswithfield
等にも対応しています。 - コンピュータ名の統計。(イベントの多い特定のコンピュータをフィルタリングするのに便利です。)
- イベントログの統計。(どのような種類のイベントがあるのかを把握し、ログ設定のチューニングに有効です。)
- 不良ルールやノイズの多いルールを除外するルールチューニング設定が可能です。
- MITRE ATT&CKとのマッピング。
- ルールレベルのチューニング。
- イベントログから不審なユーザやファイルを素早く特定するためのピボットキーワードの一覧作成。
- 詳細な調査のために全フィールド情報の出力。
- 成功と失敗したユーザログオンの要約。
- Velociraptorと組み合わせた企業向けの広範囲なすべてのエンドポイントに対するスレットハンティングとDFIR。
- CSV、JSON、JSONL形式とHTML結果サマリの出力。
- 毎日のSigmaルール更新。
- JSON形式のログ入力にも対応。
- ログフィールドの正規化
- IPアドレスにGeoIP(ASN、都市、国)情報を付加することによるログエンリッチメント。
- キーワードや正規表現で全イベントの検索。
- フィールドデータのマッピング (例:
0xc0000234
->ACCOUNT LOCKED
) - 空領域からのEvtxレコードカービング。
- 出力時のイベント重複排除。(レコード復元が有効になっている場合や、バックアップされたevtxファイル、VSSから抽出されたevtxファイルなどが含まれている場合に便利。)
- スキャン設定ウィザードにより、有効にするルールの選択が容易に。(誤検出を減らすためなど。)
- PowerShell classicログのフィールドパースと抽出。
- 低メモリモード。(注意: 結果をソートしないことで可能。エージェントやビッグデータでの実行に適している。)
- チャンネルとルールのフィルタリングによって最も効率的なパフォーマンスを達成する。
- ログに含まれるBase64文字列を検出、抽出、デコードする。
ReleasesページからHayabusaの安定したバージョンでコンパイルされたバイナリが含まれている最新版もしくはソースコードをダウンロードできます。
以下のアーキテクチャ用のバイナリを提供している:
- Linux ARM 64-bit GNU (
hayabusa-x.x.x-lin-aarch64-gnu
) - Linux Intel 64-bit GNU (
hayabusa-x.x.x-lin-x64-gnu
) - Linux Intel 64-bit MUSL (
hayabusa-x.x.x-lin-x64-musl
) - macOS ARM 64-bit (
hayabusa-x.x.x-mac-aarch64
) - macOS Intel 64-bit (
hayabusa-x.x.x-mac-x64
) - Windows ARM 64-bit (
hayabusa-x.x.x-win-aarch64.exe
) - Windows Intel 64-bit (
hayabusa-x.x.x-win-x64.exe
) - Windows Intel 32-bit (
hayabusa-x.x.x-win-x86.exe
)
Linux ARM MUSLバイナリが正常に動作しません そのため、現時点ではそのバイナリを提供していません。これは我々の実装の範囲外の問題なので、修正され次第、将来的に提供する予定です。
v2.18.0から、1つのファイルにまとめたXORエンコードされたルールと、すべての設定ファイルを1つのファイルにまとめた特別なWindowsパッケージを提供しています(hayabusa-encoded-rules repositoryにてホストされています)。 live-responseという名前がついたzipパッケージをダウンロードするだけです。 zipファイルには、Hayabusaのバイナリ、XORエンコードされたルールファイル、設定ファイルの3つのファイルが含まれています。 これらのライブレスポンスパッケージの目的は、クライアントのエンドポイントでHayabusaを実行する際に、Windows Defenderのようなウイルス対策スキャナーが.ymlルールファイルに対して誤検知をしないようにするためです。 また、USNジャーナルなどのフォレンジックアーティファクトが上書きされないよう、システムに書き込まれるファイルの量を最小限に抑えることも目的としています。
以下のgit clone
コマンドでレポジトリをダウンロードし、ソースコードからコンパイルして使用することも可能です:
注意:
main
ブランチは開発中のバージョンです。まだ正式にリリースされていない新機能が使えるかもしれないが、バグがある可能性もあるので、テスト版だと思って下さい。
git clone https://github.com/Yamato-Security/hayabusa.git --recursive
※
--recursive
をつけ忘れた場合、サブモジュールとして管理されているrules
フォルダ内のファイルはダウンロードされません。
git pull --recurse-submodules
コマンド、もしくは以下のコマンドでrules
フォルダを同期し、Hayabusaの最新のルールを更新することができます:
hayabusa.exe update-rules
アップデートが失敗した場合は、rules
フォルダの名前を変更してから、もう一回アップデートしてみて下さい。
注意: アップデートを実行する際に
rules
フォルダは hayabusa-rules レポジトリの最新のルールとコンフィグファイルに置き換えられます 既存ファイルへの修正はすべて上書きされますので、アップデート実行前に編集したファイルのバックアップをおすすめします。 もし、level-tuning
を行っているのであれば、アップデート後にルールファイルの再調整をしてくださいrules
フォルダ内に新しく追加したルールは、アップデート時に上書きもしくは削除は行われません。
Rustがインストールされている場合、以下のコマンドでソースコードからコンパイルすることができます:
注意: hayabusaをコンパイルするためにはRust(rustc)が最新版であることが必要です。
cargo build --release
最新のunstable版はmainブランチから、最新の安定版はReleasesページからダウンロードできます。
以下のコマンドで定期的にRustをアップデートしてください:
rustup update stable
コンパイルされたバイナリは./target/release
フォルダ配下で作成されます。
コンパイル前に最新のRust crateにアップデートすることで、最新のライブラリを利用することができます:
cargo update
アップデート後、何か不具合がありましたらお知らせください。
以下のコマンドで64ビットのWindows端末で32ビットのバイナリをクロスコンパイルできます:
rustup install stable-i686-pc-windows-msvc
rustup target add i686-pc-windows-msvc
rustup run stable-i686-pc-windows-msvc cargo build --release
注意: Rust の新しい安定版が出たときには必ず
rustup install stable-i686-pc-windows-msvc
を実行してください。rustup update stable
はクロスコンパイル用のコンパイラを更新しないので、ビルドエラーが発生することがあります。
opensslについてのコンパイルエラーが表示される場合は、Homebrewをインストールしてから、以下のパッケージをインストールする必要があります:
brew install pkg-config
brew install openssl
opensslについてのコンパイルエラーが表示される場合は、以下のパッケージをインストールする必要があります。
Ubuntu系のディストロ:
sudo apt install libssl-dev
Fedora系のディストロ:
sudo yum install openssl-devel
まず、Linux OSでターゲットをインストールします。
rustup install stable-x86_64-unknown-linux-musl
rustup target add x86_64-unknown-linux-musl
以下のようにコンパイルします:
cargo build --release --target=x86_64-unknown-linux-musl
注意: Rust の新しい安定版が出たときには必ず
rustup install stable-x86_64-unknown-linux-musl
を実行してください。rustup update stable
はクロスコンパイル用のコンパイラを更新しないので、ビルドエラーが発生することがあります。
MUSLバイナリは./target/x86_64-unknown-linux-musl/release/
ディレクトリ配下に作成されます。
MUSLバイナリはGNUバイナリより約15%遅いですが、より多くのLinuxバージョンとディストロで実行できます。
Hayabusa実行する際や、.yml
ルールのダウンロードや実行時にルール内でdetectionに不審なPowerShellコマンドやmimikatz
のようなキーワードが書かれている際に、アンチウィルスやEDRにブロックされる可能性があります。
誤検知のため、セキュリティ対策の製品がHayabusaを許可するように設定する必要があります。
マルウェア感染が心配であれば、ソースコードを確認した上で、自分でバイナリをコンパイルして下さい。
Windows PC起動後の初回実行時に時間がかかる場合があります。 これはWindows Defenderのリアルタイムスキャンが行われていることが原因です。 リアルタイムスキャンを無効にするかHayabusaのディレクトリをアンチウィルススキャンから除外することでこの現象は解消しますが、設定を変える前にセキュリティリスクを十分ご考慮ください。
コマンドプロンプトやWindows Terminalから32ビットもしくは64ビットのWindowsバイナリをHayabusaのルートディレクトリから実行します。
Windowsに組み込まれているコマンドプロンプトまたはPowerShellプロンプトを使用する場合、ファイルまたはディレクトリのパスに空白があると、.evtxファイルをロードできないというエラーが表示されることがあります。 .evtxファイルを正しくロードするために、以下のことを行ってください:
- ファイルまたはディレクトリのパスをダブルクォートで囲む。
- ディレクトリパスの場合は、最後の文字にバックスラッシュを入れない。
デフォルトのフォントがWindowsのLucida Console
の場合、ロゴやテーブルに使用されているさまざまな文字が正しく表示されません。
フォントをConsolas
に変更することで、これを修正できます。
これにより、ほとんどのテキスト表示の問題は修正されますが、終了メッセージに含まれる日本語文字の表示は修正されません。
以下の4つのオプションのいずれかで修正できます:
- Windows TerminalをCommand PromptまたはPowerShellの代わりに使用する。(推奨)
MS Gothic
フォントを使用する。ただし、バックスラッシュが円記号(¥)に変わることに注意してください。- HackGenフォントをインストールし、
HackGen Console NF
を使用する。 - 日本語を含む終了メッセージを表示しないために、
-q, --quiet
オプションを使用する。
まず、バイナリに実行権限を与える必要があります。
chmod +x ./hayabusa
次に、Hayabusaのルートディレクトリから実行します:
./hayabusa
まず、ターミナルやiTerm2からバイナリに実行権限を与える必要があります。
chmod +x ./hayabusa
次に、Hayabusaのルートディレクトリから実行してみてください:
./hayabusa
macOSの最新版では、以下のセキュリティ警告が出る可能性があります:
macOSの環境設定から「セキュリティとプライバシー」を開き、「一般」タブから「このまま許可」ボタンをクリックしてください。
その後、ターミナルからもう一回実行してみてください:
./hayabusa
以下の警告が出るので、「開く」をクリックしてください。
これで実行できるようになります。
computer-metrics
: コンピュータ名に基づくイベントの合計を出力する。eid-metrics
: イベントIDに基づくイベントの合計と割合の集計を出力する。expand-list
:expand
のプレースホルダをrules
フォルダから取り出す。extract-base64
: イベントからbase64文字列を抽出し、デコードする。logon-summary
: ログオンイベントのサマリを出力する。log-metrics
: ログファイルの統計情報を出力する。pivot-keywords-list
: ピボットする不審なキーワードのリストを作成する。search
: キーワードや正規表現で全イベントの検索。
csv-timeline
: CSV形式のタイムラインを出力する。json-timeline
: JSON/JSONL形式のタイムラインを出力する。level-tuning
: アラートlevel
のカスタムチューニング。list-profiles
: 出力プロファイルの一覧表示。set-default-profile
: デフォルトプロファイルを変更する。update-rules
: GitHubのhayabusa-rulesリポジトリにある最新のルールに同期させる。
help
: このメッセージまたは指定されたコマンドのヘルプを表示する。list-contributors
: コントリビュータ一覧の表示。
computer-metrics
コマンドを使うと、<System><Computer>
フィールドで定義された各コンピュータに応じたイベントの数をチェックすることができます。
Computer
フィールドを完全に頼りにしてイベントを元のコンピュータ別に分けることはできないことに注意してください。
Windows 11ではイベントログに保存するときにまったく異なるComputer
の名前を使うことがあります。
また、Windows 10ではComputer
の名前がすべて小文字で記録されることもあります。
このコマンドは検知ルールを使わないので、すべてのイベントを分析します。
このコマンドは、どのコンピュータに最も多くのログが記録されているかを素早く確認するのに適しています。
この情報があれば、タイムラインを生成する際に--include-computer
または--exclude-computer
オプションを使い、コンピュータ別に複数のタイムラインを生成したり、特定のコンピュータからのイベントを除外したりすることで、タイムライン生成をより効率的にすることができます。
Usage: computer-metrics <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
Output:
-o, --output <FILE> イベントIDに基づくイベントの合計と割合の集計を出力する (例: computer-metrics.csv)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
- ディレクトリに対してイベントIDの統計情報を出力する:
hayabusa.exe computer-metrics -d ../logs
- 結果をCSVファイルに保存する:
hayabusa.exe computer-metrics -d ../logs -o computer-metrics.csv
eid-metrics
コマンドを使用すると、イベントID(<System><EventID>
フィールド)の総数や割合をチャンネルごとに分けて表示することができます。
このコマンドは検知ルールを使用しないので、すべてのイベントをスキャンします。
Usage: eid-metrics <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
Output:
-b, --disable-abbreviations 省略機能を無効にする
-o, --output <FILE> イベントIDに基づくイベントの合計と割合の集計を出力する (例: eid-metrics.csv)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
- 一つのファイルに対してイベントIDの統計情報を出力する:
hayabusa.exe eid-metrics -f Security.evtx
- ディレクトリに対してイベントIDの統計情報を出力する:
hayabusa.exe eid-metrics -d ../logs
- 結果をCSVファイルに保存する:
hayabusa.exe eid-metrics -f Security.evtx -o eid-metrics.csv
チャンネル名、イベントID、イベントのタイトルは、rules/config/channel_eid_info.txt
で定義されています。
例:
Channel,EventID,EventTitle
Microsoft-Windows-Sysmon/Operational,1,Process Creation.
Microsoft-Windows-Sysmon/Operational,2,File Creation Timestamp Changed. (Possible Timestomping)
Microsoft-Windows-Sysmon/Operational,3,Network Connection.
Microsoft-Windows-Sysmon/Operational,4,Sysmon Service State Changed.
ルールフォルダからexpand
プレースホルダーを抽出します。
これは、expand
フィールド修飾子を使用するルールで利用する設定ファイルを作成する際に役立ちます。
expand
ルールを使用するには、./config/expand/
ディレクトリ内にexpand
フィールド修飾子の名前を持つ.txtファイルを作成し、そのファイル内に確認したい値をすべて入力するだけです。
例えば、ルールのdetection
ロジックが次のような場合:
detection:
selection:
EventID: 5145
RelativeTargetName|contains: '\winreg'
filter_main:
IpAddress|expand: '%Admins_Workstations%'
condition: selection and not filter_main
テキストファイル ./config/expand/Admins_Workstations.txt
を作成し、次のような値を入力します:
AdminWorkstation1
AdminWorkstation2
AdminWorkstation3
これは本質的に次のロジックと同じ内容を確認します:
- IpAddress: 'AdminWorkstation1'
- IpAddress: 'AdminWorkstation2'
- IpAddress: 'AdminWorkstation3'
設定ファイルが存在しない場合でも、Hayabusaはexpand
ルールを読み込みますが、それを無視します。
Usage: expand-list <INPUT> [OPTIONS]
General Options:
-h, --help ヘルプメニューを表示する
-r, --rules <DIR/FILE> ルールファイルまたはルールファイルを持つディレクトリ (デフォルト: ./rules)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
- デフォルトの
rules
ディレクトリからexpand
フィールド修飾子を抽出する:hayabusa.exe expand-list
sigma
ディレクトリからexpand
フィールド修飾子を抽出する:hayabusa.exe eid-metrics -r ../sigma
5 unique expand placeholders found:
Admins_Workstations
DC-MACHINE-NAME
Workstations
internal_domains
domain_controller_hostnames
このコマンドは、次のイベントからBase64文字列を抽出し、それをデコードして、どのようなエンコードが使用されているかを判別します。
- Security 4688 CommandLine
- Sysmon 1 CommandLine, ParentCommandLine
- PowerShell Operational 4104
- PowerShell Operational 4103
Usage: extract-base64 <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
Output:
-o, --output <FILE> Base64文字列を抽出する
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
- ディレクトリをスキャンし、結果をターミナルに出力します:
hayabusa.exe extract-base64 -d ../hayabusa-sample-evtx
- ディレクトリをスキャンし、結果をCSVファイルに出力します:
hayabusa.exe eid-metrics -r ../sigma -o base64-extracted.csv
ターミナルに出力する際、スペースに制限があるため、次のフィールドのみが表示されます:
- Timestamp
- Computer
- Base64 String
- Decoded String (if not binary)
CSVファイルに保存する際、次のフィールドが保存されます:
- Timestamp
- Computer
- Base64 String
- Decoded String (if not binary)
- Original Field
- Length
- Binary (
Y/N
) - Double Encoding (
Y
の場合、それは通常悪意があります。) - Encoding Type
- File Type
- Event
- Record ID
- File Name
log-metrics
コマンドを使うと、イベントログ内の以下のメタデータを出力することができる:
- ファイル名
- コンピュータ名
- イベント数
- 最初のタイムスタンプ
- 最後のタイムスタンプ
- チャネル
- プロバイダー
このコマンドは検知ルールを使用しないので、すべてのイベントをスキャンする。
Usage: log-metrics <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
Output:
-b, --disable-abbreviations 省略機能を無効にする
-M, --multiline イベントフィールド情報を複数の行に出力する
-o, --output <FILE> メトリクスをCSV形式で保存する (例: metrics.csv)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
- ファイルからログファイルのメトリクスを出力する:
hayabusa.exe log-metrics -f Security.evtx
- ディレクトリからログファイルのメトリクスを出力する:
hayabusa.exe log-metrics -d ../logs
- 結果をCSVファイルに保存:
hayabusa.exe log-metrics -d ../logs -o eid-metrics.csv
logon-summary
コマンドを使うことでログオン情報の要約(ユーザ名、ログイン成功数、ログイン失敗数)の画面出力ができます。
単体のevtxファイルを解析したい場合は-f
オプションを利用してください。複数のevtxファイルを対象としたい場合は-d
オプションを合わせて使うことでevtxファイルごとのログイン情報の要約を出力できます。
ログオン成功は、以下のイベントから取得される:
Security 4624
(ログオン成功)RDS-LSM 21
(リモートデスクトップサービス ローカルセッションマネージャーのログオン)RDS-GTW 302
(リモートデスクトップサービス ゲートウェイのログオン)
ログオン失敗は、Security 4625
イベントから取得される
Usage: logon-summary <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する (例1: evtx_data 例2:evtx1,evtx2)
Filtering:
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--timeline-end <DATE> 解析対象とするイベントログの終了時刻 (例: "2022-02-22 23:59:59 +09:00")
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
--timeline-start <DATE> 解析対象とするイベントログの開始時刻 (例: "2020-02-22 00:00:00 +09:00")
Output:
-o, --output <FILENAME-PREFIX> ログオンサマリをCSV形式で2つのファイルに保存する (例: -o logon-summary.csv)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
- ログオンサマリの出力:
hayabusa.exe logon-summary -f Security.evtx
- ログオンサマリ結果を保存する:
hayabusa.exe logon-summary -d ../logs -o logon-summary.csv
pivot-keywords-list
コマンドを使用すると、異常なユーザ、ホスト名、プロセスなどを迅速に特定し、イベントを関連付けるための固有のピボットキーワードのリストを作成することができます。
重要:デフォルトでは、Hayabusaはすべてのイベント(informationalおよびそれ以上)から結果を返すので、pivot-keywords-list
コマンドと-m, --min-level
オプションを組み合わせることを強くお勧めします。
例えば、まず-m critical
でcritical
アラートのみのキーワードを作成し、次に-m high
、-m medium
等々と続けていきます。
検索結果には、多くの通常のイベントと一致する共通のキーワードが含まれている可能性が高いので、検索結果を手動でチェックし、固有のキーワードのリストを1つのファイルに作成した後、grep -f keywords.txt timeline.csv
といったコマンドで疑わしい活動のタイムラインを絞り込み作成することが可能です。
Usage: pivot-keywords-list <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-w, --no-wizard 質問はしない。すべてのイベントとアラートをスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
-E, --EID-filter 速度を上げるため主なEIDだけスキャンする (コンフィグファイル: ./rules/config/target_event_IDs.txt)
-D, --enable-deprecated-rules ステータスがdeprecatedのルールを有効にする
-n, --enable-noisy-rules Noisyルールを有効にする
-u, --enable-unsupported-rules ステータスがunsupportedのルールを有効にする
-e, --exact-level <LEVEL> 特定のレベルだけスキャンする (informational, low, medium, high, critical)
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--exclude-eid <EID...> 高速化のために特定のEIDをスキャンしない (例: 1) (例: 1,4688)
--exclude-status <STATUS...> 読み込み対象外とするルール内でのステータス (例1: experimental) (例2: stable,test)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--exclude-tag <TAG...> 特定のタグを持つルールをロードしない (例: sysmon)
--include-eid <EID...> 指定したEIDのみをスキャンして高速化する (例 1) (例: 1,4688)
--include-status <STATUS...> 特定のステータスを持つルールのみをロードする (例: expermimental) (例: stable,test)
--include-tag <TAG...> 特定のタグを持つルールのみをロードする (例1: attack.execution,attack.discovery) (例2: wmi)
-m, --min-level <LEVEL> 結果出力をするルールの最低レベル (デフォルト: informational)
--timeline-end <DATE> 解析対象とするイベントログの終了時刻 (例: "2022-02-22 23:59:59 +09:00")
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
--timeline-start <DATE> 解析対象とするイベントログの開始時刻 (例: "2020-02-22 00:00:00 +09:00")
Output:
-o, --output <FILENAME-PREFIX> ピボットキーワードの一覧を複数ファイルに出力する (例: PivotKeywords)
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
- ピボットキーワードを画面に出力します:
hayabusa.exe pivot-keywords-list -d ../logs -m critical
- 重要なアラートからピボットキーワードのリストを作成し、その結果を保存します。(結果は、
keywords-Ip Addresses.txt
、keywords-Users.txt
等に保存されます):
hayabusa.exe pivot-keywords-list -d ../logs -m critical -o keywords
検索キーワードは、./rules/config/pivot_keywords.txt
を編集することでカスタマイズすることができます。
デフォルト設定はこちらのページです。
フォーマットは、キーワード名.フィールド名
です。例えば、Users
のリストを作成する場合、Hayabusaは、SubjectUserName
、TargetUserName
、User
フィールドにあるすべての値をリストアップします。
search
コマンドは、すべてのイベントのキーワード検索が可能です。
(※Hayabusaの検知結果だけではありません。)
Hayabusaの検知ルールでなにかの痕跡を検知できなくても、検索機能で検知できる可能性があるので、便利です。
Usage: hayabusa.exe search <INPUT> <--keywords "<KEYWORDS>" OR --regex "<REGEX>"> [OPTIONS]
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する (例1: evtx_data 例2:evtx1,evtx2)
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
Filtering:
-a, --and-logic ANDロジックでキーワード検索を行う (デフォルト: OR)
-F, --filter <FILTER...> 特定のフィールドでフィルタする
-i, --ignore-case 大文字と小文字を区別しない
-k, --keywords <KEYWORD...> キーワードでの検索
-r, --regex <REGEX> 正規表現での検索
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
Output:
-b, --disable-abbreviations 省略機能を無効にする
-J, --JSON-output JSON形式で検索結果を保存する (例: -J -o results.json)
-L, --JSONL-output JSONL形式で検索結果を保存 (例: -L -o results.jsonl)
-M, --multiline イベントフィールド情報を複数の行に出力する
-o, --output <FILE> ログオンサマリをCSV形式で保存する (例: search.csv)
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
../hayabusa-sample-evtx
ディレクトリでmimikatz
のキーワードを検索する:
hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz"
注意:
mimikatz
のキーワードがデータ内のどこかに存在する場合にマッチする。完全一致しなくても良い。
../hayabusa-sample-evtx
ディレクトリでmimikatz
またはkali
のキーワードを検索する:
hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -k "kali"
../hayabusa-sample-evtx
ディレクトリで大文字小文字を区別せずにmimikatz
のキーワードを検索する:
hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -i
../hayabusa-sample-evtx
ディレクトリで正規表現を使用し、IPアドレスを検索する:
hayabusa.exe search -d ../hayabusa-sample-evtx -r "(?:[0-9]{1,3}\.){3}[0-9]{1,3}"
../hayabusa-sample-evtx
ディレクトリでWorkstationName
フィールドがkali
の条件で、全イベントを表示する:
hayabusa.exe search -d ../hayabusa-sample-evtx -r ".*" -F WorkstationName:"kali"
※
.*
の正規表現を使用すると、すべてのイベントが表示される。
./rules/config/channel_abbreviations.txt
: チャンネル名とその略称のマッピング。
csv-timeline
やjson-timeline
などのコマンドは、デフォルトでスキャンウィザードが有効になりました。
これは、ユーザのニーズや好みに応じて、どの検知ルールを有効にするかを簡単に選択できるようにするためのものであります。
読み込む検知ルールのセットは、Sigmaプロジェクトの公式リストに基づいています。
詳細はこのブログ記事で説明されています。
w, --no-wizard
オプションを追加することで、簡単にウィザードを無効にし、従来の方法でHayabusaを使用できます。
core
ルールセットは、ステータスがtest
またはstable
かつ、レベルがhigh
またはcritical
のルールを有効にします。
これらは高品質のルールで、多くの誤検知は発生しないはずです。
ルールのステータスがtest
またはstable
であるため、6ヶ月以上の間に誤検知が報告されていません。
ルールは攻撃者の戦術、一般的な不審なアクティビティ、または悪意のある振る舞いに一致します。
これは--exclude-status deprecated,unsupported,experimental --min-level high
オプションを使用した場合と同じです。
core+
ルールセットは、ステータスがtest
またはstable
かつ、レベルがmedium
以上のルールを有効にします。
medium
ルールは、しばしば特定のアプリケーション、正当なユーザーの行動、または組織のスクリプトと一致するため、追加のチューニングが必要です。
これは--exclude-status deprecated,unsupported,experimental --min-level medium
オプションを使用した場合と同じです。
core++
ルールセットは、ステータスがexperimental
、test
、stable
のいずれかかつ、レベルがmedium
以上のルールを有効にします。
これらのルールは最先端のものです。
これらはSigmaHQプロジェクトで提供されているベースラインのevtxファイルに対して検証され、複数のエンジニアによってレビューされています。
それ以外最初は、ほとんどテストされていません。
これらは、できるだけ早く脅威を検出できる場合に使用しますが、誤検知のしきい値を高く保つのにコストがかかります。
これは--exclude-status deprecated,unsupported --min-level medium
オプションを使用した場合と同じです。
Emerging Threats (ET)
ルールセットは、detection.emerging_threats
のタグを持つルールを有効にします。
これらのルールは特定の脅威を対象とし、情報がまだほとんど入手できていない現在の脅威に特に役立ちます。
これらのルールは多くの誤検知を生成しないはずですが、時間とともに関連性が低下します。
これらのルールが無効になっている場合、--exclude-tag detection.emerging_threats
オプションを使用した場合と同じです。
ウィザードを無効にしてHayabusaを従来の方法で実行する場合、これらのルールはデフォルトで含まれます。
Threat Hunting (TH)
ルールセットは、detection.threat_hunting
のタグを持つルールを有効にします。
これらのルールは未知の悪意のあるアクティビティを検出するかもしれませんが、通常は誤検知が多くなります。
これらのルールが無効になっている場合、--exclude-tag detection.threat_hunting
オプションを使用した場合と同じです。
ウィザードを無効にしてHayabusaを従来の方法で実行する場合、これらのルールはデフォルトで含まれます。
Hayabusa v2.16.0以降、.evtx
ファイルと.yml
ルールを読み込む際にチャンネルベースのフィルタを有効にしています。
これは、必要なものだけを読み込むことで、スキャンを可能な限り効率的に行うことを目的としています。
単一のイベントログ内に複数のプロバイダが存在することはありますが、単一の.evtxファイル内に複数のチャンネルが含まれることは一般的ではありません。
(これまで見かけた唯一の例は、異なる2つの.evtxファイルを人工的に結合したsample-evtxプロジェクトです。)
この特性を利用して、スキャン対象のすべての.evtx
ファイルの最初のレコードでChannel
フィールドを確認します。
また、ルールのChannel
フィールドに指定されたチャンネルを使用する.yml
ルールも確認します。
この2つのリストを基に、実際に.evtx
ファイル内に存在するチャンネルを使用するルールだけを読み込みます。
例えば、ユーザーがSecurity.evtx
をスキャンしたい場合、Channel: Security
を指定しているルールのみが使用されます。
他の検出ルール、例えばApplication
ログのイベントのみを検出するルールなどを読み込む意味はありません。
なお、チャンネルフィールド(例: Channel: Security
)は、元のSigmaルールには明示的に定義されていません。
Sigmaルールでは、logsource
のservice
やcategory
フィールドでチャンネルやイベントIDが暗黙的に定義されています(例: service: security
)
hayabusa-rulesリポジトリでSigmaルールを管理する際には、logsource
フィールドを具体化し、チャンネルやイベントIDフィールドを明示的に定義しています。
これをどのように、そしてなぜ行うのかについては、こちらで詳しく説明しています。
現在、Channel
が定義されておらず、すべての.evtx
ファイルをスキャンするためのルールは以下の2つだけです:
これらの2つのルールを使用して、読み込んだすべての.evtx
ファイルに対してルールをスキャンしたい場合は、csv-timeline
およびjson-timeline
コマンドで-A, --enable-all-rules
オプションを追加する必要があります。
ベンチマークでは、ルールフィルタリングにより、スキャンするファイルに応じて、速度が20%から10倍に向上することが確認されています。
チャンネルフィルタリングは、.evtx
ファイルを読み込む際にも使用されます。
例えば、Security
チャンネルのイベントを探すルールを指定している場合、Security
ログではない.evtx
ファイルを読み込む意味はありません。
ベンチマークでは、通常のスキャンで約10%、単一のルールでスキャンする場合には最大60%以上の性能向上が見られました。
1つの.evtxファイル内に複数のチャンネルが使用されている場合、例えば複数の.evtx
ファイルがツールを使って結合された場合は、csv-timeline
およびjson-timeline
コマンドで-a, --scan-all-evtx-files
オプションを使用してこのフィルタリングを無効にできます。
注意: チャンネルフィルタリングは.evtxファイルでのみ動作します。-J, --json-inputでJSONファイルからイベントログを読み込み、さらに-Aや-aを指定した場合、エラーが発生します。
csv-timeline
コマンドはイベントのフォレンジックタイムラインをCSV形式で作成します。
Usage: csv-timeline <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-s, --sort-events ファイル保存前にイベントをソートする (警告: これは多くのメモリを使用する!)
-w, --no-wizard 質問はしない。すべてのイベントとアラートをスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-r, --rules <DIR/FILE> ルールファイルまたはルールファイルを持つディレクトリ (デフォルト: ./rules)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
-E, --EID-filter 速度を上げるため主なEIDだけスキャンする (コンフィグファイル: ./rules/config/target_event_IDs.txt)
-A, --enable-all-rules ロードされたevtxファイルに関係なく、すべてのルールを有効にする(ルールのチャネルフィルターを無効にする)
-D, --enable-deprecated-rules ステータスがdeprecatedのルールを有効にする
-n, --enable-noisy-rules Noisyルールを有効にする
-u, --enable-unsupported-rules ステータスがunsupportedのルールを有効にする
-e, --exact-level <LEVEL> 特定のレベルだけスキャンする (informational, low, medium, high, critical)
--exclude-category <CATEGORY...> 特定のlogsourceカテゴリを持つルールをロードしない (例: process_creation,pipe_created)
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--exclude-eid <EID...> 高速化のために特定のEIDをスキャンしない (例: 1) (例: 1,4688)
--exclude-status <STATUS...> 読み込み対象外とするルール内でのステータス (例1: experimental) (例2: stable,test)
--exclude-tag <TAG...> 特定のタグを持つルールをロードしない (例: sysmon)
--include-category <CATEGORY...> 特定のlogsourceカテゴリを持つルールのみをロードする (例: process_creation,pipe_created)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--include-eid <EID...> 指定したEIDのみをスキャンして高速化する (例: 1) (例: 1,4688)
--include-status <STATUS...> 特定のステータスを持つルールのみをロードする (例: expermimental) (例: stable,test)
--include-tag <TAG...> 特定のタグを持つルールのみをロードする (例1: attack.execution,attack.discovery) (例2: wmi)
-m, --min-level <LEVEL> 結果出力をするルールの最低レベル (デフォルト: informational)
-P, --proven-rules 実績のあるルールだけでスキャンし、高速化する (./rules/config/proven_rules.txt)
-a, --scan-all-evtx-files ロードされたルールに関係なく、すべてのevtxファイルをスキャンする(evtxファイルのチャネルフィルターを無効にする)
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
--timeline-end <DATE> 解析対象とするイベントログの終了時刻 (例: "2022-02-22 23:59:59 +09:00")
--timeline-start <DATE> 解析対象とするイベントログの開始時刻 (例: "2020-02-22 00:00:00 +09:00")
Output:
-b, --disable-abbreviations 省略機能を無効にする
-G, --GeoIP <MAXMIND-DB-DIR> IPアドレスのGeoIP(ASN、都市、国)情報を追加する
-H, --HTML-report <FILE> HTML形式で詳細な結果を出力する (例: results.html)
-M, --multiline イベントフィールド情報を複数の行に出力する
-F, --no-field-data-mapping フィールドデータのマッピングを無効にする
--no-pwsh-field-extraction PowerShell Classicログフィールド抽出の無効化
-o, --output <FILE> タイムラインを保存する (例: results.csv)
-p, --profile <PROFILE> 利用する出力プロファイル名を指定する
-R, --remove-duplicate-data 重複したフィールドデータは「DUP」に置き換えられる (ファイルサイズが約10〜15%削減される)
-X, --remove-duplicate-detections 重複した検知項目を削除する (デフォルト: 無効)
Display Settings:
-K, --no-color カラーで出力しない
-N, --no-summary 結果概要を出力しない (多少速くなる)
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
-T, --visualize-timeline 検知頻度タイムラインを出力する(ターミナルはUnicodeに対応する必要がある)
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
- デフォルトの
standard
プロファイルで1つのWindowsイベントログファイルに対してHayabusaを実行する:
hayabusa.exe csv-timeline -f eventlog.evtx
verbose
プロファイルで複数のWindowsイベントログファイルのあるsample-evtxディレクトリに対して、Hayabusaを実行する:
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -p verbose
- 全てのフィールド情報も含めて1つのCSVファイルにエクスポートして、LibreOffice、Timeline Explorer、Elastic Stack等でさらに分析することができる(注意:
super-verbose
プロファイルを使すると、出力するファイルのサイズがとても大きくなる!):
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -o results.csv -p super-verbose
- EID(イベントID)フィルタを有効にし、タイムラインをJSON形式で保存する:
注意: EIDフィルタを有効にすると、私達のテストでは処理時間が約10〜15%速くなりますが、アラートを見逃す可能性があります。
hayabusa.exe csv-timeline -E -d .\hayabusa-sample-evtx -o results.csv
- Hayabusaルールのみを実行する(デフォルトでは
-r .\rules
にあるすべてのルールが利用される):
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa -o results.csv -w
- Windowsでデフォルトで有効になっているログに対してのみ、Hayabusaルールを実行する:
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\builtin -o results.csv -w
- Sysmonログに対してのみHayabusaルールを実行する:
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv -w
- Sigmaルールのみを実行する:
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -r .\rules\sigma -o results.csv -w
- 廃棄(deprecated)されたルール(
status
がdeprecated
になっているルール)とノイジールール(.\rules\config\noisy_rules.txt
にルールIDが書かれているルール)を有効にする:
注意: 最近、廃止されたルールはSigmaリポジトリで別のディレクトリに置かれるようになり、Hayabusaではもうデフォルトでは含まれないようになりました。 従って、廃止されたルールを有効にする必要はないでしょう。
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx --enable-noisy-rules --enable-deprecated-rules -o results.csv -w
- ログオン情報を分析するルールのみを実行し、UTCタイムゾーンで出力する:
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\builtin\Security\LogonLogoff\Logon -U -o results.csv -w
- 起動中のWindows端末上で実行し(Administrator権限が必要)、アラート(悪意のある可能性のある動作)のみを検知する:
hayabusa.exe csv-timeline -l -m low
- 詳細なメッセージを出力する(処理に時間がかかるファイル、パースエラー等を特定するのに便利):
hayabusa.exe csv-timeline -d .\hayabusa-sample-evtx -v
- Verbose出力の例:
ルールファイルの読み込み:
Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_susp_run_folder.yml
Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_execution_mssql_xp_cmdshell_stored_procedure.yml
Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_susp_squirrel_lolbin.yml
Loaded rule: rules/sigma/builtin/win_alert_mimikatz_keywords.yml
スキャン中のエラー:
[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Rdms-UI%4Operational.evtx
Error: Failed to parse record number 58471
[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Rdms-UI%4Operational.evtx
Error: Failed to parse record number 58470
[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Windows-AppxPackaging%4Operational.evtx
Error: An error occurred while trying to serialize binary xml to output.
- 結果をTimesketchにインポートできるCSV形式に保存する:
hayabusa.exe csv-timeline -d ../hayabusa-sample-evtx --RFC-3339 -o timesketch-import.csv -p timesketch -U
- エラーログの出力をさせないようにする:
デフォルトでは、Hayabusaはエラーメッセージをエラーログに保存します。
エラーメッセージを保存したくない場合は、
-Q
を追加してください。
無償のGeoLite2のジオロケーションデータで、SrcIP(ソースIPアドレス)フィールドとTgtIP(ターゲットIPアドレス)フィールドにGeoIP(ASN組織、都市、国)情報を追加することができます。
手順:
- まずMaxMindのアカウントをこちらで登録してください。
- ダウンロードページから3つの
.mmdb
ファイルをダウンロードし、ディレクトリに保存してください。ファイル名は、GeoLite2-ASN.mmdb
、GeoLite2-City.mmdb
、GeoLite2-Country.mmdb
であることをご確認ください。 csv-timeline
またはjson-timeline
コマンドを実行する際には、-G
オプションの後にMaxMindデータベースのあるディレクトリを追加してください。
-
csv-timeline
を使用すると、次の6つのカラムが追加で出力されます:SrcASN
、SrcCity
、SrcCountry
、TgtASN
、TgtCity
、TgtCountry
-
json-timeline
を使用すると、同じSrcASN
、SrcCity
、SrcCountry
、TgtASN
、TgtCity
、TgtCountry
フィールドがDetails
オブジェクトに追加されますが、情報を含む場合のみとなります。 -
SrcIP
またはTgtIP
がlocalhost (127.0.0.1
、::1
等々)の場合、SrcASN
またはTgtASN
は、Local
として出力されます。 -
SrcIP
またはTgtIP
がプライベートIPアドレス (10.0.0.0/8
、fe80::/10
等々)の場合、SrcASN
またはTgtASN
は、Private
として出力されます。
GeoIPデータベースで検索される送信元と送信先のIPアドレスを含むフィールド名は、rules/config/geoip_field_mapping.yaml
で定義されています。
必要であれば、このリストに追加することができます。
また、このファイルには、どのイベントからIPアドレス情報を抽出するかを決定するフィルタセクションもあります。
MaxMind GeoIP データベースは、2 週間ごとに更新されます。
これらのデータベースを自動的に更新するために、こちらからMaxMindのgeoipupdate
のツールをインストールすることができます。
macOSでの手順:
brew install geoipupdate
/usr/local/etc/GeoIP.conf
を編集する: MaxMindのウェブサイトにログインした後に作成したAccountID
とLicenseKey
を入れる。EditionIDs
の行に、EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country
とあることを確認する。geoipupdate
を実行する。- GeoIP情報を追加する場合は、
-G /usr/local/var/GeoIP
を追加する。
Windowsでの手順:
- ReleasesページからWindowsバイナリの最新版(例:
geoipupdate_4.10.0_windows_amd64.zip
)をダウンロードする。 \ProgramData\MaxMind/GeoIPUpdate\GeoIP.conf
を編集する: MaxMindのウェブサイトにログインした後に作成したAccountID
とLicenseKey
を入れる。EditionIDs
の行に、EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country
とあることを確認する。geoipupdate
を実行する。
./rules/config/channel_abbreviations.txt
: チャンネル名とその略称のマッピング。
./rules/config/default_details.txt
: ルールにdetails:
行が指定されていない場合に、どのようなデフォルトのフィールド情報 (%Details%
フィールド)を出力するかを設定するファイルです。
プロバイダー名とイベントIDを元に作成されます。
./rules/config/eventkey_alias.txt
: このファイルには、フィールドの短い名前のエイリアスと、元の長いフィールド名のマッピングがあります。
例:
InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress
ここでフィールドが定義されていない場合、Hayabusaは自動的にEvent.EventData
にあるフィールドを使用してみます。
./rules/config/exclude_rules.txt
: このファイルには、使用から除外されるルールIDのリストがあります。
通常は、あるルールが別のルールに置き換わったか、そもそもそのルールが使用できないことが原因です。
ファイアウォールやIDSと同様に、シグネチャベースのツールは、自身の環境に合わせてチューニングする必要があるため、特定のルールを恒久的または一時的に除外する必要があるかもしれません。
./rules/config/exclude_rules.txt
にルールID (例:4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6
)を追加すると、不要なルールや使用できないルールを無視できます。
./rules/config/noisy_rules.txt
: このファイルには、デフォルトでは無効になっているルールのIDが入っています。-n, --enable-noisy-rules
オプションでノイジールールを有効にできます。
これらのルールは通常、性質上ノイズが多いか、誤検出があるためです。
./rules/config/target_event_IDs.txt
: EIDフィルターが有効な場合、このファイルで指定されたイベントIDのみがスキャンされます。
デフォルトでは、Hayabusaはすべてのイベントをスキャンしますが、パフォーマンスを向上させたい場合は、-E, --EID-filter
オプションを使用してください。
これにより、通常10〜25%の速度向上があります。
json-timeline
コマンドは、JSONまたはJSONL形式でイベントのフォレンジックタイムラインを作成します。
JSONLへの出力は、JSONよりも高速でファイルサイズも小さいので、結果をElastic Stack等の他のツールにインポートするだけなら、JSONLが理想です。
テキストエディタで手動で解析する場合は、JSONの方が良いでしょう。
CSV出力は小さいタイムライン(通常2GB以下)をLibreOfficeやTimeline Explorerのようなツールにインポートするのに適しています。
JSONは、jq
等のツールでデータ(大きな結果ファイルを含む)をより詳細に分析する場合に最適です。Details
フィールドが分離されているので、分析が容易になるからです。
(CSV出力では、すべてのイベントログのフィールドが1つの大きなDetails
カラムに入っており、データのソートなどが難しくなっています。)
Usage: json-timeline <INPUT> [OPTIONS]
Input:
-d, --directory <DIR> .evtxファイルを持つディレクトリのパス
-f, --file <FILE> 1つの.evtxファイルに対して解析を行う
-l, --live-analysis ローカル端末のC:\Windows\System32\winevt\Logsフォルダを解析する
General Options:
-C, --clobber 結果ファイルを上書きする
-h, --help ヘルプメニューを表示する
-J, --JSON-input .evtxファイルの代わりにJSON形式のログファイル(.jsonまたは.jsonl)をスキャンする
-s, --sort-events ファイル保存前イベントをソートする (警告: これは多くのメモリを使用する!)
-w, --no-wizard 質問はしない。すべてのイベントとアラートをスキャンする
-Q, --quiet-errors Quiet errorsモード: エラーログを保存しない
-x, --recover-records 空ページからevtxレコードをカービングする (デフォルト: 無効)
-r, --rules <DIR/FILE> ルールファイルまたはルールファイルを持つディレクトリ (デフォルト: ./rules)
-c, --rules-config <DIR> ルールフォルダのコンフィグディレクトリ (デフォルト: ./rules/config)
-t, --threads <NUMBER> スレッド数 (デフォルト: パフォーマンスに最適な数値)
--target-file-ext <FILE-EXT...> evtx以外の拡張子を解析対象に追加する。 (例1: evtx_data 例2: evtx1,evtx2)
Filtering:
-E, --EID-filter 速度を上げるため主なEIDだけスキャンする (コンフィグファイル: ./rules/config/target_event_IDs.txt)
-A, --enable-all-rules ロードされたevtxファイルに関係なく、すべてのルールを有効にする(ルールのチャネルフィルターを無効にする)
-D, --enable-deprecated-rules ステータスがdeprecatedのルールを有効にする
-n, --enable-noisy-rules Noisyルールを有効にする
-u, --enable-unsupported-rules ステータスがunsupportedのルールを有効にする
-e, --exact-level <LEVEL> 特定のレベルだけスキャンする (informational, low, medium, high, critical)
--exclude-category <CATEGORY...> 特定のlogsourceカテゴリを持つルールをロードしない (例: process_creation,pipe_created)
--exclude-computer <COMPUTER...> 特定のコンピュータ名をスキャンしない (例: ComputerA) (例: ComputerA,ComputerB)
--exclude-eid <EID...> 高速化のために特定のEIDをスキャンしない (例: 1) (例: 1,4688)
--exclude-status <STATUS...> 読み込み対象外とするルール内でのステータス (例1: experimental) (例2: stable,test)
--exclude-tag <TAG...> 特定のタグを持つルールをロードしない (例: sysmon)
--include-category <CATEGORY...> 特定のlogsourceカテゴリを持つルールのみをロードする (例: process_creation,pipe_created)
--include-computer <COMPUTER...> 特定のコンピュータ名のみをスキャンする (例: ComputerA) (例: ComputerA,ComputerB)
--include-eid <EID...> 指定したEIDのみをスキャンして高速化する (例: 1) (例: 1,4688)
--include-status <STATUS...> 特定のステータスを持つルールのみをロードする (例: expermimental) (例: stable,test)
--include-tag <TAG...> 特定のタグを持つルールのみをロードする (例1: attack.execution,attack.discovery) (例2: wmi)
-m, --min-level <LEVEL> 結果出力をするルールの最低レベル (デフォルト: informational)
-P, --proven-rules 実績のあるルールだけでスキャンし、高速化する (./rules/config/proven_rules.txt)
-a, --scan-all-evtx-files ロードされたルールに関係なく、すべてのevtxファイルをスキャンする(evtxファイルのチャネルフィルターを無効にする)
--time-offset <OFFSET> オフセットに基づく最近のイベントのスキャン (例: 1y, 3M, 30d, 24h, 30m)
--timeline-end <DATE> 解析対象とするイベントログの終了時刻 (例: "2022-02-22 23:59:59 +09:00")
--timeline-start <DATE> 解析対象とするイベントログの開始時刻 (例: "2020-02-22 00:00:00 +09:00")
Output:
-b, --disable-abbreviations 省略機能を無効にする
-G, --GeoIP <MAXMIND-DB-DIR> IPアドレスのGeoIP(ASN、都市、国)情報を追加する
-H, --HTML-report <FILE> HTML形式で詳細な結果を出力する (例: results.html)
-L, --JSONL-output タイムラインをJSONL形式で保存する (例: -L -o results.jsonl)
-F, --no-field-data-mapping フィールドデータのマッピングを無効にする
--no-pwsh-field-extraction PowerShell Classicログフィールド抽出の無効化
-o, --output <FILE> タイムラインを保存する (例: results.csv)
-p, --profile <PROFILE> 利用する出力プロファイル名を指定する
-R, --remove-duplicate-data 重複したフィールドデータは「DUP」に置き換えられる (ファイルサイズが約10〜15%削減される)
-X, --remove-duplicate-detections 重複した検知項目を削除する (デフォルト: 無効)
Display Settings:
-K, --no-color カラーで出力しない
-N, --no-summary 結果概要を出力しない (多少速くなる)
-q, --quiet Quietモード: 起動バナーを表示しない
-v, --verbose 詳細な情報を出力する
-T, --visualize-timeline 検知頻度タイムラインを出力する(ターミナルはUnicodeに対応する必要がある)
Time Format:
--European-time ヨーロッパ形式で日付と時刻を出力する (例: 22-02-2022 22:00:00.123 +02:00)
-O, --ISO-8601 ISO-8601形式で日付と時刻を出力する (例: 2022-02-22T10:10:10.1234567Z) (UTC時刻)
--RFC-2822 RFC 2822形式で日付と時刻を出力する (例: Fri, 22 Feb 2022 22:00:00 -0600)
--RFC-3339 RFC 3339形式で日付と時刻を出力する (例: 2022-02-22 22:00:00.123456-06:00)
--US-military-time 24時間制(ミリタリータイム)のアメリカ形式で日付と時刻を出力する (例: 02-22-2022 22:00:00.123 -06:00)
--US-time アメリカ形式で日付と時刻を出力する (例: 02-22-2022 10:00:00.123 PM -06:00)
-U, --UTC UTC形式で日付と時刻を出力する (デフォルト: 現地時間)
json-timeline
のオプションと設定ファイルは、csv-timeline
と同じですが、JSONL形式で出力するための-L, --JSONL-output
オプションが1つ追加されています。
level-tuning
コマンドを使用すると、環境に応じてリスクレベルを上げたり下げたりして、ルールのアラートレベルを調整できます。
Usage: level-tuning [OPTIONS]
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
General Options:
-f, --file <FILE> ルールlevelのチューニング (デフォルト: ./rules/config/level_tuning.txt)
-h, --help ヘルプメニューを表示する
- 通常使用:
hayabusa.exe level-tuning
- カスタム設定ファイルに基づくルールのアラートレベルの調整:
hayabusa.exe level-tuning -f my_level_tuning.txt
HayabubsaとSigmaのルール作成者は、アラートのリスクレベルを判定してルールを作成します。
しかし、実際のリスクレベルは環境に応じて異なる場合があります。
./rules/config/level_tuning.txt
にルールを追加して hayabusa.exe level-tuning
を実行すると、ルールファイル内のlevel
行が更新され、リスクレベルを調整することができます。
ルールファイルが直接更新されますので、ご注意ください。
注意:
update-rules
を実行するたびに、アラートレベルが元の設定に上書きされるので、レベルを変更したい場合は、update-rules
を実行した後に、level-tuning
コマンドも実行する必要があります。
./rules/config/level_tuning.txt
の一例:
id,new_level
00000000-0000-0000-0000-000000000000,informational # レベルチューニングのサンプル
この場合、ルールディレクトリ内のid
が00000000-0000-0000000000
のルールのアラートlevel
が、informational
に書き換えられます。
設定可能なレベルは、critical
、high
、medium
、low
、informational
です。
Usage: list-profiles [OPTIONS]
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
General Options:
-h, --help ヘルプメニューを表示する
Usage: set-default-profile [OPTIONS]
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
General Options:
-h, --help ヘルプメニューを表示する
-p, --profile <PROFILE> 利用する出力プロファイル名を指定する
- デフォルトプロファイルを
minimal
に設定する:hayabusa.exe set-default-profile minimal
- デフォルトプロファイルを
super-verbose
に設定する:hayabusa.exe set-default-profile super-verbose
update-rules
コマンドは、rules
フォルダをHayabusaルールのGitHubリポジトリと同期し、ルールと設定ファイルを更新します。
Usage: update-rules [OPTIONS]
Display Settings:
-K, --no-color カラーで出力しない
-q, --quiet Quietモード: 起動バナーを表示しない
General Options:
-h, --help ヘルプメニューを表示する
-r, --rules <DIR/FILE> ルールファイルまたはルールファイルを持つディレクトリ (デフォルト: ./rules)
普段は次のように実行します: hayabusa.exe update-rules
Hayabusaのconfig/profiles.yaml
設定ファイルでは、5つのプロファイルが定義されています:
minimal
standard
(デフォルト)verbose
all-field-info
all-field-info-verbose
super-verbose
timesketch-minimal
timesketch-verbose
このファイルを編集することで、簡単に独自のプロファイルをカスタマイズしたり、追加したりすることができます。
set-default-profile --profile <profile>
コマンドでデフォルトのプロファイルを変更することもできます。
利用可能なプロファイルとそのフィールド情報を表示するには、list-profiles
コマンドを使用してください。
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
最小限のdetails
情報を出力する代わりに、イベントにあるすべてのEventData
フィールド情報(%AllFieldInfo%
)が出力されます。フィールド名は元々のフィールド名になります。
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RuleTitle%, %RuleAuthor%, %RuleModifiedDate%, %Status%, %RecordID%, %Details%, %ExtraFieldInfo%, %MitreTactics%, %MitreTags%, %OtherTags%, %Provider%, %RuleCreationDate%, %RuleFile%, %EvtxFile%
Timesketchにインポートできるプロファイル。
%Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %RuleFile%, %EvtxFile%
%Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
以下のベンチマークは、2018年製のLenovo P51 (CPU: Xeon 4コア / メモリ: 64GB)上で3GBのEVTXデータに対して3891件のルールを有効にして実施されました。(2023/06/01)
プロファイル | 処理時間 | 結果のファイルサイズ | ファイルサイズ増加 |
---|---|---|---|
minimal | 8分50秒 | 770 MB | -30% |
standard (デフォルト) | 9分00秒 | 1.1 GB | 無し |
verbose | 9分10秒 | 1.3 GB | +20% |
all-field-info | 9分3秒 | 1.2 GB | +10% |
all-field-info-verbose | 9分10秒 | 1.3 GB | +20% |
super-verbose | 9分12秒 | 1.5 GB | +35% |
ビルトインの出力プロファイルで出力できる情報は以下の通り:
エイリアス名 | Hayabusaの出力情報 |
---|---|
%AllFieldInfo% | すべてのフィールド情報。 |
%Channel% | ログ名。イベントログの<Event><System><EventID> フィールド。 |
%Computer% | イベントログの<Event><System><Computer> フィールド。 |
%Details% | YML検知ルールのdetails フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログのフィールドから有用なデータを抽出することができます。イベントキーのマッピングが間違っている場合、もしくはフィールドが存在しない場合で抽出ができなかった箇所はn/a (not available)と記載されます。YML検知ルールにdetails フィールドが存在しない時のdetailsのメッセージを./rules/config/default_details.txt で設定できます。default_details.txt ではProvider Name 、EventID 、details の組み合わせで設定することができます。default_details.txt`やYML検知ルールに対応するルールが記載されていない場合はすべてのフィールド情報を出力します。 |
%ExtraFieldInfo% | %Details%で出力されなかったフィールドデータを出力する。 |
%EventID% | イベントログの<Event><System><EventID> フィールド。 |
%EvtxFile% | アラートまたはイベントを起こしたevtxファイルへのパス。 |
%Level% | YML検知ルールのlevel フィールド。(例:informational 、low 、medium 、high 、critical ) |
%MitreTactics% | MITRE ATT&CKの戦術 (例: Initial Access、Lateral Movement等々) |
%MitreTags% | MITRE ATT&CKの戦術以外の情報。attack.g(グループ)、attack.t(技術)、attack.s(ソフトウェア)の情報を出力する。 |
%OtherTags% | YML検知ルールのtags フィールドからMitreTactics 、MitreTags 以外のキーワードを出力する。 |
%Provider% | <Event><System><Provider> フィールド内のName 属性。 |
%RecordID% | <Event><System><EventRecordID> フィールドのイベントレコードID。 |
%RuleAuthor% | YML検知ルールの author フィールド。 |
%RuleCreationDate% | YML検知ルールの date フィールド。 |
%RuleFile% | アラートまたはイベントを生成した検知ルールのファイル名。 |
%RuleModifiedDate% | YML検知ルールの modified フィールド。 |
%RuleTitle% | YML検知ルールのtitle フィールド。 |
%Status% | YML検知ルールの status フィールド。 |
%Timestamp% | デフォルトではYYYY-MM-DD HH:mm:ss.sss +hh:mm 形式になっている。イベントログの<Event><System><TimeCreated SystemTime> フィールドから来ている。デフォルトのタイムゾーンはローカルのタイムゾーンになるが、--UTC オプションでUTCに変更することができる。 |
必要であれば、これらのエイリアスを出力プロファイルに追加することもできます:
エイリアス名 | Hayabusaの出力情報 |
---|---|
%RenderedMessage% | WEC機能で転送されたイベントログの<Event><RenderingInfo><Message> フィールド。 |
%RuleID% | YML検知ルールのid フィールド。 |
注意: これらはビルトインプロファイルには含まれていないので、手動でconfig/default_profile.yaml
ファイルを編集し、以下の行を追加する必要があります:
Message: "%RenderedMessage%"
RuleID: "%RuleID%"
また、イベントキーエイリアスを定義し、出力することもできます。
結果をミニマルにするため、レベル、MITRE ATT&CK戦術、チャンネル、プロバイダ、フィールド名などを省略しています。
b, --disable-abbreviations
オプションで、これらの省略のいくつかを無効にして、元々のチャンネル名、プロバイダ名などを表示することができます。
簡潔に出力するためにlevel
を以下のように省略し出力しています。
crit
:critical
high
:high
med
:medium
low
:low
info
:informational
簡潔に出力するためにMITRE ATT&CKの戦術を以下のように省略しています。
./config/mitre_tactics.txt
の設定ファイルで自由に編集できます。
Recon
: Reconnaissance (偵察)ResDev
: Resource Development (リソース開発)InitAccess
: Initial Access (初期アクセス)Exec
: Execution (実行)Persis
: Persistence (永続化)PrivEsc
: Privilege Escalation (権限昇格)Evas
: Defense Evasion (防御回避)CredAccess
: Credential Access (認証情報アクセス)Disc
: Discovery (探索)LatMov
: Lateral Movement (横展開)Collect
: Collection (収集)C2
: Command and Control (遠隔操作)Exfil
: Exfiltration (持ち出し)Impact
: Impact (影響)
簡潔に出力するためにChannelの表示を以下のように省略しています。
./rules/config/channel_abbreviations.txt
の設定ファイルで自由に編集できます。
App
:Application
AppLocker
:Microsoft-Windows-AppLocker/*
BitsCli
:Microsoft-Windows-Bits-Client/Operational
CodeInteg
:Microsoft-Windows-CodeIntegrity/Operational
Defender
:Microsoft-Windows-Windows Defender/Operational
DHCP-Svr
:Microsoft-Windows-DHCP-Server/Operational
DNS-Svr
:DNS Server
DvrFmwk
:Microsoft-Windows-DriverFrameworks-UserMode/Operational
Exchange
:MSExchange Management
Firewall
:Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
KeyMgtSvc
:Key Management Service
LDAP-Cli
:Microsoft-Windows-LDAP-Client/Debug
NTLM
Microsoft-Windows-NTLM/Operational
OpenSSH
:OpenSSH/Operational
PrintAdm
:Microsoft-Windows-PrintService/Admin
PrintOp
:Microsoft-Windows-PrintService/Operational
PwSh
:Microsoft-Windows-PowerShell/Operational
PwShClassic
:Windows PowerShell
RDP-Client
:Microsoft-Windows-TerminalServices-RDPClient/Operational
Sec
:Security
SecMitig
:Microsoft-Windows-Security-Mitigations/*
SmbCliSec
:Microsoft-Windows-SmbClient/Security
SvcBusCli
:Microsoft-ServiceBus-Client
Sys
:System
Sysmon
:Microsoft-Windows-Sysmon/Operational
TaskSch
:Microsoft-Windows-TaskScheduler/Operational
WinRM
:Microsoft-Windows-WinRM/Operational
WMI
:Microsoft-Windows-WMI-Activity/Operational
できるだけ簡潔にするために、以下の略語を使用しています:
Acct
-> AccountAddr
-> AddressAuth
-> AuthenticationCli
-> ClientChan
-> ChannelCmd
-> CommandCnt
-> CountComp
-> ComputerConn
-> Connection/ConnectedCreds
-> CredentialsCrit
-> CriticalDisconn
-> Disconnection/DisconnectedDir
-> DirectoryDrv
-> DriverDst
-> DestinationEID
-> Event IDErr
-> ErrorExec
-> ExecutionFW
-> FirewallGrp
-> GroupImg
-> ImageInj
-> InjectionKrb
-> KerberosLID
-> Logon IDMed
-> MediumNet
-> NetworkObj
-> ObjectOp
-> Operational/OperationProto
-> ProtocolPW
-> PasswordReconn
-> ReconnectionReq
-> RequestRsp
-> ResponseSess
-> SessionSig
-> SignatureSusp
-> SuspiciousSrc
-> SourceSvc
-> ServiceSvr
-> ServerTemp
-> TemporaryTerm
-> Termination/TerminatedTkt
-> TicketTgt
-> TargetUnkwn
-> UnknownUsr
-> UserPerm
-> PermamentPkg
-> PackagePriv
-> PrivilegeProc
-> ProcessPID
-> Process IDPGUID
-> Process GUID (Global Unique ID)Ver
-> Version
プログレス・バーは、複数のevtxファイルに対してのみ機能します。 解析したevtxファイルの数と割合をリアルタイムで表示します。
Hayabusaの結果はlevel
毎に文字色が変わります。
./config/level_color.txt
の値を変更することで文字色を変えることができます。形式はlevel名,(6桁のRGBのカラーhex)
です。
カラー出力をしないようにしたい場合は--no-color
オプションをご利用ください。
元々のイベント数、検知したイベント数、データ削減の統計、検知数情報、最多検知日、最多検知端末名、最多アラート等の情報がスキャン後に出力されます。
-T, --visualize-timeline
オプションを使うことで、検知したイベントの数が5以上の時、頻度のタイムライン(スパークライン)を画面に出力します。
マーカーの数は最大10個です。デフォルトのCommand PromptとPowerShell Promptでは文字化けがでるので、Windows TerminalやiTerm2等のターミナルをご利用ください。
Hayabusa検知ルールはSigmaのようなYML形式で記述され、rules
ディレクトリに入っています。
https://github.com/Yamato-Security/hayabusa-rulesのレポジトリで管理しているので、ルールのissueやpull requestはhayabusaのレポジトリではなく、ルールレポジトリへお願いします。
ルールの作成方法については、hayabusa-rulesレポジトリのREADME をお読みください。
hayabusa-rulesレポジトリにあるすべてのルールは、rules
フォルダに配置する必要があります。
level
がinformationのルールはイベント
とみなされ、low
以上はアラート
とみなされます。
Hayabusaルールのディレクトリ構造は、2つのディレクトリに分かれています:
builtin
: Windowsの組み込み機能で生成できるログ。sysmon
: sysmonによって生成されるログ。
ルールはさらにログタイプ(例:Security、Systemなど)によってディレクトリに分けられ、次の形式で名前が付けられます。
現在のルールをご確認いただき、新規作成時のテンプレートとして、また検知ロジックの確認用としてご利用ください。
Hayabusaは、logsource
フィールドを内部で処理することを唯一の例外として、Sigmaルールをネイティブにサポートしています。
過検知を減らすため、コンバータで変換した方が良いです。変換のやり方はここで説明されています。
これにより、適切なChannel
とEventID
が追加され、process_creation
のような特定のカテゴリに対してフィールドマッピングが行われます。
殆どのルールはSigmaルールと互換性があるので、Sigmaルールのようにその他のSIEM形式に変換できます。 Hayabusaルールは、Windowsのイベントログ解析専用に設計されており、以下のような利点があります:
- ログの有用なフィールドのみから抽出された追加情報を表示するための
details
フィールドを追加しています。 - Hayabusaルールはすべてサンプルログに対してテストされ、検知することが確認されています。
- Sigmaルール仕様にない集計式(例:
|equalsfield
、|endswithfield
)の利用。
私たちの知る限り、HayabusaはオープンソースのWindowsイベントログ解析ツールの中でSigmaルールを最も多くサポートしています。
- APT-Hunter - Pythonで開発された攻撃検知ツール。
- Awesome Event IDs - フォレンジック調査とインシデント対応に役立つイベントIDのリソース。
- Chainsaw - Rustで開発されたSigmaベースの攻撃検知ツール。
- DeepBlueCLI - Eric Conrad によってPowershellで開発された攻撃検知ツール。
- Epagneul - Windowsイベントログの可視化ツール。
- EventList - Miriam Wiesnerによるセキュリティベースラインの有効なイベントIDをMITRE ATT&CKにマッピングするPowerShellツール。
- MITRE ATT&CKとWindowイベントログIDのマッピング - 作者:Michel de CREVOISIER
- EvtxECmd - Eric ZimmermanによるEvtxパーサー。
- EVTXtract - 未使用領域やメモリダンプからEVTXファイルを復元するツール。
- EvtxToElk - Elastic StackにEvtxデータを送信するPythonツール。
- EVTX ATTACK Samples - SBousseaden によるEVTX攻撃サンプルイベントログファイル。
- EVTX-to-MITRE-Attack - Michel de CREVOISIERによるATT&CKにマッピングされたEVTX攻撃サンプルログのレポジトリ。
- EVTX parser - @OBenamram によって書かれた、Hayabusaが使用しているRustライブラリ。
- Grafiki - SysmonとPowerShellログの可視化ツール。
- LogonTracer - JPCERTCC による、横方向の動きを検知するためにログオンを視覚化するグラフィカルなインターフェース。
- NSA Windows Event Monitoring Guidance - NSAのWindowsイベントログ監視ガイド。
- RustyBlue - 大和セキュリティによるDeepBlueCLIのRust版。
- Sigma - コミュニティベースの汎用SIEMルール。
- SOF-ELK - Phil Hagen によるDFIR解析用のElastic Stack VM。
- so-import-evtx - evtxファイルをSecurityOnionにインポートするツール。
- SysmonTools - Sysmonの設定とオフライン可視化ツール。
- Timeline Explorer - Eric Zimmerman による最高のCSVタイムラインアナライザ。
- Windows Event Log Analysis - Analyst Reference - Forward DefenseのSteve AnsonによるWindowsイベントログ解析の参考資料。
- Zircolite - Pythonで書かれたSigmaベースの攻撃検知ツール。
Windows機での悪性な活動を検知する為には、デフォルトのログ設定を改善することが必要です。 どのようなログ設定を有効にする必要があるのか、また、自動的に適切な設定を有効にするためのスクリプトを、別のプロジェクトとして作成しました: https://github.com/Yamato-Security/EnableWindowsLogSettings
以下のサイトを閲覧することもおすすめします。:
- JSCU-NL (Joint Sigint Cyber Unit Netherlands) Logging Essentials
- ACSC (Australian Cyber Security Centre) Logging and Fowarding Guide
- Malware Archaeology Cheat Sheets
フォレンジックに有用な証拠を作り、高い精度で検知をさせるためには、sysmonをインストールする必要があります。以下のサイトを参考に設定することをおすすめします。:
- Sysmon Modular
- TrustedSec Sysmon Community Guide
- SwiftOnSecurityのSysmon設定ファイル
- Neo23x0によるSwiftOnSecurityのSysmon設定ファイルのフォーク
- ion-stormによるSwiftOnSecurityのSysmon設定ファイルのフォーク
- 2023/12/11 Christian Henriksen氏によるUnleashing the Hayabusa Feathers: My Top Features Revealed!
- 2023/10/16 Md. Mahim Bin Firoj氏によるIncident response and threat hunting using hayabusa tool
- 2023/03/21 Eric Capuano氏によるFind Threats in Event Logs with Hayabusa
- 2023/03/14 Fukusuke Takahashi氏によるHayabusa開発者向けRustパフォーマンスガイド
- 2022/06/19 Eric Capuano氏によるVelociraptorチュートリアルとHayabusaの統合方法
- 2022/01/24 Matthew Seyer (@forensic_matt)氏によるHayabusa結果をneo4jで可視化する方法
- 2024/01/24 NECセキュリティブログ: LME × Hayabusa - Windowsイベントログの集約と解析の効率化
- 2023/09/29 NECセキュリティブログ: HayabusaとSplunkによるファストフォレンジック効率化
- 2023/09/13 FFRIセキュリティブログ: HayabusaによるWindowsイベントログ解析
- 2023/03/14 Fukusuke Takahashi氏によるHayabusa開発者向けRustパフォーマンスガイド
- 2022/01/22 @kzzzzo2氏によるHayabusa結果をElastic Stackで可視化する方法
- 2021/12/31 itiB (@itiB_S144)氏によるWindowsイベントログ解析ツール「Hayabusa」を使ってみる
- 2021/12/27 Kazuminn (@k47_um1n)氏によるHayabusaの中身
どのような形でも構いませんので、ご協力をお願いします。 プルリクエスト、ルール作成、evtxログのサンプルなどがベストですが、機能リクエスト、バグの通知なども大歓迎です。
少なくとも、私たちのツールを気に入っていただけたなら、GitHubで星を付けて、あなたのサポートを表明してください。
見つけたバグをこちらでご連絡ください。 報告されたバグを喜んで修正します!
Hayabusaルールの問題点(誤検出、バグ等々)を発見された方は、hayabusa-rulesのGitHubのIssuesページにご報告ください。
Sigmaルールの問題点(誤検出、バグ等々)を発見された方は、上流のSigmaHQ GitHubのIssuesページにご報告ください。
HayabusaはAGPLv3で公開され、すべてのルールはDetection Rule License (DRL) 1.1で公開されています。 Hayabusaの社内利用、SaaSソリューションの利用、コンサルティングの利用などは自由です。 ただし、SaaS型ソリューションでHayabusaを利用し、改良を加えた場合は、その改良をオープンソース化し、プロジェクトに還元してください。
Hayabusaは、MaxMind社が作成したGeoLite2データを使用しており、https://www.maxmind.comから入手可能です。
@SecurityYamatoでHayabusa、ルール更新、その他の大和セキュリティツール等々について情報を提供しています。