Negli ultimi mesi un caso emerso dai laboratori di threat intelligence di Darktrace ha riacceso i riflettori su un problema che spesso viene sottovalutato nelle reti aziendali: il software apparentemente innocuo che, in realtà, apre la porta a malware e abusi di risorse. Protagonista della vicenda è Hola VPN, un servizio molto diffuso che promette navigazione anonima e accesso a contenuti geo-bloccati, ma che nasconde un funzionamento decisamente meno rassicurante di quanto il nome lasci intendere.
Il problema di fondo: una VPN che non è davvero una VPN
La maggior parte delle persone associa una VPN a un tunnel cifrato che instrada il traffico verso un server centralizzato gestito dal provider. Hola funziona in modo diverso: si basa su un’architettura peer-to-peer, in cui ogni utente che installa il servizio mette a disposizione (spesso senza saperlo fino in fondo) la propria connessione come nodo di uscita per il traffico di altri utenti. In pratica, il tuo dispositivo può diventare un proxy per sconosciuti.
Questo cambia radicalmente il profilo di rischio. Non si tratta più solo di una violazione delle policy aziendali sull’uso di software non autorizzato, ma di un meccanismo che può trasformare un endpoint legittimo in un punto di passaggio per traffico malevolo, comunicazioni di comando e controllo (C2) o attività di mining non autorizzato.
Cosa ha osservato Darktrace
Tra febbraio e marzo 2026, gli analisti di Darktrace hanno notato uno schema ricorrente in diversi ambienti clienti, geograficamente distanti tra loro ma con comportamenti di rete sorprendentemente simili. I dispositivi coinvolti comunicavano con domini riconducibili a Hola, utilizzando user agent specifici del servizio, e poco dopo scaricavano file eseguibili da indirizzi IP esterni “rari” — cioè endpoint con cui quei dispositivi non avevano mai interagito prima e che diverse fonti OSINT avevano già segnalato come potenzialmente pericolosi.
Il dettaglio interessante è che questi download non provenivano da un singolo server fisso: gli URL cambiavano nel tempo pur restando all’interno dello stesso dominio, segno di un’infrastruttura di distribuzione rotante, pensata probabilmente per rendere più difficile il blocco statico basato su singoli indicatori.
Questa scoperta si lega a un’inchiesta indipendente pubblicata da Sophos, che aveva già documentato come, in alcuni casi, l’installer di Hola distribuisse un componente eseguibile non dichiarato — un file identificato come me.exe — poi attribuito con buona probabilità a un miner di Monero, introdotto tramite una pipeline di distribuzione compromessa.
Due casi pratici, due esiti diversi
Darktrace racconta nel dettaglio due episodi che, pur seguendo lo stesso copione, hanno avuto sviluppi differenti a seconda di come era configurata la risposta automatica del sistema.
Primo caso (area EMEA). Un dispositivo, osservato per la prima volta a metà gennaio, comincia subito a dialogare con infrastrutture collegate a Hola. Per settimane il traffico mostra un pattern di trasferimento file piuttosto strutturato — richieste ripetute a endpoint con parametri di dimensione crescente — fino a quando, a fine febbraio, il dispositivo scarica un eseguibile da un IP esterno mai visto prima. L’analisi dell’hash del file rivela somiglianze con famiglie di malware note per il furto di credenziali, come Vidar, Rhadamanthys e Stealc. In questo ambiente, però, la risposta autonoma di Darktrace era impostata in modalità “conferma umana”: il sistema ha segnalato l’anomalia, ma è stato necessario un intervento manuale per bloccarla.
Secondo caso (area Americhe). Qui la situazione è leggermente diversa: tre dispositivi nello stesso ambiente avevano già una storia pregressa di connessioni a Hola, ben prima dell’inizio della campagna sospetta. Questo “rumore di fondo” preesistente ha probabilmente reso più difficile distinguere da subito il traffico legittimo da quello malevolo. In questo caso il payload scaricato era diverso: me.exe, lo stesso file identificato come miner di criptovalute nell’inchiesta Sophos. La differenza sostanziale è che qui la risposta automatica era impostata in modalità “completamente autonoma”, e il sistema ha potuto isolare i dispositivi colpiti senza attendere un’approvazione umana, limitando i danni in tempo reale.
Il mining come spia di un compromesso più ampio
Uno degli aspetti più istruttivi del report riguarda l’attività di cryptomining osservata su alcuni dei dispositivi colpiti. Dopo il download di eseguibili come peer.exe, i sistemi hanno iniziato a comunicare con infrastrutture di mining note, utilizzando il protocollo Minergate e credenziali che, in alcuni casi, includevano persino l’identificativo della CPU del dispositivo infetto. Le fasi tipiche di un mining pool — autenticazione, assegnazione del lavoro, invio dei risultati — erano tutte presenti, a conferma che non si trattava di traffico incidentale ma di partecipazione attiva e continuativa a un’operazione di mining distribuita.
Va ricordato che un miner non autorizzato non è “solo” un problema di prestazioni o di bolletta energetica. Nella maggior parte dei casi è un sintomo: la prova che un attaccante ha già ottenuto un punto d’appoggio nel sistema e potrebbe usarlo anche per altro — movimento laterale, persistenza, esfiltrazione di dati.
La lezione da portare a casa
Il filo conduttore di tutta l’analisi è semplice da riassumere ma facile da dimenticare nella pratica quotidiana: il software “di confine” — VPN gratuite, proxy, strumenti P2P — amplia la superficie di attacco in modi che raramente vengono considerati nelle policy IT tradizionali. Un’app che sembra innocua, magari installata da un dipendente per aggirare un blocco geografico su uno streaming, può diventare il canale attraverso cui passano malware e traffico C2, semplicemente perché si confonde con il “rumore” di traffico legittimo che l’app stessa genera.
Alcuni spunti pratici che si possono trarre da questo caso:
- Mappare e bloccare il software P2P/proxy non autorizzato nelle policy di rete, non limitandosi alle classiche VPN aziendali.
- Non fidarsi della reputazione del nome: un prodotto noto e scaricato da milioni di persone non è automaticamente sicuro, soprattutto se il suo modello di business si basa sulla condivisione di banda degli utenti.
- Monitorare le anomalie comportamentali, non solo le firme note: in questo caso, è stato proprio lo scostamento dal normale “pattern of life” dei dispositivi — non una firma di virus — a far scattare l’allarme.
- Valutare l’automazione della risposta: la differenza tra i due casi descritti sopra mostra quanto possa contare, in termini di tempo di contenimento, avere (o non avere) una risposta automatica già pronta ad agire senza attendere un operatore umano.
Il caso Hola VPN è un promemoria utile: nella sicurezza informatica, spesso il rischio più insidioso non è il malware sofisticato scritto da zero, ma l’abuso intelligente di qualcosa che è già dentro il perimetro, con il pieno consenso (anche se inconsapevole) dell’utente.
Informatics, ski racer, loves travels, Finland, Norway, mountains, squash, photography, Drones and RC Helicopter
RSS - Articoli
Commenti recenti