Libro bianco sul rilevamento efficace del beaconing C2

È necessario un set completo di segnali che dovrebbe includere caratteristiche di origine, destinazione e traffico, come certificati SSL/TLS utilizzati sia sull'origine (malware all'interno dell'ambiente) che sulla destinazione (server C2), dominio/IP/URL, caratteristiche di origine come caratteristiche dell'agente utente/processo, dimensioni/burstiness/modelli del traffico, intestazioni HTTP/payload/URI, per citarne solo alcune.

Quando si esaminano vari segnali nel tempo, nel volume, nei livelli di rete e nel profiling complessivo del traffico, il rilevamento comportamentale può fornire un meccanismo generale ed efficace per rilevare l'ultimo malware tramite attività di beaconing C2 sospette e malevole.

Figura 6: Segnali completi

Esistono diverse dimensioni per i tipi di segnale:

• Flusso di rete: attributi di origine e destinazione, così come modelli di traffico
• Livelli di rete: segnali diversi dal livello 3 al 7 (anomalie tra header TCP/IP, fingerprint SSL/TLS, header/payload HTTP e contenuti a livello applicativo)
• Tempo: frequenza, modelli di temporizzazione anomali per rilevare attività poco frequenti e lente
• Dati: contenuto e volume (dimensioni anomale dei pacchetti, burst, statistiche cumulative)

Esistono inoltre diversi tipi di segnale:

• Basato sul modello di traffico (volume, tempistica, contenuto), inclusi beaconing ripetuti in combinazione con user agent o dominio insoliti.
• Euristica (ad esempio, registrar sospetti o impronte digitali SSL dannose note)
• Anomalie (dominio insolito, user agent o impronte SSL o impronte digitali SSL)

Un punto importante è che alcuni dei segnali sopra menzionati fanno parte degli approcci attuali e delle soluzioni esistenti. Ciò rafforza l'idea che un segnale specifico, come un picco di traffico (volume elevato), non è né buono né cattivo, efficace o inefficace di per sé. Piuttosto, il contesto e l'elaborazione del segnale sono i fattori determinanti. Se utilizzato sul perimetro di una rete per bloccare/consentire il traffico, un segnale soggetto a falsi positivi può causare gravi problemi operativi. Tuttavia, se inserito in un sistema di rilevamento delle anomalie che incorpora tale segnale in una metrica di rischio granulare (discussa di seguito) e in un modello ben addestrato, può essere estremamente efficace nel rilevare New minacce in modo affidabile con un basso numero di falsi positivi.

La rilevazione efficace del C2 beaconing dai toolkit del framework C2 richiede modelli di apprendimento automatico basati su una gamma più ampia di segnali per identificare gli toolkit attuali del framework C2 e futuri comportamenti sospetti di rete che potrebbero indicare attività C2.

Figura 7: Rilevamento delle anomalie

Il rilevamento delle anomalie dovrebbe basarsi su modelli a livello di utente/dispositivo, ruolo e organizzazione. Cioè, le anomalie presuppongono che abbiamo una base "normale" valida di attività o comportamento con cui confrontare. Rilevare attività sospette può avvenire in circostanze diverse. Ci sono anomalie basate sulle azioni di un utente rispetto alla sua linea di base "normale" storica, o rispetto alla "normalità" dell'organizzazione o rispetto agli individui in ruoli simili. Tutti hanno i loro casi d'uso validi che escludono gli altri, e un buon approccio incorporerà più modelli con ambiti diversi.

I set di dati di addestramento dovrebbero includere sia il traffico dannoso che quello benigno:

• Il traffico malevolo può essere simulato utilizzando strumenti generali di test C2, specifici test di beaconing adversariali C2 basati su configurazioni pubbliche di strumenti del framework C2, oltre a configurazioni personalizzate dal punto di vista di un red team e esercizi ufficiali del red team.
• Il traffico benigno o valido viene raccolto al meglio da un numero significativo di utenti reali presso organizzazioni reali, per un periodo di tempo sufficiente a normalizzare i dati rispetto ai pregiudizi degli utenti e delle organizzazioni.

I dataset di addestramento sono il rovescio della medaglia dei dataset di test, e molto tempo dovrebbe essere dedicato ad analizzare e validare dati di buoni dati di addestramento e test. Alcuni dei fattori per la creazione di buoni dataset di test saranno discussi in una sezione successiva.

