Threat Hunting su Cobalt Strike: dalle viscere del beaconing all’infrastruttura C2
Un tool che non ha bisogno di presentazioni, ampiamente utilizzato dai threat actor e costantemente analizzato dai difensori. Dopo anni passati ad osservare e analizzare compromissioni reali, è arrivato il momento di realizzare quella che riteniamo essere la guida più completa mai pubblicata sul threat hunting di Cobalt Strike. Uno degli approcci più diffusi e riconosciuti in tal senso è quello di produrre una lista aggiornata di indirizzi IP associati a Cobalt Strike, che rappresenta un grande valore per i team di Threat Intelligence poiché consente attività di monitoraggio e blocco proattivo in grado di interrompere operazioni di post-exploitation condotte da una vasta gamma di avversari, dai ransomware operator fino agli Advanced Persistent Threats (APT) a scopo di spionaggio. Altrettanto importante, però, è ricordare che le attività di threat hunting non dovrebbero limitarsi alla sola individuazione dell’infrastruttura malevola, ma hanno un ruolo fondamentale nel riuscire a identificare la presenza di impianti Cobalt Strike all’interno del perimetro organizzativo, prima che un’intrusione abbia l’opportunità di evolvere e trasformarsi in un incidente a tutti gli effetti. Negli ultimi anni sono stati rilasciati moltissimi approfondimenti, analisi e investigazioni sul tool e sulla sua infrastruttura di command and control, alcuni estremamente dettagliati e largamente utilizzati anche durante la stesura di questo articolo. Nessuno, però, ha provato a descrivere Cobalt Strike nella sua interezza. L’obiettivo di questo lavoro è fornire una visione olistica del framework, della sua architettura e del suo utilizzo operativo, affiancando tecniche di hunting combinate: sia per l’individuazione di payload malevoli all’interno del perimetro in scenari post-compromise, sia per l’identificazione preventiva di server di command and control attivi in the wild. Panoramica su Cobalt Strike Cobalt Strike continua a essere uno dei framework di post-exploitation più diffusi nelle attività di intrusione moderne. I ransomware operator, in particolare, fanno ampio affidamento sulle sue funzionalità principali per espandere l’accesso iniziale, mantenere la persistenza e rendere operativi i movimenti laterali all’interno degli ambienti compromessi. La combinazione di velocità, flessibilità e un set di funzionalità ormai maturo lo ha reso una scelta naturale per molti attori malevoli, ed è difficile ignorarne il ruolo nella crescita costante delle campagne ransomware osservata negli ultimi anni. Diversi gruppi ransomware di alto profilo sono noti per basare una parte significativa del proprio workflow operativo proprio su Cobalt Strike. Sebbene nasca inizialmente come piattaforma commerciale di adversary simulation pensata per attività di red teaming, da tempo viene piratato e riutilizzato da un’ampia varietà di threat actor, che spaziano da gruppi a scopo puramente economico fino ad Advanced Persistent Threats (APT) orientati allo spionaggio. Molti addetti ai lavori hanno avuto modo di imbattersi in payload Cobalt Strike durante attività di incident response; tuttavia, chi non ha esperienza diretta come operatore spesso fatica a comprenderne a fondo i componenti interni, il modello di esecuzione e il tradecraft operativo. Su larga scala, individuare beacon attivi all’interno di ambienti estesi ed eterogenei rappresenta una sfida tutt’altro che banale per i team di threat hunting. Allo stesso tempo, però, questa complessità lascia ampi margini di manovra e opportunità per adottare un approccio più creativo. Nel suo core, Cobalt Strike opera come piattaforma di command and control (C2) che orchestra le attività dell’attaccante. L’applicazione è composta da due elementi principali: il team server e il client. Entrambi sono distribuiti all’interno dello stesso Java Archive (JAR), e il loro comportamento dipende esclusivamente dai parametri di esecuzione forniti dall’operatore. Il Team Server rappresenta il componente di command and control vero e proprio. È responsabile dell’accettazione delle connessioni dei client degli operatori, della gestione delle callback beacon provenienti dagli host compromessi e della risposta alle richieste web utilizzate durante le operazioni. Di default, il team server accetta connessioni client sulla porta TCP 50050 ed è progettato per essere eseguito esclusivamente su sistemi Linux. Gli operatori interagiscono con il team server tramite il Cobalt Strike Client. Il client può essere eseguito sulla stessa macchina del team server oppure collegarsi ad esso da remoto ed è disponibile per sistemi Windows, macOS e Linux. Beacon è il nome del payload malevolo predefinito di Cobalt Strike ed è utilizzato per stabilire la comunicazione con il team server. Le sessioni di callback attive provenienti dai sistemi compromessi vengono anch’esse chiamate “beacon”, una convenzione terminologica da cui deriva il nome della famiglia malware. Può possedere due modalità principali: Lo stager è un payload beacon opzionale e leggero, utilizzato per effettuare uno staging dell’infezione. In questo scenario, un primo shellcode minimale esegue controlli di base e contatta l’infrastruttura C2 configurata per scaricare il backdoor completo. Il full backdoor può invece essere eseguito tramite uno stager beacon distribuito da una famiglia di loader esterna, oppure avviato direttamente invocando l’export DLL predefinito ReflectiveLoader. Una volta caricato in memoria, il backdoor è in grado di stabilire la comunicazione con il team server utilizzando diversi meccanismi di trasporto. Infine, la struttura del tool prevede anche i loader, ovvero script aggiuntivi che possono essere importati per ampliare le funzionalità dello strumento. Alcuni sono già inclusi di default, ma gli operatori sviluppano frequentemente implementazioni personalizzate in PowerShell, .NET, C++ o Go, che poi importano ed utilizzano direttamente. Cobalt Strike Capabilities: Componenti principali I listener sono i componenti di Cobalt Strike responsabili della gestione delle connessioni in ingresso dai payload verso il team server. Il framework supporta diversi tipi di listener e consente un livello di personalizzazione molto elevato per ciascun protocollo. A seconda della modifica applicata, intervenire su un listener può richiedere la rigenerazione dei payload, il riavvio del listener stesso o, in alcuni casi, il riavvio completo del team server. I listener HTTP e HTTPS sono di gran lunga quelli più utilizzati. Nonostante Cobalt Strike venga distribuito con un certificato TLS di default, questo è ampiamente noto e di conseguenza intercettato dai prodotti di sicurezza enterprise. Per questo motivo, gli operatori tendono a utilizzare certificati validi, spesso emessi tramite servizi come Let’s Encrypt, nel tentativo di far apparire l’infrastruttura C2 come traffico legittimo. Attraverso l’uso dei Malleable Profiles, che verranno approfonditi più avanti, è inoltre possibile controllare in modo estremamente granulare la struttura e il comportamento del traffico di rete del beacon, fino a renderlo indistinguibile da normali comunicazioni HTTP. La configurazione dei listener consente anche di specificare più domini o indirizzi IP dai quali il team server accetterà le callback beacon, una funzionalità spesso sfruttata tramite infrastrutture di redirector, oltre alla possibilità di definire valori personalizzati per l’header Host a supporto di tecniche di domain fronting. I listener DNS stabiliscono le sessioni incapsulando le comunicazioni di command and control all’interno del traffico DNS per domini di cui il team server è autoritativo. Sono supportate due modalità operative: nella configurazione ibrida, che è quella di default, il DNS viene utilizzato come canale di beaconing mentre l’HTTP gestisce il trasferimento dei dati; in alternativa, è possibile abilitare una modalità pure DNS, che utilizza richieste di record A sia per il beaconing sia per lo scambio dei dati. Questo approccio è sensibilmente più lento, ma evita completamente l’uso di HTTPS e può risultare più discreto in ambienti particolarmente restrittivi. I listener SMB operano invece come bind listener e vengono utilizzati prevalentemente per concatenare più beacon all’interno di ambienti già compromessi. In questo scenario, viene aperta una porta locale sul sistema target in attesa di una connessione in ingresso da parte di un operatore o di un’altra istanza beacon. I listener Raw TCP seguono una logica simile e rappresentano un’alternativa più recente per scenari di chaining, offrendo maggiore flessibilità quando l’uso di SMB non è possibile o risulta indesiderabile. Esistono infine due tipologie di listener meno comuni, introdotte principalmente per garantire interoperabilità con altri strumenti. I Foreign listener permettono di importare sessioni Metasploit Meterpreter all’interno di Cobalt Strike, semplificando il passaggio di sessioni tra i due framework. Gli External C2 listener, invece, definiscono un’interfaccia per comunicazioni reverse TCP, in cui il payload si connette attivamente a un endpoint esterno controllato dall’operatore, anziché attendere una connessione in ingresso come avviene nei listener di tipo bind. Quasi tutto è personalizzabile Una delle caratteristiche distintive di Cobalt Strike è l’estrema flessibilità del suo comportamento. Al di là delle configurazioni di default, gli operatori possono modificare in modo significativo payload, flussi di esecuzione, tecniche di offuscamento in memoria, funzionalità di post-exploitation e tradecraft di rete, sfruttando una serie di meccanismi di estensione ufficialmente supportati. Questa personalizzazione è resa possibile principalmente attraverso Arsenal Kit, Malleable C2 Profile, Aggressor Script e, più recentemente, estensioni come i Beacon Object File (BOF) e l’esecuzione in memoria di assembly .NET. Nel loro insieme, questi componenti permettono di rimodellare ampie porzioni del framework, da come BEACON comunica ed esegue codice fino a come le attività di post-exploitation vengono implementate e automatizzate. Tecniche di offuscamento (anti-detection) Redirector In molte implementazioni reali, i BEACON non si connettono direttamente al team server. Al contrario, gli operatori introducono spesso uno o più redirector che terminano le connessioni in ingresso e inoltrano il traffico verso l’infrastruttura C2 sottostante. Questo approccio stratificato offre diversi vantaggi operativi, tra cui la possibilità di ruotare più domini per una singola istanza BEACON, sostituire redirector individuati o bloccati senza dover ridistribuire il team server e sfruttare domini a più alta reputazione per far apparire il traffico malevolo come traffico legittimo. I redirector consentono inoltre di filtrare selettivamente le richieste in ingresso, bloccando scanner, strumenti di hunting automatizzati o altre attività sospette, con l’obiettivo di proteggere il team server dall’esposizione diretta. Lo scopo è chiaramente quello di rendere più complessa l’identificazione dell’attività malevola, ma non elimina del tutto gli artefatti osservabili e, nella maggior parte dei casi, è comunque possibile individuare sia i redirector sia i team server a essi associati. Domain Fronting Nella sua forma più semplice, un redirector può essere costituito da una semplice istanza cloud che esegue un reverse proxy, ad esempio tramite nginx. Una variante più sofisticata ed efficace è rappresentata dal domain fronting. Questa tecnica consente di nascondere la reale destinazione di una connessione instradando il traffico attraverso l’infrastruttura di una Content Delivery Network (CDN). Inizialmente documentata come metodo per aggirare la censura su Internet, è stata successivamente adottata da diversi threat actor, tra cui APT29, per mascherare le comunicazioni di command and control. In una connessione HTTPS frontend, la sessione TLS viene stabilita direttamente con un dominio legittimo e ad alta reputazione ospitato dalla CDN, il cosiddetto front domain. All’interno della richiesta cifrata è presente un identificatore secondario, spesso veicolato tramite l’header HTTP Host, che indica alla CDN come instradare la richiesta verso un backend controllato dall’operatore. Dal punto di vista del difensore, la connessione TLS sembra terminare sulla CDN ed è protetta dal certificato SSL/TLS legittimo del provider. In questo scenario, bloccare l’accesso al dominio controllato dall’operatore richiede la decifratura del traffico HTTPS per individuare la reale destinazione interna della connessione, un’operazione spesso impraticabile in ambienti enterprise. Oltre ai costi prestazionali e operativi legati all’intercettazione TLS su larga scala, nella maggior parte dei casi non è neanche possibile la decifratura, poiché alcuni provider CDN applicano meccanismi di certificate pinning sulla propria infrastruttura SSL/TLS, impedendo l’intercettazione tramite certificati root fidati a livello organizzativo e riducendo ulteriormente la visibilità sul traffico di command and control fronted. Masquerading Il traffico masqueraded è progettato per apparire come comunicazione verso un servizio legittimo, pur stabilendo in realtà una connessione diretta con infrastruttura controllata dall’operatore. Il traffico frontend, al contrario, viene inizialmente inviato a un servizio legittimo di terze parti, tipicamente una CDN, e solo successivamente instradato verso il server dell’attaccante. Sebbene entrambe le tecniche abbiano l’obiettivo di offuscare l’attività di command and control, il comportamento di routing sottostante differisce in modi che sono spesso osservabili. Quando il dominio di destinazione e il valore dell’header HTTP Host coincidono, la connessione rappresenta una normale richiesta HTTP o HTTPS diretta. Una discrepanza tra questi due elementi è invece frequentemente indicativa di un tentativo deliberato di offuscamento. Se l’header Host fa riferimento a un dominio noto e ad alta reputazione, ad esempio presente nella Alexa Top 1M, mentre la destinazione effettiva risolve altrove, il comportamento è più coerente con una tecnica di domain masquerading. Se invece l’header Host punta a un endpoint associato a una CDN, come domini sotto *.azureedge.net, il traffico potrebbe indicare l’uso di domain fronting. Esistono diverse risorse pubbliche che aiutano a determinare se un determinato dominio supporti il fronting, con una lista precompilata di domini frontable suddivisi per provider CDN, che però possono essere facilmente soggetti a falsi positivi e devono quindi essere soggetti ad una revisione manuale. Hunting all’Interno del Perimetro (Detection) Execution Grossa parte delle funzionalità di post-exploitation di Cobalt Strike è implementata sotto forma di DLL Windows. Quando un operatore invoca uno di questi tool integrati, Cobalt Strike genera un processo temporaneo e utilizza rundll32.exe per caricare ed eseguire il codice malevolo. I risultati dell’esecuzione vengono poi restituiti alla sessione beacon attiva tramite meccanismi di comunicazione inter-processo basati su named pipe. Questo modello di esecuzione rende l’attività a riga di comando che coinvolge rundll32.exe un segnale particolarmente interessante da analizzare, soprattutto nei casi in cui il processo viene avviato senza argomenti significativi. Le named pipe fungono da canale di trasporto per inviare l’output delle azioni di post-exploitation al beacon. Per impostazione predefinita, Cobalt Strike utilizza una serie di pattern prevedibili per i nomi delle pipe, che possono essere sfruttati dai difensori come base per attività di detection e hunting. Nonostante il framework consenta agli operatori di modificare arbitrariamente questi nomi tramite la configurazione del Malleable C2 Profile, nella pratica questa personalizzazione è osservata raramente. Pur essendo semplice da implementare, la modifica delle pipe introduce un ulteriore attrito operativo e viene spesso trascurata dagli attori meno sofisticati. I pattern di named pipe di default utilizzati da Cobalt Strike includono i seguenti (l’asterisco indica un prefisso o suffisso variabile): \postex_* \postex_ssh_* \status_* \msagent_* \MSSE-* \*-server Sui sistemi Windows, la creazione e l’accesso alle named pipe possono essere registrati tramite gli eventi Sysmon 17 e 18. È importante sottolineare, tuttavia, che Sysmon non registra questo tipo di attività per impostazione predefinita e deve essere esplicitamente configurato affinché tali eventi siano disponibili per l’analisi. Durante la fase di esecuzione, Cobalt Strike compie diverse attività sospette che possono essere sfruttate come pattern utili nel processo di threat hunting, incluse le seguenti: Processi rundll32.exe avviati senza parametri nella riga di comando; rundll32.exe generato da rundll.exe, accompagnato da connessioni di loopback su porte alte e randomiche; Più istanze di rundll32.exe avviate da un singolo processo PowerShell; Più processi con nomi simili generati dallo stesso processo PowerShell; Processi PowerShell che generano a loro volta altri processi PowerShell; PowerShell avviato tramite WMI, in particolare nei casi in cui la riga di comando contenga comandi codificati in Base64. Defense Evasion La process injection è una caratteristica ricorrente di praticamente ogni intrusione che coinvolge Cobalt Strike e viene osservata con regolarità negli ambienti compromessi. Viene utilizzata principalmente per iniettare codice malevolo all’interno di processi remoti e, in molti casi, direttamente in lsass.exe, con l’obiettivo di estrarre credenziali dalla memoria. Iniettando il payload in un processo remoto, gli operatori creano di fatto un nuovo contesto di esecuzione allineato al contesto di sicurezza del processo target, facilitando scenari di privilege escalation o lateral movement mascherati da attività apparentemente legittime. Il comportamento di process injection di default di Cobalt Strike può essere individuato tramite Sysmon correlando una sequenza specifica di eventi. Nel flusso di iniezione più comune è tipicamente possibile osservare, in successione: Event ID 10 – Accesso a un processo (Process Access); Event ID 8 – Creazione di un thread remoto (CreateRemoteThread); Event ID 3 o 22 – Attività di rete, come connessioni o query DNS. Quando questi eventi si verificano in stretta prossimità temporale, rappresentano un forte indicatore di attività di iniezione malevola riconducibile all’esecuzione di un beacon. Esempio di process injection su un processo remoto (RuntimeBroker.exe) È importante sottolineare che non tutte le tecniche di injection producono la stessa telemetria. Metodi alternativi, come il process hollowing, non si basano sulla creazione di thread remoti e quindi non generano l’Event ID 8. Di conseguenza, le strategie di detection devono tenere conto di più percorsi di esecuzione possibili. In assenza della visibilità avanzata fornita da Sysmon, individuare attività di process injection tramite i soli log nativi di Windows risulta estremamente complesso, poiché gli eventi a basso livello necessari per questa analisi non vengono registrati in modo consistente. Credential Access Dopo aver ottenuto l’accesso iniziale tramite Cobalt Strike, una delle prime attività svolte dagli attaccanti è la raccolta di credenziali e hash dal processo LSASS. L’obiettivo è il Local Security Authority Subsystem Service (LSASS), da cui vengono estratti dati sensibile direttamente dalla memoria. Cobalt Strike mette a disposizione diversi meccanismi integrati per facilitare questa fase: il comando hashdump consente di recuperare gli hash delle password memorizzate, mentre logonpasswords richiama le funzionalità di Mimikatz per estrarre credenziali in chiaro e hash NTLM direttamente da LSASS. Queste attività non sono però semplici da individuare, in quanto, nella maggior parte dei casi osservati, gli unici eventi acquisiti in modo consistente sono quelli legati al ciclo di vita dei processi: Event ID 4688 – Creazione del processo, in cui rundll32.exe carica la DLL malevola; EventID 4689 – Terminazione del processo, al termine dell’esecuzione. Cobalt Strike BEACON Implant (SMB Pivoting) Questa detection si concentra su attività avversarie che coinvolgono un impianto beacon utilizzato per effettuare pivoting laterale e impartire comandi tramite SMB, sfruttando le named pipe. Cobalt Strike supporta infatti comunicazioni basate su SMB consentendo agli operatori di configurare i beacon per scambiare dati attraverso pipe nominate, facendo affidamento su una serie di nomi di default che vengono frequentemente riutilizzati tra diverse intrusioni. Per questo motivo, l’analisi dovrebbe concentrarsi sull’individuazione di interazioni sospette con named pipe all’interno dell’albero dei processi coinvolti, prestando particolare attenzione ad attività anomale legate a file o pipe che si discostano dal comportamento atteso del sistema. Pattern ricorrenti includono, ad esempio, l’uso di pipe con prefissi noti come: (‘pipe\msagent_’ || ‘pipe\interprocess_’ || ‘pipe\lsarpc_’ || ‘pipe\samr_’ || ‘pipe\netlogon_’ || ‘pipe\wkssvc_’ || ‘pipe\srvsvc_’ || ‘pipe\mojo_’ || ‘pipe\postex’ || ‘pipe\status_’ || ‘pipe\msse-‘) Questi elementi, se osservati nel contesto corretto e correlati con altri segnali di esecuzione e comunicazione, possono fornire indicazioni utili sull’uso di beacon per attività di lateral movement all’interno dell’ambiente. Importazione di script PowerShell Un altro artefatto ricorrente osservabile durante una compromissione che coinvolge Cobalt Strike è l’utilizzo di comandi PowerShell per l’importazione di script all’interno di una sessione beacon. In particolare, è frequente imbattersi in invocazioni del tipo: IEX (New-Object Net.WebClient).DownloadString(‘http://127.0.0%5B.%5D1:45246/’) Questo meccanismo viene utilizzato da Cobalt Strike per gestire l’esecuzione di script PowerShell importati direttamente all’interno della sessione beacon. L’uso di indirizzi di loopback e porte locali è tipico di questo workflow e può rappresentare un utile punto di partenza per attività di detection quando correlato con altri segnali di esecuzione sospetta. Abuso di rundll32.exe e SQL Server Client Configuration Utility Un pattern di esecuzione strettamente correlato prevede l’abuso di rundll32.exe per avviare la SQL Server Client Configuration Utility (cliconfg.exe). Questa relazione tra processi è comunemente osservata quando Cobalt Strike sfrutta tecniche di DLL Search Order Hijacking come parte di un bypass dei meccanismi di User Account Control (UAC). In questi casi, cliconfg.exe viene utilizzato come binario fidato per caricare una DLL malevola da una posizione controllata dall’attaccante, consentendo l’esecuzione di codice con privilegi elevati e riducendo al minimo gli indicatori di compromissione più evidenti. Dal punto di vista della detection, un pattern sospetto è rappresentato da: parent_process == rundll32.exe&&process == cliconfg.exe Osservato nel giusto contesto, questo comportamento può indicare un tentativo di escalation dei privilegi tramite abuso di binari legittimi. Privilege Escalation tramite GetSystem Questa detection evidenzia pattern a riga di comando tipicamente associati all’uso della funzionalità GetSystem da parte dei beacon di Cobalt Strike. Attraverso GetSystem, gli operatori impersonano un token associato all’account SYSTEM, ottenendo la possibilità di eseguire operazioni che vanno oltre i privilegi amministrativi standard e consolidando il controllo sull’host compromesso. Dal punto di vista operativo, questa tecnica genera un pattern piuttosto caratteristico: il processo di escalation fa uso di cmd.exe per scrivere un token esadecimale all’interno di una named pipe, che viene poi consumata dal processo per completare il workflow di elevazione dei privilegi. Quando è disponibile il logging della riga di comando, questa sequenza offre un’opportunità di detection relativamente affidabile. Un’analitica rappresentativa può essere costruita monitorando esecuzioni di cmd.exe la cui riga di comando corrisponda al seguente pattern: process == cmd.exe&&command_includes ('/(?i)echo\s+[0-9a-f]{11}\s+\>\;?\s+\\\\\.\\pipe\\[0-9a-f]{6}/.match')* Questo pattern cattura la struttura tipica prodotta durante l’esecuzione di GetSystem. Un esempio di attività generata da un BEACON di Cobalt Strike è il seguente: C:\Windows\system32\cmd.exe /c echo 92d8cc45954 >; \\.\pipe\446b3c Se osservato nel giusto contesto, in particolare in combinazione con precedenti artefatti di esecuzione e attività su named pipe, questo comportamento può costituire un forte indicatore di escalation dei privilegi a livello SYSTEM tramite Cobalt Strike. Risorse utili Qualora volessi approfondire ulteriormente le attività di threat hunting all’interno del perimetro, lasciamo di seguito alcune fonti molti utili per effettuare la detection: Awesome-CobaltStrike-Defence: raccolta di strumenti e tecniche di hunting e detection dedicate a Cobalt Strike. Cobalt Strike Beacon Decoder: strumento utile per attività forensi, in particolare nei casi in cui venga individuato un beacon all’interno dell’ambiente. Hunting all’Esterno del Perimetro (Prevention) Dopo esserci assicurati di non avere già dei “simpatici” payload malevoli all’interno del nostro ambiente, è il momento di spostare l’attenzione sulla fase preventiva. L’obiettivo è individuare server di command and control di Cobalt Strike attivi in the wild, con lo scopo di bloccarli preventivamente e impedire alla catena di infezione di proseguire qualora si dovesse entrare in contatto con payload di questo tipo. Negli ultimi anni sono state proposte numerose tecniche che analizzano in modo approfondito le risposte HTTP e DNS tipiche delle configurazioni Cobalt Strike, facendo spesso affidamento su Shodan nella fase di identificazione dei server. Per quella che è la mia esperienza, tuttavia, diverse delle metodologie pubblicate non risultano sufficientemente precise o affidabili. Alcune si basano su elementi comuni a un’ampia gamma di servizi, inclusi quelli legittimi, generando un volume elevato di falsi positivi difficili da distinguere nella pratica. Altre, invece, fanno leva su indicatori troppo fragili e facilmente modificabili dagli operatori, finendo per rendere la tecnica di detection più teorica che realmente utilizzabile. Per questo motivo, la selezione che segue non vuole essere esaustiva, ma include quelle che, a mio avviso, rappresentano le tecniche più efficaci per il raggiungimento dello scopo: Shodan Product:”Cobalt Strike Beacon” SSL certificates and serial numbers Default port 50050 + Banner hash JA3 fingerprint JA3S fingerprint JARM TLS fingerprint Watermark (License ID) 1. Shodan product:”Cobalt Strike Beacon” Questa è probabilmente la tecnica più immediata e, allo stesso tempo, una delle più precise in termini di falsi positivi. Dal momento che Shodan è in grado di effettuare fingerprinting dei servizi esposti, consente di filtrare direttamente per prodotto utilizzando il valore Cobalt Strike Beacon. Al momento della stesura, Shodan identifica oltre 250 server Cobalt Strike attivi, Cina, Hong Kong e Stati Uniti, tra i Paesi maggiormente coinvolti: 2. Certificati SSL e numeri di serie Cobalt Strike viene distribuito con un certificato SSL di default utilizzato per le comunicazioni HTTPS. Si tratta di un certificato self-signed che non ha alcun senso in un’operazione matura o ben gestita, ma che continua comunque a comparire in un numero non trascurabile di deployment reali. Uno dei metodi più semplici per individuare i controller beacon consiste nel cercare gli hash SHA-256 o SHA-1 del certificato di default, oppure il relativo numero di serie SSL. Nella pratica, le ricerche basate sugli hash del certificato e quelle basate sul numero di serie producono gli stessi risultati, poiché questi due elementi sono strettamente correlati. Default certificate: md5:950098276A495286EB2A2556FBAB6D83 sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390CDefault Serial number: ssl.cert.serial:146473198 Quando presenti, questi indicatori offrono un livello di confidenza relativamente elevato, in quanto il fingerprint SSL è unico e direttamente riconducibile alla configurazione predefinita di Cobalt Strike. Detto questo, si tratta di una tecnica tutt’altro che infallibile. Il certificato di default può essere facilmente sostituito con uno legittimo, oppure i suoi parametri possono essere modificati tramite un Malleable C2 Profile, consentendo agli operatori di eludere senza difficoltà detection basate esclusivamente su artefatti SSL statici. 3. Porta di default 50050 e banner hash Per impostazione predefinita, il team server di Cobalt Strike accetta connessioni client sulla porta TCP 50050. Considerata da sola, però, questa specifica è troppo generica per risultare utile: filtrare esclusivamente su questa porta porta inevitabilmente a un numero elevato di risultati, in gran parte non rilevanti. Per rendere questo approccio operativamente valido è necessario raffinare la ricerca unendo più filtri. Un possibile affinamento consiste nell’analizzare il banner esposto dal servizio. Ogni banner include infatti un campo hash, che rappresenta un valore numerico derivato dal campo data. L’algoritmo di hashing utilizzato da Cobalt Strike, documentato pubblicamente, può essere sfruttato come filtro aggiuntivo, riducendo sensibilmente il rumore e migliorando l’affidabilità dei risultati. 4. Fingerprint JA3 e JA3S JA3 è una tecnica open source che consente di generare fingerprint TLS osservando i parametri scambiati durante la comunicazione SSL/TLS tra client e server. Questi fingerprint derivano da una combinazione di valori estratti dal pacchetto Client Hello e, in alcuni casi, possono essere utilizzati per caratterizzare specifiche implementazioni. Successivamente all’introduzione di JA3, è stato sviluppato un approccio analogo per fingerprintare il lato server dell’handshake TLS, analizzando il messaggio Server Hello. Questa tecnica, nota come JA3S, si basa sulla raccolta dei valori decimali di alcuni campi selezionati, tra cui la versione TLS, il cipher suite negoziato e la lista delle estensioni supportate. In teoria, i fingerprint JA3S estratti da infrastrutture Cobalt Strike note potrebbero essere clusterizzati ed utilizzati per ampliare lo spazio di ricerca, individuando server che presentano caratteristiche simili. In pratica, però, questo approccio incontra rapidamente gli stessi limiti già osservati con JA3. I dataset risultanti tendono a essere molto rumorosi e, in assenza di vincoli aggiuntivi robusti, il rischio di generare un numero elevato di falsi positivi rimane significativo. 5. Fingerprint TLS JARM In modo analogo a JA3 e JA3S, JARM è progettato per fingerprintare il comportamento TLS di un server interagendo attivamente con esso. A differenza degli approcci passivi, JARM invia una sequenza di dieci pacchetti TLS Client Hello appositamente costruiti e registra specifici attributi contenuti nelle risposte. I valori raccolti vengono poi hashati per generare un singolo fingerprint JARM, utilizzabile per confronti e attività di clustering. Quando applicato a infrastrutture Cobalt Strike, il fingerprint JARM risulta fortemente influenzato dal runtime Java utilizzato dal team server. Secondo la documentazione ufficiale, OpenJDK 11 rappresenta la versione raccomandata per gli operatori, il che porta a una certa uniformità nei fingerprint osservati nelle configurazioni di default. Questa coerenza può aiutare a restringere il campo dei potenziali server Cobalt Strike, ma introduce anche un limite significativo: numerosi servizi legittimi esposti su Internet utilizzano la stessa versione di Java, rendendo i falsi positivi inevitabili. Nella configurazione base, Cobalt Strike produce il seguente JARM fingerprint: 07d14d16d21d21d00042d41d00041de5fb3038104f457d92ba02e9311512c2 Nel tempo sono stati osservati e documentati anche altri fingerprint JARM associati a deployment Cobalt Strike. Anche in questo caso, tuttavia, la tecnica va considerata esclusivamente come un segnale di supporto. Utilizzato da solo, JARM non è sufficiente come metodo primario per l’identificazione di server di command and control in the wild, e i suoi risultati dovrebbero essere interpretati come un’indicazione che un determinato IP potrebbe essere correlato ad attività Cobalt Strike. Un ulteriore aspetto da considerare è che i fingerprint JARM non sono immutabili. Come dimostrato da Raphael Mudge, modifiche alla configurazione del server possono alterare in modo sostanziale il fingerprint risultante, riducendone ulteriormente l’affidabilità se utilizzato in isolamento. Per questo motivo, è spesso più efficace combinare JARM con altri punti dati disponibili nei grandi dataset di internet scanning, come fuzzy JARM hash, banner di servizio e numeri di serie TLS o hash dei certificati, al fine di aumentare il livello complessivo di confidenza. 6. Watermark (License ID) Un’informazione che si rivela spesso utile durante l’analisi di intrusioni che coinvolgono Cobalt Strike è il watermark presente all’interno della configurazione di BEACON. Questo parametro è un valore numerico derivato dal file di licenza di Cobalt Strike e, quando disponibile, può essere utilizzato per correlare più intrusioni o campagne riconducibili allo stesso operatore o threat actor. Nella pratica, una parte consistente dei deployment osservati utilizza un watermark pari a 0, un pattern comunemente associato a versioni piratate del framework distribuite su forum underground. Questo valore, preso da solo, offre scarso valore in termini di attribuzione. Al contrario, watermark diversi da zero hanno storicamente fornito contesto utile, soprattutto quando analizzati in combinazione con altre fonti di intelligence. Nel tempo, alcuni valori di watermark sono stati pubblicamente associati a specifici attori o ecosistemi malware: 305419896: è stato ricondotto ad un affiliato di Maze ransomware group; 1359593325: è stato associato ad operazione di TrickBot; 1580103814: è stato associato ad attività di BazarLoader; 688983459: associato alla versione 4.10; 1580103824: segnalato dal CERT-UA; 987654321, 666666666, 391144938: individuate su Shodan come “Cobalt Strike products”. Come per qualsiasi indicatore singolo, i watermark non dovrebbero mai essere considerati come prova definitiva di attribuzione. Inseriti però all’interno di un quadro più ampio, che includa pattern infrastrutturali, caratteristiche dei payload e tradecraft operativo, possono aggiungere un livello di contesto significativo alle attività di analisi e attribuzione. Conclusioni Nel corso di questo articolo abbiamo analizzato Cobalt Strike da due prospettive complementari: l’individuazione di impianti beacon attivi all’interno del perimetro e l’identificazione dell’infrastruttura di command and control esposta in the wild. Concentrarsi esclusivamente sull’infrastruttura senza una reale visibilità interna lascerebbe le funzioni di hunting cieche una volta ottenuto il primo foothold; allo stesso modo, limitarsi al solo hunting sugli endpoint significa ignorare il valore preventivo che deriva dal bloccare il C2 prima ancora che venga raggiunto. Nonostante le ampie possibilità di personalizzazione offerte dal framework, gli operatori fanno spesso affidamento su pattern consolidati, profili riutilizzati e infrastrutture che cambiano molto meno di quanto ci si aspetterebbe. Questa inerzia operativa crea con continuità opportunità di detection per chi privilegia il tradecraft, la coerenza comportamentale e l’analisi nel tempo rispetto a indicatori isolati e di breve durata. In definitiva, fare hunting su Cobalt Strike non significa identificare uno specifico tool o una particolare configurazione, ma riconoscere i comportamenti che il framework abilita nelle diverse fasi di un’intrusione. Adottando questa prospettiva, Cobalt Strike può diventare un problema affrontabile, osservabile e, soprattutto, eliminabile in modo sistematico.
blog.8bitsecurity.comJan 20, 2026source