Guida all'analisi delle minacce Sysmon, parte 1

Questo articolo è la prima parte di una serie sull'analisi delle minacce Sysmon. Tutte le altre parti della serie:

Parte 1: Introduzione all'analisi dei log di Sysmon (siamo qui)
Parte 2: utilizzo dei dati degli eventi Sysmon per identificare le minacce
Parte 3. Analisi approfondita delle minacce Sysmon utilizzando i grafici

Se lavori nel campo della sicurezza informatica, probabilmente dovrai spesso comprendere gli attacchi in corso. Se hai già un occhio allenato, puoi cercare attività non standard nei registri "grezzi" non elaborati, ad esempio uno script PowerShell in esecuzione con il comando DownloadString o uno script VBS che finge di essere un file Word, semplicemente scorrendo l'ultima attività nel registro eventi di Windows. Ma questo è davvero un grosso grattacapo. Fortunatamente, Microsoft ha creato Sysmon, che rende l’analisi degli attacchi molto più semplice.

Vuoi comprendere le idee di base dietro le minacce visualizzate nel registro Sysmon? Scarica la nostra guida Eventi WMI come mezzo di spionaggio e ti rendi conto di come gli addetti ai lavori possano osservare di nascosto altri dipendenti. Il problema principale quando si lavora con il registro eventi di Windows è la mancanza di informazioni sui processi principali, ad es. è impossibile comprenderne la gerarchia dei processi. Le voci del registro Sysmon, invece, contengono l'ID del processo principale, il suo nome e la riga di comando da avviare. Grazie,Microsoft.

Nella prima parte della nostra serie, vedremo cosa puoi fare con le informazioni di base di Sysmon. Nella Parte XNUMX sfrutteremo appieno le informazioni sui processi principali per creare strutture di conformità più complesse note come grafici delle minacce. Nella terza parte esamineremo un semplice algoritmo che scansiona un grafico delle minacce alla ricerca di attività insolite analizzando il “peso” del grafico. E alla fine, sarai ricompensato con un metodo probabilistico di rilevamento delle minacce accurato (e comprensibile).

Parte 1: Introduzione all'analisi dei log di Sysmon

Cosa può aiutarti a comprendere le complessità del registro eventi? In definitiva - SIEM. Normalizza gli eventi e semplifica la loro successiva analisi. Ma non dobbiamo arrivare a tanto, almeno non all'inizio. All'inizio, per comprendere i principi del SIEM, basterà provare la meravigliosa utility gratuita Sysmon. Ed è sorprendentemente facile lavorare con lei. Continua così, Microsoft!

Quali funzionalità ha Sysmon?

In breve: informazioni utili e leggibili sui processi (vedi immagini sotto). Troverai una serie di dettagli utili che non sono presenti nel registro eventi di Windows, ma i più importanti sono i seguenti campi:

• ID processo (in decimale, non esadecimale!)
• ID del processo principale
• Riga di comando del processo
• Riga di comando del processo genitore
• Hash dell'immagine del file
• Nomi delle immagini dei file

Sysmon viene installato sia come driver di dispositivo che come servizio - maggiori dettagli qui. Il suo vantaggio principale è la capacità di analizzare i log da di pochi fonti, correlazione delle informazioni e output dei valori risultanti in una cartella del registro eventi situata lungo il percorso Microsoft -> Windows -> Sysmon -> Operativo. Nelle mie indagini da far rizzare i capelli sui registri di Windows, mi sono ritrovato a dover passare costantemente, ad esempio, dalla cartella dei registri di PowerShell alla cartella Sicurezza, sfogliando i registri degli eventi nel coraggioso tentativo di correlare in qualche modo i valori tra i due . Non è mai un compito facile e, come ho capito poi, era meglio fare subito scorta di aspirina.

Sysmon fa un salto di qualità fornendo informazioni utili (o, come amano dire i fornitori, utilizzabili) per aiutare a comprendere i processi sottostanti. Ad esempio, ho avviato una sessione segreta wmiexec, simulando il movimento di un insider intelligente all'interno della rete. Questo è ciò che vedrai nel registro eventi di Windows:

Il registro di Windows mostra alcune informazioni sul processo, ma è di scarsa utilità. Inoltre gli ID di processo in esadecimale???

Per un professionista IT professionista con una conoscenza delle basi dell'hacking, la riga di comando dovrebbe essere sospetta. Usare cmd.exe per eseguire poi un altro comando e reindirizzare l'output su un file con un nome strano è chiaramente simile alle azioni del software di monitoraggio e controllo comando e controllo (C2): In questo modo viene creata una pseudo-shell utilizzando i servizi WMI.
Ora diamo un'occhiata alla voce Sysmon equivalente, notando quante informazioni aggiuntive ci fornisce:

Le funzionalità di Sysmon in uno screenshot: informazioni dettagliate sul processo in forma leggibile

