Rilevamento efficace dei beacon C2

Introduzione

Gli aggressori stanno aggiungendo ai propri malware nuove e sofisticate funzionalità di comando e controllo (C2), in grado di eludere facilmente le comuni difese statiche basate su firme IPS o elenchi di blocco IP/dominio/url, utilizzando strumenti di framework C2 comuni e ampiamente disponibili, come Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver e Merlin. Questi strumenti forniscono funzionalità post-exploitation, tra cui comando e controllo, escalation dei privilegi e azioni sull’host, ed erano stati originariamente progettati per attività di penetration testing e operazioni di red team.

Tuttavia, gli aggressori hanno sottratto e integrato questi stessi toolkit per scopi malevoli, poiché molti prodotti sono open source, come Mythic e Merlin, mentre altri prodotti commerciali, come Cobalt Strike e Brute Ratel, sono stati sottratti dagli aggressori tramite copie compromesse o codice sorgente divulgato. Ciò ha di fatto trasformato questi stessi strumenti in framework C2 avversari per attività post-exploitation malevole.

Gli strumenti possono modellare e modificare facilmente molti parametri delle comunicazioni C2, consentendo al malware di eludere le difese attuali con ancora maggiore facilità e per periodi più lunghi, causando danni più gravi all’interno delle reti delle vittime, tra cui il furto di una maggiore quantità di dati, l’individuazione di dati più preziosi, l’indisponibilità di app/servizi aziendali e il mantenimento di un accesso nascosto alle reti per causare danni futuri.

Gli approcci attuali per rilevare il malware più recente che utilizza framework C2 impiegano firme e indicatori statici, tra cui il rilevamento degli eseguibili degli impianti, firme IPS per rilevare il traffico C2 e filtri IP/URL, che risultano inadeguati a gestire i profili dinamici e malleabili degli strumenti di framework C2 ampiamente disponibili.

È necessario un nuovo approccio che non sia legato in modo così rigido agli attacchi noti, ma che si basi sul rilevamento delle anomalie di un insieme completo di segnali forniti a modelli di apprendimento automatico addestrati, con un monitoraggio granulare del rischio di dispositivi e utenti. Questo approccio integrerà quelli esistenti, ma può aumentare notevolmente i tassi di rilevamento mantenendo bassi i falsi positivi e garantendo una maggiore resilienza futura rispetto all’evoluzione dei modelli di traffico C2, facilmente abilitata da questi stessi strumenti di framework C2.

Questo documento analizza le lacune degli approcci attuali e la maggiore efficacia ottenuta utilizzando un approccio mirato basato sull’apprendimento automatico, con segnali di rete aggiuntivi e metriche di rischio granulari basate su modelli a livello di utente e organizzazione. Vengono inoltre esaminate alcune delle principali difficoltà nel verificare l’efficacia di qualsiasi soluzione di rilevamento dei beacon C2.

Framework C2 avversari

Cobalt Strike, Metasploit, Mythic e Brute Ratel sono alcuni degli strumenti commerciali e open source di simulazione degli avversari, originariamente progettati per i test di red team sul rilevamento del malware. Questi toolkit vengono talvolta definiti strumenti di emulazione delle minacce o framework C2, poiché forniscono un ricco insieme di funzionalità (Gill) per simulare attività di minaccia reali durante le operazioni di red team, concentrandosi sulle componenti post-exploitation di comando e controllo della catena di attacco.

Nel corso del documento potremmo utilizzare alcuni di questi termini in modo intercambiabile, ma in generale useremo framework C2 per sottolineare che questi strumenti vengono impiegati da soggetti malevoli per colpire gli ambienti di produzione e che il problema da risolvere va ben oltre le simulazioni o le emulazioni effettuate da red team interni autorizzati.

Questi strumenti di framework C2 sono stati integrati, compromessi o sottratti e utilizzati da numerosi aggressori (“Cobalt Strike: un’operazione internazionale delle forze dell’ordine contrasta gli utilizzi illegali dello strumento di pentesting «coltellino svizzero»”), compresi soggetti legati a Stati nazionali come l’APT29 russo nel caso SolarWinds (“L’attacco alla supply chain di SolarWinds utilizza la backdoor SUNBURST”) e il TA415 della RPC (Larson e Blackford), per potenziare e far evolvere le funzionalità di comunicazione furtiva di vari RAT, botnet e malware con funzionalità C2.

Cobalt Strike è lo strumento di framework C2 più diffuso e viene utilizzato come esempio specifico in tutto il documento, sebbene le osservazioni si applichino a tutti gli strumenti simili. Il seguente diagramma dell’architettura di alto livello di Cobalt Strike mostra i suoi componenti di base (Rahman) e il flusso di attacco durante l’esecuzione.

Cobalt Strike e toolkit simili consentono di configurare facilmente e in modo molto ampio il traffico HTTP/S, producendo traffico C2 che spesso appare benigno, assomiglia al normale traffico HTTP/web ed è simile al traffico dei browser web o delle applicazioni più diffuse. Gli strumenti includono configurazioni predefinite che emulano sia malware noto sia applicazioni valide note.

Sebbene anche DNS sia supportato come protocollo C2, la discussione si concentrerà sul C2 tramite HTTP/S, poiché rappresenta la maggior parte del traffico di rete in entrata e in uscita da un’organizzazione, è più complesso a causa della varietà di applicazioni che utilizzano HTTP/S e attira la maggior parte dei soggetti malevoli che cercano di nascondersi nel rumore della rete, compresi i beacon C2 legittimi e benigni.

