all3xj/fixing-google-secops-detectionsMessa a punto e refactoring delle Curated Detections di Google Chronicle per eliminare l'affaticamento da alert e correggere lacune logiche e bug.
Questo repository documenta difetti architetturali di progettazione, discrepanze logiche e strategie di tuning per le Curated Detections native di Google SecOps (Chronicle).
Mentre Google Threat Intelligence (GTIG) fornisce una copertura concettuale delle minacce eccezionale (come il tracciamento delle campagne APT29/BRICKSTORM), le implementazioni YARA-L grezze delle regole curate soffrono talvolta di sviste implementative, come contraddizioni nella logica di raggruppamento e variabili di soglia hardcoded. Negli ambienti aziendali reali, questo porta frequentemente a un'enorme alert fatigue.
Questo progetto analizza perché le regole native si rompono o inondano il SOC, e condivide Regole Personalizzate ottimizzate e patch per risolvere questi problemi.
Google ha rilasciato una suite di regole per rilevare l'esfiltrazione massiva di email da Microsoft 365 Exchange Online tramite Service Principal compromessi (tecniche ampiamente utilizzate da APT29/Midnight Blizzard).
Le regole curate interessate sono:
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 APIQuesta suite di regole contiene discrepanze logiche sistemiche tra l'obiettivo dichiarato e l'implementazione YARA-L, probabilmente dovute al riuso del codice all'interno del pacchetto di regole. Le regole non riescono a distinguere correttamente tra Service Principal automatizzati e normale attività umana, generando alert che si attivano su comportamenti standard dei dipendenti.
Nonostante la descrizione della regola affermi esplicitamente: "Rileva un Service Principal con un singolo ID sessione O365...", la sezione match YARA-L della regola "Multiple User Agents" raggruppa per $application_id invece che per ID sessione ($session_id). Questo contraddice completamente l'obiettivo dichiarato della regola, aggregando login umani non correlati in una finestra di 3 ore semplicemente perché usano la stessa applicazione.
Le regole tracciano pattern comportamentali anomali (cambi di IP, ASN o User-Agent) legati a uno specifico ClientAppId. Sebbene Google includa una regex di esclusione per diverse applicazioni Microsoft native, hanno inspiegabilmente omesso il client mobile umano più diffuso: Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs e Multiple IPs. Dipendenti diversi che usano iOS e Android per controllare la stessa cassetta postale dipartimentale attivano l'alert Multiple User Agents.Per identificare gli account di servizio backend, la logica di Google si basa su questa condizione:
$e.principal.user.userid != $e.target.user.userid
[email protected]). Questo difetto di progettazione genera rumore massiccio sul normale traffico operativo umano.Per risolvere questi difetti di progettazione, hai due opzioni a seconda delle tue esigenze operative:
Opzione 1: Esclusioni Native nel SIEM (Fix Rapido)
Non è necessario disabilitare le regole o scrivere codice personalizzato. Puoi semplicemente creare un'Esclusione direttamente nell'interfaccia del SIEM Google SecOps. Basta aggiungere un'esclusione mirata al ClientAppId di Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) e alle tue applicazioni di backup autorizzate (ad esempio, Keepit). Questo ferma immediatamente l'inondazione di falsi positivi mantenendo attive le regole curate di Google.
Opzione 2: Distribuire Regole Personalizzate (Fix Architetturale)
Se vuoi correggere completamente i difetti sottostanti nella logica di raggruppamento (come la discrepanza di $application_id), devi disabilitare le Curated Detections e distribuire Regole Personalizzate. Le correzioni comportano:
27922004-...).match per aggregare correttamente per sessione.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
}
(Stessa logica, ma nelle esclusioni assicurati di consentire le tue soluzioni di backup autorizzate come Keepit (a7cd46df...) insieme a Outlook Mobile).
(A differenza della regola User Agents, Google è riuscito a raggruppare correttamente per $session_id in questo caso. Tuttavia, manca ancora dell'esclusione per Outlook Mobile. Segui la stessa logica di esclusione di cui sopra, mantenendo la condizione su $source_asn_dc >= 2).
(Stessa logica. Assicurati di aggiungere le applicazioni di backup autorizzate come Keepit (a7cd46df...) alla regex di esclusione alla fine del blocco events).
Regola: Anomalous Auth Attempts Total by Principal Hostname and Target User ID
(Nota: UEBA sta per "User and Entity Behavior Analytics". Queste regole non usano firme statiche, ma si basano su algoritmi matematici per stabilire una baseline del comportamento "normale" e generare alert su deviazioni statistiche).
Questa regola UEBA tenta di rilevare picchi di autenticazione anomali calcolando la media storica e le deviazioni standard su 30 giorni.
$num_stddevs_away = max(2) all'inizio del blocco outcome. Tuttavia, nel calcolo di $historical_threshold, lo sviluppatore di Google ha hardcodato il valore 2 invece di usare la variabile. Questo errore di programmazione impedisce agli analisti di sovrascrivere facilmente la sensibilità tramite l'interfaccia o le variabili ereditate, senza clonare e riscrivere completamente la logica YARA-L.I test nel mondo reale mostrano che modificare semplicemente le soglie statistiche (ad esempio, alzando $num_stddevs_away a 3 o 4, abbassando $coefficient_of_variation_threshold da 0.1 a 0.05, o aumentando $observation_threshold a 15) è insufficiente: riduce i conteggi da 710 a 111 alert settimanali, che rimangono eccessivamente rumorosi per un team di analisti.
Broad per "Failed Authentications by Device" e affidati strettamente al canale di alerting Precise. Questa mitigazione strutturale è l'unico modo efficace per fermare l'inondazione di alert.2 hardcodato all'interno di $historical_threshold per allinearlo alla tua variabile $num_stddevs_away, e applica coefficienti di baseline più rigorosi.Disclaimer: Queste ottimizzazioni si basano su esperienza reale di incident response e ingegneria SIEM. Testa sempre le regole YARA-L nel tuo ambiente specifico prima di distribuirle in produzione.