Closed L015H4CK closed 1 year ago
Hi Louis,
Chainsaw is not aware of base64offset
and is therefore ignoring it completely hence the outcomes you have listed in the summary. If this modifier is useful to you I can update the sigma parser in Chainsaw to handle this flag.
I will also update Chainsaw to not silently ignore modifiers it is not aware of, so its more obvious when this sort of stuff happens.
Hello Alex,
thank you for your quick response!
Since many Sigma rules are being updated to also include the encoded Base64 strings themselves, it is not as critical to support the base64offset
modifier as it may seem. Nonetheless, I think adding support for it would be really great.
I will also update Chainsaw to not silently ignore modifiers it is not aware of, so its more obvious when this sort of stuff happens.
This is definitely a good idea! :+1:
Thanks for the thorough description in the issue, yep all that makes sense. I'll find time to get it in sometime this week.
Hello there,
recently I have started working with Chainsaw using the Sigma ruleset. After some time I noticed, that Chainsaw might be missing Base64 encoding as it is used by Sigma. The following example should clarify the problem and make it reproducable.
Used rule: proc_creation_win_powershell_base64_iex.yml:
According to the Sigma Specification the
base64offset
modifier should encode the respective strings to base64 using shifts of 0, 1 and 2 bytes. (The second selection shows these encoding for the first 4 elements in the first selection part (i.e. 'IEX ([' to 'IEX (New').) The encoding is done using UTF16-LE, as stated by the in-rule comment. When running Chainsaw with this rule, detections are found in the following event logs (only CommandLine field is shown):powershell -e SQBFAFgAIAAoAFsAUwB5AHMAdABlAG0ALgBUAGUAeAB0AC4ARQBuAGMAbwBkAGkAbgBnAF0AOgA6AFUAbgBpAGMAbwBkAGUALgBHAGUAdABTAHQAcgBpAG4AZwAoAFsAUwB5AHMAdABlAG0ALgBDAG8AbgB2AGUAcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQAUwB0AHIAaQBuAGcAKAAiAGEAQQBCAHYAQQBIAE0AQQBkAEEAQgB1AEEARwBFAEEAYgBRAEIAbABBAEEAPQA9ACIAKQApACkA
-> matches 1st element in second selection list, 0 byte shift encoding ofIEX ([ ...
powershell -e aQBlAHgAIAAoAFsAUwB5AHMAdABlAG0ALgBUAGUAeAB0AC4ARQBuAGMAbwBkAGkAbgBnAF0AOgA6AFUAbgBpAGMAbwBkAGUALgBHAGUAdABTAHQAcgBpAG4AZwAoAFsAUwB5AHMAdABlAG0ALgBDAG8AbgB2AGUAcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQAUwB0AHIAaQBuAGcAKAAiAGEAQQBCAHYAQQBIAE0AQQBkAEEAQgB1AEEARwBFAEEAYgBRAEIAbABBAEEAPQA9ACIAKQApACkA
-> matches 4th element in second selection list, 0 byte shift encoding ofiex ([ ...
The following event logs are not detected, but they should be:
powershell -e SQBFAFgAKABbAFMAeQBzAHQAZQBtAC4AVABlAHgAdAAuAEUAbgBjAG8AZABpAG4AZwBdADoAOgBVAG4AaQBjAG8AZABlAC4ARwBlAHQAUwB0AHIAaQBuAGcAKABbAFMAeQBzAHQAZQBtAC4AQwBvAG4AdgBlAHIAdABdADoAOgBGAHIAbwBtAEIAYQBzAGUANgA0AFMAdAByAGkAbgBnACgAIgBhAEEAQgB2AEEASABNAEEAZABBAEIAdQBBAEcARQBBAGIAUQBCAGwAQQBBAD0APQAiACkAKQApAA==
-> not detected, 0 byte shift encoding ofIEX([ ...
, i.e. 5th element of first selection listpowershell -e SQBFAFgAKABOAGUAdwAtAEkAdABlAG0AIAB0AGUAcwB0AC4AdAB4AHQAKQA=
-> not detected, 0 byte shift encoding ofIEX(New ...
, i.e. 8th element of first selection listNow the interesting part that suggests there is no encoding performed by chainsaw. The following events logs are detected but should not be detected:
IEX([
-> detected, plaintext of 5th element of first selection listIEX(New
-> detected, plaintext of 8th element of first selection listTo summarize, Chainsaw:
Best regards, Louis