I toolkit sono altamente configurabili tramite profili malleabili e possono modificare facilmente la temporizzazione, la frequenza, il volume, i protocolli applicativi, gli IP/domini di destinazione, gli user agent, le intestazioni HTTP, i verbi HTTP, gli URI, i parametri, i certificati SSL/TLS, il ritardo del beaconing con jitter casuale e il payload/contenuto. Gli strumenti di framework C2 consentono inoltre numerose azioni post-exploitation, che vengono crittografate, scaricate ed eseguite in memoria, rendendo molto difficile rilevare sugli endpoint le attività successive alla compromissione.

Ci concentreremo sulle specifiche funzionalità di comunicazione C2 degli strumenti di framework C2, ad esempio il beaconing C2, sulla facilità con cui è possibile modificare le comunicazioni, ad esempio tramite i C2 Malleable Profiles di Cobalt Strike, e sulle difficoltà che devono affrontare le organizzazioni nel tentativo di rilevare malware furtivo.

Esistono diverse risorse valide che illustrano le funzionalità dei Malleable Profiles di Cobalt Strike (Gill), ma qui evidenzieremo alcune delle funzionalità più comunemente utilizzate. Di seguito è riportato un estratto del profilo malleabile utilizzato per imitare l’applicazione Gmail nel browser mediante Cobalt Strike (Mudge):

Alcune delle principali funzionalità e aree del profilo sono:

# Use an existing certificate or generate a self-signed certificate as seen in the above example.

# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime “60000”;
set jitter “15”;

# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename “interprocess_##“;
set spawnto “userinit.exe”;

# The uri path used for beacon->server communications can be varied with a list
set uri “//scs/mail-static//js/”;

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
    metadata {}
    header {}
}

# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
    header {}
}

# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {}    optional stager to download full Beacon
# 1. http-get {client}  client  — call home -> server
# 2. http-get {server}  server  — cmds -> client
# 3. http-post {client} client  — cmd output -> server
# 4. http-get {server}  server  — confirm -> client

Come si può osservare, semplici modifiche a questi profili possono cambiare facilmente il comportamento delle comunicazioni C2 per imitare applicazioni comuni, i relativi beacon e il traffico web. Solo per Cobalt Strike esistono più di 240 profili malleabili pubblici, immediatamente disponibili per l’uso o facilmente modificabili.

Approcci di rilevamento attuali

Gli approcci attuali per rilevare il traffico C2 malevolo tendono a confrontare firme di byte codificate in modo rigido oppure a utilizzare espressioni regolari per confrontare payload o intestazioni (firme IPS), oppure si basano sul confronto con elenchi di IP/domini/URL. Questi approcci sono statici e vengono facilmente elusi grazie alla natura dinamica e configurabile dei toolkit di framework C2 integrati dagli aggressori.

Firme IPS

Per illustrare le difficoltà delle soluzioni IPS, di seguito viene mostrata una delle regole Snort per rilevare il trojan Zeus (Snort):

Snort e molte soluzioni IPS consentono diversi confronti del contenuto o delle intestazioni ai livelli 3 e 4, oltre che a livello applicativo, come indicato dai verbi di azione nella regola. Molti confronti, come l’opzione di regola content, sono confronti statici di byte/caratteri, mentre l’opzione di regola pcre esegue un confronto mediante espressione regolare.

Osservando affiancati sia il lato dell’avversario, ad esempio il C2 Malleable Profile per gmail mostrato in precedenza, sia quello difensivo, ad esempio la regola Snort per Zeus, risultano evidenti la rigidità e la fragilità del confronto statico codificato. Si immagini che un aggressore abbia creato e distribuito una nuova variante di Zeus che utilizza Cobalt Strike e che un IPS Snort disponga della regola Zeus precedente, capace di rilevare efficacemente il nuovo malware. L’aggressore potrebbe modificare facilmente un solo carattere nel profilo, ad esempio aggiungendo uno spazio in MSIE per evitare la corrispondenza: content:"|3B 20|MSIE|20|"; in questo modo, il malware potrebbe eludere la firma IPS.

Sebbene siano presenti consapevolezza contestuale e monitoraggio dello stato, l’approccio basato sulle firme IPS è intrinsecamente limitato a causa del confronto statico, che genera falsi negativi e consente una facile elusione: letteralmente, la modifica di un solo carattere in un campo potrebbe aggirare una regola IPS.

Ciò non significa che le soluzioni IPS non siano utili. Al contrario, le firme IPS dovrebbero essere mantenute, poiché costituiscono un’utile difesa perimetrale e bloccano numerosi exploit di rete noti in modo rapido ed efficiente. In questo caso, anche se un IPS raggiungesse un tasso di rilevamento solo del 60%, quel 60% potrebbe essere facilmente bloccato o segnalato, evitando costose elaborazioni successive.

Elenchi di blocco IP/URL

Altri approcci tradizionali, come l’uso di elenchi di blocco IP o URL, vengono spesso applicati nel tentativo di impedire l’accesso iniziale o il download di malware durante la navigazione web, oltre che per bloccare il potenziale traffico C2.

Una difficoltà comune degli elenchi di blocco è che spesso non sono aggiornati, causano falsi positivi e sono reattivi, poiché vengono aggiornati dopo la compromissione dell’obiettivo n. 1 o del paziente zero.

