Rilevamento di HinataBot: un'analisi approfondita di una minaccia basata su Go

• I ricercatori Akamai del Security Intelligence Response Team (SIRT) hanno rilevato una nuova botnet basata su Go e incentrata sugli attacchi DDoS. Il malware è stato chiamato "Hinata" dal suo autore in onore di un personaggio della popolare serie anime Naruto, da noi denominato "HinataBot". 

• HinataBot è stato distribuito durante i primi tre mesi del 2023 e viene attivamente aggiornato dagli autori/operatori. 

• Il campione è stato scoperto negli honeypot HTTP e SSH che abusavano di vecchie vulnerabilità e credenziali deboli. 

• I tentativi di infezione osservati includono lo sfruttamento del servizio SOAP miniigd su dispositivi Realtek SDK (CVE-2014-8361), router Huawei HG532 (CVE-2017-17215) e server Hadoop YARN esposti (CVE N/D). 

• Tramite una combinazione di reverse engineering del malware e imitazione del server di comando e controllo (C2), siamo stati in grado di esaminare in modo approfondito il funzionamento del malware e cosa rende unico il traffico di attacco che ne deriva.

I metodi di distribuzione osservati erano una combinazione di script di infezione e payload completi che utilizzavano due vulnerabilità principali: un Hadoop YARN RCE (Figura 1) e lo sfruttamento di una vulnerabilità nel servizio SOAP miniigd all'interno dei dispositivi Realtek SDK (CVE-2014-8361; Figura 2).

Questi attacchi si sono verificati in diversi giorni tra l'11 gennaio e il 16 gennaio 2023. Gli autori degli attacchi hanno utilizzato più versioni di script di infezione, che sono state aggiornate nel tempo. Tra questi script, i due principali sono stati denominati "wget.sh" (Figura 3) e "tftp.sh" (Figura 4), che riflettono i rispettivi protocolli utilizzati per recuperare il payload appropriato.

Il malware HinataBot è stato distribuito come binari Go, progettati per essere eseguiti su varie architetture e sistemi operativi. Questa tendenza degli autori di malware che sviluppano payload specializzati per più piattaforme è diventata sempre più comune negli ultimi anni (Figura 6), probabilmente a causa della facilità di compilazione incrociata, nonché dell'IoT (Internet of Things) e dei dispositivi per piccoli uffici/home office che eseguono architetture CPU meno comuni, un panorama dimostratosi fecondo di bersagli.

Utilizzando l'IP di distribuzione come pivot, siamo stati in grado di identificare due IP aggiuntivi precedentemente utilizzati per la distribuzione. In ciascun caso, l'IP pivot è stato utilizzato come proxy. Ulteriori analisi hanno rivelato che, prima di sviluppare il proprio malware basato su Go, gli aggressori avevano tentato di distribuire una variante Mirai generica con pacchetti UPX e che utilizzava un nome meno identificabile (Figura 7).

Inoltre, siamo stati in grado di identificare un'altra vulnerabilità di cui gli autori degli attacchi hanno abusato per distribuire versioni precedenti dei propri script di infezione (Figura 9). Questa vulnerabilità, CVE-2017-17215, interessa i router Huawei HG532 e consente l'esecuzione arbitraria di codice remoto.

Come affermato in precedenza, gli autori degli attacchi tramite HinataBot originariamente distribuivano i binari Mirai, una nota famiglia di malware che ha iniziato a prendere di mira i dispositivi IoT, resa open source e che ha continuato ad essere adottata da vari attori e gruppi (e si è evoluta di conseguenza) Mirai ora include più varianti e botnet create da più autori, aggressori e gruppi. 

Osservando i record DNS storici, possiamo osservare che a febbraio 2023 l'IP più recentemente associato a HinataBot si stava risolvendo per il dominio "hihi.mirailovers.pw" (Figura 10).

