diff --git a/README-English.md b/README-English.md index 517c8187..e0f7c5b7 100644 --- a/README-English.md +++ b/README-English.md @@ -24,18 +24,29 @@ Hayabusa is not intended to be a replacement for tools like [Evtx Explorer](http # Screenshots ## Startup: -![Hayabusa Startup](/screenshots/hayabusa-start.png) +![Hayabusa Startup](/screenshots/Hayabusa-Startup.png) ## Terminal output: -![Hayabusa terminal output](/screenshots/hayabusa-results.png) +![Hayabusa terminal output](/screenshots/Hayabusa-Results.png) ## Results summary: -![Hayabusa results summary](/screenshots/hayabusa-results-summary.png) +![Hayabusa results summary](/screenshots/HayabusaResultsSummary.png) +## Analysis in Excel: + +![Hayabusa analysis in Excel](/screenshots/ExcelScreenshot.png) + +## Analysis in Timeline Explorer: + +![Hayabusa analysis in Timeline Explorer](screenshots/TimelineExplorer-ColoredTimeline.png) + +## Critical alert filtering and computer grouping in Timeline Explorer: + +![Critical alert filtering and computer grouping in Timeline Explorer](screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png) # Features * Cross-platform support: Windows, Linux, macOS @@ -61,18 +72,10 @@ Hayabusa is not intended to be a replacement for tools like [Evtx Explorer](http You can `git clone` the repository with the following command: ```bash -git clone --recurse-submodules https://github.com/Yamato-Security/hayabusa.git +git clone https://github.com/Yamato-Security/hayabusa.git ``` -> Note: The rules are located in a [different repository](https://github.com/Yamato-Security/hayabusa-rules/) and managed as a sub-module so you need to add the --recurse-submodules option. - -If you forget to clone the repository with the `--recurse-submodules` option, you can download the rules into the `hayabusa\rules` directory with the following command: - -```bash -git submodule update -i -``` - -Optionally,, you can also manually download and extract Hayabusa from [https://github.com/Yamato-Security/hayabusa](https://github.com/Yamato-Security/hayabusa) and the rules from [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules) and save the rules to a new `rules` directory. +You can also manually download and extract Hayabusa from [https://github.com/Yamato-Security/hayabusa](https://github.com/Yamato-Security/hayabusa). After that, you need to download a pre-compiled binary for the Windows, Linux or macOS at the [Releases](https://github.com/Yamato-Security/hayabusa/releases) page and save it to the `hayabusa` root folder. @@ -172,22 +175,45 @@ hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low hayabusa.exe -f Security.evtx -s ``` +* Print verbose information (useful for determining which files take long to process, etc...): +```bash +hayabusa.exe -d .\hayabusa-sample-evtx -v +``` + +* Verbose output example: +```bash +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1027.004_Obfuscated Files or Information\u{a0}Compile After Delivery/sysmon.evtx" +1 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.20 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1558.004_Steal or Forge Kerberos Tickets AS-REP Roasting/Security.evtx" +2 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.39 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1558.003_Steal or Forge Kerberos Tickets\u{a0}Kerberoasting/Security.evtx" +3 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.59 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1197_BITS Jobs/Windows-BitsClient.evtx" +4 / 509 [=>------------------------------------------------------------------------------------------------------------------------------------------] 0.79 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1218.004_Signed Binary Proxy Execution\u{a0}InstallUtil/sysmon.evtx" +5 / 509 [=>------------------------------------------------------------------------------------------------------------------------------------------] 0.98 % 1s +``` + # Hayabusa output When Hayabusa output is being displayed to the screen (the default), it will display the following information: * `Timestamp`: Default is `YYYY-MM-DD HH:mm:ss.sss +hh:mm` format. This comes from the `` field in the event log. The default timezone will be the local timezone but you can change the timezone to UTC with the `--utc` option. -* `Computer name`: This comes from the `` field in the event log. -* `Event ID`: This comes from the `` field in the event log. +* `Computer`: This comes from the `` field in the event log. +* `Event ID`: This comes from the `` field in the event log. * `Level`: This comes from the `level` field in the YML detection rule. (`informational`, `low`, `medium`, `high`, `critical`) By default, all level alerts will be displayed but you can set the minimum level with `-m`. For example, you can set `-m high`) in order to only scan for and display high and critical alerts. -* `Alert`: This comes from the `title` field in the YML detection rule. +* `Title`: This comes from the `title` field in the YML detection rule. * `Details`: This comes from the `output` field in the YML detection rule, however, only Hayabusa rules have this field. This field gives extra information about the alert or event and can extract useful data from the `` portion of the log. For example, usernames, command line information, process information, etc... When saving to a CSV file an additional two fields will be added: -* `Rule path`: The path to the detection rule that generated the alert or event. -* `File path`: The path to the evtx file that caused the alert or event. +* `Rule Path`: The path to the detection rule that generated the alert or event. +* `File Path`: The path to the evtx file that caused the alert or event. + +## Progress bar +The progress bar will only work with multiple evtx files. +It will display in real time the number and percent of evtx files that it has analyzed. # Hayabusa rules -Hayabusa detection rules are written in a sigma-like YML format and are located at [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules). +Hayabusa detection rules are written in a sigma-like YML format and are located in the `rules` folder. In the future, we plan to host the rules at [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules) so please send any issues and pull requests for rules there instead of the main hayabusa repository. Please read [AboutRuleCreation-English.md](./doc/AboutRuleCreation-English.md) to understand about the rule format how to create rules. @@ -227,6 +253,10 @@ You can add a rule ID (Example: `4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6`) to `conf You can also add a rule ID to `config/noisy-rules.txt` in order to ignore the rule by default but still be able to use the rule with the `-n` or `--enable-noisy-rules` option. +## Event ID filtering +You can perform Event ID filtering by placing the `EventID` numbers in the `config/target_eventids.txt` text file. +If you only need to search for certain IDs, you can greatly improve performance by filtering them. + # Other Windows event log analyzers and related projects There is no "one tool to rule them all" and we have found that each has its own merits so we recommend checking out these other great tools and projects and seeing which ones you like. diff --git a/README-Japanese.md b/README-Japanese.md index 66c06c9d..3d0e5517 100644 --- a/README-Japanese.md +++ b/README-Japanese.md @@ -7,12 +7,12 @@ # Hayabusa について -Hayabusaは、日本の[Yamato Security](https://yamatosecurity.connpass.com/)グループによって作られた**Windowsイベントログのファストフォレンジックタイムライン生成**および**スレットハンティングツール**であります。 Hayabusaは日本語で[「ハヤブサ」](https://en.wikipedia.org/wiki/Peregrine_falcon)を意味し、ハヤブサが世界で最も速く、狩猟(hunting)に優れ、とてもしつけやすい動物であることから選ばれました。[Rust](https://www.rust-lang.org/) で開発され、マルチスレッドに対応し、可能な限り高速に動作するよう配慮されています。[Sigma](https://github.com/SigmaHQ/Sigma)ルールをHayabusaルール形式に変換する[ツール](https://github.com/Yamato-Security/hayabusa/tree/main/tools/Sigmac)も提供しています。Hayabusaの検出ルールもSigmaと同様に、できるだけ簡単にカスタマイズや拡張ができるようにYMLで書かれています。稼働中のシステムで実行してライブ調査することも、複数のシステムからログを収集してオフライン調査することも可能です。(※現時点では、リアルタイムアラートや定期的なスキャンには対応していません。) 出力は一つの CSV タイムラインにまとめられ、Excelや[Timeline Explorer](https://ericzimmerman.github.io/#!index.md)で簡単に分析できるようになります。 +Hayabusaは、日本の[Yamato Security](https://yamatosecurity.connpass.com/)グループによって作られた**Windowsイベントログのファストフォレンジックタイムライン生成**および**スレットハンティングツール**であります。 Hayabusaは日本語で[「ハヤブサ」](https://en.wikipedia.org/wiki/Peregrine_falcon)を意味し、ハヤブサが世界で最も速く、狩猟(hunting)に優れ、とてもしつけやすい動物であることから選ばれました。[Rust](https://www.rust-lang.org/) で開発され、マルチスレッドに対応し、可能な限り高速に動作するよう配慮されています。[Sigma](https://github.com/SigmaHQ/Sigma)ルールをHayabusaルール形式に変換する[ツール](https://github.com/Yamato-Security/hayabusa/tree/main/tools/Sigmac)も提供しています。Hayabusaの検知ルールもSigmaと同様に、できるだけ簡単にカスタマイズや拡張ができるようにYMLで書かれています。稼働中のシステムで実行してライブ調査することも、複数のシステムからログを収集してオフライン調査することも可能です。(※現時点では、リアルタイムアラートや定期的なスキャンには対応していません。) 出力は一つの CSV タイムラインにまとめられ、Excelや[Timeline Explorer](https://ericzimmerman.github.io/#!index.md)で簡単に分析できるようになります。 ## 主な目的 ### 脅威ハンティング -Hayabusa には現在、1000以上のSigmaルールと約50のHayabusa検出ルールがあり、定期的にルールが追加されています。 最終的な目標はインシデントの後で、または定期的な脅威ハンティングのために、HayabusaエージェントをすべてのWindows端末にプッシュして、中央サーバーにアラートを返すことができるようにすることです。 +Hayabusa には現在、1000以上のSigmaルールと約50のHayabusa検知ルールがあり、定期的にルールが追加されています。 最終的な目標はインシデントの後で、または定期的な脅威ハンティングのために、HayabusaエージェントをすべてのWindows端末にプッシュして、中央サーバーにアラートを返すことができるようにすることです。 ### フォレンジックタイムラインの高速生成 Windowsのイベントログは、 @@ -22,23 +22,32 @@ Windowsのイベントログは、 [Evtx Explorer](https://ericzimmerman.github.io/#!index.md)や[Event Log Explorer](https://eventlogxp.com/)のような、より深く掘り下げた分析を行うツールの代替となることは意図していませんが、分析者が20%の時間で80%の作業を行えるようにすることを目的としています。 # 開発について -[DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI)というWindowsイベントログ解析ツールに触発されて、2020年に[RustyBlue](https://github.com/Yamato-Security/RustyBlue)プロジェクト用にRustに移植することから始めました。その後、YMLで書かれたSigmaのような柔軟な検出シグネチャを作り、Sigmaルールを我々のHayabusaルール形式へ変換するサポートをSigmaへのバックエンドとして追加しています。 +[DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI)というWindowsイベントログ解析ツールに触発されて、2020年に[RustyBlue](https://github.com/Yamato-Security/RustyBlue)プロジェクト用にRustに移植することから始めました。その後、YMLで書かれたSigmaのような柔軟な検知シグネチャを作り、Sigmaルールを我々のHayabusaルール形式へ変換するサポートをSigmaへのバックエンドとして追加しています。 # スクリーンショット ## 起動画面: -![Hayabusa 起動画面](/screenshots/Hayabusa-start.png) - +![Hayabusa 起動画面](/screenshots/Hayabusa-Startup.png) ## ターミナル出力画面: -![Hayabusa ターミナル出力画面](/screenshots/Hayabusa-results.png) - +![Hayabusa ターミナル出力画面](/screenshots/Hayabusa-Results.png) ## 結果サマリ画面: -![Hayabusa 結果サマリ画面](/screenshots/Hayabusa-results-summary.png) +![Hayabusa 結果サマリ画面](/screenshots/HayabusaResultsSummary.png) +## Excelでの解析: + +![Hayabusa Excelでの解析](/screenshots/ExcelScreenshot.png) + +## Timeline Explorerでの解析: + +![Hayabusa Timeline Explorerでの解析](screenshots/TimelineExplorer-ColoredTimeline.png) + +## Criticalアラートのフィルタリングとコンピュータごとのグルーピング: + +![Timeline ExplorerでCriticalアラートのフィルタリングとコンピュータグルーピング](screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png) # 特徴 * クロスプラットフォーム対応: Windows, Linux, macOS @@ -64,19 +73,10 @@ Windowsのイベントログは、 以下の`git clone`コマンドでレポジトリをダウンロードできます: ```bash -git clone --recurse-submodules https://github.com/Yamato-Security/hayabusa.git +git clone https://github.com/Yamato-Security/hayabusa.git ``` -> 注意: ルールファイルは[別リポジトリ](https://github.com/Yamato-Security/hayabusa-rules/)にてsubmoduleとして管理しているため、`--recurse-submodules`オプションを付ける必要があります。 - -clone時に `--recursive-submodules` オプションをつけ忘れると`hayabusa\rules`下にルールファイルが取り込まれません。 -以下のコマンドでsubmoduleを取り込むことができます: - -```bash -git submodule update -i -``` - -または、手動で[https://github.com/Yamato-Security/hayabusa](https://github.com/Yamato-Security/hayabusa)からHayabusaをダウンロードし、解凍し、ルールファイルを[https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules)からダウンロードし、新しい`rules`ディレクトリに保存することもできます。 +または、手動で[https://github.com/Yamato-Security/hayabusa](https://github.com/Yamato-Security/hayabusa)からHayabusaをダウンロードすることもできます。 その後、Windows、Linux、macOS用のコンパイル済みバイナリを[Releases](https://github.com/Yamato-Security/Hayabusa/releases)からダウンロードして、`hayabusa`のディレクトリに置く必要があります。 @@ -159,7 +159,7 @@ hayabusa.exe -d .\hayabusa-sample-evtx --enable-deprecated-rules --enable-noisy- hayabusa.exe -d .\hayabusa-sample-evtx -r ./rules/Hayabusa/default/events/Security/Logons -u -o results.csv ``` -* 起動中のWindows端末上で実行し（Administrator権限が必要）、アラート（悪意のある可能性のある動作）のみを検出します: +* 起動中のWindows端末上で実行し（Administrator権限が必要）、アラート（悪意のある可能性のある動作）のみを検知します: ```bash hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low ``` @@ -169,22 +169,45 @@ hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low hayabusa.exe -f Security.evtx -s ``` +* 詳細なメッセージを出力します(処理に時間がかかるファイル等を特定するのに便利): +```bash +hayabusa.exe -d .\hayabusa-sample-evtx -v +``` + +* Verbose出力の例: +```bash +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1027.004_Obfuscated Files or Information\u{a0}Compile After Delivery/sysmon.evtx" +1 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.20 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1558.004_Steal or Forge Kerberos Tickets AS-REP Roasting/Security.evtx" +2 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.39 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1558.003_Steal or Forge Kerberos Tickets\u{a0}Kerberoasting/Security.evtx" +3 / 509 [>-------------------------------------------------------------------------------------------------------------------------------------------] 0.59 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1197_BITS Jobs/Windows-BitsClient.evtx" +4 / 509 [=>------------------------------------------------------------------------------------------------------------------------------------------] 0.79 % 1s +Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1218.004_Signed Binary Proxy Execution\u{a0}InstallUtil/sysmon.evtx" +5 / 509 [=>------------------------------------------------------------------------------------------------------------------------------------------] 0.98 % 1s +``` + # Hayabusaの出力 Hayabusaの出力を画面に表示しているとき（デフォルト）は、以下の情報を表示します: * `Timestamp`: デフォルトでは`YYYY-MM-DD HH:mm:ss.sss +hh:mm`形式になっています。イベントログの``フィールドから来ています。デフォルトのタイムゾーンはローカルのタイムゾーンになりますが、`--utc` オプションで UTC に変更することができます。 -* `Computer name`: イベントログの``フィールドから来ています。 -* `Event ID`: イベントログの``フィールドから来ています。 -* `Level`: YML検出ルールの`level`フィールドから来ています。(例：`informational`, `low`, `medium`, `high`, `critical`) デフォルトでは、すべてのレベルのアラートとイベントが出力されますが、`-m`オプションで最低のレベルを指定することができます。例えば`-m high`オプションを付けると、`high`と`critical`アラートしか出力されません。 -* `Alert`: YML検出ルールの`title`フィールドから来ています。 -* `Details`: YML検出ルールの`output`フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログの``部分から有用なデータを抽出することができます。 +* `Computer`: イベントログの``フィールドから来ています。 +* `Event ID`: イベントログの``フィールドから来ています。 +* `Level`: YML検知ルールの`level`フィールドから来ています。(例：`informational`, `low`, `medium`, `high`, `critical`) デフォルトでは、すべてのレベルのアラートとイベントが出力されますが、`-m`オプションで最低のレベルを指定することができます。例えば`-m high`オプションを付けると、`high`と`critical`アラートしか出力されません。 +* `Title`: YML検知ルールの`title`フィールドから来ています。 +* `Details`: YML検知ルールの`output`フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログの``部分から有用なデータを抽出することができます。 CSVファイルとして保存する場合、以下の2つのフィールドが追加されます: -* `Rule path`: アラートまたはイベントを生成した検出ルールへのパス。 -* `File path`: アラートまたはイベントを起こしたevtxファイルへのパス。 +* `Rule Path`: アラートまたはイベントを生成した検知ルールへのパス。 +* `File Path`: アラートまたはイベントを起こしたevtxファイルへのパス。 + +## プログレスバー +プログレス・バーは、複数のevtxファイルに対してのみ機能します。 +解析したevtxファイルの数と割合をリアルタイムで表示します。 # Hayabusa ルール -Hayabusa検出ルールはSigmaのようなYML形式で記述されております: [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules). +Hayabusa検知ルールはSigmaのようなYML形式で記述されています。`rules`ディレクトリに入っていますが、将来的人[https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules)のレポジトリで管理する予定なので、ルールのissueとpull requestはhayabusaのレポジトリではなく、ルールレポジトリへお願いします。 ルールの作成方法については、[AboutRuleCreation-Japanase.md](./doc/AboutRuleCreation-Japanase.md) をお読みください。 @@ -204,7 +227,7 @@ Hayabusaルールのディレクトリ構造は、3つのディレクトリに * イベント形式: `<イベントID>_<詳細>.yml` * イベント例: `4776_NTLM-LogonToLocalAccount.yml` -現在のルールをご確認いただき、新規作成時のテンプレートとして、また検出ロジックの確認用としてご利用ください。 +現在のルールをご確認いただき、新規作成時のテンプレートとして、また検知ロジックの確認用としてご利用ください。 ## Hayabusa v.s. 変換されたSigmaルール Sigmaルールは、最初にHayabusaルール形式に変換する必要があります。変換のやり方は[ここ](https://github.com/Yamato-Security/Hayabusa/blob/main/tools/Sigmac/README-Japanese.md)で説明されています。Hayabusaルールは、Windowsのイベントログ解析専用に設計されており、以下のような利点があります: @@ -225,17 +248,21 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ ルールIDを `config/noisy-rules.txt`に追加して、デフォルトでルールを無視することもできますが、` -n`または `--enable-noisy-rules`オプションを指定してルールを使用することもできます。 +## イベントIDフィルタリング + `config/target_eventids.txt` に`EventID`番号を記述することで、イベントIDフィルタリングを行うことができます。 +特定のIDだけを解析する必要がある場合は、フィルタリングを行うことでパフォーマンスを大幅に向上させることができます。 + # その他のWindowsイベントログ解析ツールおよび関連プロジェクト 「すべてを統治する1つのツール」というものはなく、それぞれにメリットがあるため、これらの他の優れたツールやプロジェクトをチェックして、どれが気に入ったかを確認することをお勧めします。 -- [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Pythonで開発された攻撃検出ツール。 -- [Chainsaw](https://github.com/countercept/chainsaw) - Rustで開発された同様のSigmaベースの攻撃検出ツール。 -- [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) - [Eric Conrad](https://twitter.com/eric_conrad) によってPowershellで開発された攻撃検出ツール。 +- [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Pythonで開発された攻撃検知ツール。 +- [Chainsaw](https://github.com/countercept/chainsaw) - Rustで開発された同様のSigmaベースの攻撃検知ツール。 +- [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) - [Eric Conrad](https://twitter.com/eric_conrad) によってPowershellで開発された攻撃検知ツール。 - [EvtxToElk](https://www.dragos.com/blog/industry-news/evtxtoelk-a-python-module-to-load-windows-event-logs-into-elasticsearch/) - Elastic StackにEvtxデータを送信するPythonツール。 - [EVTX ATTACK Samples](https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES) - [SBousseaden](https://twitter.com/SBousseaden) によるEVTX攻撃サンプルイベントログファイル。 - [EVTX-to-MITRE-Attack](https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack) - ATT&CKにマッピングされたEVTX攻撃サンプルログのもう一つの素晴らしいレポジトリ。 - [EVTX parser](https://github.com/omerbenamram/evtx) - [@OBenamram](https://twitter.com/obenamram) によって書かれた、私たちが使用したRustライブラリ。. -- [LogonTracer](https://github.com/JPCERTCC/LogonTracer) - [JPCERTCC](https://twitter.com/jpcert_en) による、横方向の動きを検出するためにログオンを視覚化するグラフィカルなインターフェースです。 +- [LogonTracer](https://github.com/JPCERTCC/LogonTracer) - [JPCERTCC](https://twitter.com/jpcert_en) による、横方向の動きを検知するためにログオンを視覚化するグラフィカルなインターフェースです。 - [RustyBlue](https://github.com/Yamato-Security/RustyBlue) - 大和セキュリティによるDeepBlueCLIのRust版。 - [Sigma](https://github.com/SigmaHQ/Sigma) - コミュニティベースの汎用SIEMルール。 - [so-import-evtx](https://docs.securityonion.net/en/2.3/so-import-evtx.html) - evtxファイルをSecurityOnionにインポートします。 @@ -249,13 +276,13 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ 以下のベンチマークは、2021/12/19に [sample-evtx repository](https://github.com/Yamato-Security/Hayabusa-sample-evtx) から約500個のevtxファイル（130MB）を基に、Lenovo P51で計測したものです。 -| | 経過時間 | メモリ使用量 | 検出機能を備えた独自のSigmaルール数 | +| | 経過時間 | メモリ使用量 | 検知機能を備えた独自のSigmaルール数 | | :---: | :---: | :---: | :---: | | Chainsaw | 7.5 seconds | 70 MB | 170 | | Hayabusa | 7.5 seconds | 400 MB | 267 | | Zircolite | 34 seconds | 380 MB | 237 | -Hayabusaルールも有効にすると、300以上のユニークなアラートとイベントを検出します。 +Hayabusaルールも有効にすると、300以上のユニークなアラートとイベントを検知します。 このベンチマークを見ただけでは、Hayabusaは通常最低でも約400MBのメモリを使うので、Zircoliteよりもメモリを多く使うように見えますが、大きなevtxデータを解析する時にHayabusaの方が有利になります。Zircoliteのメモリ使用量が通常ログサイズの2〜3倍が必要になりますが、Hayabusaのメモリ使用はログサイズをそんなに超えません。 # ライセンス diff --git a/doc/AboutRuleCreation-English.md b/doc/AboutRuleCreation-English.md index 524bcbea..ae174e4d 100644 --- a/doc/AboutRuleCreation-English.md +++ b/doc/AboutRuleCreation-English.md @@ -442,33 +442,42 @@ Aggregation conditions can be defined in the following format: ### Four patterns for aggregation conditions: 1. No count argument or `by` keyword. Example: `selection | count() > 10` - > If `selection` is matches more than 10 times within the timeframe, the condition will match. + > If `selection` matches more than 10 times within the timeframe, the condition will match. 2. No count argument but there is a `by` keyword. Example: `selection | count() by IpAddress > 10` > `selection` will have to be true more than 10 times for the **same** `IpAddress`. 3. There is a count argument but no `by` keyword. Example: `selection | count(TargetUserName) > 10` - > If `selection` matches and `Users` is **different** more than 10 times within the timeframe, the condition will match. + > If `selection` matches and `TargetUserName` is **different** more than 10 times within the timeframe, the condition will match. 4. There is both a count argument and `by` keyword. Example: `selection | count(Users) by IpAddress > 10` > For the **same** `IpAddress`, there will need to be more than 10 **different** `TargetUserName` in order for the condition to match. ### Pattern 1 example: This is the most basic pattern: `count() {operator} {number}`. The rule below will match if `selection` happens 3 or more times. -![](count1_EN.png) +![](CountRulePattern-1-EN.png) ### Pattern 2 example: `count() by {eventkey} {operator} {number}`: Log events that match the `condition` before the pipe are grouped by the **same** `{eventkey}`. If the number of matched events for each grouping satisfies the condition specified by `{operator}` and `{number}`, then the condition will match. -![](count2_EN.png) +![](CountRulePattern-2-EN.png) ### Pattern 3 example: `count({eventkey}) {operator} {number}`: Counts how many **different** values of `{eventkey}` exist in the log event that match the condition before the condition pipe. If the number satisfies the conditional expression specified in `{operator}` and `{number}`, the condition is considered to have been met. -![](count3_EN.png) +![](CountRulePattern-3-EN.png) ### Pattern 4 example: `count({eventkey_1}) by {eventkey_2} {operator} {number}`: The logs that match the condition before the condition pipe are grouped by the **same** `{eventkey_2}`, and the number of **different** values of `{eventkey_1}` in each group is counted. If the values counted for each grouping satisfy the conditional expression specified by `{operator}` and `{number}`, the condition will match. -![](count4_EN.png) +![](CountRulePattern-4-EN.png) + +### Count rule output: +The details output for count rules is fixed and will print the original count condition in `[condition]` followed by the recorded eventkeys in `[result]`. + +In the example below, a list of `TargetUserName` usernames that were being bruteforced followed by the source `IpAddress`: +``` +[condition] count(TargetUserName) by IpAddress >= 5 in timeframe [result] count:41 TargetUserName:jorchilles/jlake/cspizor/lpesce/bgalbraith/jkulikowski/baker/eskoudis/dpendolino/sarmstrong/lschifano/drook/rbowes/ebooth/melliott/econrad/sanson/dmashburn/bking/mdouglas/cragoso/psmith/bhostetler/zmathis/thessman/kperryman/cmoody/cdavis/cfleener/gsalinas/wstrzelec/jwright/edygert/ssims/jleytevidal/celgee/Administrator/mtoussain/smisenar/tbennett/bgreenwood IpAddress:10.10.2.22 timeframe:5m +``` + # Rule creation advice 1. **When possible, always specify `Channel` and `EventID` name.** In the future, we may filter on channel names and event IDs so your rule may be ignored if this is not set. diff --git a/doc/AboutRuleCreation-Japanese.md b/doc/AboutRuleCreation-Japanese.md index b7199656..435717f6 100644 --- a/doc/AboutRuleCreation-Japanese.md +++ b/doc/AboutRuleCreation-Japanese.md @@ -462,22 +462,30 @@ detection: ### パターン1の例： これは最も基本的なパターンです：`count() {operator} {number}`. 以下のルールは、`selection`が3回以上発生した場合にマッチします。 -![](count1_JP.png) +![](CountRulePattern-1-JP.png) ### パターン2の例： -`count() by {eventkey} {operator} {number}`： パイプの前の `condition` にマッチするログイベントは、**同じ**`{eventkey}` でグループ化されます。各グループ化において、マッチしたイベントの数が `{operator}` と `{number}` で指定した条件を満たした場合、条件にマッチすることになります。 +`count() by {eventkey} {operator} {number}`： パイプの前の `condition` にマッチするログイベントは、**同じ**`{eventkey}`でグループ化されます。各グループ化において、マッチしたイベントの数が`{operator}`と`{number}`で指定した条件を満たした場合、条件にマッチすることになります。 -![](count2_JP.png) +![](CountRulePattern-2-JP.png) ### パターン3の例： -`count({eventkey}) {operator} {number}`： 条件パイプの前に、条件にマッチする `{eventkey}` の**異なる**値がいくつログイベント内に存在するかを数えます。その数が `{operator}` と `{number}` で指定された条件式を満たす場合、条件を満たしたものとみなします。 +`count({eventkey}) {operator} {number}`： 条件パイプの前に、条件にマッチする `{eventkey}` の**異なる**値がいくつログイベント内に存在するかを数えます。その数が`{operator}`と`{number}`で指定された条件式を満たす場合、条件を満たしたものとみなします。 -![](count3_JP.png) +![](CountRulePattern-3-JP.png) ### パターン4の例： -`count({eventkey_1}) by {eventkey_2} {operator} {number}`： 条件パイプの前にある条件にマッチしたログを**同じ**`{eventkey_2}` でグループ化し、各グループに含まれる `{eventkey_1}` の**異なる**値の数をカウントしています。各グループでカウントされた値が `{operator}` と `{number}` で指定された条件式を満たした場合、条件にマッチすることになります。 +`count({eventkey_1}) by {eventkey_2} {operator} {number}`： 条件パイプの前にある条件にマッチしたログを**同じ**`{eventkey_2}`でグループ化し、各グループに含まれる`{eventkey_1}`の**異なる**値の数をカウントしています。各グループでカウントされた値が`{operator}`と`{number}`で指定された条件式を満たした場合、条件にマッチすることになります。 -![](count4_JP.png) +![](CountRulePattern-4-JP.png) + +### Countルールの出力: +CountルールのDetails出力は固定で、`[condition]`にcount条件と`[result]`に記録されたイベントキーが出力されます。 + +以下の例では、ブルートフォースされた`TargetUserName`のユーザ名のリストと送信元の`IpAddress`が出力されます： +``` +[condition] count(TargetUserName) by IpAddress >= 5 in timeframe [result] count:41 TargetUserName:jorchilles/jlake/cspizor/lpesce/bgalbraith/jkulikowski/baker/eskoudis/dpendolino/sarmstrong/lschifano/drook/rbowes/ebooth/melliott/econrad/sanson/dmashburn/bking/mdouglas/cragoso/psmith/bhostetler/zmathis/thessman/kperryman/cmoody/cdavis/cfleener/gsalinas/wstrzelec/jwright/edygert/ssims/jleytevidal/celgee/Administrator/mtoussain/smisenar/tbennett/bgreenwood IpAddress:10.10.2.22 timeframe:5m +``` # ルール作成のアドバイス 1. **可能な場合は、常に `Channel`と`EventID`を指定してください。** 将来的には、チャネル名とイベンドIDでフィルタリングする可能性があるため、適切な` Channel`と`EventID`が設定されていない場合はルールが無視される可能性があります。 diff --git a/doc/CountRulePattern-1-EN.png b/doc/CountRulePattern-1-EN.png new file mode 100644 index 00000000..f4568af7 Binary files /dev/null and b/doc/CountRulePattern-1-EN.png differ diff --git a/doc/CountRulePattern-1-JP.png b/doc/CountRulePattern-1-JP.png new file mode 100644 index 00000000..4ab85c76 Binary files /dev/null and b/doc/CountRulePattern-1-JP.png differ diff --git a/doc/CountRulePattern-2-EN.png b/doc/CountRulePattern-2-EN.png new file mode 100644 index 00000000..2ebdea1a Binary files /dev/null and b/doc/CountRulePattern-2-EN.png differ diff --git a/doc/CountRulePattern-2-JP.png b/doc/CountRulePattern-2-JP.png new file mode 100644 index 00000000..cc6b92d1 Binary files /dev/null and b/doc/CountRulePattern-2-JP.png differ diff --git a/doc/CountRulePattern-3-EN.png b/doc/CountRulePattern-3-EN.png new file mode 100644 index 00000000..264ecc47 Binary files /dev/null and b/doc/CountRulePattern-3-EN.png differ diff --git a/doc/CountRulePattern-3-JP.png b/doc/CountRulePattern-3-JP.png new file mode 100644 index 00000000..e8eb53a2 Binary files /dev/null and b/doc/CountRulePattern-3-JP.png differ diff --git a/doc/CountRulePattern-4-EN.png b/doc/CountRulePattern-4-EN.png new file mode 100644 index 00000000..52009cb8 Binary files /dev/null and b/doc/CountRulePattern-4-EN.png differ diff --git a/doc/CountRulePattern-4-JP.png b/doc/CountRulePattern-4-JP.png new file mode 100644 index 00000000..4751f8db Binary files /dev/null and b/doc/CountRulePattern-4-JP.png differ diff --git a/doc/count1_EN.png b/doc/count1_EN.png deleted file mode 100644 index f046b707..00000000 Binary files a/doc/count1_EN.png and /dev/null differ diff --git a/doc/count1_JP.png b/doc/count1_JP.png deleted file mode 100644 index 028bbb7e..00000000 Binary files a/doc/count1_JP.png and /dev/null differ diff --git a/doc/count2_EN.png b/doc/count2_EN.png deleted file mode 100644 index 91dda4e1..00000000 Binary files a/doc/count2_EN.png and /dev/null differ diff --git a/doc/count2_JP.png b/doc/count2_JP.png deleted file mode 100644 index d55faab7..00000000 Binary files a/doc/count2_JP.png and /dev/null differ diff --git a/doc/count3_EN.png b/doc/count3_EN.png deleted file mode 100644 index 80026fc5..00000000 Binary files a/doc/count3_EN.png and /dev/null differ diff --git a/doc/count3_JP.png b/doc/count3_JP.png deleted file mode 100644 index f6dd561c..00000000 Binary files a/doc/count3_JP.png and /dev/null differ diff --git a/doc/count4_EN.png b/doc/count4_EN.png deleted file mode 100644 index a1324718..00000000 Binary files a/doc/count4_EN.png and /dev/null differ diff --git a/doc/count4_JP.png b/doc/count4_JP.png deleted file mode 100644 index e0042295..00000000 Binary files a/doc/count4_JP.png and /dev/null differ