Utilizzare gli strumenti NSM per analizzare le categorie di dati

Continuiamo con la nostra serie di articoli che, attraverso esempi pratici e semplificati, dimostrano l’applicazioni di strumenti fondamentali nei rispettivi ambiti. È il turno di Utilizzare gli strumenti NSM per analizzare le categorie di dati. Gli analisti all’interno di un SOC (Security Operation Center) hanno a disposizione molti strumenti diversi. Ogni SOC ha la propria suite di strumenti e ogni analista crea la propria suite di strumenti supplementari. In questo esercizio di laboratorio utilizzeremo varie funzionalità degli strumenti della distribuzione Linux di Security Onion.
Inizieremo eseguendo una riproduzione di un campione di traffico acquisito in precedenza sull’interfaccia di monitoraggio, senza dover effettivamente eseguire le azioni acquisite con il file PCAP:

Può essere complesso simulare un “incidente” di sicurezza.
La simulazione può richiedere numerose macchine e molte ore di lavoro.
Un’opzione per produrre rapidamente i dati di un “incidente”, senza dover impegnare così tante risorse, è l’uso del comando tcpreplay.
Security Onion fornisce molti file PCAP dimostrativi, simulando diversi tipi di eventi.
Il PCAP riprodotto in questo esercizio di laboratorio è la simulazione di markofu dell’hacking RSA.

Accediamo al desktop della macchina virtuale Security Onion e avviamo Sguil.
Quando ci viene chiesto di scegliere le interfacce da monitorare, scegliamo solo l’interfaccia so-eth1, su cui riprodurre il file outbound.pcap, quindi facciamo clic su Avvia Sguil:

Tramite il terminale riproduciamo il file /opt/samples/markofu/outbound.pcap PCAP sull’interfaccia di monitoraggio eth1 a una velocità di 50 pacchetti al secondo, utilizzando il comando tcpreplay.
La riproduzione dovrebbe richiedere circa 36 secondi per essere completata:

so@so:~$ sudo tcpreplay -p 50 -i eth1 /opt/samples/markofu/outbound.pcap
[sudo] password for so: Cisco123!
sending out eth1
processing file: /opt/samples/markofu/outbound.pcap
Actual: 1812 packets (1152828 bytes) sent in 36.26 seconds.
Rated: 31793.4 bps, 0.24 Mbps, 49.97 pps
Statistics for network device: eth1
Attempted packets: 1812
Successful packets: 1012
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0

Verifichiamo che siano presenti quattro avvisi sulla dashboard di Sguil.
In caso contrario, è probabilmente dovuto al fatto che il processo Snort non sia ancora completamente attivato. La VM di Security Onion può fornire un desktop utente prima che tutti i processi NSM siano completamente inizializzati. Se non ci sono avvisi in Sguil, aspettiamo semplicemente un paio di minuti e ripetiamo il passaggio tcpreplay:

Gli avvisi sono spesso sono i primi fattori da verificare, man mano che la caccia alle minacce diventa più comune nell’azienda, si riduce il tempo tra l’intrusione e il rilevamento. Indipendentemente dal cambiamento, gli avvisi continueranno ad essere una soluzione NSM efficace.
È possibile che si verifichino avvisi “falsi positivi” e “falsi negativi”, ma l’analista deve sempre ricordare che gli avvisi sono una chiamata da parte di uno strumento.

Visualizziamo quattro riepiloghi degli avvisi risultanti dalla riproduzione PCAP:
• Tutti gli avvisi specificano la stessa tupla IP a 5: TCP (protocollo 6), 172.16.150.20:1294 <-> 66.32.119.38:80. Tutti gli avvisi sono associati a una singola connessione TCP.
• Il secondo messaggio di avviso menziona esplicitamente una richiesta HTTP contenente due estensioni di file (.doc e .exe).
• PE a cui si fa riferimento nel terzo avviso è il formato Windows per un file eseguibile.
• Il termine “dotted quad” a cui si fa riferimento nel primo e nel quarto avviso è un modo complesso di comunicare l’indirizzo IP. Gli URL HTTP, che contengono indirizzi IP espliciti, hanno un certo grado di sospetto ad essi associati.
• Nel quarto avviso, ASCII MZ è il valore “magic bytes” che indica un file in formato eseguibile di Windows.

In questo caso, tutti i riepiloghi lavorano insieme per raccontare una storia coerente.
Un file eseguibile sospetto è stato scaricato dal client 172.16.150.20.
Decidiamo di esaminare più da vicino questo file.

CORSI CORRELATI:

• Corso Cyber Security;
• Corso CCNP Security SCOR;
• Corsi CCNP Security;
• Corso Penetration test;
• Corso Cisco CCNA;
• Corso Fortinet NSE4;
• Corso Fortinet NSE5;
• Corso Check Point CCSA;
• Corso Check Point CCSE;

