Google SecOps (Chronicle) Curated Detections: Analisi dei Difetti e Tuning

Questo repository documenta difetti di progettazione architetturale, discrepanze logiche e strategie di tuning per le Google SecOps (Chronicle) Curated Detections native.

Sebbene Google Threat Intelligence (GTIG) fornisca un'eccezionale copertura concettuale delle minacce (come il tracciamento delle campagne APT29/BRICKSTORM), le implementazioni YARA-L grezze delle regole curate a volte soffrono di sviste implementative, come contraddizioni nella logica di raggruppamento e variabili di soglia hardcoded. In ambienti aziendali reali, questo porta frequentemente a un'enorme fatica da alert.

Questo progetto analizza perché le regole native si rompono o inondano il SOC, e condivide Custom Rules ottimizzate e patch per risolvere questi problemi.

Tracciamento Upstream e Feedback al Fornitore

• Stato: Le lacune logiche e il feedback sulla telemetria delle regole sono stati riconosciuti dal team Detection Engineering / Product di Google, avviando un flusso di lavoro interno di revisione del ciclo di vita delle regole.

---

📑 Indice

1. Errore di Alerting della Suite O365 per BRICKSTORM / APT29
   • Difetto 1: Contraddizione nella Logica di Raggruppamento
   • Difetto 2: Svista sul Client Pubblico di Outlook Mobile
   • Difetto 3: Collisione delle Caselle di Posta Condivise
   • Soluzioni YARA-L Ottimizzate
2. O365 Teams: Tentativo di Impersonificazione Esterna
   • Difetto 1: Inversione Avversario vs. Obiettivo
   • Difetto 2: Chiave di Raggruppamento Match Errata
   • Soluzione YARA-L Ottimizzata
3. UEBA: Totale dei Tentativi di Autenticazione Anomali
   • Difetto di Hardcoding e Fatica da Alert
   • Raccomandazioni per il Tuning

---

1. Errore di Alerting della Suite O365 per BRICKSTORM / APT29

Google ha rilasciato una suite di regole per rilevare l'esfiltrazione massiva di email da Microsoft 365 Exchange Online da parte di Service Principal compromessi (tecniche ampiamente utilizzate da APT29/Midnight Blizzard).

Le regole curate interessate sono:

• 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

❌ Difetti Fondamentali nella Logica di Google

Questa suite di regole contiene disallineamenti logici sistemici tra l'obiettivo dichiarato e l'implementazione YARA-L, probabilmente dovuti al riutilizzo del codice all'interno del pacchetto di regole. Le regole non riescono a distinguere correttamente tra Service Principal automatizzati e attività umana standard, con il risultato di alert che si attivano su comportamenti normali dei dipendenti.

Difetto 1: Contraddizione nella Logica di Raggruppamento

Nonostante la descrizione della regola affermi esplicitamente: "Detects a Service Principal with a single O365 session ID...", la sezione match YARA-L della regola "Multiple User Agents" raggruppa per $application_id invece che per l'ID di sessione ($session_id). Questo contraddice completamente l'obiettivo dichiarato della regola.

• Impatto: Sessioni di dipendenti non correlate che condividono lo stesso App ID aziendale e la stessa posta condivisa vengono unite in tutto il tenant su una finestra di 3 ore. Questo attiva falsi positivi ogni volta che due utenti distinti si autenticano tramite user agent diversi (ad es. iPhone vs. Android) sotto la stessa applicazione, senza riuscire a isolare il dirottamento di singoli token.

Difetto 2: Svista sul Client Pubblico di Outlook Mobile

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 native Microsoft, ha inspiegabilmente omesso il client mobile umano più diffuso: la Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Impatto: Senza filtrare questo Public Client, i dipendenti legittimi che leggono caselle di posta condivise dai propri smartphone e che si spostano tra reti (ad esempio, passando dal Wi-Fi al 4G) attivano intrinsecamente gli avvisi Multiple ASNs. Dipendenti diversi che usano iOS e Android per controllare la stessa casella di posta dipartimentale attivano l'avviso Multiple User Agents.

Difetto 3: Collisione delle caselle di posta condivise

Per identificare gli account di servizio backend, la logica di Google si basa su questa condizione: $e.principal.user.userid != $e.target.user.userid

• Impatto: Questa condizione verifica semplicemente se l'ID dell'attore è diverso dal proprietario della casella di posta di destinazione. Sebbene sia vera per i principal di servizio automatizzati, è anche un comportamento standard per i dipendenti umani che accedono a caselle di posta condivise o dipartimentali (ad esempio, un operatore che apre [email protected]). Questo difetto di progettazione genera un'enorme quantità di rumore sul normale traffico operativo umano.

---

✅ Soluzioni YARA-L ottimizzate per le regole O365

Per correggere questi difetti di progettazione, hai due opzioni a seconda delle tue esigenze operative:

Opzione 1: Esclusioni native nel SIEM (correzione rapida) Non devi necessariamente disabilitare le regole o scrivere codice personalizzato. Puoi semplicemente creare un'Esclusione direttamente nell'interfaccia di Google SecOps SIEM. 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 interrompe immediatamente il diluvio di falsi positivi mantenendo attive le regole curate da Google.

Opzione 2: Distribuire regole personalizzate (correzione architetturale) Se vuoi correggere completamente i difetti della logica di raggruppamento sottostante (come la mancata corrispondenza di $application_id), devi disabilitare le Curated Detections e distribuire regole personalizzate. Le correzioni comportano:

1. Inserire esplicitamente Outlook Mobile nella whitelist (27922004-...).
2. Inserire nella whitelist le note app di backup aziendali autorizzate (ad esempio, Keepit).
3. Correggere le sezioni match per aggregare correttamente per sessione.

Regola ottimizzata 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