Questo articolo è la prima parte di una serie sull'analisi delle minacce di Sysmon. Tutte le altre parti della serie:
Parte 1. Introduzione all'analisi dei log di Sysmon (siamo qui)
Parte 2. Utilizzo dei dati dagli eventi Sysmon per identificare le minacce
Parte 3. Analisi approfondita delle minacce di Sysmon tramite grafi
Se ti occupi di sicurezza informatica, è probabile che ti capiti spesso di dover esaminare gli attacchi in corso. Se hai già un occhio esperto, puoi cercare attività anomale nei log "grezzi" non elaborati — ad esempio, uno script PowerShell con il comando oppure uno script VBS che si finge un file Word, semplicemente scorrendo l'ultima attività nel registro eventi di Windows. Ma è davvero un gran dolore. Per fortuna, Microsoft ha creato Sysmon, che semplifica notevolmente l'analisi degli attacchi.
Vuoi capire le idee di base dietro le minacce visualizzate nel log di Sysmon? Scarica la nostra guida e comprenderai come gli insider possono osservare silenziosamente altri dipendenti. Il principale problema nel lavorare con il registro eventi di Windows è la mancanza di informazioni sui processi padre, cioè non si può capire la gerarchia dei processi. Negli eventi del log di Sysmon, al contrario, sono presenti l'identificatore del processo padre, il suo nome e la riga di comando eseguita. Grazie, Microsoft.
Nella prima parte della nostra serie, vedremo cosa si può fare con le informazioni di base di Sysmon. Nella seconda parte sfrutteremo appieno le informazioni sui processi padre per creare strutture di corrispondenza più complesse, conosciute come grafi delle minacce. Nella terza parte esamineremo un semplice algoritmo che scansiona il grafo delle minacce per cercare attività anomale analizzando il "peso" del grafo. E alla fine, come premio, ti aspetta un metodo di rilevamento delle minacce probabilistico ordinato (e comprensibile).
Parte 1: Introduzione all'analisi dei log di Sysmon
Cosa aiuterà a districarsi nelle complessità del registro eventi? Alla fine, SIEM. Essa normalizza gli eventi e semplifica la loro analisi successiva. Ma non è necessario andare così lontano, almeno per il primo periodo. All'inizio, per comprendere i principi di SIEM, è sufficiente provare la fantastica utilità gratuita Sysmon. E sorprendentemente è facile lavorarci. Brave, Microsoft!
Quali sono le funzionalità di Sysmon?
In sintesi, informazioni utili e leggibili sui processi (vedi le immagini qui sotto). Troverai un sacco di dettagli utili che non sono nel registro eventi di Windows, ma la cosa più importante sono i seguenti campi:
- ID processo (in forma decimale, non esadecimale!)
- ID del processo padre
- La riga di comando del processo
- La riga di comando del processo padre
- Hash dell'immagine del file
- Nomi delle immagini dei file
Sysmon viene installato sia come driver di dispositivo che come servizio – maggiori dettagli Il suo principale vantaggio è la possibilità di analizzare i log da diverse fonti, correlare informazioni e produrre i risultati in un unico registro eventi, situato nel percorso Microsoft -> Windows -> Sysmon -> Operativo. Nelle mie indagini sui log di Windows, da far rabbrividire, dovevo costantemente passare tra, per esempio, la cartella dei log di PowerShell e la cartella 'Sicurezza', sfogliando i registri eventi in un eroico tentativo di confrontare i valori tra di loro. Questo non è affatto un compito facile, e come ho capito in seguito, era meglio avere subito dell'aspirina.
Sysmon compie invece un notevole passo avanti, fornendo informazioni utili (o come piace dire ai fornitori – efficaci) per aiutare a comprendere i processi fondamentali. Ad esempio, ho avviato una sessione nascosta , simulando il movimento di un insider intelligente all'interno della rete. Ecco cosa vedrai nel registro eventi di Windows:
Nel registro di Windows si vede qualche informazione sul processo, ma è poco utile. Inoltre, gli identificatori dei processi sono in forma esadecimale???
Un professionista IT che comprende le basi dell'hacking dovrebbe sospettare la riga di comando. L'uso di cmd.exe per eseguire un altro comando con il reindirizzamento dell'output in un file con un nome strano - appare chiaramente come un'azione di software di controllo e gestione : in questo modo si crea un pseudo-shell utilizzando i servizi WMI.
Ora diamo un'occhiata all'equivalente della registrazione di Sysmon, prestando attenzione a quante informazioni aggiuntive ci fornisce:
Le capacità di Sysmon in uno screenshot: informazioni dettagliate sul processo in forma leggibile
Non solo vedete la riga di comando, ma anche il nome del file, il percorso dell'applicazione eseguibile, cosa sa Windows su di essa ("Windows Command Processor"), l'identificatore del processo padre, la riga di comando del padre, che ha avviato il shell cmd, così come il vero nome del file del processo padre. Tutto in un unico posto, finalmente!
Dai log di Sysmon possiamo concludere che con un alto grado di probabilità questa riga di comando sospetta, che abbiamo visto nei log "grezzi", non è il risultato del normale lavoro di un dipendente. Al contrario, è stata generata da un processo simile a C2 — wmiexec, come ho accennato in precedenza — ed è stata direttamente creata dal processo del servizio WMI (WmiPrvSe). Ora abbiamo un indicatore che un attaccante remoto o un insider sta testando l'infrastruttura aziendale.
Presentiamo Get-Sysmonlogs
È sicuramente fantastico quando Sysmon ha i log in un unico posto. Ma sarebbe forse ancora meglio se potessimo accedere ai singoli campi del log in modo programmatico — ad esempio, tramite comandi PowerShell. In questo caso, potremmo scrivere un piccolo script PowerShell che automatizzerebbe la ricerca di potenziali minacce!
Non sono stato il primo a avere un'idea del genere. E va bene che in alcuni post sui forum e su GitHub sia già stato spiegato come utilizzare PowerShell per analizzare i log di Sysmon. Nel mio caso, volevo evitare la necessità di scrivere righe separate di script di parsing per ogni campo di Sysmon. Quindi ho utilizzato il principio dell'uomo pigro e, come mi sembra, alla fine ho inventato qualcosa di interessante.
Il primo punto importante è la possibilità del comando di leggere i log di Sysmon, filtrare gli eventi necessari e restituire il risultato in una variabile PS, come qui:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Se desideri controllare autonomamente il funzionamento del team, puoi ottenere una serie di righe di testo con un formato molto semplice usando il contenuto del primo elemento dell'array $events, $events[0].Message: nome del campo Sysmon, due punti e poi il valore stesso.
Evviva! Uscita del log Sysmon in un formato pronto per JSON
Stai pensando la stessa cosa che penso io? Con un po' più di sforzo, puoi convertire l'uscita in una stringa formattata per JSON e poi caricarla direttamente in un oggetto PS utilizzando il potente comando .
Mostrerò il codice PowerShell per la conversione — è molto semplice — nella prossima parte. Ma per ora, diamo un'occhiata a cosa può fare il mio nuovo comando chiamato get-sysmonlogs, che ho installato come modulo PS.
Invece di approfondire l'analisi dei log Sysmon attraverso l'interfaccia scomoda del registro eventi, possiamo cercare senza sforzo l'attività incrementale direttamente dalla sessione PowerShell, utilizzando anche il comando PS (alias - «?») per abbreviare i risultati della visualizzazione:
Elenco delle shell cmd lanciate tramite WMI. Analisi delle minacce a basso costo con il nostro comando Get-Sysmonlogs.
Incredibile! Ho creato uno strumento di interrogazione del log Sysmon, come se fosse un database. Nel nostro articolo su è stato notato che questa funzione sarà eseguita dall'utilità fantastica descritta, anche se formalmente tramite un'interfaccia SQL-like reale. Sì, EQL è elegante, ma ne parleremo nella terza parte.
Sysmon e analisi grafica
Asturiamo e pensiamo a cosa abbiamo appena creato. Fondamentalmente, ora abbiamo un database di eventi Windows accessibile tramite PowerShell. Come ho già menzionato, ci sono connessioni o relazioni tra le registrazioni — tramite ParentProcessId — quindi possiamo ottenere un'intera gerarchia di processi.
Se hai letto la serie sai che gli hacker amano creare attacchi complessi a più fasi, in cui ogni processo svolge il proprio piccolo ruolo e prepara il terreno per il passo successivo. Cose del genere sono estremamente difficili da catturare semplicemente dai log «grezzi».
Ma con il mio comando Get-Sysmonlogs e la struttura dati aggiuntiva che esamineremo più avanti (certo, è un grafo), avremo un modo pratico per rilevare le minacce - per fare ciò è necessario solo eseguire la giusta ricerca sui vertici.
Come sempre nei nostri progetti di blog DYI, più lavorate sull'analisi dei dettagli delle minacce su piccola scala, meglio vi rendete conto di quanto sia complessa la rilevazione delle minacce a livello organizzativo. E questa consapevolezza è estremamente importante.
Incontreremo le prime interessanti complessità nella seconda parte dell'articolo, dove inizieremo a collegare gli eventi Sysmon in strutture molto più complesse.
Fonte: habr.com
