Forum Discussion
Duplicate incidents created by NRT rule
I'm hoping this is the right place to post this (if not please let me know / delete)
I have an NRT rule that started creating multiple incidents for a single Azure AD PIM event. The rule has been running with no issues for several months, but just today has generated 15-20 alerts each time one of our admins activated a PIM role assignment.
Here's a screenshot of incidents created in Sentinel
If I run the rule logic manually, I only get 1 event returned for each role activation (with 2 PIM activations in the last 24 hours)
I'd appreciate any help in figuring out what's going on. I'm up to about 75 new Incidents all tied to these two events.
Disabling and enabling the rule worked for me.
9 Replies
- After contacting Microsoft support regarding the issue, they stated that a HotFix was applied yesterday, 12-Jan to resolve the issue with NRTs.
"Resolution: Multiple Customers had a similar issue and was escalated to Product Team. Product Team has deployed a hotfix as of 12/01/2023 and this bug has been mitigated. We have cross-checked by creating a mock event and confirmed that the bug has been resolved." Disabling and enabling the rule worked for me.
- This did the trick for me too. Thanks!
Also experiencing the same thing with NRT MFA Rejected by User and NRT New access credential added to Application or Service Principal. Seems to have started since the 3rd Jan for us, there can be one or two entries in Log Analytics but there will be an alert firing every minute for over an hour. As a temp solution we added grouping for 12 hours because last week we had ~150 incidents generate for one event. Tried looking for some kind of change that may have occured in github but not seeing anything obvious. Why are NRTs suddenly firing repeat alerts on the same historical logs?
Note the timeframe vs created time, this is because the logs are the same.
I had the same issue, see https://github.com/Azure/Azure-Sentinel/issues/7062
Same issue over here, over 50 duplicated incidents from built-in rule NRT New access credential added to Application or Service Principal
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Azure%20Active%20Directory/Analytic%20Rules/NRT_NewAppOrServicePrincipalCredential.yaml
Disabling and re-enabling the NRT rule seems to resolve the loop as its occurring.- We are now experiening this issue with an NRT rule that was behaving normally, but now is creating multiple incidents for the same alert. Running the Analytics rule manually works as expected. This seems to have started the first week of January.
- Can you post the KQL used in the NRT rule?
-jmn-Here's the Kusto
// PIM info let pimInfo = AuditLogs | where Category =~ "RoleManagement" | where AADOperationType in ("CreateRequestRoleActivation")//,"ActivateRole") | where ActivityDisplayName has_any ("Add eligible member to role", "Add member to role") | extend InitiatingApp = tostring(parse_json(tostring(InitiatedBy.app)).displayName) | extend Initiator = iif(isnotempty(InitiatingApp), InitiatingApp, tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)) | extend Target = tostring(TargetResources.userPrincipalName) | extend strTime = tostring(TimeGenerated); let pimDetails = AuditLogs | where Category =~ "RoleManagement" | where AADOperationType in ("CreateRequestRoleActivation")//,"ActivateRole") | where ActivityDisplayName has_any ("Add eligible member to role", "Add member to role") | mv-expand AdditionalDetails | extend Key = tostring(AdditionalDetails.key), Value = tostring(AdditionalDetails.value) | extend p = pack(Key,Value) | summarize bag = make_bag(p) by TimeGenerated | evaluate bag_unpack(bag) : (TimeGenerated:datetime, ExpirationTime:datetime, ipaddr:string, Justification:string, oid:string, RoleDefinitionOriginId:string, RoleDefinitionOriginType :string, StartTime:datetime, TemplateId:string, tid:string, wids:string); //| extend strTime = tostring(); //union isfuzzy=true roleAssign, pimDetails let pimAll = pimInfo | join kind = leftouter pimDetails on TimeGenerated; pimAll