L'output del rilevamento delle anomalie è fondamentale. L'approccio migliore non consiste nell'eseguire semplici determinazioni di blocco/autorizzazione o avviso/silenzio basate su un segnale grezzo, ma piuttosto nel tracciare e regolare metriche di rischio dettagliate a livello di utente, ruolo e organizzazione, che possono poi essere utilizzate per azioni correttive quali avvisi, coaching o blocchi.

Questo approccio al monitoraggio e all'azione sul rischio è fondamentalmente diverso da quello tipicamente utilizzato oggi. La maggior parte delle difese perimetrali che sono preventive e che tipicamente bloccano/allertano/permettono il traffico sono generalmente statiche e soggette ad alti tassi di falsi positivi. Il risultato netto è che queste soluzioni sono abilitate con una politica conservativa per bloccare certi rischi noti, il che apre così un gran numero di falsi negativi. Con i firewall, vediamo problemi di falsi positivi con azioni di blocco eccessivamente aggressive basate su intelligence sulle minacce IP. Con le soluzioni IPS, abbiamo discusso delle difficoltà dei falsi positivi con le firme statiche che cercano di rilevare traffico C2 altamente configurabile e dinamico.

Ma i falsi positivi a livello perimetrale possono essere molto utili come segnale per un livello più intelligente. In questo scenario, non lo useremmo per una valutazione binaria (consenti/blocca, avvisa/ignora) ma come una metrica di rischio dettagliata regolata nel tempo (ad esempio punteggio di rischio dell'utente) con una soglia calibrata prima di agire. Una metrica di rischio granulare, ad esempio un punteggio di rischio da 1000 (nessun rischio) a 0 (rischio estremo) su un utente, un dispositivo o persino un indirizzo IP, ci consente di modellare lo spettro di grigio associato alle minacce del mondo reale, dove raramente ci sono chiare valutazioni del 100% dannose o del 100% benigne.

Concettualmente, questo è rappresentato nella seguente illustrazione, in cui potrebbero essere rilevati tre segnali diversi, che di per sé sarebbero soggetti a falsi positivi. Tuttavia, se associati al rischio incrementale e valutati da un modello di apprendimento automatico ottimizzato, gli stessi segnali valutano il rischio cumulativo nel tempo e, in definitiva, forniscono un rilevamento delle anomalie con elevata affidabilità.

Figura 8: Metriche dettagliate del rischio

Si noti che i segnali in questo esempio potrebbero non essere semplici come i segnali statici. Ad esempio, un "user agent e certificato SSL/TLS non riconosciuti in un dominio insolito" potrebbe rappresentare un'anomalia se confrontato con la base di riferimento "normale" del traffico precedente per quell'utente specifico o con ruoli lavorativi simili degli utenti o dell'intera organizzazione. Un "registrar sospetto" potrebbe essere un insieme di reputazioni di dominio correlate nel tempo. Il "beaconing periodico" non è più una semplice corrispondenza di una frequenza o durata fissa, ma può rilevare attività anomale ma regolari e ripetute all'interno di una finestra temporale simile all'attività correlata ai bot, anziché alle valide chiamate del demone applicativo.

In pratica, ciò ci consente di adattare in modo incrementale e appropriato un punteggio di rischio in base a un segnale a bassa fedeltà. Non provoca alcuna azione di blocco o di avviso finché il punteggio di rischio cumulativo non supera una soglia elevata e preimpostata. Ciò ci consente di rilevare casi in cui sono presenti numerosi indicatori a bassa fedeltà e leggermente rischiosi che, se combinati con un indicatore ad alta fedeltà e ad alto rischio per un particolare utente o dispositivo, generano cumulativamente un avviso di rischio critico e un'azione con una probabilità di falsi positivi drasticamente inferiore.

Un approccio New può teoricamente essere valido e in pratica fallire miseramente, e la dimostrazione spesso si riduce ai dati o ai test. I fornitori che forniscono soluzioni e le organizzazioni che cercano soluzioni richiedono un approccio robusto per testare New minacce e valutare le soluzioni. Per ottenere risultati accurati, è essenziale testare con un dataset diversificato che includa sia traffico malevolo che benigno.

Traffico benigno
Il traffico benigno dovrebbe essere realistico, completo e simile alla produzione in termini di numero di utenti e attività. Un buon traffico, spesso dipendente dall'utente, dovrebbe essere studiato su un ampio campione di utenti e in un periodo di tempo ragionevole. Questo set di dati di test misurerà i tassi di falsi positivi (FP). La variazione principale nei set di dati sarà rappresentata dai segnali client, quali applicazioni, agenti utente e certificati SSL/TLS client utilizzati, dai segnali di destinazione rilevati nei domini/indirizzi IP di destinazione e dai segnali del modello di traffico nelle intestazioni, nel payload, nelle dimensioni e nella tempistica.

La buona notizia è che un buon traffico benigno si raccoglie facilmente dalle operazioni quotidiane degli utenti dell'organizzazione, mentre la cattiva notizia è che deve essere convalidato come benigno. L'approccio pratico consiste nel campionare statisticamente il traffico benigno fino a un certo fattore di fiducia ragionevole, poi dedicare la maggior parte del tempo a concentrarsi sugli avvisi della soluzione di rilevamento C2 testata, verificando che siano veri positivi o falsi positivi. In altre parole, campionare e verificare inizialmente per formare una linea di base, assumere che il dataset benigno sia pulito, poi procedere a identificare i falsi positivi basandosi sui test.

Figura 9: Test del traffico benigno

Traffico malevolo
L'utilizzo di profili pubblici provenienti da strumenti di framework C2 popolari fornisce una solida base per testare traffici negativi. Questi profili rappresentano configurazioni pratiche e frequentemente utilizzate che eludono le difese e aiutano a misurare i tassi di falsi negativi (FN). Tuttavia, bisogna considerare molto la creazione di un dataset rappresentativo di "traffico negativo", poiché ci sono potenzialmente più livelli nella copertura e in ciò che i dataset testano, come illustrato nel diagramma seguente:

Figura 10: Test del traffico dannoso

1. Strumenti di simulazione di violazioni e attacchi come SafeBreach sono eccellenti per i test di copertura e i test ripetuti. I loro casi di test C2 in genere includono almeno una certa simulazione dell'attività dei framework C2. Il vantaggio è che è disponibile un'ampia gamma di funzionalità, tra cui attacchi malware generali, con architetture e interfacce utente grafiche ben progettate, nonché procedure di test e report ripetibili. Questi strumenti possono offrire una vasta gamma di scenari, tra cui: attività lenta-bassa, infrastruttura IaaS/CSP, traffico HTTP e non HTTP, traffico SSL/HTTPS e spoofing di una varietà di agenti utente.
2. Strumenti di framework C2 (profili pubblici). Un test approfondito dei framework C2 richiede un lavoro mirato. Un approccio è creare un dataset di test basato sui profili pubblici specifici degli strumenti del framework C2, ad esempio Cobalt Strike. Questi profili pubblici e malleabili tendono a essere ampiamente condivisi e utilizzati da molti utenti e attori malintenzionati poiché includono emulazioni utili di applicazioni innocue come Gmail. Questo approccio fornisce tipicamente test più completi sui specifici framework C2.
3. Strumenti framework C2 (profili personalizzati). La personalizzazione interna dei Profili Malleabili C2 può fornire test ancora più realistici dei framework C2. Queste configurazioni personalizzate possono essere eseguite durante le operazioni interne del red team. Questo richiede più lavoro e investimento, poiché gli operatori del red team devono essere fluenti negli strumenti del framework C2.
4. Attacchi realistici. I test più realistici prevedono test black-box con programmi esterni di pen-testing o bug-bounty. In questi scenari, i requisiti dell'esercitazione sono attentamente elaborati per richiedere o incentivare exploit POC effettivi che utilizzano specifici strumenti del framework C2 o qualsiasi comportamento di beaconing C2, con l'avvertenza di evitare il rilevamento per un certo periodo di tempo. Gli obiettivi delle esercitazioni non sono solo testare i vettori di accesso iniziali, che rappresentano la norma, ma concentrarsi sull'attività post-violazione dimostrando la capacità di installare un payload backdoor con attività C2 dimostrata. Ciò arricchisce il set di dati di test oltre i framework C2 e può testare il codice POC backdoor con comunicazioni C2 personalizzate, ed è anche un ottimo test della resilienza di qualsiasi strumento di rilevamento a un "attaccante" esperto che utilizza TTP diversi o personalizzati.

Il testing può coinvolgere alcuni o più approcci, ma dovrebbero esserci scelte esplicite su come creare, raccogliere e convalidare i dataset di test e su come misurare i risultati attesi. Creare e raccogliere i dataset di test è molto importante affinché i test possano essere automatizzati e facilmente ripeterli.

È inoltre fondamentale misurare parametri completi durante i test: veri e falsi positivi, veri e falsi negativi. Sebbene raccogliere tutte le metriche possa sembrare ovvio, è difficile essere precisi nella definizione e chiari e ripetibili nella metodologia di misurazione, il che porta a risultati fuorvianti.

Bersagli con falsi positivi e falsi negativi
Con le minacce New evasive create dai framework C2, qualsiasi soluzione di rilevamento New mancherà dei tassi di FP e FN ampiamente accettati. Tuttavia, è fondamentale creare bersagli FP e FN. Con dataset di test di qualità nota, si possono creare basi per l'ambiente attuale e per gli utenti/dispositivi, il che consente così di creare obiettivi ragionevoli rispetto a tali linee di base.

Ad esempio, supponiamo che un'organizzazione con solo un IPS stia iniziando una valutazione delle soluzioni di rilevamento C2 New e non sia chiaro quali tassi FP/FN siano accettabili. L'organizzazione può comunque stabilire obiettivi ragionevoli seguendo una metodologia di test come:

• Creare dati di test di qualità per traffico innocuo basati su dati di produzione e traffico malevolo basandosi, ad esempio, su profili pubblici C2 malleabili per Cobalt Strike, e validando manualmente campioni di quei dataset.
• Crea una metodologia di test chiara e ripetibile definendo strumenti di test e misurazione.
• Misurare tutte le metriche (TP/TN/FP/FN) durante il test
• Prova New soluzioni e confronta le metriche. Ad esempio, l'IPS potrebbe essere ottimizzato specificamente per ottenere migliori tassi TP per il traffico dannoso, assicurandosi 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 di seguito.
• Testa New dataset e confronta. Cerca di personalizzare i dataset per riflettere adeguamenti ragionevoli da parte di un attaccante. Ci sono diversi modi per farlo.
  • Ad esempio, durante il test di Cobalt Strike, i suoi profili C2 Malleable possono essere facilmente modificati per emulare app benigne in modo leggermente diverso o completamente New app benigne utilizzate all'interno dell'organizzazione specifica. Questo può essere fatto con lo sniffing del traffico in uscita HTTP/S tramite un proxy.
  • Testa non solo uno, ma più strumenti del framework C2, poiché differiscono per capacità e tecniche. Usare uno strumento di framework C2 diverso è anche un buon cambiamento perché la modellatura del traffico C2 sarà diversa.
  • Creare un payload di test personalizzato con le proprie comunicazioni C2 codificate a mano è un altro modo per modificare i dataset di test, ma richiede più tempo e investimento.

Test di resilienza
Testando con New dataset su diverse soluzioni, otteniamo anche preziose informazioni sulla rigidità rispetto alla resilienza delle diverse soluzioni. In questo articolo, abbiamo sollevato la questione che gli approcci hard-coded e basati su firma non solo sono meno efficaci nel rilevare i framework C2, ma sono anche rigidi, con conseguente elevate velocità FP/FN e permettendo un facile bypass con semplici modifiche agli attacchi, come modifiche di profilo malleabili.

La resilienza di qualsiasi soluzione può essere testata assicurandosi che i set di dati vengano modificati entro limiti ragionevoli (ad esempio, rimanendo all'interno della stessa categoria TTP). In altre parole, possiamo eseguire un test di resilienza realistico modificando le comunicazioni C2 all'interno del set di dati sul traffico dannoso utilizzando profili malleabili C2 e monitorando le velocità TP/TN/FP/FN. Osserviamo come varia la copertura e comprendiamo anche quali modifiche devono essere apportate alla soluzione di rilevamento per mantenere la copertura per specifici obiettivi TP/TN/FP/FN.

Ritestare con dataset modificati in questo modo è analogo a un attaccante che cambia il proprio TTP. Valuta la resilienza e l'efficacia della soluzione di rilevamento New per vedere se è ancora in grado di rilevare cambiamenti all'interno della stessa categoria di tecniche di minaccia (comunicazioni C2 su HTTP/S).

Impatto falso positivo e falso negativo
La misurazione dei tassi FP/FN è buona e consente un miglioramento relativo, ma dobbiamo anche misurare o almeno stimare l'impatto di FPS e FN, altrimenti è impossibile valutare la reale utilità di qualsiasi soluzione di rilevamento. In altre parole, un tasso FP dell'1% o un miglioramento del 5% nel tasso FP non ha alcun contesto a meno che non possiamo misurare l'impatto di quell'1% o +5% in un modo che abbia senso per chi prende le decisioni sul bilancio della sicurezza.

Ecco due approcci che possono aiutare a tradurre i tassi TP/TN/FP/FN in un impatto più quantificabile:

1. Impatto sull'utente nel tempo: osservare il numero assoluto di falsi positivi equivalenti ai tassi FP e normalizzarli come tasso per utente nel tempo. Si tratta di una misura qualitativa, ma spesso ha più senso delle percentuali o dei numeri assoluti. Ad esempio, anziché l'1% di FP o 2.437 falsi positivi, potrebbe essere più semplice valutare l'impatto di 0,1 falsi positivi per utente al giorno. Se si trattasse di un gateway web sicuro, qualcuno all'interno dell'organizzazione potrebbe stabilire se un determinato obiettivo FP è accettabile in base all'impatto sull'utente nel tempo. In questo caso, il malware abilitato dal framework C2 provoca violazioni e l'impatto sull'utente è caratterizzato più da tempi di inattività o perdita di dati per utente in un determinato periodo di tempo. Abbiamo una probabilità N% di perdere $X per utente ogni anno. Spesso si tratta di stime approssimative, ma ogni punto di partenza è utile in quanto può essere rivisto e migliorato con iterazioni regolari. Se l'impatto viene valutato in termini di utenti nel tempo, diventa facile valutare soluzioni di rilevamento o protezione, il cui prezzo spesso è calcolato in base al numero di utenti all'anno.
2. Le operazioni di sicurezza hanno un impatto in termini di tempo, denaro e probabilità di violazione. Oltre all'impatto sull'utente finale, è necessario valutare anche l'impatto amministrativo, in particolare sul personale operativo che spesso dedica tempo alla gestione degli avvisi di rilevamento. Il tempo impiegato per rispondere ad allarmi rumorosi può essere tradotto direttamente in costi salariali FTE. L'ulteriore fattore di affaticamento da allerta è un impatto reale che può essere stimato in termini di efficacia (tempo di risposta) e, cosa ancora più importante, come perdita di tempo e attenzione verso minacce di impatto realmente più elevato che vengono perse o non vengono indagate. Quest'ultimo impatto diventa un fattore determinante nell'impatto delle violazioni: è più probabile che si verifichino violazioni quando le operazioni di sicurezza presentano troppi falsi positivi da analizzare ed eliminare.

Una valutazione d'impatto è spesso l'unico modo per comprendere informazioni cruciali, come il costo reale dell'efficacia del rilevamento. Ad esempio, una soluzione di rilevamento eccessivamente aggressiva con una configurazione di FN bassi e FP alti è inutile e dannosa perché le operazioni di sicurezza sprecano una quantità eccessiva di tempo rispondendo ad avvisi di bassa fedeltà invece di impegnarsi in attività di maggiore impatto. Allo stesso modo, una soluzione di rilevamento eccessivamente conservativa con FP bassi ma FN alti espone l'organizzazione a un rischio elevato di potenziale violazione, il che può essere inaccettabile da una prospettiva di valutazione del rischio complessiva.

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

Test realistici

Red team composto da esseri umani, non solo da strumenti automatizzati per test di violazione o di penetrazione. Si consiglia vivamente di utilizzare non solo utenti e ambienti di produzione per testare le soluzioni di beaconing C2, ma anche scenari avversari realistici come test di penetrazione o bug bounty. Adattando gli importi e i requisiti delle ricompense per mostrare l'implementazione esplicita e le azioni di successo post-sfruttamento dei toolkit del framework C2 più diffusi, possiamo rendere il "traffico dannoso" reale e misurabile. Questo potrebbe essere esteso a qualsiasi attività di beaconing C2, incluso il codice personalizzato per testare la resilienza della soluzione di rilevamento, e il requisito di test dovrebbe includere la dimostrazione di un'attività di beaconing giornaliera riuscita e dell'esecuzione di comandi nell'arco di una settimana, senza rilevamento.

Se un test di penetrazione 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 al testing, non solo l'efficacia dei test sarà misurata in modo completo, ma obiettivi e obiettivi continui potranno essere creati in relazione a una base attuale o storica. E certamente, se vengono eseguiti gli stessi test e misurazioni per più soluzioni, è banale confrontare le prestazioni e prendere decisioni di acquisto/implementazione.

La ricerca e la progettazione che coinvolgono questi concetti e l'approccio complessivo sono discusse più in dettaglio in: Sistemi di sicurezza e metodi per rilevare il comando e controllo malleabile (Mulugeta).