Vi serve il cloud computing? Iniziate subito

Dark background with blue code overlay

Blog

Mining Rig di Panchan: è arrivata la nuova botnet peer-to-peer in Golang

Stiv Kupchik

scritto da

Stiv Kupchik

June 15, 2022

Stiv Kupchik

scritto da

Stiv Kupchik

Stiv Kupchik svolge il ruolo di Security Researcher Team Lead in Akamai. I suoi progetti di ricerca ruotano intorno ai componenti interni dei sistemi operativi, alla ricerca sulle vulnerabilità e all'analisi dei malware. Ha presentato la sua ricerca in occasione di conferenze come Black Hat, Hexacon e 44CON. Oltre ad essere un esperto di cybersicurezza, Stiv ha conseguito anche una laurea in fisica.

Mining Rig di Panchan: è arrivata la nuova botnet peer-to-peer in Golang

Scritto da: Stiv Kupchik

Analisi riassuntiva

  • I ricercatori sulla sicurezza di Akamai hanno scoperto Panchan, una nuova botnet peer-to-peer con un worm SSH che è comparsa a marzo 2022 e da allora sta violando attivamente i server Linux.

  • Panchan è scritto in Golang e utilizza le funzionalità di concorrenza integrate per massimizzare la diffusione ed eseguire moduli malware.

  • Oltre all'attacco al dizionario SSH di base, comune alla maggior parte dei worm, questo malware raccoglie anche le chiavi SSH per eseguire il movimento laterale.

  • I ricercatori sulla sicurezza di Akamai sono stati in grado di accedere al protocollo di comunicazione del malware e al relativo pannello di amministrazione e utilizzarli per analizzare la portata dell'infezione del malware.

  • Il segmento verticale preso maggiormente di mira da Panchan (dopo le telecomunicazioni/VPS) è il settore dell'istruzione. Supponendo che la collaborazione tra diversi istituti accademici potrebbe comportare la condivisione delle chiavi SSH tra le reti, da ciò si potrebbe spiegare perché questo segmento verticale è in cima alla lista. I ricercatori sulla sicurezza di Akamai hanno individuato le e-mail dannose associate a ogni IP preso di mira.

  • Per evitare il rilevamento e ridurre la tracciabilità, il malware rilascia i suoi cryptominer come file mappati in memoria, senza alcuna presenza su disco, ed elimina i processi del cryptominer se ne rileva un eventuale monitoraggio.

  • Sulla base dell'attività del malware e della geolocalizzazione della vittima, della lingua del pannello di amministrazione e dell'attività dell'utente Discord del criminale, riteniamo che l'autore delle minacce sia giapponese.

  • Akamai MFA può mitigare il rischio rappresentato dalla raccolta di chiavi SSH. Inoltre, la configurazione di password SSH complesse dovrebbe bloccare il malware, che utilizza un elenco molto semplice di password predefinite per diffondersi. Abbiamo anche pubblicato IOC, query, firme e script da poter utilizzare per testare l'infezione.

Introduzione

Il Mining Rig di Panchan è una botnet in Golang con tante funzionalità e un cryptojacker. Il suo protocollo peer-to-peer è semplice: testo in chiaro su TCP, ma abbastanza efficace per decentralizzare la botnet. È anche persistente e perseverante e in grado di monitorare l'elusione.

 

La risposta peer-to-peer del malware con il suo nome

Nel malware è integrata una "modalità God", ossia un pannello di amministrazione in grado di modificare la configurazione di mining, che viene quindi distribuita al resto dei suoi peer. Per evitare manomissioni indesiderate, l'accesso alla modalità God richiede una chiave privata, che viene quindi utilizzata per firmare la configurazione di mining. Il malware contiene una chiave pubblica che viene utilizzata per verificare la chiave privata fornita. Il pannello di amministrazione è scritto in giapponese, il che suggerisce la geolocalizzazione del suo creatore.

