Sintesi

Questo CSIRT ha recentemente osservato attività malevole volte a sfruttare vulnerabilità note presenti in istanze datate e non adeguatamente aggiornate dei middleware JBoss e WildFly, con l’obiettivo di distribuire payload malevoli, quali Cobalt Strike e Mimikatz.

Descrizione e potenziali impatti

Questo CSIRT ha recentemente osservato attività malevole finalizzate a sfruttare vulnerabilità note presenti in istanze esposte e non adeguatamente aggiornate dei prodotti JBoss e WildFly, appartenenti a versioni da tempo fuori supporto. Tali middleware applicativi, ampiamente impiegati per l’esecuzione e la gestione di applicazioni Java Enterprise su larga scala, svolgono un ruolo centrale nell’erogazione di servizi web e backend aziendali, risultando pertanto obiettivi di particolare interesse per eventuali attori malevoli.

Lo scenario analizzato

Nel contesto dell’analisi condotta sono state individuate due istanze distinte, entrambe risalenti al 2009: la prima, relativa a JBoss 5.x, versione obsoleta e priva delle necessarie patch di sicurezza, configurata con il profilo “server\default”; la seconda, relativa a WildFly, anch’essa datata e non adeguatamente aggiornata.

Entrambe le istanze sono risultate esposte su rete pubblica prive di meccanismi di sicurezza efficaci.

Il vettore di accesso iniziale

Dall’analisi dei log raccolti si evidenziano numerose richieste HTTP GET e POST indirizzate al percorso:

/invoker/JMXInvokerServlet

noto endpoint che permette la gestione e il deployment remoto attraverso Java Management Extension (JMX) . In assenza di adeguate misure di protezione, tale interfaccia può rappresentare un efficace vettore d’ingresso per attacchi, consentendo ad un attore malevolo l’esecuzione di comandi arbitrari e il caricamento non autorizzato di applicazioni.

Tali richieste sono risultate riconducibili a tentativi di sfruttamento automatico della console JMX, che evidenziano i tipici pattern impiegati dal tool JexBoss , comunemente utilizzato per automatizzare l’individuazione e lo sfruttamento di vulnerabilità JMX ai fini del caricamento ed esecuzione di payload malevoli.

In questo caso l’attaccante, che ha inizialmente preso di mira l’istanza JBoss 5.x, è riuscito ad effettuare l’upload di un archivio WAR (Web Application Archive) opportunamente predisposto denominato:

\jboss-5.x\server\default\deploy\jexws4.war

Successivamente, è stata sfruttata la presenza di WildFly attraverso la componente nativa HDScanner , che consente l’ hot deployment, come evidenziato di seguito.

WILDFLY INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) deploy, ctxPath=/gsl

Tale funzionalità permette l’installazione automatica di nuove applicazioni, tramite il monitoraggio costante di apposite directory, gestendo in tempo reale l’aggiunta, la modifica o la rimozione di file WAR, EAR o JAR e senza richiedere il riavvio del server.

Dettaglio delle vulnerabilità note sfruttate

Sulla base delle evidenze raccolte, è altamente probabile che JexBoss abbia permesso lo sfruttamento delle vulnerabilità note elencate di seguito:

• CVE-2010-0738 (Improper Access Control) : interessa la console JMX esposta in JBoss Application Server (fino alla versione 5.1.x): questa interfaccia di gestione consente l’esecuzione di operazioni amministrative senza adeguati controlli di accesso, permettendo a un attaccante remoto l’interazione con il sistema in modo non autorizzato, fino a comportare l’esecuzione di codice arbitrario o la modifica di configurazioni critiche. Il problema risiede in una protezione inadeguata delle interfacce di management, che in ambienti di produzione dovrebbero essere disabilitate o opportunamente protette tramite autenticazione e segmentazione di rete.
• CVE-2011-4085 (Improper Access Control) : questa vulnerabilità rappresenta una regressione della precedente: nonostante l’eventuale applicazione delle patch per la CVE-2010-0738, alcune interfacce di gestione permangono accessibili e prive di meccanismi per il controllo degli accessi efficaci. Ciò permette di sfruttare tale esposizione per ottenere accesso non autorizzato a funzionalità amministrative, compromettendo la sicurezza del sistema.
• CVE-2015-7501 (Deserialization of Untrusted Data): interessa ambienti Java che impiegano la libreria Apache Commons Collections, inclusi quelli basati su JBoss. Il sistema accetta oggetti serializzati senza verificarne la provenienza o l’affidabilità, permettendo a un attaccante di inviare payload opportunamente predisposti che vengono successivamente deserializzati ed eseguiti. Tale comportamento può condurre all’esecuzione arbitraria di codice lato server, compromettendo l’intero ambiente. Il problema risiede nella mancanza di adeguati controlli di validazione durante il processo di deserializzazione degli oggetti.
• CVE-2017-12149 (Remote Code Execution via Deserialization): interessa la componente JMXInvokerServlet presente in JBoss Application Server (fino alla 5.1.x e in versioni successive di EAP/WildFly). La servlet espone un endpoint che consente di invocare operazioni JMX (Java Management Extensions) senza alcuna autenticazione o controllo degli accessi. Un attaccante remoto potrebbe sfruttare tale endpoint inviando richieste opportunamente predisposte al fine di eseguire codice Java arbitrario lato server. La vulnerabilità deriva da una errata esposizione delle interfacce di gestione JMX, che in ambienti di produzione dovrebbero essere adeguatamente protette o disabilitate.

La webshell

Dalle analisi è emerso che il pacchetto WAR precedentemente menzionato ha installato una JavaServer Page (JSP), ovvero una pagina web dinamica lato server sviluppata in Java, utilizzata per generare contenuti HTML in risposta alle richieste dell’utente.

Dall’analisi del codice è emerso la JSP è una webshell sofisticata non offuscata, nello specifico riconducibile alla famiglia GodZilla, di origine cinese.

GodZilla è in grado di istanziare ed eseguire a runtime plugin modulari Java, caricando dinamicamente il codice direttamente in memoria tramite un “ClassLoader” personalizzato. Le comunicazioni sono cifrate end-to-end tramite AES – la cui chiave è incorporata all’interno del codice – e codificati in Base64 ; una volta ricevuti i dati dall’attaccante, questi vengono decodificati, decifrati e passati al ClassLoader, senza la necessità di scrivere alcun file su disco. Alla prima richiesta, il codice viene salvato nella sessione, mentre alle successive viene istanziato ed eseguito utilizzando gli oggetti di contesto JSP.

Si evidenzia come la webshell sfrutti in modo particolare la ridefinizione di metodi standard per il caricamento dei parametri e l’esecuzione del codice Java istanziato. Come illustrato in Figura 1, il metodo equals permette il passaggio di parametri all’oggetto da eseguire, mentre il metodo toString effettua l’esecuzione del codice malevolo contenuto nella richiesta. Questo approccio permette di mascherare l’esecuzione del payload attraverso chiamate a metodi apparentemente legittimi, rendendo più difficile l’individuazione da parte di eventuali meccanismi di sicurezza o analisi statiche.

La risposta del server è anch’essa cifrata e codificata in Base64. Per garantirne l’autenticità e l’integrità, il messaggio viene “incapsulato” tra due metà di una stringa MD5 – calcolata combinando un parametro costante con la chiave AES. In pratica, la prima metà dell’hash MD5 viene scritta all’inizio della risposta, seguita dal messaggio cifrato e codificato, e infine dalla seconda metà dell’hash. Questa modalità di incapsulamento funge da marcatore statico, permettendo al client di riconoscere le risposte provenienti dal server compromesso e di distinguerle da eventuali dati non previsti, senza però garantire l’integrità dei contenuti.

Nel caso in esame è stato rilevato il file beacon.exe nella directory

\jboss-5.1.0.GA\server\default\deploy\ROOT.war\

tale evidenza sottolinea che l’obiettivo principale della webshell consiste nel caricamento iniziale del framework di attacco. Tuttavia, la Godzilla rimane uno strumento di persistenza silente, che consente agli attaccanti di mantenere un accesso nascosto sull’ambiente compromesso.

Beacon Cobalt Strike

Come anticipato, al beacon Cobalt Strike è demandata la gestione delle fasi successive dell’attacco.

Cobalt Strike è una nota suite professionale per Red Teaming che fornisce funzionalità avanzate di Command & Control e post-exploitation. Proprio per la sua completezza e facilità d’uso, è frequentemente utilizzata da gruppi APT e cybercriminali.

Tra le principali peculiarità dell’istanza analizzata (Figura 2), si evidenziano:

• Comunicazione HTTP cifrata e mimetizzata: stabilisce connessioni periodiche verso il server C2 su HTTP (porta 4477), mascherando i metadati all’interno di header HTTP standard (Cookie e User-Agent). Non risultano configurati canali alternativi come HTTPS, DNS o SMB.
• Persistenza della comunicazione: mantiene sessioni attive con il server C2 attraverso check-in regolari ogni 60 secondi, senza jitter, consentendo il costante controllo remoto del sistema compromesso.
• Injection aggressiva in memoria: è configurato per allocare memoria con permessi RWX e iniettare il codice in processi di sistema legittimi (ad esempio rundll32.exe), sfruttando metodi come CreateThread e CreateRemoteThread, per eludere controlli antivirus o EDR.
• Flusso di dati cifrato: i payload scambiati con il server C2 sono cifrati a livello applicativo e incapsulati tra segmenti di hash MD5, rendendo il contenuto delle comunicazioni non interpretabile a un’analisi diretta del traffico e aumentando la difficoltà di intercettazione o ispezione.
• Movimenti laterali : sfrutta le credenziali raccolte (tramite Mimikatz) per accedere ad altri sistemi nella rete. Mediante l’esecuzione remota di comandi e tecniche di propagazione, il beacon consente movimenti laterali mirati, con un’attenzione particolare ai server Active Directory, che costituiscono un obiettivo strategico per il controllo dell’intera infrastruttura.