Inizialmente abbiamo tentato di raggiungere l'IP di distribuzione più recente, ma sebbene fosse possibile eseguire il ping, non siamo stati in grado di scaricare il campione direttamente dal server. Ciò potrebbe indicare che gli autori degli attacchi hanno implementato un meccanismo di protezione o che rimuovono i campioni dopo la distribuzione, rendendo più difficile ottenerli al di fuori di un attacco diretto. Nelle campagne precedenti degli stessi autori, abbiamo osservato modelli di nomi apparentemente casuali (vedi Figura 9).

Fortunatamente, siamo riusciti ad acquisire un campione tramite i nostri strumenti di analisi automatizzati che ne avevano memorizzato uno per noi al momento dell'infezione iniziale. Abbiamo scaricato entrambe le versioni MIPS32 e x86-64 dal nostro archivio di malware e abbiamo iniziato l'analisi statica. I file binari erano entrambi  scritti in Go, ma erano relativamente semplici da utilizzare, poiché erano non corrotti, decompressi e non estratti (Figura 11). Da allora le versioni dei binari nei giorni precedenti a questa pubblicazione sono state rimosse, il che renderà la decompilazione più impegnativa in futuro.

Innanzitutto, abbiamo iniziato ad analizzare un campione di malware HinataBot di due mesi prima (Figura 12), ma in seguito siamo venuti a conoscenza di un campione più recente (Figura 13) che era stato rilasciato lo stesso giorno in cui avevamo scoperto il malware nei nostri log. Successivamente siamo passati invece all'analisi del campione più recente. 

La differenza principale tra le due versioni è che il campione più recente è stato semplificato e presenta funzionalità più modulari. Inoltre, l'esempio più recente include alcune misure di sicurezza di base che non erano presenti nella versione originale. Approfondiremo queste differenze in maggiore dettaglio in una sezione successiva di questo post.

Durante la nostra analisi, diverse funzioni si sono subito distinte come degne di nota. Tre distinte funzioni di attacco hanno attirato immediatamente la nostra attenzione: sym.main.startAttack, sym.main.http_floode sym.main.udp_flood (figura 14). La denominazione di queste funzioni suggerisce che il malware era destinato a sferrare attacchi DDoS.

Un'ulteriore analisi del malware ha rivelato riferimenti alle comunicazioni C2, che hanno fornito ulteriori indizi sul fatto che HinataBot faceva parte di una campagna di creazione di botnet orientata agli attacchi DDoS (Figura 15). 

Per comprendere come il malware HinataBot stabilisca una connessione al proprio C2, abbiamo lavorato a ritroso dalla stringa "Connection to CNC is OK!" e iniziato a cercare riferimenti incrociati alla stringa (Figura 16). Questo processo ci ha permesso di mappare il meccanismo con cui il malware comunica con il proprio C2.

Dall'analisi del codice di assemblaggio sono stati anche scoperti i riferimenti a un'API utilizzata per le connessioni ("API_CONNECTION_ATTACK"), oltre a numerosi possibili comandi da inviare al dispositivo infetto che non vedevamo l'ora di provare (Figura 18).

A questo punto, eravamo fiduciosi che il nostro campione si sarebbe riconnesso al server di distribuzione/C2 per notificare al C2 che il bot era attivo e in esecuzione e che attendeva i comandi, ma il server C2 era ora offline. 

Un'osservazione interessante è che HinataBot apre anche una propria porta di ascolto su TCP/61420 (Figura 19). Poiché il nostro obiettivo principale di questa ricerca era comprendere meglio il traffico di attacco che questa botnet può generare, non abbiamo dedicato molto tempo ad approfondire questa funzionalità poiché sembrava non rientrare nell'ambito. 

Tuttavia, abbiamo notato che le differenze di temporizzazione di questo listener dipendono dal successo della connettività al C2. Nei casi in cui un C2 viene contattato con successo, questo listener si disattiverà dopo tre minuti. Nei casi in cui non è stato possibile raggiungere il C2, questa porta rimane in ascolto senza limiti di tempo apparenti. Sarà necessario condurre ulteriori ricerche su questa porta per comprendere appieno quali funzionalità consente agli operatori; ad esempio, se si tratta di una funzionalità di tipo peer-to-peer o eventualmente di una funzionalità di aggiornamento/controllo/ripristino. Al momento della stesura di questo documento, non siamo in grado di fornire una risposta definitiva.

