Hey,
I’m trying to add an exception to the Detection Rules and it is not suppressing the alerts. I looked through the documentation on this but there isn’t much as it relates to how the key-value pair is added. We have an application that runs throughout the environment that keeps creating investigations and I do not want to just whitelist that particular Attack Behaviour because this may whitelist a real incident as well.
How is the Key-Value pair suppose to be entered for the exception ? I have tried adding “name” as key and the name of the executable as value. I’ve even tried the r7 id but that keeps changing.
when an ABA alert fires, you will see the Evidence tab within the Investigation
From the evidence pane you can see the Key Value pairs.
In order to add an exception for the r7_hostid, which is the agent id you would add it like so:
However if you wanted to whitelist a KVP which is a nested Key such as the process name it would be:
And if you have a deeper nested KVP you can add it like so:
It’s also possible to add multiple KVPs, which are AND joined logically
The r7_context.asset.rrn key is the unique identifier for assets which we can use to identify a unique asset.
Note the operator on the right can be “is”, “contains”, or “starts with”.
And also you can enable/disable the case sensitivity.
We have plans to improve the experience of adding these KVPs as we continue to work on the Detection Rules page, as well as adding more examples to our docs.
One more thing I forgot to mention, whilst the Evidence pane shows events in JSON format with special characters which are escaped, when you are building out the exception rule, these additional backslashes are NOT needed. Here is an example.
Note in the Evidence pane we have a value for process.exe_path=“C:\\WINDOWS\\ctfmon.exe”
When creating an exception to match this it would be
process.exe_path CONTAINS C:\Windows\ctfmon.exe
Essentially we escape backslashes for JSON spec in the frontend, but our detection engine fires against the source data which is unescaped.
Please allow me to butt in to this thread as my query is actually just related to this topic.
Supposed you want to suppress the alert for netcat service that came from a Nagios plugin. In your logs you have like the below:
“exe_path”: “C:\Program Files (x86)\Nagios\NCPA\plugins\nc64.exe”,
“cmd_line”: ““C:\Program Files (x86)\Nagios\NCPA\plugins\nc64.exe” -w 1 -n 1.1.1.1 1433”,
Is it correct that my KVP would look like this?
process.exe_path CONTAINS Nagios
AND
process.cmd_line CONTAINS nc64.exe
Will this actually suppressed the nc64.exe alert when this is under Nagios?
My goal is just to add an exception when nc64.exe is running under Nagios plugin then it is allowed, if it is not running from the Nagios plugin then it should alert as expected.
Now based on your thread, am thinking that the way I implemented the exception is wrong and maybe it should look like:
process.exe.path IS/CONTAINS C:\Program Files (x86)\Nagios\NCPA\plugins\nc64.exe
OR
process.cmd_line IS/CONTAINS C:\Program Files (x86)\Nagios\NCPA\plugins\nc64.exe
Does it make sense?
Hope to get your advice on this. Thanks!
you have it right, if you want to build an exception rule to whitelist only when the process.exe_path CONTAINS Nagios AND the process.cmd_line CONTAINS nc64.exe your first example that should do the trick.
One thing thats always worth checking when building your exception rule is the Detection Rule logic itself. I believe the Alert you are referring to is Suspicious Process - Netcat
which has the following logic
This says if the process.name is either netcat.exe, nc.exe or ncat.exe (IIN means within the provided array, with case insensitivity applied).
So it’s worth verifying that your exception rule doesn’t negate this logic entirely, otherwise you would effectively be disabling the alert with an exception rule, but thats not the case with your approach.
If you opt to use the IS operator when building an exception rule the key value pair must be an exact match, and that may not be desirable in this case.
On a final note we added since my last post which you may also find comes in handy, is the auto suggestion option to unescape characters if you so happen to copy the contexts directly from the Investigation Evidence page. You will see this prompt remove the escape characters if you happen to do so.
We also have some further additions planned to bring the evidence payload right within the exception rule builder itself. Coming soon!