Il problema è aggravato dalle tecniche di indirezione IP/dominio utilizzate per nascondere il dominio o l’indirizzo IP del server C2. Cobalt Strike dispone di redirector, che possono essere semplici proxy IP, per offuscare il vero dominio o IP del server C2. Esistono inoltre altre tecniche, come il domain fronting mediante CDN o il domain masquerading, che sfruttano le differenze tra TLS (SNI) e HTTPS (host) per nascondere il dominio malevolo finale ad alcuni filtri di sicurezza URL.

Euristiche del traffico di rete

Un approccio diverso prevede l’uso di euristiche, generalmente applicate ai modelli del traffico di rete in base al volume o al tempo. L’esempio classico consiste nel rilevare comunicazioni in uscita regolari, ad esempio ogni 60 minuti, magari verso un indirizzo IP privo di un record DNS A registrato.

Per eludere il rilevamento, i toolkit di framework C2 consentono di configurare facilmente un fattore casuale nel ritardo del beaconing mediante l’impostazione jitter di un Cobalt Strike Malleable Profile:

Figura 4: impostazioni del C2 Malleable Profile (temporizzazione del beaconing)

Queste impostazioni specificano un intervallo di connessione al server remoto di 60 secondi +/- 15%, il che significa che l’intervallo effettivo varierà da 51 a 69 secondi, eludendo i semplici controlli del beaconing ricorrente a intervalli costanti.

Efficacia

Il problema degli approcci attuali è che non rilevano efficacemente le comunicazioni C2 malleabili e vengono facilmente elusi anche quando sono configurati in modo specifico. Sono utili per rilevare in modo efficiente tecniche di attacco statiche con indicatori ben noti, ma non rilevano gli attacchi più dinamici o sofisticati oppure generano un numero elevato di falsi positivi.

Come dato di riferimento, durante i test dei Cobalt Strike C2 Malleable Profiles più comuni provenienti da repository pubblici, le soluzioni IPS predefinite come Snort e Suricata hanno rilevato una percentuale notevolmente inferiore al 20% delle comunicazioni C2 generate dai toolkit di framework C2 più comuni.

Anche dopo aver aggiunto regole specifiche per rilevare il maggior numero possibile di profili pubblici, ottimizzando la configurazione per questo particolare test, la copertura poteva aumentare ragionevolmente solo fino a circa il 60%, senza introdurre falsi positivi significativi che sarebbero stati molto problematici in un ambiente di produzione.

Esistono numerosi problemi relativi all’efficacia: non solo un maggior numero di falsi positivi, ma anche una configurazione risultante costruita rigidamente per il test specifico in questione e facilmente elusa mediante lievi modifiche ai profili. Inoltre, alla fine circa il 40% dei profili continua a non essere rilevato, una percentuale di falsi negativi molto elevata. Senza contare gli ulteriori falsi negativi causati da un aggressore determinato che personalizzi i profili C2 per imitare applicazioni esistenti e ben note in modo leggermente diverso.

Nuovo approccio di rilevamento

È necessario un approccio più efficace, non basato esclusivamente su indicatori statici, ma su modelli mirati di apprendimento automatico in grado di rilevare anomalie nel traffico di rete utilizzando numerosi segnali di rete che indicano attività sospette di comando e controllo, rispetto al normale comportamento delle applicazioni valide per gli utenti specifici all’interno dell’organizzazione specifica. Inoltre, è necessario monitorare metriche di rischio granulari a livello di utente per adottare le azioni di mitigazione più precise ed efficaci. Sono necessarie innovazioni in queste tre aree per migliorare notevolmente il rilevamento del beaconing C2 furtivo generato dagli strumenti di framework C2:

Segnali completi

È necessario un insieme completo di segnali che includa caratteristiche di origine, destinazione e traffico, come i certificati SSL/TLS utilizzati sia all’origine, ossia dal malware all’interno dell’ambiente, sia alla destinazione, ossia dal server C2, dominio/IP/URL, caratteristiche dell’origine come user agent/caratteristiche dei processi, dimensioni/picchi/modelli del traffico, intestazioni HTTP/payload/URI, solo per citarne alcuni.

Esaminando vari segnali relativi a tempo, volume, livelli di rete e profilazione complessiva del traffico, il rilevamento comportamentale può offrire un meccanismo generale ed efficace per rilevare il malware più recente attraverso attività di beaconing C2 sospette e malevole.

I tipi di segnali presentano diverse dimensioni:

• Flusso di rete: attributi di origine e destinazione, oltre ai modelli di traffico
• Livelli di rete: segnali diversi dal livello 3 al 7, comprese anomalie nelle intestazioni TCP/IP, nelle impronte SSL/TLS, nelle intestazioni e nei payload HTTP e nei contenuti a livello applicativo
• Tempo: frequenza e modelli temporali anomali per rilevare attività poco frequenti e lente
• Dati: contenuto e volume, comprese dimensioni anomale dei pacchetti, picchi e statistiche cumulative

Esistono inoltre diversi tipi di segnali:

• Basati sui modelli di traffico (volume, temporizzazione, contenuto), compreso il beaconing ripetuto insieme a user agent o domini insoliti.
• Euristiche (ad esempio, registrar sospetti o impronte SSL malevole note)
• Anomalie (domini, user agent o impronte SSL insoliti)