Come notato in precedenza, il nuovo campione di HinataBot includeva alcune misure di sicurezza di base che erano assenti nelle versioni precedenti. La prima misura di questo tipo era un requisito password. Dopo aver eseguito il campione, la prima cosa che si nota è un'eccezione non rilevata. Nel messaggio di errore risultante risulta abbastanza chiaro (Figura 20). 

Dopo un esame più attento del messaggio di errore, abbiamo scoperto che l'esempio richiedeva il passaggio di un argomento aggiuntivo all'esecuzione. Mentre passare letteralmente qualsiasi cosa in questo argomento consentirà di superare l'eccezione non rilevata, HinataBot uscirà correttamente. Da qui, è risultato ovvio che dovevamo tornare al disassemblaggio per osservare cosa HinataBot potesse cercare in questo argomento.

Abbiamo cercato nel campione di malware e alla fine abbiamo identificato la stringa di 17 caratteri (0x005fe3d2) "HINATA_START_NICE" (0x005fe3d8) utilizzata in una chiamata sym.runtime.memequal (0x005fe3e0) che fallirebbe e causerebbe il passaggio del malware a un'istruzione ret, interrompendo l'esecuzione (Figura 21). Abbiamo usato questa stringa come argomento durante l'esecuzione del campione, che ha consentito all'esecuzione di passare a un codice più interessante.

È interessante notare che il personaggio dell'anime di Naruto chiamato Hinata è inizialmente un personaggio pacifico e gentile per poi diventare un feroce combattente, qualcosa a cui gli autori del malware potrebbero alludere quando usano l'argomento "HINATA_START_NICE", prima che il malware comunichi al suo C2 e partecipi al lancio degli attacchi

Vale la pena notare che questo requisito password non era presente nei precedenti campioni di malware HinataBot del gennaio 2023; pertanto la maggior parte degli script di infezione che abbiamo riscontrato non includeva questo argomento. Tuttavia, a un esame più attento dopo aver scoperto questo requisito, siamo stati in grado di rintracciare gli script di infezione più recenti (Figura 22), che hanno passato l'argomento ai file binari al momento dell'infezione. Sarebbe stato utile saperlo In anticipo.

