Comando e controllo su un broker MQTT pubblico: le backdoor Toy Ghouls e il punto cieco delle reti industriali

Due impianti Windows analizzati da Kaspersky non usano infrastruttura propria per il comando e controllo: uno si appoggia al broker MQTT pubblico di HiveMQ, l’altro al protocollo Matrix. Le vittime documentate sono russe e non si tratta di un attacco a sistemi industriali, ma la tecnica solleva un problema di rilevamento che riguarda direttamente chi gestisce reti OT.

Due backdoor, nessuna infrastruttura propria

Il 4 settembre 2026 Kaspersky ha pubblicato su Securelist l’analisi di due backdoor che i suoi ricercatori attribuiscono al gruppo a movente finanziario noto come Toy Ghouls, indicato anche con i nomi Bearlyfy, Laboo.boo e Feral Wolf. L’attribuzione è dei team GERT e Security Services di Kaspersky e va riportata come tale.

Il gruppo è attivo dal 2025 contro organizzazioni russe. Ha iniziato appoggiandosi a strumenti disponibili pubblicamente e a builder di ransomware trapelati, quelli di Babuk e LockBit, per poi sviluppare codice proprio, tra cui il ransomware GenieLocker, in versioni per Windows, Linux ed ESXi.

I due impianti individuati all’inizio di luglio 2026 si chiamano mqtt-bird-agent 0.1.0 e matrix-bird-agent 0.1.0, e corrispondono a due eseguibili Windows, cplsupport.exe e wtass.exe . Il tratto che li rende interessanti è che nessuno dei due porta con sé un server di comando e controllo: entrambi si appoggiano a servizi e protocolli legittimi.

Un secondo elemento merita attenzione, e riguarda il modo in cui arrivano sulla macchina. La distribuzione avviene attraverso Windows Remote Management, con utilità di post-sfruttamento open source come Evil-WinRM e WinRM-fs. Il report non descrive il vettore di accesso iniziale, ma la scelta di WinRM implica che gli operatori dispongono già di credenziali amministrative quando installano l’impianto: la backdoor non è il punto di ingresso, è ciò che rende l’accesso persistente.

La persistenza si ottiene registrandosi come servizio Windows, con i nomi “cplsupport” (descritto come “Problem Reports Control Panel”) e “wtas” (“Windows Telemetry Aggregator Service”), tramite argomenti di installazione e disinstallazione. In entrambe le varianti i campi sensibili della configurazione vengono cifrati al primo avvio con ChaCha20-Poly1305, con una chiave derivata dal valore MachineGuid del registro di sistema: un accorgimento che impedisce di riutilizzare la configurazione su un’altra macchina e complica il lavoro di chi analizza il campione fuori dall’ambiente di origine. La variante MQTT conserva il file cifrato su disco; la variante Matrix lo cancella dopo il primo avvio e sposta i parametri in una chiave di registro dedicata.

Perché un broker MQTT pubblico è un canale quasi ideale

Secondo Kaspersky, la variante mqtt-bird-agent comunica con broker.hivemq.com sulla porta 8883, quella standard di MQTT su TLS. Il dominio è quello del broker pubblico di HiveMQ, uno dei più noti tra quelli messi a disposizione gratuitamente per test e prototipazione: non è un server compromesso né un dominio registrato dagli attaccanti. Il report descrive quattro percorsi di scambio: uno per lo stato del sistema infetto, uno per le metriche periodiche (CPU, memoria, disco, carico, tempo di attività), uno da cui la backdoor legge i comandi e uno su cui restituisce i risultati. I comandi vengono eseguiti tramite PowerShell in modalità nascosta.

Un’annotazione di precisione: nello stesso passaggio Securelist parla di un “cluster” creato dagli attaccanti e di un piano gratuito con limiti di 100 connessioni concorrenti e 10 GB di traffico mensili. Sono esattamente le caratteristiche del piano Serverless gratuito di HiveMQ Cloud, che prevede credenziali di accesso e TLS, non quelle del broker demo aperto, che non ha né cluster né piani. Il report non scioglie l’ambiguità. La conseguenza pratica è che non si può dare per certo che il canale fosse privo di autenticazione, e che l’indirizzo effettivamente contattato potrebbe essere un sottodominio dedicato del servizio cloud piuttosto che il nome generico del broker pubblico: in entrambi i casi, comunque, la destinazione appartiene a un fornitore legittimo e ampiamente usato.

Vale la pena spiegare perché questa scelta sia efficace, al di là della gratuità.

MQTT è un protocollo publish and subscribe: il client non riceve connessioni in ingresso, si limita a stabilire una connessione uscente verso il broker e ad attendere. Non serve alcuna porta aperta sul perimetro, e il traffico ha la forma di una sessione TLS lunga verso un servizio cloud, esattamente come mille integrazioni legittime. I messaggi sono minuscoli, perché il protocollo nasce per la telemetria su reti a banda ridotta, quindi il volume non fa scattare soglie. E poiché il broker è condiviso da chiunque lo usi per test, l’indirizzo di destinazione non è un indicatore di compromissione: bloccarlo a livello di reputazione significa bloccare un servizio legittimo.

