Google SecOps (Chronicle) 精选检测：缺陷分析与调优

本仓库记录了原生 Google SecOps (Chronicle) 精选检测 的架构设计缺陷、逻辑不一致性以及调优策略。

尽管 Google 威胁情报（GTIG）提供了卓越的概念性威胁覆盖（例如追踪 APT29/BRICKSTORM 攻击活动），但精选规则的原始 YARA-L 实现有时会存在实现疏漏，例如分组逻辑矛盾和硬编码阈值变量。在真实的企业环境中，这常常导致大量的告警疲劳。

本项目分析了原生规则为何会失效或淹没 SOC，并分享了用于解决这些问题的优化自定义规则和补丁。

📑 目录

1. O365 套件针对 BRICKSTORM / APT29 的告警失效
   • 缺陷 1：分组逻辑矛盾
   • 缺陷 2：Outlook 移动公开客户端被忽略
   • 缺陷 3：共享邮箱冲突
   • 调优后的 YARA-L 解决方案
2. UEBA：异常身份验证尝试总数
   • 硬编码缺陷与告警疲劳
   • 调优建议

1. O365 套件针对 BRICKSTORM / APT29 的告警失效

Google 发布了一套规则，用于检测失陷的服务主体从 Microsoft 365 Exchange Online 批量外发电子邮件（该技术被 APT29/Midnight Blizzard 大量使用）。

受影响的精选规则包括：

• O365 Mailbox Access by Service Principal with Multiple User Agents
• O365 Multiple Mailboxes Accessed by Service Principal
• O365 Mailbox Access by Service Principal from Multiple ASNs
• O365 Multiple Mailboxes Accessed via Microsoft Graph API

❌ Google 逻辑中的核心缺陷

这套规则在既定目标与 YARA-L 实现之间存在系统性的逻辑错配，很可能是规则包中代码复用的结果。这些规则未能正确区分自动化服务主体与正常的人类活动，导致告警会在普通员工行为上触发。

缺陷 1：分组逻辑矛盾

尽管规则描述中明确说明：“检测使用单一 O365 会话 ID 的服务主体……”，但“Multiple User Agents”规则的 YARA-L match 部分却按 $application_id 而不是会话 ID（$session_id）进行分组。这与规则所述目标完全矛盾，仅仅因为使用相同应用程序，就会在 3 小时窗口内聚合不相关的人类登录行为。

缺陷 2：Outlook 移动公开客户端被忽略

这些规则会追踪与特定 ClientAppId 相关的异常行为模式（变化的 IP、ASN 或 User-Agent）。虽然 Google 为多个原生 Microsoft 应用程序包含了排除正则表达式，但他们却莫名其妙地遗漏了最普遍的人类移动客户端：Microsoft Outlook 移动应用（27922004-5251-4030-b22d-91ecd9a37ea4）。

• 影响： 如果不将此公开客户端过滤掉，合法员工在智能手机上读取共享邮箱并在网络之间切换（例如从 Wi-Fi 切换到 4G）时，必然会触发 Multiple ASNs 和 Multiple IPs 告警。不同员工使用 iOS 和 Android 查看同一个部门邮箱时，也会触发 Multiple User Agents 告警。

缺陷 3：共享邮箱冲突

为了识别后端服务账户，Google 的逻辑依赖以下条件： $e.principal.user.userid != $e.target.user.userid

• 影响： 该条件仅检查操作者 ID 是否与目标邮箱所有者不同。虽然这对自动化服务主体成立，但对于访问共享邮箱或部门邮箱的人类员工（例如操作人员打开 [email protected]）来说也是标准行为。这一设计缺陷会在正常的操作人员流量上产生大量噪声。

✅ 面向 O365 规则的调优 YARA-L 解决方案

要修复这些设计缺陷，你可以根据运营需求选择以下两种方案：

方案 1：原生 SIEM 排除（快速修复） 你不一定需要禁用规则或编写自定义代码。你可以直接在 Google SecOps SIEM 界面中创建一个排除项。只需添加一个针对 Outlook Mobile 的 ClientAppId（27922004-5251-4030-b22d-91ecd9a37ea4）以及你授权的备份应用程序（例如 Keepit）的排除项。这会在保持 Google 精选规则处于激活状态的同时，立即阻止误报洪流。

方案 2：部署自定义规则（架构级修复） 如果你想彻底修复底层分组逻辑缺陷（例如 $application_id 不匹配），则必须禁用精选检测并部署自定义规则。修复措施包括：

1. 显式将 Outlook Mobile（27922004-...）加入白名单。
2. 将已知授权的企业备份应用（例如 Keepit）加入白名单。
3. 修复 match 部分，使其按会话正确聚合。

调优规则 1：Multiple User Agents

