Skip to content

TI Map Domain Entity to SecurityAlert creates infinite feedback loop #13860

@LindenSec

Description

@LindenSec

Bug: TI Map Domain Entity to SecurityAlert creates infinite feedback loop

Affected Templates

  • TI map Domain entity to SecurityAlert (df88b403-1cb9-49ea-a43d-b6613051cf7f)
  • Likely also affects: TI map IP, URL, Email, and FileHash entity to SecurityAlert (same query pattern)
  • Source: Azure-Sentinel GitHub

Description

The "TI map Domain entity to SecurityAlert" analytic rule creates an infinite alert feedback loop. When the rule matches a domain from a ThreatIntelIndicator against a SecurityAlert, the resulting TI Map alert is written back to the SecurityAlert table with the matched domain embedded in its Entities field. On the next scheduled run (1 hour later), the rule picks up its own previous output as a new match, generating another alert. This repeats indefinitely, producing one duplicate alert per hour for as long as the TI indicator remains active.

Root Cause

The SecurityAlerts variable in the rule query has no filter to exclude alerts generated by Sentinel's own analytic rules:

let SecurityAlerts = SecurityAlert
| where TimeGenerated > ago(dt_lookBack)
| extend domain = todynamic(dynamic_to_json(extract_all(...)))
...

The TI Map alert is written to SecurityAlert with ProviderName == "ASI Scheduled Alerts" and the matched domain is included in the Entities JSON. Since the query extracts domains from Entities using a broad regex, it re-extracts the same domain from its own output and matches it against the TI indicator again.

Steps to Reproduce

  1. Deploy the "TI map Domain entity to SecurityAlert" rule as-is from the Content Hub / GitHub template
  2. Have an active domain indicator in ThreatIntelIndicators (e.g., maliciousdomain.com)
  3. Wait for any SecurityAlert to contain that domain in its Entities (e.g., from a Defender XDR detection or another Sentinel rule)
  4. The TI Map rule fires and creates a new alert
  5. On the next hourly run, the rule picks up its own alert from step 4 and fires again
  6. This continues every hour indefinitely

Observed Impact

  • One duplicate alert generated per hour per matched domain, indefinitely
  • In our environment, a single domain accumulated 2000+ alerts before the loop was identified
  • Alert fatigue — SOC analysts see a wall of identical TI Map alerts with no new underlying activity
  • Incident queue pollution when auto-incident-creation is enabled
  • Misleading entity alert counts in investigation timelines

Evidence

Screenshot showing hourly TI Map alerts with no underlying activity:

Image

All alerts reference the same domain. No corresponding activity found in DeviceNetworkEvents, DnsEvents, CommonSecurityLog, or EmailUrlInfo.

Suggested Fix

Add a filter to exclude TI Map alerts from the input SecurityAlerts set to break the self-referencing loop:

let SecurityAlerts = SecurityAlert
| where TimeGenerated > ago(dt_lookBack)
| where AlertName !has "TI Map"

This preserves matching against all legitimate alert sources (Defender XDR, Defender for Cloud, other Sentinel analytic rules) while preventing TI Map rules from consuming their own output.

Kind regards,
Damien - LindenSec

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions