Readmeの更新
This commit is contained in:
Tanaka Zakku
126
README-English.md
Normal file
126
README-English.md
Normal file
@@ -0,0 +1,126 @@
|
||||
<div align="center">
|
||||
<p>
|
||||
|
||||
|
||||
|
||||
</p>
|
||||
</div>
|
||||
|
||||
# Hayabusa
|
||||
Hayabusa is a very fast Windows event analyzer used for creating forensic timelines and performing threat hunting based on IoCs written in either hayabusa or SIGMA rules. It can be run live, offline, pushed out as agents to be run on endpoints in an enterprise after an incident or even periodically reporting back alerts on slack.
|
||||
|
||||
# About Hayabusa
|
||||
Hayabusa ("falcon" in Japanese) was written by the Yamato Security group in Japan. First inspired by the DeepblueCLI Windows event log analyzer, we started in 2020 porting it over to Rust for the RustyBlue project, then created SIGMA-like flexible signatures based in YAML, and then added a backend to SIGMA to support converting SIGMA rules into hayabusa rules. Supporting multi-threading, (to our knowledge) it is currently the fastest forensics timeline generator and threat hunting tool as well supports the most features in SIGMA. It can analyze multiple Windows event logs and consolidate the results into one timeline for easy analysis. It will output in CSV to be imported into tools like Timeline Explorer and Excel for analysis.
|
||||
|
||||
# Screenshots
|
||||
Add screenshots here.
|
||||
|
||||
# Features
|
||||
* Cross-platform support: Windows, Linux, macOS (Intel + ARM)
|
||||
* Faster than a hayabusa falcon!
|
||||
* English and Japanese support
|
||||
* Multi-thread support
|
||||
* Enterprise-wide threat hunting via alerts to Slack
|
||||
* Creating event timelines for forensic investigations and incident response
|
||||
* Threat hunting based on IoC signatures written in easy to read/create/edit YAML based hayabusa rules
|
||||
* SIGMA support to convert SIGMA rules to hayabusa rules
|
||||
* Event log statistics (Useful for getting a picture of what types of events there are and for tuning your log settings)
|
||||
|
||||
# Downloads
|
||||
You can download pre-compiled binaries for the Windows, Linux and macOS at [Releases.](https://github.com/Yamato-Security/hayabusa/releases)
|
||||
|
||||
# Usage
|
||||
## Command line options
|
||||
````
|
||||
USAGE:
|
||||
hayabusa.exe [FLAGS] [OPTIONS]
|
||||
|
||||
FLAGS:
|
||||
--credits Prints a list of contributors
|
||||
-h, --help Prints help information
|
||||
--rfc-2822 Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600
|
||||
--slack Sends alerts to Slack
|
||||
-s, --statistics Prints statistics for event logs
|
||||
-u, --utc Output time in UTC format (default: local time)
|
||||
-V, --version Prints version information
|
||||
|
||||
OPTIONS:
|
||||
--csv-timeline <CSV_TIMELINE> Save timeline to CSV file
|
||||
-d, --directory <DIRECTORY> Event log files directory
|
||||
-f, --filepath <FILEPATH> Event file path
|
||||
--human-readable-timeline <HUMAN_READABLE_TIMELINE> Human readable timeline
|
||||
-l, --lang <LANG> Output language
|
||||
-t, --threadnum <NUM> Number of threads (Default is the number of CPU cores)
|
||||
````
|
||||
|
||||
## Usage examples
|
||||
* Run hayabusa against one Windows event log file:
|
||||
````
|
||||
hayabusa.exe --filepath=eventlog.evtx
|
||||
````
|
||||
|
||||
* Run hayabusa against a directory with multiple Windows event log files:
|
||||
````
|
||||
hayabusa.exe --directory=.\evtx
|
||||
````
|
||||
|
||||
* Export to a CSV file:
|
||||
````
|
||||
hayabusa.exe --directory=.\evtx --csv-timeline results.csv
|
||||
````
|
||||
|
||||
# Hayabusa rules
|
||||
Hayabusa attack detection rules are written in a SIGMA-like YAML format.
|
||||
|
||||
Please read [AboutRuleCreation-English.md](./doc/AboutRuleCreation-English.md) to understand about how to create rules.
|
||||
|
||||
All of the rules are in the `rules` folder.
|
||||
You can check out the current rules to use as a template in creating new ones.
|
||||
|
||||
# Compiling from source
|
||||
If you have rust installed, you can compile from source with the following command.
|
||||
|
||||
````
|
||||
cargo build --release
|
||||
````
|
||||
|
||||
# How to send alerts to a Slack channel
|
||||
|
||||
Slackチャンネルへの通知にはSlackでのWEBHOOKURLの設定と実行マシンの環境変数(WEBHOOKURL、CHANNEL)への追加が必要です。
|
||||
|
||||
1. Add an "Incoming Webhook" to the slack workspace you want to send alerts to.
|
||||
2. 「チャンネルへの投稿」で投稿するチャンネルを選択し 「Incoming Webhookインテグレーションの追加」をクリックします。
|
||||
3. 遷移後のぺージの「Webhook URL」の内容(https:hooks.slack.com/services/xxx...)を環境変数の`WEBHOOK_URL` に代入してください。
|
||||
4. 投入するchannelを#付きで環境変数の`CHANNEL`に代入してください。
|
||||
5. 以下のコマンドで実行をするとCHANNELで指定したチャンネルに検知情報の通知が送付されます。
|
||||
|
||||
````
|
||||
hayabusa.exe --slack
|
||||
````
|
||||
|
||||
# Other Windows event log analyzers and related projects
|
||||
There is no "one tool to rule them all" and we have found that each have their own merits so we recommend checking out these other great tools and projects and see which ones you like.
|
||||
|
||||
- [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Attack detection tool written in Python.
|
||||
- [Chainsaw](https://github.com/countercept/chainsaw) - A similar SIGMA based attack detection tool written in Rust.
|
||||
- [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) - Attack detection tool written in Powershell.
|
||||
- [EvtxToElk](https://www.dragos.com/blog/industry-news/evtxtoelk-a-python-module-to-load-windows-event-logs-into-elasticsearch/) - Python tool to send Evtx data to Elastic Stack.
|
||||
- [EVTX ATTACK Samples](https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES) - EVTX attack sample event log files by [SBousseaden](https://twitter.com/SBousseaden).
|
||||
- [EVTX-to-MITRE-Attack](https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack) - Another great repository of EVTX attack sample logs mapped to ATT&CK.
|
||||
- [EVTX parser](https://github.com/omerbenamram/evtx) - the Rust library we used written by [@OBenamram](https://twitter.com/obenamram).
|
||||
- [LogonTracer](https://github.com/JPCERTCC/LogonTracer) - A graphical interface to visualize logons to detect lateral movement by [JPCERTCC](https://twitter.com/jpcert_en).
|
||||
- [RustyBlue](https://github.com/Yamato-Security/RustyBlue) - Rust port of DeepBlueCLI by [Eric Conrad](https://twitter.com/eric_conrad).
|
||||
- [SIGMA](https://github.com/SigmaHQ/sigma) - Generic SIEM rules.
|
||||
- [so-import-evtx](https://docs.securityonion.net/en/2.3/so-import-evtx.html) - Import evtx files into Security Onion.
|
||||
- [Timeline Explorer](https://ericzimmerman.github.io/#!index.md) - The best CSV timeline analyzer by [Eric Zimmerman](https://twitter.com/ericrzimmerman).
|
||||
- [Zircolite](https://github.com/wagga40/Zircolite) - SIGMA based attack detection tool written in Python.
|
||||
|
||||
## License
|
||||
|
||||
Hayabusa is released under GPLv3 and all rules are release under the Detection Rule License (DRL) 1.1
|
||||
|
||||
## Contributing
|
||||
|
||||
We would love any form of contributing. Pull requests and rule creation are the best but feature requests, notifying us of bugs, etc... are also very welcome.
|
||||
|
||||
At the least, if you like our tool then please give us a star on Github and show your support!
|
||||
125
README-Japanese.md
Normal file
125
README-Japanese.md
Normal file
@@ -0,0 +1,125 @@
|
||||
<div align="center">
|
||||
<p>
|
||||
|
||||
|
||||
</p>
|
||||
</div>
|
||||
|
||||
# Hayabusa
|
||||
Hayabusaは非常に高速なWindowsイベントアナライザで、フォレンジックタイムラインの作成や、HayabusaまたはSIGMAルールで記述されたIoCに基づいた脅威のハンティングを行うために使用されます。ライブでもオフラインでも実行でき、インシデント後に企業内のエンドポイントで実行されるエージェントとしてプッシュアウトしたり、slackで定期的にアラートを報告することもできます。
|
||||
|
||||
# Hayabusaについて
|
||||
Hayabusaは日本のYamato Securityグループによって書かれました。最初にDeepblueCLI Windowsイベントログアナライザに触発され、2020年にRustyBlueプロジェクトのためにRustに移植することから始まり、SIGMAのようなYAMLベースの柔軟なシグネチャを作成し、SIGMAのルールをhayabusaのルールに変換することをサポートするためにSIGMAにバックエンドを追加しました。マルチスレッドをサポートし、（我々の知る限り）現在最速のフォレンジックタイムラインジェネレータと脅威探索ツールであり、SIGMAの最も多くの機能をサポートしています。複数のWindowsイベントログを分析し、分析しやすいように結果を一つのタイムラインに集約することができます。また、CSV形式で出力されるので、Timeline ExplorerやExcelなどのツールに取り込んで分析することができます。
|
||||
|
||||
# スクリーンショット
|
||||
screenshotを入れる
|
||||
|
||||
# 機能
|
||||
* 複数のOSに対応: Windows, Linux, macOS (Intel + ARM)
|
||||
* ハヤブサよりも速い！
|
||||
* 英語と日本語に対応
|
||||
* マルチスレッド
|
||||
* エンタプライズ向けのインシデント対応やヘルスチェックのためのSlackへのアラート通知
|
||||
* フォレンジック調査用のイベントタイムライン作成
|
||||
* 作成・編集しやすいYAML形式のhayabusaルールでIoCシグネチャーを作成し、攻撃検知(スレットハンティング)を行う
|
||||
* SIGMAルールをhayabusaルールに自動変換
|
||||
* イベントログの集計(どのようなイベントがあるかを把握するためやログ設定のチューニングに便利)
|
||||
|
||||
# ダウンロード
|
||||
[Releases](https://github.com/Yamato-Security/hayabusa/releases)からコンパイル済みの実行ファイルをダウンロードできます。
|
||||
|
||||
# 使い方
|
||||
## コマンドラインオプション
|
||||
````
|
||||
USAGE:
|
||||
hayabusa.exe [FLAGS] [OPTIONS]
|
||||
|
||||
FLAGS:
|
||||
--credits コントリビューターの一覧表示
|
||||
-h, --help ヘルプ画面の表示
|
||||
--rfc-2822 日付と時間をRFC 2822形式で表示する。例： Mon, 07 Aug 2006 12:34:56 -0600
|
||||
--slack Slackへの通知
|
||||
-s, --statistics イベントログの集計
|
||||
-u, --utc 時間をUTCで出力する（デフォルトはローカル時間）
|
||||
-V, --version バージョン情報を出力する
|
||||
|
||||
OPTIONS:
|
||||
--csv-timeline <CSV_TIMELINE> タイムラインをCSVに保存する
|
||||
-d, --directory <DIRECTORY> イベントログファイルが入っているディレクトリ
|
||||
-f, --filepath <FILEPATH> イベントファイルのパス
|
||||
--human-readable-timeline <HUMAN_READABLE_TIMELINE> 読みやすいタイミングを出力
|
||||
-l, --lang <LANG> 出力する言語
|
||||
-t, --threadnum <NUM> スレッド数（デフォルトではCPUコア数）
|
||||
````
|
||||
|
||||
## 使い方の例
|
||||
* Windowsイベントログを一つ指定する:
|
||||
````
|
||||
hayabusa.exe --filepath=eventlog.evtx
|
||||
````
|
||||
|
||||
* Windowsイベントログが格納されているフォルダを指定する:
|
||||
````
|
||||
hayabusa.exe --directory=.\evtx
|
||||
````
|
||||
|
||||
* 結果をCSVファイルに出力する:
|
||||
````
|
||||
hayabusa.exe --directory=.\evtx --csv-timeline kekka.csv
|
||||
````
|
||||
|
||||
# ルールファイル
|
||||
HayabusaではWindowsEventログを検知するルールをYAML形式で定義します。
|
||||
|
||||
ルールの記載方法については[AboutRuleCreation-Japanese.md](./doc/AboutRuleCreation-Japanese.md)を参照してください。
|
||||
|
||||
ルールファイルはrulesフォルダ内に設置します。
|
||||
rulesフォルダには組み込みルールファイルも設置されていますので、参考にしてください。
|
||||
|
||||
# ソースコードからのコンパイル
|
||||
下記のコマンドでビルドできます。
|
||||
|
||||
````
|
||||
cargo build --release
|
||||
````
|
||||
|
||||
# Slackチャンネルへの通知
|
||||
|
||||
Slackチャンネルへの通知にはSlackでのWEBHOOKURLの設定と実行マシンの環境変数(WEBHOOKURL、CHANNEL)への追加が必要です。
|
||||
|
||||
1. 通知先のSlackのワークスペースに対して「Incoming Webhook」をSlackに追加してください。
|
||||
2. 「チャンネルへの投稿」で投稿するチャンネルを選択し 「Incoming Webhookインテグレーションの追加」をクリックします。
|
||||
3. 遷移後のぺージの「Webhook URL」の内容(https:hooks.slack.com/services/xxx...)を環境変数の`WEBHOOK_URL` に代入してください。
|
||||
4. 投入するchannelを#付きで環境変数の`CHANNEL`に代入してください。
|
||||
5. 以下のコマンドで実行をするとCHANNELで指定したチャンネルに検知情報の通知が送付されます。
|
||||
|
||||
````
|
||||
hayabusa.exe --slack
|
||||
````
|
||||
|
||||
# 関連するWindowsイベントログのスレットハンティングプロジェクト
|
||||
まだ完璧なWindowsイベントログ解析ツールは存在していなくて、それぞれ長所短所があるので、以下のツールとプロジェクトもチェックして、好きなツールを使ってくださいね！
|
||||
|
||||
- [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) Powershellで書かれた攻撃検知ツール。
|
||||
- [EvtxToElk](https://www.dragos.com/blog/industry-news/evtxtoelk-a-python-module-to-load-windows-event-logs-into-elasticsearch/) - EvtxデータをElastic Stackにインポートするツール。
|
||||
- [EVTX ATTACK Samples](https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES) - 攻撃の痕跡が入っているEVTXサンプルファイルのリポジトリ。作者：[SBousseaden](https://twitter.com/SBousseaden)。
|
||||
- [EVTX-to-MITRE-Attack](https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack) - もう一つの素晴らしい攻撃の痕跡が入っているEVTXサンプルファイルのリポジトリ。攻撃はMITE ATT&CKにマッピングされている。
|
||||
- [EVTXパーサ](https://github.com/omerbenamram/evtx) - Hayabusaが使っているRustライブラリ。作者：[@OBenamram](https://twitter.com/obenamram)。
|
||||
- [LogonTracer](https://github.com/JPCERTCC/LogonTracer) - 横展開を検知するためのEVTX可視化ツール。作者：[JPCERTCC](https://twitter.com/jpcert)。
|
||||
- [RustyBlue](https://github.com/Yamato-Security/RustyBlue) - DeepBlueCLIをRustに書き換えたツール。
|
||||
- [SIGMA](SIGMA: https://github.com/SigmaHQ/sigma) - SIEM等のジェネリックな攻撃検知ルール。
|
||||
- [so-import-evtx](https://docs.securityonion.net/en/2.3/so-import-evtx.html) - evtxファイルをSecurity Onionにインポートするコマンド。
|
||||
- [Timeline Explorer](https://ericzimmerman.github.io/#!index.md) - CSV形式のタイムラインの最高な解析ツール。作者：[Eric Zimmerman](https://twitter.com/ericrzimmerman)。
|
||||
- [Zircolite](https://github.com/wagga40/Zircolite) - Pythonで書かれたSIGMAベースの攻撃検知ツール。
|
||||
|
||||
## ライセンス
|
||||
|
||||
HayabusaのライセンスはGPLv3で、ルールはすべてDetection Rule License (DRL) 1.1でリリースしています。
|
||||
|
||||
## 貢献
|
||||
|
||||
コントリビューターは大募集中です！プルリクエストやルール作成が一番ですが、機能リクエストやバグのお知らせなども大歓迎です。
|
||||
|
||||
hayabusaを気に入って頂けたら、Githubで星をつけて応援してくださいね！
|
||||
84
README.md
84
README.md
@@ -1,83 +1,5 @@
|
||||
# Lagotto
|
||||
Aiming to be the world's greatest Windows event log analysis tool!
|
||||
Hayabusa Readme:
|
||||
|
||||
世界一のWindowsイベントログ解析ツールを目指しています！
|
||||
[English](README-English.md)
|
||||
|
||||
|
||||
# Platforms
|
||||
Lagottoは下記のプラットフォーム上で実行できます。
|
||||
* Windows
|
||||
* Linux
|
||||
* macOS
|
||||
|
||||
# Downloads
|
||||
[Releases](https://github.com/Yamato-Security/YamatoEventAnalyzer/releases)からコンパイル済みの実行ファイルをダウンロードできます。
|
||||
|
||||
# Usage
|
||||
## Commnad line option
|
||||
````
|
||||
USAGE:
|
||||
lagotto.exe [FLAGS] [OPTIONS]
|
||||
|
||||
FLAGS:
|
||||
--credits Prints credits
|
||||
-h, --help Prints help information
|
||||
--rfc-2822 Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600
|
||||
--slack Slack notification
|
||||
-s, --statistics Prints statistics for event logs
|
||||
-u, --utc Output time in UTC format(default: local time)
|
||||
-V, --version Prints version information
|
||||
|
||||
OPTIONS:
|
||||
--csv-timeline <CSV_TIMELINE> Csv output timeline
|
||||
-d, --directory <DIRECTORY> Event log files directory
|
||||
-f, --filepath <FILEPATH> Event file path
|
||||
--human-readable-timeline <HUMAN_READABLE_TIMELINE> Human readable timeline
|
||||
-l, --lang <LANG> Output language
|
||||
-t, --threadnum <NUM> Thread number
|
||||
````
|
||||
|
||||
## Usage examples
|
||||
* Windowsイベントログを一つ指定する
|
||||
````
|
||||
lagotto.exe --filepath=eventlog.evtx
|
||||
````
|
||||
|
||||
* Windowsイベントログが格納されているフォルダを指定する
|
||||
````
|
||||
lagotto.exe --directory=.\evtx
|
||||
````
|
||||
|
||||
* 結果をCSVファイルに出力する。
|
||||
````
|
||||
lagotto.exe --directory=.\evtx --csv-timeline lagotto.csv
|
||||
````
|
||||
|
||||
# Rule files
|
||||
LagottoではWindowsEventログを検知するルールをYAML形式で定義します。
|
||||
|
||||
ルールの記載方法については[RULEFILE.md](./doc/RULEFILE.md)を参照してください。
|
||||
|
||||
ルールファイルはrulesフォルダ内に設置します。
|
||||
rulesフォルダには組み込みルールファイルも設置されていますので、参考にしてください。
|
||||
|
||||
# How to compile from source files
|
||||
下記のコマンドでビルドできます。
|
||||
|
||||
````
|
||||
cargo build
|
||||
````
|
||||
|
||||
# How to notify to Slack channel
|
||||
|
||||
Slackチャンネルへの通知にはSlackでのWEBHOOKURLの設定と実行マシンの環境変数(WEBHOOKURL、CHANNEL)への追加が必要です。
|
||||
|
||||
1. 通知先のSlackのワークスペースに対して「Incoming Webhook」をSlackに追加してください。
|
||||
2. 「チャンネルへの投稿」で投稿するチャンネルを選択し 「Incoming Webhookインテグレーションの追加」をクリックします。
|
||||
3. 遷移後のぺージの「Webhook URL」の内容(https:hooks.slack.com/services/xxx...)を環境変数の`WEBHOOK_URL` に代入してください。
|
||||
4. 投入するchannelを#付きで環境変数の`CHANNEL`に代入してください。
|
||||
5. 以下のコマンドで実行をするとCHANNELで指定したチャンネルに検知情報の通知が送付されます。
|
||||
|
||||
````
|
||||
lagotto.exe --slack
|
||||
````
|
||||
[Japanese](README-Japanese.md)
|
||||
315
doc/AboutRuleCreation-Japanese.md
Normal file
315
doc/AboutRuleCreation-Japanese.md
Normal file
@@ -0,0 +1,315 @@
|
||||
# ルールファイル
|
||||
LagottoはWindowsEventログの検知ルールをYAML形式のファイルに記載します。
|
||||
単なる文字列一致だけでなく、正規表現やANDやOR等の条件を組み合わせることができ、複雑な検知ルールも表現できるようになっています。
|
||||
ここではその検知ルールの書き方について説明します。
|
||||
|
||||
# ルールファイルのフォーマット
|
||||
ルールファイルのフォーマットは下記の通りです。
|
||||
|
||||
``````
|
||||
title: PowerShell Execution Pipeline
|
||||
description: This rule detect powershell execution pipeline.
|
||||
author: Zach Mathis
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID: 7040
|
||||
Event.System.Channel: System
|
||||
falsepositives:
|
||||
- unknown
|
||||
level: medium
|
||||
output: 'command=%CommandLine%'
|
||||
creation_date: 2020/11/8
|
||||
updated_date: 2020/11/8
|
||||
``````
|
||||
|
||||
* title [required]: ルールファイルのタイトルを入力します。
|
||||
* description [optional]: ルールファイルの説明を入力します。
|
||||
* author [optional]: ルールファイルの作者を入力します。
|
||||
* detection [required]: 検知ルールを入力します。
|
||||
* falsepositives [optional]: 誤検知に関する情報を入力します。
|
||||
* level [optional]: リスクレベルを入力します。指定する値は`informational`,`low`,`medium`,`high`,`critical`のいづれかです。
|
||||
* output [required]: イベントログが検知した場合に表示されるメッセージを入力します。
|
||||
* creation_date [optional]: ルールファイルの作成日を入力します。
|
||||
* updated_date [optional]: ルールファイルの更新日を入力します。
|
||||
|
||||
# detectionの記法について
|
||||
## detectionの基本
|
||||
まず、detectionの基本的な書き方について説明します。
|
||||
|
||||
### AND条件とOR条件の書き方
|
||||
AND条件を記載する場合はYAMLのハッシュを用いて記載します。
|
||||
下記のようにdetectionを記載すると、以下`両方の条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID: 7040
|
||||
Event.System.Channel: System
|
||||
``````
|
||||
|
||||
OR条件を記載する場合は配列を利用します。
|
||||
下記のようにdetectionを記載すると、以下`いずれの条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
- Event.System.EventID: 7040
|
||||
- Event.System.Channel: System
|
||||
``````
|
||||
|
||||
また、下記のように記載することもできます。
|
||||
この場合、以下`両方の条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`又は`7041`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID:
|
||||
- 7040
|
||||
- 7041
|
||||
Event.System.Channel: System
|
||||
``````
|
||||
|
||||
### eventkey
|
||||
WindowsイベントログをXML形式で一部抜粋で出力すると、下記のようになります。ルールファイルの例に含まれる`Event.System.Channel`は、XMLの`<Event><System><Channel>System<Channel><System></Event>`を指しています。今回の例のように、XML形式のWindowsイベントログについて、入れ子になったXMLのタグに含まれる値をルールの条件に指定する場合、`.`でつなげて指定します。ルールファイルでは、この`.`でつなげた文字列をeventkeyと呼んでいます。
|
||||
|
||||
``````
|
||||
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
|
||||
<System>
|
||||
<EventID>7040</EventID>
|
||||
<Channel>System</Channel>
|
||||
</System>
|
||||
<EventData>
|
||||
<Data Name='param1'>Background Intelligent Transfer Service</Data>
|
||||
<Data Name='param2'>自動的な開始</Data>
|
||||
</EventData>
|
||||
</Event>
|
||||
``````
|
||||
|
||||
### eventkeyのalias
|
||||
`.`でつなげたeventkeyは長い文字列になってしまうことがあるため、Lagottoではeventkeyに対するエイリアスを使用できます。エイリアスは`config\eventkey_alias.txt`というファイルに定義されています。ファイルはCSV形式であり、aliasとevent_keyという列から構成されています。aliasにはエイリアスを定義し、event_keyには`.`でつなげたeventkeyを指定します。このエイリアスを用いると、最初に例に挙げたdetectionは以下のように書き換えることができます。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
``````
|
||||
### XMLの属性(attribute)をルールの条件にする方法
|
||||
WindowsEventログをXML形式で出力すると、XMLの属性に値が設定されている場合もあります。下記の例だと、ProviderタグのNameが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}'/>
|
||||
<EventID>4672</EventID>
|
||||
<EventRecordID>607469</EventRecordID>
|
||||
<Channel>Security</Channel>
|
||||
<Security />
|
||||
</System>
|
||||
</Event>
|
||||
````````````
|
||||
|
||||
XMLの属性をeventkeyで指定するには、{eventkey}_attributes.{attribute_name}という形式で指定します。例えば、ProviderタグのName属性をルールファイルに指定する場合、下記のようになります。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4672
|
||||
Event.System.Provider_attributes.Name: 'Microsoft-Windows-Security-Auditing'
|
||||
``````
|
||||
|
||||
### EventData
|
||||
WindowsEventログをXML形式で出力すると、EventDataというタグが使用されている場合があります。(EventDataタグは様々なEventIDのログで頻繁に利用されます。)このEventDataにネストされたタグの名前は全て`Data`となっており、ここまで説明してきたeventkeyではSubjectUserSidやSubjectUserNameを区別することができません。
|
||||
````````````
|
||||
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
|
||||
<System>
|
||||
<EventID>5379</EventID>
|
||||
<TimeCreated SystemTime='2021-10-20T10:16:18.7782563Z' />
|
||||
<EventRecordID>607469</EventRecordID>
|
||||
<Channel>Security</Channel>
|
||||
<Security />
|
||||
</System>
|
||||
<EventData>
|
||||
<Data Name='SubjectUserSid'>S-1-1-11-1111111111-111111111-1111111111-1111</Data>
|
||||
<Data Name='SubjectUserName'>lagotto</Data>
|
||||
<Data Name='SubjectDomainName'>DESKTOP-LAGOTTO</Data>
|
||||
<Data Name='SubjectLogonId'>0x11111111</Data>
|
||||
</EventData>
|
||||
</Event>
|
||||
````````````
|
||||
|
||||
この問題に対応するため、eventkeyで`Data`の代わりに`Name`に指定されている値をeventkeyに指定できるようになっています。例えば、EventData内のSubjectUserNameとSubjectDomainNameをルールの条件とする場合、下記のように記載します。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
Event.EventData.SubjectUserName: lagotto
|
||||
Event.EventData.SubjectDomainName: DESKTOP-LAGOTTO
|
||||
``````
|
||||
|
||||
### EventDataの特殊なパターン
|
||||
EventDataというタグにネストされたタグの中には、Name属性が存在しないタグもあります。
|
||||
``````
|
||||
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
|
||||
<System>
|
||||
<EventID>5379</EventID>
|
||||
<Channel>Security</Channel>
|
||||
<Security />
|
||||
</System>
|
||||
<EventData>
|
||||
<Data>Available</Data>
|
||||
<Data>None</Data>
|
||||
<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`というeventkeyを指定します。この場合、EventDataタグにネストされているName属性の指定されてないタグのうち、いずれか一つでも一致するタグがあれば、条件に一致したものとして処理されます。
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 5379
|
||||
EventData: None
|
||||
``````
|
||||
|
||||
## パイプ
|
||||
eventkeyにはパイプを指定することができます。ここまで説明した書き方では完全一致しか表現できませんでしたが、パイプを使うことでより柔軟な検知ルールを記載できるようになります。下記の例ではCommandLineの値が`yamato.*lagotto`という正規表現にマッチする場合、条件に一致したものとして処理されます。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine|re: yamato.*lagotto
|
||||
``````
|
||||
|
||||
使用できるパイプの一覧です。なお、v1.0.0時点では、複数のパイプをつなげて使用することはできません。
|
||||
* startswith: 先頭一致
|
||||
* endswith: 後方一致
|
||||
* contains: 部分一致
|
||||
* re: 正規表現(正規表現の処理にはregexクレートを使用しています。正規表現の詳細記法についてはhttps://docs.rs/regex/1.5.4/regex/を参照してください。)
|
||||
|
||||
## ワイルドカード
|
||||
eventkeyに対応する値にはワイルドカードを指定することができます。下記の例ではCommandLineがlagottoという文字列で始まっていれば、条件に一致したものとして処理されます。基本的にはsigmaルールのwildcardと同じ仕様になっています。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine: lagotto*
|
||||
``````
|
||||
|
||||
使用できるワイルドカードの一覧です。
|
||||
* `*`: 任意の0文字以上の文字列にマッチします。(内部的には`.*`という正規表現に変換されます。)
|
||||
* `?`: 任意の1文字にマッチします。(内部的には`.`という正規表現に変換されます。)
|
||||
|
||||
ワイルドカードを使用する場合、下記のルールに則って解釈されます。
|
||||
* ワイルドカード(`*`と`?`)をエスケープするにはバックスラッシュ(`/`)を使用します。
|
||||
* ワイルドカードの直前に文字としてのバックスラッシュ(`/`)を使用する場合、`\\*`又は`\\?`と記載してください。
|
||||
* バックスラッシュを単体で使う分にはエスケープ不要です。
|
||||
|
||||
## eventkeyにネストできるキーワード
|
||||
eventkeyには特定のキーワードをネストさせることができます。下記の例ではCommandLineの値が`aa*bb`というワイルドカードにマッチした上で文字列長が10以上である場合、条件に一致したものと処理されます。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine:
|
||||
value: aa*bb
|
||||
min_length: 10
|
||||
``````
|
||||
|
||||
現状では下記のキーワードを指定できます。
|
||||
* value: 文字列による一致(ワイルドカードやパイプを指定することもできます)
|
||||
* min_length: 指定した文字数以上である場合、条件に一致したものとして処理されます。
|
||||
* regexes: 指定したファイルに記載された正規表現のリストにひとつでも一致すれば、`条件に一致した`ものとして処理されます。
|
||||
* whitelist: 指定したファイルに記載された正規表現のリストにひとつでも一致すれば、`条件に一致していない`ものとして処理されます。
|
||||
|
||||
### regexes.txtとwhitelist.txt
|
||||
lagottoではregexesやwhitelistを使用した組み込みのルールを用意しており、それらのルールはregexes.txtとwhitelist.txtを参照しています。regexes.txtとwhitelist.txtを書き換えることで、参照する全てのルールの挙動を一度に変更することが可能です。
|
||||
|
||||
また、regexesやwhitelistに指定するファイルは、ユーザーが独自に作成することも可能です。作成する場合、regexes.txtとwhitelist.txtを参考にしてください。
|
||||
|
||||
## condition
|
||||
これまでの記法を用いると、AND条件やOR条件を表現することができますが、ANDやOR等が複雑に入り組んだ条件を定義することは難しい場合があります。その場合、conditionというキーワードを使用することで、複雑な条件式を定義することができます。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection_1:
|
||||
EventID: 7040
|
||||
selection_2:
|
||||
EventID: 7041
|
||||
selection_3:
|
||||
Channel: System
|
||||
selection_4:
|
||||
CommandLine|contains: lsass.exe
|
||||
selection_5:
|
||||
CommandLine|contains: services.exe
|
||||
selection_6:
|
||||
ParentProcessName|contains: wininit.exe
|
||||
|
||||
condition: ( selection_1 or selection_2 ) and selection_3 and ( selection_4 or selection_5 ) and ( not selection_6 )
|
||||
``````
|
||||
|
||||
conditionには以下のキーワードを使用することができます。
|
||||
* {expression1} and {expression2}: {expression1}と{expression2}のAND条件を表します。
|
||||
* {expression1} or {expression2}: {expression1}と{expression2}のOR条件を表します。
|
||||
* not {expression}: {expression}の条件式の真偽を逆転させます。
|
||||
* ( {expression} ) : {expression}の条件式を優先して評価します。数学等で現れる括弧と同じです。
|
||||
|
||||
なお、上記の例では、条件式をグルーピングするためにselection_1やselection_2といった名前を使用していますが、selectionというprefixを付ける必要はなく、ユーザーが任意の名前を定義できます。ただし、使用可能な文字は`\w`という正規表現にマッチする文字のみです。
|
||||
|
||||
## aggregation condition
|
||||
上記で説明したconditionには、andやor条件だけでなく、検知したイベントログを集計するような機能も実装されています。この機能をaggregation conditionと呼んでおり、conditionの後にパイプでつなげて指定します。下記の例では、DestinationIpの値が3種類以上あるかどうかをSubjectUserName毎に判定する条件式になります。
|
||||
|
||||
``````
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
condition: selection | count(DestinationIp) by SubjectUserName >= 3
|
||||
``````
|
||||
|
||||
aggregation conditionは下記の形式で定義できます。なお、{number}には数値を指定します。
|
||||
* `count() {operator} {number}`: conditionのパイプ以前の条件に一致したログについて、一致したログ数が{operator}と{number}で指定した条件式を満たす場合に、条件に一致したものとして処理されます。
|
||||
|
||||
|
||||
|
||||
* `count() by {eventkey_2} {operator} {number}`: conditionのパイプ以前の条件に一致したログを{eventkey_2}毎にグルーピングし、グルーピング毎に一致したログ数が{operator}と{number}で指定した条件式を満たす場合に、条件に一致したものとして処理されます。
|
||||
|
||||
|
||||
|
||||
* `count({eventkey}) {operator} {number}`: conditionのパイプ以前の条件に一致したログについて、{eventkey}の値が何種類存在するか数えます。その数が{operator}と{number}で指定した条件式を満たす場合に、条件に一致したものとして処理されます。
|
||||
|
||||
|
||||
|
||||
* `count({eventkey_1}) by {eventkey_2} {operator} {number}`: conditionのパイプ以前の条件に一致したログを{eventkey_2}毎にグルーピングし、そのグループ毎に{eventkey_1}の値が何種類存在するか数えます。そのグルーピング毎に数えた値が{operator}と{number}で指定した条件式を満たす場合に、条件に一致したものとして処理されます。
|
||||
|
||||
|
||||
|
||||
また、上記のoperatorには下記を指定できます。
|
||||
* `==`: 指定された値と等しい場合、条件に一致したものと処理されます。
|
||||
* `>=`: 指定された値以上である場合、条件に一致したものと処理されます。
|
||||
* `>`: 指定された値より大きい場合、条件に一致したものと処理されます。
|
||||
* `<=`: 指定された値以下である場合、条件に一致したものと処理されます。
|
||||
* `<`: 指定された値より小さい場合、条件に一致したものと処理されます。
|
||||
|
||||
# outputの記法
|
||||
detectionの条件に一致した場合に、出力されるメッセージを指定できます。固定の文字列が出力できる他、eventkeyを%で囲むことにより、検知したログの値を表示することも可能です。下記の例では検知した際のメッセージにScriptBlockTextというeventkeyの値を使用しています。
|
||||
|
||||
``````
|
||||
output: 'command=%ScriptBlockText%'
|
||||
``````
|
||||
BIN
hayabusa-logo.png
Normal file
BIN
hayabusa-logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Reference in New Issue
Block a user