Mimikatz

L’analisi dei log dell’XDR evidenzia attività avanzate di post‑exploitation riconducibili a Mimikatz, orchestrate tramite il beacon di Cobalt Strike. Tra gli eventi registrati si segnalano dumping delle credenziali di sistema, comportamenti tipici di process injection e l’esecuzione di binari di sistema utilizzati come proxy per mascherare le azioni malevole intraprese. In particolare, la presenza di riferimenti espliciti di “Credential Dumping via Mimikatz” confermano che l’attaccante è riuscito ad estrarre credenziali dalla memoria di sistema, facilitando movimenti laterali e l’espansione del proprio controllo sulla rete. Tali evidenze dimostrano la capacità del beacon di raccogliere credenziali e utilizzarle per compromettere ulteriori host, ponendo particolare attenzione a quelli strategici, come i server Active Directory.

Criticità e superficie di esposizione

Il caso trattato sottolinea, ancora una volta, quanto sia rischioso esporre servizi applicativi su Internet senza garantire un’adeguata protezione tramite misure di sicurezza e aggiornamenti costanti. Sistemi accessibili pubblicamente, ove non correttamente configurati o mantenuti, costituiscono infatti un vettore privilegiato per gli attaccanti, che possono sfruttare vulnerabilità note, configurazioni errate o di default per ottenere un punto di accesso nella rete dell’organizzazione.

Questi scenari sono stati ampiamente trattato nell’ambito del bollettino BL01/250626/CSIRT-ITA , che rimarca come la presenza di tali scenari incrementino la superficie di esposizione e il rischio di compromissione.

Con riferimento al caso in esame, è possibile evidenziare che ancora oggi, in Italia (Figura 3), vi è un elevata esposizione di middleware Jboss 5.x e WildFly vulnerabili e ormai fuori supporto

Se si confrontano questi risultati con quanto osservabile nel resto d’Europa (Figura 4) emerge chiaramente come il fenomeno sia tuttora ampiamente diffuso e rappresenti una minaccia concreta per la sicurezza delle infrastrutture IT.

Questo scenario rimarca l’urgenza di adottare interventi mirati, volti a ridurre la superficie d’attacco e a implementare controlli di sicurezza efficaci — di quali una lista non esaustiva è riportata nel paragrafo “Azioni di mitigazione” — indispensabili per limitare le possibilità di compromissione e limitare il rischio complessivo per l’organizzazione.

Azioni di mitigazione

Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi attivando le seguenti misure preventive:

• applicare regolarmente patch di sicurezza a sistemi operativi, applicazioni e middleware, riducendo la superficie di attacco sfruttabile da vulnerabilità note;
• valutare la sostituzione di prodotti giunti a fine ciclo di vita (EOL), che non riceveranno ulteriori aggiornamenti dal vendor, con soluzioni moderne e supportate;
• esporre all’esterno solo i servizi strettamente necessari, limitando l’accesso tramite firewall e VPN;
• implementare la segmentazione della rete e VLAN dedicate al fine di isolare eventuali sistemi critici;
• rimuovere dalle configurazioni componenti e moduli non necessari;
• disabilitare funzionalità predefinite non utilizzate e applicare configurazioni sicure consigliate dai vendor;
• utilizzare meccanismi di autenticazione forte (multi-factor authentication);
• implementare una gestione rigorosa delle credenziali e ruotare periodicamente le password;
• abilitare logging e audit dettagliati per individuare attività sospette;
• integrare sistemi EDR/XDR e SIEM per rilevare indicatori di compromissione (IoC) o tecniche di attacco (es. process injection, credential dumping);
• mantenere copie di backup offline e testare regolarmente i piani di ripristino;
• definire procedure di incident response aggiornate al fine di reagire prontamente a eventuali compromissioni.

Azioni di risposta agli incidenti

Qualora si riscontrino evidenze di avvenuta compromissione sui propri sistemi, si raccomanda agli utenti e alle organizzazioni di attuare le seguenti azioni:

• collezionare eventuali evidenze, quali processi/servizi in esecuzione su dispositivi target, log di rete e log di autenticazione considerati non convenzionali;
• porre in isolamento e/o offline gli host potenzialmente interessati dalla compromissione;
• ripristinare gli host compromessi ad un’immagine precedente consistente (dopo aver espletato le necessarie attività forensi);
• resettare gli account degli utenti interessati dalla compromissione;
• segnalare tempestivamente a questo CSIRT, tramite il portale https://segnalazioni.acn.gov.it/ l’evento occorso.