Indicatore dei periodi effettivi di compromesso [chiuso]

Spesso agli analisti di malware viene chiesto di correlare retroattivamente gli IoC. Gli IoC recentemente correlati sono tornati al codice cinese a partire dal 2002. Solo pochi mesi fa, abbiamo rilevato significativi IoC che legavano una comunità di minacce ai suoi predecessori a partire dal 2006. Senza la possibilità di tenere traccia di tutti questi IoC nel corso degli anni, ci sarebbe non è stata una correlazione.

Esistono anche modi per valutare gli IoC:

Livello 1: hash SHA2, ASN BGP, nomi host
Livello 2: hash MD5 + SHA1, prefissi IPv4 / IPv6
Livello 3: nomi Mutex, Imphashes
Livello 4: regole di Yara
Livello 5: somiglianze di file, classi o blocchi (ad es., Icewater, GCluster.py, TLSH o ssdeep fuzzy hash)
Livello 6: Apiscout e tecniche di analista di malware di livello principale

Il malware tende a bypassare tutto quanto sopra in modi diversi. Alcuni malware possono persino mentire o ignorare tutto quanto sopra, simultaneamente. Sicuramente vuoi scalare i tuoi IoC quando lavori contro lo spazio di quella minaccia. Tuttavia, ti consigliamo anche di prendere in considerazione fattori che i computer non possono scalare: l'elemento umano, la sorpresa e le indicazioni.

Forse intendi, per quanto tempo dovresti monitorare IoC sulla rete? O intendi in sweep attraverso una flotta?

Se stai cercando un modo per gestire gli IoC sulla rete, controlla il Bro Intelligence Framework . Per la gestione della flotta di oggetti IoC ci sono alcuni strumenti, come Viper per il database e la visualizzazione di IoC classici, YaraGuardian per l'organizzazione e la ricerca delle regole Yara, Timesketch a giocare con i dati, così come i modi di raccogliere risorse e dati di log di mining / monitoraggio.

Ci sono molti modi per approcciare la raccolta di artefatti e log, oltre a monitoraggio, analisi e sintesi. Mi piace il modo in cui questi professionisti delineano 3 approcci - link - in particolare attraverso i loro toolsets quali Automated Containment and Enrichment (ACE Server), Hunting ELK (HELK) e UpRoot. Vedrai le tecniche da questi set di strumenti in piattaforme commerciali, come Infocyte, Splunk Enterprise Security e Carbon Black Cb Response, rispettivamente. Se vuoi davvero scalare le scansioni di flotte di IoC, allora ACE Server, InfoCyte e forse anche gli strumenti PowerForensics o PowerShell Kansa sono i miei suggerimenti per il primo round.

WannaCry è uscito 90 giorni dopo l'annuncio della vulnerabilità EternalBlue. Se avessi smesso di cercare gli IoC EternalBlue dopo 90 giorni, avresti perso la vista di WannaCry.

Inoltre, alcuni malware o tecniche persistono per anni perché le reti possono essere lente ad adattarsi, quindi funzionano ancora. Se smetti di cercarli, perderai preziose informazioni sulle minacce.

Se disponi degli strumenti corretti, dovresti essere in grado di gestire la manutenzione IoC a lungo termine. Alcuni IoC sono intrinsecamente limitati nel tempo (come gli IoC che dipendono da Internet), quindi potrebbero avere una vita breve.

Altrimenti, mi sembra che se hai strumenti automatici per rilevare e rispondere a IoC, o puoi bloccarli prima che si manifestino (anti-malware, firewall, IDS, ecc.), allora puoi (forse) fermarti cercandoli attivamente sugli strati di rilevamento che si verificano dopo tali controlli tecnici.

Dipende ciò che stai cercando di rilevare, davvero. Ciò potrebbe significare che cerchi un ambiente solo per gli indicatori esistenti, se sei abbastanza sicuro che qualcosa è stato compromesso e vuoi sapere se l'autore dell'attacco è andato oltre, o potrebbe significare continuare a guardare gli indicatori su base continuativa, se stai provando a rilevare proattivamente le intrusioni.

Ad esempio, se una particolare stringa inviata a un server HTTP consente a un utente malintenzionato di bloccarsi, come soluzione temporanea, potrebbe essere utile configurare un firewall per bloccare quella stringa sui server HTTP. Tuttavia, una volta risolto il server HTTP, in modo che la stringa non causi più problemi, probabilmente non ti interessa, se non per interesse puramente accademico, in modo da poter interrompere il monitoraggio per questo. L'indicatore è ancora valido (si dice "qualcuno conosce questa stringa e sta provando a causare un arresto anomalo"), ma non si applica più al proprio ambiente.

Allo stesso modo, in modo leggermente meno forzato, se stai monitorando il traffico proveniente da un determinato paese come probabile che sia malevolo, potrebbe essere necessario modificare questa regola se la tua azienda si espande in quel paese, il che significa che il traffico legittimo è anche provenienti dalla stessa fonte.

Ci sono alcuni casi in cui è necessario mantenere il monitoraggio essenzialmente per sempre: qualsiasi sistema può diventare l'obiettivo di un attacco DDoS con pochissimo preavviso, quindi riprendere le fasi iniziali e rispondere in modo appropriato richiede un monitoraggio continuo. Non puoi affermare "non saremo mai un obiettivo per gli attacchi DDoS", mentre puoi tranquillamente dire "non stiamo eseguendo SSH, quindi non è necessario monitorare il traffico potenzialmente pericoloso sulle porte SSH", come a condizione che desideri aggiornare il monitoraggio in caso di modifiche.

Se la qualità della tua intelligenza è elevata, non c'è alcun motivo (a parte i problemi relativi allo storage / alle prestazioni) che non dovresti mantenere gli indicatori indefinitamente.

Assicurati che vi sia un qualche tipo di convalida degli indicatori prima di agire e manterrai una buona minaccia per l'igiene.

L'infrastruttura dell'attaccante viene riutilizzata, quindi se stai seguendo la procedura di rimozione dopo 90 giorni, alla fine ti mancheranno eventi degni di nota.