rule custom_ttp_o365_mailbox_access_by_service_principal_with_multiple_uas {
  meta:
    rule_name = "[CUSTOM] O365 Mailbox Access by Service Principal with Multiple User Agents"
    description = "Detects a Service Principal with a single O365 session ID accessing O365 mailboxes with multiple user agents. Tuned to fix grouping logic and exclude Outlook Mobile (Public Client) human traffic."
    severity = "Low"
    tactic = "TA0009"
    technique = "T1114.002"

  events:
    $e.metadata.log_type = "OFFICE_365"
    $e.metadata.product_event_type = "MailItemsAccessed" nocase
    $e.target.application = "Exchange"
    $e.security_result.detection_fields["RecordType"] = /^(2|50)$/
    
    // Extract actual Session ID and App ID
    $session_id = $e.network.session_id
    $application_id = $e.additional.fields["ClientAppId"]
    
    $e.principal.user.userid !=$e.target.user.userid
    
    ( 
      $e.network.http.user_agent = /AppId/ nocase or $e.additional.fields["ClientAppId"] = /./
    )
    
    // EXCLUSIONS: Added Outlook Mobile + Standard Google Exclusions
    $e.additional.fields["ClientAppId"] != /^(27922004-5251-4030-b22d-91ecd9a37ea4|bea75f7a-2505-46e8-9bf6-d3f7da9c9da7|b52893c8-bc2e-47fc-918b-77022b299bbc|...)$/ nocase

  match:
    // Group by both App AND Session to isolate the specific token lifecycle
    $application_id,$session_id over 3h

  outcome:
    $vendor_name = "Microsoft"
    $product_name = "Office 365"
    $source_ua_dc = count_distinct($e.network.http.user_agent)
    $client_app_id = array_distinct($e.additional.fields["ClientAppId"])

  condition:
    // Triggers if the SAME session rotates 2+ User Agents
    $e and $source_ua_dc >= 2
}

调优规则 2：Multiple Mailboxes Accessed

（逻辑相同，但在排除规则中，请确保将你授权的备份解决方案（如 Keepit（a7cd46df...））与 Outlook Mobile 一起加入白名单。）

调优规则 3：Multiple ASNs

（与 User Agents 规则不同，Google 在这条规则中确实正确地按 $session_id 进行了分组。但是，它仍然缺少 Outlook Mobile 排除项。请遵循上述相同的排除逻辑，并保留 $source_asn_dc >= 2 条件。）

调优规则 4：Multiple Mailboxes Accessed via Microsoft Graph API

（逻辑相同。请确保在 events 块末尾的排除正则表达式中追加授权的备份应用程序，如 Keepit（a7cd46df...）。）

2. UEBA：异常身份验证尝试总数

规则： Anomalous Auth Attempts Total by Principal Hostname and Target User ID

（注：UEBA 代表“用户和实体行为分析”。这些规则不使用静态签名，而是依靠数学算法来建立“正常”行为基线，并在统计偏差时发出告警。）

❌ 硬编码缺陷与告警疲劳

该 UEBA 规则尝试通过计算 30 天的历史平均值和标准差来检测异常身份验证峰值。

• 告警疲劳： 在我们的生产环境中，这条精选规则产生了极低的真阳性率（约 0.08%，2324 条告警中只有 2 条可处理的工单）。它本质上就是纯粹的噪声。
• 代码缺陷： Google 在 outcome 块的开头声明了一个变量 $num_stddevs_away = max(2)。然而，在 $historical_threshold 计算中，Google 开发者硬编码了值 2 而没有使用该变量。这个编程错误使分析师无法在不完全克隆并重写 YARA-L 逻辑的情况下，通过 UI 或继承变量轻松覆盖灵敏度。

✅ UEBA 调优建议

真实环境测试表明，仅调整统计阈值（例如将 $num_stddevs_away 提高到 3 或 4、将 $coefficient_of_variation_threshold 从 0.1 降低到 0.05，或把 $observation_threshold 增加到 15）是不够的：它只会将每周告警数从 710 条降至 111 条，对分析师团队来说仍然过于嘈杂。

• 推荐方法： 对于 SecOps 企业租户，禁用“Failed Authentications by Device”的 Broad 规则集告警，并严格依赖 Precise 告警通道。这种结构性缓解措施是阻止告警洪流的唯一有效方法。
• 备选自定义方法： 如果你必须让其保持激活状态，请将该规则克隆为自定义规则，修复 $historical_threshold 中硬编码的 2 以匹配你自己的 $num_stddevs_away 变量，并实施更严格的基线系数。

免责声明：这些调优基于真实世界的事件响应和 SIEM 工程经验。在部署到生产环境之前，请务必在您的特定环境中测试 YARA-L 规则。