Sfide nel monitoraggio dei log di Azure: Approfondimenti per il vostro SOC

I registri delle attività completi e tempestivi sono strumenti potenti che consentono il monitoraggio della sicurezza e la risposta agli incidenti nel cloud. Tuttavia, studiando i registri di Azure, i nostri ricercatori hanno notato molte carenze che complicano la comprensione delle azioni degli utenti e che potrebbero persino permettere a un aggressore di sfuggire. In questo post discuteremo di questi problemi e del loro impatto sul lavoro del team blu. 

Perché studiare i log di Azure Monitor    

Prima di discutere i dettagli specifici del provider, è bene notare che i log hanno un significato diverso negli ambienti cloud e on-premise.

Gli amministratori hanno una certa scelta nelle configurazioni on-premise: È possibile intercettare il traffico di rete per monitorare l'attività o raccogliere i log sul bordo della rete e sui singoli computer. Le soluzioni di registrazione e monitoraggio (hardware e software) sono sostituibili e, se un particolare prodotto del fornitore non funziona bene, è possibile installarne un altro.

Nel cloud non si hanno queste opzioni: il provider controlla completamente i log disponibili. Se sono di alta qualità, bene! Ma se ci sono problemi, siete in balia della volontà del fornitore di risolverli. Potete segnalarli al fornitore e sperare che vengano risolti o cercare di aggirarli, se possibile.

Il monitoraggio delle attività nell'ambiente cloud comporta diverse aspettative:

• Nessuna modifica non annunciata alla struttura o al contenuto del registro.
• Registrazione tempestiva degli eventi
• Registrazioni di registro complete e accurate (senza valori mancanti o interrotti)
• Documentazione completa per gli eventi registrati
• Un modo semplice per correlare gli eventi e le sessioni utente tra i diversi log.
• Una serie di indicatori di minaccia da utilizzare nell'analisi degli incidenti.

Quando si analizza l'attività, i seguenti dati devono essere costantemente disponibili in tutte le fonti di log e per tutti i tipi di eventi:

• Nomi e dettagli dell'operazione
• Identità dell'utente e informazioni sulla sessione
• IP
• Geolocalizzazione
• Informazioni sul dispositivo
• Indicatori di minaccia e reputazione

