Nella rassegna di questa settimana, il team Cyber Threat Intelligence (CTI) di Tanium analizza il gruppo di ransomware BERT, emerso di recente, che sta ora prendendo di mira le piattaforme Windows e Linux nei settori della tecnologia, della sanità e dei servizi per eventi. Successivamente, il team esamina una campagna condotta da un broker di accesso iniziale (IAB) che, per il momento, viene identificato con il codice TGR-CRI-0045. Infine, analizziamo l’evoluzione di XWorm in un trojan di accesso remoto (RAT) altamente adattabile.
Il ransomware BERT prende di mira le piattaforme Windows e Linux
Trend Micro ha fornito ulteriori dettagli sul gruppo di ransomware BERT, recentemente emerso. Il gruppo, attivo fin dal aprile 2025, sta ora prendendo di mira organizzazioni in Asia, Europa e Stati Uniti con attacchi multipiattaforma rivolti sia ai sistemi Windows che a quelli Linux .
Nonostante il codice sia semplice, BERT ricorre a tattiche aggressive quali la crittografia simultanea e lo spegnimento di ESXi per massimizzare il disagio causato e aumentare il proprio potere negoziale in materia di riscatto.
Come funziona la variante “ Windows ” di BERT?
Secondo Trend Micro, il gruppo utilizza una struttura di codice semplice per la versione “ Windows ” del proprio ransomware, con stringhe specifiche che provocano la chiusura dei processi.
Trend Micro ha riscontrato che la chiave pubblica, l’estensione del file e la richiesta di riscatto erano tutte facilmente individuabili nel codice e ha individuato l’utilizzo dello standard AES per la crittografia.
[Legga anche: L’arte della negoziazione con gli autori di ransomware]
Trend Micro ha inoltre individuato ulteriori campioni di BERT che erano stati caricati in rete. Molte di queste sembravano essere versioni precedenti prive di crittografia e di altre caratteristiche rilevate nella loro telemetria interna, il che indica che vi sono state diverse iterazioni di BERT.
Inoltre, Trend Micro ha individuato uno script denominato “ PowerShell ” che funge da caricatore per il payload effettivo del ransomware BERT. Questo script PowerShell “aumenta i privilegi, disattiva Windows Defender, il firewall e il controllo degli account utente (UAC), quindi scarica ed esegue il ransomware da un indirizzo IP remoto”.
Evoluzione delle varianti di BERT
Le varianti precedenti procedevano innanzitutto a enumerare le unità e a inserire la richiesta di riscatto in ogni directory. A quel punto raccoglierebbero i percorsi dei file necessari, li memorizzerebbero in un array e procederebbero con la crittografia.
La variante più recente utilizza una ConcurrentQueue di e crea un DiskWorker di su ciascuna unità per ottimizzare il processo di crittografia. Questo approccio consente la crittografia multithread, permettendo a BERT di avviare la crittografia dei file non appena vengono identificati, anziché attendere di aver raccolto tutti i percorsi dei file, aumentando così in modo significativo la velocità e l’efficacia.
Cosa occorre sapere sulla variante “ Linux ”
Nel mese di maggio, Trend Micro ha individuato una variante di BERT Linux che utilizza 50 thread per massimizzare la velocità di crittografia. Questa variante accetta tre parametri della riga di comando:
- Per specificare la directory di destinazione da crittografare
- Per impostare il numero di thread per la crittografia (il valore predefinito è 50)
- Per attivare la modalità silenziosa
Qualora il ransomware venga eseguito senza tali parametri, provvederà a spegnere le macchine virtuali, terminando tutti i processi delle macchine virtuali in esecuzione all’interno dell’host ESXi. Una volta che questa variante avrà completato la propria routine di crittografia, aggiungerà l’estensione .encrypted_by_bert a ciascun file e inserirà la richiesta di riscatto.
Trend Micro ritiene che il gruppo possa aver ricavato questa variante dalla variante “ Linux ” di REvil.
Commenti degli analisti del team Cyber Threat Intelligence di Tanium
Sono trascorsi solo pochi mesi dalla comparsa di BERT, ma esistono già varianti che prendono di mira sia i sistemi “ Windows ” che quelli “ Linux ”, il che evidenzia una tendenza crescente tra gli autori delle minacce a progettare malware e ransomware in grado di sfruttare gli ambienti ibridi.
La conclusione è che il codice di BERT è relativamente semplice, ma il gruppo che lo ha sviluppato eccelle nel mettere in atto attacchi. Ciò ci ricorda che l’efficacia di una minaccia non sempre è correlata alla sua complessità tecnica.
TGR-CRI-0045 exploit sfruttano le chiavi dei dispositivi trapelate per accedere alle organizzazioni
Palo Alto ha recentemente individuato , una campagna condotta da un IAB, che sta temporaneamente monitorando con il codice TGR-CRI-0045.
È stato rilevato che questo attore sfruttava chiavi di sistema ASP.NET trapelate per dirottare le sessioni e ottenere accesso non autorizzato ai server Internet Information Services (IIS) di Microsoft , consentendo una persistenza nascosta e ulteriori compromissioni.
Come è stata scoperta questa vulnerabilità di IIS
All’inizio di quest’anno, Palo Alto ha affrontato alcune intrusioni nei server web in due diversi ambienti dei clienti. Entrambe le intrusioni hanno comportato l’esecuzione di una shell di comando proveniente da un processo di lavoro di IIS e presentavano caratteristiche comuni.
Dall’indagine è emerso che l’autore dell’attacco «ha eseguito comandi che caricavano assembly .NET gestiti (codice C#) direttamente in memoria (caricamento riflessivo)». Questo exploit prendeva di mira il View State, ovvero un parametro presente nei siti ASP.NET in esecuzione su IIS Microsoft .
Spiegazione della catena di exploit TGR-CRI-0045
I siti web utilizzano il View State per gestire le interazioni tra browser e server. È emerso che il parametro _VIEWSTATE dell' è vulnerabile a causa di tecniche di deserializzazione che gli autori degli attacchi possono utilizzare per consentire l'esecuzione di codice da remoto. Tuttavia, ciò può avvenire solo se l'autore dell'attacco dispone della chiave del computer corretta.
È noto che gli autori degli attacchi ricorrano all’utilizzo di elenchi di chiavi di sistema trapelate oppure estraggano le chiavi direttamente dai server in esecuzione. Una volta in possesso di tali chiavi, indipendentemente dal metodo utilizzato, possono creare il payload di deserializzazione e sferrare l’attacco contro il server.
Secondo Palo Alto, TGR-CRI-0045 avrebbe utilizzato strumenti quali , ysoserial.net e — un generatore di payload open source per la creazione di payload dannosi basati sulla deserializzazione.
Comprendere gli assemblaggi
Palo Alto ha individuato cinque sottoinsiemi di assembly .NET che sono stati caricati in memoria dopo che l’autore dell’attacco ha sfruttato la vulnerabilità relativa allo stato di visualizzazione. Tra questi figurano:
cmd /c: Esegue comandi di sistema arbitrari sul server compromesso- Vincitore: Probabilmente utilizzato per verificare il successo dello sfruttamento o la prontezza dell’ambiente
- Caricamento di file: Consente all’autore dell’attacco di caricare file o strumenti dannosi direttamente sul server a scopo di ulteriore sfruttamento o persistenza
- Download del file: Consente all’autore dell’attacco di sottrarre dati sensibili o di recuperare payload dall’ambiente compromesso
- Caricatore riflettente: Inietta ed esegue assembly .NET direttamente in memoria senza ricorrere al disco, una tecnica di elusione fondamentale che evita la scrittura di artefatti sul disco e contribuisce ad aggirare i metodi di rilevamento tradizionali
Tutte queste assemblaggi presentavano caratteristiche simili nella gestione dei dati ed effettuavano le stesse chiamate per terminare le risposte HTTP.
Cosa accade dopo lo sfruttamento?
Le attività successive allo sfruttamento condotte da questo attore hanno compreso la ricognizione sia dell’host compromesso che della rete. Palo Alto rileva che l'autore dell'attacco ha utilizzato sistematicamente il percorso Windows\Temp\111t come directory di staging.
Per l’escalation dei privilegi, l’autore dell’attacco ha utilizzato un file binario personalizzato updf, in grado di eseguire comandi con privilegi SYSTEM, nonché di creare nuovi utenti locali e di aggiungere tali utenti al gruppo di amministratori locali.
L'autore dell'attacco scaricava inoltre frequentemente un file binario ELF denominato (attualmente disponibile all'indirizzo), utilizzava e TxPortMap per identificare i server raggiungibili dal dispositivo inizialmente compromesso ed effettuava operazioni di ricognizione tramite la shell di comando.
Commenti degli analisti del team Cyber Threat Intelligence di Tanium
L'analisi di Palo Alto evidenzia come gli IAB si stiano evolvendo in termini di sofisticazione tecnica. Non si affidano più esclusivamente a tecniche tradizionali quali l’ , il phishing o l’attacco di forza bruta.
L'analisi evidenzia inoltre come la gestione delle informazioni riservate, quali le chiavi di sistema, debba essere trattata alla stregua delle credenziali o dei token API, poiché un uso improprio può causare gravi incidenti di sicurezza.
Il rapporto include linee guida per la correzione e il rafforzamento della sicurezza di , oltre a una sintesi più ampia delle implicazioni delle tecniche di attacco in memoria rivolte a IIS.
XWorm si evolve in un RAT modulare e elusivo
Secondo Splunk, XWorm si è evoluto in un trojan di accesso remoto modulare che sfrutta formati di file mutevoli, linguaggi di scripting e tecniche di offuscamento per eludere il rilevamento e distribuire i propri payload.
L'analisi di Splunk mette in evidenza la struttura modulare del malware e i suoi legami con le operazioni di ransomware. Il rapporto fornisce inoltre strategie di rilevamento concrete per aiutare i responsabili della sicurezza a contrastare il suo comportamento furtivo.
L'analisi di un attacco di phishing XWorm
Splunk osserva che XWorm sta alternando diversi formati di file e linguaggi di scripting nell’ambito di una più ampia strategia volta a eludere i sistemi di difesa. Il malware utilizza inoltre una serie di dropper, stager e loader nella propria catena di infezione.
Gli analisti hanno approfondito l'analisi di XWorm per identificare i vari formati di file che utilizza. Il team ha estratto 1.000 campioni di XWorm da Malware Bazaar, alla ricerca di tipi di file più particolari rispetto ai tradizionali file * EXE * e *DLL*. Tra i tipi di file più comunemente utilizzati figurano VBS, batch, JavaScript e PowerShell. Questo tipo di file viene spesso inviato tramite e-mail.
Analogamente, Splunk ha analizzato i nomi dei file per comprendere quale tipo di esca di ingegneria sociale possa essere utilizzata più spesso da XWorm. Hanno individuato diversi temi ricorrenti, tra cui fatture, ricevute e avvisi di spedizione.
Alcuni componenti dello script scaricheranno il payload principale di XWorm direttamente dal server C2 . Nel corso dell’indagine, Splunk ha individuato file HTA e programmi di preparazione PowerShell che fungevano da fase iniziale e avevano il compito di scaricare il payload della fase successiva.
In che modo XWorm distribuisce i propri payload
Splunk sono stati individuati script VBS e script batch di preparazione che erano stati offuscati per rendere più difficile l’analisi del codice ed eludere il rilevamento.
Questi script decodificano e decriptano due file eseguibili direttamente in memoria: si tratta di una tecnica comune utilizzata per evitare la scrittura su disco ed eludere il rilevamento. Questi file eseguibili fungono da stager e da loader della fase successiva, con il compito di fornire componenti aggiuntivi e, in ultima analisi, di distribuire il payload di XWorm:
- Stager: Aggira l’AMSI (Antimalware Scan Interface) per disabilitare la scansione degli script
- Loader: Manipola l'ETW (Event Tracing for Windows) di Windows per eludere il monitoraggio in fase di esecuzione
Entrambi sono concepiti come meccanismi anti-analisi volti a ridurre la visibilità e a ostacolare l'individuazione.
Lo stager garantisce inoltre la persistenza e aumenta i privilegi creando chiavi di avvio nel Registro di sistema e attività pianificate. Tenta di decomprimere i dati GZIP dalle proprie sezioni di risorse, utilizza il caricamento laterale delle DLL per mascherare il codice dannoso come librerie legittime e inietta shellcode nei processi di destinazione per eseguire i payload in memoria.
Cosa fa il payload di XWorm dopo l’infezione
Il payload finale di XWorm è un file eseguibile decriptato (payload.exe). XWorm utilizza il WMI (Windows Management Instrumentation) per effettuare attività di ricognizione dell’host, compresa l’identificazione delle webcam disponibili. Come altri tipi di malware, XWorm sfrutta le impostazioni di esclusione di Microsoft Defender per impedire che la propria directory venga sottoposta a scansione.
Splunk È stata inoltre individuata una funzione denominata RunDisk() che esegue un componente PowerShell con una politica di esecuzione modificata. Il malware tenta di diffondersi tramite unità rimovibili e include una funzione per l'elaborazione dei comandi backdoor. Analogamente allo stager e ai loader, il malware utilizza le chiavi di esecuzione del Registro di sistema e le attività pianificate per garantire la propria persistenza.
Commenti degli analisti del team Cyber Threat Intelligence di Tanium
XWorm è estremamente adattabile e pone diverse sfide particolari ai difensori.
La sua evoluzione riflette una tendenza più ampia verso una maggiore modularità e capacità di elusione potenziate. Questo, unito all’utilizzo di formati di file a rotazione e di linguaggi di scripting, è destinato probabilmente a migliorare il suo tasso di successo e ad accrescerne l’attrattiva tra gli autori delle minacce.
L'analisi di Splunk sottolinea inoltre l'importanza dei rilevamenti comportamentali per aspetti quali attività sospette nel Registro di sistema, in contrapposizione agli indicatori statici.
Ha qualche informazione in merito a queste storie che desidera condividere? Visiti il sito e il forum di discussione di Tanium per avviare una conversazione.
Per approfondire l’argomento, vi invitiamo a consultare le nostre recenti raccolte di informazioni sulle minacce informatiche .
