Google SecOps (Chronicle) Curated Detections: Flaw Analysis & Tuning

This repository documents architectural design flaws, logic discrepancies, and tuning strategies for native Google SecOps (Chronicle) Curated Detections.

While Google Threat Intelligence (GTIG) provides exceptional conceptual threat coverage (such as tracking APT29/BRICKSTORM campaigns), raw YARA-L implementations of curated rules sometimes suffer from implementation oversights, such as grouping logic contradictions and hardcoded threshold variables. In real-world enterprise environments, this frequently leads to massive alert fatigue.

This project analyzes why native rules break or flood the SOC, and shares optimized Custom Rules and patches to resolve these issues.

Upstream Tracking & Vendor Feedback

• Status: Logic gaps and rule telemetry feedback have been acknowledged by Google's Detection Engineering / Product team, initiating a Google-internal rule lifecycle review workstream.

---

📑 Table of Contents

1. O365 Suite Alerting Failure for BRICKSTORM / APT29
   • Flaw 1: Grouping Logic Contradiction
   • Flaw 2: Outlook Mobile Public Client Oversight
   • Flaw 3: Shared Mailbox Collision
   • Tuned YARA-L Solutions
2. O365 Teams: External Impersonation Attempt
   • Flaw 1: Adversary vs. Target Inversion
   • Flaw 2: Erroneous Match Grouping Key
   • Tuned YARA-L Solution
3. UEBA: Anomalous Auth Attempts Total
   • Hardcoding Flaw & Alert Fatigue
   • Tuning Recommendations

---

1. O365 Suite Alerting Failure for BRICKSTORM / APT29

Google released a suite of rules to detect bulk email exfiltration from Microsoft 365 Exchange Online by compromised Service Principals (techniques heavily used by APT29/Midnight Blizzard).

The affected curated rules are:

• 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

❌ Core Flaws in Google's Logic

This suite of rules contains systemic logic mismatches between the stated objective and the YARA-L implementation, likely due to code reuse across the rule pack. The rules fail to properly distinguish between automated Service Principals and standard human activity, resulting in alerts that trigger on normal employee behavior.

Flaw 1: Grouping Logic Contradiction

Despite the rule description explicitly stating: "Detects a Service Principal with a single O365 session ID...", the YARA-L match section of the "Multiple User Agents" rule groups by $application_id instead of the session ID ($session_id). This completely contradicts the rule's stated objective.

• Impact: Unrelated employee sessions sharing the same enterprise App ID and same shared mail are merged across the entire tenant over a 3-hour window. This triggers false positives whenever any two distinct users authenticate via different user agents (e.g., iPhone vs. Android) under the same application, failing to isolate individual token hijacking.

Flaw 2: Outlook Mobile Public Client Oversight

The rules track anomalous behavioral patterns (changing IPs, ASNs, or User-Agents) tied to a specific ClientAppId. While Google includes an exclusion regex for several native Microsoft applications, they inexplicably omitted the most ubiquitous human mobile client: the Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Impact: Without filtering out this Public Client, legitimate employees reading shared mailboxes from their smartphones who move between networks (e.g., switching from Wi-Fi to 4G) inherently trigger the Multiple ASNs alerts. Different employees using iOS and Android to check the same departmental mailbox trigger the Multiple User Agents alert.

Flaw 3: Shared Mailbox Collision

To identify backend service accounts, Google's logic relies on this condition: $e.principal.user.userid != $e.target.user.userid

• Impact: This condition simply checks if the actor ID is different from the target mailbox owner. While true for automated service principals, it is also standard behavior for human employees accessing shared or departmental mailboxes (e.g., an operator opening [email protected]). This design flaw generates massive noise on standard operational human traffic.

---

✅ Tuned YARA-L Solutions for O365 Rules

To fix these design flaws, you have two options depending on your operational needs:

Option 1: Native SIEM Exclusions (Quick Fix) You do not necessarily have to disable the rules or write custom code. You can simply create an Exclusion directly within the Google SecOps SIEM UI. Just add an exclusion targeting the ClientAppId of Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) and your authorized backup applications (e.g., Keepit). This immediately stops the false positive flood while keeping Google's curated rules active.

Option 2: Deploy Custom Rules (Architectural Fix) If you want to completely fix the underlying grouping logic flaws (such as the $application_id mismatch), you must disable the Curated Detections and deploy Custom Rules. The fixes involve:

1. Explicitly whitelisting Outlook Mobile (27922004-...).
2. Whitelisting known authorized Enterprise Backup Apps (e.g., Keepit).
3. Fixing the match sections to properly aggregate by session.

Tuned Rule 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
}

Tuned Rule 2: Multiple Mailboxes Accessed

(Same logic, but in the exclusions ensure you whitelist your authorized backup solutions like Keepit (a7cd46df...) alongside Outlook Mobile).