Google SecOps (Chronicle) Kuratierte Detections: Schwachstellenanalyse & Tuning

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

Obwohl Google Threat Intelligence (GTIG) eine außergewöhnliche konzeptionelle Bedrohungsabdeckung bietet (wie die Verfolgung von APT29/BRICKSTORM-Kampagnen), leiden die rohen YARA-L-Implementierungen kuratierter Regeln manchmal unter Implementierungsfehlern, wie Widersprüchen in der Gruppierungslogik und hartcodierten Schwellenwertvariablen. In realen Unternehmensumgebungen führt dies häufig zu massiver Alert-Müdigkeit.

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

📑 Inhaltsverzeichnis

1. O365-Suite-Alerting-Fehler für BRICKSTORM / APT29
   • Fehler 1: Widerspruch in der Gruppierungslogik
   • Fehler 2: Übersehen des öffentlichen Clients von Outlook Mobile
   • Fehler 3: Kollision bei freigegebenen Postfächern
   • Abgestimmte YARA-L-Lösungen
2. UEBA: Anomale Authentifizierungsversuche gesamt
   • Hardcodierungsfehler & Alert-Müdigkeit
   • Tuning-Empfehlungen für UEBA

1. O365-Suite-Alerting-Fehler für BRICKSTORM / APT29

Google hat eine Reihe von Regeln veröffentlicht, um die massenhafte E-Mail-Exfiltration aus Microsoft 365 Exchange Online durch kompromittierte Service-Principals zu erkennen (Techniken, die stark von APT29/Midnight Blizzard 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

❌ Kernfehler in Googles Logik

Diese Regelsuite enthält systemische Logikabweichungen zwischen dem erklärten Ziel und der YARA-L-Implementierung, wahrscheinlich aufgrund von Code-Wiederverwendung im gesamten Regelpaket. Die Regeln schaffen es nicht, ordnungsgemäß zwischen automatisierten Service-Principals und normaler menschlicher Aktivität zu unterscheiden, was zu Alerts führt, die bei normalem Mitarbeiterverhalten ausgelöst werden.

Fehler 1: Widerspruch in der Gruppierungslogik

Obwohl die Regelbeschreibung ausdrücklich besagt: "Erkennt einen Service Principal mit einer einzigen O365-Sitzungs-ID...", gruppiert der YARA-L-match-Abschnitt der Regel "Multiple User Agents" nach $application_id anstelle der Sitzungs-ID ($session_id). Dies widerspricht vollständig dem erklärten Ziel der Regel, da nicht zusammenhängende menschliche Anmeldungen über ein 3-Stunden-Fenster aggregiert werden, nur weil sie dieselbe Anwendung verwenden.

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

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 einfügt, haben sie unerklärlicherweise den allgegenwärtigsten menschlichen mobilen Client ausgelassen: die Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Auswirkung: Ohne das Herausfiltern dieses öffentlichen Clients lösen legitime Mitarbeiter, die freigegebene Postfächer von ihren Smartphones lesen und zwischen Netzwerken wechseln (z. B. von WLAN auf 4G), von Natur aus die Alerts Multiple ASNs und Multiple IPs aus. Verschiedene Mitarbeiter, die iOS und Android verwenden, um dasselbe Abteilungspostfach zu prüfen, lösen den Alert Multiple User Agents aus.

Fehler 3: Kollision bei freigegebenen 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 Akteurs-ID von der ID des Zielpostfachbesitzers unterscheidet. Dies trifft zwar auf automatisierte Service-Principals zu, ist aber auch Standardverhalten für menschliche Mitarbeiter, die auf freigegebene oder Abteilungspostfächer zugreifen (z. B. ein Operator, der [email protected] öffnet). Dieser Designfehler erzeugt massives Rauschen auf normalem operativem menschlichem Verkehr.

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

Um diese Designfehler zu beheben, haben Sie je nach Ihren betrieblichen Anforderungen zwei Optionen:

Option 1: Native SIEM-Ausschlüsse (Schnellkorrektur) Sie müssen die Regeln nicht unbedingt deaktivieren oder benutzerdefinierten Code schreiben. Sie können einfach direkt in der Google-SecOps-SIEM-Benutzeroberfläche einen Ausschluss 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 falscher Positivmeldungen, während Googles kuratierte Regeln aktiv bleiben.

Option 2: Bereitstellung von Custom Rules (Architektonische Korrektur) Wenn Sie die zugrunde liegenden Gruppierungslogikfehler (wie die $application_id-Abweichung) vollständig beheben möchten, müssen Sie die kuratierten Detections deaktivieren und Custom Rules 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.

Abgestimmte 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"] = /./
    )
    
    // 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
}

