3BB, MeshCentral diventa una backdoor root: l’attacco punta alle credenziali RADIUS

🛡️ Executive Summary

• Hunt.io ha recuperato 298 file da un server dell’attaccante con prove di accesso root e agenti MeshCentral attivi nella rete 3BB.
• Gli script puntavano ai database RADIUS, oltre 55 host interni, chiavi SSH, credenziali MySQL e sistemi F5 BIG-IP.
• Il toolkit contiene una catena completa per CVE-2024-21762 contro FortiGate, ma non dimostra che quella falla sia stata il vettore iniziale.

Un attaccante ha operato all’interno della rete di 3BB, uno dei maggiori operatori broadband thailandesi, mantenendo accesso persistente tramite MeshCentral, piattaforma open source normalmente utilizzata per l’amministrazione remota. La ricostruzione di Hunt.io mostra sistemi già registrati nel pannello dell’aggressore, alcuni con agenti eseguiti come root, script per il password spraying su oltre 55 host interni e strumenti destinati a estrarre credenziali dai database RADIUS degli abbonati. Sullo stesso staging server era presente anche una catena completa per sfruttare CVE-2024-21762 contro un FortiGate SSL-VPN. Ma il punto decisivo è proprio ciò che i dati non dimostrano: il toolkit prova capacità e intenti dell’attaccante, non consente di stabilire con certezza che FortiGate sia stato il vettore iniziale dell’intrusione.

Un server lasciato aperto espone 298 file dell’operazione contro 3BB

La ricostruzione nasce da un errore operativo dell’attaccante. L’analisi originale pubblicata da Hunt.io descrive un server raggiungibile su 92.63.180[.]133:8888 che il sistema AttackCapture ha acquisito il 3 giugno 2026. La directory conteneva 298 file distribuiti in 30 sottocartelle, per circa 19 MB complessivi: exploit, strumenti di privilege escalation, script di brute force, configurazioni MeshCentral, cookie di sessione, dati sulle macchine già raggiunte e procedure di cancellazione delle tracce.

Non si tratta quindi semplicemente di una collezione di malware trovata su Internet. Alcuni script erano stati eseguiti da un host con indirizzo privato 10.11.152.63, gateway interno e dominio di ricerca triplet.co.th, elemento compatibile con una macchina già presente all’interno della rete 3BB. La metodologia ricorda direttamente il caso ShinyHunters contro Oracle PeopleSoft, dove server di staging lasciati esposti avevano rivelato agenti MeshCentral camuffati da servizi Microsoft Azure. Anche in quel caso lo strumento RMM non costituiva il vettore iniziale, ma il livello utilizzato dopo la compromissione per conservare e ampliare il controllo.

MeshCentral viene lasciato intenzionalmente dopo la pulizia delle tracce

Il ruolo di MeshCentral è uno degli elementi meglio documentati dell’operazione. Il file meshagent.msh assegnava le macchine compromesse al gruppo denominato TH-3BB e configurava come server di gestione www.ayuthayatech[.]com, raggiunto attraverso WebSocket sulla porta 443. L’inventario devices.json mostrava più dispositivi collegati e diversi agenti in esecuzione con privilegi root.

L’attaccante disponeva inoltre di cookie validi per la console MeshCentral e di script dedicati all’installazione automatica del relativo agent. Ancora più significativo è cleanup_target.sh: eliminava exploit, web shell, log di autenticazione, syslog e cronologia delle shell, ma lasciava deliberatamente installato MeshCentral. Il comportamento conferma la trasformazione di un prodotto amministrativo legittimo in un meccanismo di persistenza. È la stessa asimmetria già vista nella campagna RMM distribuita in 46 Paesi con GoTo, LogMeIn, ScreenConnect, ConnectWise e ITarian: firma legittima, traffico cifrato, funzioni di terminale e file transfer arrivano direttamente dal software di amministrazione e non devono essere sviluppate dal malware. La detection basata soltanto sul nome dell’eseguibile perde quindi gran parte della propria efficacia.

Leggi anche: ScreenConnect passa da strumento RMM a backdoor worm-like con esecuzione e propagazione automatizzate

Il toolkit FortiGate contiene una catena completa per CVE-2024-21762

Il materiale recuperato mostra un investimento particolare contro mail.3bb.co[.]th:10443, identificato come FortiGate 60F SSL-VPN. Otto script eseguivano fingerprinting dell’appliance attraverso header HTTP, pagina di login, file fgt_lang.js, stringhe caratteristiche delle versioni FortiOS ed ETag. L’operatore testava più vulnerabilità note, tra cui CVE-2022-42475, CVE-2023-27997, CVE-2018-13379 e CVE-2024-21762, prima di concentrarsi su quest’ultima. Il toolkit arrivava fino a una catena RCE articolata in heap spray attraverso /remote/hostcheck_validate, out-of-bounds write e ROP chain destinata ad avviare /bin/node con una reverse shell verso il VPS dell’aggressore. Alcuni script cercavano perfino di scaricare l’esatta immagine FortiOS 7.2.5 utilizzando il numero seriale dell’appliance per adattare i gadget ROP alla build bersaglio. Questa precisione non equivale tuttavia alla prova del vettore iniziale. Hunt.io documenta che gli exploit erano preparati e che l’operatore aveva accesso interno, ma non dispone dei log necessari per concatenare causalmente i due elementi. La cautela è importante soprattutto dopo le campagne FortiBleed contro FortiGate, nelle quali credential stuffing e abuso delle funzioni diagnostiche erano stati distinti dalle vulnerabilità del prodotto.

Root arriva anche attraverso PwnKit, Dirty COW e backdoor SUID