Un aspetto importante è che alcuni dei segnali precedenti fanno parte degli approcci attuali e delle soluzioni esistenti. Ciò rafforza il concetto secondo cui un determinato segnale, come un picco di traffico o un volume elevato, non è di per sé né buono né cattivo, né efficace né inefficace. Il fattore determinante è invece il contesto e l’elaborazione del segnale. Se utilizzato al perimetro di rete per bloccare o consentire il traffico, un segnale soggetto a falsi positivi può causare gravi problemi operativi. Tuttavia, se viene fornito a un sistema di rilevamento delle anomalie che lo integra in una metrica di rischio granulare, descritta di seguito, e in un modello ben addestrato, può risultare estremamente efficace nel rilevare nuove minacce in modo robusto e con pochi falsi positivi.

Rilevamento delle anomalie

Per rilevare efficacemente il beaconing C2 generato dai toolkit di framework C2 sono necessari modelli di apprendimento automatico basati su una gamma più completa di segnali, in grado di identificare i toolkit di framework C2 attuali e i futuri comportamenti di rete sospetti che potrebbero indicare attività C2.

Il rilevamento delle anomalie dovrebbe basarsi su modelli a livello di utente/dispositivo, ruolo e organizzazione. In altre parole, le anomalie presuppongono l’esistenza di una baseline valida dell’attività o del comportamento «normale» da utilizzare per il confronto. Il rilevamento delle attività sospette può avvenire in circostanze diverse. Esistono anomalie basate sul confronto tra le azioni di un utente e la sua baseline «normale» storica, la baseline «normale» dell’organizzazione oppure il comportamento delle persone con ruoli simili. Tutti questi casi d’uso sono validi e indipendenti dagli altri; un buon approccio integrerà più modelli con ambiti diversi.

Dati di addestramento

I set di dati di addestramento dovrebbero includere traffico sia malevolo sia benigno:

• Traffico malevolo: può essere simulato utilizzando strumenti generali di test C2, test specifici del beaconing C2 avversario basati sulle configurazioni pubblicamente disponibili degli strumenti di framework C2, nonché configurazioni personalizzate dal punto di vista di un red team ed esercitazioni ufficiali del red team.
• Traffico benigno: il traffico valido viene raccolto al meglio da un numero significativo di utenti reali presso organizzazioni reali, per un periodo sufficiente a normalizzare le distorsioni relative agli utenti e all’organizzazione.

I set di dati di addestramento sono il rovescio della medaglia dei set di dati di test e occorre dedicare molto tempo all’analisi e alla convalida di dati validi per l’addestramento e i test. Alcuni dei fattori necessari per creare set di dati di test validi vengono discussi in una sezione successiva.

Metriche di rischio granulari

L’output del rilevamento delle anomalie è fondamentale. L’approccio migliore non esegue semplici determinazioni di blocco/consenso o segnalazione/silenzio basate su un segnale grezzo, ma monitora e modifica metriche di rischio granulari a livello di utente, ruolo e organizzazione, che possono quindi essere utilizzate per azioni correttive come segnalazione, formazione o blocco.

Questo approccio al monitoraggio e alla gestione del rischio è fondamentalmente diverso da quello utilizzato normalmente oggi. La maggior parte delle difese perimetrali preventive, che generalmente bloccano, segnalano o consentono il traffico, è statica e soggetta a un elevato tasso di falsi positivi. Il risultato finale è che queste soluzioni vengono abilitate con criteri conservativi per bloccare rischi certi e noti, lasciando così spazio a un gran numero di falsi negativi. Con i firewall, si osservano problemi di falsi positivi dovuti ad azioni di blocco eccessivamente aggressive basate sulla threat intelligence relativa agli IP. Per le soluzioni IPS, abbiamo esaminato le difficoltà relative ai falsi positivi generate dalle firme statiche nel tentativo di rilevare traffico C2 altamente configurabile e dinamico.

Tuttavia, i falsi positivi a livello perimetrale possono essere molto utili come segnale per un livello più intelligente. In questo scenario, non verrebbero utilizzati per una valutazione binaria, come consentire/bloccare o segnalare/ignorare, ma come metrica di rischio granulare modificata nel tempo, ad esempio un punteggio di rischio dell’utente, con una soglia ottimizzata prima di intraprendere un’azione. Una metrica di rischio granulare, ad esempio un punteggio di rischio compreso tra 1000, nessun rischio, e 0, rischio estremo, relativo a un utente, un dispositivo o persino un indirizzo IP, consente di modellare lo spettro di grigi associato alle minacce reali, per le quali raramente esistono valutazioni chiaramente malevole al 100% o benigne al 100%.

A livello concettuale, ciò è rappresentato nell’illustrazione seguente, in cui potrebbero essere rilevati tre segnali diversi che, singolarmente, sarebbero soggetti a falsi positivi. Tuttavia, se associati a un rischio incrementale e valutati da un modello di apprendimento automatico ottimizzato, gli stessi segnali consentono di valutare il rischio cumulativo nel tempo e, infine, di ottenere un rilevamento delle anomalie con un elevato livello di affidabilità.