Non vedi solo la riga di comando, ma anche il nome del file, il percorso dell'applicazione eseguibile, cosa ne sa Windows ("Windows Command Processor"), l'identificatore parentale processo, riga di comando il genitore, che ha avviato la shell cmd, nonché il nome file reale del processo principale. Tutto in un unico posto, finalmente!
Dal registro Sysmon possiamo concludere che con un alto grado di probabilità questa riga di comando sospetta che abbiamo visto nei registri “grezzi” non è il risultato del normale lavoro del dipendente. Al contrario, è stato generato da un processo simile a C2 - wmiexec, come ho detto prima - ed è stato generato direttamente dal processo del servizio WMI (WmiPrvSe). Ora abbiamo un indicatore che un utente malintenzionato remoto o interno sta testando l’infrastruttura aziendale.

Presentazione di Get-Sysmonlogs

Ovviamente è fantastico quando Sysmon mette i log in un unico posto. Ma probabilmente sarebbe ancora meglio se potessimo accedere ai singoli campi di registro in modo programmatico, ad esempio tramite i comandi di PowerShell. In questo caso, potresti scrivere un piccolo script PowerShell che automatizzi la ricerca di potenziali minacce!
Non sono stato il primo ad avere un'idea del genere. Ed è positivo che in alcuni post del forum e GitHub progetti È già stato spiegato come utilizzare PowerShell per analizzare il log Sysmon. Nel mio caso, volevo evitare di dover scrivere righe separate di script di analisi per ciascun campo Sysmon. Quindi ho usato il principio dell'uomo pigro e penso di aver ottenuto qualcosa di interessante come risultato.
Il primo punto importante è la capacità della squadra Get-WinEvent leggi i log Sysmon, filtra gli eventi necessari e invia il risultato alla variabile PS, come qui:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Se vuoi testare tu stesso il comando, visualizzando il contenuto nel primo elemento dell'array $events, $events[0].Message, l'output può essere una serie di stringhe di testo con un formato molto semplice: il nome del Campo Sysmon, due punti e quindi il valore stesso.

Evviva! Output del log Sysmon in un formato pronto per JSON

Stai pensando la mia stessa cosa? Con un piccolo sforzo in più, puoi convertire l'output in una stringa formattata JSON e poi caricarla direttamente in un oggetto PS utilizzando un potente comando ConvertFrom-Json .
Mostrerò il codice PowerShell per la conversione, è molto semplice, nella parte successiva. Per ora, vediamo cosa può fare il mio nuovo comando chiamato get-sysmonlogs, che ho installato come modulo PS.
Invece di immergerci in profondità nell'analisi del registro Sysmon attraverso una scomoda interfaccia del registro eventi, possiamo cercare facilmente l'attività incrementale direttamente da una sessione di PowerShell, nonché utilizzare il comando PS where (alias – “?”) per abbreviare i risultati della ricerca:

Elenco delle shell cmd avviate tramite WMI. Analisi delle minacce a basso costo con il nostro team Get-Sysmonlogs

Meravigliosa! Ho creato uno strumento per interrogare il registro Sysmon come se fosse un database. Nel nostro articolo su EQL è stato notato che questa funzione sarà svolta dalla simpatica utility in essa descritta, anche se formalmente ancora attraverso una vera e propria interfaccia di tipo SQL. Sì, EQL elegante, ma ne parleremo nella terza parte.

Analisi di Sysmon e dei grafici

Facciamo un passo indietro e pensiamo a ciò che abbiamo appena creato. In sostanza, ora disponiamo di un database di eventi di Windows accessibile tramite PowerShell. Come ho notato in precedenza, esistono connessioni o relazioni tra i record, tramite ParentProcessId, quindi è possibile ottenere una gerarchia completa di processi.

Se hai letto la serie "Le avventure del malware sfuggente" sai che gli hacker amano creare attacchi complessi in più fasi, in cui ogni processo gioca il suo piccolo ruolo e prepara un trampolino di lancio per il passo successivo. È estremamente difficile cogliere queste cose semplicemente dal registro “grezzo”.
Ma con il comando Get-Sysmonlogs e un'ulteriore struttura dati che esamineremo più avanti nel testo (un grafico, ovviamente), abbiamo un modo pratico per rilevare le minacce, che richiede solo la corretta ricerca dei vertici.
Come sempre con i nostri progetti blog DYI, più lavori sull'analisi dei dettagli delle minacce su piccola scala, più ti renderai conto di quanto sia complesso il rilevamento delle minacce a livello aziendale. E questa consapevolezza è estremamente punto importante.

Le prime interessanti complicazioni le incontreremo nella seconda parte dell'articolo, dove inizieremo a collegare tra loro gli eventi Sysmon in strutture molto più complesse.

Fonte: habr.com