In sostanza, si vuole essere in grado di dire chi ha fatto cosa e quando (e cos'altro ha fatto). Purtroppo, queste aspettative non sono sempre soddisfatte dai log di Azure.

Come monitoriamo gli eventi in Azure

Azure dispone di una serie matura di prodotti per l'analisi e il monitoraggio degli eventi:  

Microsoft Sentinel è un prodotto SIEM nativo che ingerisce i log da varie fonti. Dispone di una serie di rilevamenti integrati e consente di definirne di personalizzati. 

Azure Log Analytics è una piattaforma di analisi dei log, ideale per indagini ad hoc su eventi sospetti.    

Entrambi supportano Kusto, un potente linguaggio di interrogazione e analisi dei log. Inoltre, è possibile utilizzare soluzioni di terze parti per monitorare e interpretare i log.

L'infrastruttura di log di Azure è vasta e conta decine, se non centinaia, di fonti di log. Sarebbe impossibile parlarne tutti, quindi ci concentreremo sui log generati da Azure AD (ora Entra ID), la soluzione IAM di Azure, e da Microsoft 365, una suite per ufficio SaaS cloud .

Copertura dei registri Entra ID: 

• ‍Sign-ins - diversi registri che coprono l'attività di firma di utenti interattivi e non interattivi, di presidi di servizio e di identità gestite.
• Audit: una registrazione delle operazioni significative del repertorio
• Provisioning - dati sul provisioning degli utenti da parte di servizi di terze parti

Questi registri sono accessibili tramite Graph API e attualmente esistono una versione base (1.0) e una Beta, con schemi diversi. 

I registri delle attività di Microsoft 365 vengono consumati attraverso la Management Activity API, che fornisce diversi registri per diversi tipi di eventi:

• Audit.AzureActiveDirectory - eventi dal servizio Entra ID (simili a quelli disponibili tramite Graph API), come le assegnazioni e le modifiche alla directory.
• Audit.Exchange - Eventi di Exchange
• Audit.SharePoint - Attività di SharePoint
• Audit.General - la maggior parte delle azioni che non rientrano in nessuno degli altri log.
• DLP.All - Eventi di prevenzione della perdita di dati

Problemi noti del registro di Azure Monitor

Ora che abbiamo esplorato l'importanza del monitoraggio dei log di Azure, approfondiamo alcuni problemi che abbiamo riscontrato in questi log. La consapevolezza di questi problemi può aiutarvi a creare query di analisi migliori e a perdere meno tempo a chiedervi perché le cose si comportano nel modo in cui si comportano.    

Le sfide specifiche che dovrebbero essere all'attenzione di ogni analista e architetto della sicurezza includono:

• Schema fluido
• Flusso di log
• Ritardi nell'evento
• Eventi mancanti
• Imposta di registro
• Eventi che non vengono mai registrati
• Documentazione carente
• Modifiche non annunciate
• Incoerenze ID
• Incoerenze IP
• Incoerenze di geolocalizzazione
• Incoerenze delle informazioni sul dispositivo
• Valori infranti

Analizziamo ciascuno di essi in modo più dettagliato.

Schema fluido

Lo schema di alcuni log (ad esempio Management Activity API) è "fluido". Ciò significa che un parametro univoco in una nuova operazione verrà aggiunto al log come nuova colonna.

Questo lo rende difficile da gestire, anche per Log Analytics. (Abbiamo osservato che mostra errori relativi a un "limite massimo di 500 colonne raggiunto"). Se state cercando di consumare gli eventi in un SIEM esterno, potreste dover essere selettivi sulle colonne da consumare ed è impossibile prevedere le nuove colonne che Azure aggiungerà.

Un metodo migliore sarebbe stato uno schema statico in tutti i log, con l'aggiunta di campi struttura (ad esempio in JSON) per gestire la variabilità.

Flusso di log

In Azure si verificano occasionalmente interruzioni dei log. In effetti, negli ultimi anni ne abbiamo registrati diversi. Sebbene uno sia durato diverse settimane e sia stato scoperto accidentalmente, Microsoft è generalmente brava ad avvisare i clienti in queste situazioni.

Il problema è che durante un'interruzione, l'utente può essere completamente cieco a qualsiasi attività nell'ambiente. Se vi capita anche di perdere l'annuncio dell'interruzione, nulla vi indicherà che c'è un problema. È essenziale tenere sotto controllo la salute del servizio in Azure e possibilmente investire in una soluzione di monitoraggio che tenga traccia del flusso di log.

Le interruzioni possono anche essere intenzionali. La configurazione della registrazione è controllata in banda e una compromissione dell'account di un amministratore può portare l'aggressore a disabilitare la registrazione su larga scala (ad esempio tramite Set-AdminAuditLogConfig) o in modo più fine e furtivo (ad esempio tramite Set-Mailbox -AuditEnabled).

Il monitoraggio del flusso di log e delle modifiche alla configurazione è essenziale per ridurre questi problemi. Solo pochi utenti autorizzati devono essere in grado di modificare le impostazioni di log. Sarebbe preferibile che Azure aggiungesse più controlli alla configurazione dei registri, a causa delle significative conseguenze negative derivanti dalla disabilitazione accidentale o intenzionale dei registri.

Ritardi nell'evento

Microsoft pubblica i tempi previsti per la disponibilità degli eventi di log. Il tempo di ingestione dell'API Graph è dichiarato inferiore a 3 minuti. Secondo la nostra esperienza, possono essere necessari fino a 30 minuti per visualizzare gli eventi in queste fonti.

La disponibilità tipica pubblicizzata per gli eventi di Management ActivityAPI è compresa tra 60 e 90 minuti. In realtà, i ritardi osservati sono più significativi. Ecco alcuni numeri massimi che abbiamo rilevato di recente - alcuni tempi superano di gran lunga le 24 ore (la colonna max_delay contiene il tempo massimo osservato tra la creazione dell'evento e la sua disponibilità nel log):

Questi tempi di ritardo sono insostenibili. Alcuni attaccanti si muovono con estrema rapidità. Se consideriamo il tempo necessario per l'elaborazione da parte degli strumenti di rilevamento, l'ingestione da parte del SIEM esterno e la reazione da parte del personale del SOC, diventa chiaro che, in molti casi, il blue team arriverà in ritardo, quasi per scelta. 

Più gli aggressori automatizzano i loro strumenti, più la situazione peggiora. Azure deve dare priorità alla disponibilità rapida dei registri. Altrimenti, i difensori possono solo reagire agli incidenti, non fermarli. I ritardi negli eventi sono ancora più difficili da gestire quando i record di log vengono inoltrati a un SIEM esterno. Le chiamate API di log prendono come parametri gli intervalli di tempo, quindi è necessario accettare la perdita di record o interrogare intervalli di tempo sovrapposti e rimuovere i record duplicati per non perdere gli eventi in ritardo.

Eventi mancanti

Alcuni tipi di eventi possono essere presenti in più di un registro. Ad esempio, i record di accesso sono disponibili sia in Graph API che in Management Activity API. Confrontando i record dello stesso evento in entrambe le fonti, si potranno notare differenze occasionali. 

Considerate i seguenti esempi tratti da una recente indagine su un incidente. Sebbene corrispondano tutti alle stesse azioni da parte di un attaccante, i record registrati non corrispondono esattamente:

Graph API (beta - in Azure Portal):

Graph API (v1.0): 

AuditAzureActiveDirectory in Management Activity API:

Questo tipo di incoerenza è difficile da riprodurre e spiegare, ma è necessario esserne consapevoli quando si effettua l'analisi dei registri. È possibile che i record vadano persi e che sia necessaria l'analisi di più registri per ottenere un quadro più completo di ciò che è accaduto.

Imposta di registro

Molti tipi di eventi e dettagli di log sono disponibili solo con i livelli di pagamento più elevati (ad esempio E5 e P2). Alcuni esempi sono gli eventi MailItemsAccessed, i dettagli sui rischi nel log degli accessi e altri ancora. Questo rappresenta un dilemma per molti clienti: significa scegliere tra costi più bassi e una migliore visibilità delle attività nell'ambiente. 

Non è una buona scelta da fare e, a nostro avviso, le funzioni di sicurezza di base (come i log) dovrebbero essere disponibili per tutti i clienti cloud . Come ha recentemente affermato il senatore statunitense Ron Wyden,"Far pagare le persone per le funzioni premium necessarie per non essere hackerati è come vendere un'auto e poi far pagare un extra per le cinture di sicurezza e gli airbag". 

Questa mancanza di visibilità ha causato difficoltà in molti casi di clienti di Vectra AI su cui abbiamo dovuto indagare. Una recente violazione pubblica da parte dell'APT Storm-0558, di cui si è dovuta occupare la stessa Microsoft, ha portato questo problema alla luce del sole. A seguito di questo incidente, Microsoft ha concordato con la CISA di estendere l'accesso al logging a tutti i clienti questo autunno. 

Si spera che le cose migliorino presto. Nel frattempo, è necessario assicurarsi che la registrazione a cui si ha accesso tramite la licenza sia adeguata alle esigenze di IR della propria organizzazione. Se così non fosse, è il momento di fare un aggiornamento. Quando i dati essenziali non sono disponibili, alcuni di essi (ad esempio, la reputazione IP e le informazioni di geolocalizzazione) possono essere acquisiti da fonti terze.

Alcuni eventi che non vengono mai registrati

Azure è un "paradiso di ricognizione", con eventi di tipo "get" che corrispondono alla lettura di configurazione e dati che, con rare eccezioni, non vengono registrati. A partire da ottobre 2023, è stato introdotto un nuovo registro che registra le chiamate API Graph e che copre alcune delle operazioni di ricognizione. Tuttavia, l'enumerazione attraverso altre API rimane invisibile ai difensori.

Ciò significa che quando un attaccante ottiene l'accesso all'ambiente cloud , può enumerare la maggior parte delle informazioni (utenti, servizi, configurazione) senza che i difensori lo vedano. Questo rappresenta un grande punto cieco: nei nostri test, la maggior parte degli strumenti di enumerazione M365/AAD open-source non ha lasciato alcuna traccia nei log. 

Non è chiaro perché sia stata presa la decisione di non registrare tali eventi, anche se forse per risparmiare spazio. Sfortunatamente, non esiste un'opzione che permetta di attivare tale registrazione, anche se il cliente desidera vedere questo tipo di eventi. Ciò significa che si rimane all'oscuro finché gli aggressori non iniziano a modificare l'ambiente.

Documentazione carente

Mentre le API di Azure sono documentate abbastanza bene, la documentazione sugli eventi di log è carente. Per molti eventi, l'unica cosa documentata è il nome dell'operazione, ma i singoli campi e il loro significato sono spesso un mistero. È necessario cercare tra i blog e i forum di discussione per cercare di interpretare ciò che sta accadendo.

Oltre a non essere chiaro lo scopo di un campo, anche i valori dei singoli dati sono talvolta poco documentati. Abbiamo visto tipi di autenticazione specifici, codici di stato, sottotipi di operazioni e altri dati senza descrizione. Neanche una ricerca approfondita è riuscita a fare chiarezza su alcuni di questi valori.

Poiché non comprendiamo alcuni campi e valori, non possiamo monitorarli e interpretarli durante le indagini e la risposta agli incidenti.

Modifiche non annunciate

Con l'evoluzione delle funzionalità cloud (come spesso accade), nei registri compaiono senza preavviso nuovi tipi di eventi. Ad esempio, è stato aggiunto un nuovo codice di errore per gli errori di accesso senza password che abbiamo recentemente documentato. Il team di ricerca sulla sicurezza Vectra AI ha dovuto dedicare del tempo a indagare su questo codice prima di capire cosa lo avesse innescato e, fino a quel momento, le nostre query di monitoraggio non ne erano a conoscenza.  

L'aspetto più preoccupante è che anche gli eventi esistenti possono scomparire o cambiare formato. Alcuni esempi recenti sono:

• L'evento MailboxLogin che stavamo monitorando e che è scomparso silenziosamente dai registri di Exchange.
• Errori di accesso per nomi utente inesistenti che venivano monitorati per individuare le prime fasi dell'attività di ricognizione e non venivano più scritti nei registri di accesso.

Quando le query di monitoraggio e di analisi sono alla ricerca di eventi specifici, queste modifiche le faranno smettere di funzionare senza preavviso. Questo è il peggior tipo di guasto, quando non ci si accorge nemmeno che c'è un problema. Potrebbe essere necessario investire in una logica per monitorare l'integrità dei registri e tenere sotto controllo la modifica dei contenuti e della documentazione dei registri. Sfortunatamente, la maggior parte dei difensori è troppo impegnata per dedicare del tempo a questo aspetto.

Incoerenze ID

Gli ID utente non sono sempre "stabili". A seconda del contesto e del tipo di operazione, lo stesso utente può comparire nei registri con "nomi principali dell'utente" (UPN) diversi. Ad esempio, l'utente potrebbe essere registrato come:

• john.smith@company.com
• John.Smith@company.com (notare la differenza di lettere maiuscole e minuscole)
• AN045789@company.com

M365 Exchange mette i bastoni tra le ruote aggiungendo nomi legacy come i seguenti (e altri):

"NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e "per conto di "NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/JohnSmith".

Nei casi di variabilità dei nomi, collegare eventi diversi allo stesso utente diventa difficile. Se la correlazione degli eventi in base all'UPN può essere il primo impulso, la correlazione in base all'ID interno univoco può essere una strategia più solida (ma non ancora infallibile).  

Le difficoltà continuano:  

• Nomi diversi in registri diversi possono avere nomi di campi sovrapposti con significati diversi. Ad esempio, user_id significherà un GUID utente in un registro e un UPN in un altro.
• Gli ID utente possono avere valori che rappresentano il nome e il cognome dell'utente, i nomi delle applicazioni, i GUID delle applicazioni e altri nomi insoliti e ID univoci.
• Gli ID utente possono essere vuoti o contenere nomi inutili come "Non disponibile", "Sconosciuto", "Nessun UPN":

Come difensore, dovete essere pronti a vedere queste informazioni (poco utili) nei campi dell'identità dell'utente e costruire la funzionalità di interrogazione di conseguenza.

Incoerenze IP

Un indirizzo IP valido è un requisito fondamentale per ogni record di log. Sebbene nella maggior parte dei casi le voci di registro contengano indirizzi IPv4 e IPv6 validi, a volte si riscontrano IP difficili da comprendere e da utilizzare nelle analisi:

• IP con numeri di porta (sia v4 che v6)
• IP vuoti
• IP locali e privati:127.0.0.1, 192.168.*, 10.*
• IP tutti a zero: 0.0.0.0
• Maschere IP invece di IP: 255.255.255.255
• IP che corrispondono all'infrastruttura Azure, non all'utente che esegue l'operazione.

Gli IP non possono essere correlati ai registri di accesso per alcune operazioni, il che complica l'analisi degli incidenti. Gli indicatori di rischio e di reputazione degli IP possono essere occasionalmente disponibili, ma sono soggetti alla "tassa di registrazione".

Come difensore, è necessario prevedere questi casi speciali quando si scrivono le query di caccia e gli avvisi e tenerli in considerazione nella propria logica.

Incoerenze di geolocalizzazione

Attualmente, Microsoft fornisce solo la geolocalizzazione per i record di accesso. Questo sarebbe stato utile per altre fonti di log, perché non è sempre possibile collegare le attività a record di accesso specifici.

Questa funzione non è perfetta. A volte si verificano degli intoppi:

• Lo stesso IP si risolve in più posizioni (molto probabilmente legate a dispositivi mobili).
• I record vengono geolocalizzati in massa in modo errato.
• Mancano le geoinformazioni:

La geolocalizzazione viene facilmente ingannata anche da TOR, VPN, proxy e IP di provider cloud e deve essere presa con le molle.

Incoerenze delle informazioni sul dispositivo

I dettagli del dispositivo sono complessi da determinare per Microsoft (a meno che non si tratti di un dispositivo registrato). Le informazioni sulla piattaforma e sul browser vengono normalmente analizzate dall'agente utente (UA).

Purtroppo anche qui ci sono delle incongruenze: 

• Alcuni log analizzano l'UA e lo forniscono in modo frammentario, mentre altri forniscono l'intera stringa UA (che deve essere interpretata).
• Le informazioni sul dispositivo non sono disponibili in tutti i registri
• I valori analizzati non sono sempre coerenti (ad es. "Windows" vs. "Windows 10").

Gli aggressori possono facilmente falsificare l'Agente utente, ma è comunque prezioso per le indagini, in quanto non tutti sono abbastanza disciplinati da cambiarlo senza dare nell'occhio. 

Valori infranti

Alcuni campi di log hanno strutture complesse (ad esempio JSON) e le query di caccia e monitoraggio devono analizzarli per fare riferimento a specifici sottocampi.

Occasionalmente, questi valori vengono tagliati a causa dei limiti di dimensione, dando luogo a strutture interrotte. Ad esempio, si consideri il seguente valore registrato per l'operazione Set-ConditionalAccessPolicy. Una parte di esso viene tagliata e sostituita con tre punti ("..."), il che confonde il parser JSON: 

Le query di monitoraggio che si imbattono in tali record falliranno, dando luogo a punti ciechi.

In questi casi, affidarsi al parsing corretto dei valori potrebbe non essere la strategia migliore e la ricerca per sottostringa potrebbe funzionare meglio.

Cosa serve per migliorare la qualità dei tronchi?

Non siamo i soli a criticare la qualità dei registri di Azure (problemi simili sono stati sollevati in precedenza da CrowdStrike e EricWoodruff) e possiamo solo ipotizzare il motivo per cui ne esistono così tanti.

I registri di solito passano in secondo piano, in termini di priorità, rispetto ad altre funzionalità nello sviluppo del software. Le funzionalità dei servizi di back-end possono essere sacrificate quando il team di sviluppo deve rilasciare la funzionalità principale del prodotto.

In enormi ecosistemi di prodotti come Azure, vengono riuniti più prodotti indipendenti (e talvolta legacy). È difficile che tutti forniscano un buon segnale in un'architettura di registrazione comune e questa funzionalità non è esattamente "a contatto con i clienti", quindi i reclami al riguardo possono essere ignorati.

Qualunque sia la ragione, l'assenza di alternative in un ambiente cloud rende i problemi di log molto più gravi di quanto non sarebbero stati in una configurazione tradizionale on-premises. Oltre a essere consapevoli delle carenze dei registri e a cercare di aggirare alcuni di essi, i difensori non hanno altre opzioni. Microsoft possiede questa funzionalità e spetta a loro migliorarla.

Riteniamo che il team di Azure possa (e debba) apportare una serie di modifiche non invasive:

• Tutti gli eventi, i campi e i valori delle enum devono essere completamente documentati per eliminare le congetture dall'analisi dei log.
• La struttura e i contenuti dei registri devono essere trattati come un'API: qualsiasi modifica che possa compromettere la funzionalità di interrogazione dei registri deve essere introdotta in modo controllato e i clienti devono avere il tempo di adattarsi alle modifiche.
• Tutte le aggiunte e (soprattutto) le rimozioni di operazioni registrate devono essere chiaramente annunciate.
• I documenti devono essere consegnati in modo molto più tempestivo di quanto non lo siano oggi, in pochi secondi anziché in minuti o ore, e gli eventi non devono subire ritardi o arrivare fuori ordine.
• Tutti i valori registrati devono essere utili, corretti e non ambigui.
• I registri devono contenere informazioni utili per la risposta agli incidenti (ad esempio, la reputazione IP).

L'ideale sarebbe rifattorizzare l'architettura di logging per renderla più snella (simile a quella disponibile in AWS e Okta).

Le indicazioni per i giocatori della squadra rossa

Finora abbiamo parlato solo delle difficoltà che questi problemi pongono alla vostra squadra. Ma è importante ricordare che ogni perdita del difensore è un guadagno per l'attaccante. Black hat, APT e red-teamer competenti possono sfruttare le peculiarità del logging di Azure per nascondere le proprie azioni e complicare gli sforzi del blue-team.

Ecco alcune delle tecniche che gli aggressori potrebbero utilizzare:

• Utilizzo di operazioni insolite che sono meno documentate o comprese.
• Esecuzione di azioni che iniettano nei log valori non corretti o non documentati per complicare l'analisi.
• Connessione da località per le quali le informazioni IP o di geolocalizzazione sono registrate in modo non corretto
• Temporizzazione delle operazioni per sfruttare i ritardi di ingestione o per complicare la scoperta di eventi correlati.

Naturalmente, sarebbero necessarie ulteriori ricerche per trasformare qualsiasi carenza di registrazione in una robusta tecnica di evasione.

Il vostro lavoro di difensori è difficile. Cercare di rilevare e rimediare rapidamente agli attacchi è un'impresa ardua, e diventa ancora più laborioso quando si devono registrare i problemi e aggirarli.

La promessa di una maggiore sicurezza nel cloud non è un sogno irrealizzabile e uno dei modi per contribuire al suo raggiungimento è quello di fornire una registrazione di alta qualità. Sebbene i fornitori abbiano il potere di farlo, potrebbero non essere incentivati a renderlo un obiettivo prioritario. È qui che entriamo in gioco noi. Più la comunità di ricerca sulla sicurezza si espone e più pressione esercitiamo, più ci avviciniamo al miglioramento della qualità dei log.

Volete partecipare alla conversazione? Partecipa direttamente al team di ricerca sulla sicurezza Vectra AI , su questo post del blog e su altri argomenti, su Reddit.