Si noti che i segnali di questo esempio potrebbero non essere semplici segnali statici. Ad esempio, un «dominio insolito, un user agent non riconosciuto e un certificato SSL/TLS» potrebbero costituire un’anomalia se confrontati con la precedente baseline «normale» del traffico di quello specifico utente, con utenti che ricoprono ruoli professionali simili o con l’intera organizzazione. Un «registrar sospetto» può essere una combinazione della reputazione del dominio correlata nel tempo. Inoltre, il «beaconing periodico» non consiste più nel semplice confronto con una frequenza o durata fissa, ma può rilevare attività anomale, regolari e ripetute entro una finestra temporale, simili alle attività correlate ai bot piuttosto che alle connessioni in uscita valide dei daemon applicativi.

In pratica, ciò consente di modificare un punteggio di rischio in modo incrementale e appropriato sulla base di un segnale a bassa affidabilità. Non viene intrapresa alcuna azione di blocco o segnalazione finché il punteggio di rischio cumulativo non supera una soglia elevata e ottimizzata. Ciò consente di individuare i casi in cui sono presenti molti indicatori a bassa affidabilità e lievemente rischiosi che, se combinati con un indicatore a maggiore affidabilità e rischio più elevato per un determinato utente o dispositivo, generano cumulativamente un avviso e un’azione per rischio critico con una probabilità di falsi positivi notevolmente inferiore.

Valutazione e test

Un nuovo approccio può essere teoricamente valido ma fallire miseramente nella pratica, e molto spesso la prova dipende dai dati o dai test. I fornitori di soluzioni e le organizzazioni alla ricerca di soluzioni necessitano di un approccio robusto per testare le nuove minacce e valutare le soluzioni. Per ottenere risultati precisi, è essenziale eseguire test con un set di dati diversificato che includa traffico sia malevolo sia benigno.

Traffico benigno

Il traffico benigno dovrebbe essere realistico, completo e simile a quello di produzione in termini di numero di utenti e attività. Il traffico valido, spesso dipendente dagli utenti, dovrebbe essere studiato su un ampio campione di utenti e per un periodo di tempo ragionevole. Questo set di dati di test misurerà i tassi di falsi positivi (FP). Le principali variazioni nei set di dati saranno rappresentate dai segnali del client, come le applicazioni, gli user agent e i certificati SSL/TLS client utilizzati; dai segnali di destinazione presenti nei domini/indirizzi IP di destinazione; e dai segnali relativi ai modelli di traffico nelle intestazioni, nel payload, nelle dimensioni e nella temporizzazione.

La buona notizia è che il traffico benigno valido può essere raccolto facilmente dalle operazioni quotidiane degli utenti dell’organizzazione; la cattiva notizia è che deve essere convalidato come benigno. L’approccio pratico consiste nel campionare statisticamente il traffico benigno fino a raggiungere un ragionevole livello di affidabilità, quindi dedicare la maggior parte del tempo agli avvisi generati dalla soluzione di rilevamento C2 sottoposta a test, verificandoli come veri positivi o falsi positivi. In altre parole, occorre inizialmente campionare e verificare i dati per creare una baseline, presumere che il set di dati benigno sia pulito e quindi procedere all’identificazione dei falsi positivi sulla base dei test.

Traffico malevolo

L’utilizzo di profili pubblici provenienti da strumenti di framework C2 diffusi fornisce una base solida per testare il traffico malevolo. Questi profili rappresentano configurazioni pratiche e utilizzate di frequente che eludono le difese e contribuiscono a misurare i tassi di falsi negativi (FN). Tuttavia, occorre prestare molta attenzione alla creazione di un set di dati rappresentativo del «traffico malevolo», poiché possono esistere diversi livelli di copertura e diversi elementi verificati dai set di dati, come illustrato nel diagramma seguente:

1. Strumenti di simulazione di violazioni e attacchi, come SafeBreach, sono eccellenti per i test di copertura e i test ripetuti. I relativi casi di test C2 includono generalmente almeno una simulazione delle attività dei framework C2. Il vantaggio è la disponibilità di un’ampia gamma di funzionalità, tra cui attacchi malware generici, GUI e architetture ben progettate, oltre a procedure e report di test ripetibili. Questi strumenti possono fornire numerosi scenari, tra cui attività lente e a basso volume, comunicazioni verso infrastrutture IaaS/CSP, traffico HTTP e non HTTP, traffico SSL/HTTPS e spoofing di diversi user agent.
2. Strumenti di framework C2 (profili pubblici). I test approfonditi dei framework C2 richiedono un’attività mirata. Un approccio consiste nel creare un set di dati di test basato sugli specifici profili pubblici degli strumenti di framework C2, ad esempio Cobalt Strike. Questi profili malleabili pubblici tendono a essere ampiamente condivisi e utilizzati da numerosi utenti e soggetti malevoli, poiché includono emulazioni utili di applicazioni benigne come gmail. Questo approccio offre generalmente test più completi relativi agli specifici framework C2.
3. Strumenti di framework C2 (profili personalizzati). La personalizzazione interna dei C2 Malleable Profiles può fornire test ancora più realistici dei framework C2. Queste configurazioni personalizzate possono essere create durante le operazioni interne del red team. Ciò richiede più lavoro e investimenti, poiché gli operatori del red team devono conoscere approfonditamente gli strumenti di framework C2.
4. Attacchi realistici. I test più realistici prevedono test black-box con attività esterne di penetration testing o programmi bug bounty. In questi scenari, i requisiti dell’esercitazione vengono definiti attentamente in modo da richiedere o incentivare exploit POC effettivi che utilizzino specifici strumenti di framework C2 o qualsiasi comportamento di beaconing C2, con l’ulteriore requisito di evitare il rilevamento per un determinato periodo di tempo. Gli obiettivi delle esercitazioni non consistono soltanto nel testare i vettori di accesso iniziale, come avviene normalmente, ma anche nel concentrarsi sulle attività successive alla violazione, dimostrando la capacità di installare un payload backdoor con attività C2 comprovata. Ciò arricchisce il set di dati di test oltre i framework C2, può verificare codice POC per backdoor con comunicazioni C2 personalizzate e costituisce inoltre un test eccellente della resilienza di qualsiasi strumento di rilevamento rispetto a un «aggressore» esperto che utilizza TTP diversi o personalizzati.