Abgestimmte Regel 2: Multiple Mailboxes Accessed

(Gleiche Logik, aber stellen Sie in den Ausschlüssen sicher, dass Sie Ihre autorisierten Backup-Lösungen wie Keepit (a7cd46df...) zusammen mit Outlook Mobile auf die Whitelist setzen).

Abgestimmte Regel 3: Multiple ASNs

(Im Gegensatz zur User-Agents-Regel hat Google es hier tatsächlich geschafft, korrekt nach $session_id zu gruppieren. Es fehlt jedoch weiterhin der Ausschluss für Outlook Mobile. Befolgen Sie dieselbe Ausschlusslogik wie oben und behalten Sie die Bedingung $source_asn_dc >= 2 bei).

Abgestimmte Regel 4: Multiple Mailboxes Accessed via Microsoft Graph API

(Gleiche Logik. Stellen Sie sicher, dass Sie autorisierte Backup-Anwendungen wie Keepit (a7cd46df...) am Ende des events-Blocks zum Ausschluss-Regex hinzufügen).

2. UEBA: Anomale Authentifizierungsversuche gesamt

Regel: Anomalous Auth Attempts Total by Principal Hostname and Target User ID

(Hinweis: UEBA steht für "User and Entity Behavior Analytics". Diese Regeln verwenden keine statischen Signaturen, sondern verlassen sich auf mathematische Algorithmen, um "normales" Verhalten zu baselinen und auf statistische Abweichungen aufmerksam zu machen).

❌ Hardcodierungsfehler & Alert-Müdigkeit

Diese UEBA-Regel versucht, anomale Authentifizierungsspitzen zu erkennen, indem sie den historischen Durchschnitt und die Standardabweichungen über 30 Tage berechnet.

• Alert-Müdigkeit: In unserer Produktionsumgebung erzeugte diese kuratierte Regel eine unglaublich niedrige True-Positive-Rate (~0,08 %, mit 2 verwertbaren Tickets aus 2324 Alerts). Es ist im Wesentlichen reines Rauschen.
• Codefehler: Google deklariert zu Beginn des Outcome-Blocks eine Variable $num_stddevs_away = max(2). In der $historical_threshold-Berechnung hat der Google-Entwickler jedoch den Wert 2 hartcodiert, anstatt die Variable zu verwenden. Dieser Programmierfehler verhindert, dass Analysten die Empfindlichkeit einfach über die Benutzeroberfläche oder geerbte Variablen überschreiben können, ohne die YARA-L-Logik vollständig zu klonen und neu zu schreiben.

✅ Tuning-Empfehlungen für UEBA

Tests in der Praxis zeigen, dass das bloße Anpassen statistischer Schwellenwerte (z. B. Erhöhen von $num_stddevs_away auf 3 oder 4, Senken von $coefficient_of_variation_threshold von 0.1 auf 0.05 oder Erhöhen von $observation_threshold auf 15) nicht ausreicht: Die Anzahl sinkt von 710 auf 111 wöchentliche Alerts, was für ein Analystenteam weiterhin übermäßig laut ist.

• Empfohlener Ansatz: Für SecOps-Unternehmensmandanten deaktivieren Sie die Alertierung des Broad-Regelsatzes für "Fehlgeschlagene Authentifizierungen nach Gerät" und verlassen Sie sich strikt auf den Precise-Alerting-Kanal. Diese strukturelle Abhilfe ist der einzige wirksame Weg, um die Alert-Flut zu stoppen.
• Alternativer Custom-Ansatz: Wenn Sie sie unbedingt aktiv halten müssen, klonen Sie die Regel in eine Custom Rule, korrigieren Sie die hartcodierte 2 innerhalb von $historical_threshold, sodass sie Ihrer benutzerdefinierten Variable $num_stddevs_away entspricht, und setzen Sie strengere Baseline-Koeffizienten durch.

Haftungsausschluss: Diese Abstimmungen basieren auf realer Incident-Response- und SIEM-Engineering-Erfahrung. Testen Sie YARA-L-Regeln stets in Ihrer spezifischen Umgebung, bevor Sie sie in der Produktion bereitstellen.