withsecurelabs / chainsaw Goto Github PK

Chainsaw for Windows does not run in Windows 7? Is there a Version that will run in Windows 7?

However it does run in Windows 10.

Kenneth

Symantec category: Malware
Hash: 90A88E340271274B9BFF5502C34E4669CD450FD6286625E827FB66019A9F1B6B

Great work on this! I really appreciate all the work that went into it!

While the individual objects contained within the JSON output are considered valid JSON, it seems like when they are concatenated together in the results file, they are not separated (by comma ,), and/or considered as an array of objects (with open/closing bracket []), so the results can't be picked up by tools that parse JSON without additional work. If needed, I can follow up with a PR as I get time.

Additionally, it would be nice to consider allowing for JSON output to stdout, so a file would not need to be written to disk, but other tools could easily parse the data returned.

-o Parameter

Expected behavior as per README.md

Using chainsaw <EVTX-File> -o example.txt lets me save the results to a txt file.

Actual behavior

error: Found argument '-o' which wasn't expected, or isn't valid in this context

-j/--json Parameter

Expected behavior as per .\chainsaw.exe search --help

.\chainsaw.exe search --help does not show any -o option for chainsaw. It instead shows a -j/--json option. This should store the output to a .JSON file.

Actual behavior

Using this parameter yields basically the same error message:

error: Found argument '-j' which wasn't expected, or isn't valid in this context

Summary

• Missmatch between README.md and output of --help
• -o not known for search
• -j/--json not known for search

Testing Environment

I tested the most current version chainsaw 1.1.5 (chainsaw_x86_64-pc-windows-msvc.zip) using:

• Windows 11 Pro N (10.0.22000 Build 22000) cmd.exe
• Tested for PowerShell 5.1.22000.282

It would be really nice to have sigma metadatas (especially level and tags) directly in the json output file.

This would be usefull when indexing results in a SIEM !

Thanks

I'm trying to generate a json output file. Unfortuanttly it seems not to work because it's not allowed to add a path after --json like --json C:\TEMP\test.json

Expected behavior:
If I'm running the command:
chainsaw.exe" hunt C:\Windows\System32\winevt\Logs --rules "C:\xyz\xyz\xyz\chainsaw\sigma_rules" --mapping "xyz\xyz\xyz\chainsaw\mapping_files\sigma-mapping.yml --json C:\xyz\xyz\xyz\chainsaw\output.json
I would execpet in the folder C:\xyz\xyz\xyz\chainsaw\ the output.json.

Actual behavior
If I'm running the command:
chainsaw.exe" hunt C:\Windows\System32\winevt\Logs --rules "C:\xyz\xyz\xyz\chainsaw\sigma_rules" --mapping "xyz\xyz\xyz\chainsaw\mapping_files\sigma-mapping.yml --json C:\xyz\xyz\xyz\chainsaw\output.json

I get the following "error" dialog:
error: Found argument 'C:\xyz\xyz\xyz\chainsaw\output.json' which wasn't expected, or isn't valid in this context

If I'm running it without a path like:
chainsaw.exe" hunt C:\Windows\System32\winevt\Logs --rules "C:\xyz\xyz\xyz\chainsaw\sigma_rules" --mapping "xyz\xyz\xyz\chainsaw\mapping_files\sigma-mapping.yml --json

Its working but prints the json in the console which is not what I expect from this paramter.

Could you maybe have a look on it?

Thanks already and many greetings

Potential bug resulting in incorrect Sigma detections since Chainsaw v1.1.0.

When parsing a System.evtx file with Chainsaw v1.1.0 (from "chainsaw_x86_64-pc-windows-msvc.zip"), several Sigma rules are incorrectly triggered by every 7045 event. See example below:

A similar test using Chainsaw v1.0.2 shows no false positives, see below:

Finally a test with Chainsaw v1.0.2 using the Sigma rule set bundled with v1.1.0. No false positives, see below:

On one of my first run-throughs of using Chainsaw I mistakenly put the logs I wanted to parse in the root of the program folder on a windows machine and then ran some analysis tasks. It seems it will recursively check subfolders under the main folder for additional event files and add them to the capture. This resulted in me thinking I was seeing signs of compromise in the output .csv files that were actually pulled in from the samples and merged with the results from the actual parsing. May want to add a check or a warning to new users to ensure they don't make the same mistake.

Hi,
Great Tool! Would love to see the --csv option to have the ability to output/write the csv files to a specified directory similar to the --json option? With that, it should be pretty easy to integrate with other tools, such as integrating it as a kape module.

Running Ubuntu 20.04 and getting the following errors when launching cargo build

warning: field is never read: category--> src/convert/sigma.rs:22:5 | 22 | pub category: Option<String>, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note:#[warn(dead_code)]` on by default

warning: field is never read: product
--> src/convert/sigma.rs:24:5
|
24 | pub product: Option,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: field is never read: service
--> src/convert/sigma.rs:26:5
|
26 | pub service: Option,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: field is never read: logsource
--> src/convert/sigma.rs:50:5
|
50 | pub logsource: Option,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: chainsaw (lib) generated 4 warnings
Finished release [optimized] target(s) in 3m 30s
`

Since we merged in #23 the progress bar for the search functionality no longer seems to work.
The hunt search bar still works, so I assume this might be to do with how we are printing now?

@alexkornitzer - One for you to take a look at if you have time?

I have evtx saved as json. Noticed in your blog that you convert evtx to json, before searching thru them. Is it possible to feed json directly ? Thanks

Running on a sample of 178 evtx files and it fails quickly throwing the error "[!] Chainsaw exited: An error occurred while trying to deserialize evtx stream."

However, it does not give any indication of which log file it failed to parse, and with 100+ logs it's time consuming to work out which evtx file(s) it's struggling with.

Additionally it can be tedious to copy the files to a new location and remove just the one invalid file and re-run, so a suggested fix would preferably be one that:

• Skips any evtx file it fails to parse
• Provides verbose (or logged) indication of the filename when throwing errors

At the time I clearly did not read this bit of the spec properly (or at all). So that way we parse sigma into tau for Rule collections is incorrect. This results in issues (#19, #30). Correcting this should not be too difficult.

Hello,

Thanks for all your work on this fantastic tool!

Sigma rules in the SigmaHQ repo seem to change by the hour. It's a very fast moving repo, as I've come to find out. Manually updating these Sigma rules is simply something most people won't do and over time they'll be missing out on new rules for the latest threats. A fair amount of examiners likely won't know any better that these rules should be maintained and updated on a fairly regular basis.

The ask here is to consider adding a --sync command (or similar) that'll mirror the contents of https://github.com/SigmaHQ/sigma/tree/master/rules into the .\Chainsaw\sigma_rules directory, folders and all. If not all folders, then maybe at least the Windows and APT folders, to start?

Thanks for any consideration!

I can see that chainsaw only supports files with evtx extension.
https://github.com/countercept/chainsaw/blob/master/src/util.rs#L56

Would it be possible to add a command line argument to check for a different file extension ?

thanks !

Pulled latest compiled release x64 windows

chainsaw_x86_64-pc-windows-msvc.zip

VirusTotal reports a few issues

similar to issue #8 having an option for the csv output to stdout would be great

Request to add support for more event log providers related to F-Secure alerts. The built-in support for F-Secure alerts consumes events from the "F-Secure Ultralight SDK" provider. My limited research shows that alerts are also found in the "F-Secure File scanning" and "FSecure-FSecure-F-Secure DeepGuard" providers. These alerts aren't detected by Chainsaw.

(Let me know if there is any good documentation about event ID:s and log providers used by F-Secure.)

Hello, I downloaded the release version of chainsaw and it's running smoothly using sigma-rules from SigmaHQ, which is great. But once I use custom rules from another repository, it threw an error. I'm not sure where the error come from, but it became an issue when I'm trying to use custom rule.

PS> chainsaw.exe hunt <evtx location> -r <custom rules location> -m ".\mapping_files\sigma-mapping.yml"
██████╗██╗  ██╗ █████╗ ██╗███╗   ██╗███████╗ █████╗ ██╗    ██╗
██╔════╝██║  ██║██╔══██╗██║████╗  ██║██╔════╝██╔══██╗██║    ██║
██║     ███████║███████║██║██╔██╗ ██║███████╗███████║██║ █╗ ██║
██║     ██╔══██║██╔══██║██║██║╚██╗██║╚════██║██╔══██║██║███╗██║
╚██████╗██║  ██║██║  ██║██║██║ ╚████║███████║██║  ██║╚███╔███╔╝
 ╚═════╝╚═╝  ╚═╝╚═╝  ╚═╝╚═╝╚═╝  ╚═══╝╚══════╝╚═╝  ╚═╝ ╚══╝╚══╝
    By F-Secure Countercept (Author: @FranticTyping)

[+] Found 231 EVTX files
[+] Converting detection rules...
thread 'main' panicked at 'removal index (is 0) should be < len (is 0)', library\alloc\src\vec\mod.rs:1385:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Is the mapping incompatibility become an issue?

First of all, great tool 👍

Would it be possible to display the rule author somewhere whenever a rule matches on an eventlog entry to comply with the Detection Rule License?
Maybe in brackets behind the rule title in the column detection_rules?

https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md

I guess this would be the right location:
https://github.com/countercept/chainsaw/blob/0a4b0f22427985a6cd0af1b1fd559933e5adf6f7/src/hunt/modules.rs#L50

Request to include a -q flag that only prints the JSON output (excludes banner, etc.). This would make it easier to pipe the output of chainsaw to other tools.

I saved the results as a json file. I believe there's a format error somewhere. When I paste the contents into a json syntax verifier it fails, and when I import it into PowerShell and convert it, it also fails.

.\chainsaw.exe hunt .\evtx_attack_samples\Execution\exec_persist_rundll32_mshta_scheduledtask_sysmon_1_3_11.evtx --rules .\sigma_rules\ --mapping .\mapping_files\sigma-mapping.yml --lateral-all --json .\results.json

Get-Content -raw .\results.json | ConvertFrom-Json
// Fails

It would be nice to have an option to output JSON results to stdout for immediate consumptions vs. writing to a file.

Originally discussed here: #2 (comment)

Wondering if there is a way to parse an XML file of event logs that may have been extracted from memory with volatility or
Willi Ballenthin's evtxtract. Not able to find a method to extract the individual logs from the xml, but if this feature could be added to the tool, that'd be awesome! Thanks!

Request to add support for sending the output as Syslog or CEF stream.

This would give the possibility of performing threat hunting on multiple teams at the same time without the need for forensic acquisitions.

Example:

1-Display chainsaw on a big grouf of computers (Ex: 1000)
2-Execute a chainsaw command on multiple computers. (Example: With psexec.)
3-Receive all the data in a SIEM and query about them.

I cloned the repository and tried compiling the software but unfortunately I did not find any relevant document to do so. Am I missing anything or looking at wrong place? My OS is Ubuntu-20.04

When \r present in columns, the CSV files generate additional lines and not formatted correctly:

system_time,id,detection_rules,computer_name,Event.EventData.TargetFilename,image
2021-10-26 05:58:04,11,"+ Suspicious xxxx
File Created In TMP","""xxxx""",xxxx,xxxx
2021-10-26 06:55:36,11,"+ Suspicious xxxx
File Created In TMP","""xxxx""",xxxx,xxxx

This is normally the case for the column "Detection Rules".
Would it be possible to remove that \r or generate that column in a different way so that the CSVs will be created correctly?

Request to include start / end date options, to select events to process. This would optimize processing of large event log files, such as ForwardedEvents.evtx with 10-20 GB max size. Ideally the date filters would be applied as early as possible, to avoid unnecessary processing of irrelevant events. Suggested options:

OPTIONS:
  -sd, --start-date <datetime>
           Start date for including events (UTC). Anything older than this is dropped. Format: yyyy-MM-dd HH:mm:ss

  -ed, --end-date <datetime>
           End date for including events (UTC). Anything newer than this is dropped. Format: yyyy-MM-dd HH:mm:ss

So IMO the chainsaw code needs a bit of a clean. We also need to add tests so that its easier for contributions and changes. When I find some time I will try and make some headway into this.

• Refactor to handle Rust style testing
• Clean code as required

No matter what folder you specify it seems to load the default rules folder

Hey, a beginner at this I was wondering if anyone could help me install this on my Windows 10?
I'm really not getting it... Thanks in advance!

had a 200mb log which shows the 4624 when using "search" however doesn't when using "hunt".

is it an issue with log size?

Request to add support for WEF/WEC ForwardedEvents.evtx files. Chainsaw seems to process such files, but no results are shown for searches or hunts. See examples below:

Hello,

Would it be possible for some documentation or guidance on how to expand the functionality of Chainsaw using sigma rules and chainsaw's mapping file?

I've spoken with a number of people in the DFIR community who would love to be able to contribute and build on what is already an amazing tool but have struggled to understand how to write new rules and then map it to Chainsaw's output (myself included!)

I'd be more than happy to collate some ideas for detection rules if that would help the process in anyway.

Any help, support or resource you can offer would be greatly appreciated.

Many thanks

Tom

It would be great to have the start and end date filters support the local machine time as apart from servers most desktops in an organization would have local time set.

Currently the events returned with date filters set are also in UTC time which means one needs to reconvert back the output to local time.

Most sigma rules use numeric EventID - i.e.:

detection:
    selection:
        EventID: 7045
        ServiceName:
            - 'srservice'
            - 'ipvpn'
            - 'hkmsvc'
    condition: selection

modules.rs [line 215] however converts the EventID to a String

doc["EventID"] = json!(event_id.to_string());

and the condition (EventID: 7045) is therefore not met. After removing the conversion to String (or rewriting the Sigma Rule to EventID: "7045") the Event is successfully matched:

doc["EventID"] = json!(event_id);

Upon attempting to create some test rules, I could not get a simple contains condition to hit on a type 400 powershell event. So I removed everything from the condition but the event ID and tried again, and still got no hits.

Tried removing as much as possible to isolate the problem, changing the log source service and product between the various "powershell", "powershell-classic" etc... used across pre-existing sigma rules.

Whilst I tried a large number of variants, see below the rule I believe should be most likely to work based off of existing rules in the 'sigma_rules' ruleset. this rule does not hit on any of the 400 events within a "Windows PowerShell.evtx" log:

title: test
id: 30a8cb77-8eb3-4cfb-8e79-ad447c5a4592
description: test
status: experimental
author: Michael
date: 2021/11/19
modified: 2021/11/19
tags:
    - attack.execution
    - attack.t1086
logsource:
    product: windows
    service: powershell-classic
detection:
    selection:
        EventID: 400
    condition: selection
falsepositives:
    - unknown
level: low

Even when only a single rule matches, testing numerous sets of logs will often come back with "+ Accessing WinAPI in PowerShell" or something similar, where the + character is added to the start of the column value.

I'm unsure if this is because there may be one or more rules in the main sigma ruleset that don't have a title, but even in that case it would be preferable to exclude the empty " +" from the start.

As a small compatibility sidenote, this does then interfere with opening the csv outputs in excel as excel will turn these column values into equations, which is actually quite difficult to get around without some transformation of the file.

Hello, thanks a lot for this amazing product.

Currently, Chainsaw result includes the name of matched Sigma rule. Can you include Sigma rule ID and description too?

Sigma ID is not a mandatory field according to https://github.com/SigmaHQ/sigma/wiki/Specification, but it could be nice to know more information about the match from the Sigma rule specification.

Thanks!

Curious why not use separate-json-attributes for the EvtxParserSettings?

The issue with not using this settings is that it causes inconsistent json attribute naming standard:

When ever a XML element as an attribute, the JSON field will split into a #text and #attributes. This causes issues on many fronts. Using separate-json-attributes setting for the parser will normalize the fields and an XML element's value will always be the field name and any element attributes will be placed under <ELEMENT_NAME>_attributes. This prevents inconsistent field names in JSON serializations.

Some other references:

• https://youtu.be/9lu3NOaNXdY?t=591
• omerbenamram/evtx#198

If you are open to this I can create a PR

Curious as to why there isn't an option for both hunt/search for an output directory?

I use this for multiple concurrent clients and it creates a lot of overhead to either move chainsaw and its libraries needed, or constantly moving the folder created from where chainsaw executes to my current working directory

Trend Micro Antivirus removing chainsaw.exe as a malicious file. Is there any way we could get it reported to trend to allow it?

We pull event logs out of RAM for forensic analysis. This can lead to both complete and incomplete files, and when you have hundreds of event logs trying to figure out which ones are good and which ones are bad can be tedious. When Chainsaw hits an incomplete/corrupt file it stops the whole search with the message "an error occurred while trying to deserialize evtx stream". If there's 400 evtx logs and only 1 of them is bad, it will stop the whole search.

Is it possible to have it skip files it can't parse in order to complete the search? Or barring that can it at least output which file it hung up on so I can remove it from the directory?

When running against some triage images that contain unreadable directories, chainsaw will exit even with --ignore-errors set.

Example:
Chainsaw exited: IO error for operation on E:\System Volume Information: Access is denied. (os error 5)

Yo yo,

It's your boy, Mert.

Was just testing the json output. It looks like built-in detections do not get appended to the json output. Was this by design or a bug?

Json output:

Normal output:

When running chainsaw in search mode against a very large set of event logs, if the search parameters are broad enough to capture a lot of results then the memory used by Chainsaw will balloon and may result in the binary being terminated.

This is due to #7 where we now load hits into a Vec before printing in order to output JSON correctly. If there are too many matches then the Vec will bloat out and consume too much memory.

Awesome tool...thx for sharing with the community!

The CSV output should be in UTF8. Please fix this with your next release. Thank you!

I processed EVTX files from a French system and a lot of characters were bogus. JSON output looked fine.

Cheers!

The JSON output for "search" puts a [] around the JSON data and introduces other formatting errors.

From Firefox: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data. Even if I remove the []'s, I still get that.

Get-Content -Raw .\output.json | ConvertFrom-Json returns blank data as well.

This is chainsaw version 1.1.5 on Windows 10.

It would be extremely useful for this tool to have a switch like --PSObject, that outputs the results to stdout as PowerShell object data. Currently, I have to save the results to a csv file then import it into PowerShell for additional manipulation using "Import-Csv "chainsawfile.csv". Though, this mild inconvenience isn't a show stopper, skipping the step of saving the results and being able to manipulate object data would be super awesome. A simple example is using PowerShell's Out-GridView to view the results natively and then applying filters or just searching. That, and having to clean up the files afterward wouldn't be necessary.

Example of request:
chainsaw.exe hunt $SavedEventLogs --rules .\sigma_rules\ --mapping .\mapping_files\sigma-mapping.yml --PSObject | Out-GrdiView -Title 'Chainsaw Results'

Current Non-Preferred Method:
chainsaw.exe hunt $SavedEventLogs --rules .\sigma_rules\ --mapping .\mapping_files\sigma-mapping.yml --csv
Import-Csv ".\chainsaw_2021-09-05T11-52-35(external_rule)_-suspicious_process_creation.csv" | Out-GridView -Title "Chainsaw Results"
Remove-Item ".\chainsaw_2021-09-05T11-52-35(external_rule)-_suspicious_process_creation.csv"