all3xj/fixing-google-secops-detectionsAjustement et refactorisation de Google Chronicle Curated Detections pour éliminer la fatigue des alertes et corriger les lacunes logiques/bugs.
Ce référentiel documente les défauts de conception architecturale, les incohérences logiques et les stratégies de réglage des détections organisées Google SecOps (Chronicle) natives.
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 organisé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 d'alerte massive.
Ce projet analyse pourquoi les règles natives cassent ou submergent le SOC, et partage des règles personnalisées optimisées et des correctifs pour résoudre ces problèmes.
Google a publié une suite de règles pour détecter l'exfiltration massive d'e-mails depuis Microsoft 365 Exchange Online par des principaux de service compromis (des techniques largement utilisées par APT29/Midnight Blizzard).
Les règles organisées concernées sont :
O365 Mailbox Access by Service Principal with Multiple User AgentsO365 Multiple Mailboxes Accessed by Service PrincipalO365 Mailbox Access by Service Principal from Multiple ASNsO365 Multiple Mailboxes Accessed via Microsoft Graph APICette suite de règles contient des incohérences logiques systémiques entre l'objectif déclaré et l'implémentation YARA-L, probablement dues à la réutilisation de code au sein du pack de règles. Les règles ne parviennent pas à distinguer correctement les principaux de service automatisés de l'activité humaine standard, ce qui génère des alertes déclenchées par le comportement normal des employés.
Bien que la description de la règle indique explicitement : « Détecte un principal de service avec un identifiant de session O365 unique... », la section match du YARA-L de la règle « Multiple User Agents » regroupe par $application_id au lieu de l'identifiant de session ($session_id). Cela contredit totalement l'objectif déclaré de la règle, en agrégeant des connexions humaines sans rapport sur une fenêtre de 3 heures uniquement parce qu'elles utilisent la même application.
Les règles suivent les modèles de comportement anormaux (changements d'adresses 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 mobile Microsoft Outlook (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs et Multiple IPs. Des employés différents utilisant iOS et Android pour consulter la même boîte aux lettres départementale déclenchent l'alerte Multiple User Agents.Pour identifier les comptes de service backend, la logique de Google repose sur cette condition :
$e.principal.user.userid != $e.target.user.userid
[email protected]). Ce défaut de conception génère un bruit massif sur le trafic humain opérationnel standard.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'avez pas nécessairement besoin de désactiver les règles ou d'écrire du code personnalisé. Vous pouvez simplement créer une exclusion directement dans l'interface SIEM de 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 maintenant actives les règles organisées de Google.
Option 2 : Déployer des règles personnalisées (correctif architectural)
Si vous voulez 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 détections organisées et déployer des règles personnalisées. Les correctifs consistent à :
27922004-...) à la liste blanche.match pour agréger correctement par session.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
}
(Même logique, mais dans les exclusions, assurez-vous de placer sur liste blanche vos solutions de sauvegarde autorisées comme Keepit (a7cd46df...) en plus d'Outlook Mobile).
(Contrairement à la règle User Agents, Google a en fait réussi à regrouper correctement par $session_id dans celle-ci. Cependant, il lui manque toujours l'exclusion d'Outlook Mobile. Suivez la même logique d'exclusion que ci-dessus, en conservant la condition sur $source_asn_dc >= 2).
(Même logique. Assurez-vous d'ajouter les applications de sauvegarde autorisées comme Keepit (a7cd46df...) à la regex d'exclusion à la fin du bloc events).
Règle : Anomalous Auth Attempts Total by Principal Hostname and Target User ID
(Remarque : UEBA signifie « User and Entity Behavior Analytics ». Ces règles n'utilisent pas de signatures statiques, mais s'appuient plutôt sur des algorithmes mathématiques pour établir une référence du comportement « normal » et alerter en cas d'écarts statistiques).
Cette règle UEBA tente de détecter les pics d'authentification anormaux en calculant la moyenne historique et les écarts types sur 30 jours.
$num_stddevs_away = max(2) au début du bloc outcome. Cependant, dans le calcul de $historical_threshold, le développeur de Google a codé en dur la valeur 2 au lieu d'utiliser la variable. Cette erreur de programmation empêche les analystes de modifier facilement la sensibilité via l'interface ou des variables héritées sans cloner et réécrire entièrement la logique YARA-L.Les tests en conditions réelles montrent qu'ajuster simplement les seuils statistiques (par exemple, augmenter $num_stddevs_away à 3 ou 4, abaisser $coefficient_of_variation_threshold de 0.1 à 0.05, ou augmenter $observation_threshold à 15) est insuffisant : cela réduit le nombre d'alertes hebdomadaires de 710 à 111, ce qui reste excessivement bruyant pour une équipe d'analystes.
Broad pour « Failed Authentications by Device » et fiez-vous strictement au canal d'alertes Precise. Cette atténuation structurelle est la seule façon efficace d'arrêter le flot d'alertes.2 codé en dur dans $historical_threshold pour qu'il corresponde à votre variable personnalisée $num_stddevs_away, et imposez des coefficients de référence plus stricts.Avertissement : Ces réglages reposent sur une expérience réelle de réponse aux incidents et d'ingénierie SIEM. Testez toujours les règles YARA-L dans votre environnement spécifique avant de les déployer en production.