La nostra analisi del campione HinataBot ha rivelato un gran numero di stringhe di testo in chiaro molto lunghe integrate nel binario. Go utilizza un approccio unico per archiviare i valori letterali stringa inserendoli in un blocco di memoria contiguo noto come tabella di stringhe o pool interno di stringhe."""" 

Di conseguenza, quando si esegue il comando delle stringhe o i disassemblatori su un binario Go, l'output può apparire come un miscuglio confuso di caratteri, rendendo difficile la distinzione tra le singole stringhe nella tabella (Figura 23).

Questa tecnica differisce da altri linguaggi di programmazione, che in genere memorizzano stringhe di byte che terminano con Null. Senza questi byte Null finali, gli strumenti continuano a leggere una stringa rilevata fino a quando non incontrano un byte Null. Questo rende una semplice analisi delle stringhe un po' più impegnativa.  

Osservare i riferimenti incrociati dai segmenti di codice nei segmenti di indirizzo della tabella delle stringhe può aiutare a identificare dove iniziano le singole stringhe nella tabella più grande. In genere, è anche possibile identificare la loro lunghezza caricata in un registro prima o dopo il caricamento della stringa o come parte di una chiamata di funzione che utilizzerà la porzione di stringa a cui si fa riferimento (Figura 24). Ci vuole un po' per abituarsi, ma una volta che acquisite familiarità con la convenzione, è piuttosto semplice.

L'handshake consisteva in una connessione iniziale, seguita dall'invio da parte del bot di un messaggio del tipo "API_CONNECTION_BOT [os]/[architecture] [hostname]". Il bot quindi si aspetta un messaggio del tipo API_CONNECTION_SIGNAL_OK di ritorno dal server C2, che preparerebbe il bot per l'ascolto dei comandi in arrivo (Figura 26) Eliminato l'handshake, inviamo il segnale API_CONNECTION_ATTACK: per avviare gli attacchi. 

Abbiamo creato un server C2 molto semplice per automatizzare il mantenimento di questa connessione e consentirci di modificare e inviare un comando memorizzato in un file di testo senza dover modificare il codice, il che ha consentito un test molto semplice e rapido (Figura 27). Questo ci ha consentito di risparmiare molto tempo nel corso di questa ricerca.

La versione più recente di questo malware ha due metodi di attacco principali: HTTP e UDP. La versione precedente conteneva questi due, oltre a metodi di attacco che sfruttavano i flood ICMP e TCP. Non è chiaro perché questi metodi siano stati rimossi.

Per esaminare più dettagliatamente il traffico di attacco effettivo, abbiamo utilizzato il nostro server C2 improvvisato per mantenere la connessione mentre il bot ci inviava heartbeat. In questo modo, ci siamo potuti concentrare solo sui comandi di attacco e senza doverci preoccupare di mantenere una connessione con il dispositivo infetto.

Dopo analisi e test approfonditi, siamo finalmente riusciti a mappare la struttura e i campi necessari per iniziare a lanciare attacchi e a catturare i pacchetti in transito. L'autore del malware sfrutta più convenzioni Go come funzioni anonime, goroutine, canali, pool di lavoro e gruppi di attesa, rendendo la decompilazione un po' più complicata. Alla fine, dopo una serie di test, abbiamo capito la struttura del comando di attacco (Figura 28). (Figure 28).

La struttura di comando di base, una volta finalmente mappata, è molto semplice. I comandi di attacco iniziano sempre con API_CONNECTION_ATTACK: seguito da tre campi obbligatori, ATTACK_TYPE, TARGETe DURATION dell'attacco. Per udp_flood c'è anche un quarto campo di attacco UDP_OPTIONS; questo campo è richiesto anche quando si lancia un attacco udp_flood a causa del modo in cui si verifica il controllo dei comandi, ma, stranamente, non è affatto necessario che sia valido.

Tipo di attacco 0: http_flood

Il comando http_flood non sembra utilizzare parametri di opzioni aggiuntivi come fa l'attacco udp_flood . Poiché si basa sulla libreria Go net.http nativa, la maggior parte della configurazione e delle opzioni di analisi per questo attacco proviene direttamente dalla libreria Go stessa ed è controllata tramite la direttiva TARGET . 

Nel comando di attacco nella Figura 29, stiamo sferrando un attacco http_flood (tipo 0) diretto a 127.127.127.127 su TCP/31337 che durerà 10 secondi. Il percorso, la porta, i parametri GET e il protocollo sono tutti dedotti da questa direttiva di destinazione. Se non viene fornita alcuna porta, l'impostazione predefinita sarà TCP/80.

Come accennato in precedenza, questo binario si appoggia alla libreria Go net.http per sferrare gli attacchi. Il bot crea un pool di lavoro di 512 processi di lavoro tramite Goroutine e ogni processo di lavoro crea il proprio oggetto net.http.Request . Nella Figura 30, possiamo vedere in parte come funziona dall'interno di un singolo processo di lavoro.

Innanzitutto, vengono creati un nuovo oggetto di contesto e una nuova classe RequestWithContext . Questo oggetto di contesto verrà popolato con intestazioni HTTP che verranno utilizzate durante l'attacco dalla classe RequestWithContext . Alcune di queste intestazioni sono statiche, mentre altre sono randomizzate. Nella Figura 30 sono riportate le chiamate Rand Seed e Intn , che vengono utilizzate per selezionare un User-Agent casuale da un elenco di 10 user-agent statici codificati all'interno del file binario. Descriveremo quali intestazioni cercare di seguito mentre analizziamo il traffico in uscita dal malware durante un attacco http_flood .

Esaminiamo alcune osservazioni importanti delle intestazioni HTTP acquisite durante gli eventi di attacco simulato. Ci sono diversi valori abbastanza ovvi qui per il fingerprinting, sia nei campi statici che randomizzati. Gli addetti alla sicurezza dovrebbero esaminare questo campione di traffico, ma per paura di aiutare l'autore a migliorare effettivamente le funzionalità di attacco, esitiamo a evidenziare esattamente perché questo traffico è probabilmente facile da individuare e bloccare per gli addetti alla sicurezza. Senza fornire troppo aiuto all'autore del malware, possiamo affermare che gran parte del payload è piuttosto statico, in termini di dimensioni, ordine e valore. Alcuni campi sono randomizzati: questi campi includono le intestazioni User-Agent (da un elenco di 10 user-agent statici), Keep-Alive e Cookie. Gli addetti alla sicurezza dovrebbero anche esaminare attentamente le intestazioni Host e Riferimento nel campione di traffico della Figura 31. Vale la pena notare che se il comando di attacco non specifica una porta di destinazione nella direttiva di destinazione, il valore predefinito sarà TCP/80 o TCP/443 e la porta non sarà inclusa in nessuna delle due intestazioni.

Questo comando di attacco ha un aspetto leggermente diverso dalla variante http_flood , principalmente a causa del valore UDP_OPTIONS passato (1531337) nel parametro finale. Questo parametro controlla la porta di destinazione a cui verranno inviati i pacchetti UDP. Il valore è in realtà composto da tre parti, la prima parte è il tipo di parametro (1), la seconda è la lunghezza (5) del valore e la terza è il valore stesso (31337). 

Sembra che questo quarto parametro sia richiesto per l'analisi dei comandi, ma il valore può essere scartato e se non viene fornito alcun valore di porta qui, il file binario verrà impostato automaticamente su UDP/80 come porta di destinazione dell'attacco. Inizialmente, si presumeva che, poiché questi dati vengono trasmessi in questo modo, avremmo trovato altri parametri di configurazione aggiuntivi per 1-9, ma sembra che solo il parametro della porta (1) abbia un effetto sul traffico di attacco in uscita dal bot.

Lo screenshot nella Figura 34 mostra la configurazione del socket udp_flood , che utilizza la libreria net di Go tramite net.Dial per creare il socket UDP. Quindi crea 512 processi di lavoro, che condividono il socket, ciascuno in esecuzione in un ciclo che trasmette i dati sul socket finché il timer della durata non invia loro un comando kill tramite un canale condiviso. I pacchetti UDP (Figura 35) in uscita dal bot sono molto grandi (65.549 byte per pacchetto in totale) ed è probabile che arrivino frammentati alle vittime tramite Internet . Questa dimensione è codificata all'interno del file binario e non è sotto il controllo dell'autore degli attacchi in base all'attacco.

I 65.507 byte racchiusi nel segmento di dati UDP sono tutti byte Null (Figura 36). L'intestazione ID IP incrementa in modo sequenziale durante l'attacco e, sebbene la porta di origine sia temporanea, rimane statica durante la durata del flood. Si tratta probabilmente di un effetto collaterale della gestione di net.Dial del socket UDP nell'intero pool di lavoro dell'autore degli attacchi. Un'altra cosa da notare sono i checksum non riusciti sui dati UDP.

IP

• 77.73.131.247
  

• 156.236.16.237
  

• 185.112.83.254
  

Porte

• 61420
  

• 4120
  

CVE

• CVE-2017-17215
  

• CVE-2014-8361
  

Nomi file

• tftp.sh
  

• wget.sh
  

• hinata-linux.amd64
  

• hinata-windows-arm5
  

• hinata-plan9-arm5
  

• hinata-openbsd-arm5
  

• hinata-netbsd-arm5
  

• hinata-linux-arm5
  

• hinata-freebsd-arm5
  

• hinata-windows-arm7
  

• hinata-windows-arm64.exe
  

• hinata-windows-arm6
  

• hinata-windows-arm
  

• hinata-windows-amd64.exe
  

• hinata-windows-386.exe
  

• hinata-solaris-amd64
  

• hinata-plan9-arm7
  

• hinata-plan9-arm6
  

• hinata-plan9-arm
  

• hinata-plan9-amd64
  

• hinata-plan9-386
  

• hinata-openbsd-mips64
  

• hinata-openbsd-arm7
  

• hinata-openbsd-arm64
  

• hinata-openbsd-arm6
  

• hinata-openbsd-arm
  

• hinata-openbsd-amd64
  

• hinata-openbsd-386
  

• hinata-netbsd-arm7
  

• hinata-netbsd-arm64
  

• hinata-netbsd-arm6
  

• hinata-netbsd-arm
  

• hinata-netbsd-amd64
  

• hinata-netbsd-386
  

• hinata-linux-s390x
  

• hinata-linux-riscv64
  

• hinata-linux-ppc64le
  

• hinata-linux-ppc64
  

• hinata-linux-mipsle
  

• hinata-linux-mips64le
  

• hinata-linux-mips64
  

• hinata-linux-mips
  

• hinata-linux-arm7
  

• hinata-linux-arm64
  

• hinata-linux-arm6
  

• hinata-linux-arm
  

• hinata-linux-amd64
  

• hinata-linux-386
  

• hinata-js-wasm
  

• hinata-illumos-amd64
  

• hinata-freebsd-arm7
  

• hinata-freebsd-arm64
  

• hinata-freebsd-arm6
  

• hinata-freebsd-arm
  

• hinata-freebsd-amd64
  

• hinata-freebsd-386
  

• hinata-dragonfly-amd64
  

• hinata-darwin-arm64
  

• hinata-darwin-amd64
  

• hinata-android-arm64
  

• hinata-aix-ppc64
  

Hash recenti

• 01422e34b2114c68cdb6ce685cd2e5673bbe5652259a0c4b862d5de2824a9375
  

• 1b958fd718f1419700c53fed10807e873e8399c354877b0a3dfceac7a8581456
  

• 8a84dc2a9a06b1fae0dd16765509f88f6f54559c36d4353fd040d02d4563f703
  

• 4aba67fdd694219ff0dff07ebd444ed154edacc00c3a61f9b661eabe811a0446
  

• 71154ad6bd1a8a79fc674c793bb82b8e7d1371eca0f909c6e4a98ef8e7f5d1da
  

• c6a7e25290677cc7b9331343166b140f2c320764a815b241747e6913b1a386d9
  

• 92adfbe6aae06d7c99469aeb6551db8eee964b589f2b8774e29d987cfbd0e0d6
  

• 8eda08ce362c09b5f45772467f94d5370068c1798f78c5316f15647ac898c621
  

• ff7638c0c893c021c3a059a21a71600249881afd84dc0d751d99db1c8edd3cac
  

• a3fac6fea9201c3c3eaae47bd95e0be93e91298e48df75540958834f9e75ac4d
  

• 9875bb9dd6d159a3b327de80e151ef7f3831c0d6833ae781490d68e426b73680
  

• 6ec35ef48ffdf9a92aa8845c336b327c280e1f20d7130ba0856540aed3233bbc
  

• C0aa34dd8dbf654d5230d4ef1db61f9befc89a0ea16cb7757edbf8a8090c9146
  

• 5643bf01e113de246575a9ec39ea12a85f9babb6ac069132ad8d1a7bfa56ed1b
  

• 845134ee7335f07b23e081f024cad5cbfc9ef453d6e2adc7970d6543292e5bcc
  

• 995681f388f5e0a405c282ae9ce22dc41f2249f0f5208254e1eec6e302d7ad7d
  

• 07326cce5325eabbe1caa2b3f8a4ab78e7913b65703c0afc3bab808441c30688
  

• 61181b4b7b7040ce4ab9c489a2b857f5a7fe8407c422327fff798f3b55e0cbe3
  

• 75c050580725279a6592eecc2b02b6fa78f5469c2f08fb1d0e2fe616beb8bf0d
  

• E3427838132b6161f10e77d0beca1beac90c63a8ccc4aabd523041aec25aab67