ViPNet usato contro enti russi e due zero-day SonicWall danno accesso root

🛡️ Executive Summary

• HelloNet sfrutta il DLL sideloading nel sistema di aggiornamento ViPNet per iniettare loader, proxy e backdoor dentro processi Windows affidabili.
• UTA0533 concatena due zero-day SonicWall SMA1000 per raggiungere servizi locali, ottenere privilegi root e installare webshell persistenti.
• ViPNet richiede threat hunting mirato; SonicWall impone patch immediate, analisi forense, reimaging e rotazione completa delle credenziali.

Due operazioni avanzate hanno trasformato prodotti destinati alla protezione delle comunicazioni aziendali in punti di ingresso per attacchi ad alto impatto. La campagna HelloNet sfrutta il sistema di aggiornamento di ViPNet per colpire organizzazioni russe nei settori governativo, energetico, industriale, logistico, educativo e dei trasporti. Parallelamente, l’attore UTA0533 ha concatenato le vulnerabilità CVE-2026-15409 e CVE-2026-15410 contro appliance SonicWall SMA1000, raggiungendo servizi interni, privilegi root, webshell e credenziali LDAP. I due incidenti condividono lo stesso elemento critico: l’abuso della fiducia accordata a software e apparati collocati nei punti più sensibili delle reti.

HelloNet sfrutta il sistema di aggiornamento ViPNet

La campagna HelloNet, attiva almeno da maggio 2026, prende di mira installazioni di ViPNet, una famiglia di prodotti russi utilizzata per costruire reti protette, cifrare le comunicazioni e controllare l’accesso alle risorse aziendali. ViPNet Client 4 integra crittografia conforme agli standard GOST, firewall personale, protezione del traffico IP e collegamenti sicuri per ambienti fisici, virtuali e VDI. La presenza di certificazioni rilasciate dalle autorità russe ne ha favorito l’adozione in organizzazioni governative e infrastrutture regolamentate, rendendo il software un bersaglio particolarmente utile per raggiungere reti altrimenti difficili da penetrare. Secondo la ricostruzione tecnica della campagna HelloNet pubblicata da Kaspersky, gli attaccanti hanno collocato una libreria malevola denominata wtsapi32.dll nella directory C:\Program Files (x86)\InfoTeCS\VIPNet Update System. Il processo legittimo itcsrvup64.exe, avviato automaticamente insieme al sistema operativo, cerca e carica la DLL dalla propria directory prima di utilizzare la libreria prevista da Windows. Questa condizione consente il DLL sideloading, tecnica con cui un eseguibile affidabile e firmato viene indotto a eseguire codice estraneo senza che l’attaccante debba sostituire direttamente il programma originale. Lo stesso schema è utilizzato in numerose campagne APT, compresi gli attacchi in cui il DLL sideloading viene nascosto dietro eseguibili Microsoft legittimi, perché riduce l’efficacia dei controlli basati esclusivamente sulla reputazione del processo. In HelloNet, il caricamento avviene a ogni riavvio e trasforma il componente di aggiornamento ViPNet in un meccanismo di persistenza stabile. Kaspersky non ha però dimostrato che l’infrastruttura centrale del produttore sia stata compromessa: le evidenze disponibili mostrano l’abuso locale del processo di aggiornamento sulle macchine infette, non necessariamente una distribuzione malevola proveniente dai server ufficiali di InfoTeCS.

HelloInjector porta il malware dentro svchost.exe

La libreria wtsapi32.dll, classificata come HelloInjector, rappresenta il primo stadio della catena. Dopo l’avvio, il loader cerca un processo svchost.exe associato al gruppo netsvcs e vi inserisce il proprio codice attraverso le funzioni NtWriteVirtualMemory e NtCreateThreadEx. L’iniezione permette al malware di operare dentro un processo di sistema comune, confondendosi con l’attività ordinaria di Windows e beneficiando dei privilegi già disponibili. Una volta completato il trasferimento, HelloInjector esegue in memoria HelloProxy, componente che agisce contemporaneamente come proxy nascosto e caricatore di moduli aggiuntivi. Il malware intercetta funzioni relative alla gestione dei socket mediante la libreria Microsoft Detours e controlla specifiche richieste I/O utilizzate dalle connessioni di rete. Dopo l’inizializzazione resta in ascolto sulle porte 5003 e 5060, distinguendo il traffico di comando attraverso una sequenza di handshake predefinita. HelloProxy può inoltrare comunicazioni verso altri indirizzi oppure ricevere file eseguibili dal server di comando, caricarli direttamente nella memoria del processo e avviarli in thread separati. Tra i moduli recuperati compare HelloExecutor, una backdoor impiegata per eseguire comandi e ricostruire la struttura della rete compromessa. Gli operatori hanno interrogato utenti, gruppi, configurazioni IP, directory ViPNet e sistemi raggiungibili, cercando anche materiali esportati dai componenti di amministrazione. HelloCleaner elimina invece i log generati da ViPNet, riducendo le tracce disponibili per le verifiche successive. Su almeno un sistema è stato individuato anche HelloBackdoor, impianto scritto in Rust che ascolta sulla porta 443, accetta un valore di attivazione specifico e consente di caricare file, scaricare contenuti o eseguire comandi tramite cmd.exe. Gli aggressori hanno inoltre usato una copia rinominata di PuTTY Plink per creare tunnel SSH inversi, collegando l’infrastruttura compromessa ai propri server. Questa concatenazione tra sideloading, process injection, proxy e tunneling mostra una struttura progettata per mantenere l’accesso anche quando un singolo modulo viene rilevato.

Gli indizi cinesi non bastano per attribuire l’attacco

La scelta degli obiettivi indica un’operazione di spionaggio mirata contro grandi organizzazioni russe, ma l’identità degli operatori rimane incerta. Kaspersky ha rilevato nel codice una stringa inutilizzata riferita al portale cinese sina.com e percorsi che mostrano il download di pacchetti Rust dal mirror mirrors.ustc.edu.cn, gestito dall’Università di Scienza e Tecnologia della Cina. Questi elementi suggeriscono un possibile ambiente di sviluppo in lingua cinese, ma non costituiscono una prova definitiva. Le stringhe possono derivare dalle configurazioni del compilatore, da librerie riutilizzate oppure essere state inserite intenzionalmente per confondere l’attribuzione. La campagna viene quindi associata soltanto con bassa confidenza a un gruppo APT sconosciuto di lingua cinese. Sul piano difensivo, gli indicatori più utili restano tecnici: la comparsa di wtsapi32.dll nella directory di aggiornamento ViPNet, librerie prive di firma InfoTeCS, processi anomali avviati da itcsrvup64.exe, iniezioni verso svchost.exe, tunnel creati da copie rinominate di Plink e traffico inatteso sulle porte 5003, 5060 e 443. Il caso rientra in una tendenza più ampia nella quale strumenti di amministrazione, VPN e software certificati vengono sfruttati per oltrepassare il perimetro senza ricorrere a malware immediatamente riconoscibili. Anche le credenziali sottratte a decine di migliaia di appliance Fortinet VPN hanno mostrato quanto gli apparati di accesso remoto possano trasformarsi da dispositivi di protezione in moltiplicatori della compromissione. Le organizzazioni che utilizzano ViPNet devono quindi verificare l’integrità delle directory del prodotto, confrontare firme digitali e hash, monitorare l’attività figlia dei processi InfoTeCS e conservare copie esterne dei log, impedendo a un modulo locale di cancellare l’unica traccia disponibile dell’intrusione.

Due zero-day SonicWall aprono i servizi locali agli attaccanti