La botnet introduce un approccio unico (e forse nuovo) al movimento laterale mediante la raccolta di chiavi SSH. Invece di usare solo la forza bruta o gli attacchi al dizionario su indirizzi IP casuali come avviene nella maggior parte delle botnet, il malware legge anche i file id_rsa and known_hosts per raccogliere le credenziali esistenti e utilizzarle per spostarsi lateralmente nella rete.

Il malware è scritto in Golang e utilizza le funzionalità di concorrenza di Golang per la maggior parte della logica principale, eseguendole come routine Go simultanee. L'autore di questa minaccia è in cima alle nuove versioni di Go: la prima versione del malware rilevata (da marzo 2022) è stata compilata utilizzando Go 1.17.7 (rilasciato a febbraio 2022), mentre l'ultimo campione è stato compilato utilizzando Go 1.18 (rilasciato a marzo 2022). Inoltre, Go 1.18 ha apportato alcune modifiche alle sue strutture dati interne, quindi né gli strumenti online né il disassemblatore IDA potevano analizzare correttamente il malware e abbinare il nome della funzione al puntatore funzione. Nell' Appendice A: breve analisi della decompilazione Go, descriviamo come abbiamo superato questo problema..

In questo rapporto, descriveremo in dettaglio le funzionalità del malware, come l'abbiamo rilevato e il processo che abbiamo seguito per tentare di attribuirlo. 

Per un elenco di IoC, potete visualizzare l'archivio Github qui.

Attività del malware

Il team di ricerca sulla sicurezza di Akamai monitora in modo proattivo l'attività di botnet e malware sulla nostra rete globale di sensori. Abbiamo notato per la prima volta l'attività di Panchan il 19 marzo 2022. La comunicazione peer-to-peer e la funzionalità worm del malware hanno attirato la nostra attenzione e hanno richiesto ulteriori indagini. 

Durante il reverse engineering del malware, abbiamo sviluppato alcuni script in grado di "sintonizzarsi" sulla botnet, che hanno consentito al team di raccogliere un elenco completo di computer infetti (peer di botnet). Abbiamo rilevato 209 peer, 40 dei quali sono attualmente attivi. 

Mappa della distribuzione mondiale delle vittime

Sebbene gli obiettivi siano distribuiti in tutto il mondo, sembra esserci una maggiore concentrazione di obiettivi in Asia.

Tabella con il numero di vittime per continente

La nostra attribuzione delle origini giapponesi dell'autore delle minacce (come descritto in dettaglio più avanti) potrebbe spiegare il maggior numero di obiettivi in Asia. Dal momento che non sembra esserci un'organizzazione dietro questo malware, è plausibile che sia più facile per l'autore delle minacce attenersi a ciò è vicino e familiare.

Osservando i segmenti verticali delle vittime, la maggior parte degli IP delle vittime è registrata nella propria piattaforma di hosting/VPS, in cui non sono presenti molte informazioni. Il segmento verticale più comune tra le vittime monitorate è stato quello dell'istruzione. Ciò potrebbe essere dovuto alla scarsa gestione della password o correlato alla capacità unica di movimento laterale del malware con chiavi SSH rubate. I ricercatori di diversi istituti accademici potrebbero collaborare più frequentemente rispetto ai dipendenti del settore aziendale e richiedere credenziali per autenticarsi su computer al di fuori della propria organizzazione/rete. A rafforzare questa ipotesi, abbiamo osservato che alcune delle università coinvolte provenivano dallo stesso paese (ad es. Spagna) e altre dalla stessa regione (es. Taiwan e Hong Kong).

Analisi delle funzionalità del malware

 

Vettore di infezione: worm SSH

Flusso di infezione del malware

Il malware, in grado di diffondersi automaticamente tramite SSH, utilizza due metodi per generare i suoi obiettivi con i dettagli di autenticazione:

     chiavi SSH esistenti

Il malware cerca nella directory HOME dell'utente in esecuzione la configurazione e le chiavi SSH. Legge la chiave privata in ~HOME/.ssh/id_rsa e la utilizza per tentare di autenticarsi a qualsiasi indirizzo IP trovato in ~HOME/.ssh/known_hosts. Questo è un nuovo metodo di raccolta delle credenziali il cui utilizzo non è stato da noi osservato in altri malware.

     Credenziali di forza bruta