C’è però un motivo ulteriore, ed è quello che riguarda direttamente il nostro perimetro editoriale. MQTT è lo standard di fatto della telemetria industriale e dell’Internet of Things. In una rete di stabilimento, in un impianto di trattamento acque, in una flotta di dispositivi connessi, il traffico MQTT in uscita non è un’anomalia: è il funzionamento normale. Un canale di comando e controllo che parla MQTT, in quel contesto, non si nasconde tra il rumore, coincide con il rumore.

Il caso Matrix, e la differenza che quasi nessuno sta facendo

La seconda variante usa il protocollo Matrix. L’agente invia messaggi di stato e metriche con tipi di evento personalizzati, riceve comandi preceduti dal prefisso cmd: da un account chiamato “panel-bot” e li esegue attraverso la riga di comando di Windows, non PowerShell. Accetta inoltre un’istruzione di configurazione che regola l’intervallo di invio delle metriche, in una finestra che va da cinque secondi a un’ora; il valore viene salvato nel registro. Le risposte tornano come eventi di un tipo dedicato.

Qui però la somiglianza con il caso MQTT si ferma, e conviene dirlo chiaramente perché diverse riprese della notizia stanno appiattendo le due cose. Il server Matrix utilizzato è sotto il controllo degli attaccanti, raggiungibile a un dominio che richiama il nome del client Element. Non c’è quindi abuso di un servizio di terzi: c’è l’uso di un protocollo legittimo e federato su infrastruttura propria. È mimetismo di protocollo, non parassitismo di servizio.

La distinzione conta per chi deve difendersi. Nel caso MQTT il dominio di destinazione è inutilizzabile come indicatore, perché legittimo; nel caso Matrix il dominio è un indicatore valido e bloccabile, ed è l’analisi comportamentale a essere più difficile, perché il traffico Matrix cifrato è opaco per definizione.

Un’osservazione di prospettiva, che è nostra e non del report. Matrix sta guadagnando terreno nelle amministrazioni pubbliche europee proprio come alternativa sovrana alle piattaforme di messaggistica statunitensi, e il tema della sovranità digitale ne sta accelerando l’adozione. Nelle organizzazioni che lo hanno introdotto, il traffico Matrix passerà presto dall’essere un’anomalia all’essere ordinario. Vale per Matrix ciò che vale già oggi per MQTT negli impianti industriali: la protezione offerta dall’anomalia statistica ha una scadenza, e coincide con il momento in cui la tecnologia diventa diffusa.

Che cosa questo caso non dice

Poiché l’angolo più interessante riguarda le reti industriali, è necessario essere precisi su ciò che il report documenta e su ciò che non documenta, altrimenti l’analisi si trasforma in allarmismo.

Non si tratta di un attacco a sistemi di controllo industriale. Gli impianti girano su Windows, vengono installati come servizi dopo che gli attaccanti hanno già ottenuto privilegi amministrativi, ed eseguono comandi tramite PowerShell o riga di comando: è una backdoor IT, non un malware progettato per interagire con logiche di processo. Le vittime documentate sono organizzazioni russe, e il report non individua settori specifici né fornisce un numero di vittime.

Il motivo di interesse non è quindi ciò che è accaduto, è ciò che la tecnica rende possibile. Un canale di comando e controllo su MQTT esiste ora, è documentato e funziona. Il giorno in cui un impianto simile venisse installato su un sistema di una rete dove MQTT è traffico normale, la difficoltà di rilevamento non sarebbe teorica. È un’osservazione prospettica, e come tale va presa: nessuna delle fonti disponibili afferma che ciò sia già avvenuto.

Detection: dove guardare davvero

Il primo punto è il più controintuitivo, e riguarda la priorità. Poiché la distribuzione avviene via WinRM con strumenti noti, il momento in cui questa catena è più visibile non è quello del comando e controllo, è quello che lo precede. Sul lato Windows i segnali sono ordinari e già disponibili: la registrazione di un nuovo servizio (evento 7045 nel registro System), l’attività nel canale Microsoft-Windows-WinRM/Operational su macchine che non dovrebbero ricevere sessioni remote, connessioni in ingresso sulle porte 5985 e 5986 da postazioni che non appartengono al team di amministrazione, e la scrittura nelle directory cplsupport e SynapseAgent sotto ProgramData. Chi ha un buon rilevamento sulle attività amministrative anomale intercetta la catena prima che il canale MQTT entri in funzione, e per la maggior parte delle organizzazioni questo è l’investimento con il ritorno migliore.

Sul canale, le indicazioni utili sono di natura diversa da quelle a cui si è abituati, e vanno lette con la mappa dell’impianto davanti.