Consulta il nostro Catalogo Corsi per Tecnologia oppure fai una Ricerca per Vendor o ancora trova uno specifico corso attraverso il motore di ricerca interno: Ricerca Corsi. Contattaci ora al Numero Verde 800-177596, il nostro team saprà supportarti nella scelta del percorso formativo più adatto alla tue esigenze.

Security Onion è configurato per conservare le acquisizioni complete dei pacchetti del traffico di rete sulle sue interfacce di rilevamento.
Per impostazione predefinita, Security Onion rimuove i file di acquisizione di pacchetti completi più vecchi quando l’utilizzo del disco supera la soglia del 90%.

È necessario prestare attenzione durante l’estrazione e l’utilizzo di file potenzialmente dannosi.
Esiste il rischio che l’analista possa infettare il proprio sistema o altri sistemi del SOC con malware.
Comprendere alcuni concetti di base dell’analisi del malware è importante, quindi verrà dimostrato qui.

Per ogni avviso, i dati del pacchetto non elaborati associati alla tupla IP 5 vengono estratti dai dati netsniff-ng e inseriti anche nel database Sguil.
La trascrizione mostrerà una decodifica ASCII dei dati grezzi del pacchetto:

• Le intestazioni HTTP rendono chiaro che il client ha richiesto /tigers/Brandonlnge/Diagnostics/swing-mechanics.doc.exe e il server sta rispondendo alla richiesta con un file di 8192 byte con un tipo di contenuto application / x-msdos-program.
• La maggior parte del contenuto del file è illeggibile ma le poche stringhe visibili sono sospette.
• SOFTWARE \ Classes \ http \ shell \ open \ command e SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run sembrano fare riferimento alle chiavi di registro di Windows.
• svchosts.exe (con una s) sembra essere il nome di un processo da nascondere tra i processi svchost.exe legittimi, ad esempio:

In Sguil, selezioniamo l’avviso interessato all’analisi, quindi facciamo clic con il pulsante destro del mouse sulla colonna ID avviso e selezioniamo Wireshark.
Esaminiamo le prime diverse righe nel riquadro di riepilogo del pacchetto.

I primi tre pacchetti sono l’handshake TCP a 3 vie.
• Il quarto pacchetto include la richiesta HTTP GET.
Puoi vedere il riferimento a un file denominato swing-mechanics.doc.exe.
• I pacchetti mostrano i dati inviati dal server al client e i l’avviso del client di conferma ricevimento dati.

Non è sicuro, né saggio, tentare di eseguire un potenziale malware sulla propria postazione per scopi di analisi e identificazione. Dovremmo invece fare affidamento su strumenti e servizi che offrono una sandbox per eseguire il malware all’interno. L’obiettivo è mettere correttamente in quarantena il malware dall’ambiente di produzione osservandone il comportamento.
Payload Security è un esempio di una soluzione sandbox gratuita per l’analisi del malware, consente a un analista di caricare un file sospetto per l’analisi.

Apriamo il terminale sulla VM di Security Onion.
Lanciamo il comando “strings” sull’eseguibile che abbiamo salvato utilizzando Wireshark. Saremo in grado di visualizzare tutte le stringhe stampabili dal file binario eseguibile.

L’eseguibile contiene un indirizzo IP (221.54.197.32), che può essere un indirizzo di richiamata per una shell inversa.
• Lo scopo probabile del nome svchosts.exe è quello di consentire a un processo dannoso di nascondersi tra i processi svchost.exe legittimi.
• HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run è un percorso di registro che può essere utilizzato per avviare file eseguibili all’avvio, comunemente utilizzato per fornire la persistenza del malware.

Estraiamo il file usando Wireshark.
Andiamo a File> Esporta oggetti> HTTP.
Viene visualizzato un elenco di tutti i file trasportati in HTTP.
Selezioniamo il file denominato swing-mechanics.doc.exe e facciamo clic su Salva con nome.
Selezioniamo la cartella Home nell’elenco dei luoghi, quindi clic su Salva:

A questo punto, se stessimo eseguendo un’analisi effettiva, avremmo dovuto consultare i dati della sessione per vedere se l’host interno 172.16.150.20 o altri host interni hanno comunicato con 221.54.197.32. In tal caso, è il momento di passare a un analista senior, ma lo scopo di questo laboratorio è acquisire ulteriore esperienza con il set di strumenti Security Onion. L’utilizzo di valori hash per riconoscere particolari file binari è una tecnica analitica molto potente. In precedenza, nel passaggio del lab Payload Security, veniva mostrato il valore hash SHA256. In questo passaggio di laboratorio, calcoleremo il valore hash SHA-1 di un file. Torniamo alla finestra del terminale. Utilizziamo il comando sha1sum per calcolare il valore hash SHA-1 del file swing-mechanics.doc.exe: