Contenuto di rilevamento proattivo: CVE-2019-0708 vs ATT&CK, Sigma, Elastic e ArcSight
Penso che la maggior parte della comunità di sicurezza abbia concordato che la vulnerabilità CVE-2019-0708 sia di priorità critica da affrontare. E mentre dire “aggiorna le tue cose!” sembra la prima cosa a cui si dovrebbe pensare, i ricordi di WannaCry e NotPetya sono ancora freschi nella mia mente. Sappiamo che l’applicazione delle patch non avverrà alla velocità e alla scala necessarie. E quindi stiamo, ancora una volta, costruendo le regole di rilevamento!
Un piccolo ma importante dettaglio: la vulnerabilità CVE-2019-0708 è correlata ai Servizi Desktop Remoto (RDS), quindi l’effettiva implementazione di Microsoft nell’uso del Protocollo Desktop Remoto (RDP) su Windows. Il protocollo RDP in sé è a posto. Sento che questa affermazione deve essere qui per evitare ogni tipo di clamore simile a quello visto durante l’epidemia di Wannacry.
L’hashtag “BlueKeep” è stato usato per la prima volta da Kevin Beaumount. L’ho scelto per 2 motivi: riferimento a GoT e per trovare post rilevanti su Twitter, poiché non si può semplicemente hashtagare un CVE (a meno che non si rimuovano i trattini). BlueKeep sta semplicemente rendendo più facile la twiterops 😉
https://twitter.com/GossiTheDog/status/1128348383704485895
Spostando la bilancia a favore dei difensori.
Per stabilire la teoria del rilevamento dobbiamo considerare due modelli di minaccia:
- Minaccia Worm, simile allo scenario di WannaCry.
- Attore APT, che utilizza la vulnerabilità come parte di una campagna più sofisticata, proprio come EternalBlue & SMB erano solo una parte del disastro NotPetya.
Per identificare le risorse a rischio ci riferiremo alla seguente tabella, condivisa per cortesia di Dragos:
fonte: https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/
Il CVE-2019-0708 può essere usato per l’accesso iniziale su vasta scala simile a Wannacry? Un rapido sguardo ai dati di Shodan rivela molte macchine su Internet con porta 3389 esposta e che eseguono versioni potenzialmente vulnerabili di Windows:
https://www.shodan.io/search?query=port:3389+os:”Windows+7+or+8″
https://www.shodan.io/search?query=port:3389+2003
https://www.shodan.io/search?query=port:3389+2008
https://www.shodan.io/search?query=port:3389+os:”Windows+XP”E in totale stiamo guardando a 2.375 milioni di host con RDP raggiungibile da internet – ma non trarre conclusioni troppo in fretta!
https://www.shodan.io/search?query=Remote+Desktop+Protocol
Citazione dal tweet di Dan Tentler del 23 aprile 2017 “non tutti quegli host sono Windows, e non tutte quelle porte sono smb”. Adattandolo ai giorni nostri “Non tutti quei 2.3 milioni di host sono Windows e non tutte quelle porte sono servizi vulnerabili al CVE-2019-0708”. Se confrontiamo questo con la timeline di WannaCry siamo nella fase in cui MS-17010 è già disponibile, EternalBlue non è ancora uscito e quindi non possiamo andare e cercare il prossimo DoublePulsar. E fino a quando non esisterà tale PoC e qualcuno eseguirà la scansione del backdoor presente, proprio come fece Dan 2 anni fa, non possiamo essere assolutamente certi che le cose stiano andando male. Tuttavia, stanno “per” arrivare a quel punto e forse abbiamo ancora 30 giorni per mettere in atto le difese, forse meno.
https://twitter.com/Viss/status/856227372785221632
Mentre possiamo discutere se quelle macchine siano usate da organizzazioni reali, il loro stato di patch, la segmentazione della rete ecc., è conoscenza comune che molte aziende operano ancora versioni vulnerabili di Windows e i cicli di patch possono essere duri per quei sistemi. Inoltre, rispetto a Wannacry, vediamo circa 24K+ host potenzialmente sfruttabili contro 140K+ host con DoublePulsar che affrontano internet 3 settimane prima dell’incidente.
Il pericolo maggiore a questo stadio è lo sfruttamento di CVE-2019-0708 una volta dentro l’organizzazione per compromettere rapidamente gli host e per il Movimento Laterale. E dato che l’Exploit PoC non è stato ancora rilasciato al momento della stesura di questo articolo (molti falsi però ci sono) useremo ogni strumento a nostra disposizione per costruire il rilevamento -prima- ancora che l’exploit venga fuori.
Considerando tutto quanto sopra le top-3 cose che puoi fare come difensore sono:
- Distribuire contenuti di rilevamento proattivi.
- Difendere rigorosamente l’aggiunta di patch o la mitigazione della vulnerabilità.
- Tieni traccia dello sviluppo della situazione seguendo input da ricercatori di cui ti fidi.
Per rinforzare alcuni dei punti vorrei riferirmi a 2 tweet di Florian Roth sul problema:
 |
 |
Regole Sigma, primo a soccorrere.
La prima regola, ulteriormente citata come Sigma #1, è stata condivisa per cortesia di Markus Neis al repo Github di Sigma per affrontare la tecnica di Movimento Laterale T12010 / Sfruttamento dei Servizi Remoti https://attack.mitre.org/techniques/T1210/ :
Nel giro di un’ora, una regola simile (Sigma #2) è stata pubblicata su SOC Prime TDM da Roman Ranskyi come community / libera da usare con alcune differenze nella logica di rilevamento che si estendono a T1036 / Mascheramento https://attack.mitre.org/techniques/T1036/ e T1046 / Scansione del Servizio di Rete https://attack.mitre.org/techniques/T1046/ .
Fondamentalmente abbiamo un rilevamento TLP:WHITE e TLP:GREEN là fuori, prima dell’exploit! Ma è sufficiente per rilevare un attacco su vasta scala?
Machine Learning, facendolo un passo avanti.
Esploriamo come le capacità di Machine Learning possono darci un certo vantaggio sul problema e partiamo con la creazione di una ricetta per Elastic stack.
ML Ricetta: Rilevare Movimento Laterale su RDP potenzialmente correlato a CVE-2019-0708
Teoria
Un numero eccessivo di indirizzi IP di destinazione unici nelle connessioni RDP avviate da un host durante una finestra temporale limitata può essere un’indicazione del Movimento Laterale e diffusione del worm che utilizza il protocollo RDP come metodo di propagazione (usando l’exploit RDS correlato alla vulnerabilità CVE-2019-0708).
Descrizione
Questa ricetta individuare gli indirizzi IP delle sorgenti che possono potenzialmente essere punti di propagazione del worm RDP o Movimento Laterale tramite RDP / T1076 attraverso segmenti di rete.
Efficacia
Questa ricetta è fornita come parte di un rilevamento proattivo automatizzato per la vulnerabilità di esecuzione di codice remoto nei Servizi Desktop Remoto (CVE-2019-0708) worm RDP ancora inesistente, che ci si aspetta sfrutti la vulnerabilità e usi RDP per il Movimento Laterale attraverso segmenti LAN interni. Informazioni aggiuntive sul comportamento del worm RDP, dopo averlo osservato in azione, possono essere utilizzate per il tuning della ricetta per produrre risultati di rilevamento più efficaci.
Tipo di Case d’Uso
Comportamento Base delle Minacce (EAB) – Questo case d’uso rileva anomalie associate ai comportamenti d’attacco base. Ogni anomalia rilevata riceve un punteggio di Anomalia normalizzato e viene annotata con i valori degli altri campi nei dati che hanno influenza statistica sull’anomalia. Comportamenti base delle minacce che condividono influenze statistiche comuni sono spesso legate a un avanzamento comune dell’attacco.
Fonte Dati del Case d’Uso
Eventi Netflow, log di flusso VPC di dati simili in formato ECS, che contengono log delle connessioni RDP tra host Windows all’interno di segmenti LAN interni.
Ricetta del Case d’Uso
| Per: | Connessioni RDP. |
| Modello: | Conteggio unico degli indirizzi IP di destinazione per ciascuno dei indirizzi IP sorgente. |
| Rileva: | Numero insolitamente alto di indirizzi IP di destinazione perun indirizzo IP sorgente specifico. |
| Confrontato con: | Popolazione di tutti gli indirizzi IP sorgente (il più alto registrato) nei risultati della query.Partiziona per: |
| Nessuno | None |
| Escludi: | None |
| Durata: | Esegui l’analisi sugli eventi Netflow per un periodo di 2 settimane opiù a lungo. |
| Ricette correlate: | None |
| Risultati: | Host influenzatori potrebbero essere scanner di vulnerabilità, host di salto o host compromessi che agiscono come sorgenti diworm RDP.propagazione di worm RDP. |
Caratteristiche di Input e Influencer Candidati
| Campo richiesto | Descrizione | Esempio |
| Source.ip | Sorgente della sessione RDP | 10.10.1.1 |
| Destination.ip | Destinazione della sessione RDP | 10.10.1.124 |
| Destination.port | Porta TCP che identifica la connessione RDP | 3389 |
Pattern di Indici Elasticsearch Esempio:ecs-netflow*Query Elasticsearch Esempio:“query”: {“term”: {“destination.port”: {“value”: 3389,”boost”: 1}}}
Analisi di Machine Learning / Configurazione del Rilevatore:
Rilevatore(i): high_distinct_count(destination.ip) su source.ip
Bucketspan: 15m
Influencer(s): source.ip
Esplorando i risultati di ML in Elastic stack.
La visualizzazione del singolo metrica ci trova i droni che stavamo cercando. Così, migliore sarà il dataset a disposizione, più accurata sarà la rilevazione degli outliers.
L’Anomaly Explorer aiuta a spiegare la storia delle connessioni RDP usuali rispetto a un comportamento worm-like o a un amministratore estremamente impegnato che potrebbe o meno lavorare per l’attore di minaccia APT 😉
Il suono caldo a tubo del motore di correlazione ArcSight.
A questo punto abbiamo definito chiaramente la logica di rilevamento, vediamo se possiamo applicarla alla tecnologia che molte aziende ancora utilizzano come strumento SIEM primario. Ci sono diversi compiti che cercheremo di risolvere riguardo la minaccia imminente:
- Identificare su base automatica le risorse a rischio.
- Tracciare attività RDP anomale sulle risorse sopra identificate.
- Tentare di rilevare il Movimento Laterale sfruttando regole Sigma e basate sul comportamento.
Compito #1: è dove possiamo fare affidamento su diverse funzioni in ArcSight.
Effettuare un elenco delle risorse vulnerabili a CVE-2019-0708 sfruttando il modello Asset & Network che (dovrebbe essere) popolato da qualsiasi scanner di vulnerabilità che fornisce output CEF (Qualys, Nessus o anche nmap faranno il trucco).
E se non abbiamo uno scanner? Possiamo tracciare gli host potenzialmente vulnerabili creando un filtro sugli asset Windows XP, 7, 2003 e 2008 sia su base modello Asset & Network che in base agli ID evento di Windows generati da quelle versioni che sono distinti dalle versioni più recenti di Windows.
Compito #2: per sostituire il Machine Learning faremo una regola che rileva eventi di Firewall e Netflow basati sulla Categorizzazione e memorizza gli IP di origine e destinazione RDP sulla Lista Attiva. In questo modo possiamo trovare la prima connessione da/a risorse potenzialmente/confermate vulnerabili. Inoltre, costruiremo Trend per profilare le connessioni RDP e rilevare Picchi di traffico in base al conteggio delle connessioni.
Compito #3: portando la regola Sigma #1 dalla query alla correlazione in tempo reale coprirà il rilevamento del Movimento Laterale T1210. Per realizzare questo, ho copiato la fonte Sigma #1 in Uncoder.io per produrre una query ArcSight. Una cosa bella delle query ArcSight è che avendo una certa conoscenza del linguaggio si può facilmente trasformare il codice in un filtro per la regola di correlazione in tempo reale.
Metti tutto insieme e collegalo al tuo SOC!
Per ArcSight i pezzi di contenuto sopra sono legati in un’unica dashboard che dovrebbe rimanere vuota durante le operazioni normali. Per far partire gli eventi sul canale principale del SOC aggiungi una regola leggera per consumare gli avvisi correlati dal canale attivo “Dettagli Evento di Correlazione”.
Per SOC basato su Elastic abbiamo aggiunto una semplice dashboard Kibana. Essa visualizza i picchi RDP e il visual di Machine Learning per trovare outliers basati sul traffico netflow oltre a dettagli sui trigger delle regole Sigma, host impattati ecc.
Se stai già usando la dashboard SOC Prime per la gestione di Watcher puoi esplorare i dati attraverso il prisma di MITRE ATT&CK e effettuare un pivot tra Tattiche, Tecniche, Utenti, Computer colpiti, osservare la Timeline dell’attacco, gestire Watcher, fare pivot su regole Sigma e casi tramite l’app SOC Workflow. Tutto questo senza mai lasciare l’interfaccia Kibana.
Elastic, ArcSight o Sigma?
Se utilizziamo solo ATT&CK come benchmark, Elastic è il vincitore essendo una tecnica avanti.
Il vantaggio principale dello stack Elastic è la sua capacità di combinare sia il Machine Learning sia moderne query di Threat Hunting basate su Sigma. Ricorda che il refactoring delle regole Sigma in query di correlazione in tempo reale non trova Masquerading / T1036 su ArcSight.
Tuttavia, vale la pena notare che è effettivamente più facile configurare ArcSight per sfruttare dati da scanner di vulnerabilità per la correlazione interdispositivo. Combinato con tutte le altre fonti log nel pacchetto di rilevamento può essere più efficace per molte organizzazioni.
Se guardiamo al compito dal punto di vista della velocità e del costo di sviluppo del rilevamento Sigma guida chiaramente la strada. Finché il tuo SIEM o EDR supporta Sigma o hai log Sysmon da tutte le tue macchine inclusi XP, 7, 2003 e 2008 questa sarà una soluzione ottimale per te. Una volta ancora, il vantaggio di un pacchetto di rilevamento più ampio rispetto a una singola regola si basa principalmente sul nostro presupposto che un attacco reale utilizzerà RDP per il movimento laterale. Non esiste una taglia unica quando si tratta di rilevamento delle minacce. Il punteggio finale sarà impostato quando l’exploit funzionante reale sarà fuori e possiamo costruire il rilevamento, molto probabilmente utilizzando le regole Sigma. Alla fine della giornata, abbiamo costruito un contenuto di Rilevamento Proattivo basato su Regole e Machine Learning per il “Conosciuto Sconosciuto”, proprio come recentemente ha dichiarato il Dr. Anton Chuvakin nel suo post: https://blogs.gartner.com/anton-chuvakin/2019/04/30/rule-based-detection/ .
Non dimenticare la prevenzione e aggiorna le tue cose
Impara dagli errori degli altri, aggiornarlo in anticipo sarà tanto beneficiario quanto se avessi tutte le SMB aggiornate durante l’epidemia di Wannacry. Se ricevi un no dal team che gestisce le patch, distribuisci i rilevamenti, testa i backup e delega il rischio. https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/
Link a contenuti di rilevamento gratuiti e mappature a MITRE ATT&CK
- Sigma #1 di Markus Neis https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_susp_rdp.yml Movimento Laterale; T1210; fonti di log: microsoft sysmon.
- Sigma #2 di Roman Ranskyi https://tdm.socprime.com/tdm/info/2159/ Movimento Laterale, Evasione Difensiva, Scoperta; T1210, T1036, T1046; fonti di log: microsoft sysmon.
- Pacchetto di regole ArcSight .ARB https://tdm.socprime.com/tdm/info/2160/ Movimento laterale, Scoperta; T1210, T1046, T1076; fonti di log: firewall, netflow, scanner di vulnerabilità, registri MS Active Directory, Sysmon.
- Pacchetto di regole Elastic stack https://tdm.socprime.com/tdm/info/2160/ Movimento laterale, Evasione della difesa, Scoperta; T1210, T1036, T1046, T1076; fonti di log: netflow, registri MS Active Directory, Microsoft Sysmon.
Edizione della community di SOC Workflow App: https://github.com/socprime/soc_workflow_app_ce
/Stai al sicuro
