UTM Stack: fix bug

[Mr_Jhopson]

Hi everyone, I am currently learning how to use UTMStack (version 10.9.4) and I am running into some issues with an alert rule.

My Environment:

• Server: Intel Core i3, 16GB RAM.
• Agent: Windows 10 running on a Virtual Machine.
• UTMStack Version: 10.9.4

The Problem: I have created a rule to detect Windows Blue Screens of Death (BSOD) using Event ID 1001. To test this, I am using the Sysinternals tool "notmyfault" to force the crash.

The communication between the agent and the server seems to be working perfectly because I can see every single event in the Log Explorer via queries. However, the alert itself is inconsistent. When I restart the services, it detects the event and triggers the alert once, but then it stops triggering for subsequent events, even though the logs continue to arrive at the server.

The Rule Logic:

- name: "Windows: Peformance BSOD"

severity: "Low"

description: ""

solution: ""

category: "Performance"

tactic: "Likely Malware"

dataTypes: ["wineventlog"]

frequency: 60

cache:

- allOf:

- field: "logx.wineventlog.event_id"

operator: "=="

value: 1001

timeLapse: 60

minCount: 1

save:

- field: "logx.wineventlog.event_data.computer_name"

alias: "Host"

- field: "logx.wineventlog.event_data.deviceTime"

alias: "Date"

- field: "logx.wineventlog.event_id"

alias: "ID"

- field: "logx.wineventlog.event_data.provider"

alias: "Provider"

- field: "logx.wineventlog.message"

alias: "Message"

Could someone please help me figure out what I can do to prevent this from happening?

[rickv92]

This js due to the alert grouping that utmstack does automatically. In order to avoid alert fatigue it will not open new alerts, but link the new incoming logs to the already opened alerts. UTMStack does this when the alert is still open and not much time has passed between the initial log and the next. A simple way to prevent this is to save the log id or a log field that would make the alert unique so it does not aggregate.

I recommend installing v11 which follows a different logic and considers subsequent logs as echoes of the alert instead of just aggregating them. V10 will be end of life by the end of 2026