Enabling all Sigma rules causes ElastAlert Rules Mismatch in Detections

[Zer0-cyber-web]

Version

3.1.0

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

12

RAM

64

Storage for /

256Gb

Storage for /nsm

16T

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Recently I enabled all Sigma rules in Detections. And after enablement - I have constant ElastAlert "Rule Mismatch" error with a lot of "soc.fields.enabledButNotDeployedCount" (1238 out of 1854 Sigma rules).
How can I get rid of those mismatches? I made full SO reboot already. But Mismatch is still present.

One of mismatch messages:

{"fields":{"deployedButNotEnabled":[],"deployedButNotEnabledCount":0,"detectionEngine":"elastalert","enabledButNotDeployed":["055fb148-60f8-462d-ad16-26926ce050f1"],"enabledButNotDeployedCount":1,"intCheckId":"6929cd78-4f76-43ff-90b5-0e0f55949d9d"},"level":"warn","timestamp":"2026-06-17T09:06:07.665021311Z","message":"integrity check failed"}

Any help would be appreciated!

Guidelines

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

[Zer0-cyber-web]

The problem was in Sigma rule "AWS User Login Profile Was Modified" - it has some errors.

Details

title: AWS User Login Profile Was Modified
id: 055fb148-60f8-462d-ad16-26926ce050f1
status: test
description: |
Detects activity when someone is changing passwords on behalf of other users.
An attacker with the "iam:UpdateLoginProfile" permission on other users can change the password used to login to the AWS console on any user that already has a login profile setup.
references:
- https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation
author: toffeebr33k
date: 2021-08-09
modified: 2024-04-26
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1098
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: 'iam.amazonaws.com'
eventName: 'UpdateLoginProfile'
filter_main_user_identity:
userIdentity.arn|fieldref: requestParameters.userName
condition: selection and not 1 of filter_main_*
falsepositives:
- Legitimate user account administration
level: high

After I disabled this rule and restarted so-soc

docker restart so-soc

Mismatch is gone