readme update

This commit is contained in:
Tanaka Zakku
2022-04-11 09:15:23 +09:00
parent 265d42df30
commit 1dc9a11d94
2 changed files with 44 additions and 75 deletions

View File

@@ -59,10 +59,9 @@ Hayabusaは、日本の[Yamato Security](https://yamatosecurity.connpass.com/)
- [Hayabusaルール](#hayabusaルール)
- [Hayabusa v.s. 変換されたSigmaルール](#hayabusa-vs-変換されたsigmaルール)
- [検知ルールのチューニング](#検知ルールのチューニング)
- [検知レベルのlevelチューニング](#検知レベルのlevelチューニング)
- [イベントIDフィルタリング](#イベントidフィルタリング)
- [検知レベルのチューニング](#検知レベルのチューニング)
- [その他のWindowsイベントログ解析ツールおよび関連プロジェクト](#その他のwindowsイベントログ解析ツールおよび関連プロジェクト)
- [Sigmaをサポートする他の類似ツールとの比較](#sigmaをサポートする他の類似ツールとの比較)
- [コミュニティによるドキュメンテーション](#コミュニティによるドキュメンテーション)
- [英語](#英語)
- [日本語](#日本語)
@@ -128,6 +127,7 @@ CSVのタイムラインをExcelやTimeline Explorerで分析する方法は[こ
* イベントログの統計。(どのような種類のイベントがあるのかを把握し、ログ設定のチューニングに有効です。)
* 不良ルールやノイズの多いルールを除外するルールチューニング設定が可能です。
* MITRE ATT&CKとのマッピング (CSVの出力ファイルのみ)。
* ルールレベルのチューニング。
# 予定されている機能
@@ -312,6 +312,7 @@ USAGE:
-s --statistics 'イベント ID の統計情報を表示する。'
-q --quiet 'Quietモード。起動バナーを表示しない。'
-Q --quiet-errors 'Quiet errorsモード。エラーログを保存しない。'
--level-tuning <LEVEL_TUNING_FILE> 'ルールlevelのチューニング [default: ./config/level_tuning.txt]'
--contributors 'コントリビュータの一覧表示。'
```
@@ -468,9 +469,9 @@ Hayabusaルールのディレクトリ構造は、3つのディレクトリに
ルールはさらにログタイプSecurity、Systemなどによってディレクトリに分けられ、次の形式で名前が付けられます。
* アラート形式: `<イベントID>_<MITRE ATT&CKの攻撃手法名>_<詳細>.yml`
* アラート例: `1102_IndicatorRemovalOnHost-ClearWindowsEventLogs_SecurityLogCleared.yml`
* イベント形式: `<イベントID>_<詳細>.yml`
* アラート形式: `<イベントID>_<イベントの説明>_<リスクの説明>.yml`
* アラート例: `1102_SecurityLogCleared_PossibleAntiForensics.yml`
* イベント形式: `<イベントID>_<イベントの説明>.yml`
* イベント例: `4776_NTLM-LogonToLocalAccount.yml`
現在のルールをご確認いただき、新規作成時のテンプレートとして、また検知ロジックの確認用としてご利用ください。
@@ -487,8 +488,7 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
1. [Rust正規表現クレート](https://docs.rs/regex/1.5.4/regex/)では機能しない正規表現を使用するルール。
2. [Sigmaルール仕様](https://github.com/SigmaHQ/Sigma/wiki/Specification)の`count`以外の集計式。
> 注意この制限はSigmaルールの変換ツールにあり、Hayabusa自身にあるわけではありません。
3. `|near`を使用するルール。
## 検知ルールのチューニング
@@ -498,6 +498,20 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
ルールIDを `rules/config/noisy_rules.txt`に追加して、デフォルトでルールを無視することもできますが、`-n`または `--enable-noisy-rules`オプションを指定してルールを使用することもできます。
## 検知レベルのlevelチューニング
Hayabusaルール、Sigmaルールはそれぞれの作者が検知した際のリスクレベルを決めています。
ユーザが独自のリスクレベルに設定するには`./config/level_tuning.txt`に変換情報を書き、`hayabusa.exe --level-tuning`を実行することでルールファイルが書き換えられます。
ルールファイルが直接書き換えられることに注意して使用してください。
`./config/level_tuning.txt`の例:
```
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
```
ルールディレクトリ内で`id``00000000-0000-0000-0000-000000000000`のルールのリスクレベルが`informational`に書き換えられます。
## イベントIDフィルタリング
`config/target_eventids.txt`にイベントID番号を追加することで、イベントIDでフィルタリングすることができます。
@@ -507,19 +521,6 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
最高のパフォーマンスを得たい場合はこのリストを使用してください。ただし、検出漏れの可能性が若干あることにご注意ください。
## 検知レベルのチューニング
Hayabusaルール、Sigmaルールはそれぞれの作者が検知した際の脅威レベルを決めています。
ユーザが独自の脅威レベルに設定するには `./config/level_tuning.txt` に変換情報を書き、`hayabusa --level-tuning` を実行することでルールファイルが書き換えられます。
ルールファイルが直接書き換えられることに注意して使用してください。
`./config/level_tuning.txt` の例
```
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
```
ルールディレクトリ内の `00000000-0000-0000-0000-000000000000` に該当するルールの脅威レベルが `informational` に書き換えられます。
# その他のWindowsイベントログ解析ツールおよび関連プロジェクト
「すべてを統治する1つのツール」というものはなく、それぞれにメリットがあるため、これらの他の優れたツールやプロジェクトをチェックして、どれが気に入ったかを確認することをお勧めします。
@@ -546,23 +547,6 @@ id,new_level
* [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA/) - [Yamato Security](https://github.com/Yamato-Security/)によるWindowsイベントログ解析のマルチツール。
* [Zircolite](https://github.com/wagga40/Zircolite) - Pythonで書かれたSigmaベースの攻撃検知ツール。
## Sigmaをサポートする他の類似ツールとの比較
対象となるサンプルデータ、コマンドラインオプション、ルールのチューニング等によって結果が異なるため、完全な比較はできませんが、ご了承ください。
我々のテストでは、Hayabusaはすべてのツールの中で最も多くのSigmaルールをサポートしながらも、非常に高速な速度を維持し、大量のメモリを必要としないことが分かっています。
以下のベンチマークは、2021/12/23に [sample-evtx repository](https://github.com/Yamato-Security/Hayabusa-sample-evtx) から約500個のevtxファイル130MBを基に、Lenovo P51で計測したものです。Hayabusa 1.0.0を使いました。
| | 経過時間 | メモリ使用量 | 利用可能のSigmaルール数 |
| :-------: | :---------: | :--------------------------------------------: | :---------------------: |
| Chainsaw | 7.5 seconds | 70 MB | 170 |
| Hayabusa | 7.8 seconds | 340 MB | 267 |
| Zircolite | 34 seconds | 380 MB (通常、ログファイルの3倍のサイズが必要) | 237 |
* Hayabusaルールも有効にすると、約300のユニークなアラートとイベントを検知します。
* 合計7.5GBの多数のイベントログファイルでテストしたところ、7分以内に終了し、1GB以上のメモリを使用しませんでした。消費されるメモリ量は、ターゲットのevtxファイルのサイズではなく、結果のサイズによって増えます。
* [Timeline Explorer](https://ericzimmerman.github.io/#!index.md)などのツールで解析するために、結果を1つのCSVタイムラインにまとめる唯一のツールです。
# コミュニティによるドキュメンテーション
## 英語

View File

@@ -59,10 +59,9 @@ Hayabusa is a **Windows event log fast forensics timeline generator** and **thre
- [Hayabusa Rules](#hayabusa-rules)
- [Hayabusa v.s. Converted Sigma Rules](#hayabusa-vs-converted-sigma-rules)
- [Detection Rule Tuning](#detection-rule-tuning)
- [Event ID Filtering](#event-id-filtering)
- [Detection Level Tuning](#detection-level-tuning)
- [Event ID Filtering](#event-id-filtering)
- [Other Windows Event Log Analyzers and Related Projects](#other-windows-event-log-analyzers-and-related-projects)
- [Comparison To Other Similar Tools](#comparison-to-other-similar-tools)
- [Community Documentation](#community-documentation)
- [English](#english)
- [Japanese](#japanese)
@@ -126,6 +125,7 @@ You can learn how to analyze CSV timelines in Excel and Timeline Explorer [here]
* Event log statistics. (Useful for getting a picture of what types of events there are and for tuning your log settings.)
* Rule tuning configuration by excluding unneeded or noisy rules.
* MITRE ATT&CK mapping of tactics (only in saved CSV files).
* Rule level tuning.
# Planned Features
@@ -306,6 +306,7 @@ USAGE:
-s --statistics 'Prints statistics of event IDs.'
-q --quiet 'Quiet mode. Do not display the launch banner.'
-Q --quiet-errors 'Quiet errors mode. Do not save error logs.'
--level-tuning <LEVEL_TUNING_FILE> 'Tune the rule level [default: ./config/level_tuning.txt]'
--contributors 'Prints the list of contributors.'
```
@@ -460,9 +461,9 @@ The hayabusa rule directory structure is separated into 3 directories:
Rules are further seperated into directories by log type (Example: Security, System, etc...) and are named in the following format:
* Alert format: `<EventID>_<MITRE ATT&CK Name>_<Description>.yml`
* Alert example: `1102_IndicatorRemovalOnHost-ClearWindowsEventLogs_SecurityLogCleared.yml`
* Event format: `<EventID>_<Description>.yml`
* Alert format: `<EventID>_<EventDescription>_<AttackDescription>.yml`
* Alert example: `1102_SecurityLogCleared_PossibleAntiForensics.yml`
* Event format: `<EventID>_<EventDescription>.yml`
* Event example: `4776_NTLM-LogonToLocalAccount.yml`
Please check out the current rules to use as a template in creating new ones or for checking the detection logic.
@@ -479,8 +480,7 @@ Sigma rules need to first be converted to hayabusa rule format explained [here](
1. Rules that use regular expressions that do not work with the [Rust regex crate](https://docs.rs/regex/1.5.4/regex/)
2. Aggregation expressions besides `count` in the [sigma rule specification](https://github.com/SigmaHQ/sigma/wiki/Specification).
> Note: the limitation is in the sigma rule converter and not in hayabusa itself.
3. Rules that use `|near`.
## Detection Rule Tuning
@@ -490,6 +490,22 @@ You can add a rule ID (Example: `4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6`) to `rule
You can also add a rule ID to `rules/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.
## Detection Level Tuning
Hayabusa and Sigma rule authors will determine the risk level of the alert when writing their rules.
However, the actual risk level will differ between environments.
You can tune the risk level of the rules by adding them to `./config/level_tuning.txt` and executing `hayabusa.exe --level-tuning` which will update the `level` line in the rule file.
Please note that the rule file will be updated directly.
`./config/level_tuning.txt` sample line:
```
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
```
In this case, the risk level of the rule with an `id` of `00000000-0000-0000-0000-000000000000` in the rules directory will have its `level` rewritten to `informational`.
## Event ID Filtering
You can filter on event IDs by placing event ID numbers in `config/target_eventids.txt`.
@@ -499,20 +515,6 @@ We have provided a sample ID filter list at [`config/target_eventids_sample.txt`
Please use this list if you want the best performance but be aware that there is a slight possibility for missing events (false negatives).
## Detection Level Tuning
The Hayabusa rule and Sigma rule determine the threat level when each author detects it.
To set the user to their own threat level, write the conversion information in `./config/level_tuning.txt` and execute` hayabusa --level-tuning` to rewrite the rule file.
Please note that the rule file will be rewritten directly.
`./config/level_tuning.txt` Sample
```
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
```
The threat level of the rule corresponding to `00000000-0000-0000-0000-000000000000` in the rules directory is rewritten to` informational`.
# 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.
@@ -539,23 +541,6 @@ There is no "one tool to rule them all" and we have found that each has its own
* [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA) - The swiff-army knife for Windows event logs by [Yamato Security](https://github.com/Yamato-Security/)
* [Zircolite](https://github.com/wagga40/Zircolite) - Sigma-based attack detection tool written in Python.
## Comparison To Other Similar Tools
Please understand that it is not possible to do a perfect comparison as results will differ based on the target sample data, command-line options, rule tuning, etc...
In our tests, we have found hayabusa to support the largest number of sigma rules compared to other similar tools while still maintaining very fast speeds and does not require a great amount of memory.
The following benchmarks were taken on a Lenovo P51 based on approximately 500 evtx files (130MB) from our [sample-evtx repository](https://github.com/Yamato-Security/hayabusa-sample-evtx) at 2021/12/23 with hayabusa version 1.0.0.
| | Elapsed Time | Memory Usage | Unique Sigma Rules With Detections |
| :-------: | :----------: | :----------------------------------------------------------: | :--------------------------------: |
| Chainsaw | 7.5 seconds | 75 MB | 170 |
| Hayabusa | 7.8 seconds | 340 MB (memory usage depends on the amount of alerts) | 267 |
| Zircolite | 34 seconds | 380 MB (normally requires 3 times the size of the log files) | 237 |
* With hayabusa rules enabled, it will detect around 300 unique alerts and events.
* When tested on many event logs files totaling 7.5 GB, it finished in under 7 minutes and used around 1 GB of memory. The amount of memory consumed is based on the size of the results, not on the size of the target evtx files.
* It is the only tool that provides a consolidated single CSV timeline to analysis in tools like [Timeline Explorer](https://ericzimmerman.github.io/#!index.md).
# Community Documentation
## English