Acknowledgements
Describe the bug
UTMStack 11.2.13 appears to introduce a widespread detection-rule regression caused by the actionResult normalization changes from PR #2366:
PR #2366 normalizes vendor-specific action/result strings into canonical values such as:
success
failed
denied
blocked
accepted
However, a number of existing detection rules still compare actionResult against the previous vendor-specific values. This means events can be successfully ingested and normalized, while the associated detection rule silently stops matching.
A confirmed example is the rule: Microsoft 365 New Inbox Rule Created
The Microsoft 365 filter in 11.2.13 now performs:
- add:
function: 'string'
params:
key: actionResult
value: 'success'
where: oneOf("log.ResultStatus", ["Succeeded", "Success", "Successful", "PartiallySucceeded", "True"])
- add:
function: 'string'
params:
key: actionResult
value: 'failed'
where: oneOf("log.ResultStatus", ["Failure", "Failed"])
However the corresponding rule still uses
where: |
equals("log.Workload", "Exchange") &&
equals("action", "New-InboxRule") &&
oneOf("actionResult", ["Success","Succeeded","PartiallySucceeded","True"])
Regression Issue
Expected Behavior
Creation of a new test inbox rule fires the related alerting rule.
Current Behavior
Rule fails to fire due to mismatch of resultStatus field.
Reproduction Steps
- Install or upgrade UTMStack to version 11.2.13.
- Configure Microsoft 365 audit log ingestion.
- Verify that Microsoft 365 events are being received normally.
- Create a new Inbox rule in a monitored Microsoft 365 / Exchange Online mailbox.
Possible Solution
Update entire ruleset to use normalized actionResult values introduced in PR #2366
Additional Information/Context
No response
UTMStack Version
11.2.13
Operating System and version
Ubuntu 24.4
Hypervisor and Version | Server Vendor and Model
ESX
Browser and version
Microsoft Edge
Acknowledgements
Describe the bug
UTMStack 11.2.13 appears to introduce a widespread detection-rule regression caused by the
actionResultnormalization changes from PR #2366:PR #2366 normalizes vendor-specific action/result strings into canonical values such as:
successfaileddeniedblockedacceptedHowever, a number of existing detection rules still compare
actionResultagainst the previous vendor-specific values. This means events can be successfully ingested and normalized, while the associated detection rule silently stops matching.A confirmed example is the rule:
Microsoft 365 New Inbox Rule CreatedThe Microsoft 365 filter in 11.2.13 now performs:
However the corresponding rule still uses
Regression Issue
Expected Behavior
Creation of a new test inbox rule fires the related alerting rule.
Current Behavior
Rule fails to fire due to mismatch of resultStatus field.
Reproduction Steps
Possible Solution
Update entire ruleset to use normalized actionResult values introduced in PR #2366
Additional Information/Context
No response
UTMStack Version
11.2.13
Operating System and version
Ubuntu 24.4
Hypervisor and Version | Server Vendor and Model
ESX
Browser and version
Microsoft Edge