This commit is contained in:
Alan Smithee
2022-02-13 23:21:01 +09:00
11 changed files with 464 additions and 233 deletions

View File

@@ -7,53 +7,59 @@
</div>
# About Hayabusa
Hayabusa is a **Windows event log fast forensics timeline generator** and **threat hunting tool** created by the [Yamato Security](https://yamatosecurity.connpass.com/) group in Japan. Hayabusa means ["peregrine falcon"](https://en.wikipedia.org/wiki/Peregrine_falcon") in Japanese and was chosen as peregrine falcons are the fastest animal in the world, great at hunting and highly trainable. It is written in [Rust](https://www.rust-lang.org/) and supports multi-threading in order to be as fast as possible. We have provided a [tool](https://github.com/Yamato-Security/hayabusa/tree/main/tools/sigmac) to convert [sigma](https://github.com/SigmaHQ/sigma) rules into hayabusa rule format. The hayabusa detection rules, like sigma, are also written in YML in order to be as easily customizable and extensible as possible. It can be run either on running systems for live analysis or by gathering logs from multiple systems for offline analysis. (At the moment, it does not support real-time alerting or periodic scans.) The output will be consolidated into a single CSV timeline for easy analysis in Excel or [Timeline Explorer](https://ericzimmerman.github.io/#!index.md).
## Main goals
### 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 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 YML, 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
![Hayabusa Startup](/screenshots/Hayabusa-Startup.png)
## Terminal output:
## Terminal output
![Hayabusa terminal output](/screenshots/Hayabusa-Results.png)
## Results summary:
## Results summary
![Hayabusa results summary](/screenshots/HayabusaResultsSummary.png)
## Analysis in Excel:
## Analysis in Excel
![Hayabusa analysis in Excel](/screenshots/ExcelScreenshot.png)
## Analysis in Timeline Explorer:
## Analysis in Timeline Explorer
![Hayabusa analysis in Timeline Explorer](screenshots/TimelineExplorer-ColoredTimeline.png)
## Critical alert filtering and computer grouping in Timeline Explorer:
## Critical alert filtering and computer grouping in Timeline Explorer
![Critical alert filtering and computer grouping in Timeline Explorer](screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png)
# 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).
You can learn how to analyze CSV timelines in Excel and Timeline Explorer [here](doc/CSV-AnalysisWithExcelAndTimelineExplorer-English.pdf).
# Features
* Cross-platform support: Windows, Linux, macOS
* Developed in Rust to be memory safe and faster than a hayabusa falcon!
* Multi-thread support delivering up to a 5x speed improvement!
@@ -65,6 +71,7 @@ You can learn how to analyze CSV timelines in Excel and Timeline Explorer [here]
* Rule tuning configuration by excluding bad rules or noisy rules
# Planned Features
* Enterprise-wide hunting on all endpoints
* Japanese language support
* MITRE ATT&CK mapping
@@ -74,6 +81,7 @@ You can learn how to analyze CSV timelines in Excel and Timeline Explorer [here]
* JSON support for sending alerts to Elastic Stack/Splunk, etc...
# Downloads
You can download the latest Hayabusa version from the [Releases](https://github.com/Yamato-Security/hayabusa/releases) page.
You can also `git clone` the repository with the following command and compile binary from source code.:
@@ -96,6 +104,7 @@ git submodule update --init
```
# Compiling from source (Optional)
If you have rust installed, you can compile from source with the following command:
```bash
@@ -104,6 +113,7 @@ cargo build --release
```
## Advanced: Updating Rust packages
You can update to the latest rust crates before compiling to get the latest libraries:
```bash
@@ -113,9 +123,11 @@ cargo update
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
```
@@ -123,94 +135,144 @@ git clone https://github.com/Yamato-Security/hayabusa-sample-evtx.git
> Note: You need to run the binary from the Hayabusa root directory.
# Usage
> Note: You need to run the Hayabusa binary from the Hayabusa root directory. Example: `.\hayabusa.exe`
## Caution: Output printed to screen may stop in Windows Terminal
As of Feb 1, 2022, Windows Terminal will freeze midway when displaying results to the screen when run against the sample evtx files.
This is because there is a control code (0x9D) in the output.
This is known Windows Terminal bug which will eventually be fixed but for the meantime, you can avoid this bug by adding the `-c` (colored output) option when you run hayabusa.
## 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'
-u --update-rules 'Clone latest hayabusa-rule'
-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'
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files.'
-f --filepath=[FILEPATH] 'File path to one .evtx file.'
-r --rules=[RULEDIRECTORY/RULEFILE] 'Rule file or directory (default: ./rules)'
-c --color 'Output with color. (Terminal needs to support True Color.)'
-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'
--contributors 'Prints the list of contributors.'
FLAGS:
-c, --color Output with color. (Terminal needs to support True Color.)
--contributors Prints the list of contributors.
-D, --enable-deprecated-rules Enable sigma rules marked as deprecated.
-n, --enable-noisy-rules Enable rules marked as noisy.
-h, --help Prints help information
-q, --quiet Quiet mode. Do not display the launch banner.
-Q, --quiet-errors Quiet errors mode. Do not save error logs.
--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)
-s, --statistics Prints statistics of event IDs.
-u, --utc Output time in UTC format. (default: local time)
-V, --version Prints version information
-v, --verbose Output verbose information.
OPTIONS:
-d, --directory <DIRECTORY> Directory of multiple .evtx files.
--end-timeline <ENDTIMELINE> End time of the event to load from event file. (example: '2018/11/28
12:00:00 +09:00')
-f, --filepath <FILEPATH> File path to one .evtx file.
-m, --min-level <LEVEL> Minimum level for rules. (default: informational)
-o, --output <CSV_TIMELINE> Save the timeline in CSV format. (example: results.csv)
-r, --rules <RULEDIRECTORY/RULEFILE> Rule file or directory (default: ./rules)
--start-timeline <STARTTIMELINE> Start time of the event to load from event file. (example: '2018/11/28
12:00:00 +09:00')
-t, --thread-number <NUMBER> Thread number. (default: optimal number for performance.)
```
## 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
@@ -229,6 +291,7 @@ 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.
@@ -239,18 +302,24 @@ When Hayabusa output is being displayed to the screen (the default), it will dis
* `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.
It will display in real time the number and percent of evtx files that it has finished analyzing.
## Color Output
Hayabusa output to the screen can change font color by `Level`.
Config file is `.\config\level_color.txt`. format is `level,(RGB 6digit ColorHex)`.
You can output the alerts in color based on the alert `level` by specifying `-c` or `--color`.
You can change the default colors in the config file at `.\config\level_color.txt` in the format of `level,(RGB 6-digit ColorHex)`.
Note: Color can only be displayed in terminals that support [True Color](https://en.wikipedia.org/wiki/Color_depth#True_color_(24-bit)).
Example: [Windows Terminal](https://docs.microsoft.com/en-us/windows/terminal/install) or [iTerm2](https://iterm2.com/) for macOS.
# 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.
@@ -259,32 +328,38 @@ All of the rules from the hayabusa-rules repository should be placed in the `rul
`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 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
* `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
Rules are further seperated into directories by log type (Example: Security, System, etc...) and are named in the following format:
* Alert format: `<EventID>_<MITRE ATT&CK Name>_<Description>.yml`
* Alert example: `1102_IndicatorRemovalOnHost-ClearWindowsEventLogs_SecurityLogCleared.yml`
* Event format: `<EventID>_<Description>.yml`
* Event example: `4776_NTLM-LogonToLocalAccount.yml`
* Alert format: `<EventID>_<MITRE ATT&CK Name>_<Description>.yml`
* Alert example: `1102_IndicatorRemovalOnHost-ClearWindowsEventLogs_SecurityLogCleared.yml`
* Event format: `<EventID>_<Description>.yml`
* Event example: `4776_NTLM-LogonToLocalAccount.yml`
Please check out the current rules to use as a template in creating new ones or for checking the detection logic.
## 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 `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).
**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. 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 that you do not need or cannot be used.
@@ -292,6 +367,7 @@ You can add a rule ID (Example: `4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6`) to `conf
You can also add a rule ID to `config/noisy-rules.txt` in order to ignore the rule by default but still be able to use the rule with the `-n` or `--enable-noisy-rules` option.
## Event ID filtering
You can 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.
@@ -300,37 +376,41 @@ We have provided a sample ID filter list at [`config/target_eventids_sample.txt`
Please use this list if you want the best performance but be aware that there is a slight possibility for missing events (false negatives).
# 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 by [Eric Conrad](https://twitter.com/eric_conrad).
- [EventList](https://github.com/miriamxyra/EventList/) - Map security baseline event IDs to MITRE ATT&CK by [Miriam Wiesner](https://github.com/miriamxyra)
- [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 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.
- [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA) - The swiff-army knife for Windows event logs by [Yamato Security](https://github.com/Yamato-Security/)
- [Zircolite](https://github.com/wagga40/Zircolite) - Sigma-based attack detection tool written in Python.
* [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Attack detection tool written in Python.
* [Awesome Event IDs](https://github.com/stuhli/awesome-event-ids) - Collection of Event ID resources useful for Digital Forensics and Incident Response
* [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).
* [EventList](https://github.com/miriamxyra/EventList/) - Map security baseline event IDs to MITRE ATT&CK by [Miriam Wiesner](https://github.com/miriamxyra).
* [EvtxECmd](https://github.com/EricZimmerman/evtx) - Evtx parser by [Eric Zimmerman](https://twitter.com/ericrzimmerman).
* [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 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.
* [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA) - The swiff-army knife for Windows event logs by [Yamato Security](https://github.com/Yamato-Security/)
* [Zircolite](https://github.com/wagga40/Zircolite) - Sigma-based attack detection tool written in Python.
## Comparison to other similar tools that support sigma
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 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 |
| | 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.
@@ -338,15 +418,15 @@ The following benchmarks were taken on a Lenovo P51 based on approximately 500 e
# Community Documentation
## English
## English
- 2022/01/24 [Graphing Hayabusa results in neo4j](https://www.youtube.com/watch?v=7sQqz2ek-ko) by Matthew Seyer ([@forensic_matt](https://twitter.com/forensic_matt))
* 2022/01/24 [Graphing Hayabusa results in neo4j](https://www.youtube.com/watch?v=7sQqz2ek-ko) by Matthew Seyer ([@forensic_matt](https://twitter.com/forensic_matt))
## Japanese
- 2022/01/22 [Visualizing Hayabusa results in Elastic Stack](https://qiita.com/kzzzzo2/items/ead8ccc77b7609143749) by [@kzzzzo2](https://qiita.com/kzzzzo2)
- 2021/12/31 [Intro to Hayabusa](https://itib.hatenablog.com/entry/2021/12/31/222946) by itiB ([@itiB_S144](https://twitter.com/itiB_S144))
- 2021/12/27 [Hayabusa internals](https://kazuminkun.hatenablog.com/entry/2021/12/27/190535) by Kazuminn ([@k47_um1n](https://twitter.com/k47_um1n))
* 2022/01/22 [Visualizing Hayabusa results in Elastic Stack](https://qiita.com/kzzzzo2/items/ead8ccc77b7609143749) by [@kzzzzo2](https://qiita.com/kzzzzo2)
* 2021/12/31 [Intro to Hayabusa](https://itib.hatenablog.com/entry/2021/12/31/222946) by itiB ([@itiB_S144](https://twitter.com/itiB_S144))
* 2021/12/27 [Hayabusa internals](https://kazuminkun.hatenablog.com/entry/2021/12/27/190535) by Kazuminn ([@k47_um1n](https://twitter.com/k47_um1n))
# Contribution

View File

@@ -7,14 +7,17 @@
</div>
# Hayabusa について
Hayabusaは、日本の[Yamato Security](https://yamatosecurity.connpass.com/)グループによって作られた**Windowsイベントログのファストフォレンジックタイムライン生成**および**スレットハンティングツール**です。 Hayabusaは日本語で[「ハヤブサ」](https://en.wikipedia.org/wiki/Peregrine_falcon)を意味し、ハヤブサが世界で最も速く、狩猟(hunting)に優れ、とても訓練しやすい動物であることから選ばれました。[Rust](https://www.rust-lang.org/) で開発され、マルチスレッドに対応し、可能な限り高速に動作するよう配慮されています。[Sigma](https://github.com/SigmaHQ/Sigma)ルールをHayabusaルール形式に変換する[ツール](https://github.com/Yamato-Security/hayabusa/tree/main/tools/Sigmac)も提供しています。Hayabusaの検知ルールもSigmaと同様にYML形式であり、カスタマイズ性や拡張性に優れます。稼働中のシステムで実行してライブ調査することも、複数のシステムからログを収集してオフライン調査することも可能です。(※現時点では、リアルタイムアラートや定期的なスキャンには対応していません。) 出力は一つのCSVタイムラインにまとめられ、Excelや[Timeline Explorer](https://ericzimmerman.github.io/#!index.md)で簡単に分析できるようになります。
## 主な目的
### スレット(脅威)ハンティング
Hayabusa には現在、1000以上のSigmaルールと約50のHayabusa検知ルールがあり、定期的にルールが追加されています。 最終的な目標はインシデントレスポンスや定期的なスレットハンティングのために、HayabusaエージェントをすべてのWindows端末にインストールして、中央サーバーにアラートを返す仕組みを作ることです。
### フォレンジックタイムラインの高速生成
Windowsのイベントログは、
1解析が困難なデータ形式であること
2データの大半がイズであり調査に有用でないこと
@@ -22,9 +25,11 @@ 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ルール形式へ変換するツールも作成しました。
# スクリーンショット
## 起動画面:
![Hayabusa 起動画面](/screenshots/Hayabusa-Startup.png)
@@ -50,11 +55,13 @@ Windowsのイベントログは、
![Timeline ExplorerでCriticalアラートのフィルタリングとコンピュータグルーピング](screenshots/TimelineExplorer-CriticalAlerts-ComputerGrouping.png)
# タイムラインのサンプル結果
CSVと手動で編集したXLSXのタイムライン結果のサンプルは[こちら](https://github.com/Yamato-Security/hayabusa/tree/main/sample-results)で確認できます。
CSVのタイムラインをExcelやTimeline Explorerで分析する方法は[こちら](doc/CSV-AnalysisWithExcelAndTimelineExplorer-Japanese.pdf)で紹介しています。
# 特徴
* クロスプラットフォーム対応: Windows, Linux, macOS
* Rustで開発され、メモリセーフでハヤブサよりも高速です
* マルチスレッド対応により、最大5倍のスピードアップを実現!
@@ -66,6 +73,7 @@ CSVのタイムラインをExcelやTimeline Explorerで分析する方法は[こ
* 不良ルールやノイズの多いルールを除外するルールチューニング設定が可能です。
# 予定されている機能
* すべてのエンドポイントでの企業全体のスレットハンティング
* 日本語対応
* MITRE ATT&CK とのマッピング
@@ -75,6 +83,7 @@ CSVのタイムラインをExcelやTimeline Explorerで分析する方法は[こ
* JSONへの出力→Elastic Stack/Splunkへのインポート
# ダウンロード
Hayabusaの[Releases](https://github.com/Yamato-Security/hayabusa/releases)から最新版をダウンロードできます。
または、以下の`git clone`コマンドでレポジトリをダウンロードし、ソースコードからコンパイルして使用することも可能です。
@@ -90,6 +99,7 @@ Hayabusaでは検知ルールを`rules/`フォルダの取得はコンパイル
```
# ソースコードからのコンパイル(任意)
rustがインストールされている場合、以下のコマンドでソースコードからコンパイルすることができます:
```bash
@@ -98,6 +108,7 @@ cargo build --release
```
## アドバンス: Rustパッケージの更新
コンパイル前に最新のRust crateにアップデートすることで、最新のライブラリを利用することができます:
```bash
@@ -107,9 +118,11 @@ cargo update
※ アップデート後、何か不具合がありましたらお知らせください。
## サンプル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
```
@@ -117,94 +130,144 @@ git clone https://github.com/Yamato-Security/hayabusa-sample-evtx.git
> ※ 以下の例でHayabusaを試したい方は、上記コマンドをhayabusaのルートフォルダから実行してください。
# 使用方法
> 注意: Hayabusaのルートディレクトリから、バイナリを実行する必要があります。例`.\hayabusa.exe`
## Windows Terminalで利用する際の注意事項
2021/02/01現在、Windows Terminalから標準出力でhayabusaを使ったときに、コントロールコード(0x9D等)が検知結果に入っていると出力が止まることが確認されています。
Windows Terminalからhayabusaを標準出力で解析させたい場合は、 `-c` (カラー出力)のオプションをつければ出力が止まることを回避できます。
## コマンドラインオプション
```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'
-u --update-rules 'Clone latest hayabusa-rule'
-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'
-d --directory=[DIRECTORY] 'Directory of multiple .evtx files.'
-f --filepath=[FILEPATH] 'File path to one .evtx file.'
-r --rules=[RULEDIRECTORY/RULEFILE] 'Rule file or directory (default: ./rules)'
-c --color 'Output with color. (Terminal needs to support True Color.)'
-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'
--contributors 'Prints the list of contributors.'
FLAGS:
-c, --color Output with color. (Terminal needs to support True Color.)
--contributors Prints the list of contributors.
-D, --enable-deprecated-rules Enable sigma rules marked as deprecated.
-n, --enable-noisy-rules Enable rules marked as noisy.
-h, --help Prints help information
-q, --quiet Quiet mode. Do not display the launch banner.
-Q, --quiet-errors Quiet errors mode. Do not save error logs.
--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)
-s, --statistics Prints statistics of event IDs.
-u, --utc Output time in UTC format. (default: local time)
-V, --version Prints version information
-v, --verbose Output verbose information.
OPTIONS:
-d, --directory <DIRECTORY> Directory of multiple .evtx files.
--end-timeline <ENDTIMELINE> End time of the event to load from event file. (example: '2018/11/28
12:00:00 +09:00')
-f, --filepath <FILEPATH> File path to one .evtx file.
-m, --min-level <LEVEL> Minimum level for rules. (default: informational)
-o, --output <CSV_TIMELINE> Save the timeline in CSV format. (example: results.csv)
-r, --rules <RULEDIRECTORY/RULEFILE> Rule file or directory (default: ./rules)
--start-timeline <STARTTIMELINE> Start time of the event to load from event file. (example: '2018/11/28
12:00:00 +09:00')
-t, --thread-number <NUMBER> Thread number. (default: optimal number for performance.)
```
## 使用例
* 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
@@ -223,6 +286,7 @@ Checking target evtx FilePath: "./hayabusa-sample-evtx/YamatoSecurity/T1218.004_
エラーメッセージを保存したくない場合は、`-Q`を追加してください。
# Hayabusaの出力
Hayabusaの結果を標準出力に表示しているときデフォルトは、以下の情報を表示します:
* `Timestamp`: デフォルトでは`YYYY-MM-DD HH:mm:ss.sss +hh:mm`形式になっています。イベントログの`<Event><System><TimeCreated SystemTime>`フィールドから来ています。デフォルトのタイムゾーンはローカルのタイムゾーンになりますが、`--utc` オプションで UTC に変更することができます。
@@ -233,19 +297,25 @@ Hayabusaの結果を標準出力に表示しているときデフォルト
* `Details`: YML検知ルールの`details`フィールドから来ていますが、このフィールドはHayabusaルールにしかありません。このフィールドはアラートとイベントに関する追加情報を提供し、ログの`<Event><System><EventData>`部分から有用なデータを抽出することができます。
CSVファイルとして保存する場合、以下の2つのフィールドが追加されます:
* `Rule Path`: アラートまたはイベントを生成した検知ルールへのパス。
* `File Path`: アラートまたはイベントを起こしたevtxファイルへのパス。
## プログレスバー
プログレス・バーは、複数のevtxファイルに対してのみ機能します。
解析したevtxファイルの数と割合をリアルタイムで表示します。
## 標準出力へのカラー設定
Hayabusaの結果はLevel毎に文字色を変えることができます。
`-c`または`--color`を指定することで、Hayabusaの結果は`level`毎に文字色を変えることができます。
`.\config\level_color.txt`の値を変更することで文字色を変えることができます。
形式は`level名,(6桁のRGBのカラーhex)`です。
注意: True Colorに対応しているターミナルが必要です。
例: [Windows Terminal](https://docs.microsoft.com/en-us/windows/terminal/install) またはmacOSの[iTerm2](https://iterm2.com/)。
# Hayabusa ルール
Hayabusa検知ルールはSigmaのようなYML形式で記述されています。`rules`ディレクトリに入っていますが、将来的には[https://github.com/Yamato-Security/hayabusa-rules](https://github.com/Yamato-Security/hayabusa-rules)のレポジトリで管理する予定なので、ルールのissueとpull requestはhayabusaのレポジトリではなく、ルールレポジトリへお願いします。
ルールの作成方法については、[AboutRuleCreation-Japanese.md](./doc/AboutRuleCreation-Japanese.md) をお読みください。
@@ -255,32 +325,38 @@ Hayabusa検知ルールはSigmaのようなYML形式で記述されています
`level`がinformationのルールは `events` とみなされ、`low` 以上は `alerts` とみなされます。
Hayabusaルールのディレクトリ構造は、3つのディレクトリに分かれています。
* `default`: Windows OSでデフォルトで記録されるログ
* `non-default`: グループポリシーやセキュリティベースラインの適用でオンにする必要があるログ
* `sysmon`: [sysmon](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon)によって生成されるログ
* `testing`: 現在テストしているルールを配置するための一時ディレクトリ
* `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`
* アラート形式: `<イベント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`に追加すると、不要なルールや利用できないルールを無視することができます。
@@ -288,6 +364,7 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
ルールIDを `config/noisy-rules.txt`に追加して、デフォルトでルールを無視することもできますが、` -n`または `--enable-noisy-rules`オプションを指定してルールを使用することもできます。
## イベントIDフィルタリング
`config/target_eventids.txt`にイベントID番号を追加することで、イベントIDでフィルタリングすることができます。
これはパフォーマンスを向上させるので、特定のIDだけを検索したい場合に推奨されます。
@@ -296,36 +373,41 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
最高のパフォーマンスを得たい場合はこのリストを使用してください。ただし、誤検出の可能性が若干あることにご注意ください。
# その他のWindowsイベントログ解析ツールおよび関連プロジェクト
「すべてを統治する1つのツール」というものはなく、それぞれにメリットがあるため、これらの他の優れたツールやプロジェクトをチェックして、どれが気に入ったかを確認することをお勧めします。
- [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Pythonで開発された攻撃検知ツール。
- [Chainsaw](https://github.com/countercept/chainsaw) - Rustで開発された同様のSigmaベースの攻撃検知ツール
- [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) - [Eric Conrad](https://twitter.com/eric_conrad) によってPowershellで開発された攻撃検知ツール。
- [EventList](https://github.com/miriamxyra/EventList/) - [Miriam Wiesner](https://github.com/miriamxyra)によるセキュリティベースラインの有効なイベントIDをMITRE ATT&CKにマッピングする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) による、横方向の動きを検知するためにログオンを視覚化するグラフィカルなインターフェース
- [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によるWindowsイベントログ解析の参考資料
- [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA/) - [Yamato Security](https://github.com/Yamato-Security/)によるWindowsイベントログ解析のマルチツール。
- [Zircolite](https://github.com/wagga40/Zircolite) - Pythonで書かれたSigmaベースの攻撃検知ツール
* [APT-Hunter](https://github.com/ahmedkhlief/APT-Hunter) - Pythonで開発された攻撃検知ツール。
* [Awesome Event IDs](https://github.com/stuhli/awesome-event-ids) - フォレンジック調査とインシデント対応に役立つイベントIDのリソース
* [Chainsaw](https://github.com/countercept/chainsaw) - Rustで開発された同様のSigmaベースの攻撃検知ツール。
* [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI) - [Eric Conrad](https://twitter.com/eric_conrad) によってPowershellで開発された攻撃検知ツール。
* [EventList](https://github.com/miriamxyra/EventList/) - [Miriam Wiesner](https://github.com/miriamxyra)によるセキュリティベースラインの有効なイベントIDをMITRE ATT&CKにマッピングするPowerShellツール。
* [EvtxECmd](https://github.com/EricZimmerman/evtx) - [Eric Zimmerman](https://twitter.com/ericrzimmerman)によるEvtxパーサー
* [EVTXtract](https://github.com/williballenthin/EVTXtract) - 未使用領域やメモリダンプからEVTXファイルを復元するツール
* [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) による、横方向の動きを検知するためにログオンを視覚化するグラフィカルなインターフェース
* [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によるWindowsイベントログ解析の参考資料。
* [WELA (Windows Event Log Analyzer)](https://github.com/Yamato-Security/WELA/) - [Yamato Security](https://github.com/Yamato-Security/)によるWindowsイベントログ解析のマルチツール。
* [Zircolite](https://github.com/wagga40/Zircolite) - Pythonで書かれたSigmaベースの攻撃検知ツール。
## Sigmaをサポートする他の類似ツールとの比較
対象となるサンプルデータ、コマンドラインオプション、ルールのチューニング等によって結果が異なるため、完全な比較はできませんが、ご了承ください。
我々のテストでは、Hayabusaはすべてのツールの中で最も多くのSigmaルールをサポートしながらも、非常に高速な速度を維持し、大量のメモリを必要としないことが分かっています。
以下のベンチマークは、2021/12/23に [sample-evtx repository](https://github.com/Yamato-Security/Hayabusa-sample-evtx) から約500個のevtxファイル130MBを基に、Lenovo P51で計測したものです。Hayabusa 1.0.0を使いました。
| | 経過時間 | メモリ使用量 | 利用可能のSigmaルール数 |
| :---: | :---: | :---: | :---: |
| Chainsaw | 7.5 seconds | 70 MB | 170 |
| Hayabusa | 7.8 seconds | 340 MB | 267 |
| Zircolite | 34 seconds | 380 MB (通常、ログファイルの3倍のサイズが必要) | 237 |
| | 経過時間 | メモリ使用量 | 利用可能の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ファイルのサイズではなく、結果のサイズによって増えます。
@@ -335,13 +417,13 @@ Sigmaルールは、最初にHayabusaルール形式に変換する必要があ
## 英語
- 2022/01/24 [Hayabusa結果をneo4jで可視化する方法](https://www.youtube.com/watch?v=7sQqz2ek-ko) by Matthew Seyer ([@forensic_matt](https://twitter.com/forensic_matt))
* 2022/01/24 [Hayabusa結果をneo4jで可視化する方法](https://www.youtube.com/watch?v=7sQqz2ek-ko) by Matthew Seyer ([@forensic_matt](https://twitter.com/forensic_matt))
## 日本語
- 2022/01/22 [Hayabusa結果をElastic Stackで可視化する方法](https://qiita.com/kzzzzo2/items/ead8ccc77b7609143749) by [@kzzzzo2](https://qiita.com/kzzzzo2)
- 2021/12/31 [Windowsイベントログ解析ツール「Hayabusa」を使ってみる](https://itib.hatenablog.com/entry/2021/12/31/222946) by itiB ([@itiB_S144](https://twitter.com/itiB_S144))
- 2021/12/27 [Hayabusaの中身](https://kazuminkun.hatenablog.com/entry/2021/12/27/190535) by Kazuminn ([@k47_um1n](https://twitter.com/k47_um1n))
* 2022/01/22 [Hayabusa結果をElastic Stackで可視化する方法](https://qiita.com/kzzzzo2/items/ead8ccc77b7609143749) by [@kzzzzo2](https://qiita.com/kzzzzo2)
* 2021/12/31 [Windowsイベントログ解析ツール「Hayabusa」を使ってみる](https://itib.hatenablog.com/entry/2021/12/31/222946) by itiB ([@itiB_S144](https://twitter.com/itiB_S144))
* 2021/12/27 [Hayabusaの中身](https://kazuminkun.hatenablog.com/entry/2021/12/27/190535) by Kazuminn ([@k47_um1n](https://twitter.com/k47_um1n))
# 貢献

View File

@@ -11,6 +11,7 @@ use std::error::Error;
use std::fs::File;
use std::io;
use std::io::BufWriter;
use std::io::Write;
use std::process;
#[derive(Debug, Serialize)]
@@ -39,6 +40,9 @@ pub struct DisplayFormat<'a> {
/// level_color.txtファイルを読み込み対応する文字色のマッピングを返却する関数
pub fn set_output_color() -> Option<HashMap<String, Vec<u8>>> {
if !configs::CONFIG.read().unwrap().args.is_present("color") {
return None;
}
let read_result = utils::read_csv("config/level_color.txt");
if read_result.is_err() {
// color情報がない場合は通常の白色の出力が出てくるのみで動作への影響を与えない為warnとして処理する
@@ -135,64 +139,69 @@ fn emit_csv<W: std::io::Write>(
for (time, detect_infos) in messages.iter() {
for detect_info in detect_infos {
if displayflag {
// カラーをつけない場合は255,255,255で出力する
let mut output_color: Vec<u8> = vec![255, 255, 255];
if color_map.is_some() {
let target_color = color_map.as_ref().unwrap().get(&detect_info.level);
if target_color.is_some() {
output_color = target_color.unwrap().to_vec();
}
let output_color =
_get_output_color(&color_map.as_ref().unwrap(), &detect_info.level);
wtr.serialize(DisplayFormat {
timestamp: &format!(
"{} ",
&format_time(time).truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
level: &format!(
" {} ",
&detect_info.level.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
computer: &format!(
" {} ",
&detect_info.computername.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
event_i_d: &format!(
" {} ",
&detect_info.eventid.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
rule_title: &format!(
" {} ",
&detect_info.alert.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
details: &format!(
" {}",
&detect_info.detail.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
})?;
} else {
wtr.serialize(DisplayFormat {
timestamp: &format!("{} ", &format_time(time)),
level: &format!(" {} ", &detect_info.level),
computer: &format!(" {} ", &detect_info.computername),
event_i_d: &format!(" {} ", &detect_info.eventid),
rule_title: &format!(" {} ", &detect_info.alert),
details: &format!(" {}", &detect_info.detail),
})?;
}
wtr.serialize(DisplayFormat {
timestamp: &format!(
"{} ",
&format_time(time).truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
level: &format!(
" {} ",
&detect_info.level.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
computer: &format!(
" {} ",
&detect_info.computername.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
event_i_d: &format!(
" {} ",
&detect_info.eventid.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
rule_title: &format!(
" {} ",
&detect_info.alert.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
details: &format!(
" {}",
&detect_info.detail.truecolor(
output_color[0],
output_color[1],
output_color[2]
)
),
})?;
} else {
// csv出力時フォーマット
wtr.serialize(CsvFormat {
@@ -224,17 +233,25 @@ fn emit_csv<W: std::io::Write>(
total_detect_counts_by_level,
"Total".to_string(),
"detections".to_string(),
&color_map,
);
_print_unique_results(
unique_detect_counts_by_level,
"Unique".to_string(),
"rules".to_string(),
&color_map,
);
Ok(())
}
/// 与えられたユニークな検知数と全体の検知数の情報(レベル別と総計)を元に結果文を標準出力に表示する関数
fn _print_unique_results(mut counts_by_level: Vec<u128>, head_word: String, tail_word: String) {
fn _print_unique_results(
mut counts_by_level: Vec<u128>,
head_word: String,
tail_word: String,
color_map: &Option<HashMap<String, Vec<u8>>>,
) {
let mut wtr = BufWriter::new(io::stdout());
let levels = Vec::from([
"critical",
"high",
@@ -248,19 +265,45 @@ fn _print_unique_results(mut counts_by_level: Vec<u128>, head_word: String, tail
counts_by_level.reverse();
// 全体の集計(levelの記載がないためformatの第二引数は空の文字列)
println!(
writeln!(
wtr,
"{} {}: {}",
head_word,
tail_word,
counts_by_level.iter().sum::<u128>()
);
)
.ok();
for (i, level_name) in levels.iter().enumerate() {
println!(
let output_str;
let output_raw_str = format!(
"{} {} {}: {}",
head_word, level_name, tail_word, counts_by_level[i]
);
if color_map.is_none() {
output_str = output_raw_str;
} else {
let output_color =
_get_output_color(&color_map.as_ref().unwrap(), &level_name.to_string());
output_str = output_raw_str
.truecolor(output_color[0], output_color[1], output_color[2])
.to_string();
}
writeln!(wtr, "{}", output_str).ok();
}
wtr.flush().ok();
}
/// levelに対応したtruecolorの値の配列を返す関数
fn _get_output_color(color_map: &HashMap<String, Vec<u8>>, level: &String) -> Vec<u8> {
// カラーをつけない場合は255,255,255で出力する
let mut output_color: Vec<u8> = vec![255, 255, 255];
let target_color = color_map.get(level);
if target_color.is_some() {
output_color = target_color.unwrap().to_vec();
}
return output_color;
}
fn format_time(time: &DateTime<Utc>) -> String {
if configs::CONFIG.read().unwrap().args.is_present("utc") {
format_rfc(time)
@@ -416,7 +459,26 @@ mod tests {
.datetime_from_str("1996-02-27T01:05:01Z", "%Y-%m-%dT%H:%M:%SZ")
.unwrap();
let expect_tz = expect_time.with_timezone(&Local);
let expect = "Timestamp|Computer|EventID|Level|RuleTitle|Details\n".to_string()
let expect_header = "Timestamp|Computer|EventID|Level|RuleTitle|Details\n";
let expect_colored = expect_header.to_string()
+ &get_white_color_string(
&expect_tz
.clone()
.format("%Y-%m-%d %H:%M:%S%.3f %:z")
.to_string(),
)
+ " | "
+ &get_white_color_string(test_computername)
+ " | "
+ &get_white_color_string(test_eventid)
+ " | "
+ &get_white_color_string(test_level)
+ " | "
+ &get_white_color_string(test_title)
+ " | "
+ &get_white_color_string(output)
+ "\n";
let expect_nocoloed = expect_header.to_string()
+ &expect_tz
.clone()
.format("%Y-%m-%d %H:%M:%S%.3f %:z")
@@ -432,15 +494,23 @@ mod tests {
+ " | "
+ output
+ "\n";
let mut file: Box<dyn io::Write> =
Box::new(File::create("./test_emit_csv_display.txt".to_string()).unwrap());
assert!(emit_csv(&mut file, true, None).is_ok());
match read_to_string("./test_emit_csv_display.txt") {
Err(_) => panic!("Failed to open file."),
Ok(s) => {
assert_eq!(s, expect);
assert!(s == expect_colored || s == expect_nocoloed);
}
};
assert!(remove_file("./test_emit_csv_display.txt").is_ok());
}
fn get_white_color_string(target: &str) -> String {
let white_color_header = "\u{1b}[38;2;255;255;255m";
let white_color_footer = "\u{1b}[0m";
return white_color_header.to_owned() + target + white_color_footer;
}
}

View File

@@ -53,29 +53,30 @@ fn build_app<'a>() -> ArgMatches<'a> {
return ArgMatches::default();
}
let usages = "-d --directory=[DIRECTORY] 'Directory of multiple .evtx files'
-f --filepath=[FILEPATH] 'File path to one .evtx file'
let usages = "-d --directory=[DIRECTORY] 'Directory of multiple .evtx files.'
-f --filepath=[FILEPATH] 'File path to one .evtx file.'
-r --rules=[RULEDIRECTORY/RULEFILE] 'Rule file or 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'
-c --color 'Output with color. (Terminal needs to support True Color.)'
-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.'
-u --update-rules 'Clone latest hayabusa-rule'
-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'
-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'";
--contributors 'Prints the list of contributors.'";
App::new(&program)
.about("Hayabusa: Aiming to be the world's greatest Windows event log analysis tool!")
.version("1.1.0")
.author("Yamato-Security(https://github.com/Yamato-Security/hayabusa)")
.author("Yamato Security (https://github.com/Yamato-Security/hayabusa)")
.setting(AppSettings::VersionlessSubcommands)
.usage(usages)
.args_from_usage(usages)

View File

@@ -13,8 +13,8 @@ use crate::detections::utils::get_serde_number_to_string;
use crate::filter;
use crate::yaml::ParseYaml;
use hashbrown;
use hashbrown::HashMap;
use serde_json::Value;
use std::collections::HashMap;
use std::io::BufWriter;
use std::sync::Arc;
use tokio::{runtime::Runtime, spawn, task::JoinHandle};

View File

@@ -5,7 +5,8 @@ use self::selectionnodes::{
AndSelectionNode, NotSelectionNode, OrSelectionNode, RefSelectionNode, SelectionNode,
};
use super::selectionnodes;
use std::{collections::HashMap, sync::Arc};
use hashbrown::HashMap;
use std::sync::Arc;
lazy_static! {
pub static ref CONDITION_REGEXMAP: Vec<Regex> = vec![

View File

@@ -3,7 +3,8 @@ use crate::detections::print::Message;
use chrono::{DateTime, Utc};
use std::{collections::HashMap, fmt::Debug, sync::Arc, vec};
use hashbrown::HashMap;
use std::{fmt::Debug, sync::Arc, vec};
use yaml_rust::Yaml;

View File

@@ -2,9 +2,9 @@ use crate::detections::configs;
use crate::detections::print::AlertMessage;
use crate::detections::print::ERROR_LOG_STACK;
use crate::detections::print::QUIET_ERRORS_FLAG;
use hashbrown::HashSet;
use lazy_static::lazy_static;
use regex::Regex;
use std::collections::HashSet;
use std::fs::File;
use std::io::BufWriter;
use std::io::{BufRead, BufReader};

View File

@@ -1,5 +1,5 @@
use crate::detections::{configs, detection::EvtxRecordInfo, utils};
use std::collections::HashMap;
use hashbrown::HashMap;
#[derive(Debug)]
pub struct EventStatistics {

View File

@@ -1,7 +1,7 @@
use crate::detections::{configs, detection::EvtxRecordInfo};
use super::statistics::EventStatistics;
use std::collections::HashMap;
use hashbrown::HashMap;
#[derive(Debug)]
pub struct Timeline {

View File

@@ -6,7 +6,7 @@ use crate::detections::print::AlertMessage;
use crate::detections::print::ERROR_LOG_STACK;
use crate::detections::print::QUIET_ERRORS_FLAG;
use crate::filter::RuleExclude;
use std::collections::HashMap;
use hashbrown::HashMap;
use std::ffi::OsStr;
use std::fs;
use std::io;
@@ -201,34 +201,6 @@ impl ParseYaml {
let files: Vec<(String, Yaml)> = yaml_docs
.into_iter()
.filter_map(|(filepath, yaml_doc)| {
// ignoreフラグがONになっているルールは無視する。
if yaml_doc["ignore"].as_bool().unwrap_or(false) {
self.ignorerule_count += 1;
return Option::None;
}
self.rulecounter.insert(
yaml_doc["ruletype"].as_str().unwrap_or("Other").to_string(),
self.rulecounter
.get(&yaml_doc["ruletype"].as_str().unwrap_or("Other").to_string())
.unwrap_or(&0)
+ 1,
);
if configs::CONFIG.read().unwrap().args.is_present("verbose") {
println!("Loaded yml file path: {}", filepath);
}
// 指定されたレベルより低いルールは無視する
let doc_level = &yaml_doc["level"]
.as_str()
.unwrap_or("informational")
.to_string()
.to_uppercase();
let doc_level_num = configs::LEVELMAP.get(doc_level).unwrap_or(&1);
let args_level_num = configs::LEVELMAP.get(level).unwrap_or(&1);
if doc_level_num < args_level_num {
return Option::None;
}
//除外されたルールは無視する
let rule_id = &yaml_doc["id"].as_str();
if rule_id.is_some() {
@@ -244,6 +216,30 @@ impl ParseYaml {
}
}
self.rulecounter.insert(
yaml_doc["ruletype"].as_str().unwrap_or("Other").to_string(),
self.rulecounter
.get(&yaml_doc["ruletype"].as_str().unwrap_or("Other").to_string())
.unwrap_or(&0)
+ 1,
);
if configs::CONFIG.read().unwrap().args.is_present("verbose") {
println!("Loaded yml file path: {}", filepath);
}
// 指定されたレベルより低いルールは無視する
let doc_level = &yaml_doc["level"]
.as_str()
.unwrap_or("informational")
.to_string()
.to_uppercase();
let doc_level_num = configs::LEVELMAP.get(doc_level).unwrap_or(&1);
let args_level_num = configs::LEVELMAP.get(level).unwrap_or(&1);
if doc_level_num < args_level_num {
return Option::None;
}
if !configs::CONFIG
.read()
.unwrap()
@@ -273,7 +269,7 @@ mod tests {
use crate::filter;
use crate::yaml;
use crate::yaml::RuleExclude;
use std::collections::HashSet;
use hashbrown::HashSet;
use std::path::Path;
use yaml_rust::YamlLoader;