In un’architettura industriale ordinata, i client MQTT stanno in posti prevedibili: gateway e dispositivi edge al livello 2 del modello Purdue, sistemi di raccolta dati e historian al livello 3, un broker in zona demilitarizzata industriale che fa da unico punto di contatto verso l’IT e il cloud. Una connessione MQTT in uscita da una postazione Windows di livello 3 o 4, e a maggior ragione da un server di dominio o da una workstation di ufficio, non ha una funzione operativa che la giustifichi. Il primo strumento non è quindi un sensore di rete: è l’inventario dei client autorizzati, per zona, con l’indicazione del broker a cui ciascuno deve parlare. È lo stesso principio di zone e conduit di IEC 62443-3-2 applicato a un protocollo che spesso resta fuori dal disegno perché considerato “solo telemetria”.

Il secondo strumento sono i topic. Negli impianti che adottano la specifica Sparkplug B, la struttura è fissa: spBv1.0/<gruppo>/<tipo di messaggio>/<nodo>/<dispositivo> , con un vocabolario chiuso di tipi (NBIRTH, DDATA, NDEATH e pochi altri) e payload binario Protobuf. Anche dove Sparkplug non è in uso, quasi tutti gli impianti hanno una convenzione di denominazione per sito, linea e macchina. Un topic che non appartiene a nessuna di queste gerarchie, con un identificativo opaco al primo livello e percorsi come status , metrics , cmd/req e cmd/res , è riconoscibile a colpo d’occhio da chi conosce la convenzione, molto più di quanto lo sia dal volume o dalla frequenza.

Qui però va detto un limite che il report non discute. Sulla porta 8883 il traffico è cifrato in TLS, e i topic non sono visibili a chi ascolta passivamente sulla rete. Le piattaforme di monitoraggio OT che analizzano il traffico da una porta SPAN riconoscono MQTT in chiaro sulla 1883 e ne estraggono i topic; su TLS vedono l’handshake, il nome del server nell’estensione SNI, il certificato e il ritmo delle sessioni, nient’altro. La visibilità sui topic si recupera in due modi soltanto: sul broker, se è interno e registra le connessioni e le sottoscrizioni, oppure sull’host, con la telemetria di processo che mostra quale eseguibile ha aperto la connessione. Nel caso in esame, un servizio registrato come “Problem Reports Control Panel” che apre una sessione TLS persistente verso un broker MQTT è un’anomalia leggibile sull’endpoint anche senza vedere un solo byte del contenuto.

Resta il ritmo, che è osservabile anche in TLS. Un sensore industriale pubblica su evento o per eccezione, con cadenze legate al processo; un impianto di comando e controllo invia metriche a intervallo fisso e interroga il canale con regolarità. Sulla durata di ore o giorni, la differenza è misurabile.

Sul piano architetturale la misura che chiude il problema alla radice è nota e poco applicata: i dispositivi di una rete industriale dovrebbero parlare con un broker interno, con autenticazione mutua tramite certificati, e la zona OT non dovrebbe avere alcuna via verso broker pubblici su internet. L’eccezione tipica, e pericolosa, è la manutenzione remota dei fornitori di macchine, che spesso passa proprio da broker cloud del costruttore: va censita e incanalata attraverso la zona demilitarizzata, non tollerata come traffico di fondo. È lo stesso ragionamento di segmentazione tra IT e OT che si applica agli altri protocolli di campo. Il caso polacco della APN privata che nessuno sorvegliava ha mostrato poche settimane fa che cosa succede quando un canale considerato tecnico e innocuo resta fuori dal perimetro di monitoraggio.

Restano infine gli indicatori pubblicati nel report: le hash dei due eseguibili, le chiavi di registro sotto HKLM\Software\synapse e HKLM\Software\SynapseAgent , e la richiesta verso un servizio pubblico di geolocalizzazione degli indirizzi IP che entrambe le varianti effettuano all’avvio. Quest’ultima, per un sistema che non ha alcuna ragione di sapere in quale Paese si trova, è un segnale semplice e sorprendentemente efficace.

Dove sta andando il cybercrime

Il dato di fondo di questa vicenda va oltre i due campioni analizzati. Un gruppo criminale che rinuncia a infrastruttura propria in favore di servizi e protocolli legittimi ottiene tre vantaggi in una volta sola: costi di gestione quasi nulli, resistenza ai takedown, perché non c’è un server da sequestrare, e una superficie di attribuzione molto più povera, perché non ci sono registrazioni di dominio, hosting o pagamenti da seguire a ritroso.

È la stessa direzione che si osserva nell’abuso di piattaforme cloud, di servizi di collaboration e di repository pubblici come canali di comando e controllo. La differenza, qui, è che il servizio scelto appartiene al mondo della telemetria industriale, un’area in cui la maturità del monitoraggio è mediamente inferiore a quella dell’IT e in cui l’analisi del traffico è ostacolata da vincoli di disponibilità che non ammettono interruzioni.

Per chi difende, la lezione non è aggiungere un dominio a una lista di blocco. È accettare che l’elenco dei canali plausibili per un comando e controllo coincide ormai con l’elenco dei servizi che l’organizzazione usa legittimamente, e costruire il rilevamento su questa premessa invece che sulla reputazione delle destinazioni.