Google SecOps (Chronicle) Curated Detections: Schwachstellenanalyse & Tuning

Dieses Repository dokumentiert architektonische Designfehler, Logikdiskrepanzen und Tuning-Strategien für native Google SecOps (Chronicle) Curated Detections.

Während Google Threat Intelligence (GTIG) eine außergewöhnliche konzeptionelle Bedrohungsabdeckung bietet (etwa die Verfolgung von APT29/BRICKSTORM-Kampagnen), leiden die rohen YARA-L-Implementierungen der kuratierten Regeln mitunter unter Implementierungsübersehen wie Gruppierungslogik-Widersprüchen und fest codierten Schwellenwertvariablen. In realen Unternehmensumgebungen führt dies häufig zu massiver Alert-Müdigkeit.

Dieses Projekt analysiert, warum native Regeln brechen oder das SOC überfluten, und teilt optimierte Custom Rules und Patches zur Behebung dieser Probleme.

Upstream-Tracking & Hersteller-Feedback

• Status: Logiklücken und Regel-Telemetrie-Feedback wurden vom Detection Engineering / Product-Team von Google bestätigt, wodurch ein Google-interner Workstream zur Überprüfung des Regel-Lebenszyklus angestoßen wurde.

---

📑 Inhaltsverzeichnis

1. O365 Suite-Alarmierungsfehler für BRICKSTORM / APT29
   • Fehler 1: Widerspruch in der Gruppierungslogik
   • Fehler 2: Übersehen des öffentlichen Outlook Mobile-Clients
   • Fehler 3: Kollision bei gemeinsam genutzten Postfächern
   • Optimierte YARA-L-Lösungen
2. O365 Teams: Versuch der externen Identitätsnachahmung
   • Fehler 1: Umkehrung von Angreifer und Ziel
   • Fehler 2: Fehlerhafter Match-Gruppierungsschlüssel
   • Optimierte YARA-L-Lösung
3. UEBA: Anomale Authentifizierungsversuche gesamt
   • Hardcoding-Fehler & Alert-Müdigkeit
   • Tuning-Empfehlungen

---

1. O365 Suite-Alarmierungsfehler für BRICKSTORM / APT29

Google veröffentlichte eine Reihe von Regeln zur Erkennung von Massen-E-Mail-Exfiltration aus Microsoft 365 Exchange Online durch kompromittierte Service Principals (Techniken, die von APT29/Midnight Blizzard stark genutzt werden).

Die betroffenen kuratierten Regeln sind:

• 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

❌ Zentrale Fehler in Googles Logik

Diese Regelreihe enthält systemische Logikdiskrepanzen zwischen dem erklärten Ziel und der YARA-L-Implementierung, wahrscheinlich aufgrund von Code-Wiederverwendung innerhalb des Regelpakets. Die Regeln unterscheiden nicht ordnungsgemäß zwischen automatisierten Service Principals und standardmäßiger menschlicher Aktivität, was dazu führt, dass Alarme bei normalem Mitarbeiterverhalten ausgelöst werden.

Fehler 1: Widerspruch in der Gruppierungslogik

Obwohl die Regelbeschreibung ausdrücklich angibt: „Detects a Service Principal with a single O365 session ID...", gruppiert der YARA-L-match-Abschnitt der Regel „Multiple User Agents" nach $application_id statt nach der Session-ID ($session_id). Dies widerspricht vollständig dem erklärten Ziel der Regel.

• Auswirkung: Nicht zusammenhängende Mitarbeitersitzungen, die dieselbe Enterprise-App-ID und dasselbe gemeinsam genutzte Postfach teilen, werden über den gesamten Tenant hinweg in einem 3-Stunden-Fenster zusammengeführt. Dies löst Fehlalarme aus, sobald sich zwei verschiedene Benutzer über unterschiedliche User Agents (z. B. iPhone vs. Android) unter derselben Anwendung authentifizieren, und es gelingt nicht, einzelne Token-Hijackings zu isolieren.

Fehler 2: Übersehen des öffentlichen Outlook Mobile-Clients

Die Regeln verfolgen anomale Verhaltensmuster (wechselnde IPs, ASNs oder User-Agents), die an eine bestimmte ClientAppId gebunden sind. Während Google einen Ausschluss-Regex für mehrere native Microsoft-Anwendungen bereitstellt, wurde der am weitesten verbreitete menschliche mobile Client auf unerklärliche Weise ausgelassen: die Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Auswirkung: Ohne das Herausfiltern dieses Public Clients lösen legitime Mitarbeiter, die von ihren Smartphones aus gemeinsam genutzte Postfächer lesen und dabei zwischen Netzwerken wechseln (z. B. vom WLAN zu 4G), zwangsläufig die Warnungen zu Multiple ASNs aus. Verschiedene Mitarbeiter, die unter iOS und Android dasselbe Abteilungspostfach prüfen, lösen die Warnung zu Multiple User Agents aus.

Schwachstelle 3: Kollision bei gemeinsam genutzten Postfächern

Zur Identifizierung von Backend-Dienstkonten stützt sich Googles Logik auf diese Bedingung: $e.principal.user.userid != $e.target.user.userid

• Auswirkung: Diese Bedingung prüft lediglich, ob sich die Akteur-ID vom Besitzer des Zielpostfachs unterscheidet. Das trifft zwar auf automatisierte Dienstprinzipale zu, ist aber auch Standardverhalten für menschliche Mitarbeiter, die auf gemeinsam genutzte oder Abteilungspostfächer zugreifen (z. B. ein Operator, der [email protected] öffnet). Dieser Designfehler erzeugt massives Rauschen bei normalem operativem menschlichem Datenverkehr.

---

✅ Angepasste YARA-L-Lösungen für O365-Regeln

Um diese Designfehler zu beheben, haben Sie je nach betrieblichen Anforderungen zwei Möglichkeiten:

Option 1: Native SIEM-Ausschlüsse (Schnelllösung) Sie müssen nicht unbedingt die Regeln deaktivieren oder eigenen Code schreiben. Sie können einfach einen Ausschluss direkt in der Google SecOps SIEM UI erstellen. Fügen Sie einfach einen Ausschluss hinzu, der auf die ClientAppId von Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) und Ihre autorisierten Backup-Anwendungen (z. B. Keepit) abzielt. Dies stoppt sofort die Flut an Fehlalarmen, während Googles kuratierte Regeln aktiv bleiben.

Option 2: Bereitstellung benutzerdefinierter Regeln (Architektur-Fix) Wenn Sie die zugrunde liegenden Fehler in der Gruppierungslogik (wie die Diskrepanz bei $application_id) vollständig beheben möchten, müssen Sie die Curated Detections deaktivieren und benutzerdefinierte Regeln bereitstellen. Die Korrekturen umfassen:

1. Explizites Whitelisting von Outlook Mobile (27922004-...).
2. Whitelisting bekannter autorisierter Enterprise-Backup-Apps (z. B. Keepit).
3. Korrektur der match-Abschnitte, um ordnungsgemäß nach Sitzung zu aggregieren.

Angepasste Regel 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"] = /./
    )