Il secondo incidente riguarda le appliance SonicWall Secure Mobile Access 1000, dispositivi collocati sul perimetro per offrire accesso remoto a reti, applicazioni e identità aziendali. La prima vulnerabilità, CVE-2026-15409, ha ottenuto un punteggio CVSS 10.0 ed è classificata ufficialmente come Server-Side Request Forgery. La falla interessa l’interfaccia Workplace e consente a un attaccante remoto non autenticato di indurre l’appliance a inoltrare richieste verso destinazioni che normalmente non sarebbero raggiungibili dall’esterno. Nella catena osservata, richieste costruite verso /wsproxy, accompagnate dallo User-Agent SMA Connect Agent e da un parametro bmID specifico, aprono un tunnel WebSocket verso servizi vincolati all’interfaccia localhost. L’attaccante supera così la separazione tra Internet e i componenti interni dell’appliance, raggiungendo CouchDB e il servizio di controllo. La seconda falla, CVE-2026-15410, ha punteggio CVSS 7.2 ed è descritta da SonicWall come una vulnerabilità di code injection nella Appliance Management Console. L’abuso del workflow remove_hotfix, combinato con un percorso manipolato, permette di iniettare comandi nel servizio privilegiato. UTA0533 ha concatenato le due vulnerabilità: prima ha utilizzato il tunnel SSRF per interagire con servizi locali, poi ha preparato script in /tmp, recuperato il valore /sys/class/dmi/id/product_uuid e derivato la credenziale necessaria a interagire con il control service. Il passaggio finale ha consentito di eseguire comandi come root. Lo schema ricorda altri incidenti nei quali uno zero-day Cisco SD-WAN ha aperto la strada ai privilegi root, ma in questo caso il bersaglio è l’apparato che governa direttamente l’accesso remoto. SonicWall ha confermato lo sfruttamento attivo e ha corretto le vulnerabilità nelle build 12.4.3-03453 e 12.5.0-02835. Le versioni precedenti indicate nell’avviso ufficiale devono essere considerate esposte.

ROOTRUN e ORANGETAIL mantengono il controllo dell’appliance

Dopo aver ottenuto privilegi elevati, UTA0533 ha scritto in /usr/bin/xzfind un binario ELF denominato ROOTRUN, configurato con il bit setuid per consentire l’esecuzione successiva di comandi come root. Gli attaccanti hanno poi distribuito KNUCKLEBALL, uno script Python salvato come deploy_new.py, utilizzato per caricare due archivi JAR nel processo legittimo workplace.startup.CommandStartup. Il primo contiene una versione modificata di Suo5, proxy HTTP open source impiegato per instradare traffico attraverso il sistema compromesso. Il secondo ospita ORANGETAIL, una webshell personalizzata simile a Behinder che usa AES-128-ECB e risposte JSON modificate per gestire i comandi senza ricorrere a protocolli immediatamente riconoscibili. La persistenza viene rafforzata intervenendo sullo script /etc/init.d/workplace e sulla configurazione di NGINX Unit conservata in /var/lib/unit/conf.json.

Le nuove route rendono le webshell raggiungibili attraverso percorsi mimetizzati come /workplace/error.jsp e /workplace/dialogs/errorDialog.jsp, integrandole nella struttura della normale applicazione web. Su una delle appliance, gli operatori hanno inoltre creato script in /var/tmp per eseguire tcpdump e intercettare traffico LDAP non cifrato, ottenendo nomi utente e password utilizzabili per il movimento laterale nella rete interna. L’attività osservata è iniziata il 22 giugno 2026; un riavvio effettuato il 2 luglio ha eliminato alcuni componenti residenti esclusivamente in memoria, ma non gli artefatti persistenti scritti sul filesystem. La correzione software è quindi soltanto il primo passaggio. Nell’avviso sulle vulnerabilità SonicWall e sugli altri prodotti enterprise esposti emerge già la necessità di trattare questi apparati come sistemi potenzialmente compromessi, non come semplici dispositivi da aggiornare. SonicWall raccomanda un’analisi forense completa e, in presenza di indicatori, il reimaging delle appliance fisiche, il redeploy delle istanze virtuali, la rotazione delle password di utenti e amministratori e il reset dei token TOTP. Devono essere controllate le richieste /wsproxy concluse con stato HTTP 101, le operazioni anomale remove_hotfix, le route inattese in conf.json, i file ROOTRUN, gli script Python e le modifiche ai servizi di avvio. In entrambi gli incidenti, il principio operativo è identico: quando viene violato un prodotto che gestisce aggiornamenti, VPN o identità, la patch non garantisce da sola il ripristino della fiducia. L’organizzazione deve presumere che credenziali, configurazioni e canali interni possano essere stati esposti e ricostruire l’ambiente partendo da componenti verificati.