Rule exception in SIEM Kibana 7.12

[dsgamr]

Hi,
One of build in rules - Whoami Process Activity - generates a lot of false positives in my environment so I tried to add exception to the rule.
Problem is that to do it properly one has to use wildcards which doesn't seem to work right know in rule exceptions.

Here is an simple process tree example, where trusted application runs whoami through cmd.exe:

- Trusted app
  - C:\WINDOWS\system32\cmd.exe /S /C ""C:\WINDOWS\System32\whoami.exe" /groups > "C:\path_to_Temp\prefix-random_string.tmp"
    - C:\WINDOWS\System32\whoami.exe"  /groups <- command that actually triggers signal.

I think that proper way to add exception would be like that:

process.parent.command_line is C:\WINDOWS\system32\cmd.exe /S /C ""C:\WINDOWS\System32\whoami.exe" /groups > "C:\path_to_Temp\prefix-*.tmp"

I have tried various combinations with and without parentheses but it doesn't seem to work.

Am I missing something? What would be a better way to do it?

[Andrew_G (Andrew Macri)]

Hi @dsgamr, welcome to the community!

You're correct, we're tracking adding support for wildcards in rule exception lists in this issue.

Using the example you provided, I documented the steps to add an exception and demonstrate that the exception is working.

Regarding the sample event provided above:

@dsgamr

- Trusted app
  - C:\WINDOWS\system32\cmd.exe /S /C ""C:\WINDOWS\System32\whoami.exe" /groups > "C:\path_to_Temp\prefix-random_string.tmp"
    - C:\WINDOWS\System32\whoami.exe"  /groups <- command that actually triggers signal.

It looks like the sample may be missing a trailing double quote, though it's hard to tell without a copy of the original event. I preserved this feature of the data while documenting the steps below, because the technique should work the same.

Creating a detection rule for testing

To test our exception, first we'll create an example detection rule with the following custom query:

process.parent.command_line: *

The custom query above will match any event where the process.parent.command_line field exists.

Above: defining a custom query detection rule for testing

To simplify testing, the rule:

• Runs every 1 minute
• Has an additional look-back time of 24 hours

Ingesting a sample document

Next, after creating and activating the rule, I indexed the following document via Kibana Dev Tools:

POST auditbeat-7.8.0-2021.04.30-000023/_doc/
{
  "@timestamp": "2021-05-04T13:41:06.527Z",
  "process": {
    "parent": {
      "command_line": "C:\\WINDOWS\\system32\\cmd.exe /S /C \"\"C:\\WINDOWS\\System32\\whoami.exe\" /groups > \"C:\\path_to_Temp\\prefix-random_string.tmp\""
    }
  },
  "test": "1st event",
  "host": {
    "name": "testing-exception-lists"
  }
}

In addition to containing a process.parent.command_line with a value based on the example, the document above also contains a field named test that we'll reference when viewing the alerts.

Viewing the first alert

The screenshot of the Detection alerts page below:

• Is filtered in the KQL bar at the top of the page by the host.name in our sample event (host.name: testing-exception-lists)
• Includes the test and process.parent.command_line columns
• Shows the detection rule matches the newly-indexed document, with the expected values for the test and process.parent.command_line fields:

Above: The first detection

Adding the exception

Clicking the Add rule exception action on the rule in the Detection alerts table, as shown in the screenshot below, brings up the Add rule exception window:

In the Add Rule Exception window, enter process.parent.command_line in the Field drop down, as shown in the screenshot below:

Next, paste the following value from the example into the Value drop down:

C:\WINDOWS\system32\cmd.exe /S /C ""C:\WINDOWS\System32\whoami.exe" /groups > "C:\path_to_Temp\prefix-random_string.tmp"

as shown in the screenshot below:

After clicking the Add Rule Exception in the screenshot above, the newly-created exception will be associated with the rule.

The newly-added exception can be seen in the Exceptions tab on the rule details page, as shown in the screenshot below:

Verifying the exception

To verify the exception is working, we will index some additional events via Dev Tools:

POST auditbeat-7.8.0-2021.04.30-000023/_doc/
{
  "@timestamp": "2021-05-04T13:42:06.527Z",
  "process": {
    "parent": {
      "command_line": "command line for 2nd event"
    }
  },
  "test": "2nd event",
  "host": {
    "name": "testing-exception-lists"
  }
}

POST auditbeat-7.8.0-2021.04.30-000023/_doc/
{
  "@timestamp": "2021-05-04T13:43:06.527Z",
  "process": {
    "parent": {
      "command_line": "C:\\WINDOWS\\system32\\cmd.exe /S /C \"\"C:\\WINDOWS\\System32\\whoami.exe\" /groups > \"C:\\path_to_Temp\\prefix-random_string.tmp\""
    }
  },
  "test": "3rd event",
  "host": {
    "name": "testing-exception-lists"
  }
}

POST auditbeat-7.8.0-2021.04.30-000023/_doc/
{
  "@timestamp": "2021-05-04T13:44:06.527Z",
  "process": {
    "parent": {
      "command_line": "command line for 4th event"
    }
  },
  "test": "4th event",
  "host": {
    "name": "testing-exception-lists"
  }
}

When we index the documents above, the expected results are:

• An alert will be created for the event with the "test": "2nd event" field, because it doesn't match our exception
• An alert will NOT be created for the event with the "test": "3rd event" field, because it matches our exception
• An alert will be created for the event with the "test": "4th event" field, because it doesn't match our exception

Per the screenshot below, the alerts shown in the (refreshed) Detection alerts table match our expected results:

Above: As expected, an alert was NOT generated for the 3rd event, because it matched the exception