Il malware può randomizzare gli indirizzi IP e tentare un attacco tramite dizionario utilizzando un elenco di utenti e password predeterminati. Lo spreader di forza bruta viene generato più volte in un processo separato, vincolato solo al limite impostato del sistema operativo sui file aperti. I nomi utente e le password sono abbastanza semplici: combinazioni di stringhe predefinite come "ubuntu," "radice," "utente," '‘debian," "pi," ecc.

Dopo una corretta autenticazione nella destinazione, il malware crea una cartella nascosta con un nome casuale nella directory principale / e si copia nella cartella nascosta con il nome xinetd tramite sftp.

Il malware esegue quindi in remoto il file binario copiato sul computer di destinazione (utilizzando nohup) e gli passa un elenco di peer tramite la riga di comando. Dopo un'infezione riuscita, il malware avvia un'operazione HTTPS POST su un webhook Discord, che viene probabilmente utilizzato per il monitoraggio delle vittime.

Comunicazione peer-to-peer

Il protocollo peer-to-peer della botnet è abbastanza semplice. Tutto viene inviato in testo in chiaro tramite la porta TCP 1919. Tutti i peer sono in ascolto su quella porta e creano una regola per autorizzarlo in iptables. Ogni messaggio inizia con il Mining Rig di Panchan "hi!" e termina con "finish". Tra essi, il malware invia comandi di configurazione separati da ritorni a capo. Abbiamo osservato solo due opzioni di configurazione: sharepeer e sharerigconfig

sharepeer  è abbastanza semplice: è seguito da un IP, che viene quindi aggiunto all'elenco dei peer interni del malware

sharerigconfig è seguito da una stringa con codifica base64, che in realtà è una struttura JSON che codifica la configurazione di mining e una firma di tale configurazione:

 

sharerigconfig è seguito da una stringa con codifica base64
sharerigconfig è seguito da una stringa con codifica base64 (seconda parte)

La firma viene convalidata tramite una chiave pubblica salvata internamente per garantire l'autenticità. Anche la logica di comunicazione è semplice: durante una connessione da o verso un peer, il malware analizza la relativa configurazione salvata in memoria (ottenuta in precedenza, quando ha iniziato l'esecuzione), genera la stringa del messaggio e la invia. Riceve anche un messaggio simile dall'altro lato e lo analizza. Nuovi peer vengono aggiunti all'elenco dei peer, mentre la configurazione viene sovrascritta se è di una versione più recente.

Per verificare la presenza di aggiornamenti, il malware si connette periodicamente ai suoi peer salvati.

Modalità God

Questa è probabilmente la funzionalità più esclusiva del malware: Dispone di un pannello amministrativo integrato direttamente nel file binario del malware. Per avviarlo, è necessario passare al malware la stringa della modalità God come primo argomento della riga di comando (seguito da un elenco di peer).

Controllo degli accessi

Anche se il pannello di amministrazione è integrato nel malware, non può accedervi qualunque utente. Per prevenire accessi indesiderati al pannello, il malware richiede prima una chiave privata e solo dopo la convalida è possibile accedere alla sua interfaccia.

 

Controllo della chiave privata

Non avevamo la chiave privata necessaria, quindi abbiamo corretto il programma per saltare la convalida della chiave e accettare qualsiasi chiave privata fornita (ha richiesto solo una singola modifica da JZ a JMP).

 

Prima e dopo il file binario modificato per ignorare la convalida della chiave privata

 

Pannello di amministrazione: statistiche

Dopo aver fornito la chiave privata e aver effettuato l'accesso, veniamo accolti da una schermata di stato sulla configurazione corrente.

 

 Prima e dopo il file binario modificato per ignorare la convalida della chiave privata

