Merge pull request #288 from Yamato-Security/readme-EN-update-2021-12-16
Readme-EN-update
This commit is contained in:
Yamato Security
GitHub
@@ -7,40 +7,56 @@
|
||||
</div>
|
||||
|
||||
# About Hayabusa
|
||||
Hayabusa ("falcon" in Japanese) 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. It is written in [Rust](https://www.rust-lang.org/) and supports multi-threading in order to be as fast as possible. It supports converted [sigma](https://github.com/SigmaHQ/sigma) and hayabusa detection rules written in YAML in order to be as easily customizable and extensible as possible. It can be run either on a live system or by gathering logs from multiple systems. 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).
|
||||
|
||||
## Fast forensics timeline generation
|
||||
## Main goals
|
||||
|
||||
### Threat hunting
|
||||
Hayabusa currently has over 1000 sigma rules and around 50 hayabusa rules with more rules being added regularly. The ultimate goal is to be able to push out hayabusa agents to all Windows endpoints after an incident or for periodic threat hunting and have them alert back to a central server.
|
||||
|
||||
### Fast forensics timeline generation
|
||||
Windows event log analysis has traditionally been a very long and tedious process because Windows event logs are 1) in a data format that is hard to analyze and 2) the majority of data is noise and not useful for investigations. Hayabusa's main goal is to extract out only useful data and present it in an easy-to-read format that is usable not only by professionally trained analysts but any Windows system administrator.
|
||||
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 slower deep-dive analysis but is intended for letting analysts get 80% of their work done in 20% of the time.
|
||||
|
||||
## Threat hunting
|
||||
Hayabusa currently has over 1000 detection rules and the ultimate goal is to be able to push out hayabusa agents to all Windows endpoints after an incident or for periodic threat hunting and have them alert back to a central server.
|
||||
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:
|
||||
## Startup:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal output:
|
||||
## Terminal output:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Results summary:
|
||||
## Results summary:
|
||||
|
||||
|
||||
|
||||
|
||||
## Analysis in Excel:
|
||||
|
||||
|
||||
|
||||
## Analysis in Timeline Explorer:
|
||||
|
||||
|
||||
|
||||
## Critical alert filtering and computer grouping in Timeline Explorer:
|
||||
|
||||
|
||||
|
||||
# Sample timeline results
|
||||
You can check out sample CSV and manually edited XLSX timeline results [here](https://github.com/Yamato-Security/hayabusa/tree/main/sample-results).
|
||||
|
||||
# Features
|
||||
* Cross-platform support: Windows, Linux, macOS
|
||||
* Developed in Rust to be memory safe and faster than a hayabusa falcon!
|
||||
* Multi-thread support
|
||||
* 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)
|
||||
@@ -53,93 +69,178 @@ Results summary:
|
||||
* MITRE ATT&CK heatmap generation
|
||||
* User logon and failed logon summary
|
||||
* Input from JSON logs
|
||||
* Output to JSON -> import to Elastic Stack/Splunk
|
||||
* 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
|
||||
If you have rust installed, you can compile from source with the following command.
|
||||
```bash
|
||||
git clone https://github.com/Yamato-Security/hayabusa.git
|
||||
```
|
||||
|
||||
````
|
||||
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.
|
||||
|
||||
# Compiling from source (Optional)
|
||||
If you have rust installed, you can compile from source with the following command:
|
||||
|
||||
```bash
|
||||
cargo clean
|
||||
cargo build --release
|
||||
````
|
||||
```
|
||||
|
||||
# Usage
|
||||
## Command line options
|
||||
````
|
||||
USAGE:
|
||||
-f --filepath=[FILEPATH] 'File path to one .evtx file'
|
||||
--csv-timeline=[CSV_TIMELINE] 'Save the timeline in CSV format'
|
||||
--rfc-2822 'Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600'
|
||||
--rfc-3339 'Output date and time in RFC 3339 format. Example: 2006-08-07T12:34:56.485214 -06:00'
|
||||
--verbose 'Output verbose information to target event file path and rule file'
|
||||
-q 'Quiet mode. Do not display the launch banner'
|
||||
-r --rules=[RULEDIRECTORY] 'Rule file directory (default: ./rules)'
|
||||
-m --min-level=[LEVEL] 'Minimum level for rules (default: informational)' (Possiblities are: informational, low, medium, high, critical)
|
||||
-u --utc 'Output time in UTC format (default: local time)'
|
||||
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
|
||||
-s --statistics 'Prints statistics of event IDs'
|
||||
-n --show-noisyalerts 'do not exclude noisy rules'
|
||||
-t --threadnum=[NUM] 'Thread number (default: optimal number for performance)' (Usually there is no performance benefit in increasing the number of threads but you may want to lower to a smaller number to reduce CPU load.)
|
||||
--contributors 'Prints the list of contributors'
|
||||
````
|
||||
## Advanced: Updating Rust packages
|
||||
You can update to the latest rust crates before compiling to get the latest libraries:
|
||||
|
||||
## Usage examples
|
||||
* Run hayabusa against one Windows event log file:
|
||||
````
|
||||
hayabusa.exe -f eventlog.evtx
|
||||
````
|
||||
```bash
|
||||
cargo update
|
||||
```
|
||||
|
||||
* Run hayabusa against the sample-evtx directory with multiple Windows event log files:
|
||||
````
|
||||
hayabusa.exe -d .\sample-evtx
|
||||
````
|
||||
|
||||
* Export to a single CSV file for further analysis with excel or timeline explorer:
|
||||
````
|
||||
hayabusa.exe -d .\sample-evtx --csv-timeline results.csv
|
||||
````
|
||||
|
||||
* Only run hayabusa rules:
|
||||
````
|
||||
hayabusa.exe -d .\sample-evtx --csv-timeline results.csv -r ./rules/hayabusa
|
||||
````
|
||||
|
||||
* Only run sigma rules and show noisy alerts (disabled by default):
|
||||
````
|
||||
hayabusa.exe -d .\sample-evtx --csv-timeline results.csv -r ./rules/sigma --show-noisyalerts
|
||||
````
|
||||
|
||||
* Only run rules to analyze logons and output in the UTC timezone:
|
||||
````
|
||||
hayabusa.exe -d .\sample-evtx --csv-timeline results.csv -r ./rules/hayabusa/default/events/Security/Logons -u
|
||||
````
|
||||
|
||||
* Run on a live Windows machine (requires Administrator privileges) and only detect alerts (potentially malicious behavior):
|
||||
````
|
||||
hayabusa.exe -d C:\Windows\System32\winevt\Logs -m low
|
||||
````
|
||||
|
||||
* Get event ID statistics:
|
||||
````
|
||||
hayabusa.exe -d C:\Windows\System32\winevt\Logs -s
|
||||
````
|
||||
Please let us know if anything breaks after you update.
|
||||
|
||||
## 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 if you want to follow along in the examples below.
|
||||
|
||||
# Usage
|
||||
## Command line options
|
||||
```bash
|
||||
USAGE:
|
||||
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
|
||||
-f --filepath=[FILEPATH] 'File path to one .evtx file'
|
||||
-r --rules=[RULEDIRECTORY] 'Rule file directory (default: ./rules)'
|
||||
-o --output=[CSV_TIMELINE] 'Save the timeline in CSV format. Example: results.csv'
|
||||
-v --verbose 'Output verbose information'
|
||||
-D --enable-deprecated-rules 'Enable sigma rules marked as deprecated'
|
||||
-n --enable-noisy-rules 'Enable rules marked as noisy'
|
||||
-m --min-level=[LEVEL] 'Minimum level for rules (default: informational)'
|
||||
--start-timeline=[STARTTIMELINE] 'Start time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
|
||||
--end-timeline=[ENDTIMELINE] 'End time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
|
||||
--rfc-2822 'Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600'
|
||||
--rfc-3339 'Output date and time in RFC 3339 format. Example: 2006-08-07T12:34:56.485214 -06:00'
|
||||
-u --utc 'Output time in UTC format (default: local time)'
|
||||
-t --thread-number=[NUMBER] 'Thread number (default: optimal number for performance)'
|
||||
-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.'
|
||||
--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:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx
|
||||
```
|
||||
|
||||
* Export to a single CSV file for further analysis with excel or timeline explorer:
|
||||
```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`):
|
||||
```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:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\default -o results.csv
|
||||
```
|
||||
|
||||
* Only run hayabusa rules for sysmon logs:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
|
||||
```
|
||||
|
||||
* Only run sigma rules:
|
||||
```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`):
|
||||
```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:
|
||||
```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
|
||||
```
|
||||
|
||||
* Print verbose information (useful for determining which files take long to process, parsing errors, 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
|
||||
```
|
||||
|
||||
* Quiet error mode:
|
||||
By default, hayabusa will save error messages to error log files.
|
||||
If you do not want to save error messages, please add `-Q`.
|
||||
|
||||
# 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`: This comes from the `<Event><System><Computer>` field in the event log.
|
||||
* `Event ID`: This comes from the `<Event><System><EventID>` 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.
|
||||
* `Title`: This comes from the `title` field in the YML detection rule.
|
||||
* `Details`: This comes from the `details` 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.
|
||||
|
||||
## 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 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 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.
|
||||
|
||||
All of the rules are in the `rules` folder.
|
||||
`informational` level rules are considered `events`, while anything rated `low` and higher are considered `alerts`.
|
||||
All of the rules from the hayabusa-rules repository should be placed in the `rules` folder.
|
||||
`informational` level rules are considered `events`, while anything with a `level` of `low` and higher are considered `alerts`.
|
||||
|
||||
The hayabusa rule directory structure is separated into 3 directories:
|
||||
* `default`: logs that are turned on by default
|
||||
* `non-default`: logs that need to be turned on through group policy
|
||||
* `default`: logs that are turned on in Windows by default.
|
||||
* `non-default`: logs that need to be turned on through group policy, security baselines, etc...
|
||||
* `sysmon`: logs that are generated by [sysmon](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon).
|
||||
* `testing`: a temporary directory to put rules that you are currently testing
|
||||
|
||||
@@ -153,57 +254,70 @@ Please check out the current rules to use as a template in creating new ones or
|
||||
|
||||
## Hayabusa v.s. converted Sigma rules
|
||||
Sigma rules need to first be converted to hayabusa rule format explained [here](https://github.com/Yamato-Security/hayabusa/blob/main/tools/sigmac/README-English.md). Hayabusa rules are designed solely for Windows event log analysis and have the following benefits:
|
||||
1. An extra `output` field to display additional information taken from only the useful fields in the log.
|
||||
1. An extra `details` field to display additional information taken from only the useful fields in the log.
|
||||
2. They are all tested against sample logs and are known to work.
|
||||
> Some sigma rules may not work as intended due to bugs in the conversion process, unsupported features, or differences in implementation (such as in regular expressions).
|
||||
3. Japanese output in the `title_jp` and `output_jp` field.
|
||||
|
||||
**Limitations**: To our knowledge, hayabusa provides the greatest support for sigma rules out of any open source Windows event log analysis tool, however, there are still rules that are not supported:
|
||||
1. Rules that use regular expressions that do not work with the [Rust regex crate](https://docs.rs/regex/1.5.4/regex/)
|
||||
2. Rules that use `1 of them` or `all of them`
|
||||
3. Rules that use the following modifiers: `base64`, `base64offset`, `utf16le`, `utf16be`, `wide`, `utf16`.
|
||||
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.
|
||||
|
||||
## Detection rule tuning
|
||||
Like firewalls and IDSes, any signature-based tool will require some tuning to fit your environment so you may need to permanently or temporarily exclude certain rules.
|
||||
|
||||
You can add a rule ID (Example: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6) to `config/exclude-rules.txt` in order to ignore any rule you do not need.
|
||||
You can add a rule ID (Example: `4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6`) to `config/exclude-rules.txt` in order to ignore any rule that you do not need or cannot be used.
|
||||
|
||||
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 `--show-noisyalerts` option.
|
||||
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 filter on event IDs by placing event ID numbers in `config/target_eventids.txt`.
|
||||
This will increase performance so it is recommended if you only need to search for certain IDs.
|
||||
|
||||
We have provided a sample ID filter list at [`config/target_eventids_sample.txt`](https://github.com/Yamato-Security/hayabusa/blob/main/config/target_eventids_sample.txt) created from the `EventID` fields in all of the rules as well as IDs seen in actual results.
|
||||
|
||||
Please use this list if you want the best performance but be aware that there is a slight possibility for false positives.
|
||||
|
||||
# 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.
|
||||
|
||||
- [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.
|
||||
- [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 by [Eric Conrad](https://twitter.com/eric_conrad).
|
||||
- [EVTXtract](https://github.com/williballenthin/EVTXtract) - Recover EVTX log files from unallocated space and memory images.
|
||||
- [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).
|
||||
- [RustyBlue](https://github.com/Yamato-Security/RustyBlue) - Rust port of DeepBlueCLI by Yamato Security.
|
||||
- [Sigma](https://github.com/SigmaHQ/sigma) - Community based 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).
|
||||
- [Windows Event Log Analysis - Analyst Reference](https://www.forwarddefense.com/media/attachments/2021/05/15/windows-event-log-analyst-reference.pdf) - by Forward Defense's Steve Anson.
|
||||
- [Zircolite](https://github.com/wagga40/Zircolite) - SIGMA based attack detection tool written in Python.
|
||||
- [Zircolite](https://github.com/wagga40/Zircolite) - Sigma-based attack detection tool written in Python.
|
||||
|
||||
## Comparison to other similar tools that support sigma
|
||||
It is not possible to do a perfect comparison as these tools support a different number of sigma rules.
|
||||
Hayabusa supports the largest number of sigma rules as well as will run additional hayabusa rules so will may take more time than other tools that do not do as much analysis.
|
||||
Also, time and memory usage will differ dramatically depending on what sample event log files are used, command-line options, rule tuning, etc... so please understand that results will vary.
|
||||
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 out of all the tools while still maintaining very fast speeds and does not require a great amount of memory.
|
||||
|
||||
The following were taken based on approximately 500 logs (130MB) from our sample-evtx repository at 2021/12/09.
|
||||
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 | 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).
|
||||
|
||||
| | Elapsed Time | Memory Usage | Total Sigma Events Detected | Unique Sigma Events Detected |
|
||||
| :---: | :---: | :---: | :---: | :---: |
|
||||
| Chainsaw | 10 seconds | 75 MB | 552 | 170 |
|
||||
| Hayabusa | xx | xx | 9783 | 265 |
|
||||
| Zircolite | 55 seconds | 400 MB | 1954 | 237 |
|
||||
|
||||
# License
|
||||
|
||||
Hayabusa is released under GPLv3 and all rules are released under the Detection Rule License (DRL) 1.1
|
||||
Hayabusa is released under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html) and all rules are released under the [Detection Rule License (DRL) 1.1](https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md).
|
||||
|
||||
# Contribution
|
||||
|
||||
|
||||
@@ -2,108 +2,325 @@
|
||||
<p>
|
||||
|
||||
|
||||
|
||||
</p>
|
||||
</div>
|
||||
|
||||
# Hayabusa
|
||||
Hayabusaは非常に高速なWindowsイベントアナライザで、フォレンジックタイムラインの作成や、HayabusaまたはSIGMAルールで記述されたIoCに基づいた脅威のハンティングを行うために使用されます。ライブでもオフラインでも実行でき、インシデント後に企業内のエンドポイントで実行されるエージェントとしてプッシュアウトすることもできます。
|
||||
# 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について
|
||||
Hayabusaは日本のYamato Securityグループによって書かれました。最初にDeepblueCLI Windowsイベントログアナライザに触発され、2020年にRustyBlueプロジェクトのためにRustに移植することから始まり、SIGMAのようなYAMLベースの柔軟なシグネチャを作成し、SIGMAのルールをhayabusaのルールに変換することをサポートするためにSIGMAにバックエンドを追加しました。マルチスレッドをサポートし、（我々の知る限り）現在最速のフォレンジックタイムラインジェネレータと脅威探索ツールであり、SIGMAの最も多くの機能をサポートしています。複数のWindowsイベントログを分析し、分析しやすいように結果を一つのタイムラインに集約することができます。また、CSV形式で出力されるので、Timeline ExplorerやExcelなどのツールに取り込んで分析することができます。
|
||||
## 主な目的
|
||||
|
||||
### スレット(脅威)ハンティング
|
||||
Hayabusa には現在、1000以上のSigmaルールと約50のHayabusa検知ルールがあり、定期的にルールが追加されています。 最終的な目標はインシデントの後で、または定期的なスレットハンティングのために、HayabusaエージェントをすべてのWindows端末にプッシュして、中央サーバーにアラートを返すことができるようにすることです。
|
||||
|
||||
### フォレンジックタイムラインの高速生成
|
||||
Windowsのイベントログは、
|
||||
1）解析が困難なデータ形式であること
|
||||
2）データの大半がノイズであり調査に有用でないこと
|
||||
から、従来は非常に長い時間と手間がかかる解析作業となっていました。 Hayabusa は、有用なデータのみを抽出し、専門的なトレーニングを受けた分析者だけでなく、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へのバックエンドとして追加しています。
|
||||
|
||||
# スクリーンショット
|
||||
screenshotを入れる
|
||||
## 起動画面:
|
||||
|
||||
# 機能
|
||||
* 複数のOSに対応: Windows, Linux, macOS (Intel + ARM)
|
||||
* ハヤブサよりも速い！
|
||||
* 英語と日本語に対応
|
||||
* マルチスレッド
|
||||
* フォレンジック調査用のイベントタイムライン作成
|
||||
* 作成・編集しやすいYAML形式のhayabusaルールでIoCシグネチャーを作成し、攻撃検知(スレットハンティング)を行う
|
||||
* SIGMAルールをhayabusaルールに自動変換
|
||||
* イベントログの集計(どのようなイベントがあるかを把握するためやログ設定のチューニングに便利)
|
||||
|
||||
|
||||
## ターミナル出力画面:
|
||||
|
||||
|
||||
|
||||
## 結果サマリ画面:
|
||||
|
||||
|
||||
|
||||
## Excelでの解析:
|
||||
|
||||
|
||||
|
||||
## Timeline Explorerでの解析:
|
||||
|
||||
|
||||
|
||||
## Criticalアラートのフィルタリングとコンピュータごとのグルーピング:
|
||||
|
||||
|
||||
|
||||
# タイムラインのサンプル結果
|
||||
CSVと手動で編集したXLSXのタイムライン結果のサンプルは[こちら](https://github.com/Yamato-Security/hayabusa/tree/main/sample-results)で確認できます。
|
||||
|
||||
# 特徴
|
||||
* クロスプラットフォーム対応: Windows, Linux, macOS
|
||||
* Rustで開発され、メモリセーフでハヤブサよりも高速です！
|
||||
* マルチスレッド対応により、最大5倍のスピードアップを実現!
|
||||
* フォレンジック調査やインシデントレスポンスのために、分析しやすいCSVタイムラインを作成します。
|
||||
* 読みやすい/作成/編集可能なYMLベースのHayabusaルールで作成されたIoCシグネチャに基づくスレット
|
||||
* SigmaルールをHayabusaルールに変換するためのSigmaルールのサポートがされています。
|
||||
* 現在、他の類似ツールに比べ最も多くのSigmaルールをサポートしており、カウントルールにも対応しています。
|
||||
* イベントログの統計（どのような種類のイベントがあるのかを把握し、ログ設定のチューニングに有効です。）
|
||||
* 不良ルールやノイズの多いルールを除外するルールチューニング設定が可能です。
|
||||
|
||||
# 予定されている機能
|
||||
* すべてのエンドポイントでの企業全体のスレットハンティング
|
||||
* 日本語対応
|
||||
* MITRE ATT&CK とのマッピング
|
||||
* MITRE ATT&CK ヒートマップ生成機能
|
||||
* ユーザーログオンと失敗したログオンのサマリー
|
||||
* JSONログからの入力
|
||||
* JSONへの出力→Elastic Stack/Splunkへのインポート
|
||||
|
||||
# ダウンロード
|
||||
[Releases](https://github.com/Yamato-Security/hayabusa/releases)からコンパイル済みの実行ファイルをダウンロードできます。
|
||||
以下の`git clone`コマンドでレポジトリをダウンロードできます:
|
||||
|
||||
# 使い方
|
||||
## コマンドラインオプション
|
||||
````
|
||||
USAGE:
|
||||
hayabusa.exe [FLAGS] [OPTIONS]
|
||||
```bash
|
||||
git clone https://github.com/Yamato-Security/hayabusa.git
|
||||
```
|
||||
|
||||
FLAGS:
|
||||
--credits コントリビューターの一覧表示
|
||||
-h, --help ヘルプ画面の表示
|
||||
--rfc-2822 日付と時間をRFC 2822形式で表示する。例： Mon, 07 Aug 2006 12:34:56 -0600
|
||||
-s, --statistics イベントログの集計
|
||||
-u, --utc 時間をUTCで出力する（デフォルトはローカル時間）
|
||||
-V, --version バージョン情報を出力する
|
||||
または、手動で[https://github.com/Yamato-Security/hayabusa](https://github.com/Yamato-Security/hayabusa)からHayabusaをダウンロードすることもできます。
|
||||
|
||||
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、Linux、macOS用のコンパイル済みバイナリを[Releases](https://github.com/Yamato-Security/Hayabusa/releases)からダウンロードして、`hayabusa`のディレクトリに置く必要があります。
|
||||
|
||||
## 使い方の例
|
||||
* Windowsイベントログを一つ指定する:
|
||||
````
|
||||
hayabusa.exe --filepath=eventlog.evtx
|
||||
````
|
||||
# ソースコードからのコンパイル（任意）
|
||||
rustがインストールされている場合、以下のコマンドでソースコードからコンパイルすることができます:
|
||||
|
||||
* 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フォルダには組み込みルールファイルも設置されていますので、参考にしてください。
|
||||
|
||||
# ソースコードからのコンパイル
|
||||
下記のコマンドでビルドできます。
|
||||
|
||||
````
|
||||
```bash
|
||||
cargo clean
|
||||
cargo build --release
|
||||
````
|
||||
```
|
||||
|
||||
# 関連するWindowsイベントログのスレットハンティングプロジェクト
|
||||
まだ完璧なWindowsイベントログ解析ツールは存在していなくて、それぞれ長所短所があるので、以下のツールとプロジェクトもチェックして、好きなツールを使ってくださいね！
|
||||
## アドバンス: Rustパッケージの更新
|
||||
コンパイル前に最新のRust crateにアップデートすることで、最新のライブラリを利用することができます:
|
||||
|
||||
- [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ベースの攻撃検知ツール。
|
||||
```bash
|
||||
cargo update
|
||||
```
|
||||
|
||||
## ライセンス
|
||||
※ アップデート後、何か不具合がありましたらお知らせください。
|
||||
|
||||
HayabusaのライセンスはGPLv3で、ルールはすべてDetection Rule License (DRL) 1.1でリリースしています。
|
||||
## サンプルevtxファイルでHayabusaをテストする
|
||||
Hayabusaをテストしたり、新しいルールを作成したりするためのサンプルevtxファイルをいくつか提供しています: [https://github.com/Yamato-Security/Hayabusa-sample-evtx](https://github.com/Yamato-Security/Hayabusa-sample-evtx)
|
||||
|
||||
## 貢献
|
||||
以下のコマンドで、サンプルのevtxファイルを新しいサブディレクトリ `hayabusa-sample-evtx` にダウンロードすることができます:
|
||||
```bash
|
||||
git clone https://github.com/Yamato-Security/hayabusa-sample-evtx.git
|
||||
```
|
||||
|
||||
コントリビューターは大募集中です！プルリクエストやルール作成が一番ですが、機能リクエストやバグのお知らせなども大歓迎です。
|
||||
> ※ 以下の例でHayabusaを試したい方は、上記コマンドをhayabusaのルートフォルダから実行してください。
|
||||
|
||||
hayabusaを気に入って頂けたら、Githubで星をつけて応援してくださいね！
|
||||
# 使用方法
|
||||
## コマンドラインオプション
|
||||
```bash
|
||||
USAGE:
|
||||
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
|
||||
-f --filepath=[FILEPATH] 'File path to one .evtx file'
|
||||
-r --rules=[RULEDIRECTORY] 'Rule file directory (default: ./rules)'
|
||||
-o --output=[CSV_TIMELINE] 'Save the timeline in CSV format. Example: results.csv'
|
||||
-v --verbose 'Output verbose information'
|
||||
-D --enable-deprecated-rules 'Enable sigma rules marked as deprecated'
|
||||
-n --enable-noisy-rules 'Enable rules marked as noisy'
|
||||
-m --min-level=[LEVEL] 'Minimum level for rules (default: informational)'
|
||||
--start-timeline=[STARTTIMELINE] 'Start time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
|
||||
--end-timeline=[ENDTIMELINE] 'End time of the event to load from event file. Example: '2018/11/28 12:00:00 +09:00''
|
||||
--rfc-2822 'Output date and time in RFC 2822 format. Example: Mon, 07 Aug 2006 12:34:56 -0600'
|
||||
--rfc-3339 'Output date and time in RFC 3339 format. Example: 2006-08-07T12:34:56.485214 -06:00'
|
||||
-u --utc 'Output time in UTC format (default: local time)'
|
||||
-t --thread-number=[NUMBER] 'Thread number (default: optimal number for performance)'
|
||||
-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.'
|
||||
--contributors 'Prints the list of contributors'
|
||||
```
|
||||
|
||||
## 使用例
|
||||
* 1 つのWindowsイベントログファイルに対してHayabusaを実行します:
|
||||
```bash
|
||||
hayabusa.exe -f eventlog.evtx
|
||||
```
|
||||
|
||||
* 複数のWindowsイベントログファイルのあるsample-evtxディレクトリに対して、Hayabusaを実行します:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx
|
||||
```
|
||||
|
||||
* 1 つのCSVファイルにエクスポートして、EXCELやTimeline Explorerでさらに分析することができます:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -o results.csv
|
||||
```
|
||||
|
||||
* Hayabusaルールのみを実行します（デフォルトでは `-r .\rules` にあるすべてのルールが利用されます）:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa -o results.csv
|
||||
```
|
||||
|
||||
* Windowsでデフォルトで有効になっているログに対してのみ、Hayabusaルールを実行します:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\default -o results.csv
|
||||
```
|
||||
|
||||
* Sysmonログに対してのみHayabusaルールを実行します:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv
|
||||
```
|
||||
|
||||
* Sigmaルールのみを実行します:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx -r .\rules\sigma -o results.csv
|
||||
```
|
||||
|
||||
* 廃棄(deprecated)されたルール(`status`が`deprecated`になっているルール)とノイジールール(`.\config\noisy-rules.txt`にルールIDが書かれているルール)を有効にします:
|
||||
```bash
|
||||
hayabusa.exe -d .\hayabusa-sample-evtx --enable-deprecated-rules --enable-noisy-rules -o results.csv
|
||||
```
|
||||
|
||||
* ログオン情報を分析するルールのみを実行し、UTCタイムゾーンで出力します:
|
||||
```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
|
||||
```
|
||||
|
||||
* 詳細なメッセージを出力します(処理に時間がかかるファイル、パースエラー等を特定するのに便利):
|
||||
```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
|
||||
```
|
||||
|
||||
* Quiet error mode:
|
||||
デフォルトでは、Hayabusaはエラーメッセージをエラーログに保存します。
|
||||
エラーメッセージを保存したくない場合は、`-Q`を追加してください。
|
||||
|
||||
# Hayabusaの出力
|
||||
Hayabusaの出力を画面に表示しているとき（デフォルト）は、以下の情報を表示します:
|
||||
|
||||
* `Timestamp`: デフォルトでは`YYYY-MM-DD HH:mm:ss.sss +hh:mm`形式になっています。イベントログの`<Event><System><TimeCreated SystemTime>`フィールドから来ています。デフォルトのタイムゾーンはローカルのタイムゾーンになりますが、`--utc` オプションで UTC に変更することができます。
|
||||
* `Computer`: イベントログの`<Event><System><Computer>`フィールドから来ています。
|
||||
* `Event ID`: イベントログの`<Event><System><EventID>`フィールドから来ています。
|
||||
* `Level`: YML検知ルールの`level`フィールドから来ています。(例：`informational`, `low`, `medium`, `high`, `critical`) デフォルトでは、すべてのレベルのアラートとイベントが出力されますが、`-m`オプションで最低のレベルを指定することができます。例えば`-m high`オプションを付けると、`high`と`critical`アラートしか出力されません。
|
||||
* `Title`: YML検知ルールの`title`フィールドから来ています。
|
||||
* `Details`: YML検知ルールの`details`フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログの`<Event><System><EventData>`部分から有用なデータを抽出することができます。
|
||||
|
||||
CSVファイルとして保存する場合、以下の2つのフィールドが追加されます:
|
||||
* `Rule Path`: アラートまたはイベントを生成した検知ルールへのパス。
|
||||
* `File Path`: アラートまたはイベントを起こしたevtxファイルへのパス。
|
||||
|
||||
## プログレスバー
|
||||
プログレス・バーは、複数のevtxファイルに対してのみ機能します。
|
||||
解析したevtxファイルの数と割合をリアルタイムで表示します。
|
||||
|
||||
# Hayabusa ルール
|
||||
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) をお読みください。
|
||||
|
||||
[hayabusa-rulesレポジトリ](https://github.com/Yamato-Security/hayabusa-rules)にあるすべてのルールは、`rules`フォルダに配置する必要があります。
|
||||
|
||||
情報レベルのルールは `events` とみなされ、`level`が`low` 以上のものは `alerts` とみなされます。
|
||||
|
||||
Hayabusaルールのディレクトリ構造は、3つのディレクトリに分かれています。
|
||||
* `default`: Windows OSでデフォルトで記録されるログ
|
||||
* `non-default`: グループポリシーやセキュリティベースラインの適用でオンにする必要があるログ
|
||||
* `sysmon`: [sysmon](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon)によって生成されるログ。
|
||||
* `testing`: 現在テストしているルールを配置するための一時ディレクトリ
|
||||
|
||||
ルールはさらにログタイプ（例：Security、Systemなど）によってディレクトリに分けられ、次の形式で名前が付けられます。
|
||||
* アラート形式: `<イベントID>_<MITRE ATT&CKの攻撃手法名>_<詳細>.yml`
|
||||
* アラート例: `1102_IndicatorRemovalOnHost-ClearWindowsEventLogs_SecurityLogCleared.yml`
|
||||
* イベント形式: `<イベント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のイベントログ解析専用に設計されており、以下のような利点があります:
|
||||
1. ログの有用なフィールドのみから抽出された追加情報を表示するための `details`フィールドを追加しています。
|
||||
2. Hayabusaルールはすべてサンプルログに対してテストされ、検知することが確認されています。
|
||||
> 変換処理のバグ、サポートされていない機能、実装の違い(正規表現など)により、一部のSigmaルールは意図したとおりに動作しない可能性があります。
|
||||
|
||||
**制限事項**: 私たちの知る限り、Hayabusa はオープンソースの Windows イベントログ解析ツールの中でSigmaルールを最も多くサポートしていますが、まだサポートされていないルールもあります。
|
||||
1. [Rust正規表現クレート](https://docs.rs/regex/1.5.4/regex/)では機能しない正規表現を使用するルール。
|
||||
2. [Sigmaルール仕様](https://github.com/SigmaHQ/Sigma/wiki/Specification)の`count`以外の集計式。
|
||||
|
||||
> 注意：この制限はSigmaルールの変換ツールにあり、Hayabusa自身にあるわけではありません。
|
||||
|
||||
## 検知ルールのチューニング
|
||||
ファイアウォールやIDSと同様に、シグネチャベースのツールは、環境に合わせて調整が必要になるため、特定のルールを永続的または一時的に除外する必要がある場合があります。
|
||||
|
||||
ルールID(例: `4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6`) を `config/exclude-rules.txt`に追加すると、不要なルールや利用できないルールを無視することができます。
|
||||
|
||||
ルールIDを `config/noisy-rules.txt`に追加して、デフォルトでルールを無視することもできますが、` -n`または `--enable-noisy-rules`オプションを指定してルールを使用することもできます。
|
||||
|
||||
## イベントIDフィルタリング
|
||||
`config/target_eventids.txt`にイベントID番号を追加することで、イベントIDでフィルタリングすることができます。
|
||||
これはパフォーマンスを向上させるので、特定のIDだけを検索したい場合に推奨されます。
|
||||
|
||||
すべてのルールの`EventID`フィールドと実際のスキャン結果で見られるIDから作成したIDフィルタリストのサンプルを[`config/target_eventids_sample.txt`](https://github.com/Yamato-Security/hayabusa/blob/main/config/target_eventids_sample.txt)で提供しています。
|
||||
|
||||
最高のパフォーマンスを得たい場合はこのリストを使用してください。ただし、誤検出の可能性が若干あることにご注意ください。
|
||||
|
||||
# その他の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で開発された攻撃検知ツール。
|
||||
- [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) による、横方向の動きを検知するためにログオンを視覚化するグラフィカルなインターフェースです。
|
||||
- [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にインポートします。
|
||||
- [Timeline Explorer](https://ericzimmerman.github.io/#!index.md) - [Eric Zimmerman](https://twitter.com/ericrzimmerman) による最高のCSVタイムラインアナライザーです。
|
||||
- [Windows Event Log Analysis - Analyst Reference](https://www.forwarddefense.com/media/attachments/2021/05/15/windows-event-log-analyst-reference.pdf) - Forward DefenseのSteve Ansonによるものです。
|
||||
- [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タイムラインにまとめる唯一のツールです。
|
||||
|
||||
# ライセンス
|
||||
|
||||
Hayabusaは[GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html)で公開され、すべてのルールは[Detection Rule License (DRL) 1.1](https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md)で公開されています。
|
||||
|
||||
# 貢献
|
||||
|
||||
どのような形でも構いませんので、ご協力をお願いします。プルリクエスト、ルール作成、evtxログのサンプルなどがベストですが、機能リクエスト、バグの通知なども大歓迎です。
|
||||
|
||||
少なくとも、私たちのツールを気に入っていただけたなら、Githubで星を付けて、あなたのサポートを表明してください。
|
||||
|
||||
@@ -5,6 +5,7 @@ Garigariganzy (@garigariganzy31): Developer, event ID statistics implementation,
|
||||
ItiB (@itiB_S144) : Core developer, sigmac hayabusa backend, rule creation, etc...
|
||||
James Takai / hachiyone(@hach1yon): Current lead developer, tokio multi-threading, sigma aggregation logic, sigmac backend, rule creation, sigma count implementation etc…
|
||||
Kazuminn (@k47_um1n): Developer
|
||||
Tsubokku (@ytsuboi0322): Translations
|
||||
Yusuke Matsui (@apt773): AD hacking working group leader, rule testing, documentation, research, support, etc...
|
||||
Zach Mathis (@yamatosecurity, Yamato Security Founder): Project leader, tool and concept design, rule creation and tuning, etc…
|
||||
|
||||
@@ -13,7 +14,7 @@ Hayabusa would not have been possible without first creating RustyBlue, so we wo
|
||||
|
||||
Zach Mathis (@yamatosecurity, Yamato Security Founder): Project Leader
|
||||
Nishikawa Akira (@nishikawaakira): Lead Developer
|
||||
kazuminn (@k47_um1n): Core Developer
|
||||
Kazuminn (@k47_um1n): Core Developer
|
||||
itiB (@itiB_S144): Core Developer
|
||||
James Takai / hachiyone (@hach1yon): Core Developer
|
||||
garigariganzy (@garigariganzy31): Developer
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Rule files
|
||||
## About rule files
|
||||
Hayabusa detection rules are written in [YAML](https://en.wikipedia.org/wiki/YAML) format.
|
||||
It can express complex detection rules by combining not only simple string matching but also regular expressions, `AND`, `OR`, and other conditions.
|
||||
In this section, we will explain how to write hayabusa detection rules.
|
||||
@@ -6,17 +6,17 @@ 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
|
||||
updated_date: 2021/11/26
|
||||
date: 2020/11/08
|
||||
modified: 2021/11/26
|
||||
|
||||
#Alert section
|
||||
title: User added to local Administrators group
|
||||
title_jp: ユーザがローカル管理者グループに追加された
|
||||
output: 'User: %MemberName% : SID: %MemberSid% : Group: %TargetUserName%'
|
||||
output_jp: 'ユーザ: %MemberName% : SID: %MemberSid% : グループ名: %TargetUserName%'
|
||||
details: 'User: %SubjectUserName% : Group: %TargetUserName% : LogonID: %SubjectLogonId%'
|
||||
details_jp: 'ユーザ: %SubjectUserName% : グループ名: %TargetUserName% : ログオンID: %SubjectLogonId%'
|
||||
description: A user was added to the local Administrators group.
|
||||
description_jp: ユーザがローカル管理者グループに追加された。
|
||||
|
||||
@@ -40,50 +40,51 @@ 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 section
|
||||
* **author [required]**: Name of the author(s).
|
||||
* **contributor** [optional]: Name of any contributor(s) (anyone who made any minor corrections).
|
||||
* **creation_date [required]**: Date the rule was made.
|
||||
* **updated_date** [optional]: Date the rule was updated.
|
||||
* **date [required]**: Date the rule was made.
|
||||
* **modified** [optional]: Date the rule was updated.
|
||||
|
||||
> #Alert section
|
||||
> ## Alert section
|
||||
* **title [required]**: Rule file title. This will also be the name of the alert that gets displayed so the briefer the better. (Should not be longer than 85 characters.)
|
||||
* **title_jp** [optional]: The title in Japanese.
|
||||
* output [optional]: The details of the alert that gets displayed. Please output any fields in the Windows event log that are useful for analysis. Fields are seperated by `" : "` (two spaces on both sides). Field placeholders are enclosed with a `%` (Example: `%MemberName%`) and need to be defined in `config\eventkey_alias.txt`. (Explained below.)
|
||||
* **output_jp** [optional]: The output message in Japanese.
|
||||
* **description** [optional]: A description of the rule. This does not get displayed so you can make this long.
|
||||
* details [optional]: The details of the alert that gets displayed. Please output any fields in the Windows event log that are useful for analysis. Fields are seperated by `" : "` (two spaces on both sides). Field placeholders are enclosed with a `%` (Example: `%MemberName%`) and need to be defined in `config\eventkey_alias.txt`. (Explained below.)
|
||||
* **details_jp** [optional]: The details message in Japanese.
|
||||
* **description** [optional]: A description of the rule. This does not get displayed so you can make this long and detailed.
|
||||
* **description_jp** [optional]: The description in Japanese.
|
||||
|
||||
> #Rule section
|
||||
> ## Rule section
|
||||
* **id [required]**: A randomly generated version 4 UUID used to uniquely identify the rule. You can generate one [here](https://www.uuidgenerator.net/version4).
|
||||
* **level [required]**: Severity level based on [sigma's definition](https://github.com/SigmaHQ/sigma/wiki/Specification). Please write one of the following: `informational`,`low`,`medium`,`high`,`critical`
|
||||
* **status[required]**: `stable` for tested rules and `testing` for rules that need to be tested.
|
||||
* **detection [required]**: The detection logic goes here. (Explained below.)
|
||||
* **falsepositives [required]**: The possibilities for false positives. For example: `system administrator`, `normal user usage`, `normal system usage`, `legacy application`, `security team`, `none`. If it is unknown, please write `unknown`.
|
||||
* **tags** [optional]: If the technique is a [LOLBINS/LOLBAS](https://lolbas-project.github.io/) technique, please add the `lolbas` tag. If the alert can be mapped to a technique in the [MITRE ATT&CK](https://attack.mitre.org/) framework, please add the tactic ID (Example: `attack.t1098`) and any applicable tactics below:
|
||||
* attack.impact -> Impact
|
||||
* attack.initial_access -> Initial Access
|
||||
* attack.execution -> Execution
|
||||
* attack.lateral_movement -> Lateral Movement
|
||||
* attack.persistence -> Persistence
|
||||
* attack.privilege_escalation -> Privilege Escalation
|
||||
* attack.reconnaissance -> Reconnaissance
|
||||
* attack.collection -> Collection
|
||||
* attack.command_and_control -> Command and Control
|
||||
* attack.credential_access -> Credential Access
|
||||
* attack.defense_evasion -> Defense Evasion
|
||||
* attack.discovery -> Discovery
|
||||
* attack.exfiltration -> Exfiltration
|
||||
* attack.resource_development -> Resource Development
|
||||
* `attack.impact` -> Impact
|
||||
* `attack.initial_access` -> Initial Access
|
||||
* `attack.execution` -> Execution
|
||||
* `attack.lateral_movement` -> Lateral Movement
|
||||
* `attack.persistence` -> Persistence
|
||||
* `attack.privilege_escalation` -> Privilege Escalation
|
||||
* `attack.reconnaissance` -> Reconnaissance
|
||||
* `attack.collection` -> Collection
|
||||
* `attack.command_and_control` -> Command and Control
|
||||
* `attack.credential_access` -> Credential Access
|
||||
* `attack.defense_evasion` -> Defense Evasion
|
||||
* `attack.discovery` -> Discovery
|
||||
* `attack.exfiltration` -> Exfiltration
|
||||
* `attack.resource_development` -> Resource Development
|
||||
* **references** [optional]: Any links to references.
|
||||
* **sample-evtx [required]**: File path or URL to an event log file that this rule will detect.
|
||||
* **logsource [required]**: The source of where the log comes from. Please specify one of the following:
|
||||
* `default`: For logs that are turned on in Windows by default.
|
||||
* `non-default`: For logs that need to be turned on through group policy, etc...
|
||||
* `non-default`: For logs that need to be turned on through group policy, security baselines, etc...
|
||||
* `sysmon`: Logs that require sysmon to be installed.
|
||||
* **non-default-setting** [optional]: Explanation of how to turn on the log setting for `non-default` log sources.
|
||||
* **ruletype [required]**: `Hayabusa` for hayabusa rules. Rules automatically converted from sigma will be `Sigma`.
|
||||
* **ruletype [required]**: `Hayabusa` for hayabusa rules. Rules automatically converted from sigma Windows rules will be `Sigma`.
|
||||
|
||||
# Detection field
|
||||
## Detection fundamentals
|
||||
@@ -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,26 +149,26 @@ 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%`, then you need to update `config\eventkey_alias.txt` with a new alias.
|
||||
Not all eventkey aliases are defined in `config\eventkey_alias.txt`. If you are not getting the correct data in the `details`(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.
|
||||
|
||||
### 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,22 +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>
|
||||
@@ -208,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
|
||||
@@ -220,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>
|
||||
@@ -238,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
|
||||
@@ -274,18 +289,18 @@ 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 `. *`.)
|
||||
* `?`: Matches any single character. (Internally converted to the regular expression `. `.)
|
||||
* `*`: Matches any string of zero or more characters. (Internally it is converted to the regular expression `.*`)
|
||||
* `?`: Matches any single character. (Internally converted to the regular expression `.`)
|
||||
|
||||
About escaping wildcards:
|
||||
* Wildcards (`*` and `?`) can be escaped by using a backslash: `\*`, `\?`.
|
||||
@@ -295,23 +310,23 @@ About escaping wildcards:
|
||||
## Nesting keywords inside eventkeys
|
||||
Eventkeys can be nested with specific keywords.
|
||||
In the example below, the rule will match if the following are true:
|
||||
* `ServiceName` is called `malicious-service` or contains a regular expression in `./config/regex/regexes_suspicous_service.txt`.
|
||||
* `ServiceName` is called `malicious-service` or contains a regular expression in `./config/regex/detectlist_suspicous_services.txt`.
|
||||
* `ImagePath` has a minimum of 1000 characters.
|
||||
* `ImagePath` does not have any matches in the `allowlist`.
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: System
|
||||
EventID: 7045
|
||||
ServiceName:
|
||||
- value: malicious-service
|
||||
- regexes: ./config/regex/regexes_suspicous_services.txt
|
||||
- regexes: ./config/regex/detectlist_suspicous_services.txt
|
||||
ImagePath:
|
||||
min_length: 1000
|
||||
allowlist: ./config/regex/allowlist_legitimate_serviceimage.txt
|
||||
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).
|
||||
@@ -320,20 +335,20 @@ Currently, the following keywords can be specified:
|
||||
* `allowlist`: rule will be skipped if there is any match found in the list of regular expressions in the file that you specify in this field.
|
||||
|
||||
### regexes and allowlist keywords
|
||||
Hayabusa has two built-in regular expression files:
|
||||
* `./config/regex/regexes_suspicous_services.txt`: to detect suspicious service names
|
||||
* `./config/regex/allowlist_legitimate_serviceimage.txt`: to allow legitimate services
|
||||
Hayabusa has two built-in regular expression files used for the `.\rules\hayabusa\default\alerts\System\7045_CreateOrModiftySystemProcess-WindowsService_MaliciousServiceInstalled.yml` file:
|
||||
* `./config/regex/detectlist_suspicous_services.txt`: to detect suspicious service names
|
||||
* `./config/regex/allowlist_legitimate_services.txt`: to allow legitimate services
|
||||
|
||||
Files defined in `regexes` and `allowlist` can be edited to change the behavior of all rules that reference them without having to change any rule file itself.
|
||||
|
||||
You can also use different regexes and allowlist textfiles that you create.
|
||||
Please refer to the default `./config/regexes_suspicous_services.txt` and `./config/allowlist_legitimate_serviceimage.txt` when creating your own.
|
||||
You can also use different detectlist and allowlist textfiles that you create.
|
||||
Please refer to the built-in `./config/regex/detectlist_suspicous_services.txt` and `./config/regex/allowlist_legitimate_services.txt` when creating your own.
|
||||
|
||||
## condition
|
||||
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.
|
||||
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
|
||||
@@ -354,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}
|
||||
@@ -365,22 +380,46 @@ The following expressions can be used for `condition`.
|
||||
In the above example, selection names such as `SELECTION_1`, `SELECTION_2`, etc... are used but they can be named anything as long as they only contain the following characters: `a-z A-Z 0-9 _`
|
||||
> However, please use the standard convention of `selection_1`, `selection_2`, `filter_1`, `filter_2`, etc... to make things easy to read whenever possible.
|
||||
|
||||
## aggregation condition
|
||||
## not logic
|
||||
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
|
||||
EventID: 4673
|
||||
filter:
|
||||
- ProcessName: C:\Windows\System32\net.exe
|
||||
- ProcessName: C:\Windows\System32\lsass.exe
|
||||
- ProcessName: C:\Windows\System32\audiodg.exe
|
||||
- ProcessName: C:\Windows\System32\svchost.exe
|
||||
- ProcessName: C:\Windows\System32\mmc.exe
|
||||
- ProcessName: C:\Windows\System32\net.exe
|
||||
- ProcessName: C:\Windows\explorer.exe
|
||||
- ProcessName: C:\Windows\System32\SettingSyncHost.exe
|
||||
- ProcessName: C:\Windows\System32\sdiagnhost.exe
|
||||
- ProcessName|startswith: C:\Program Files
|
||||
- SubjectUserName: LOCAL SERVICE
|
||||
condition: selection and not filter
|
||||
```
|
||||
|
||||
## Aggregation conditions (Count rules)
|
||||
### Basics
|
||||
The `condition` keyword described above implements not only `AND` and `OR` logic, but is also able to count or "aggregate" events.
|
||||
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.
|
||||
In this password spray detection example below, a conditional expression is used to determine if there are 5 or more `TargetUserName` values from one source `IpAddress` within a timeframe of 5 minutes.
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
condition: selection | count(AccountName) by ComputerName >= 10
|
||||
timeframe: 24h
|
||||
``````
|
||||
condition: selection | count(TargetUserName) by IpAddress > 5
|
||||
timeframe: 5m
|
||||
```
|
||||
|
||||
The aggregation condition can be defined in the following format:
|
||||
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}`.
|
||||
|
||||
`{operator}` can be one of the following:
|
||||
@@ -398,84 +437,158 @@ The aggregation condition can be defined in the following format:
|
||||
* `12h`: 12 hours
|
||||
* `7d`: 7 days
|
||||
* `3M`: 3 months
|
||||
> `timeframe` is not required by highly encouraged to define when possible for performance and memory efficiency.
|
||||
> `timeframe` is not required but highly encouraged to define when possible for performance and memory efficiency.
|
||||
|
||||
|
||||
### 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.
|
||||
2. No count argument but there is a `by` keyword. Example: `selection | count() by Date > 10`
|
||||
> `selection` will have to be true more than 10 times for the **same** `Date`.
|
||||
3. There is a count argument but no `by` keyword. Example: `selection | count(Users) > 10`
|
||||
> If `selection` matches and `Users` 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 Date > 10`
|
||||
> For the **same** `Date`, there will need to be more than 10 **different** `Users` in order for the condition to 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 `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.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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
|
||||
```
|
||||
The timestamp of the alert will be the time from the first event detected.
|
||||
|
||||
# Rule creation advice
|
||||
1. **When possible, always specify the `Channel` name.** In the future, we may filter on channel names so your rule may be ignored if the proper `Channel` is not set.
|
||||
2. **When possible, always specify the `EventID`.** In the future, we may filter on channel names so your rule may be ignored if the proper `EventID` is not set.
|
||||
3. **Do not use multiple `selection` fields when it is not needed.** For example:
|
||||
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 and excessive grouping when it is not needed.** For example:
|
||||
|
||||
Bad example:
|
||||
```
|
||||
### Bad example:
|
||||
```yaml
|
||||
detection:
|
||||
SELECTION_1:
|
||||
EventID: 4625
|
||||
SELECTION_2:
|
||||
LogonType: 3
|
||||
condition: SELECTION_1 and SELECTION_2
|
||||
SELECTION_1:
|
||||
Channnel: Security
|
||||
SELECTION_2:
|
||||
EventID: 4625
|
||||
SELECTION_3:
|
||||
LogonType: 3
|
||||
FILTER_1:
|
||||
SubStatus: "0xc0000064" #Non-existent user
|
||||
FILTER_2:
|
||||
SubStatus: "0xc000006a" #Wrong password
|
||||
condition: SELECTION_1 and SELECTION_2 and SELECTION_3 and not (FILTER_1 or FILTER_2)
|
||||
```
|
||||
|
||||
Good example:
|
||||
```
|
||||
### Good example:
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 4625
|
||||
LogonType: 3
|
||||
condition: selection
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4625
|
||||
LogonType: 3
|
||||
filter:
|
||||
- SubStatus: "0xc0000064" #Non-existent user
|
||||
- SubStatus: "0xc000006a" #Wrong password
|
||||
condition: selection and not filter
|
||||
```
|
||||
|
||||
4. **Name any of your filtering selections `filter`, `filter_1`, `filter_2`, etc... and do not use excessive grouping.**
|
||||
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:
|
||||
SELECTION_1:
|
||||
EventID: 4625
|
||||
SELECTION_2:
|
||||
LogonType: 3
|
||||
SELECTION_3:
|
||||
IpAddress: '-'
|
||||
condition: ((SELECTION_1 and SELECTION_2) and not (SELECTION_3))
|
||||
Takoyaki:
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
Naruto:
|
||||
TargetUserName|endswith: "$"
|
||||
IpAddress: "-"
|
||||
Sushi:
|
||||
SubjectUserName|endswith: "$"
|
||||
TargetUserName|endswith: "$"
|
||||
TargetInfo|endswith: "$"
|
||||
Godzilla:
|
||||
SubjectUserName|endswith: "$"
|
||||
Ninja:
|
||||
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$"
|
||||
IpAddress: "-"
|
||||
Daisuki:
|
||||
- ProcessName|endswith: "powershell.exe"
|
||||
- ProcessName|endswith: "WMIC.exe"
|
||||
condition: Takoyaki and Daisuki and not (Naruto and not Godzilla) and not Ninja and not Sushi
|
||||
```
|
||||
|
||||
Good example:
|
||||
```
|
||||
### OK example:
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 4625
|
||||
LogonType: 3
|
||||
filter:
|
||||
IpAddress: '-'
|
||||
condition: selection and not filter
|
||||
```
|
||||
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
|
||||
EventID: 4648
|
||||
selection_TargetUserIsComputerAccount:
|
||||
TargetUserName|endswith: "$"
|
||||
IpAddress: "-"
|
||||
filter_UsersAndTargetServerAreComputerAccounts: #Filter system noise
|
||||
SubjectUserName|endswith: "$"
|
||||
TargetUserName|endswith: "$"
|
||||
TargetInfo|endswith: "$"
|
||||
filter_SubjectUserIsComputerAccount:
|
||||
SubjectUserName|endswith: "$"
|
||||
filter_SystemAccounts:
|
||||
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_SuspiciousProcess:
|
||||
- ProcessName|endswith: "powershell.exe"
|
||||
- ProcessName|endswith: "WMIC.exe"
|
||||
condition: selection_basic and selection_SuspiciousProcess and not (selection_TargetUserIsComputerAccount
|
||||
and not filter_SubjectUserIsComputerAccount) and not filter_SystemAccounts and not filter_UsersAndTargetServerAreComputerAccounts
|
||||
```
|
||||
|
||||
# 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/).
|
||||
|
||||
The documentation for how to use it is [here](https://github.com/Yamato-Security/hayabusa/blob/main/tools/sigmac/README-English.md).
|
||||
@@ -1,84 +1,151 @@
|
||||
# ルールファイル
|
||||
HayabusaはWindowsEventログの検知ルールをYAML形式のファイルに記載します。
|
||||
単なる文字列一致だけでなく、正規表現やANDやOR等の条件を組み合わせることができ、複雑な検知ルールも表現できるようになっています。
|
||||
ここではその検知ルールの書き方について説明します。
|
||||
# ルールファイルについて
|
||||
Hayabusaの検知ルールは、[YAML](https://en.wikipedia.org/wiki/YAML) 形式で記述されています。
|
||||
単純な文字列のマッチングだけでなく、正規表現や`AND`、`OR`などの条件を組み合わせて複雑な検知ルールを表現することができます。
|
||||
本節では、Hayabusaの検知ルールの書き方について説明します。
|
||||
|
||||
# ルールファイルのフォーマット
|
||||
ルールファイルのフォーマットは下記の通りです。
|
||||
## ルールファイル形式
|
||||
記述例:
|
||||
|
||||
``````
|
||||
title: PowerShell Execution Pipeline
|
||||
description: This rule detect powershell execution pipeline.
|
||||
author: Zach Mathis
|
||||
```yaml
|
||||
#Author section
|
||||
author: Eric Conrad, Zach Mathis
|
||||
date: 2020/11/08
|
||||
modified: 2021/11/26
|
||||
|
||||
#Alert section
|
||||
title: User added to local Administrators group
|
||||
title_jp: ユーザがローカル管理者グループに追加された
|
||||
details: 'User: %SubjectUserName% : Group: %TargetUserName% : LogonID: %SubjectLogonId%'
|
||||
details_jp: 'ユーザ: %SubjectUserName% : グループ名: %TargetUserName% : ログオンID: %SubjectLogonId%'
|
||||
description: A user was added to the local Administrators group.
|
||||
description_jp: ユーザがローカル管理者グループに追加された。
|
||||
|
||||
#Rule section
|
||||
id: 611e2e76-a28f-4255-812c-eb8836b2f5bb
|
||||
level: high
|
||||
status: stable
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID: 7040
|
||||
Event.System.Channel: System
|
||||
Channel: Security
|
||||
EventID: 4732
|
||||
TargetUserName: Administrators
|
||||
condition: selection
|
||||
falsepositives:
|
||||
- unknown
|
||||
level: medium
|
||||
output: 'command=%CommandLine%'
|
||||
creation_date: 2020/11/8
|
||||
updated_date: 2020/11/8
|
||||
``````
|
||||
- system administrator
|
||||
tags:
|
||||
- attack.persistence
|
||||
- attack.t1098
|
||||
references:
|
||||
- https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4732
|
||||
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
|
||||
```
|
||||
|
||||
* title [required]: ルールファイルのタイトルを入力します。
|
||||
* description [optional]: ルールファイルの説明を入力します。
|
||||
* author [optional]: ルールファイルの作者を入力します。
|
||||
* detection [required]: 検知ルールを入力します。
|
||||
* falsepositives [optional]: 誤検知に関する情報を入力します。例：unknown、system administrator、normal user usage、normal system usage、legacy application、security team等々。
|
||||
* level [optional]: リスクレベルを入力します。指定する値は`informational`,`low`,`medium`,`high`,`critical`のいづれかです。
|
||||
* output [required]: イベントログが検知した場合に表示されるメッセージを入力します。
|
||||
* creation_date [optional]: ルールファイルの作成日を入力します。
|
||||
* updated_date [optional]: ルールファイルの更新日を入力します。
|
||||
> ## 著者名欄
|
||||
* **author [必須]**: 著者名（複数可）。
|
||||
* **contributor** [オプション]: 寄稿者の名前（細かい修正をした人）。
|
||||
* **date [必須]**: ルールが作成された日付。
|
||||
* **modified** [オプション]: ルールが更新された日付。
|
||||
|
||||
# detectionの記法について
|
||||
## detectionの基本
|
||||
まず、detectionの基本的な書き方について説明します。
|
||||
> ## アラートセクション
|
||||
* **title [必須]**: ルールファイルのタイトル。これは表示されるアラートの名前にもなるので、簡潔であるほどよいです。(85文字以下でなければなりません。)
|
||||
* **title_jp** [オプション]: 日本語のタイトルです。
|
||||
* details [オプション]: 表示されるアラートの詳細です。Windowsイベントログの中で解析に有効なフィールドがあれば出力してください。フィールドは `" : "` で区切られます（両側ともスペース2つ）。フィールドのプレースホルダは `%` で囲まれ (例: `%MemberName%`) 、`config_eventkey_alias.txt` で定義する必要があります。(以下で説明します)
|
||||
* **details_jp** [オプション]: 日本語の出力メッセージ。
|
||||
* **description** [オプション]: ルールの説明。これは表示されないので、長く詳細に記述することができます。
|
||||
* **description_jp** [オプション]: 日本語の説明文です。
|
||||
|
||||
### AND条件とOR条件の書き方
|
||||
AND条件を記載する場合はYAMLのハッシュを用いて記載します。
|
||||
下記のようにdetectionを記載すると、以下`両方の条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
> ## ルールセクション
|
||||
* **id [必須]**: ルールを一意に識別するために使用される、ランダムに生成されたバージョン4のUUIDです。 [ここ](https://www.uuidgenerator.net/version4) で生成することができます。
|
||||
* **level [必須]**: [sigmaルールの定義](https://github.com/SigmaHQ/sigma/wiki/Specification)に基づく重要度レベル。 以下のいずれかを記述してください。 `informational`,`low`,`medium`,`high`,`critical`
|
||||
* **status[必須]**: テスト済みのルールには `stable` を、テストが必要なルールには `testing` を指定します。
|
||||
* **detection [必須]**: 検知ロジックはここに入ります。(以下で説明します。)
|
||||
* **falsepositives [必須]**: 誤検知の可能性について記載を行います。例: `system administrator`, `normal user usage`, `normal system usage`, `legacy application`, `security team`, `none`。 不明な場合は `unknown` と記述してください。
|
||||
* **tags** [オプション]: もしその技術が[LOLBINS/LOLBAS](https://lolbas-project.github.io/)の技術であれば、`lolbas` タグを追加してください。アラートを[MITRE ATT&CK](https://attack.mitre.org/) フレームワークにマッピングできる場合は、戦術ID（例：`attack.t1098`）や以下に該当する戦術を追加してください。
|
||||
* `attack.impact` -> Impact
|
||||
* `attack.initial_access` -> Initial Access
|
||||
* `attack.execution` -> Execution
|
||||
* `attack.lateral_movement` -> Lateral Movement
|
||||
* `attack.persistence` -> Persistence
|
||||
* `attack.privilege_escalation` -> Privilege Escalation
|
||||
* `attack.reconnaissance` -> Reconnaissance
|
||||
* `attack.collection` -> Collection
|
||||
* `attack.command_and_control` -> Command and Control
|
||||
* `attack.credential_access` -> Credential Access
|
||||
* `attack.defense_evasion` -> Defense Evasion
|
||||
* `attack.discovery` -> Discovery
|
||||
* `attack.exfiltration` -> Exfiltration
|
||||
* `attack.resource_development` -> Resource Development
|
||||
* **references** [オプション]: 参考文献への任意のリンク。
|
||||
* **sample-evtx [必須]**: このルールが検知するイベントログファイルへのファイルパスまたはURL。
|
||||
* **logsource [必須]**: ログの出所。以下のいずれかを指定してください。
|
||||
* `default`: Windowsでデフォルトで有効になっているログの場合等
|
||||
* `non-default`: グループポリシーやセキュリティベースラインなどで有効にする必要があるログ用。
|
||||
* `sysmon`: sysmonのインストールが必要なログ。
|
||||
* **non-default-setting** [オプション]: `non-default` のログソースのログ設定をオンにする方法の説明です。
|
||||
* **ruletype [必須]**: Hayabusaルールには `Hayabusa` を指定します。SigmaのWindowsルールから自動変換されたルールは `Sigma` になります。
|
||||
|
||||
``````
|
||||
# 検知フィールド
|
||||
## 検知の基礎知識
|
||||
まず、検知の作り方の基本を説明します。
|
||||
|
||||
|
||||
### AND論理とOR論理の書き方
|
||||
ANDロジックを書くには、ネストされた辞書を使用します。
|
||||
以下の検知ルールでは、ルールがマッチするためには、**両方の条件**が真でなければならないと定義しています。
|
||||
|
||||
* イベントIDは `7040` であること。
|
||||
* チャンネルは `System` であること。
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID: 7040
|
||||
Event.System.Channel: System
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
OR条件を記載する場合は配列を利用します。
|
||||
下記のようにdetectionを記載すると、以下`いずれの条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
OR論理を記述するには、リスト（`- `で始まる辞書）を使用します。
|
||||
以下の検知ルールでは、**片方**の条件がトリガーされることになります。
|
||||
|
||||
``````
|
||||
* イベントIDは `7040` であること。
|
||||
|
||||
**または**
|
||||
* チャンネルは `System` であること。
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
- Event.System.EventID: 7040
|
||||
- Event.System.Channel: System
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
また、下記のように記載することもできます。
|
||||
この場合、以下`両方の条件を満たす`イベントログを検知します。
|
||||
* EventIDが`7040`又は`7041`に完全一致する
|
||||
* Channelが`System`に完全一致する
|
||||
また、以下のように「AND」と「OR」の論理を組み合わせることも可能です。
|
||||
この場合、以下の2つの条件が両方成立したときにルールがマッチします。
|
||||
|
||||
``````
|
||||
* イベントID が `7040` **または** `7041` のどちらかであること。
|
||||
* チャンネルが `System` であること。
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Event.System.EventID:
|
||||
- 7040
|
||||
- 7041
|
||||
Event.System.Channel: System
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
### eventkey
|
||||
WindowsイベントログをXML形式で一部抜粋で出力すると、下記のようになります。ルールファイルの例に含まれる`Event.System.Channel`は、XMLの`<Event><System><Channel>System<Channel><System></Event>`を指しています。今回の例のように、XML形式のWindowsイベントログについて、入れ子になったXMLのタグに含まれる値をルールの条件に指定する場合、`.`でつなげて指定します。ルールファイルでは、この`.`でつなげた文字列をeventkeyと呼んでいます。
|
||||
### イベントキー
|
||||
以下は、Windowsイベントログの抜粋で、オリジナルのXMLでフォーマットしたものです。上記のルールファイルの例の `Event.System.Channel` フィールドは、オリジナルのXMLタグを参照しています。
|
||||
|
||||
``````
|
||||
`<Event><System><Channel>System<Channel><System></Event>`
|
||||
|
||||
ネストされたXMLタグはドット(`.`)で区切られたタグ名で置き換えられます。Hayabusaのルールでは、ドットでつながれたこれらのフィールド文字列は `eventkeys` と呼ばれます。
|
||||
|
||||
```xml
|
||||
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
|
||||
<System>
|
||||
<EventID>7040</EventID>
|
||||
@@ -86,24 +153,29 @@ WindowsイベントログをXML形式で一部抜粋で出力すると、下記
|
||||
</System>
|
||||
<EventData>
|
||||
<Data Name='param1'>Background Intelligent Transfer Service</Data>
|
||||
<Data Name='param2'>自動的な開始</Data>
|
||||
<Data Name='param2'>auto start</Data>
|
||||
</EventData>
|
||||
</Event>
|
||||
``````
|
||||
```
|
||||
|
||||
### eventkeyのalias
|
||||
`.`でつなげたeventkeyは長い文字列になってしまうことがあるため、hayabusaではeventkeyに対するエイリアスを使用できます。エイリアスは`config\eventkey_alias.txt`というファイルに定義されています。ファイルはCSV形式であり、aliasとevent_keyという列から構成されています。aliasにはエイリアスを定義し、event_keyには`.`でつなげたeventkeyを指定します。このエイリアスを用いると、最初に例に挙げたdetectionは以下のように書き換えることができます。
|
||||
#### イベントキーエイリアス
|
||||
`.`の区切りが多くて長いイベントキーが一般的であるため、Hayabusaはエイリアスを使って簡単に扱えるようにします。エイリアスは `config\eventkey_alias.txt`ファイルで定義されています。このファイルは `alias` と `event_key` のマッピングで構成される CSV ファイルです。以下に示すように、エイリアスを使用して上記のルールを書き直し、ルールを読みやすくすることができます。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
``````
|
||||
### XMLの属性(attribute)をルールの条件にする方法
|
||||
WindowsEventログをXML形式で出力すると、XMLの属性に値が設定されている場合もあります。下記の例だと、ProviderタグのNameがXMLの属性です。
|
||||
EventID: 7040
|
||||
condition: selection
|
||||
```
|
||||
|
||||
````````````
|
||||
#### 注意: 未定義のイベントキーエイリアスについて
|
||||
すべてのイベントキーエイリアスが `config\eventkey_alias.txt`で定義されているわけではありません。`details`（アラートの詳細）メッセージで正しいデータを取得しておらず、代わりに`%EventID%`のような結果を取得している場合、または検知ロジックの選択が正しく機能していない場合は、新しいエイリアスを使用して `config\eventkey_alias.txt`を更新する必要があります。
|
||||
|
||||
### 条件における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}'/>
|
||||
@@ -113,21 +185,36 @@ WindowsEventログをXML形式で出力すると、XMLの属性に値が設定
|
||||
<Security />
|
||||
</System>
|
||||
</Event>
|
||||
````````````
|
||||
```
|
||||
イベントキーのXML属性を指定するには、`{eventkey}_attributes.{attribute_name}`という形式を使います。例えば、ルールファイルの `Provider` 要素の `Name` 属性を指定する場合は、以下のようになります。
|
||||
|
||||
XMLの属性をeventkeyで指定するには、{eventkey}_attributes.{attribute_name}という形式で指定します。例えば、ProviderタグのName属性をルールファイルに指定する場合、下記のようになります。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4672
|
||||
Event.System.Provider_attributes.Name: 'Microsoft-Windows-Security-Auditing'
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
### EventData
|
||||
WindowsEventログをXML形式で出力すると、EventDataというタグが使用されている場合があります。(EventDataタグは様々なEventIDのログで頻繁に利用されます。)このEventDataにネストされたタグの名前は全て`Data`となっており、ここまで説明してきたeventkeyではSubjectUserSidやSubjectUserNameを区別することができません。
|
||||
````````````
|
||||
### 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>
|
||||
@@ -138,27 +225,29 @@ WindowsEventログをXML形式で出力すると、EventDataというタグが
|
||||
</System>
|
||||
<EventData>
|
||||
<Data Name='SubjectUserSid'>S-1-1-11-1111111111-111111111-1111111111-1111</Data>
|
||||
<Data Name='SubjectUserName'>hayabusa</Data>
|
||||
<Data Name='SubjectDomainName'>DESKTOP-HAYABUSA</Data>
|
||||
<Data Name='SubjectUserName'>Hayabusa</Data>
|
||||
<Data Name='SubjectDomainName'>DESKTOP-Hayabusa</Data>
|
||||
<Data Name='SubjectLogonId'>0x11111111</Data>
|
||||
</EventData>
|
||||
</Event>
|
||||
````````````
|
||||
```
|
||||
|
||||
この問題に対応するため、eventkeyで`Data`の代わりに`Name`に指定されている値をeventkeyに指定できるようになっています。例えば、EventData内のSubjectUserNameとSubjectDomainNameをルールの条件とする場合、下記のように記載します。
|
||||
この問題に対処するために、`Data Name`で割り当てられた値を指定することができます。例えば、EventData に含まれる `SubjectUserName` と `SubjectDomainName` をルールの条件として利用したい場合、以下のように記述することが可能です。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
Event.EventData.SubjectUserName: hayabusa
|
||||
EventID: 7040
|
||||
Event.EventData.SubjectUserName: Hayabusa
|
||||
Event.EventData.SubjectDomainName: DESKTOP-HAYBUSA
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
### EventDataの特殊なパターン
|
||||
EventDataというタグにネストされたタグの中には、Name属性が存在しないタグもあります。
|
||||
``````
|
||||
### EventDataの異常なパターン
|
||||
`EventData` にネストされたいくつかのタグは `Name` 属性を持ちません。
|
||||
|
||||
```xml
|
||||
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
|
||||
<System>
|
||||
<EventID>5379</EventID>
|
||||
@@ -171,145 +260,345 @@ EventDataというタグにネストされたタグの中には、Name属性が
|
||||
<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属性の指定されてないタグのうち、いずれか一つでも一致するタグがあれば、条件に一致したものとして処理されます。
|
||||
``````
|
||||
上記のようなイベントログを検知するには、`EventData`という名前のイベントキーを指定します。この場合、`Name`属性を持たないネストされたタグのいずれかがマッチする限り、条件はマッチします。
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 5379
|
||||
EventData: None
|
||||
``````
|
||||
condition: selection
|
||||
```
|
||||
|
||||
## パイプ
|
||||
eventkeyにはパイプを指定することができます。ここまで説明した書き方では完全一致しか表現できませんでしたが、パイプを使うことでより柔軟な検知ルールを記載できるようになります。下記の例ではCommandLineの値が`yamato.*hayabusa`という正規表現にマッチする場合、条件に一致したものとして処理されます。
|
||||
パイプは、以下のようにイベントキーと組み合わせて、文字列のマッチングに使用することができます。これまで説明した条件はすべて完全一致ですが、パイプを使うことで、より柔軟な検知ルールを記述することができます。以下の例では、`EventData`の値が正規表現 `[\s\S]*EngineVersion=2.0[\s\S]*` にマッチする場合、条件にマッチすることになります。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine|re: yamato.*hayabusa
|
||||
``````
|
||||
Channel: Microsoft-Windows-PowerShell/Operational
|
||||
EventID: 400
|
||||
EventData|re: '[\s\S]*EngineVersion=2\.0[\s\S]*'
|
||||
condition: selection
|
||||
```
|
||||
|
||||
使用できるパイプの一覧です。なお、v1.0.0時点では、複数のパイプをつなげて使用することはできません。
|
||||
* startswith: 先頭一致
|
||||
* endswith: 後方一致
|
||||
* contains: 部分一致
|
||||
* re: 正規表現(正規表現の処理にはregexクレートを使用しています。正規表現の詳細記法についてはhttps://docs.rs/regex/1.5.4/regex/を参照してください。)
|
||||
パイプの後に指定できるものの一覧です。現時点では、Hayabusa は複数のパイプを連結することはサポートしていません。
|
||||
* startswith: 文字列を先頭からチェックします。
|
||||
* endswith: 文字列の末尾をチェックします。
|
||||
* contains: ある単語がデータ内に含まれているかどうかをチェックします。
|
||||
* re: 正規表現を使用します。(私たちは regex crate を使っているので、正しい正規表現の書き方については https://docs.rs/regex/1.5.4/regex/ のドキュメントを参照してください)。
|
||||
> 注意: 正規表現を使用するSigmaルールの中には、Rustが正規表現を使用する方法の違いにより、 検知に失敗するものがあります。
|
||||
|
||||
## ワイルドカード
|
||||
eventkeyに対応する値にはワイルドカードを指定することができます。下記の例ではCommandLineがhayabusaという文字列で始まっていれば、条件に一致したものとして処理されます。基本的にはsigmaルールのwildcardと同じ仕様になっています。
|
||||
イベントキーにワイルドカードを使用することができます。以下の例では、`ProcessCommandLine` が "malware" という文字列で始まる場合、このルールはマッチします。
|
||||
この仕様は、Sigmaルールのワイルドカードと基本的に同じです。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine: hayabusa*
|
||||
``````
|
||||
Channel: Security
|
||||
EventID: 4688
|
||||
ProcessCommandLine: malware*
|
||||
condition: selection
|
||||
```
|
||||
|
||||
使用できるワイルドカードの一覧です。
|
||||
* `*`: 任意の0文字以上の文字列にマッチします。(内部的には`.*`という正規表現に変換されます。)
|
||||
* `?`: 任意の1文字にマッチします。(内部的には`.`という正規表現に変換されます。)
|
||||
以下の2つのワイルドカードを使用することができます。
|
||||
* `*`: 0文字以上の任意の文字列にマッチします。(内部的には正規表現 `.*` に変換されます)。
|
||||
* `?`: 任意の1文字にマッチします。(内部的には正規表現 `. ` に変換されます)。
|
||||
|
||||
ワイルドカードを使用する場合、下記のルールに則って解釈されます。
|
||||
* ワイルドカード(`*`と`?`)をエスケープするにはバックスラッシュ(`/`)を使用します。
|
||||
* ワイルドカードの直前に文字としてのバックスラッシュ(`/`)を使用する場合、`\\*`又は`\\?`と記載してください。
|
||||
* バックスラッシュを単体で使う分にはエスケープ不要です。
|
||||
ワイルドカードのエスケープについて
|
||||
* ワイルドカード(`*` and `?`)は、バックスラッシュでエスケープできます: `\*` と `\?`.
|
||||
* もし、ワイルドカードの直前にバックスラッシュを使用したい場合は、 `\\*` または `\\?` と記述してください。
|
||||
* バックスラッシュを単独で使用する場合は、エスケープは必要ありません。
|
||||
|
||||
## eventkeyにネストできるキーワード
|
||||
eventkeyには特定のキーワードをネストさせることができます。下記の例ではCommandLineの値が`aa*bb`というワイルドカードにマッチした上で文字列長が10以上である場合、条件に一致したものと処理されます。
|
||||
## イベントキー内のキーワードのネスト
|
||||
イベントキーは、特定のキーワードでネストすることができます。
|
||||
以下の例では、以下の場合にルールがマッチします。
|
||||
* `ServiceName` が `malicious-service` であるか、または `./config/regex/regexes_suspicous_service.txt` にある正規表現を含んでいる場合。
|
||||
* `ImagePath` は1000文字以上であること。
|
||||
* `ImagePath` は `allowlist` にマッチするものが一つもありません。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
CommandLine:
|
||||
value: aa*bb
|
||||
min_length: 10
|
||||
``````
|
||||
EventID: 7045
|
||||
ServiceName:
|
||||
- value: malicious-service
|
||||
- regexes: ./config/regex/detectlist_suspicous_services.txt
|
||||
ImagePath:
|
||||
min_length: 1000
|
||||
allowlist: ./config/regex/allowlist_legitimate_services.txt
|
||||
condition: selection
|
||||
```
|
||||
|
||||
現状では下記のキーワードを指定できます。
|
||||
* value: 文字列による一致(ワイルドカードやパイプを指定することもできます)
|
||||
* min_length: 指定した文字数以上である場合、条件に一致したものとして処理されます。
|
||||
* regexes: 指定したファイルに記載された正規表現のリストにひとつでも一致すれば、`条件に一致した`ものとして処理されます。
|
||||
* allowlist: 指定したファイルに記載された正規表現のリストにひとつでも一致すれば、`条件に一致していない`ものとして処理されます。
|
||||
現在、指定できるキーワードは以下の通りです。
|
||||
* `value`: 文字列によるマッチング (ワイルドカードやパイプも指定可能)。
|
||||
* `min_length`: 指定された文字数以上の場合にマッチします。
|
||||
* `regexes`: このフィールドで指定したファイル内の正規表現のいずれかにマッチする場合にマッチします。
|
||||
* `allowlist`: このフィールドで指定したファイル内の正規表現のリストにマッチするものがある場合、ルールはスキップされます。
|
||||
|
||||
### regexesとallowlist
|
||||
hayabusaではregexesやallowlistを使用した組み込みのルールを用意しており、それらのルールはhayabusa/config/regex内にあるregexes_suspicous_service.txtとallowlist_legimate_serviceimage.txtを参照しています。これらのファイルを書き換えることで、参照する全てのルールの挙動を一度に変更することが可能です。
|
||||
### regexesとallowlistキーワード
|
||||
Hayabusaに`.\rules\hayabusa\default\alerts\System\7045_CreateOrModiftySystemProcess-WindowsService_MaliciousServiceInstalled.yml`のルールのために使う2つの正規表現ファイルが用意されています。
|
||||
* `./config/regex/detectlist_suspicous_services.txt`: 怪しいサービス名を検知するためのものです。
|
||||
* `./config/regex/allowlist_legitimate_services.txt`: 正規のサービスを許可するためのものです。
|
||||
|
||||
`regexes` と `allowlist` で定義されたファイルは、ルールファイル自体を変更することなく、それらを参照するすべてのルールの動作を変更するために編集することが可能です。
|
||||
|
||||
また、regexesやallowlistに指定するファイルは、ユーザーが独自に作成することも可能です。作成する場合、regexes_suspicous_service.txtとallowlist_legimate_serviceimage.txtを参考にしてください。
|
||||
また、自分で作成した異なる regexes と allowlist テキストファイルを使用することもできます。
|
||||
デフォルトの `./config/detectlist_suspicous_services.txt` と `./config/allowlist_legitimate_services.txt` を参考にして、独自のファイルを作成してください。
|
||||
|
||||
## condition
|
||||
これまでの記法を用いると、AND条件やOR条件を表現することができますが、ANDやOR等が複雑に入り組んだ条件を定義することは難しい場合があります。その場合、conditionというキーワードを使用することで、複雑な条件式を定義することができます。
|
||||
## condition (条件)
|
||||
上記で説明した表記法では、`AND`や`OR`の論理を表現することができますが、複雑な論理を定義しようとすると混乱してしまうでしょう。
|
||||
より複雑なルールを作りたい場合は、以下のように `condition` キーワードを使用します。
|
||||
|
||||
``````
|
||||
```yaml
|
||||
detection:
|
||||
SELECTION_1:
|
||||
EventID: 3
|
||||
SELECTION_2:
|
||||
Initiated: 'true'
|
||||
SELECTION_3:
|
||||
DestinationPort:
|
||||
- '4444'
|
||||
- '666'
|
||||
SELECTION_4:
|
||||
Image: '*\Program Files*'
|
||||
SELECTION_5:
|
||||
DestinationIp:
|
||||
- 10.*
|
||||
- 192.168.*
|
||||
- 172.16.*
|
||||
- 127.*
|
||||
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} の両方を必要とする。
|
||||
* `{expression1} or {expression2}`: {expression1} または {expression2} のどちらかを必要とする
|
||||
* `not {expression}`: {expression} の論理を反転させる
|
||||
* `( {expression} )`: {expression} の優先順位を設定する。数学と同じ優先順位の論理に従う。
|
||||
|
||||
上記の例では、 `SELECTION_1`、` SELECTION_2`などの選択名が使用されていますが、次の文字 `a-z A-Z 0-9 _`のみが含まれている限り、任意の名前を付けることができます。
|
||||
> ただし、可能な限り読みやすくするために、 `selection_1`、` selection_2`、 `filter_1`、` filter_2`などの標準的な規則を使用してください。
|
||||
|
||||
## notロジック
|
||||
多くのルールは誤検知を引き起こすので、検索するシグネチャーの選択と同時に、誤検知が無いようにフィルターの選択をすることはよくあります。
|
||||
|
||||
例えば
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4673
|
||||
filter:
|
||||
- ProcessName: C:\Windows\System32\net.exe
|
||||
- ProcessName: C:\Windows\System32\lsass.exe
|
||||
- ProcessName: C:\Windows\System32\audiodg.exe
|
||||
- ProcessName: C:\Windows\System32\svchost.exe
|
||||
- ProcessName: C:\Windows\System32\mmc.exe
|
||||
- ProcessName: C:\Windows\System32\net.exe
|
||||
- ProcessName: C:\Windows\explorer.exe
|
||||
- ProcessName: C:\Windows\System32\SettingSyncHost.exe
|
||||
- ProcessName: C:\Windows\System32\sdiagnhost.exe
|
||||
- ProcessName|startswith: C:\Program Files
|
||||
- SubjectUserName: LOCAL SERVICE
|
||||
condition: selection and not filter
|
||||
```
|
||||
|
||||
## aggregation condition (集計条件) (別名: カウントルール)
|
||||
### 基本事項
|
||||
上記の `condition` キーワードは `AND` や `OR` ロジックを実装しているだけでなく、イベントをカウントしたり、「aggregate(集約)」したりすることも可能です。
|
||||
この機能は「集計条件」と呼ばれ、条件をパイプでつないで指定をします。
|
||||
以下のパスワードスプレー攻撃の例では、5分以内に同じ送信元の`IpAddress`で5個以上の `TargetUserName`があるかどうかを判断するために条件式が使用されています。
|
||||
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
condition: selection | count(TargetUserName) by IpAddress > 5
|
||||
timeframe: 5m
|
||||
```
|
||||
|
||||
集計条件は以下の形式で定義することができます。
|
||||
* `count() {operator} {number}`: パイプの前の最初の条件にマッチするログイベントに対して、マッチしたログの数が `{operator}` と `{number}` で指定した条件式を満たす場合に条件がマッチします。
|
||||
|
||||
`{operator}` は以下のいずれかになります。
|
||||
* `==`: 指定された値と等しい場合、条件にマッチしたものとして扱われる。
|
||||
* `>=`: 指定された値以上であれば、条件にマッチしたものとして扱われる。
|
||||
* `>`: 指定された値以上であれば、条件にマッチしたものとして扱われる。
|
||||
* `<=`: 指定された値以下の場合、条件にマッチしたものとして扱われる。
|
||||
* `<`: 指定された値より小さい場合、条件にマッチしたものとして扱われる。
|
||||
|
||||
`{number}` は数値である必要があります。
|
||||
|
||||
`timeframe` は以下のように定義することができます。
|
||||
* `15s`: 15秒
|
||||
* `30m`: 30分
|
||||
* `12h`: 12時間
|
||||
* `7d`: 7日間
|
||||
* `3M`: 3ヶ月
|
||||
> `timeframe` は必須ではありませんが、パフォーマンスとメモリ効率のために、可能な限り定義することが強く推奨されます。
|
||||
|
||||
|
||||
### 集計条件として4パターン:
|
||||
1. count 引数または `by` キーワードを指定しない。例: `selection | count() > 10`
|
||||
> もし `selection` が時間枠内に10回以上マッチすれば、条件にマッチします。
|
||||
2. count 引数はないが、`by` キーワードはある。例: `selection | count() by IpAddress > 10`
|
||||
> `selection` は**同じ**`IpAddress` に対して10回以上 true になる必要があります。
|
||||
3. count 引数があるが、`by` キーワードがない場合。例: `selection | count(TargetUserName) > 10`
|
||||
> `selection` がマッチし、かつ `TargetUserName` が時間枠内で10回以上**異なる**場合であれば、条件にマッチします。
|
||||
4. count 引数と `by` キーワードの両方が存在する。例: `selection | count(TargetUserName) by IpAddress > 10`
|
||||
> **同じ**「日付」に対して、条件が一致するためには、10人以上の**異なる**「ユーザ」が存在する必要があります。
|
||||
|
||||
|
||||
### パターン1の例：
|
||||
これは最も基本的なパターンです：`count() {operator} {number}`. 以下のルールは、`selection`が3回以上発生した場合にマッチします。
|
||||
|
||||
|
||||
|
||||
### パターン2の例：
|
||||
`count() by {eventkey} {operator} {number}`： パイプの前の `condition` にマッチするログイベントは、**同じ**`{eventkey}`でグループ化されます。各グループ化において、マッチしたイベントの数が`{operator}`と`{number}`で指定した条件を満たした場合、条件にマッチすることになります。
|
||||
|
||||
|
||||
|
||||
### パターン3の例：
|
||||
`count({eventkey}) {operator} {number}`： 条件パイプの前に、条件にマッチする `{eventkey}` の**異なる**値がいくつログイベント内に存在するかを数えます。その数が`{operator}`と`{number}`で指定された条件式を満たす場合、条件を満たしたものとみなします。
|
||||
|
||||
|
||||
|
||||
### パターン4の例：
|
||||
`count({eventkey_1}) by {eventkey_2} {operator} {number}`： 条件パイプの前にある条件にマッチしたログを**同じ**`{eventkey_2}`でグループ化し、各グループに含まれる`{eventkey_1}`の**異なる**値の数をカウントしています。各グループでカウントされた値が`{operator}`と`{number}`で指定された条件式を満たした場合、条件にマッチすることになります。
|
||||
|
||||
|
||||
|
||||
### 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`が設定されていない場合はルールが無視される可能性があります。
|
||||
|
||||
2. **不要な場合は複数の `selection`と`filter`セクションを使用しないでください。**
|
||||
|
||||
### 悪い例：
|
||||
```yaml
|
||||
detection:
|
||||
detection:
|
||||
SELECTION_1:
|
||||
Channnel: Security
|
||||
SELECTION_2:
|
||||
EventID: 4625
|
||||
SELECTION_3:
|
||||
LogonType: 3
|
||||
FILTER_1:
|
||||
SubStatus: "0xc0000064"
|
||||
FILTER_2:
|
||||
SubStatus: "0xc000006a"
|
||||
condition: SELECTION_1 and SELECTION_2 and SELECTION_3 and not (FILTER_1 or FILTER_2)
|
||||
```
|
||||
|
||||
### 良い例：
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
Channel: Security
|
||||
EventID: 4625
|
||||
LogonType: 3
|
||||
filter:
|
||||
- SubStatus: "0xc0000064" #Non-existent user
|
||||
- SubStatus: "0xc000006a" #Wrong password
|
||||
condition: selection and not filter
|
||||
```
|
||||
|
||||
3. **複数のセクションが必要な場合は、チャンネル名とイベントIDの情報を記入する最初のセクションを `section_basic_info` セクションに、その他のセクションを `section_` と `filter_` の後に意味のある名前を付けるか、または `section_1`, `filter_1` などの記法を用いてください。また、分かりにくいところはコメントを書いて説明してください。**
|
||||
|
||||
### 悪い例：
|
||||
```yaml
|
||||
detection:
|
||||
Takoyaki:
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
Naruto:
|
||||
TargetUserName|endswith: "$"
|
||||
IpAddress: "-"
|
||||
Sushi:
|
||||
SubjectUserName|endswith: "$"
|
||||
TargetUserName|endswith: "$"
|
||||
TargetInfo|endswith: "$"
|
||||
Godzilla:
|
||||
SubjectUserName|endswith: "$"
|
||||
Ninja:
|
||||
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$"
|
||||
IpAddress: "-"
|
||||
Daisuki:
|
||||
- ProcessName|endswith: "powershell.exe"
|
||||
- ProcessName|endswith: "WMIC.exe"
|
||||
condition: Takoyaki and Daisuki and not (Naruto and not Godzilla) and not Ninja and not Sushi
|
||||
```
|
||||
|
||||
### OKな例：
|
||||
```yaml
|
||||
detection:
|
||||
selection_1:
|
||||
EventID: 7040
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
selection_2:
|
||||
EventID: 7041
|
||||
selection_3:
|
||||
Channel: System
|
||||
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:
|
||||
CommandLine|contains: lsass.exe
|
||||
selection_5:
|
||||
CommandLine|contains: services.exe
|
||||
selection_6:
|
||||
ParentProcessName|contains: wininit.exe
|
||||
- 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
|
||||
```
|
||||
|
||||
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毎に判定する条件式になります。
|
||||
|
||||
``````
|
||||
### 良い例：
|
||||
```yaml
|
||||
detection:
|
||||
selection:
|
||||
EventID: 7040
|
||||
Channel: System
|
||||
condition: selection | count(DestinationIp) by SubjectUserName >= 3
|
||||
``````
|
||||
selection_basic_info:
|
||||
Channel: Security
|
||||
EventID: 4648
|
||||
selection_TargetUserIsComputerAccount:
|
||||
TargetUserName|endswith: "$"
|
||||
IpAddress: "-"
|
||||
filter_UsersAndTargetServerAreComputerAccounts: #Filter system noise
|
||||
SubjectUserName|endswith: "$"
|
||||
TargetUserName|endswith: "$"
|
||||
TargetInfo|endswith: "$"
|
||||
filter_SubjectUserIsComputerAccount:
|
||||
SubjectUserName|endswith: "$"
|
||||
filter_SystemAccounts:
|
||||
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_SuspiciousProcess:
|
||||
- ProcessName|endswith: "powershell.exe"
|
||||
- ProcessName|endswith: "WMIC.exe"
|
||||
condition: selection_basic and selection_SuspiciousProcess and not (selection_TargetUserIsComputerAccount
|
||||
and not filter_SubjectUserIsComputerAccount) and not filter_SystemAccounts and not filter_UsersAndTargetServerAreComputerAccounts
|
||||
```
|
||||
|
||||
aggregation conditionは下記の形式で定義できます。なお、{number}には数値を指定します。
|
||||
* `count() {operator} {number}`: conditionのパイプ以前の条件に一致したログについて、一致したログ数が{operator}と{number}で指定した条件式を満たす場合に、条件に一致したものとして処理されます。
|
||||
# SigmaルールからHayabusaルール形式への自動変換
|
||||
SigmaルールからHayabusaルール形式への自動変換を行うsigmacのバックエンドを[こちら](https://github.com/Yamato-Security/hayabusa/tree/main/tools/sigmac)で作成しました。
|
||||
|
||||
|
||||
|
||||
* `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%'
|
||||
``````
|
||||
使い方のReadmeは[こちら](https://github.com/Yamato-Security/hayabusa/blob/main/tools/sigmac/README-Japanese.md)です。
|
||||
BIN
doc/CountRulePattern-1-EN.png
Normal file
BIN
doc/CountRulePattern-1-EN.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 150 KiB |
BIN
doc/CountRulePattern-1-JP.png
Normal file
BIN
doc/CountRulePattern-1-JP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 150 KiB |
BIN
doc/CountRulePattern-2-EN.png
Normal file
BIN
doc/CountRulePattern-2-EN.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
BIN
doc/CountRulePattern-2-JP.png
Normal file
BIN
doc/CountRulePattern-2-JP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
BIN
doc/CountRulePattern-3-EN.png
Normal file
BIN
doc/CountRulePattern-3-EN.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 194 KiB |
BIN
doc/CountRulePattern-3-JP.png
Normal file
BIN
doc/CountRulePattern-3-JP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
BIN
doc/CountRulePattern-4-EN.png
Normal file
BIN
doc/CountRulePattern-4-EN.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 176 KiB |
BIN
doc/CountRulePattern-4-JP.png
Normal file
BIN
doc/CountRulePattern-4-JP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
BIN
doc/count1.png
BIN
doc/count1.png
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 123 KiB |
BIN
doc/count2.png
BIN
doc/count2.png
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 158 KiB |
BIN
doc/count3.png
BIN
doc/count3.png
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 130 KiB |
BIN
doc/count4.png
BIN
doc/count4.png
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 141 KiB |
BIN
screenshots/ExcelScreenshot.png
Normal file
BIN
screenshots/ExcelScreenshot.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 379 KiB |
BIN
screenshots/Hayabusa-Startup.png
Normal file
BIN
screenshots/Hayabusa-Startup.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 121 KiB |
BIN
screenshots/HayabusaResultsSummary.png
Normal file
BIN
screenshots/HayabusaResultsSummary.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
BIN
screenshots/TimelineExplorer-ColoredTimeline.png
Normal file
BIN
screenshots/TimelineExplorer-ColoredTimeline.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 402 KiB |
BIN
screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png
Normal file
BIN
screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 81 KiB |
Reference in New Issue
Block a user