Dentro la rete il toolkit non dipendeva da un unico percorso. Gli aggressori avevano preparato PwnKit, Dirty COW, Ghostcat e una backdoor SUID, insieme a strumenti dedicati alla raccolta delle credenziali e allo sfruttamento dei database. Un file recuperato da Hunt.io, got63.txt, documenta l’esecuzione di comandi con privilegi root sull’host interno vm-BCSWILDFLY_M63. La catena PwnKit utilizzava il classico abuso di GCONV_PATH, mentre il componente install_suid.c permetteva di creare un accesso privilegiato persistente. La scelta di conservare exploit vecchi ma affidabili mostra una caratteristica tipica delle intrusioni enterprise: una volta superato il perimetro, non è indispensabile utilizzare vulnerabilità recenti se sistemi interni non aggiornati offrono ancora escalation note. È un principio che nelle reti telecom era già apparso nelle operazioni contro operatori asiatici, dove Dirty COW, PwnKit e vulnerabilità sudo venivano combinate con tunneling e strumenti legittimi per ottenere e mantenere root. Anche i recenti Pedit COW e DirtyClone hanno mostrato quanto le primitive di escalation Linux continuino a puntare alla modifica dello stato privilegiato del sistema, pur attraverso vulnerabilità tecnicamente differenti.

I database RADIUS erano un obiettivo esplicito dell’attaccante

L’elemento più sensibile riguarda l’infrastruttura di autenticazione degli abbonati. Lo script cred_hunt.sh cercava chiavi SSH private, configurazioni PHP, password dei database, SNMP community string e cronologia delle shell. db_creds.sh era invece costruito specificamente per estrarre dati dai database radius_corp, radiusinfo e job_radius, compresa la tabella NAS utilizzata per identificare i dispositivi che autenticano contro il sistema RADIUS. Hunt.io interpreta questa specializzazione come indicazione dell’interesse verso le credenziali degli utenti broadband. Tuttavia targeting ed esfiltrazione non sono sinonimi: il materiale dimostra che gli script erano progettati per raggiungere quei dati, non che l’intero database degli abbonati sia stato effettivamente sottratto. La distinzione evita di trasformare un’intrusione documentata in un data breach dai contorni non ancora provati. Il gruppo disponeva comunque di credenziali specifiche dell’organizzazione e avviava password spraying SSH contro oltre 55 indirizzi interni, oltre a tentare autenticazioni MySQL senza password, accessi FTP anonimi e recupero di chiavi utilizzabili per nuovi pivot.

F5, MySQL e il portale commerciale ampliano la superficie interna

L’operatore non si limitava al backbone di autenticazione. Undici script della serie deep prendevano di mira agent.3bb.co[.]th, portale commerciale basato su CodeIgniter 2 dietro un bilanciatore F5 BIG-IP. Gli strumenti provavano session forgery, SQL injection, path traversal, upload di file, request smuggling CL.TE e TE.CL e diversi percorsi di aggiramento dei controlli applicativi. Un file conteneva la risposta HTML completa di una pagina autenticata, evidenza che l’aggressore era riuscito ad accedere almeno a una porzione delle funzionalità interne. Script separati sondavano inoltre F5 BIG-IP per CVE-2021-22986, CVE-2022-1388 e CVE-2023-46747. Sul versante database, i componenti mysql_rce cercavano di sfruttare INTO OUTFILE per depositare web shell PHP e iniettare chiavi SSH. Questa ridondanza è operativamente importante: anche se un singolo accesso viene rimosso, web shell, chiavi SSH, account SUID e MeshCentral offrono percorsi differenti per rientrare. È lo stesso problema osservato nelle campagne in cui SimpleHelp e altri prodotti di amministrazione remota restano installati dopo lo sfruttamento della vulnerabilità iniziale.

Continua con:

• CameraSwarm compromette oltre 14.000 dispositivi Dahua e lascia 1.923 backdoor persistenti
• FortiGate resta un obiettivo privilegiato anche su appliance aggiornate attraverso abuso delle identità SSO

Il problema non è MeshCentral ma chi possiede il piano di amministrazione

L’intrusione 3BB mostra perché i prodotti di remote management siano diventati così utili nelle fasi successive alla compromissione. MeshCentral non è malware e non emerge alcuna vulnerabilità del progetto utilizzata in questa operazione. È precisamente questa normalità a renderlo utile all’attaccante: remote shell, gestione dei file, agent persistente e comunicazioni cifrate sono funzionalità previste dal prodotto.

Il controllo difensivo non può quindi ridursi a bloccare MeshCentral. Le organizzazioni devono conoscere quali RMM sono autorizzati, quali server di management possono controllarli e quali endpoint hanno realmente motivo di eseguirli. Un agent legittimo collegato a un dominio sconosciuto deve essere trattato in modo radicalmente diverso dallo stesso agent collegato all’infrastruttura aziendale.

Nel caso 3BB, la priorità è ancora più ampia: la pulizia prevista dall’attaccante cancellava le tracce degli exploit ma preservava il proprio canale remoto. Eliminare la vulnerabilità iniziale, quindi, non sarebbe sufficiente a espellerlo. Servono verifica degli agent MeshCentral, ricerca di web shell e file SUID inattesi, controllo delle chiavi SSH, rotazione delle credenziali RADIUS e MySQL, revoca dei certificati VPN eventualmente esposti e revisione degli accessi amministrativi.

È anche la ragione per cui il caso non dovrebbe essere semplificato in “FortiGate violato con CVE-2024-21762”. Il dato più solido è diverso: un attaccante era già riuscito a trasformare strumenti di amministrazione, credenziali e vecchi exploit Linux in una rete di accessi ridondanti all’interno di un ISP. Il vero incidente comincia lì, non dal nome della vulnerabilità che potrebbe aver aperto la prima porta.