CISA spiega malware su Ivanti EPMM e SystemBC evolve nel C2

di Redazione
0 commenti 6 minuti di lettura

La CISA pubblica un report su malware che prende di mira Ivanti Endpoint Manager Mobile, sfruttando CVE-2025-4427 e CVE-2025-4428 per bypass di autenticazione ed esecuzione di codice remoto, mentre Lumen Black Lotus Labs analizza l’evoluzione di SystemBC come proxy bot SOCKS5 con noise nel C2 e supporto TOR. L’analisi Ivanti documenta due set di malware che iniettano listener malevoli in Apache Tomcat tramite web-install.jar, segmentato e consegnato in Base64 via HTTP GET sul parametro ?format=, con persistenza ottenuta tramite iniezione runtime e class loader offuscati. Dal 15 maggio 2025 gli attori concatenano le falle per ottenere accesso iniziale, elencare directory, raccogliere informazioni di sistema, rubare credenziali LDAP ed eseguire script come heapdump, mentre SystemBC permane nel panorama ransomware come infrastruttura di proxy e C2 a supporto di gruppi associati a campagne di estorsione, confermando un quadro di minacce che combinano MDM breach e crimeware orientato alla rete.

Ivanti EPMM: vulnerabilità e superfici d’attacco

La criticità CVE-2025-4427 abilita authentication bypass su Ivanti EPMM, consentendo l’accesso a risorse protette senza credenziali. La falla CVE-2025-4428 introduce code injection su endpoint applicativi, consentendo la scrittura e l’esecuzione di payload su sistemi che eseguono Apache Tomcat. Le versioni coinvolte includono 11.12.0.4 e precedenti, 12.3.0.1 e precedenti, 12.4.0.1 e precedenti, 12.5.0.0 e precedenti. Ivanti ha divulgato le vulnerabilità il 13 maggio 2025, mentre la CISA ha inserito le CVE nel Known Exploited Vulnerabilities Catalog il 19 maggio 2025. Gli avversari concatenano i bug per ottenere accesso iniziale, operare su /mifs/rs/api/v2/, enumerare la root directory, mappare la rete interna, scaricare file malevoli ed eseguire comandi remoti sulle interfacce esposte.

Catena di compromissione e consegna dei loader

La consegna dei loader avviene in segmenti Base64 spediti in sequenza tramite HTTP GET che sfrutta Expression Language sul parametro ?format=. La logica prevede l’append progressivo in /tmp/web-install.jar, fino a ricomporre l’archivio completo. Un esempio sintetizza l’uso di EL per aprire un FileOutputStream, decodificare il Base64 e scrivere i chunk sul file JAR in modalità append, replicando la dinamica “write-and-append” fino al completamento. Questa metodologia evita trasferimenti voluminosi in un’unica richiesta, frammenta il payload e riduce segnali anomali evidenti, favorendo stealth e evasione in ambienti di monitoraggio orientati ai pattern.

Set uno: ReflectUtil.class e SecurityHandlerWanListener

image 321
CISA spiega malware su Ivanti EPMM e SystemBC evolve nel C2 10

Il set uno utilizza web-install.jar come Loader 1, includendo ReflectUtil.class mascherato in org.apache.http. Il loader istanzia dinamicamente classi malevole, aggira restrizioni dei moduli JDK e scansiona oggetti e contesti a runtime. La classe ReflectUtil.class inietta in Apache Tomcat un listener denominato SecurityHandlerWanListener, caricato con getClassName su org.junit.SecurityHandlerWanListener. Se la classe non risulta presente, il codice provvede a decodifica Base64 e decompressione gzip della definizione incorporata, assicurando la disponibilità del componente. SecurityHandlerWanListener.class intercetta HTTP request con pattern specifici, decifra i payload e li inoltra a classi dinamiche in grado di eseguire comandi arbitrari. Le operazioni di decodifica impiegano AES con chiave 7c6a8867d728c3bb; l’output dei comandi può essere incapsulato e reinviato attraverso le stesse richieste, mantenendo il canale C2 all’interno del traffico applicativo. La persistenza deriva dall’iniezione runtime nel container Tomcat, senza toccare la configurazione persistente, riducendo artefatti su disco.

Set due: WebAndroidAppInstaller.class e intercettazione form-urlencoded

Screenshot 2025 09 19 180021
CISA spiega malware su Ivanti EPMM e SystemBC evolve nel C2 11

Il set due adotta web-install.jar come Loader 2 e introduce WebAndroidAppInstaller.class sotto com.mobileiron.service. Questo componente intercetta richieste HTTP con Content-Type application/x-www-form-urlencoded, recupera parametri come password, li decifra con AES e chiave 3c6e0b8a9c15224a, quindi genera e carica una nuova classe malevola capace di eseguire codice arbitrario. L’output viene crittografato, Base64-encodato e inserito nella response, chiudendo il ciclo C2 sulla stessa superficie HTTP. Come nel set uno, la persistenza si regge sull’iniezione nel runtime Tomcat, minimizzando modifiche visibili e privilegiando la furtività all’installazione tradizionale di webshell su file system.