La prima sezione riguarda le statistiche dei peer, che vengono contattate prima dell'avvio della modalità God, in base all'elenco dei peer che viene passato sulla riga di comando del malware (non avendo fornito un elenco dei peer durante l'analisi, è pari a zero).

La seconda sezione è la configurazione del crypto-mining. È nello stesso formato della configurazione di mining inviata tra peer, ma con testo giapponese anziché inglese. La differenza di lingua è probabilmente dovuta alla facilità di programmazione: stampare il testo giapponese è semplice, ma analizzarlo è più difficile, quindi il creatore del malware ha utilizzato l'inglese nella configurazione inviata tra i peer.

Infine, viene visualizzato un menu con le seguenti opzioni:

  1. Aggiorna la schermata di stato

  2. Stampa l'elenco dei peer attivi

  3. Aggiorna le impostazioni del miner

  4. Esci

Pannello di aggiornamento della configurazione di mining

 

Miner senza file

Il malware implementa due miner: xmrig e nbhash. Entrambi i file binari del miner sono codificati in base64 all'interno del binario del malware stesso e vengono estratti ed eseguiti durante il runtime. Tuttavia, l'esecuzione presenta alcune novità, poiché i miner non vengono affatto estratti sul disco. Invece, il malware utilizza la funzione UNIX memfd_create per creare un file mappato in memoria con il contenuto binario del miner, in modo da poterlo eseguire direttamente dalla memoria senza un percorso di file system tracciabile Dalla configurazione che abbiamo estratto da vari peer di botnet, sembra che utilizzi il malware NiceHash per i suoi mining pool e wallet. I portafogli NiceHash non appartengono alla blockchain, pertanto non possiamo vedere i relativi dettagli di transazioni e mining per misurare i profitti effettivi.

Anti-terminazione

Il malware rileva i segnali di terminazione di Linux (in particolare SIGTERM, 0xF e SIGINT, 0x2) che gli vengono inviati e li ignora. Ciò rende più difficile terminare il malware, ma non impossibile, poiché SIGKILL non viene gestito (poiché non è possibile, secondo lo standard POSIX, pagina 313)

Anti-monitoraggio

Questo modulo viene chiamato internamente anti-task manager, ma, contrariamente al suo nome, non interferisce con il funzionamento del task manager. Invece, il malware cerca continuamente i processi top e htop. Dopo averli trovati, termina i processi di mining attualmente in esecuzione.

Persistenza

Il malware si copia in /bin/systemd-worker e crea un servizio systemd con lo stesso nome. Questa azione viene probabilmente eseguita per imitare i servizi di sistema legittimi al fine di ridurre i sospetti ed evitare indagini.

Attribuzione

Durante la convalida della chiave privata, nel pannello della modalità God, viene visualizzata una schermata aggiuntiva.

 

Schermata di verifica della chiave privata della modalità God

La richiesta di copyright è piuttosto interessante: menziona Panchan e dispone di un effettivo server Discord! Seguendo il collegamento, sembra che possiamo effettivamente accedere a tale server e ottenere anche il nome utente Discord effettivo utilizzato da Panchan. Abbiamo supposto che questo server sia lo stesso a cui il malware invia i segnali dopo una connessione SSH riuscita.

 

Invito del server Discord

Ci siamo aggiunti al server, sperando di trovare informazioni sull'autore delle minacce e visualizzare le notifiche Discord inviate dal malware come parte del flusso di infezione. Non abbiamo trovato nulla di tutto ciò: la chat principale era vuota, ad eccezione di un saluto da parte di un altro membro inviato a marzo. Probabilmente, sono presenti altre chat disponibili solo per i membri del server con privilegi più elevati: ecco perché non le abbiamo visualizzate. L'unica informazione utile che abbiamo trovato è che il server è stato creato all'inizio di marzo 2022, una data molto vicina alla nostra prima osservazione del malware.

Cercando altre attività di quell'utente, potremmo anche trovarlo attivo nel server Discord di Privex (un provider VPS).

 

Attività dell'autore della minaccia in Privex Discord

Oltre ai normali VPS, Privex offre anche VM preinstallate con il software del nodo della blockchain. Ciò potrebbe significare che l'autore della minaccia le stia utilizzando per ospitare il proprio server o forse sta prendendo attivamente di mira le proprie macchine virtuali per il crypto-jacking.

Rilevamento e mitigazione

Per facilitare il rilevamento, abbiamo creato un archivio con IOC e firme Yara e Snort da poter utilizzare per testare l'infezione. Abbiamo anche sviluppato uno script bash che può essere eseguito su una VM. Cercate i seguenti indicatori Panchan:

  • Il processo systemd-worker

  • Il processo xinetd, se viene eseguito da un percorso diverso da /bin o /sbin

  • Processi in ascolto sulla porta TCP 1919

Inoltre, la comunicazione in uscita sulle porte TCP 3380 e 3387 potrebbe indicare un traffico verso il pool di crittografia.

Per i lettori che vogliono difendere in modo proattivo le proprie reti, possiamo consigliare quanto segue:

  • Usare password sicure e complesse. Il malware utilizza un numero molto limitato di combinazioni di nome utente e password predefinite che non devono essere configurate su alcun computer di produzione. La creazione di password complesse può ridurre notevolmente l'impatto del malware.

  • Configurare l'MFA ove possibile. L'utilizzo dell'MFA impedirebbe qualsiasi tentativo di accesso non autorizzato. Akamai MFA può anche contribuire alla protezione dalla raccolta di chiavi SSH.

  • Segmentare la rete ove possibile. Sebbene sia legittimo disporre di computer aperti a Internet tramite SSH, è consigliabile controllare chi è autorizzato a connettersi ad essi da Internet, nonché con chi è autorizzato a connettersi all'interno della rete. La configurazione di tali controlli di accesso riduce l'impatto che un computer violato può avere sulla rete, oltre a ridurre la superficie di attacco complessiva.

  • Monitorare l'attività delle risorse delle macchine virtuali. Le botnet di questo tipo, il cui obiettivo finale è il crypto-jacking, possono aumentare l'utilizzo delle risorse dei computer a livelli anormali. Il monitoraggio costante può avvisare in caso di attività sospette. Nel caso di Panchan, anche il monitoraggio dell'utilizzo delle risorse avrebbe interrotto completamente il crypto-mining.

 

Appendice A: breve analisi della decompilazione Go

I file eseguibili Go vengono compilati staticamente, il che significa che tutte le dipendenze dell'eseguibile vengono compilate direttamente nel file binario. In tal modo, si creano enormi file binari con molte funzioni (per riferimento, il nostro malware era di 30 MB con circa 3.700 funzioni).

Per aiutare con le tracce dello stack, Go dispone di una struttura pclntab che abbina nomi di funzione e puntatori all'interno del file binario. Questa struttura esiste anche nei file binari separati, quindi possiamo usarla per trovare i nomi delle funzioni.

 

Pclntab Go all'interno di un file binario Go

In Go 1.18, questa struttura è cambiata. Mentre prima conteneva puntatori a posizioni nel file binario, ora contiene invece gli offset da posizioni specifiche: i puntatori funzione sono ora offset dalla prima funzione Go (che è indicata nella struttura pcln commentata come text_start nell'immagine sopra), i puntatori nome sono offset dall'inizio della matrice del nome della funzione e ad entrambi viene fatto riferimento da offset in una matrice diversa che contiene i dati della funzione

 



Stiv Kupchik

scritto da

Stiv Kupchik

June 15, 2022

Stiv Kupchik

scritto da

Stiv Kupchik

Stiv Kupchik svolge il ruolo di Security Researcher Team Lead in Akamai. I suoi progetti di ricerca ruotano intorno ai componenti interni dei sistemi operativi, alla ricerca sulle vulnerabilità e all'analisi dei malware. Ha presentato la sua ricerca in occasione di conferenze come Black Hat, Hexacon e 44CON. Oltre ad essere un esperto di cybersicurezza, Stiv ha conseguito anche una laurea in fisica.