请教：无相似架构的表关联方法及Defender狩猎查询修正

原查询的核心错误 #

你当前的join条件完全不成立：

• $left.AlertInfo是表名不是字段，AlertInfo表中存储警报ID的字段是AlertId
• Url（邮件点击的链接）和AlertId没有直接关联逻辑，强行匹配只会得到错误结果

正确的关联逻辑 #

要实现需求，需要找到AlertInfo（EDR警报）和邮件点击事件（EmailEvents/UrlClickEvents）的共有关联维度，常见的两种可行方案：

方案1：通过用户UPN关联（警报涉及的用户存在允许点击的入站邮件） #

如果EDR警报是针对某个用户触发的，可通过用户的AccountUpn关联该用户的邮件点击行为：

// 第一步：筛选符合条件的入站邮件允许点击事件
let ClickURL = EmailEvents
| where EmailDirection == "Inbound"
| join (
    UrlClickEvents 
    | where Workload == "Email"
    | where ActionType == "ClickAllowed" or IsClickedThrough != "0"
) on NetworkMessageId
| project Timestamp, SenderFromAddress, AccountUpn, Url, UrlChain, Subject, NetworkMessageId;

// 第二步：筛选EDR警报，提取关联的用户UPN，再关联邮件点击事件
AlertInfo
| where DetectionSource == "EDR"
// 从警报的Entities字段中提取用户UPN（Defender警报会将涉及实体存在Entities数组中）
| extend AccountUpn = tostring(parse_json(Entities)[0].UserPrincipalName)
| project AlertId, AlertName, Severity, AccountUpn
// 内连接：仅保留警报用户同时有允许点击记录的结果
| join kind=inner ClickURL on AccountUpn

方案2：通过警报关联的事件ID/URL直接匹配 #

如果EDR警报是由邮件URL点击直接触发的，可通过警报的RelatedEventIds或Entities中的URL进行关联：

let ClickURL = EmailEvents
| where EmailDirection == "Inbound"
| join (
    UrlClickEvents 
    | where Workload == "Email"
    | where ActionType == "ClickAllowed" or IsClickedThrough != "0"
) on NetworkMessageId
| project Timestamp, SenderFromAddress, AccountUpn, Url, UrlChain, Subject, NetworkMessageId, EventId = tostring(EventId);

AlertInfo
| where DetectionSource == "EDR"
// 提取警报关联的事件ID列表
| extend RelatedEventIds = parse_json(RelatedEventIds)
// 将事件ID数组拆分成单行，便于关联
| mv-expand RelatedEventIds to typeof(string)
| project AlertId, AlertName, Severity, RelatedEventIds
// 通过事件ID关联邮件点击事件
| join kind=inner ClickURL on $left.RelatedEventIds == $right.EventId

关键说明 #

• 若要通过AlertId直接关联，需确保目标表（如UrlClickEvents）中存在AlertId字段——但默认情况下UrlClickEvents不存储AlertId，必须通过中间实体（用户、事件ID、URL）关联
• 可根据实际警报的内容调整Entities字段的提取逻辑（比如有些警报的用户实体可能不是第一个元素，可添加过滤条件）

内容的提问来源于stack exchange，提问作者sl0th