sigma
sigma copied to clipboard
Carbon Black Backend - Broken Wildcards
Hi,
I believe that the CarbonBlack backend is not working as intended in regards to wildcards. This also affects Uncoder.io
Take the following Sigma:
selection:
Image:
- '*\UMWorkerProcess.exe'
When run through sigmac with the carbonblack target (same behavior for uncoder.io as well) this is the result:
(process_name:\\UMWorkerProcess.exe)
The wildcard has been replaced with a backslash. The correct query should be:
(process_name:*\UMWorkerProcess.exe)
This is also true for modifiers:
filter:
TargetFilename|endswith:
- CacheCleanup.bin
- .txt
- .log
- .cfg
- cleanup.bin
Gives:
(filemod:CacheCleanup.bin OR filemod:.txt OR filemod:.log OR filemod:.cfg OR filemod:cleanup.bin)
Preceding wildcards are not there, the correct query should be:
(filemod:*CacheCleanup.bin OR filemod:*.txt OR filemod:*.log OR filemod:*.cfg OR filemod:*cleanup.bin)
There is also a problem with trailing wildcards in paths, where you would want to escape the last slash to wildcard a directory:
detection:
selection:
TargetFilename:
- 'C:\test\path\for\sigma\\*'
Gives:
(filemod:C:\test\path\for\sigma\\)
I will take a further look and experiment with the CarbonBlack backend but I am not familiar with the code so any help with this would be greatly appreciated. Thank you
I'm not use to Carbon Black but in the code : https://github.com/SigmaHQ/sigma/blob/bcf2bf2e4db218b30b546b4e499b6cd8ea82525e/tools/sigma/backends/carbonblack.py#L92 https://github.com/SigmaHQ/sigma/blob/bcf2bf2e4db218b30b546b4e499b6cd8ea82525e/tools/sigma/backends/carbonblack.py#L119
So seen to be the expected behavior
@GeeG33 looks like you have used CB for a while, I'm sure you are aware that CB strongly recommends against using leading wild cards in queries. So I'd think generally it it would be in the best interest to follow those recommendations, the only places I've seen leading wildcards useful are in filemods and the command line. The trailing asterisks I would agree that it is helpful time to time based on the way the tokenization occurs.
I agree with your analysis @nighttardis , although it has to be said that for the example given by @GeeG33 :
filter:
TargetFilename|endswith:
- CacheCleanup.bin
- .txt
- .log
- .cfg
- cleanup.bin
cachecleanup.bin
and cleanup.bin
are likely to be tokenised as such and will be detected by the generated rule; but,
.txt
, .log
and .cfg
will probably never have matches in CarbonBlack without a wildcard.
This is a fundamental difference in how traditional 'contains' operations work (which Sigma assumes) and how all tokenised-based implementations (CarbonBlack/Elastic/etc.) work.
Related: #1653
This seems to me an issue of best practice Vs real need. To circumvent this one needs to either modify the backend to make it work with regex by removing the checks pointed out by @frack113 or simply write the SIGMA rules in a way to identify the check that "needs" a wildcard during conversion (similar to how some backends require the null
value to be on a separate selection).
The 2nd option isn't viable for rule writing in a generic way. This leaves us only with tuning the backend code in a "hacky" way to fit this need.
Closing this as answered and no changes will be introduced as it was mentioned above that the backend is following best practices. I suggest not taking such rules into consideration for now.
Also please note that since SIGMAC is approaching its EOL we don't want to introduce breaking changes to the backend themselves.
Check https://github.com/SigmaHQ/pySigma as it's the future of SIGMA backends.