Indicatori di compromissione e riferimenti operativi

La CISA pubblica indicatori di compromissione in MAR-251126.r1.v1.CLEAR_stix2.json, includendo SHA256 relativi a loader e classi. Gli endpoint sfruttati comprendono /mifs/rs/api/v2/featureusage?format=, coerentemente con la tecnica EL injection e append su /tmp/web-install.jar. Gli indicatori abbracciano inoltre stringhe e sequenze di byte che agevolano hunting e triage forense su artefatti JAR e classi Java tipiche dei due set.

Regole YARA per i due set di loader e classi

La CISA accompagna il report con regole YARA mirate. La regola CISA_251126_01 copre Loader 1 con stringhe relative a org/apache/http/client e percorsi come /wo/ReflectUtil.class, includendo byte sequence caratteristici. La CISA_251126_02 si focalizza su ReflectUtil.class, evidenziando riferimenti a client/wo/ReflectUtil e alla classe SecurityHandlerWanListener con metodi come getListener e addListener. La CISA_251126_03 riguarda SecurityHandlerWanListener.class, con stringhe su ServletRequestListener, ClassLoader, la chiave 7c6a8867d728c3bb, il token pass e un riferimento https://www.live.com/ tipico dell’implementazione osservata. La CISA_251126_04 intercetta Loader 2 come Tomcat listener shell, con indicatori su com/mobileiron/service/ e /wo/WebAndroidAppInstaller.class. Infine, CISA_251126_05 punta WebAndroidAppInstaller.class con segnali come 3c6e0b8a9c15224a, pass e pattern di caricamento dinamico.

Regole SIGMA e attività di hunting sui log

La componente SIGMA include CMA_SIGMA_MAR_251126_Ivanti_EPMM_CVE_2025_4427_TLP_CLEAR.yaml, orientata a log di rete e applicativi. La regola rileva HTTP GET con ?format= e pattern compatibili con EL injection usati per l’append a /tmp/web-install.jar, compresi chunk Base64-encoded. Il focus ricade su /mifs/rs/api/v2/ e su parametri che indicano modalità true per l’append, fornendo segnali di hunting per SIEM e pipeline di detection già in esercizio.

SystemBC: proxy bot SOCKS5, noise e TOR nel C2

L’analisi di Lumen Black Lotus Labs osserva SystemBC come proxy bot a SOCKS5 che trasforma host infetti in relay di comunicazioni C2. La piattaforma adotta un protocollo custom con noise per confondere il profilo del traffico, integra supporto TOR per anonimato e si ancora a pipeline ransomware dove facilita movimento laterale e tunneling. SystemBC persiste nel 2025 come componente multipurpose all’interno di catene di intrusione, con implementazioni in linguaggio C e capacità di esecuzione comandi, raccolta credenziali e session management lato server C2. La documentazione evidenzia beacon periodici, tasking per funzioni di proxy e crittografia delle comunicazioni, delineando un ecosistema di crimeware che mantiene infrastrutture diffuse e riutilizzabili.

Dinamiche C2 e distribuzione di SystemBC

image 322
CISA spiega malware su Ivanti EPMM e SystemBC evolve nel C2 12

Il C2 di SystemBC gestisce comandi, instradamento sessioni e delivery di componenti, operando con rumore sintetico per mascherare scambi e ridurre la rilevabilità su firewall e IDS. Le sessioni multiple vengono orchestrate con scambio di chiavi e canali crittografati, mentre la distribuzione nel dark web e l’impiego in catene ransomware consolidano il ruolo del proxy bot come infrastruttura di servizio. La presenza in campagne associate a gruppi come DarkSide e Conti si inserisce nel quadro delle estorsioni supportate da infrastrutture modulari, in cui SystemBC fornisce offuscamento, persistenza di rete e tunneling applicativo.

Implicazioni tecniche e continuità delle campagne

image 323
CISA spiega malware su Ivanti EPMM e SystemBC evolve nel C2 13

L’insieme delle evidenze mostra come MDM esposti con Ivanti EPMM siano sfruttati per accesso iniziale e comando remoto attraverso listener nascosti nel runtime di Tomcat, mentre SystemBC fornisce infrastruttura di rete per proxy e C2 nelle catene ransomware. La combinazione di frammentazione Base64, caricamento dinamico di classi, decifre AES con chiavi note e intercettazione di parametri form-urlencoded consolida una superficie d’attacco silenziosa, con hunting supportato da YARA e SIGMA pubblicate. Dal 15 maggio 2025 si osserva un pattern coerente di intrusioni con raccolta informazioni, download di file malevoli, heapdump e furto di credenziali LDAP, in linea con operazioni mirate a stabilizzare C2 interni e a preparare fasi successive di abuso.

Articoli correlati