Google SecOps (Chronicle) Curated Detections : analyse des défauts et optimisation

Ce dépôt documente les défauts de conception architecturale, les incohérences logiques et les stratégies d'optimisation des Curated Detections natives de Google SecOps (Chronicle).

Bien que Google Threat Intelligence (GTIG) offre une couverture conceptuelle exceptionnelle des menaces (comme le suivi des campagnes APT29/BRICKSTORM), les implémentations YARA-L brutes des règles curatées souffrent parfois d'oublis d'implémentation, tels que des contradictions dans la logique de regroupement et des variables de seuil codées en dur. Dans les environnements d'entreprise réels, cela conduit fréquemment à une fatigue massive liée aux alertes.

Ce projet analyse pourquoi les règles natives se cassent ou inondent le SOC, et partage des règles personnalisées optimisées ainsi que des correctifs pour résoudre ces problèmes.

Suivi amont et retours au fournisseur

• Statut : Les lacunes logiques et les retours de télémétrie des règles ont été reconnus par l'équipe Detection Engineering / Produit de Google, initiant un chantier interne Google de revue du cycle de vie des règles.

---

📑 Table des matières

1. Échec d'alerte de la suite O365 pour BRICKSTORM / APT29
   • Défaut 1 : Contradiction dans la logique de regroupement
   • Défaut 2 : Oubli du client public Outlook Mobile
   • Défaut 3 : Collision de boîtes aux lettres partagées
   • Solutions YARA-L optimisées
2. O365 Teams : Tentative d'usurpation d'identité externe
   • Défaut 1 : Inversion adversaire vs. cible
   • Défaut 2 : Clé de regroupement de correspondance erronée
   • Solution YARA-L optimisée
3. UEBA : Total des tentatives d'authentification anormales
   • Défaut de codage en dur et fatigue liée aux alertes
   • Recommandations d'optimisation

---

1. Échec d'alerte de la suite O365 pour BRICKSTORM / APT29

Google a publié une suite de règles visant à détecter l'exfiltration massive d'e-mails depuis Microsoft 365 Exchange Online par des Service Principals compromis (techniques massivement utilisées par APT29/Midnight Blizzard).

Les règles curatées concernées sont :

• 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

❌ Défauts fondamentaux dans la logique de Google

Cette suite de règles contient des incohérences logiques systémiques entre l'objectif énoncé et l'implémentation YARA-L, probablement dues à une réutilisation de code au sein du pack de règles. Les règles ne parviennent pas à distinguer correctement les Service Principals automatisés de l'activité humaine standard, ce qui entraîne des alertes déclenchées sur le comportement normal des employés.

Défaut 1 : Contradiction dans la logique de regroupement

Bien que la description de la règle indique explicitement : « Detects a Service Principal with a single O365 session ID... », la section match YARA-L de la règle « Multiple User Agents » regroupe par $application_id au lieu de l'ID de session ($session_id). Cela contredit totalement l'objectif énoncé de la règle.

• Impact : Des sessions d'employés sans lien entre elles, partageant le même App ID d'entreprise et la même boîte aux lettres partagée, sont fusionnées sur l'ensemble du tenant sur une fenêtre de 3 heures. Cela déclenche des faux positifs dès que deux utilisateurs distincts s'authentifient via des user agents différents (par exemple iPhone vs. Android) sous la même application, sans parvenir à isoler le détournement de jeton individuel.

Défaut 2 : Oubli du client public Outlook Mobile

Les règles suivent les modèles comportementaux anormaux (changements d'IP, d'ASN ou de User-Agents) liés à un ClientAppId spécifique. Bien que Google inclue une regex d'exclusion pour plusieurs applications Microsoft natives, ils ont inexplicablement omis le client mobile humain le plus omniprésent : l'application Microsoft Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4).

• Impact : Sans filtrer ce Public Client, les employés légitimes consultant des boîtes aux lettres partagées depuis leurs smartphones et se déplaçant entre réseaux (par exemple, en passant du Wi-Fi à la 4G) déclenchent intrinsèquement les alertes Multiple ASNs. Différents employés utilisant iOS et Android pour consulter la même boîte aux lettres départementale déclenchent l'alerte Multiple User Agents.

Défaut 3 : Collision de boîtes aux lettres partagées

Pour identifier les comptes de service backend, la logique de Google repose sur cette condition : $e.principal.user.userid != $e.target.user.userid

• Impact : Cette condition vérifie simplement si l'ID de l'acteur est différent du propriétaire de la boîte aux lettres cible. Bien que cela soit vrai pour les principaux de service automatisés, c'est également un comportement standard pour les employés humains accédant à des boîtes aux lettres partagées ou départementales (par exemple, un opérateur ouvrant [email protected]). Ce défaut de conception génère un bruit massif sur le trafic humain opérationnel standard.

---

✅ Solutions YARA-L ajustées pour les règles O365

Pour corriger ces défauts de conception, vous avez deux options selon vos besoins opérationnels :

Option 1 : Exclusions natives du SIEM (correctif rapide) Vous n'êtes pas nécessairement obligé de désactiver les règles ou d'écrire du code personnalisé. Vous pouvez simplement créer une Exclusion directement dans l'interface du SIEM Google SecOps. Ajoutez simplement une exclusion ciblant le ClientAppId d'Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) et vos applications de sauvegarde autorisées (par exemple, Keepit). Cela arrête immédiatement le flot de faux positifs tout en gardant les règles curatées de Google actives.

Option 2 : Déployer des règles personnalisées (correctif architectural) Si vous souhaitez corriger complètement les défauts sous-jacents de la logique de regroupement (comme l'incohérence de $application_id), vous devez désactiver les Curated Detections et déployer des règles personnalisées. Les correctifs impliquent :

1. Ajouter explicitement Outlook Mobile (27922004-...) à la liste blanche.
2. Ajouter à la liste blanche les applications de sauvegarde d'entreprise autorisées connues (par exemple, Keepit).
3. Corriger les sections match pour agréger correctement par session.

Règle ajustée 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)$/