I test possono prevedere uno o più approcci, ma è necessario scegliere esplicitamente come creare, raccogliere e convalidare i set di dati di test e come misurare i risultati previsti. La creazione e la raccolta dei set di dati di test sono molto importanti per consentire di automatizzare e ripetere facilmente i test.

Durante i test è inoltre fondamentale misurare metriche complete: veri e falsi positivi, veri e falsi negativi. Sebbene la raccolta di tutte le metriche possa sembrare ovvia, definire con precisione e misurare in modo chiaro e ripetibile è difficile e può portare a risultati fuorvianti.

Obiettivi per falsi positivi e falsi negativi

Per le nuove minacce elusive create dai framework C2, qualsiasi soluzione di rilevamento più recente sarà priva di tassi FP e FN ampiamente accettati. Tuttavia, è fondamentale definire obiettivi FP e FN. Con set di dati di test di qualità nota è possibile creare baseline per l’ambiente e gli utenti/dispositivi attuali, che consentono quindi di definire obiettivi ragionevoli rispetto a tali baseline.

Ad esempio, si supponga che un’organizzazione dotata soltanto di un IPS inizi a valutare nuove soluzioni di rilevamento C2 e non sia chiaro quali tassi FP/FN siano accettabili. L’organizzazione può comunque definire obiettivi ragionevoli seguendo una metodologia di test come la seguente:

• Creare dati di test di qualità per il traffico benigno sulla base dei dati di produzione e per il traffico malevolo sulla base, ad esempio, dei profili C2 malleabili pubblici per Cobalt Strike, convalidando manualmente campioni di tali set di dati.
• Creare una metodologia di test chiara e ripetibile definendo gli strumenti di test e misurazione.
• Misurare tutte le metriche (TP/TN/FP/FN) durante i test.
• Testare le nuove soluzioni e confrontare le metriche. Ad esempio, l’IPS potrebbe essere ottimizzato specificamente per ottenere tassi TP migliori per il traffico malevolo, garantendo però che vengano misurati e convalidati anche i tassi FP/TN/FN. In questo modo è possibile valutare correttamente l’efficacia delle diverse soluzioni, soprattutto in termini di impatto complessivo sull’organizzazione, come descritto nella sezione Impatto riportata di seguito.
• Testare nuovi set di dati ed effettuare confronti. Personalizzare i set di dati per riflettere modifiche ragionevoli apportate da un aggressore. Esistono diversi modi per farlo.
  • Ad esempio, durante i test di Cobalt Strike, i relativi C2 Malleable Profiles possono essere facilmente modificati per emulare le app benigne in modo leggermente diverso oppure per emulare app benigne completamente nuove utilizzate all’interno dell’organizzazione specifica. Ciò può essere fatto intercettando il traffico HTTP/S in uscita tramite un proxy.
  • Testare non uno, ma più strumenti di framework C2, poiché differiscono per funzionalità e tecniche. Anche l’utilizzo di uno strumento di framework C2 diverso costituisce una buona variazione, poiché la modellazione del traffico C2 sarà differente.
  • La creazione di un payload di test personalizzato con comunicazioni C2 scritte manualmente costituisce un ulteriore metodo per modificare i set di dati di test, ma richiede il massimo investimento in termini di tempo e risorse.

Test di resilienza

Testando nuovi set di dati con soluzioni diverse, si ottengono anche informazioni preziose sulla rigidità rispetto alla resilienza delle diverse soluzioni. In questo documento è stato evidenziato che gli approcci codificati in modo rigido e basati sulle firme non solo sono meno efficaci nel rilevare i framework C2, ma sono anche rigidi, generano tassi FP/FN elevati e consentono una facile elusione mediante semplici modifiche all’attacco, come le modifiche ai profili malleabili.

La resilienza di qualsiasi soluzione può essere verificata assicurandosi che i set di dati vengano modificati entro limiti ragionevoli, ossia rimanendo nella stessa categoria TTP. In altre parole, è possibile eseguire un test di resilienza realistico modificando le comunicazioni C2 all’interno del set di dati del traffico malevolo mediante profili C2 malleabili e monitorando i tassi TP/TN/FP/FN. In questo modo è possibile osservare come varia la copertura e comprendere quali modifiche siano necessarie nella soluzione di rilevamento per mantenere la copertura rispetto a specifici obiettivi TP/TN/FP/FN.

La ripetizione dei test con set di dati modificati in questo modo è analoga alla modifica delle TTP da parte di un aggressore. Consente di valutare la resilienza e l’efficacia della nuova soluzione di rilevamento, verificando se è ancora in grado di rilevare le modifiche all’interno della stessa categoria di tecnica di minaccia, ossia le comunicazioni C2 tramite HTTP/S.

