Closed chavez243ca closed 4 years ago
I have fixed it in my environment by altering the last two searches to regex:
... OR /.+p.+::d.+/ OR /.+s.+::l.+/
Also wondering if this should be field-specific? I have prefixed the query with CommandLine:
This is a general issue with Sigma rules that are not bound to particular fields. In the ES query this means that all fields are queried, including analyzed ones. For searches against analyzed fields the query itself is analyzed. As consequence search terms like p::d
are decomposed into separate searches for the token p
and d
, which leads to the behavior observed by you. The solution is to restrict the search of such queries to non-analyzed (aka keyword) fields by wildcards on queries, e.g.:
\*.keyword:*p::d*
I've identified two todos arising by this:
The issue fixing process will be tracked in both new issues. Thanks for reporting this!
Should be fixed now, please try again.
Graylog backend is now derived from Elasticsearch query string backend because it is used by Graylog.
This specifically: " p\:\:d " OR " s\:\:l "
Which I believe is designed to trigger on privilege::debug OR sekurlsa::logonpasswords, respectively.
However, in practice I'm seeing it trigger on commandline switches, eg:
ontape -s -L 0 -t STDIO
forfiles /p D:
I have found adding an additional backslash, or removing the slashes altogether yields the exact same results in search.