Sigma rules disappear after enabling

[gustavoberman]

Version

Other (please provide detail below)

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

other (please provide detail below)

Hardware Specs

Meets minimum requirements

CPU

20

RAM

16GB

Storage for /

150GB

Storage for /nsm

300GB

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Hello there,
I started testing a standalone 2.4.201 ManagerSearch install for a small network.
Installation went without a problem, same with agent installation in 10 hosts between physical/virtual servers and physical desktops. All linux based

So I went to Detection, filter to include sigma, core, and then linux, this came up with some 26 rules.
I enabled all 26. I wait for some minutes, look for other things, when I came back to detections, this rules are nowhere. Not in enabled or disabled. Wait for a couple hours and the rules are still not there.

Next day, the rules appears again, enabled.

Any idea what causes this?
How can I follow the process?

/opt/so/log/elastalert/elastalert.log have a lot of errors regarding some of this enabled rules like:

026-02-03 00:02:25,192     INFO apscheduler.executors.default Running job "Rule: Linux Crypto Mining Pool Connections -- a46c93b7-55ed-4d27-a41b-c259456c4746 (trigger: interval[0:03:00], next run at: 2026-02-03 00:05:29 UTC)" (scheduled at 2026-02-03 00:02:25.192357+00:00)
2026-02-03 00:02:25,194  WARNING        elasticsearch POST https://seconion:9200/.ds-logs-*/_eql/search?ignore_unavailable=true [status:400 request:0.002s]
2026-02-03 00:02:25,195    ERROR           elastalert Error running query: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1:66: Unknown column [DestinationHostname]')
2026-02-03 00:02:25,202     INFO           elastalert Ran Linux Crypto Mining Pool Connections -- a46c93b7-55ed-4d27-a41b-c259456c4746 from 2026-02-02 23:52 UTC to 2026-02-03 00:02 UTC: 0 query hits (0 already seen), 0 matches, 0 alerts sent
2026-02-03 00:02:25,202     INFO           elastalert Linux Crypto Mining Pool Connections -- a46c93b7-55ed-4d27-a41b-c259456c4746 range 600
2026-02-03 00:02:25,202     INFO apscheduler.executors.default Job "Rule: Linux Crypto Mining Pool Connections -- a46c93b7-55ed-4d27-a41b-c259456c4746 (trigger: interval[0:03:00], next run at: 2026-02-03 00:05:29 UTC)" executed successfully

And if I check for that rule in "convert" it gives me the following error in kibana:

{
  "error": {
    "root_cause": [
      {
        "type": "verification_exception",
        "reason": """Found 1 problem
line 2:67: Unknown column [DestinationHostname]"""
      }
    ],
    "type": "verification_exception",
    "reason": """Found 1 problem
line 2:67: Unknown column [DestinationHostname]"""
  },
  "status": 400
}

Another example error is :

2026-02-03 00:02:36,307     INFO apscheduler.executors.default Running job "Rule: Credentials In Files - Linux -- df3fcaea-2715-4214-99c5-0056ea59eb35 (trigger: interval[0:03:00], next run at: 2026-02-03 00:05:39 UTC)" (scheduled at 2026-02-03 00:02:36.307356+00:00)
2026-02-03 00:02:36,309  WARNING        elasticsearch POST https://seconion:9200/.ds-logs-*/_eql/search?ignore_unavailable=true [status:400 request:0.002s]
2026-02-03 00:02:36,309    ERROR           elastalert Error running query: RequestError(400, 'verification_exception', 'Found 2 problems\nline 1:11: Unknown column [type]\nline 1:30: first argument of ["grep" and "password"] must be [boolean], found value ["grep"] type [keyword]')
2026-02-03 00:02:36,314     INFO           elastalert Ran Credentials In Files - Linux -- df3fcaea-2715-4214-99c5-0056ea59eb35 from 2026-02-02 23:52 UTC to 2026-02-03 00:02 UTC: 0 query hits (0 already seen), 0 matches, 0 alerts sent
2026-02-03 00:02:36,314     INFO           elastalert Credentials In Files - Linux -- df3fcaea-2715-4214-99c5-0056ea59eb35 range 600
2026-02-03 00:02:36,314     INFO apscheduler.executors.default Job "Rule: Credentials In Files - Linux -- df3fcaea-2715-4214-99c5-0056ea59eb35 (trigger: interval[0:03:00], next run at: 2026-02-03 00:05:39 UTC)" executed successfully

Which convert and test in kibana gives:

{
  "error": {
    "root_cause": [
      {
        "type": "verification_exception",
        "reason": """Found 2 problems
line 2:12: Unknown column [type]
line 2:31: first argument of ["grep" and "password"] must be [boolean], found value ["grep"] type [keyword]"""
      }
    ],
    "type": "verification_exception",
    "reason": """Found 2 problems
line 2:12: Unknown column [type]
line 2:31: first argument of ["grep" and "password"] must be [boolean], found value ["grep"] type [keyword]"""
  },
  "status": 400
}

So I guess that there are a lot predefined sigma core rules that makes no sense and have to test each one before enabling

Thanks!

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

Did you synchronize Elastalert after you enabled them?

[cm-ops]

When you make changes to rules in Detections, you would need to run a synchronization to apply the changes to the rules.

For the disabled rules it looks like data type mismatches causing the errors.

[gustavoberman]

When you make changes to rules in Detections, you would need to run a synchronization to apply the changes to the rules.

Sadly, this do not work for me.

I disabled 3 specific sigma rules, then I clicked on options->Elastalert->Full Update. Waited for for the process to finish, then refresh to look for those 3 specific sigma rules either enabled/disabled and they are not there.

[gustavoberman]

Next day: the rules are there again.

[cm-ops]

When you disable the rule and you don't see them in Detections, check the so-detection index and see if they are in there. An example search in Kibana > Dev Tools is below (change the publicID to the ID of the rule you are looking for):

GET so-detection/_search
{
    "query": {
        "match": {
          "so_detection.publicId": "c0d3734d-330f-4a03-aae2-65dacc6a8222"
        }
    }
}

Do you see it in the index? When you disable, also check the /opt/so/log/soc/sensoroni-server.log for that action.

Seems like if it is removed, when the rules update during it's normal 24-hour update it reimports them.

[gustavoberman]

After testing some more, the issue seems to be resolved.
I do not know if it was some update in between, but now enable/disable works just fine.