Impatto dei falsi positivi e dei falsi negativi

La misurazione dei tassi FP/FN è utile e consente di rilevare miglioramenti relativi, ma è anche necessario misurare o almeno stimare l’impatto degli FP e degli FN; in caso contrario, è impossibile valutare la reale utilità di qualsiasi soluzione di rilevamento. In altre parole, un tasso FP dell’1% o un miglioramento del 5% del tasso FP non hanno alcun contesto, a meno che non sia possibile misurare l’impatto di quell’1% o +5% in un modo significativo per i responsabili delle decisioni relative al budget per la sicurezza.

Di seguito sono riportati due approcci che possono contribuire a tradurre i tassi TP/TN/FP/FN in un impatto maggiormente quantificabile:

1. Impatto sugli utenti nel tempo: considerare il numero assoluto di falsi positivi equivalente ai tassi FP e normalizzarlo come tasso per utente nel tempo. Si tratta di una misura qualitativa, ma spesso è più significativa delle percentuali o dei numeri assoluti. Ad esempio, invece dell’1% di FP o di 2.437 falsi positivi, potrebbe essere più facile valutare l’impatto di 0,1 falsi positivi per utente al giorno. Se si trattasse di un secure web gateway, un responsabile dell’organizzazione potrebbe determinare se un determinato obiettivo FP sia accettabile in base all’impatto sugli utenti nel tempo. In questo caso, il malware abilitato dai framework C2 causa violazioni e l’impatto sugli utenti è caratterizzato principalmente da tempi di inattività o perdita di dati per utente in un determinato periodo. Esiste una probabilità pari a N% di una perdita di $X per utente ogni anno. Si tratta spesso di stime approssimative, ma qualsiasi punto di partenza è utile, poiché può essere rivisto e migliorato mediante iterazioni regolari. Se l’impatto viene valutato in termini di utenti nel tempo, diventa facile valutare le soluzioni di rilevamento o protezione, spesso tariffate in base al numero di utenti per anno.
2. Impatto sulle Security Operations in termini di tempo, denaro e probabilità di violazione. Oltre all’impatto sugli utenti finali, è necessario valutare l’impatto amministrativo, in particolare sul personale operativo che spesso dedica tempo alla gestione degli avvisi di rilevamento. Il tempo impiegato per rispondere ad avvisi rumorosi può essere tradotto direttamente nel costo salariale FTE. L’ulteriore fattore dell’affaticamento da avvisi è un impatto reale che può essere stimato in termini di efficacia, ossia tempo di risposta, e soprattutto come perdita di tempo e attenzione rispetto alle minacce realmente più gravi, che vengono perse o non analizzate. Quest’ultimo impatto diventa un fattore nell’impatto delle violazioni: è più probabile che si verifichino violazioni quando le operazioni di sicurezza devono analizzare ed eliminare un numero eccessivo di falsi positivi.

Una valutazione dell’impatto è spesso l’unico modo per comprendere informazioni fondamentali, come il costo reale derivante dall’efficacia del rilevamento. Ad esempio, una soluzione di rilevamento eccessivamente aggressiva con una configurazione caratterizzata da pochi FN e molti FP è inutile e dannosa, perché le operazioni di sicurezza sprecano una quantità eccessiva di tempo rispondendo ad avvisi a bassa affidabilità invece di dedicarsi ad attività di maggiore valore. Analogamente, una soluzione di rilevamento eccessivamente conservativa con pochi FP ma molti FN espone l’organizzazione a un rischio elevato di potenziale violazione, che può risultare inaccettabile dal punto di vista della valutazione complessiva del rischio.

L’impatto dovrebbe essere stimato e valutato contemporaneamente alle metriche principali TP/FP/TN/FN.

Test realistici

Utilizzare un red team composto da persone, non soltanto strumenti automatizzati di simulazione delle violazioni o di penetration testing. È vivamente consigliato utilizzare non solo utenti e ambienti di produzione per testare le soluzioni di beaconing C2, ma anche scenari avversari realistici, come penetration testing o bug bounty. Modificando gli importi delle ricompense e i requisiti in modo da richiedere esplicitamente l’impianto e l’esecuzione riuscita di azioni post-exploitation mediante toolkit di framework C2 diffusi, è possibile rendere il «traffico malevolo» reale e misurabile. L’ambito potrebbe essere esteso a qualsiasi attività di beaconing C2, compreso codice personalizzato, per verificare la resilienza della soluzione di rilevamento; inoltre, il requisito del test dovrebbe includere la dimostrazione di attività quotidiane di beaconing e dell’esecuzione di comandi per una settimana senza rilevamento.

Se un penetration test esterno o un programma bug bounty viene ripetuto, le differenze nei tassi di rilevamento saranno misurabili e utili per valutare l’efficacia e il ROI.

Con un approccio rigoroso ai test, non solo sarà possibile misurare in modo completo l’efficacia, ma anche definire obiettivi e traguardi continuativi rispetto a una baseline attuale/storica. Inoltre, se gli stessi test e le stesse misurazioni vengono eseguiti su più soluzioni, confrontare le prestazioni e prendere decisioni di acquisto/implementazione diventa semplice.

Considerazioni sulla progettazione

La ricerca e la progettazione relative a questi concetti e all’approccio complessivo sono esaminate più dettagliatamente in: Sistemi e metodi di sicurezza per rilevare comunicazioni malleabili di comando e controllo (Mulugeta).

