CSEC_PUBLIC/hayabusa
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Git clone and output sections added. syntax highL

Browse Source
This commit is contained in:
Tanaka Zakku
2021-12-20 08:34:42 +09:00
parent e7a57b5361
commit c4ea1ca155
6 changed files with 300 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

121
README-English.md
View File

@@ -7,7 +7,7 @@
</div>
# About Hayabusa
Hayabusa is a **Windows event log fast forensics timeline generator** and **threat hunting tool** created by the [Yamato Security](https://yamatosecurity.connpass.com/) group in Japan. Hayabusa means ["peregrine falcon"](https://en.wikipedia.org/wiki/Peregrine_falcon") in Japanese and was chosen as peregrine falcons are the fastest animal in the world, great at hunting and highly trainable. It is written in [Rust](https://www.rust-lang.org/) and supports multi-threading in order to be as fast as possible. We have provided a [tool](https://github.com/Yamato-Security/hayabusa/tree/main/tools/sigmac) to convert [sigma](https://github.com/SigmaHQ/sigma) rules into hayabusa rule format. The hayabusa detection rules, like sigma, are also written in YAML in order to be as easily customizable and extensible as possible. It can be run either on running systems for live analysis or by gathering logs from multiple systems for offline analysis. (At the moment, it does not support real-time alerting or periodic scans.) The output will be consolidated into a single CSV timeline for easy analysis in Excel or [Timeline Explorer](https://ericzimmerman.github.io/#!index.md).
Hayabusa is a **Windows event log fast forensics timeline generator** and **threat hunting tool** created by the [Yamato Security](https://yamatosecurity.connpass.com/) group in Japan. Hayabusa means ["peregrine falcon"](https://en.wikipedia.org/wiki/Peregrine_falcon") in Japanese and was chosen as peregrine falcons are the fastest animal in the world, great at hunting and highly trainable. It is written in [Rust](https://www.rust-lang.org/) and supports multi-threading in order to be as fast as possible. We have provided a [tool](https://github.com/Yamato-Security/hayabusa/tree/main/tools/sigmac) to convert [sigma](https://github.com/SigmaHQ/sigma) rules into hayabusa rule format. The hayabusa detection rules, like sigma, are also written in YML in order to be as easily customizable and extensible as possible. It can be run either on running systems for live analysis or by gathering logs from multiple systems for offline analysis. (At the moment, it does not support real-time alerting or periodic scans.) The output will be consolidated into a single CSV timeline for easy analysis in Excel or [Timeline Explorer](https://ericzimmerman.github.io/#!index.md).
## Main goals
@@ -19,7 +19,7 @@ Windows event log analysis has traditionally been a very long and tedious proces
Hayabusa is not intended to be a replacement for tools like [Evtx Explorer](https://ericzimmerman.github.io/#!index.md) or [Event Log Explorer](https://eventlogxp.com/) for more deep-dive analysis but is intended for letting analysts get 80% of their work done in 20% of the time.
# About the development
First inspired by the [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) Windows event log analyzer, we started in 2020 porting it over to Rust for the [RustyBlue](https://github.com/Yamato-Security/RustyBlue) project, then created sigma-like flexible detection signatures written in YAML, and then added a backend to sigma to support converting sigma rules into our hayabusa rule format.
First inspired by the [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) Windows event log analyzer, we started in 2020 porting it over to Rust for the [RustyBlue](https://github.com/Yamato-Security/RustyBlue) project, then created sigma-like flexible detection signatures written in YML, and then added a backend to sigma to support converting sigma rules into our hayabusa rule format.
# Screenshots
## Startup:
@@ -42,7 +42,7 @@ Hayabusa is not intended to be a replacement for tools like [Evtx Explorer](http
* Developed in Rust to be memory safe and faster than a hayabusa falcon!
* Multi-thread support delivering up to a 5x speed improvement!
* Creates a single easy-to-analyze CSV timeline for forensic investigations and incident response
* Threat hunting based on IoC signatures written in easy to read/create/edit YAML based hayabusa rules
* Threat hunting based on IoC signatures written in easy to read/create/edit YML based hayabusa rules
* Sigma rule support to convert sigma rules to hayabusa rules
* Currently it supports the most sigma rules compared to other similar tools and even supports count rules
* Event log statistics (Useful for getting a picture of what types of events there are and for tuning your log settings)
@@ -58,18 +58,44 @@ Hayabusa is not intended to be a replacement for tools like [Evtx Explorer](http
* JSON support for sending alerts to Elastic Stack/Splunk, etc...
# Downloads
You can download pre-compiled binaries for the Windows, Linux and macOS at [Releases.](https://github.com/Yamato-Security/hayabusa/releases)
You can `git clone` the repository with the following command:
# Compiling from source
```bash
git clone --recurse-submodules 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.
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.
# Compiling from source (Optional)
If you have rust installed, you can compile from source with the following command:
````
```bash
cargo build --release
````
```
## Testing hayabusa out on sample evtx files
We have provided some sample evtx files for you to test hayabusa and/or create new rules at [https://github.com/Yamato-Security/hayabusa-sample-evtx](https://github.com/Yamato-Security/hayabusa-sample-evtx)
You can download the sample evtx files to a new `hayabusa-sample-evtx` sub-directory with the following command:
```bash
git clone https://github.com/Yamato-Security/hayabusa-sample-evtx.git
```
> Note: Please run this command from the hayabusa root folder.
# Usage
## Command line options
````
```bash
USAGE:
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
-f --filepath=[FILEPATH] 'File path to one .evtx file'
@@ -88,69 +114,80 @@ USAGE:
-s --statistics 'Prints statistics of event IDs'
-q --quiet 'Quiet mode. Do not display the launch banner'
--contributors 'Prints the list of contributors'
````
```
## Usage examples
* Run hayabusa against one Windows event log file:
````
```bash
hayabusa.exe -f eventlog.evtx
````
```
* Run hayabusa against the sample-evtx directory with multiple Windows event log files:
````
hayabusa.exe -d .\sample-evtx
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx
```
* Export to a single CSV file for further analysis with excel or timeline explorer:
````
hayabusa.exe -d .\sample-evtx -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -o results.csv
```
* Only run hayabusa rules (the default is to run all the rules in `-r .\rules`):
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa -o results.csv
```
* Only run hayabusa rules for logs that are enabled by default on Windows:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa\default -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\default -o results.csv
```
* Only run hayabusa rules for sysmon logs:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
```
* Only run sigma rules:
````
hayabusa.exe -d .\sample-evtx -r .\rules\sigma -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\sigma -o results.csv
```
* Enable deprecated rules (those with `status` marked as `deprecated`) and noisy rules (those whose rule ID is listed in `.\config\noisy-rules.txt`):
````
hayabusa.exe -d .\sample-evtx --enable-noisy-rules --enable-deprecated-rules -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx --enable-noisy-rules --enable-deprecated-rules -o results.csv
```
* Only run rules to analyze logons and output in the UTC timezone:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa\default\events\Security\Logons -u -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\default\events\Security\Logons -u -o results.csv
```
* Run on a live Windows machine (requires Administrator privileges) and only detect alerts (potentially malicious behavior):
````
```bash
hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low
````
```
* Get event ID statistics:
````
```bash
hayabusa.exe -f Security.evtx -s
````
```
## Testing hayabusa out on sample evtx files
We have provided some sample evtx files for you to test hayabusa and/or create new rules at [https://github.com/Yamato-Security/hayabusa-sample-evtx](https://github.com/Yamato-Security/hayabusa-sample-evtx)
# 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 `<Event><System><TimeCreated SystemTime>` 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 `<Event><System><Computer>` field in the event log.
* `Event ID`: This comes from the `<Event><System><EventRecordID>` 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.
* `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 `<Event><System><EventData>` 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.
# Hayabusa rules
Hayabusa detection rules are written in a sigma-like YAML 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 at [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules).
Please read [AboutRuleCreation-English.md](./doc/AboutRuleCreation-English.md) to understand about the rule format how to create rules.

121
README-Japanese.md
View File

@@ -7,7 +7,7 @@
</div>
# 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と同様に、できるだけ簡単にカスタマイズや拡張ができるようにYAMLで書かれています。稼働中のシステムで実行してライブ調査することも、複数のシステムからログを収集してオフライン調査することも可能です。(※現時点では、リアルタイムアラートや定期的なスキャンには対応していません。) 出力は一つの 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)で簡単に分析できるようになります。
## 主な目的
@@ -22,7 +22,7 @@ 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に移植することから始めました。その後、YAMLで書かれた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へのバックエンドとして追加しています。
# スクリーンショット
## 起動画面:
@@ -45,7 +45,7 @@ Windowsのイベントログは、
* Rustで開発され、メモリセーフでハヤブサよりも高速です！
* マルチスレッド対応により、最大5倍のスピードアップを実現!
* フォレンジック調査やインシデントレスポンスのために、分析しやすいCSVタイムラインを作成します。
* 読みやすい/作成/編集可能なYAMLベースのHayabusaルールで記述されたIoCシグネチャに基づく脅威ハンティング
* 読みやすい/作成/編集可能なYMLベースのHayabusaルールで作成されたIoCシグネチャに基づく脅威ハンティング
* SigmaルールをHayabusaルールに変換するためのSigmaルールのサポートがされています。
* 現在、他の類似ツールに比べ最も多くのSigmaルールをサポートしており、カウントルールにも対応しています。
* イベントログの統計（どのような種類のイベントがあるのかを把握し、ログ設定のチューニングに有効です。）
@@ -61,18 +61,38 @@ Windowsのイベントログは、
* JSONへの出力→Elastic Stack/Splunkへのインポート
# ダウンロード
Windows、Linux、macOS用のコンパイル済みバイナリは、[Releases](https://github.com/Yamato-Security/Hayabusa/releases)からダウンロードできます。
以下の`git clone`コマンドでレポジトリをダウンロードできます:
# ソースコードからのコンパイル
```bash
git clone --recurse-submodules 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`ディレクトリに保存することもできます。
その後、Windows、Linux、macOS用のコンパイル済みバイナリを[Releases](https://github.com/Yamato-Security/Hayabusa/releases)からダウンロードして、`hayabusa`のディレクトリに置く必要があります。
# ソースコードからのコンパイル（任意）
rustがインストールされている場合、以下のコマンドでソースコードからコンパイルすることができます:
````
```bash
cargo build --release
````
```
## サンプルevtxファイルでHayabusaをテストする
Hayabusaをテストしたり、新しいルールを作成したりするためのサンプルevtxファイルをいくつか提供しています: [https://github.com/Yamato-Security/Hayabusa-sample-evtx](https://github.com/Yamato-Security/Hayabusa-sample-evtx)
# 使用方法
## コマンドラインオプション
````
```bash
USAGE:
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
-f --filepath=[FILEPATH] 'File path to one .evtx file'
@@ -91,69 +111,80 @@ USAGE:
-s --statistics 'Prints statistics of event IDs'
-q --quiet 'Quiet mode. Do not display the launch banner'
--contributors 'Prints the list of contributors'
````
```
## 使用例
* 1 つのWindowsイベントログファイルに対してHayabusaを実行します:
````
```bash
hayabusa.exe -f eventlog.evtx
````
```
* 複数のWindowsイベントログファイルのあるsample-evtxディレクトリに対して、Hayabusaを実行します:
````
hayabusa.exe -d .\sample-evtx
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx
```
* 1 つのCSVファイルにエクスポートして、EXCELやTimeline Explorerでさらに分析することができます:
````
hayabusa.exe -d .\sample-evtx -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -o results.csv
```
* Hayabusaルールのみを実行します（デフォルトでは `-r .\rules` にあるすべてのルールが利用されます）:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa -o results.csv
```
* Windowsでデフォルトで有効になっているログに対してのみ、Hayabusaルールを実行します:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa\default -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\default -o results.csv
```
* Sysmonログに対してのみHayabusaルールを実行します:
````
hayabusa.exe -d .\sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
```
* Sigmaルールのみを実行します:
````
hayabusa.exe -d .\sample-evtx -r .\rules\sigma -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\sigma -o results.csv
```
* 廃棄(deprecated)されたルール(`status`が`deprecated`になっているルール)とノイジールール(`.\config\noisy-rules.txt`にルールIDが書かれているルール)を有効にします:
````
hayabusa.exe -d .\sample-evtx --enable-deprecated-rules --enable-noisy-rules -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx --enable-deprecated-rules --enable-noisy-rules -o results.csv
```
* ログオン情報を分析するルールのみを実行し、UTCタイムゾーンで出力します:
````
hayabusa.exe -d .\sample-evtx -r ./rules/Hayabusa/default/events/Security/Logons -u -o results.csv
````
```bash
hayabusa.exe -d .\hayabusa-sample-evtx -r ./rules/Hayabusa/default/events/Security/Logons -u -o results.csv
```
* 起動中のWindows端末上で実行し（Administrator権限が必要）、アラート（悪意のある可能性のある動作）のみを検出します:
````
```bash
hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low
````
```
* イベントIDの統計情報を取得します:
````
```bash
hayabusa.exe -f Security.evtx -s
````
```
## サンプルevtxファイルでHayabusaをテストする
Hayabusaをテストしたり、新しいルールを作成したりするためのサンプルevtxファイルをいくつか提供しています: [https://github.com/Yamato-Security/Hayabusa-sample-evtx](https://github.com/Yamato-Security/Hayabusa-sample-evtx)
# Hayabusaの出力
Hayabusaの出力を画面に表示しているとき（デフォルト）は、以下の情報を表示します:
* `Timestamp`: デフォルトでは`YYYY-MM-DD HH:mm:ss.sss +hh:mm`形式になっています。イベントログの`<Event><System><TimeCreated SystemTime>`フィールドから来ています。デフォルトのタイムゾーンはローカルのタイムゾーンになりますが、`--utc` オプションで UTC に変更することができます。
* `Computer name`: イベントログの`<Event><System><Computer>`フィールドから来ています。
* `Event ID`: イベントログの`<Event><System><EventRecordID>`フィールドから来ています。
* `Level`: YML検出ルールの`level`フィールドから来ています。(例：`informational`, `low`, `medium`, `high`, `critical`) デフォルトでは、すべてのレベルのアラートとイベントが出力されますが、`-m`オプションで最低のレベルを指定することができます。例えば`-m high`オプションを付けると、`high`と`critical`アラートしか出力されません。
* `Alert`: YML検出ルールの`title`フィールドから来ています。
* `Details`: YML検出ルールの`output`フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログの`<Event><System><EventData>`部分から有用なデータを抽出することができます。
CSVファイルとして保存する場合、以下の2つのフィールドが追加されます:
* `Rule path`: アラートまたはイベントを生成した検出ルールへのパス。
* `File path`: アラートまたはイベントを起こしたevtxファイルへのパス。
# Hayabusa ルール
Hayabusa検出ルールはSigmaのようなYAML形式で記述されております: [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules).
Hayabusa検出ルールはSigmaのようなYML形式で記述されております: [https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules).
ルールの作成方法については、[AboutRuleCreation-Japanase.md](./doc/AboutRuleCreation-Japanase.md) をお読みください。
@@ -197,9 +228,9 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
# その他の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攻撃サンプルログのもう一つの素晴らしいレポジトリ。

143
doc/AboutRuleCreation-English.md
View File

@@ -6,7 +6,7 @@ In this section, we will explain how to write hayabusa detection rules.
# Rule file format
Example:
``````
```yaml
#Author section
author: Eric Conrad, Zach Mathis
creation_date: 2020/11/08
@@ -40,7 +40,8 @@ references:
sample-evtx: ./sample-evtx/EVTX-to-MITRE-Attack/TA0003-Persistence/T1098.xxx-Account manipulation/ID4732-User added to local admin groups.evtx
logsource: default
ruletype: Hayabusa
``````
```
> ## Author section
* **author [required]**: Name of the author(s).
* **contributor** [optional]: Name of any contributor(s) (anyone who made any minor corrections).
@@ -96,13 +97,13 @@ The detection rule below defines that **both conditions** have to be true in ord
* **AND**
* Channel has to exactly be `System`.
``````
```yaml
detection:
selection:
Event.System.EventID: 7040
Event.System.Channel: System
condition: selection
``````
```
To write OR logic, we use lists (Dictionaries that start with `- `).
In the detection rule below, **either one** of the conditions will result in the rule being triggered.
@@ -110,13 +111,13 @@ In the detection rule below, **either one** of the conditions will result in the
* **OR**
* Channel has to exactly be `System`.
``````
```yaml
detection:
selection:
- Event.System.EventID: 7040
- Event.System.Channel: System
condition: selection
``````
```
We can also combine `AND` and `OR` logic as shown below.
In this case, the rule matches when the following two conditions are both true.
@@ -124,7 +125,7 @@ In this case, the rule matches when the following two conditions are both true.
* **AND**
* Channel is exactly `System`.
``````
```yaml
detection:
selection:
Event.System.EventID:
@@ -132,12 +133,12 @@ detection:
- 7041
Event.System.Channel: System
condition: selection
``````
```
### Eventkeys
The following is an excerpt of a Windows event log, formatted in the original XML. The `Event.System.Channel` field in the rule file example above refers to the original XML tag: `<Event><System><Channel>System<Channel><System></Event>`. Nested XML tags are replaced by tag names seperated by dots (`.`). In hayabusa rules, these field strings connected together with dots are refered to as `eventkeys`.
``````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>7040</EventID>
@@ -148,18 +149,18 @@ The following is an excerpt of a Windows event log, formatted in the original XM
<Data Name='param2'>auto start</Data>
</EventData>
</Event>
``````
```
#### Eventkey Aliases
Long eventkeys with many `.` seperations are common, so hayabusa will use aliases to make them easier to work with. Aliases are defined in the `config\eventkey_alias.txt` file. This file is a CSV file made up of `alias` and `event_key` mappings. You can rewrite the rule above as shown below with aliases making the rule easier to read.
``````
```yaml
detection:
selection:
Channel: System
EventID: 7040
condition: selection
``````
```
#### Caution: Undefined Eventkey Aliases
Not all eventkey aliases are defined in `config\eventkey_alias.txt`. If you are not getting the correct data in the `output`(Alert details) message, and instead are getting results like `%EventID%` or if the selection in your detection logic is not working properly, then you need to update `config\eventkey_alias.txt` with a new alias.
@@ -167,7 +168,7 @@ Not all eventkey aliases are defined in `config\eventkey_alias.txt`. If you are
### How to use XML attributes in conditions
XML elements may have attributes set by adding a space to the element. For example, `Name` in `Provider Name` below is an XML attribute of the `Provider` element.
````````````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/>
@@ -177,36 +178,36 @@ XML elements may have attributes set by adding a space to the element. For examp
<Security />
</System>
</Event>
````````````
```
To specify XML attributes in an eventkey, use the format `{eventkey}_attributes.{attribute_name}`. For example, to specify the `Name` attribute of the `Provider` element in a rule file, it would look like this:
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4672
Event.System.Provider_attributes.Name: 'Microsoft-Windows-Security-Auditing'
condition: selection
``````
```
### grep search
Hayabusa can perform grep searches in Windows event log files by not specifying any eventkeys.
To do a grep search, specify the detection as shown below. In this case, if the strings `mimikatz` or `metasploit` are included in the Windows Event log, it will match. It is also possible to specify wildcards.
``````
```yaml
detection:
selection:
- mimikatz
- metasploit
``````
```
> Note: Hayabusa internally converts Windows event log data to JSON format before processing the data so it is not possible to match on XML tags.
### EventData
Windows event logs are divided into two parts: the `System` part where the fundamental data (Event ID, Timestamp, Record ID, Log name (Channel)) is written, and the `EventData` part where arbitrary data is written depending on the Event ID. The problem is that the names of the tags nested in EventData are all called `Data` so the eventkeys described so far cannot distinguish between `SubjectUserSid` and `SubjectUserName`.
````````````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
@@ -222,11 +223,11 @@ Windows event logs are divided into two parts: the `System` part where the funda
<Data Name='SubjectLogonId'>0x11111111</Data>
</EventData>
</Event>
````````````
```
To deal with this problem, you can specify the value assigned in `Data Name`. For example, if you want to use `SubjectUserName` and `SubjectDomainName` in the EventData as a condition of a rule, you can describe it as follows:
``````
```yaml
detection:
selection:
Channel: System
@@ -234,12 +235,12 @@ detection:
Event.EventData.SubjectUserName: hayabusa
Event.EventData.SubjectDomainName: DESKTOP-HAYBUSA
condition: selection
``````
```
### Abnormal patterns in EventData
Some of the tags nested in `EventData` do not have a `Name` attribute.
``````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
@@ -252,30 +253,30 @@ Some of the tags nested in `EventData` do not have a `Name` attribute.
<Data>NewEngineState=Available PreviousEngineState=None SequenceNumber=9 HostName=ConsoleHost HostVersion=2.0 HostId=5cbb33bf-acf7-47cc-9242-141cd0ba9f0c EngineVersion=2.0 RunspaceId=c6e94dca-0daf-418c-860a-f751a9f2cbe1 PipelineId= CommandName= CommandType= ScriptName= CommandPath= CommandLine=</Data>
</EventData>
</Event>
``````
```
To detect an event log like the one above, you can specify an eventkey named `EventData`. In this case, the condition will match as long as any one of the nested tags without a `Name` attribute matches.
``````
```yaml
detection:
selection:
Channel: Security
EventID: 5379
EventData: None
condition: selection
``````
```
## Pipes
A pipe can be used with eventkeys as shown below for matching strings. All of the conditions we have described so far use exact matches, but by using pipes, you can describe more flexible detection rules. In the following example, if the value of `EventData` matches the regular expression `[\s\S]*EngineVersion=2\.0[\s\S]*`, it will match the condition.
``````
```yaml
detection:
selection:
Channel: Microsoft-Windows-PowerShell/Operational
EventID: 400
EventData|re: '[\s\S]*EngineVersion=2\.0[\s\S]*'
condition: selection
``````
```
This is a list of what you can specify after the pipe. At the moment, hayabusa does not support chaining multiple pipes together.
* startswith: Checks the string from the beginning
@@ -288,14 +289,14 @@ This is a list of what you can specify after the pipe. At the moment, hayabusa d
Wildcards can be used in eventkeys. In the example below, if `ProcessCommandLine` starts with the string "malware", the rule will match.
The specification is fundamentally the same as sigma rule wildcards.
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4688
ProcessCommandLine: malware*
condition: selection
``````
```
The following two wildcards can be used.
* `*`: Matches any string of zero or more characters. (Internally it is converted to the regular expression `.*`)
@@ -313,7 +314,7 @@ In the example below, the rule will match if the following are true:
* `ImagePath` has a minimum of 1000 characters.
* `ImagePath` does not have any matches in the `allowlist`.
``````
```yaml
detection:
selection:
Channel: System
@@ -325,7 +326,7 @@ detection:
min_length: 1000
allowlist: ./config/regex/allowlist_legitimate_services.txt
condition: selection
``````
```
Currently, the following keywords can be specified:
* `value`: matches by string (wildcards and pipes can also be specified).
@@ -347,7 +348,7 @@ Please refer to the built-in `./config/regex/detectlist_suspicous_services.txt`
With the notation we explained above, you can express `AND` and `OR` logic but it will be confusing if you are trying to define complex logic.
When you want to make more complex rules, you should use the `condition` keyword as shown below.
``````
```yaml
detection:
SELECTION_1:
EventID: 3
@@ -368,7 +369,7 @@ detection:
SELECTION_6:
DestinationIsIpv6: 'false'
condition: (SELECTION_1 and (SELECTION_2 and SELECTION_3) and not ((SELECTION_4 or (SELECTION_5 and SELECTION_6))))
``````
```
The following expressions can be used for `condition`.
* `{expression1} and {expression2}`: Require both {expression1} AND {expression2}
@@ -383,7 +384,7 @@ In the above example, selection names such as `SELECTION_1`, `SELECTION_2`, etc.
Many rules will result in false positives so it is very common to have a selection for signatures to search for but also a filter selection to not alert on false positives.
For example:
``````
```yaml
detection:
selection:
Channel: Security
@@ -401,7 +402,7 @@ detection:
- ProcessName|startswith: C:\Program Files
- SubjectUserName: LOCAL SERVICE
condition: selection and not filter
``````
```
## Aggregation conditions (Count rules)
### Basics
@@ -409,14 +410,14 @@ The `condition` keyword described above implements not only `AND` and `OR` logic
This function is called the "aggregation condition" and is specified by connecting a condition with a pipe.
In the example below, a conditional expression is used to determine if there are ten or more `AccountName` values for any given `ComputerName` within a timeframe of 24 hours.
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4648
condition: selection | count(AccountName) by ComputerName >= 10
timeframe: 24h
``````
```
Aggregation conditions can be defined in the following format:
* `count() {operator} {number}`: For log events that match the first condition before the pipe, the condition will match if the number of matched logs satisfies the condition expression specified by `{operator}` and `{number}`.
@@ -472,10 +473,10 @@ This is the most basic pattern: `count() {operator} {number}`. The rule below wi
# 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.
2. **Do not use multiple `selection` or `filter` fields when it is not needed.** For example:
2. **Do not use multiple `selection` or `filter` fields and excessive grouping when it is not needed.** For example:
Bad example:
```
### Bad example:
```yaml
detection:
SELECTION_1:
Channnel: Security
@@ -490,8 +491,8 @@ detection:
condition: SELECTION_1 and SELECTION_2 and SELECTION_3 and not (FILTER_1 or FILTER_2)
```
Good example:
```
### Good example:
```yaml
detection:
selection:
Channel: Security
@@ -503,10 +504,10 @@ detection:
condition: selection and not filter
```
1. **When you need multiple sections, please name the first section with channel and event ID information in the `section_basic_info` section and other selections with meaningful names after `section_` and `filter_`, or use the notation `section_1`, `filter_1`, etc... Also, please write comments to explain anything difficult to understand.**
3. **When you need multiple sections, please name the first section with channel and event ID information in the `section_basic_info` section and other selections with meaningful names after `section_` and `filter_`, or use the notation `section_1`, `filter_1`, etc... Also, please write comments to explain anything difficult to understand.**
Bad example:
```
### Bad example:
```yaml
detection:
Takoyaki:
Channel: Security
@@ -529,8 +530,32 @@ detection:
condition: Takoyaki and Daisuki and not (Naruto and not Godzilla) and not Ninja and not Sushi
```
Good example:
### OK example:
```yaml
detection:
selection_1:
Channel: Security
EventID: 4648
selection_2:
TargetUserName|endswith: "$"
IpAddress: "-"
filter_1: #Filter system noise
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
filter_2:
SubjectUserName|endswith: "$"
filter_3:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$" #Filter out default Desktop Windows Manager and User Mode Driver Framework accounts
IpAddress: "-" #Don't filter if the IP address is remote to catch attackers who created backdoor accounts that look like DWM-12, etc..
selection_4:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: selection_1 and selection_4 and not (selection_2 and not filter_2) and not filter_3 and not filter_1
```
### Good example:
```yaml
detection:
selection_basic_info:
Channel: Security
@@ -554,30 +579,6 @@ detection:
and not filter_SubjectUserIsComputerAccount) and not filter_SystemAccounts and not filter_UsersAndTargetServerAreComputerAccounts
```
OK example:
```
detection:
selection_1:
Channel: Security
EventID: 4648
selection_2:
TargetUserName|endswith: "$"
IpAddress: "-"
filter_1: #Filter system noise
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
filter_2:
SubjectUserName|endswith: "$"
filter_3:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$" #Filter out default Desktop Windows Manager and User Mode Driver Framework accounts
IpAddress: "-" #Don't filter if the IP address is remote to catch attackers who created backdoor accounts that look like DWM-12, etc..
selection_4:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: selection_1 and selection_4 and not (selection_2 and not filter_2) and not filter_3 and not filter_1
```
# Converting sigma rules to hayabusa format
We have created a backend for sigmac to convert rules from sigma to hayabusa format [here](https://github.com/Yamato-Security/hayabusa/blob/main/tools/sigmac/).

142
doc/AboutRuleCreation-Japanese.md
View File

@@ -6,7 +6,7 @@ Hayabusaの検知ルールは、[YAML](https://en.wikipedia.org/wiki/YAML) 形
# ルールファイル形式
記述例:
``````
```yaml
#Author section
author: Eric Conrad, Zach Mathis
creation_date: 2020/11/08
@@ -40,7 +40,8 @@ references:
sample-evtx: ./sample-evtx/EVTX-to-MITRE-Attack/TA0003-Persistence/T1098.xxx-Account manipulation/ID4732-User added to local admin groups.evtx
logsource: default
ruletype: Hayabusa
``````
```
> ## 著者名欄
* **author [必須]**: 著者名（複数可）。
* **contributor** [オプション]: 寄稿者の名前（細かい修正をした人）。
@@ -97,13 +98,13 @@ ANDロジックを書くには、ネストされた辞書を使用します。
* イベントIDは `7040` であること。
* チャンネルは `System` であること。
``````
```yaml
detection:
selection:
Event.System.EventID: 7040
Event.System.Channel: System
condition: selection
``````
```
OR論理を記述するには、リスト（`- `で始まる辞書）を使用します。
以下の検出ルールでは、**片方**の条件がトリガーされることになります。
@@ -113,13 +114,13 @@ OR論理を記述するには、リスト（`- `で始まる辞書）を使用
**または**
* チャンネルは `System` であること。
``````
```yaml
detection:
selection:
- Event.System.EventID: 7040
- Event.System.Channel: System
condition: selection
``````
```
また、以下のように「AND」と「OR」の論理を組み合わせることも可能です。
この場合、以下の2つの条件が両方成立したときにルールがマッチします。
@@ -127,7 +128,7 @@ detection:
* イベントID が `7040` **または** `7041` のどちらかであること。
* チャンネルが `System` であること。
``````
```yaml
detection:
selection:
Event.System.EventID:
@@ -135,7 +136,7 @@ detection:
- 7041
Event.System.Channel: System
condition: selection
``````
```
### イベントキー
以下は、Windowsイベントログの抜粋で、オリジナルのXMLでフォーマットしたものです。上記のルールファイルの例の `Event.System.Channel` フィールドは、オリジナルのXMLタグを参照しています。
@@ -144,7 +145,7 @@ detection:
ネストされたXMLタグはドット(`.`)で区切られたタグ名で置き換えられます。Hayabusaのルールでは、ドットでつながれたこれらのフィールド文字列は `eventkeys` と呼ばれます。
``````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>7040</EventID>
@@ -155,18 +156,18 @@ detection:
<Data Name='param2'>auto start</Data>
</EventData>
</Event>
``````
```
#### イベントキーエイリアス
`.`の区切りが多くて長いイベントキーが一般的であるため、Hayabusaはエイリアスを使って簡単に扱えるようにします。エイリアスは `config\eventkey_alias.txt`ファイルで定義されています。このファイルは `alias` と `event_key` のマッピングで構成される CSV ファイルです。以下に示すように、エイリアスを使用して上記のルールを書き直し、ルールを読みやすくすることができます。
``````
```yaml
detection:
selection:
Channel: System
EventID: 7040
condition: selection
``````
```
#### 注意: 未定義のイベントキーエイリアスについて
すべてのイベントキーエイリアスが `config\eventkey_alias.txt`で定義されているわけではありません。`output`（アラートの詳細）メッセージで正しいデータを取得しておらず、代わりに`%EventID%`のような結果を取得している場合、または検出ロジックの選択が正しく機能していない場合は、新しいエイリアスを使用して `config\eventkey_alias.txt`を更新する必要があります。
@@ -174,7 +175,7 @@ detection:
### 条件におけるXML属性の使用方法
XML要素には、スペースを入れることで属性を設定することができます。例えば、以下の `Provider Name` の `Name` は `Provider` 要素のXML属性です。
````````````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/>
@@ -184,35 +185,36 @@ XML要素には、スペースを入れることで属性を設定すること
<Security />
</System>
</Event>
````````````
```
イベントキーのXML属性を指定するには、`{eventkey}_attributes.{attribute_name}`という形式を使います。例えば、ルールファイルの `Provider` 要素の `Name` 属性を指定する場合は、以下のようになります。
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4672
Event.System.Provider_attributes.Name: 'Microsoft-Windows-Security-Auditing'
condition: selection
``````
```
### grep検索
Hayabusaではeventkeyを指定せず、WindowsEventログに含まれる文字列にマッチするかどうかを判定する機能も用意されています。この機能をHayabusaではgrep検索と呼んでいます。
grep検索をするには下記のようにdetectionを指定します。この場合、`mimikatz`または`metasploit`という文字列がWindowsEventログに含まれる場合に、条件に一致したものとして条件に一致したものとして処理されます。また、grep検索にはワイルドカードを指定することも可能です。
``````
```yaml
detection:
selection:
- `mimikatz`
- `metasploit`
``````
```
> ※ Hayabusaでは内部的にWindowsEventログをJSON形式に変換して上で処理を行っています。そのため、XMLのタグをgrep検索でマッチさせることはできません。
### イベントデータ
Windowsのイベントログは、基本データ（イベントID、タイムスタンプ、レコードID、ログ名（チャンネル））が書き込まれる`System`部分と、イベントIDに応じて任意のデータが書き込まれる`EventData`部分の2つに分けられます。問題は、`EventData` にネストされたタグの名前がすべて `Data` であるため、これまで説明したイベントキーでは `SubjectUserSid` と `SubjectUserName` を区別できないことです。
````````````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
@@ -228,10 +230,11 @@ Windowsのイベントログは、基本データ（イベントID、タイム
<Data Name='SubjectLogonId'>0x11111111</Data>
</EventData>
</Event>
````````````
```
この問題に対処するために、`Data Name`で割り当てられた値を指定することができます。例えば、EventData に含まれる `SubjectUserName` と `SubjectDomainName` をルールの条件として利用したい場合、以下のように記述することが可能です。
``````
```yaml
detection:
selection:
Channel: System
@@ -239,12 +242,12 @@ detection:
Event.EventData.SubjectUserName: Hayabusa
Event.EventData.SubjectDomainName: DESKTOP-HAYBUSA
condition: selection
``````
```
### EventDataの異常なパターン
`EventData` にネストされたいくつかのタグは `Name` 属性を持ちません。
``````
```xml
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
@@ -257,30 +260,30 @@ detection:
<Data>NewEngineState=Available PreviousEngineState=None SequenceNumber=9 HostName=ConsoleHost HostVersion=2.0 HostId=5cbb33bf-acf7-47cc-9242-141cd0ba9f0c EngineVersion=2.0 RunspaceId=c6e94dca-0daf-418c-860a-f751a9f2cbe1 PipelineId= CommandName= CommandType= ScriptName= CommandPath= CommandLine=</Data>
</EventData>
</Event>
``````
```
上記のようなイベントログを検出するには、`EventData`という名前のイベントキーを指定します。この場合、`Name`属性を持たないネストされたタグのいずれかがマッチする限り、条件はマッチします。
``````
```yaml
detection:
selection:
Channel: Security
EventID: 5379
EventData: None
condition: selection
``````
```
## パイプ
パイプは、以下のようにイベントキーと組み合わせて、文字列のマッチングに使用することができます。これまで説明した条件はすべて完全一致ですが、パイプを使うことで、より柔軟な検出ルールを記述することができます。以下の例では、`EventData`の値が正規表現 `[\s\S]*EngineVersion=2.0[\s\S]*` にマッチする場合、条件にマッチすることになります。
``````
```yaml
detection:
selection:
Channel: Microsoft-Windows-PowerShell/Operational
EventID: 400
EventData|re: '[\s\S]*EngineVersion=2\.0[\s\S]*'
condition: selection
``````
```
パイプの後に指定できるものの一覧です。現時点では、Hayabusa は複数のパイプを連結することはサポートしていません。
* startswith: 文字列を先頭からチェックします。
@@ -293,14 +296,14 @@ detection:
イベントキーにワイルドカードを使用することができます。以下の例では、`ProcessCommandLine` が "malware" という文字列で始まる場合、このルールはマッチします。
この仕様は、Sigmaルールのワイルドカードと基本的に同じです。
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4688
ProcessCommandLine: malware*
condition: selection
``````
```
以下の2つのワイルドカードを使用することができます。
* `*`: 0文字以上の任意の文字列にマッチします。(内部的には正規表現 `.*` に変換されます)。
@@ -318,7 +321,7 @@ detection:
* `ImagePath` は1000文字以上であること。
* `ImagePath` は `allowlist` にマッチするものが一つもありません。
``````
```yaml
detection:
selection:
Channel: System
@@ -330,7 +333,7 @@ detection:
min_length: 1000
allowlist: ./config/regex/allowlist_legitimate_services.txt
condition: selection
``````
```
現在、指定できるキーワードは以下の通りです。
* `value`: 文字列によるマッチング (ワイルドカードやパイプも指定可能)。
@@ -352,7 +355,7 @@ Hayabusaに`.\rules\hayabusa\default\alerts\System\7045_CreateOrModiftySystemPro
上記で説明した表記法では、`AND`や`OR`の論理を表現することができますが、複雑な論理を定義しようとすると混乱してしまうでしょう。
より複雑なルールを作りたい場合は、以下のように `condition` キーワードを使用します。
``````
```yaml
detection:
SELECTION_1:
EventID: 3
@@ -373,7 +376,7 @@ detection:
SELECTION_6:
DestinationIsIpv6: 'false'
condition: (SELECTION_1 and (SELECTION_2 and SELECTION_3) and not ((SELECTION_4 or (SELECTION_5 and SELECTION_6))))
``````
```
`condition`には、以下の式を用いることができます。
* `{expression1} and {expression2}`: {expression1} と {expression2} の両方を必要とする。
@@ -389,7 +392,7 @@ detection:
例えば
``````
```yaml
detection:
selection:
Channel: Security
@@ -407,7 +410,7 @@ detection:
- ProcessName|startswith: C:\Program Files
- SubjectUserName: LOCAL SERVICE
condition: selection and not filter
``````
```
## aggregation condition (集計条件) (別名: カウントルール)
### 基本事項
@@ -415,14 +418,14 @@ detection:
この機能は「集計条件」と呼ばれ、条件をパイプでつないで指定をします。
以下の例では、24時間以内に任意の`ComputerName`に対して10個以上の `AccountName` 値があるかどうかを判断するために条件式が使用されています。
``````
```yaml
detection:
selection:
Channel: Security
EventID: 4648
condition: selection | count(AccountName) by ComputerName >= 10
timeframe: 24h
``````
```
集計条件は以下の形式で定義することができます。
* `count() {operator} {number}`: パイプの前の最初の条件にマッチするログイベントに対して、マッチしたログの数が `{operator}` と `{number}` で指定した条件式を満たす場合に条件がマッチします。
@@ -480,8 +483,9 @@ detection:
1. **可能な場合は、常に `Channel`と`EventID`を指定してください。** 将来的には、チャネル名とイベンドIDでフィルタリングする可能性があるため、適切な` Channel`と`EventID`が設定されていない場合はルールが無視される可能性があります。
2. **不要な場合は複数の `selection`と`filter`セクションを使用しないでください。**
悪い例：
```
### 悪い例：
```yaml
detection:
detection:
SELECTION_1:
@@ -497,8 +501,8 @@ detection:
condition: SELECTION_1 and SELECTION_2 and SELECTION_3 and not (FILTER_1 or FILTER_2)
```
良い例：
```
### 良い例：
```yaml
detection:
selection:
Channel: Security
@@ -512,8 +516,8 @@ detection:
3. **複数のセクションが必要な場合は、チャンネル名とイベントIDの情報を記入する最初のセクションを `section_basic_info` セクションに、その他のセクションを `section_` と `filter_` の後に意味のある名前を付けるか、または `section_1`, `filter_1` などの記法を用いてください。また、分かりにくいところはコメントを書いて説明してください。**
悪い例：
```
### 悪い例：
```yaml
detection:
Takoyaki:
Channel: Security
@@ -536,8 +540,32 @@ detection:
condition: Takoyaki and Daisuki and not (Naruto and not Godzilla) and not Ninja and not Sushi
```
良い例：
### OKな例：
```yaml
detection:
selection_1:
Channel: Security
EventID: 4648
selection_2:
TargetUserName|endswith: "$"
IpAddress: "-"
filter_1: #Filter system noise
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
filter_2:
SubjectUserName|endswith: "$"
filter_3:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$" #Filter out default Desktop Windows Manager and User Mode Driver Framework accounts
IpAddress: "-" #Don't filter if the IP address is remote to catch attackers who created backdoor accounts that look like DWM-12, etc..
selection_4:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: selection_1 and selection_4 and not (selection_2 and not filter_2) and not filter_3 and not filter_1
```
### 良い例：
```yaml
detection:
selection_basic_info:
Channel: Security
@@ -561,30 +589,6 @@ detection:
and not filter_SubjectUserIsComputerAccount) and not filter_SystemAccounts and not filter_UsersAndTargetServerAreComputerAccounts
```
OKな例：
```
detection:
selection_1:
Channel: Security
EventID: 4648
selection_2:
TargetUserName|endswith: "$"
IpAddress: "-"
filter_1: #Filter system noise
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
filter_2:
SubjectUserName|endswith: "$"
filter_3:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$" #Filter out default Desktop Windows Manager and User Mode Driver Framework accounts
IpAddress: "-" #Don't filter if the IP address is remote to catch attackers who created backdoor accounts that look like DWM-12, etc..
selection_4:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: selection_1 and selection_4 and not (selection_2 and not filter_2) and not filter_3 and not filter_1
```
# SigmaルールからHayabusaルール形式への自動変換
SigmaルールからHayabusaルール形式への自動変換を行うsigmacのバックエンドを[こちら](https://github.com/Yamato-Security/hayabusa/tree/main/tools/sigmac)で作成しました。

BIN
screenshots/hayabusa-results-summary.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 69 KiB

BIN
screenshots/hayabusa-start.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 81 KiB

After

Width:  |  Height:  |  Size: 121 KiB