I have a drop-down menu with all of the rule names that appear in the events. Some of those have been mapped in a lookup table and tailored to the needs of the company. For the others, I would need to display different information.
The base search is as follows (search id:base_search):
index=epo detection_method="Exploit Prevention" | eval filter_exists=if(
[| inputlookup defined_filters.csv | eval search="threat_name==\"".threat_name."\""
| stats count by threat_name, | sort 0 - count
| table threat_name],
"True", "False" ) | table threat_name, filter_exists
Please note that the True and False were just tests to make sure that I get what I expect to receive, which I do.
What I want to do next, is for the events that return a True value, perform a certain secondary search passing the threat_name to it because it needs the threat_name to process further.
This is an example of my secondary search if the first one returns true (search id:defined_filter):
[| inputlookup defined_filters.csv
| eval search="threat_name==\"".threat_name."\"" . if(isnull(where_eval), "", " and not (" . where_eval . ")")
| stats values(search) as search
| eval search="(" . mvjoin(search, ") or (") . ")"
| eval search=replace(replace(search, "\\\\", "\\\\\\\\"), "\"", "\\\"")
| return search]
| map maxsearches=1 search="search index=epo detection_method=\"Exploit Prevention\" threat_name=\"$threat_name$\" | where `map_workaround($$search$$)`"
For those that return false I need another secondary search. I guess I'm stuck at how to either nest or call the secondary search based on the results of the base_search and pass it the threat_name so I can create panels based on the results of each case.
... View more
We encountered some issues when upgrading our clustered indexes infrastructure from 7.2.4 to 7.2.5. The upgrade process for all machines worked as expected, however, when trying to access our search head, it seemed not to be able to communicate with the rest of our infrastructure.
After debugging the logfiles we found out that some of our defined FIELDALIAS'es in the props.conf on one of our custom apps was causing the search head to fatally crash. The following line within the crash log seemed to be at the base of the problem.
03-28-2019 16:24:20.505 WARN FieldAliaser - Invalid field alias specification in stanza 'XXX': FIELDALIAS-file_hash='TargetHash' (type='targethash')
03-28-2019 16:24:20.548 WARN CalcFieldProcessor - Invalid eval expression for 'EVAL-user' in stanza [XXX]: The expression is malformed. Expected ).
Even though the log does not indicate it to be an error, these were the last couple of lines prior to the application crashing. After uncommenting these field aliases in the application, all functionality went back to normal. Prior to the upgrade, however, these aliases did not have any impact on the search head's functionality.
I am wondering whether something changed with the current upgrade that could cause this issue. After looking into the patchnotes, I could not determine any significant changes that would. We rely on those custom apps for our day-to-day operations and having those fields is essential for us.
... View more
Currently I have a search as follows:
myFieldName="mySearchValue" | where match(path,`startOfPath`)
`startOfPath` expands to f.e. "^C\:\\\Windows\\\.*"
Some cases, however, I'd need to specify additional paths. In order to avoid to have a lot of repetition, my question was whether it was possible to use startOfPath + rest of path to validate the path.
As requested by mydog8it I'll elaborate with a concrete example of what I'm trying to accomplish.
macro 1 : filter_CLIENT_CONTROL
ThreatName="Client Control" | where match(SourcePath,`path_windows` + CustomRestOfPath)
macro 2 : path_windows
Whilst what I'm trying to accomplish is as follows for the filter_CLIENT_CONTROL macro:
ThreatName="Client Control" | where match(SourcePath,`path_windows` + ".*\\(COMPATTELRUNNER)\.EXE" ")
So in essence, the regex within the filter_CLIENT_CONTROL macro expands to ^C\:\\(WINDOWS)\\.*\\(COMPATTELRUNNER)\.EXE
... View more
I am trying to figure out how to pass a field value in the search to a macro which interprets it and does further processing through a lookup table.
I have consulted multiple threads but due to karma cannot link to them. Currently my approach is as follows:
index=my_index my_custom_field="the_value_to_filter_for" | map search="|`my_processing_macro($my_custom_field_)`"
Macro: my_processing_macro(1) (argument defined as name)
lookup my_lookup_table_def $name$ as lookup_table_column1
Lookup table (CSV-format): linked to lookup table definition
So in short, the value I pass in my_custom_field corresponds to a column1 row in the lookup table. Basically column 2 contains the regex or other macro's to expand during processing.
... View more