Detection Rules (SIEM) exceptions bug?

Hello,

Everytime I try to create an exception for builtin security rule "Enumeration of Kernel Modules" I receive an error :

type: Invalid literal value, expected "new_terms", language: Invalid enum value. Expected 'kuery' | 'lucene', received 'eql' (400)
{
  "name": "Error",
  "body": {
    "message": "type: Invalid literal value, expected \"new_terms\", language: Invalid enum value. Expected 'kuery' | 'lucene', received 'eql'",
    "status_code": 400
  },
  "message": "Bad Request",
  "stack": "Error: Bad Request\n    at fetch_Fetch.fetchResponse (https://xxx/d7985c806432/bundles/core/core.entry.js:16:232024)\n    at async https://xxx/d7985c806432/bundles/core/core.entry.js:16:230016\n    at async https://xxx/d7985c806432/bundles/core/core.entry.js:16:229973"
}

Here are some screenshots:


I also tried with API

POST kbn:/api/detection_engine/rules/30ef3bf0-fb00-11ed-b238-dffaf1b25f7d/exceptions
{
  "items": [
    {
      "comments": [],
      "description": "Exception list item",
      "entries": [
        {
          "field": "user.name",
          "operator": "included",
          "type": "match",
          "value": "root"
        }
      ],
      "name": "test",
      "namespace_type": "single",
      "tags": [],
      "type": "simple"
    }
  ]
}

I've got the same error :frowning:

Elastic version : 8.17.2

Any idea ?

Thanks

Hi @marrc.rousseau !

I checked out 8.17.2 and was able to successfully add an exception to "Enumeration of Kernel Modules".

I don't see anything jump out on the exception side. The error message makes me think there's something odd happening on the rule side.

Would you be able to share a HAR? I'd be curious to see what rule version you're using and see if I can recreate using that specific version.

Hi @yctercero

Thanks for your reply

For an unknow reason there are two rules "Enumeration of Kernel Modules"

First one is

Second one is

Looks like the first one is an old one
Creating an exception on both rules triggers the error

I deleted the old one, enabled the second one, create an exception and now no more error.

Apparently the problem came from a conflict between these two versions of the same rule

Problem solved.

Thanks