Vantaggi

Rilevamento delle anomalie di nuove minacce sconosciute

Questo approccio mitiga efficacemente le minacce sconosciute sfruttando modelli di apprendimento automatico addestrati sul comportamento delle applicazioni specifico degli utenti all’interno di un’organizzazione. La metrica granulare del rischio dell’utente riduce significativamente i falsi positivi.

Al contrario, gli approcci reattivi esistenti si basano sull’identificazione di una prima vittima o paziente zero, un soggetto sacrificato per il bene comune, seguita dall’analisi e dalla ricerca del fornitore, che possono richiedere giorni o persino mesi, prima che il fornitore rilasci una nuova firma o regola per bloccare la nuova minaccia per i clienti che non sono ancora stati attaccati. Per sua natura, questo approccio è inefficace nel bloccare le minacce malleabili nuove ed emergenti.

Un approccio di rilevamento delle anomalie che sfrutta modelli di apprendimento automatico specifici e ottimizzati può rilevare in modo univoco i comportamenti sospetti senza richiedere un ciclo di analisi, rilascio e aggiornamento. L’approccio mantiene la propria robustezza anche con l’evoluzione delle tattiche delle minacce.

Analisi completa dei segnali

Il rilevamento delle anomalie in un insieme completo di segnali, come tempo, volume, comunicazioni TCP/IP, fingerprinting SSL/TLS e payload dei protocolli applicativi, può rilevare efficacemente comunicazioni C2 malleabili sofisticate.

Rilevamento dei toolkit avversari

Questo approccio può rilevare efficacemente l’uso degli strumenti di framework C2 e dei framework C2 più recenti, oltre alle attività di beaconing C2 nuove e sospette, facendo affidamento sul rilevamento delle anomalie mediante un’ampia gamma di segnali di rete specifici degli utenti presenti nell’ambiente e confrontandoli con il traffico valido e benigno nell’ambiente.

Efficacia del rilevamento

Gli approcci attuali, ossia firme IPS + blocchi IP/dominio/URL, non rilevano un’elevata percentuale delle comunicazioni C2 avanzate presenti nel malware più recente, dal 40% fino all’80% a seconda degli scenari di test.

Utilizzando un nuovo approccio con un modello di apprendimento automatico ottimizzato, il rilevamento delle anomalie di un ricco insieme di segnali e una metrica di rischio granulare, è possibile rilevare più dell’85-95% di questi attacchi attualmente elusi.

Ciò determina un tasso complessivo di rilevamento dei veri positivi superiore al 95%, con falsi positivi minimi.

Conclusione

I toolkit di framework C2 hanno fornito agli aggressori tecniche sofisticate per eludere il rilevamento del comando e controllo (C2). In particolare, toolkit ampiamente disponibili come Cobalt Strike, Brute Ratel e Mythic sono accessibili come codice open source oppure come codice commerciale compromesso o sottratto.

Gli approcci statici tradizionali, che fanno ampio affidamento su firme e indicatori statici come gli elenchi di blocco IP/URL, presentano gravi limitazioni e vengono facilmente aggirati da queste minacce in continua evoluzione.

Per affrontare questa difficoltà, è necessario un approccio fondamentalmente diverso che sfrutti modelli di apprendimento automatico. Questi modelli incorporano un insieme completo di segnali di rete e vengono addestrati specificamente sia a livello di utente sia di organizzazione. Utilizzano inoltre metriche granulari del rischio dell’utente per ridurre i falsi positivi e misurare le sfumature spesso associate alle minacce.

L’efficacia degli approcci basati sull’apprendimento automatico dovrebbe essere valutata attentamente dagli utenti. Test rigorosi su un ambiente di prova robusto contenente traffico malevolo e benigno sono essenziali per determinarne l’efficacia nel rilevare e mitigare queste nuove minacce.

Riferimenti

1. “Cobalt Strike: un’operazione internazionale delle forze dell’ordine contrasta gli utilizzi illegali dello strumento di pentesting «coltellino svizzero».” The Record from Recorded Future News, 3 luglio 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Consultato il 23 agosto 2024.
2. Gill, Andy. “Comprendere i profili di Cobalt Strike – Aggiornato per Cobalt Strike 4.6.” ZSEC Blog, 13 aprile 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Consultato il 23 agosto 2024.
3. Larson, Selena, e Daniel Blackford. “Cobalt Strike: lo strumento APT preferito per il crimeware.” Proofpoint, 29 giugno 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.
4. Mudge, Raphael. “Malleable C2 Profiles: gmail.” Malleable-C2-Profiles normal gmail.profile, rsmudge, 28 febbraio 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.
5. Mulugeta, Dagmawi. “Sistemi e metodi di sicurezza per rilevare comunicazioni malleabili di comando e controllo.” Free Patents Online, 20 agosto 2024, https://www.freepatentsonline.com/12069081.html.
6. Rahman, Alyssa. “Cobalt Strike | Definizione dei componenti di Cobalt Strike e BEACON.” Google Cloud, 10 dicembre 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.
7. Snort. “SID 1:25050.” Regola Snort: connessione in uscita della variante MALWARE-CNC Win.Trojan.Zeus, https://www.snort.org/rule_docs/1-25050.
8. “L’attacco alla supply chain di SolarWinds utilizza la backdoor SUNBURST.” Google Cloud, 13 dicembre 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.