Gli analisti di sicurezza informatica sono sommersi da eventi di sicurezza che devono essere valutati, analizzati, correlati e classificati in ordine di priorità. Se sei un analista, probabilmente hai competenze incredibili, ma sei ostacolato da un lavoro manuale e noioso.
Nel mio ultimo blog ho parlato di un cliente nel settore manifatturiero, dove abbiamo aiutato il team blu a individuare il team rosso che utilizzava strumenti amministrativi esistenti per nascondere le proprie attività. Questa volta vorrei parlare delle nostre nuove funzionalità di ricerca delle minacce e di indagine approfondita.
Recentemente ho assistito il team di sicurezza di un cliente vittima di un phishing . Il mio obiettivo era quello di aiutarli a condurre un'indagine più approfondita su un evento che avevano inizialmente rilevato senza il mio aiuto. Sebbene sia molto bravo a individuare gli aggressori, il mio obiettivo è quello di potenziare le capacità umane affinché gli analisti della sicurezza possano diventare più rapidi ed efficienti nella ricerca delle minacce e nella risposta agli incidenti. La sicurezza è migliore quando lavoriamo insieme.
Ad ogni modo, abbiamo iniziato con un dipendente che ha ricevuto phishing , che richiedeva le credenziali di accesso a un sito web tramite un link incorporato in un PDF allegato. Una volta ottenute le credenziali di accesso, l'autore dell'attacco, fingendo di essere il dipendente, ha inviato una seconda phishing ad altri colleghi dell'azienda.
La seconda e-mail conteneva un altro PDF dannoso destinato a diffondere ulteriormente la presenza dell'autore dell'attacco all'interno dell'azienda. Fortunatamente, la seconda phishing è stata notata da un dipendente diligente e il team di sicurezza è stato immediatamente informato dell'incidente. Il team di sicurezza si è subito rivolto a Recall per indagare su quanto accaduto.
Analisi PDF e phishing
Archiviando i metadati di rete arricchiti in un indice ricercabile, ho consentito al team di sicurezza di approfondire i dettagli di quanto accaduto dopo che avevano sospettato di essere stati vittime di un phishing . Il team di sicurezza voleva comprendere meglio i dettagli del PDF sospetto per identificare malware nascosto.
Sebbene il PDF non contenesse alcun malware, l'indagine ha portato a un file ospitato da Office 365 e a un link a un phishing in cui al dipendente veniva richiesto di inserire le credenziali di Office 365.
L'autore del PDF e phishing sono stati identificati nei metadati che conservo per tutto il tempo necessario. Il nome dell'autore ha consentito al team di sicurezza di trovare documenti simili tramite ricerche open source.
Ho anche consentito al team di sicurezza di utilizzare le mie capacità di indagine sugli incidenti per individuare il phishing nell'e-mail originale e determinare quali dispositivi host comunicavano con quel dominio.
Dispositivi host primari
Per accelerare le indagini, ho correlato i metadati raccolti con dispositivi host e account specifici. Ciò ha consentito al team di sicurezza di effettuare ricerche basate su un nome specifico in un intervallo di dati specifico.
In questa indagine, il team di sicurezza ha identificato un intervallo di tempo in cui phishing è stata inviata per la prima volta. Questo ha segnato l'inizio della compromissione. Abbiamo quindi esaminato l'attività sull'account e sui dispositivi host correlati all'e-mail per vedere esattamente cosa è successo prima e dopo l'invio phishing .
Utilizzo di LDAP
La nostra indagine sui dispositivi host primari ha evidenziato due periodi anomali poco dopo la compromissione iniziale. Il primo periodo ha coinciso con un picco nel traffico LDAP su tutta la rete. Un'ulteriore analisi ha dimostrato che questo picco era presente in diversi dispositivi host secondari, ma non in tutti.
Analizzando il picco iniziale LDAP per gli host primari, è emerso un traffico ancora maggiore correlato alla ricognizione LDAP, segno di un comportamento anomalo. Il picco LDAP indicava che la minaccia era progredita nel ciclo di vita dell'attacco fino a raggiungere comportamenti di ricognizione e movimento laterale.
Utilizzo di DCE/RPC
Entrambi i dispositivi host hanno registrato picchi nel traffico DCE/RPC (Distributed Computing Environment/Remote Procedure Call) durante la compromissione. Nessuno di questi picchi corrispondeva ad aumenti a livello di rete nell'ambiente del cliente.
È importante notare che queste chiamate richiedono l'esecuzione di codice sui dispositivi host. Questo traffico è generato dalle applicazioni, dal sistema operativo o dagli script in esecuzione sui sistemi dei dispositivi host.
Analizzando uno dei picchi rilevati sui dispositivi host primari, abbiamo individuato un caso di oltre 10.000 chiamate in un periodo di 10 minuti che contenevano il tipo e il numero di richieste tipiche della ricognizione di Active Directory (AD).
Dispositivi host secondari
Dopo l'invio della comunicazione iniziale, i dispositivi host secondari hanno comunicato con il phishing . Picchi simili sono stati osservati poco dopo la comunicazione iniziale con il phishing .
Quasi tutte le comunicazioni provenivano da un dispositivo host secondario. Come per l'attività osservata con gli host primari, l'improvviso aumento delle richieste e il tipo di richieste indicavano comportamenti di ricognizione.
Conclusione
Dagli artefatti osservati e dalle indagini, il mio Recall hanno fornito al team di sicurezza un contesto conclusivo sull'attacco phishing e indicazioni dettagliate su come rispondere rapidamente.
Lavorando insieme, abbiamo determinato la portata della minaccia e identificato i dispositivi host a rischio prima che l'attacco potesse diffondersi ulteriormente e più in profondità all'interno della rete.