Gli analisti di cybersecurity sono sommersi da eventi di sicurezza che devono essere gestiti, analizzati, correlati e classificati come prioritari. Se siete analisti, probabilmente avete delle capacità incredibili ma siete frenati da un lavoro manuale e noioso.
Nel mio ultimo blog ho parlato di un cliente del settore manifatturiero in cui abbiamo assistito il team blu nell'individuazione del team rosso che utilizzava gli strumenti di amministrazione esistenti per nascondere i propri comportamenti. Questa volta voglio parlare delle nostre nuove funzionalità di threat hunting e deep investigation.
Di recente ho assistito il team di sicurezza di un cliente vittima di un attacco phishing . Il mio obiettivo era aiutarli a condurre un'indagine più approfondita su un evento che avevano inizialmente rilevato senza il mio aiuto. Sebbene io sia bravissimo a scovare gli aggressori, il mio obiettivo è quello di affiancare gli esseri umani, in modo che gli analisti della sicurezza possano diventare cacciatori di minacce e addetti alla risposta agli incidenti più rapidi ed efficienti. La sicurezza è migliore quando lavoriamo insieme.
In ogni caso, siamo partiti da un dipendente che ha ricevuto un'e-mail phishing , in cui si chiedevano le credenziali di posta elettronica per un link a un sito web incorporato in un PDF allegato. Una volta ottenute le credenziali di posta elettronica, l'aggressore, fingendosi un dipendente, ha inviato una seconda e-mail phishing ad altri dipendenti dell'azienda.
Il secondo messaggio di posta elettronica conteneva un altro PDF dannoso destinato a diffondere la posizione dell'aggressore all'interno dell'azienda. Fortunatamente, la seconda e-mail 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 sull'accaduto.
Analisi dei PDF e dominio phishing
Memorizzando metadati di rete arricchiti in un indice ricercabile, ho permesso al team di sicurezza di approfondire i dettagli di ciò che è accaduto dopo aver sospettato di essere stato vittima di un attacco phishing . Il team di sicurezza voleva capire meglio i dettagli del PDF sospetto per identificare il 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 sito web phishing in cui al dipendente veniva richiesto di inserire le credenziali di Office 365.
L'autore del PDF e il dominio phishing sono stati identificati nei metadati che vengono conservati per tutto il tempo necessario. Il nome dell'autore ha permesso al team di sicurezza di trovare documenti simili tramite ricerche open source.
Ho anche permesso al team di sicurezza di utilizzare le mie capacità di investigazione sugli incidenti per trovare il dominio phishing nell'e-mail originale e determinare quali dispositivi host comunicavano con quel dominio.
Dispositivi host primari
Per velocizzare l'indagine, ho messo in relazione i metadati raccolti con dispositivi e account host specifici. Questo ha permesso al team di sicurezza di effettuare una ricerca basata su un nome specifico in un intervallo di dati specifico.
In questa indagine, il team di sicurezza ha identificato una finestra temporale in cui l'e-mail 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 dell'e-mail 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 di traffico LDAP nell'intera rete. Un ulteriore esame ha mostrato che questo picco era presente in diversi dispositivi host secondari, ma non in tutti.
Analizzando il picco LDAP iniziale per gli host primari, è emerso un traffico ancora più intenso legato alla ricognizione LDAP, segno di un comportamento anomalo. Il picco LDAP indicava che la minaccia era progredita nel ciclo di vita dell'attacco fino alla ricognizione e al movimento laterale.
Utilizzo di DCE/RPC
Entrambi i dispositivi host hanno registrato picchi di 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 è guidato da applicazioni, dal sistema operativo o da script in esecuzione sui sistemi dei dispositivi host.
Scavando in un picco osservato con i dispositivi host primari, abbiamo trovato un caso di oltre 10.000 chiamate in un periodo di 10 minuti che conteneva 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 dominio phishing . Picchi simili sono stati osservati poco dopo la comunicazione iniziale con il dominio phishing .
Quasi tutte le comunicazioni provenivano da un dispositivo host secondario. Come l'attività riscontrata con gli host primari, l'improvviso aumento delle richieste e i tipi di richieste indicavano comportamenti di ricognizione.
Conclusione
Dai manufatti osservati e dall'indagine, il mio Recall hanno fornito al team di sicurezza un contesto conclusivo sull'attacco e-mail 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 in profondità all'interno della rete.