🚨 CVE-2026-48282: una semplice Path Traversal può trasformarsi in una Remote Code Execution su Adobe ColdFusion.

Nel video spiego:
🔴 cos'è RDS
🔴 perché il CVSS è 10.0
🔴 come avviene la catena di attacco
🔴 cosa controllare dopo aver applicato la patch

🎥 Guarda il video:
👉 https://youtu.be/SHYU1ag3NsQ

#CyberSecurity #ColdFusion #CVE202648282 #InfoSec #BlueTeam
@sicurezza@diggita.com

Alle 2:20 del mattino di martedì 28 luglio, poche ore prima che le azioni di Unitel iniziassero a essere scambiate sulla borsa di Luanda nella più grande IPO della storia angolana, i sistemi core del principale operatore di telecomunicazioni del paese sono andati in tilt. Voce, dati mobili e connettività internet si sono fermati per oltre 21 milioni di persone, quasi metà della popolazione dell’Angola. La tempistica, quasi chirurgica, ha subito sollevato una domanda che l’azienda stessa non ha escluso: è stato un sabotaggio pensato per far deragliare la quotazione?

Un blackout nazionale nelle 24 ore che contavano di piùUnitel, ex monopolista statale passato sotto controllo pubblico nel 2022 dopo il sequestro delle quote un tempo detenute da Isabel dos Santos, figlia dell’ex presidente José Eduardo dos Santos, ha dichiarato di aver rilevato l’incidente attorno alle 2:20 locali del 28 luglio e di aver attivato “immediatamente” i protocolli di risposta e contenimento. Il ripristino graduale dei servizi mobili è iniziato solo alle 11:45 del giorno successivo, provincia per provincia, con gli SMS rimasti fuori uso più a lungo di voce e dati. Le infrastrutture fisse su fibra e wireless, che servono istituzioni pubbliche e aziende, sono invece rimaste operative per tutta la durata dell’incidente, un dettaglio che suggerisce un impatto concentrato sui sistemi core mobili piuttosto che su un evento di disponibilità generalizzato.

Il dato più interessante arriva dalla telemetria di rete, non dai comunicati aziendali. Recorded Future News ha verificato che i prefissi IP di Unitel sono rimasti annunciati su internet per tutta la durata dell’incidente: i router che connettono l’operatore al resto della rete globale non sono mai andati offline, come invece accadrebbe in un classico taglio di connettività a monte o in un attacco DDoS volumetrico. Il traffico misurato da Cloudflare Radar mostra invece un crollo netto proprio nella finestra dell’attacco, confinato esclusivamente a Unitel mentre gli altri operatori angolani non hanno mostrato alcun degrado. La lettura più plausibile è quella di un incidente che ha disabilitato sistemi interni critici — probabilmente elementi core della rete mobile o piattaforme di autenticazione/billing — piuttosto che un attacco alla connettività esterna.

Il contesto: una IPO da record e un sospetto legittimoL’attacco è arrivato meno di 24 ore prima del debutto di Unitel alla BODIVA, la borsa angolana, nell’ambito del programma di privatizzazioni del presidente João Lourenço volto a ridurre il peso dello stato nell’economia post-marxista del paese. L’offerta, gestita dall’istituto statale di gestione patrimoniale IGAPE per una quota del 15%, è stata sottoscritta oltre il 120%, con più di 11.000 investitori coinvolti: un test di appetito del mercato per gli asset statali angolani, considerato un possibile precursore per la futura quotazione della compagnia petrolifera nazionale Sonangol. Nonostante il blackout in corso, la negoziazione è comunque partita mercoledì, valutando la società 2,14 miliardi di dollari e raccogliendo circa 321 milioni per le casse pubbliche.

Unitel stessa ha dichiarato di non poter escludere che l’attacco fosse “deliberato e mirato”, proprio a causa della coincidenza con l’avvio delle negoziazioni azionarie. Nessun gruppo ha rivendicato la responsabilità, e non ci sono conferme pubbliche su esfiltrazione di dati o impiego di ransomware. Un elemento di contesto rilevante: settimane prima dell’incidente, il collettivo “CyberTeam” — coinvolto in un attacco contro l’Assemblea Nazionale angolana — aveva lasciato intendere che Unitel potesse essere il bersaglio successivo, sebbene al momento non vi sia alcuna prova che leghi quel gruppo all’incidente di luglio. L’interruzione ha avuto ricadute anche sull’economia reale: i terminali POS collegati alla rete Unitel hanno smesso di funzionare, colpendo pagamenti digitali e comunicazioni aziendali in un paese dove la penetrazione mobile è lo scheletro portante dei servizi finanziari.

Perché conta per chi guarda alla sicurezza delle telcoAl di là del singolo episodio, l’incidente Unitel è un caso di scuola su tre fronti che meritano attenzione da parte di chi si occupa di protezione delle infrastrutture critiche. Primo: la tempistica di un attacco può essere un’arma quanto il payload stesso. Colpire un operatore telco nelle ore immediatamente precedenti un evento finanziario ad alta visibilità massimizza il danno reputazionale e la pressione su chi deve decidere se procedere comunque con l’IPO, indipendentemente dalla natura tecnica dell’attacco. Secondo: la persistenza dei prefissi BGP durante l’intero blackout conferma ancora una volta che gli attacchi più dannosi contro le telco moderne non colpiscono più solo la disponibilità della rete di trasporto, ma i sistemi applicativi core — HLR/HSS, piattaforme di autenticazione, sistemi di billing — la cui compromissione può paralizzare i servizi senza mai far sparire l’infrastruttura di routing dai radar esterni. Terzo: la sequenza di ripristino, provincia per provincia e canale per canale (voce e dati prima, SMS dopo), suggerisce un lavoro di remediation selettivo su sistemi distinti piuttosto che un semplice riavvio, coerente con un incidente di sicurezza più che con un guasto tecnico diffuso.

Per i team di difesa delle telco, specialmente in mercati emergenti dove eventi di mercato ad alta visibilità (IPO, fusioni, aste di spettro) sono sempre più frequenti, il caso Unitel rafforza la necessità di considerare tali finestre temporali come periodi a rischio elevato, con controlli rafforzati su change management, accessi privilegiati ai sistemi core e monitoraggio della telemetria BGP/traffico in tempo reale per distinguere rapidamente un attacco interno da un problema di connettività esterna. Vale la pena notare che nessuna autorità di regolamentazione, né la BODIVA né l’authority dei mercati di capitale angolana, ha rilasciato dichiarazioni pubbliche sull’accaduto: un silenzio istituzionale che lascia molte domande aperte su attribuzione, impatto reale sui dati dei clienti ed eventuali richieste estorsive dietro le quinte.

Cosa manca ancora al quadroA oggi restano senza risposta le domande più rilevanti per una piena classificazione dell’incidente: quale vettore di accesso iniziale è stato usato, se ci sia stata esfiltrazione di dati dei 21 milioni di abbonati, e se dietro l’attacco ci sia un gruppo con motivazioni finanziarie, un attore hacktivista legato a tensioni politiche interne, oppure un operatore state-sponsored interessato a colpire la privatizzazione degli asset angolani. La vicenda merita un monitoraggio attento nelle prossime settimane, sia per eventuali rivendicazioni su forum underground sia per comunicazioni obbligatorie che Unitel, in quanto società ora quotata, dovrà rendere al mercato.

28 luglio, ore 2:20 locali: rilevamento dell’incidente sui sistemi core Unitel

28-29 luglio: interruzione totale di voce, dati mobili e SMS a livello nazionale; rete fissa non impattata

29 luglio, ore 11:45: avvio del ripristino graduale provincia per provincia

29 luglio: debutto di Unitel alla BODIVA nonostante l’incidente in corso, raccolta di circa 321 milioni di dollari

Nessuna rivendicazione pubblica, nessuna conferma di esfiltrazione dati al momento della pubblicazione

Non ha un sito web, non ha un catalogo prodotti pubblico, non ha nemmeno un’insegna. Eppure Guangdong Chanming Technology, una società con sede nel Guangdong praticamente invisibile su internet, avrebbe costruito e gestito per anni una delle infrastrutture di offuscamento più utilizzate dagli APT cinesi legati all’Esercito Popolare di Liberazione: la rete RedRelay, nota nella letteratura di threat intelligence occidentale anche come ORBWEAVER. A smascherarla è stato il collettivo di ricercatori indipendenti Intrusion Truth, che da oltre otto anni applica tecniche di OSINT per identificare le persone e le società dietro le operazioni di cyberspionaggio di Pechino.

Cos’è una ORB network e perché fa paura ai difensoriLe “Operational Relay Box” network, o ORB network, sono infrastrutture di proxy multi-hop costruite aggregando router domestici compromessi, VPS commerciali e dispositivi IoT, con l’obiettivo di far rimbalzare il traffico degli attaccanti attraverso molteplici salti prima di raggiungere il bersaglio finale. Google Mandiant e Microsoft le descrivono da anni come uno degli sviluppi più insidiosi nel tradecraft delle APT cinesi: a differenza di una singola VPN o di un bulletproof hosting, un ORB network cambia continuamente topologia, mescola traffico legittimo e malevolo sugli stessi nodi e rende quasi inutile il blocco per indirizzo IP, perché l’infrastruttura di oggi non è quella di domani. Gruppi come Volt Typhoon hanno già dimostrato quanto queste reti complichino l’attribuzione e la difesa perimetrale nelle infrastrutture critiche occidentali.

Da Free Connect a RedRelay: la genesi del progettoSecondo la ricostruzione di Intrusion Truth, RedRelay nasce come evoluzione di Free Connect (FCN), un tool VPN sviluppato in origine come progetto personale da Wang Huiping, oggi co-fondatore di Guangdong Chanming. Il codice, un tempo ospitato su GitHub sotto lo pseudonimo “boywhp”, è stato progressivamente trasformato in un prodotto commerciale a duplice uso: da un lato uno strumento di anonimizzazione generico, dall’altro un’infrastruttura su misura per operazioni offensive. I ricercatori sono risaliti a Wang incrociando un numero di telefono registrato su documenti societari con un indirizzo email legato al progetto FCN, un classico errore operativo che il collettivo sfrutta sistematicamente per deanonimizzare gli sviluppatori di tool “dual use” cinesi.

Sul piano tecnico, campioni VirusTotal riconducibili al dominio associato a FCN includono file identificati come stn.exe, mentre le versioni Linux del tool utilizzano un comando distintivo che ha condotto gli analisti a “bulbature”, un artefatto già associato in passato alla famiglia di malware WHIPWEAVE, anch’essa collegata all’ecosistema RedRelay/ORBWEAVER.

I brevetti che tradiscono lo scopo realeLa parte più interessante dell’indagine riguarda i brevetti e i copyright software depositati da Guangdong Chanming presso gli uffici cinesi competenti. Almeno due brevetti descrivono esplicitamente flussi di traffico anonimizzati e multi-hop coerenti con il comportamento osservato di RedRelay. Ma l’elenco dei prodotti registrati va ben oltre l’anonimizzazione: tra i titoli figurano un “Internet Security Access System”, un “Multi-functional Security Proxy”, un “Anti-traceability Network”, un sistema di “Network Vulnerability Testing”, un “Android Secret Extraction System” e, particolarmente rilevante, un “Telegram Data Collection System”. Si tratta di capacità che, cumulate, disegnano il profilo di un fornitore di strumenti di sorveglianza ed estrazione dati su misura per operazioni statali, non di un’azienda di cybersecurity difensiva come vorrebbe far credere l’assenza quasi totale di presenza pubblica.

Il cliente: non solo intelligence, ma anche poliziaGli elementi più sensibili emersi dall’indagine riguardano i clienti. Documenti di procurement riconducibili a canali dell’Esercito Popolare di Liberazione citano la fornitura da parte di Guangdong Chanming di un “Anonymous Network System” a un’unità di stanza nel distretto di Haidian, a Pechino, area storicamente associata alla PLA Cyberspace Force. Le analisi open source collegano inoltre l’uso di RedRelay a diversi cluster di cyberspionaggio cinese tracciati da anni dall’industria della threat intelligence sotto etichette come APT15, Ke3chang, Vixen Panda, Red Vulture, Playful Dragon e Nylon Typhoon, gruppi storicamente attivi contro ministeri degli esteri, ambasciate e contractor della difesa in Europa e Asia. Secondo Intrusion Truth, a queste attribuzioni si aggiungerebbero designazioni interne cinesi come l’Unità 61046 e l’VIII Ufficio del CSF (Cyberspace Force), sebbene questo livello di attribuzione resti – come sempre in questi casi – basato su indizi convergenti più che su prove dirette e verificabili da terzi.

Non meno significativo è che tra i clienti indicati compaia anche il Ministero della Pubblica Sicurezza, l’apparato che gestisce le forze di polizia cinesi: un dettaglio che conferma quanto il confine tra sorveglianza interna e cyberspionaggio esterno, nel modello cinese dei contractor privati “dual use”, sia ormai strutturalmente sfumato – lo stesso schema documentato in passato per fornitori come i900 e la galassia legata a APT41 e Silk Typhoon.

Due righe per i difensoriPer i team di detection, la lezione principale è che il blocklisting basato su indirizzi IP o su singoli domini è una difesa in costante ritardo contro le ORB network: RedRelay, come le altre infrastrutture simili, ruota continuamente nodi residenziali e commerciali compromessi. È più efficace investire in detection comportamentale (pattern di traffico anomali verso servizi di collaborazione, orari di attività non coerenti con l’utenza reale, fingerprint TLS associati a tool come FCN/stn), condivisione di intelligence tra organizzazioni sullo stesso settore e monitoraggio delle infrastrutture note collegate a WHIPWEAVE. Per le organizzazioni che gestiscono comunicazioni sensibili su Telegram o piattaforme simili, la conferma dell’esistenza di un “Telegram Data Collection System” commerciale cinese è un promemoria che l’app di messaggistica, da sola, non garantisce alcuna protezione dall’intelligence statale se l’endpoint o l’account è nel mirino.

Indicatori e riferimenti notiSocietà identificata: Guangdong Chanming Technology Co., Ltd.
Persona chiave: Wang Huiping (co-fondatore, ex sviluppatore progetto "Free Connect / FCN", GitHub handle "boywhp")
Infrastruttura: RedRelay (alias ORBWEAVER), ORB network multi-hop
Artefatti noti: stn.exe (Windows), comando distintivo Linux collegato a "bulbature"
Famiglia malware collegata: WHIPWEAVE
Prodotti brevettati/registrati: Internet Security Access System, Multi-functional Security Proxy,
Anti-traceability Network, Network Vulnerability Testing System, Android Secret Extraction System,
Telegram Data Collection System, File Transfer Network
Clienti riportati: unità PLA Cyberspace Force (distretto di Haidian, Pechino), Ministero della Pubblica Sicurezza
Gruppi APT collegati: APT15 / Ke3chang / Vixen Panda / Red Vulture / Playful Dragon / Nylon Typhoon
Designazioni interne citate: Unità 61046, VIII Ufficio CSFL’indagine di Intrusion Truth, pubblicata il 27 luglio 2026 e ripresa nei giorni successivi da Risky Business, GBHackers e altre testate di settore, si inserisce in un filone di ricerca ormai consolidato: dal caso i-Soon del 2024 alle rivelazioni su altri fornitori “fantasma” del ministero della Sicurezza di Stato, l’ecosistema dei contractor privati cinesi continua a produrre errori operativi sufficienti a far emergere, poco alla volta, l’architettura reale dietro le campagne di cyberspionaggio più persistenti contro obiettivi occidentali.

Un’advisory congiunta pubblicata il 30 luglio 2026 da National Intelligence Service, National Police Agency, KISA e Financial Security Institute sudcoreani, basata sull’analisi di AhnLab ASEC, ricostruisce oltre un anno di attività di un gruppo state-sponsored contro cittadini e aziende della Corea del Sud. Il dato più interessante non è la campagna di spionaggio in sé, ma la sua sovrapposizione tecnica con episodi attribuiti al ransomware Gunra: stessa vulnerabilità sfruttata, stesse impronte SSH, stessa infrastruttura di rete. Gli analisti l’hanno battezzata Operation Double Barrel.

Un anno e mezzo di infiltrazione silenziosaSecondo ASEC, tra il 2025 e la prima metà del 2026 un attore state-sponsored ha sfruttato in modo continuativo vulnerabilità in software di sicurezza finanziaria diffuso in Corea del Sud — la categoria di plugin e moduli di autenticazione che le banche e i portali pubblici sudcoreani impongono spesso agli utenti per operazioni online, un ecosistema già colpito in passato da gruppi legati alla Corea del Nord proprio per la sua ubiquità e per i privilegi elevati con cui questi moduli girano sui sistemi degli utenti.

Il vettore di accesso iniziale ha seguito due binari paralleli: watering hole su siti legittimi sudcoreani nei settori media, istruzione, sanità e manifatturiero, e spear-phishing con link malevoli inviati direttamente ai bersagli. In entrambi i casi l’obiettivo era far raggiungere alla vittima una pagina che sfruttasse la vulnerabilità nel software finanziario per installare un backdoor.

Gli impianti: Struggle e BrandoorASEC identifica due famiglie di backdoor principali nella campagna: Struggle, tracciato anche come SIGNBT 3.0, e Brandoor, alias COPPERHEDGE. Non sono nomi nuovi per chi segue le operazioni nordcoreane: SIGNBT è una famiglia storicamente associata al cluster Andariel dell’ombrello Lazarus, mentre COPPERHEDGE è un impianto documentato da anni negli advisory CISA/US-CERT sotto l’etichetta HIDDEN COBRA, usato in particolare contro exchange di criptovalute e istituzioni finanziarie. La loro presenza in questa campagna rafforza l’attribuzione a un attore nordcoreano, anche se il report ASEC, in linea con la prassi delle agenzie sudcoreane, evita l’attribuzione esplicita in favore della dicitura “gruppo state-sponsored”.

Oltre ai due backdoor principali, l’advisory cita strumenti aggiuntivi per l’escalation di privilegi e la consegna di payload successivi, elemento che suggerisce un kit modulare adattato caso per caso a seconda del bersaglio e dei privilegi ottenuti nella fase di accesso iniziale.

Il secondo barile: Gunra ransomwareGunra è un gruppo ransomware relativamente giovane, emerso sui data leak site nel 2025 con un locker dual-platform per Windows e Linux; la variante Linux, analizzata a fondo da ASEC in report precedenti, si è rivelata tecnicamente fragile a causa di un generatore di numeri casuali difettoso nell’implementazione della cifratura, un dettaglio che in alcuni casi ha permesso il recupero dei file senza pagare il riscatto.

Ciò che rende rilevante Operation Double Barrel è che alcuni incidenti attribuiti a Gunra hanno riutilizzato le stesse vulnerabilità nel software finanziario coreano sfruttate dal gruppo state-sponsored, e mostrano sovrapposizioni in malware, impronte delle chiavi SSH e infrastruttura di rete, inclusi indirizzi usati per il download di payload e per il reverse tunneling. ASEC non si spinge a dichiarare che si tratti dello stesso gruppo, ma ipotizza tecniche, strumenti o infrastruttura condivisi, oppure una collaborazione limitata tra i due attori.

Lo scenario non è inedito: negli ultimi anni diversi ricercatori hanno documentato episodi in cui operatori legati alla Corea del Nord hanno sperimentato il ransomware come ulteriore fonte di finanziamento, affiancandolo alle tradizionali operazioni di furto di criptovalute e spionaggio economico. Se confermata, una relazione anche solo infrastrutturale tra un cluster di spionaggio statale e una gang ransomware indipendente solleva interrogativi non banali su come Pyongyang stia monetizzando l’accesso ottenuto per scopi di intelligence, eventualmente “affittandolo” o rivendendolo a operatori criminali con obiettivi finanziari.

Timeline2025 — inizio dello sfruttamento delle vulnerabilità nel software di sicurezza finanziaria coreano; primi impianti Struggle/SIGNBT 3.0 e Brandoor/COPPERHEDGE osservati in campagne watering hole e spear-phishing.

2025 – H1 2026 — incidenti paralleli attribuiti al ransomware Gunra riutilizzano le stesse vulnerabilità e mostrano sovrapposizioni infrastrutturali.

30 luglio 2026 — NIS, NPA, KISA e FSI pubblicano l’advisory congiunta “Operation Double Barrel”; AhnLab ASEC rilascia i report tecnici in coreano e inglese con IoC completi.

Due righe per i difensoriPer i team di difesa, anche fuori dalla Corea del Sud, il caso offre due lezioni. La prima: i moduli di sicurezza aggiuntivi imposti da settori regolamentati (banking security software, plugin di autenticazione, agent antifrode) restano un bersaglio ad alto ritorno per gli attaccanti, proprio perché godono di privilegi elevati e fiducia implicita da parte dell’utente. La seconda: il monitoraggio delle infrastrutture ransomware non può più prescindere dalla correlazione con il tracking degli APT, perché la separazione tra “cybercrime a scopo di lucro” e “operazioni di intelligence statale” nel caso nordcoreano è sempre più sfumata. Chi gestisce threat intelligence dovrebbe incrociare sistematicamente IoC di gruppi ransomware emergenti con quelli degli intrusion set nordcoreani noti, cercando sovrapposizioni di infrastruttura anche quando l’attribuzione formale resta incerta.

Indicatori di compromissioneNome operazione: Operation Double Barrel
Enti coinvolti nell'advisory: NIS, NPA, KISA, FSI (Corea del Sud)
Fonte tecnica: AhnLab ASEC
Backdoor identificati: Struggle (alias SIGNBT 3.0), Brandoor (alias COPPERHEDGE)
Gruppo ransomware collegato: Gunra
Vettori di accesso iniziale: watering hole su siti legittimi coreani (media, istruzione,
sanità, manifatturiero), spear-phishing con link malevoli
Vulnerabilità sfruttate: falle in software di sicurezza finanziaria coreano
Indicatori tecnici condivisi tra le due campagne: impronte di chiavi SSH, indirizzi IP
di download e reverse tunneling, credenziali riutilizzate
Report completi: [AhnLab] Operation Double Barrel (KOR/ENG) (2026.07.30)
MITRE ATT&CK: T1189 Drive-by Compromise, T1566.002 Spearphishing Link,
T1190 Exploit Public-Facing Application, T1105 Ingress Tool Transfer,
T1059 Command and Scripting Interpreter, T1003 OS Credential Dumping,
T1021.004 Remote Services: SSH, T1071.001 Application Layer Protocol: Web Protocols,
T1078 Valid AccountsFonte: AhnLab ASEC, advisory congiunta NIS/NPA/KISA/FSI.

Un server Alibaba Cloud lasciato aperto per errore ha smascherato un intero cluster di cyberspionaggio China-nexus: intrusioni attive contro un ospedale vietnamita, il Ministero degli Esteri malese, decine di istituti universitari di Hong Kong e persino un pacchetto di spear-phishing indirizzato al Congresso dell’Honduras. Group-IB lo chiama JadeProx, e la sua tradecraft ruota attorno a un loader Windows mai documentato prima, il TriBack Loader, distribuito anche tramite un finto installer di Claude.

Un errore operativo che vale un intero dossierA metà aprile 2026 i ricercatori di Group-IB hanno individuato, nella regione Singapore di Alibaba Cloud, un server di staging esposto senza alcuna autenticazione. Al momento della pubblicazione del report, il 23 luglio 2026, il server era già stato smantellato, ma la sua cronologia bash, i pacchetti di phishing, gli strumenti post-exploitation e i path dei webshell hanno permesso di ricostruire in dettaglio un’operazione attiva su tre continenti diversi.

Gli obiettivi identificati sono eterogenei ma coerenti con un mandato di raccolta informativa ad ampio spettro tipico degli operatori legati alla Cina: il sistema di imaging medicale (PACS, Picture Archiving and Communications System) di un ospedale pubblico vietnamita, da cui transitano radiografie, TAC e risonanze dei pazienti; il Ministero degli Esteri della Malesia, violato con webshell e strumenti di tunneling; l’infrastruttura universitaria di Hong Kong, colpita con una scansione massiva; e un pacchetto di spear-phishing con decoy finanziario indirizzato al Congresso Nazionale dell’Honduras. Gli operatori sono arrivati al server dell’ospedale vietnamita attraverso webshell piazzate su un’interfaccia di gestione Java esposta su Internet.

TriBack Loader: un unico loader, quattro variantiAl centro della tradecraft c’è un loader Windows che Group-IB battezza TriBack Loader, mai documentato in precedenza. Compare in quattro catene di infezione, tutte costruite attorno al DLL sideloading: un eseguibile legittimo firmato viene abbinato a una DLL malevola e a un payload cifrato in formato .dat o .log.

La DLL inverte i byte del payload, li decifra con XOR a chiave rotante, ed esegue lo shellcode tramite chiamate Win32 che gli EDR monitorano meno rispetto alla classica CreateThread. Le quattro varianti si differenziano proprio nella chiamata finale usata per l’esecuzione: due si affidano a InitOnceExecuteOnce e a un callback TimerQueue, una terza sfrutta EtwpCreateEtwThread, una routine non documentata di ntdll per la creazione di thread. Anche il binario firmato ospite cambia da variante a variante. Per i ricercatori, la ripetizione sistematica della stessa sequenza di API suggerisce l’esistenza di un builder automatizzato per la generazione del loader.

Due varianti distribuiscono AdaptixC2, framework open source di post-exploitation già osservato in altre campagne ransomware. Una terza variante, particolarmente insidiosa, si maschera da software Claude: usa DonutLoader per eseguire Beagle, una backdoor documentata per la prima volta da Sophos. La quarta variante resta un mistero: il file cifrato che ne conteneva il payload non è mai stato recuperato.

L’esca perfetta: un finto Claude con MSI malevoloUno degli aspetti più rilevanti per un pubblico di professionisti è la campagna di impersonificazione del software Anthropic. Il dominio claude-pro[.]com, registrato il 28 marzo 2026, ha distribuito un installer MSI malevolo che, superato un prompt UAC, posizionava la catena di sideloading nella cartella di avvio di Windows per garantirsi la persistenza. La backdoor Beagle consegnata da questa variante comunicava con license[.]claude-pro[.]com come infrastruttura di comando e controllo.

Sophos, lavorando a partire dal sito fasullo, dalla sua infrastruttura di hosting e dai campioni di malware raccolti, ha rilevato la stessa chiave XOR riutilizzata in build risalenti a febbraio 2026, ma ha specificato che una chiave condivisa non basta da sola a confermare un singolo attore dietro tutte le campagne: nell’ecosistema China-nexus gli strumenti circolano liberamente tra gruppi diversi. Lo stesso approccio prudente vale per Group-IB, che raggruppa le intrusioni asiatiche sotto l’etichetta JadeProx senza attribuirle in modo definitivo a un gruppo APT già catalogato.

Se la valutazione di Sophos è corretta e il sito fasullo faceva parte di una campagna di malvertising attiva, l’esposizione va ben oltre ministeri e ospedali: raggiunge chiunque, nel mondo, stesse semplicemente cercando di scaricare Claude.

Vulnerabilità vecchie di anni per colpire infrastrutture nuoveSul fronte dello scanning contro l’istruzione di Hong Kong, gli operatori hanno lanciato Nuclei con template a severità critica contro una lista di 14.653 URL legati al settore educativo, individuando 13 vulnerabilità uniche. Il report non specifica quanti tentativi di sfruttamento successivi abbiano avuto successo, ma indica quattro CVE specifiche tentate contro singoli host, tutte con punteggio CVSS 9.8: CVE-2018-11511 (ASUSTOR ADM), CVE-2021-24139 (plugin WordPress 10Web Photo Gallery), CVE-2021-31755 (router Tenda AC11) e CVE-2021-32305 (WebSVN).

Il dettaglio interessante per i difensori è che la falla su Tenda AC11 è nel catalogo KEV (Known Exploited Vulnerabilities) di CISA dal 3 novembre 2021, con una scadenza di remediation federale spirata appena due settimane dopo. In altre parole: la parte “artigianale” e sofisticata di questa operazione — loader custom, sideloading, ETW abuse — si appoggia a un ingresso iniziale banale, fatto di CVE pubbliche e non patchate da anni. L’ingegneria del loader conta poco se la porta d’ingresso resta aperta dal 2021.

Cosa monitorareGroup-IB e i ricercatori coinvolti raccomandano di concentrare il rilevamento sulla catena di sideloading piuttosto che sui singoli indicatori di rete, dato che nomi file e host firmati cambiano a ogni build:

Segnalare binari vendor firmati eseguiti da directory scrivibili dall’utente, temporanee o dalla cartella Startup, specialmente in presenza di file .dat o .log cifrati nella stessa cartella.

Cercare copie sospette di hostfxr.dll, avk.dll o MpClient.dll, insieme a cartelle annidate del tipo CL###### e allo script ~del.vbs.bat.

Bloccare o investigare i domini del cluster: claude-pro[.]com, license[.]claude-pro[.]com, sylverixstrategy[.]com, gouvvbo[.]top, vertextrust-advisors[.]com, e tre domini civetta che imitano vendor di sicurezza condividendo lo stesso IP — update-trellix[.]com, update-crowdstrike[.]com, update-sentinelone[.]com.

Dare priorità alle applicazioni Java esposte su Internet, quindi a qualsiasi sistema pubblico con una falla non patchata di severità 9.8, incluse le quattro citate.

Indicatori di compromissioneDomini:
claude-pro[.]com (registrato 28/03/2026)
license[.]claude-pro[.]com
sylverixstrategy[.]com
gouvvbo[.]top
vertextrust-advisors[.]com
update-trellix[.]com
update-crowdstrike[.]com
update-sentinelone[.]com

Infrastruttura di staging:
43.106.71[.]28:8000

CVE sfruttate (CVSS 9.8):
CVE-2018-11511 - ASUSTOR ADM
CVE-2021-24139 - 10Web Photo Gallery (WordPress)
CVE-2021-31755 - Tenda AC11 (KEV CISA dal 03/11/2021)
CVE-2021-32305 - WebSVN

Artefatti su disco:
hostfxr.dll / avk.dll / MpClient.dll (copie sospette)
CL###### (cartelle annidate)
~del.vbs.bat

Malware associato:
TriBack Loader (loader custom, DLL sideloading)
AdaptixC2 (post-exploitation open source)
DonutLoader -> Beagle backdoorFonti: report Group-IB, The Hacker News, Sophos.

Migliaia di email di conferma iscrizione e newsletter che intasano la casella di posta in pochi minuti, seguite — puntuale come un copione — da un messaggio Teams di un fantomatico “IT Support” pronto ad aiutare. È la sequenza che eSentire’s Threat Response Unit (TRU) ha documentato in una campagna di luglio 2026 contro un’azienda del settore software, attribuita al broker di accessi iniziali UNC6692. Il bersaglio finale non è un semplice furto di credenziali: è l’installazione di Edgecution, un’estensione malevola per Microsoft Edge capace di evadere la sandbox del browser e prendere il controllo dell’host sottostante.

UNC6692 non è un nome nuovo per chi segue il crimine informatico organizzato: Google Cloud/Mandiant lo ha già descritto come un initial access broker (IAB) che prepara il terreno per gruppi ransomware, tra cui la syndicate nota come Payouts King. La catena osservata da eSentire — email bombing, impersonificazione IT via Teams, Quick Assist e una suite di malware modulare battezzata “SNOW” — è la stessa tradecraft già segnalata da Google e da The Hacker News nei mesi scorsi, ma il report più recente aggiunge dettagli tecnici granulari sull’ultimo anello della catena, l’estensione Edgecution, e sui suoi indicatori di compromissione.

Fase 1: sommergere la vittima di email per giustificare una chiamataL’attacco si apre con una tecnica ormai da manuale ma sempre efficace: l’email bombing. Iscrivendo l’indirizzo della vittima a migliaia di newsletter e servizi di conferma automatica, gli attaccanti saturano la casella di posta in pochi minuti. L’obiettivo non è nascondere altro traffico, ma costruire un pretesto plausibile: un dipendente sommerso da email è più propenso ad accettare senza troppe domande il contatto di un “supporto IT” che offre di risolvere il problema.

Subito dopo il bombing, gli attaccanti contattano la vittima su Microsoft Teams impersonando l’identità “IT Support | Corporate IT Service (Internal)”. La scelta del canale non è casuale: Teams è percepito come un ambiente aziendale “fidato” rispetto alla posta elettronica, il che abbassa ulteriormente la soglia di sospetto della vittima nel momento cruciale.

Fase 2: Quick Assist come porta d’accesso hands-onIl finto tecnico guida la vittima a lanciare Quick Assist, lo strumento di assistenza remota integrato in Windows, dando agli attaccanti accesso interattivo alla macchina. Da quel momento sono loro a dirigere l’infezione: portano la vittima su un sito di phishing ospitato su Amazon S3 e progettato per imitare una pagina Office 365. La pagina utilizza i primi due pulsanti per far scaricare alla vittima AutoHotkey e uno script stager, mentre un modulo di login raccoglie in chiaro la password Office 365 non appena viene premuto “invio”. Un dettaglio curioso della catena: lo script analizza persino gli appunti (clipboard) della vittima con un’espressione regolare, alla ricerca di un codice di riferimento fornito verbalmente durante la finta sessione di supporto — un ulteriore livello di “autenticazione sociale” della truffa.

Edgecution: un’estensione Edge che rompe il sandbox del browserIl payload finale, Edgecution, combina un’estensione malevola per Microsoft Edge con un native messaging host in Python. È proprio questa combinazione a permettere all’estensione — normalmente confinata alla sandbox del browser — di comunicare con un processo nativo sul sistema operativo e, di fatto, evadere i limiti imposti dal browser stesso. Una volta installata, Edgecution è in grado di monitorare in tempo reale i siti web visitati dalla vittima, catturare le credenziali Office 365 inserite, scrivere file arbitrari sul disco, enumerare i processi in esecuzione ed eseguire comandi shell, Python o PowerShell a piacimento — di fatto un accesso remoto completo mascherato da componente del browser.

Lo stager scaricato dal sito S3 arriva come archivio ZIP protetto da password, estratto tramite tar.exe in una sottocartella nascosta dentro %LOCALAPPDATA%\Microsoft\Edge\User Data. Tutte le stringhe presenti nello stager e nel native messaging host sono offuscate con XOR e decodificate solo a runtime, un accorgimento pensato per rallentare l’analisi statica. Per la persistenza, il malware scrive voci di registro sotto la chiave NativeMessagingHosts di Microsoft Edge e crea — eseguendolo immediatamente — un’attività pianificata configurata per rilanciare Edge con l’estensione caricata a ogni accesso.

Un IAB al servizio del ransomwareIl quadro attributivo colloca UNC6692 non come gruppo ransomware in sé, ma come specialista dell’accesso iniziale che poi rivende o passa il testimone a operazioni di estorsione più ampie, in particolare Payouts King. È un modello di business ormai consolidato nell’ecosistema del cybercrime: separare chi entra da chi cifra e negozia il riscatto permette a entrambe le parti di specializzarsi e di essere più difficili da tracciare come un’unica organizzazione. Vista in quest’ottica, la sofisticazione dell’ingegneria sociale di UNC6692 — pretesto costruito ad arte, canale Teams “aziendale”, Quick Assist, verifica via clipboard — non è fine a se stessa: è l’investimento necessario per garantirsi l’accesso di alta qualità che un cliente ransomware è disposto a pagare.

Due righe per i difensoriPer i team blue team, la catena UNC6692 offre diversi punti di intercettazione prima che si arrivi a Edgecution. Il primo è comportamentale: un’ondata improvvisa di iscrizioni a newsletter verso una singola casella dovrebbe generare un alert automatico, così come un contatto Teams esterno o appena creato che si presenta come “IT Support” — Microsoft Teams consente di etichettare gli account esterni, e questa etichetta va monitorata, non ignorata dagli utenti. Il secondo punto di controllo è tecnico: le policy aziendali dovrebbero limitare l’uso di Quick Assist ai soli casi avviati dall’help desk interno tramite ticket, bloccandolo o quantomeno alertando su ogni sessione avviata da un utente su richiesta esterna. Sul fronte endpoint, vale la pena monitorare la creazione di voci sotto HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts e la creazione di scheduled task che rilanciano msedge.exe con parametri di estensione custom, oltre a restringere via policy quali estensioni Edge possono essere installate al di fuori dello store ufficiale.

Va sottolineato che, secondo eSentire, l’archivio ZIP di Edgecution viene ricostruito da byte “spogliati” dell’header standard, un dettaglio che rende la sua individuazione tramite semplice controllo di firma file inefficace: servono euristiche comportamentali o EDR capaci di ispezionare i native messaging host registrati, non solo le estensioni installate nel browser.

Indicatori di compromissione[Infrastruttura C2 Edgecution - domini CloudFront]
d385m5skczp5q5.cloudfront[.]net
d7xpwoah6gdv2.cloudfront[.]net
(+ 5 domini CloudFront aggiuntivi identificati da eSentire TRU)
[URL di delivery phishing/payload - Amazon S3]
hxxps://app7040.s3.us-east-1.amazonaws[.]com/patch.html
hxxps://app5805.s3.us-east-1.amazonaws[.]com/js/patch3265343.a
(+ 3 URL aggiuntivi identificati da eSentire TRU)
[Hash SHA-256 - artefatti sito phishing e payload]
232bca658c585627830623fcdce56647dc291666b25c901ee56212681198067a
e88c196a86c74ea0e53dfe77c93f577cb441ee590756cf7f3284522a2d6a6be5
da1cf68c9dc1cebcebf8ec7d1cf99ac9c0291db7b21bf279b9cad24c7a49948c
[Comandi osservati in fase di deployment]
tar.exe -xf ".zip" -C "%LOCALAPPDATA%\Microsoft\Edge\User Data\test1" --passphrase ""
cmd.exe /c python --version 2>&1
cmd /c start /min ... & del
[Account Microsoft Teams usati per l'impersonificazione IT]
Identità display: "IT Support | Corporate IT Service (Internal)"
(indirizzi email specifici omessi dalla fonte originale)
[Persistenza]
Chiave di registro: HKLM\SOFTWARE\Microsoft\Edge\NativeMessagingHosts
Meccanismo: Scheduled Task creato ed eseguito immediatamente per rilanciare Microsoft Edge con l'estensione caricataFonti: eSentire Threat Response Unit (TRU), Google Cloud Threat Intelligence/Mandiant, The Hacker News, BleepingComputer.

Per tre giorni, tra il 9 e il 13 luglio 2026, un server ospitato a Hong Kong ha lasciato aperte al mondo intero tre directory contenenti l’intera cassetta degli attrezzi di un’operazione contro il Ministero delle Finanze thailandese. Dentro, oltre 580 file e 470 MB di exploit, webshell e credenziali rubate, i ricercatori di Hunt.io e il giornalista Bob Diachenko hanno trovato qualcosa di nuovo: i log di un agente IA autonomo, Hermes, lasciato libero di enumerare host, scalare privilegi e frugare tra i file di un ministero senza che nessun essere umano ne supervisionasse i comandi in tempo reale.

Non è la prima volta che un attore offensivo delega lavoro di routine a un modello linguistico: negli ultimi mesi si sono già visti agenti IA usati in intrusioni ransomware e cloud, e persino in operazioni di spionaggio attribuite ad attori legati alla Cina. Ma il caso thailandese, documentato da Hunt.io in un report pubblicato il 25 luglio, è tra i primi a mostrare un’agente IA che opera davvero “senza supervisione” — in modalità YOLO, senza prompt di conferma — contro un obiettivo governativo, mentre un impianto Go inedito, ribattezzato dall’operatore stesso “Hades”, veniva preparato per garantire la persistenza sui sistemi compromessi.

Un server in Hong Kong, tre directory aperteL’infrastruttura ruota attorno all’indirizzo 43.246.208[.]207, allocato da AS132883 (TOPIDC, Hong Kong). Non è un server anonimo qualsiasi: Hunt.io lo classifica ad alto rischio perché in passato ha ospitato un controller ShadowPad, e al momento dell’analisi serviva anche un server C2 VShell sulla porta 21083. Un solo dominio, redhatupdating432.dnsrd[.]com, risolveva verso l’host, ma la sua presenza precede l’attività osservata, che i ricercatori collocano tra fine giugno e i primi di luglio 2026.

Sul server sono state trovate tre directory aperte in rapida successione: il 9 luglio (145 file, tra cui exploit per diverse CVE, script per attacchi alle caselle di posta del ministero e i primi log di Hermes), il 10 luglio (62 eseguibili Go compilati per Windows e Linux, incluso l’impianto Hades) e una terza il 13 luglio. Un pivot sui certificati TLS — tutti con Common Name “www” ma organizzazioni emittenti rotanti come “Web Services” o “Cloud Platform”, uniti dalla stessa impronta JA4X — ha permesso di collegare altri due host alla stessa infrastruttura: uno in Malesia (118.107.222[.]232) e un secondo a Hong Kong (202.181.27[.]115), quest’ultimo usato come nodo C2 secondario per Hades.

Hermes: l’agente che ha fatto il lavoro sporcoHermes è un agente IA open source pubblicato a febbraio 2026, capace di funzionare come demone persistente con memoria tra sessioni, e ha da tempo superato le 140.000 stelle su GitHub, diventando uno dei framework agentici più diffusi. Tra le sue modalità operative c’è “YOLO”, che elimina le richieste di conferma umana prima di eseguire comandi potenzialmente pericolosi — esattamente l’impostazione che l’operatore ha scelto di attivare.

Nella directory hermes-results recuperata il 9 luglio, Hunt.io ha trovato cinque file di log (schema call_00_[ID].txt) che documentano l’agente al lavoro: una prima scansione LinPEAS per la valutazione dell’escalation di privilegi, una seconda esecuzione LinPEAS per l’enumerazione dei servizi, una ricerca di binari SUID/SGID, un’enumerazione di container e file system (con numerosi errori di broken pipe, segno che l’agente produceva più output di quanto il server riuscisse a gestire) e, infine, una ricerca ricorsiva nella web root collegata all’ufficio del Segretario Permanente del ministero, dove ha esposto documenti Office, moduli di valutazione del personale e archivi risalenti al 2012.

Lo script LinPEAS fornito all’agente era stato personalizzato per verificare tre CVE Linux del 2026: CVE-2026-43503 (“DirtyClone”), CVE-2026-31431 (“Copy Fail”, nel modulo algif_aead) e CVE-2026-43284/CVE-2026-43500 (“Dirty Frag”), tutte vulnerabilità locali di privilege escalation nel kernel Linux. Un file di configurazione recuperato mostra inoltre l’indirizzo IP del client SSH usato per operare l’agente, 103.97.0[.]57 (AS133073, Hong Kong), un quarto nodo dell’infrastruttura dell’attaccante.

Il pannello web di Hermes espone un fingerprint HTTP riconoscibile — header Server: HermesWebUI, realm Basic-auth “Hermes WebUI” — che ha permesso a Hunt.io di censire i pannelli esposti in rete: quasi 5.900 eventi nell’ultimo mese. Un secondo pivot sul percorso predicibile /hermes-results/call_*.txt ha restituito 575 directory con output dell’agente pubblicamente accessibili senza autenticazione, un’indicazione che l’uso “disattento” di questi agenti da parte di altri operatori è tutt’altro che isolato.

Hades: l’impianto che tiene il terrenoSe Hermes ha fatto l’enumerazione, il lavoro di persistenza è affidato a Hades, un impianto Go inedito individuato nella directory del 10 luglio insieme a 62 binari compilati per Windows (PE) e Linux (ELF), molti dei quali mascherati da processi di sistema legittimi — ctfmon, csrss, conhost, MicrosoftEdgeUpdate su Windows; kworker, multipathd, accounts-daemon su Linux. Alcuni file, come hades_linux_amd64 e hades_windows_amd64, portano invece il nome del progetto e sembrano fungere da template.

L’analisi statica e dinamica dei due campioni recuperati (uno per piattaforma) conferma che condividono lo stesso codebase. Tra le funzionalità di sicurezza operativa integrate: un kill-date configurabile (variabile d’ambiente HADES_KILLDATE) e un orario di lavoro programmato, che tiene il beacon “addormentato” fuori da una finestra oraria configurata per ridurre le probabilità di essere rilevato. Sul lato tecniche, il malware usa process hollowing su svchost.exe per il caricamento riflessivo del PE, persistenza via chiave di registro Run e task pianificati su Windows (cron su Linux), comunicazione HTTPS su percorsi URI camuffati da asset statici, e include capacità di screenshot basate su GDI. Il nome — nella mitologia greca Hermes accompagna le anime nell’Ade — è probabilmente una scelta non casuale dell’operatore.

Il bersaglio: Hadoop, Hive e credenziali di postaGli script e i file di configurazione recuperati fanno riferimento a sistemi del Ministero delle Finanze per nome host e indirizzo interno: un pannello amministrativo web, un cluster big-data Apache Hadoop e la relativa piattaforma di gestione Ambari, tutti su IP non instradabili — un livello di conoscenza della topologia interna che suggerisce una fase di ricognizione precedente non documentata nei file recuperati. Tra gli artefatti anche una web shell PHP camuffata da file di cache di sistema, tunnel HTTP suo5, e script Perl/Python per attacchi di password spraying contro l’infrastruttura di posta ministeriale con wordlist mirate. File di cookie jar mostrano inoltre token di sessione e CSRF sottratti da un pannello amministrativo e da una piattaforma di document management interna.

Cookie di sessione attivi, webshell distribuite e accesso alla rete interna indicano che l’operatore è riuscito a compromettere più sistemi all’interno della rete del MOF. Il vettore di accesso iniziale, tuttavia, resta sconosciuto: non è emerso dai documenti analizzati. Hunt.io e Diachenko hanno notificato il CERT nazionale thailandese e la National Cyber Security Agency (NCSA) il 15 luglio, ricevendo conferma di presa in carico lo stesso giorno; la pubblicazione della ricerca è stata trattenuta per la consueta finestra di disclosure di 7 giorni. Al momento della scrittura il ministero non ha confermato la violazione.

Due righe per i difensoriIl dato tecnico più interessante non è la singola vulnerabilità sfruttata, ma la combinazione: un agente IA che coordina l’enumerazione e la scoperta di privilege escalation, un impianto cross-platform con opsec dedicata che tiene l’accesso, e tooling scritto su misura per un bersaglio specifico. Per i team di sicurezza, Hunt.io suggerisce interventi molto concreti: rivedere la modalità di autenticazione di HiveServer2 (il default NONE accetta qualunque credenziale via SASL PLAIN), applicare la blocklist delle UDF Hive, effettuare audit ricorsivi delle web root alla ricerca di file PHP con nomi “a punto” che imitano cache di sistema, aggiornare sudo alla 1.9.5p2 e verificare la presenza di CVE-2021-4034 (PwnKit), disabilitare WebDAV su eventuali istanze IIS 6.0 residue, e soprattutto allertare su connessioni in uscita da processi web server verso porte interne come 10000 o 50070 — un web server che raggiunge un nodo Hadoop è di per sé un segnale forte.

Più in generale, il caso conferma una tendenza che i team di threat intelligence osservano da mesi: gli agenti IA “agentic” stanno diventando un moltiplicatore di forza per operatori anche non particolarmente sofisticati, capaci di automatizzare fasi di post-exploitation che un tempo richiedevano ore di lavoro manuale. E, come dimostra la scoperta di 575 directory /hermes-results/ esposte pubblicamente, la fretta con cui questi strumenti vengono dispiegati genera essa stessa nuove superfici di esposizione per chi li usa.

Indicatori di compromissione[Infrastruttura di rete]
43.246.208[.]207 - AS132883 TOPIDC, Hong Kong - server con directory aperte (9/10/13 luglio)
103.97.0[.]57 - AS133073 HK Kwaifong Group, Hong Kong - client SSH verso il server di staging
118.107.222[.]232 - AS55720 The Gigabit, Malaysia - overlap certificato TLS 'www'
202.181.27[.]115 - AS134196 Converged Communications, Hong Kong - overlap certificato TLS 'www'
redhatupdating432.dnsrd[.]com - dominio storicamente risolto verso 43.246.208[.]207
[Hash SHA-256]
linux_amd64 (VShell stage 1, Linux): 0f8c905aa25c86f85454acb7e77bf5c50220c2a82e5b69a33741e55c8a85f2fc
windows_amd64.exe (VShell stage 1, Win): a9447ae174f4aa54f760b7d7cc985c1a970f31e151d3ff66fac247f99ba1b509
linux_amd64 (VShell stage 2, Linux): ec7e9ab43a0cc65d29f0b84a93ba88c43d01fed3dec5c968525dc73c03cbfda2
windows_amd64.exe (VShell stage 2, Win): b65b7ede835ebba36294d52d7780065523340ee09bb8b209ef2dc495e53dfd53
multipathd_04d0 (Hades, Linux): d252ee7b348b7e43e432d8fb154465838f5cd5fb564905323460e6f0a0c7d1e2
dwm_33b7.exe (Hades, Windows): c74010aa82e8164c8d4ca9e073ec6b9a762e53db67498b22f5ccaef3a82853f
[Configurazione Hades]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Check-in: /assets/app.min.js
Tasking: /assets/vendor.js
Result upload: /assets/main.js
Env var: HADES_KILLDATE (kill-date operativo)
[CVE sfruttate per privilege escalation nello script LinPEAS custom]
CVE-2026-43503 (DirtyClone) - LPE kernel Linux
CVE-2026-31431 (Copy Fail, modulo algif_aead) - LPE kernel Linux
CVE-2026-43284 / CVE-2026-43500 (Dirty Frag) - LPE via page-cache write
CVE-2021-3156 (sudo heap overflow) e CVE-2021-4034 (PwnKit) - exploit staged sul server
[Fingerprint per rilevare pannelli Hermes esposti]
Header: Server: HermesWebUI
Basic-auth realm: "Hermes WebUI"
Percorso output: /hermes-results/call_*.txt
Porta osservata sul server di staging: 8878Fonti: Hunt.io (“Thailand’s Ministry of Finance Targeted With Hermes AI Agent Running Unattended, Hades Implant Staged”), BleepingComputer, The Hacker News, Security Affairs.

C’è un momento in cui un’operazione di ransomware smette di essere un pugno di script e diventa un’azienda vera e propria, con reparti, scadenze e un pannello di controllo. Per il gruppo Funky Mantis, noto anche come DevMan, quel momento è arrivato tra la fine del 2025 e il gennaio 2026, quando la sua infrastruttura di attacco si è trasformata in una piattaforma centralizzata capace di gestire più operazioni contemporaneamente, con tanto di CRM interno per tracciare vittime, curatori e pagamenti attesi. A ricostruirlo sono stati gli analisti di Catalyst/Prodaft, che hanno esaminato due versioni del pannello web del gruppo e trovato indizi che l’infrastruttura sia stata usata in almeno un attacco reale.

Da toolkit a piattaforma “as-a-service”Funky Mantis opera secondo il modello ormai classico del ransomware-as-a-service: gli amministratori mantengono un’infrastruttura chiusa a cui gli affiliati accedono per ottenere accesso a reti già compromesse, generare versioni del malware, negoziare con le vittime e monitorare i pagamenti. Quello che distingue questa gang è la maturità del tooling gestionale. La prima versione del pannello, osservata a fine 2025, offriva già funzioni per creare varianti del malware, una sezione finanziaria, una chat diretta con le vittime e supporto tecnico per gli affiliati in difficoltà.

A gennaio 2026 è comparsa una seconda versione, con un sistema di contabilità molto più sofisticato: gli operatori possono creare team, assegnare partecipanti a specifici bersagli, tracciare lo stato di ogni attacco, le scadenze di pagamento e l’incasso atteso per ciascuna vittima. È, di fatto, un CRM per l’estorsione, che permette di coordinare più campagne parallele da un’unica cabina di regia — la stessa logica organizzativa di una software house legittima, applicata alla gestione degli attacchi ransomware su scala.

Cosa rivelano le chat interneI ricercatori hanno avuto accesso a messaggi privati scambiati tra i partecipanti al programma, che mostrano l’organizzazione interna del gruppo: gli amministratori distribuiscono l’accesso a reti compromesse in diversi paesi, assegnano “curatori” (curator) che supervisionano gli affiliati e impongono scadenze strette, spesso di pochi giorni, per portare a termine l’attacco. Nelle conversazioni ricorrono riferimenti a organizzazioni del settore sanitario, infrastrutture critiche, ambito commerciale ed enti governativi. È interessante notare che, in alcuni casi, gli affiliati si limitano a dichiarare un attacco riuscito senza che i ricercatori abbiano potuto confermarne l’effettivo esito — un promemoria che, nell’ecosistema RaaS, la vanteria fa parte del modello di business quanto il cifrario stesso.

Il cifrario: ChaCha20-Poly1305 e la caccia ai sistemi medicaliSul piano tecnico, gli analisti hanno esaminato la variante Windows del cifrario. Il programma verifica i privilegi di amministratore, tenta di disattivare le protezioni native di Windows, arresta servizi specifici, elimina le shadow copy di sistema per impedire il ripristino, enumera le risorse di rete raggiungibili e cifra i file sia sui dischi locali sia sugli storage connessi. Al termine dell’esecuzione rilascia una nota di riscatto e, in alcune configurazioni, può autoeliminare il proprio eseguibile per ostacolare l’analisi forense successiva.

La cifratura utilizza l’algoritmo ChaCha20-Poly1305 e aggiunge ai file colpiti l’estensione .devman21 — dettaglio che conferma il legame con l’alias DevMan con cui il gruppo è tracciato in altre fonti. Il malware è chiaramente orientato all’ambiente corporate: tra i bersagli figurano documenti, database, backup, macchine virtuali, codice sorgente e, soprattutto, file collegati a sistemi medicali. Gli operatori promuovono separatamente attacchi contro infrastrutture critiche e offrono funzionalità dedicate per colpire sistemi di controllo industriale, segnalando un’ambizione che va oltre la crittografia opportunistica di file server aziendali.

Un punto resta però non confermato: se il gruppo eserciti davvero double extortion con esfiltrazione dei dati. Il servizio pubblicizza questa capacità nei materiali promozionali rivolti agli affiliati, ma gli analisti non hanno trovato né strumenti di exfiltration né tracce concrete di trasferimento file verso l’esterno. È possibile che si tratti, almeno in parte, di una promessa commerciale non ancora del tutto implementata — un dettaglio che i difensori non dovrebbero comunque dare per scontato in fase di risposta all’incidente.

Come rilevarlo: TTP invece di hashIl consiglio più utile che arriva dalla ricerca di Catalyst Prodaft riguarda l’approccio alla detection. Data la velocità con cui varianti e hash del cifrario possono cambiare tra un affiliato e l’altro, gli analisti raccomandano di non basare il rilevamento su file isolati o firme statiche, ma sulla sequenza di azioni tipica di un attacco in preparazione. Tra gli indicatori comportamentali da monitorare: accessi remoti anomali, uso successivo di account con privilegi elevati, attività insolita su condivisioni SMB, modifiche alle Group Policy, disattivazione di meccanismi di protezione endpoint e cancellazione di meccanismi di recupero come le shadow copy. Questo approccio “TTP-first” consente di intercettare la fase di preparazione dell’attacco prima ancora che il cifrario venga effettivamente distribuito, quando le opzioni di risposta sono ancora molte.

Per i team di sicurezza che operano in ambito sanitario o industriale, il caso Funky Mantis è un altro segnale che il ransomware-as-a-service sta convergendo verso modelli operativi sempre più simili a normali strumenti SaaS di project management — il che, paradossalmente, li rende anche più prevedibili da un punto di vista comportamentale, se si sa dove guardare.

Indicatori di compromissioneGruppo: Funky Mantis (alias DevMan)
Modello: Ransomware-as-a-Service (RaaS) con pannello CRM per affiliati

Estensione file cifrati: .devman21
Algoritmo di cifratura: ChaCha20-Poly1305

Comportamenti osservati (Windows):

• Verifica privilegi amministrativi
• Tentativo di disattivazione delle protezioni Windows native
• Arresto di servizi specifici prima della cifratura
• Cancellazione delle shadow copy di sistema (inibizione del recovery)
• Enumerazione risorse di rete/condivisioni SMB
• Cifratura di dischi locali e storage connessi
• Possibile autoeliminazione del binario a fine esecuzione

Settori target: sanità (sistemi medicali), infrastrutture critiche/ICS,
ambito commerciale, enti governativi

Indicatori comportamentali da monitorare (TTP-first, non solo hash):

• Accesso remoto anomalo seguito da uso di account privilegiati
• Attività insolita su SMB / enumerazione di condivisioni di rete
• Modifiche alle Group Policy
• Disattivazione di strumenti di protezione endpoint
• Cancellazione di shadow copy o altri meccanismi di recupero dati

Fonte primaria: Catalyst Prodaft, "Funky Mantis platform: coordination and locker analysis"

Sui forum underground si vende come “il crypter più letale del sottosuolo”. Cruciferra, in vendita dall’autunno 2025 su Exploit[.]in a partire da 450 dollari al mese fino a 2.000 per la versione completa, non è l’ennesimo offuscatore di malware: secondo un’analisi pubblicata da Proofpoint il 20 luglio, il servizio combina disattivazione degli EDR via driver vulnerabili, syscall indiretti, un motore di cifratura polimorfico con oltre 90 combinazioni di algoritmi e una variante custom della tecnica di Process Ghosting. Il risultato è un payload che gira in memoria senza mai esistere in forma scansionabile su disco.

Un “umbrella service” per decine di gruppi criminali scollegati tra loroCruciferra non è legato a un singolo attore: Proofpoint lo descrive come un servizio “ombrello”, utilizzato in decine di campagne indipendenti per proteggere payload molto diversi tra loro, da AsyncRAT e Agent Tesla a Remcos, XWorm, zgRAT, Formbook/XLoader, DarkCloud Stealer, Phantom Stealer, Snake Keylogger e ValleyRAT. Scritto in Mono, il crypter viene sempre eseguito tramite DLL side-loading: la vittima scarica un archivio contenente un eseguibile legittimo in apparenza e una DLL malevola, che viene caricata automaticamente al lancio del programma principale.

Tra i clienti identificati da Proofpoint figura TA4922, gruppo cinese di cybercrime già noto per l’espansione delle proprie campagne a livello globale. Tra fine aprile e inizio giugno 2026, TA4922 ha condotto almeno quattro campagne da poche centinaia di email ciascuna, con esche a tema fiscale che impersonavano l’Income Tax Department indiano per convincere le vittime a scaricare archivi ZIP contenenti il loader di AsyncRAT. Altre campagne osservate hanno sfruttato notifiche fasulle della Social Security Administration statunitense per distribuire XWorm e AdaptixC2 tramite file VHD, mentre una campagna di fine giugno ha usato reclami di ospiti su presunte cimici da letto per colpire il settore alberghiero con zgRAT.

Come Cruciferra acceca gli EDRPrima ancora di eseguire il payload finale, Cruciferra dedica gran parte del proprio codice a rendersi invisibile agli strumenti di analisi e difesa. Il DLL principale contiene spesso centinaia o migliaia di funzioni esportate fittizie che puntano a codice spazzatura: solo una manciata di export porta effettivamente al codice malevolo, rendendo più difficile per un analista o un sandbox individuare il punto di ingresso reale. Il malware nasconde poi le finestre di console che potrebbero tradire un’infezione, tramite un thread in background che scandisce ripetutamente l’albero dei processi cercando finestre di classe “ConsoleWindowClass” da occultare con ShowWindow e SetWindowPos.

Sul fronte della telemetria, Cruciferra applica un unhooking sistematico delle funzioni monitorate da EDR e antivirus, ripristinando una copia pulita delle DLL di sistema in memoria per rimuovere gli hook installati dai prodotti di sicurezza. Ricorre inoltre a syscall indiretti: legge una copia pulita di ntdll.dll dal disco e ne conserva gli stub in una struttura globale, così da invocare le API senza passare dagli hook inline che gli EDR installano solitamente su ntdll.dll. A completare il quadro, il malware ripara anche eventuali hook sulla Import Address Table (IAT), una tecnica più datata ma qui reintrodotta deliberatamente, e disabilita le notifiche di sistema modificando chiavi di registro come ToastEnabled e Balloon, per impedire che Windows Defender o il Security Center mostrino avvisi visibili all’utente.

BYOVD: un driver forense trasformato in killer di EDRL’elemento più aggressivo del crypter è l’abuso di driver kernel legittimi ma vulnerabili, tecnica nota come Bring-Your-Own-Vulnerable-Driver (BYOVD). Cruciferra rilascia sul sistema un “helper driver” firmato digitalmente, spesso il driver GoFlyDrv.sys, e lo usa per inviare comandi IOCTL a basso livello che terminano i processi degli agenti EDR individuati scandendo la lista dei processi attivi. In alternativa, gli analisti hanno osservato anche altri driver impiegati con la stessa logica: Core64.sys, HwOs2Ec.sys, LnvMSRIO.sys, MemoryInformer.sys, NTIOLib_X64.sys, ProcessMonitorDriver.sys e selfprot.sys. Trattandosi di driver firmati da produttori legittimi (spesso strumenti diagnostici o di manutenzione hardware), Windows li carica senza obiezioni nonostante le vulnerabilità note che permettono di trasformarli in armi contro gli stessi prodotti di sicurezza che dovrebbero fermarli.

Per elevare i propri privilegi quando non gira già come amministratore, Cruciferra sfrutta inoltre il bypass dello User Account Control tramite COM Elevation Moniker, e garantisce la persistenza scrivendo una voce denominata “putty” nella chiave di registro Run, così da rieseguirsi automaticamente a ogni riavvio del sistema.

Process Ghosting “potenziato”: nessun file da scansionarePer l’esecuzione finale del payload, Cruciferra adotta una variante della tecnica di Process Ghosting: crea un file temporaneo, lo marca per l’eliminazione tramite NtSetInformationFile, vi scrive il payload malevolo, quindi crea una sezione immagine con NtCreateSection e SEC_IMAGE prima di chiudere l’handle. Il file viene cancellato dal disco dal sistema operativo, ma la sezione di memoria che lo rappresenta resta viva; un processo legittimo viene poi creato in stato sospeso, la sezione “fantasma” vi viene mappata tramite NtMapViewOfSection, e il contesto del thread viene reindirizzato al vero punto di ingresso del payload prima di riprendere l’esecuzione. Il risultato è un processo in esecuzione supportato da un’immagine PE che non è mai esistita su disco in una forma analizzabile.

Cruciferra aggiunge due ulteriori accorgimenti a questa tecnica, già di per sé insidiosa: applica una patch a ZwQueryVirtualMemory in modo che, quando un EDR interroga la regione di memoria “fantasma”, riceva una risposta manipolata che nasconde l’anomalia del file cancellato; e neutralizza NtManageHotPatch, funzione che il sistema operativo può usare per validare l’integrità delle sezioni immagine caricate rispetto al file su disco che le supporta, impedendo così qualunque verifica di coerenza da parte del kernel.

Crittografia su misura: oltre 90 algoritmi ricombinatiIl payload viene conservato nella sezione “.reloc” del binario, codificato in Base16 con un set di caratteri personalizzato, e protetto da uno delle oltre 90 varianti di algoritmi crittografici che Cruciferra può generare combinando componenti presi da cifrari e generatori di numeri pseudocasuali noti: Keccak (SHA-3), convoluzione ciclica, reti Feistel generalizzate, SPECK-128/256 in modalità CTR, PRNG multiply-accumulate, una versione modificata di Threefish-256, combinazioni Xorshift64/middle-square e diverse varianti ARX (Addition-Rotation-XOR). L’unico algoritmo standard rimasto intatto è DES-CBC-PKCS7. Questo approccio “bring your own crypto” rende ogni campione sostanzialmente unico dal punto di vista crittografico, complicando enormemente il rilevamento basato su firme statiche.

Un dettaglio utile ai difensori: i metadati “File Version Information” dei binari generati da Cruciferra contengono spesso stringhe casuali generate combinando due o quattro parole a caso (ad esempio “2026 Colpoplastric Semipreactical Group” nei campi Copyright, Product e Description), un pattern che, unito a firme YARA mirate, ha permesso a Proofpoint di tracciare su VirusTotal nuove build del crypter caricate a intervalli di pochi minuti, segno di un servizio in sviluppo attivo e continuo.

Due righe per i difensoriBloccare il caricamento dei driver kernel noti come vulnerabili tramite la lista di blocco di Microsoft (HVCI/driver blocklist) e strumenti come LOLDrivers, includendo GoFlyDrv.sys e gli altri driver associati a Cruciferra.

Monitorare la creazione di sezioni immagine da file marcati per l’eliminazione (NtCreateSection su file con delete-pending) come indicatore di Process Ghosting, oltre a chiamate anomale a NtManageHotPatch.

Verificare la presenza della chiave di persistenza “putty” nel Run key del registro, un IOC comportamentale a basso costo di rilevamento.

Applicare filtri anti-phishing rafforzati sulle esche a tema fiscale e previdenziale, particolarmente ricorrenti nelle campagne osservate.

Dare priorità a soluzioni EDR con protezione kernel indipendente dal proprio agente in user-mode, per resistere a tecniche BYOVD che colpiscono direttamente il processo dell’agente.

Cruciferra conferma una tendenza ormai consolidata nel malware-as-a-service: la sofisticazione tecnica un tempo riservata agli APT state-sponsored è oggi acquistabile con un abbonamento mensile, e la vera barriera all’ingresso per il cybercrime commodity non è più scrivere codice evasivo, ma semplicemente pagare chi lo ha già scritto.

IoC# Driver BYOVD abusati da Cruciferra (SHA-256)
Core64.sys 17aae57cf6255c7eb169bf62ea67376d9708976eb7831f8cdd0ea38bdcb37dc4
GoFlyDrv.sys 2fdfdd13a0c548bb68c9d5aa8599a9265d4659da3e237fe7a42ac6ac06b9a06a
HwOs2Ec.sys c4e93449453cf67c5d5605bb8f425207a738a242fdb432d720acc32faa74926c
LnvMSRIO.sys c5b1e9aafc8f2b4ab05effc00fd43f3114b9ef1d592a086c952793ac4e299809
MemoryInformer.sys 7887e919555fb5948c217556ba149392a72982b1bc427d3db779db9dcbf09ee8
NTIOLib_X64.sys 09bedbf7a41e0f8dabe4f41d331db58373ce15b2e9204540873a1884f38bdde1
ProcessMonitorDriver.sys 5b4f59236a9b950bcd5191b35d19125f60cfb9e1a1e1aa2e4f914b6745dde9df
selfprot.sys c46e907886e2158cbc453e767183aecf07887b5ac8848f19684451883d69f5f0

Campagna TA4922 / Cruciferra / AsyncRAT

hxxp://hsahyteiows[.]gu[.]cc
hxxp://yicoweytcbtw[.]gu[.]cc
hxxp://xkcifgieusr[.]gu[.]cc
hxxp://fuaytrwese[.]love
3c181f642e24c28602a87be7f195e2f3d1ffa30b37e20f5121d99f88b22ab80e (Tax-Number52563.zip, SHA256)
66dbe675480dc229e5b3ab8ad74207f73486e64e57805074f784bb2e01bcb865 (Tax-Number809863.zip, SHA256)

Campagna XWorm

gatuso[.]duckdns[.]org (C2)

Campagna zgRAT

digital-magicians[.]com/photo295825092412[.]zip (Payload URL)
0zbqnac1t4dv2t2wuodv1m[.]com (C2)
89[.]34[.]90[.]99:56001 (C2)

Persistenza

Registro: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\putty

Cl0p torna a colpire dove sa fare più male: non un endpoint qualsiasi, ma il software che tiene insieme la catena di progettazione e produzione di centinaia di aziende manifatturiere, automotive, aerospaziali e di abbigliamento. La gang, la stessa che ha reso celebri gli attacchi di massa contro MOVEit, GoAnywhere MFT e Accellion FTA, sta ora sfruttando una falla critica in PTC Windchill e FlexPLM per ottenere accesso non autenticato, installare webshell e avviare campagne di estorsione su scala industriale.

Un bersaglio scelto con cura: il PLM come infrastruttura critica invisibileWindchill è la piattaforma di Product Lifecycle Management (PLM) di PTC usata da produttori e ingegneri per gestire distinte base, disegni CAD, cicli di revisione e conformità normativa. FlexPLM è la sua controparte pensata per retail, abbigliamento, calzature e beni di consumo. Sono, in sostanza, il “sistema nervoso” della progettazione di prodotto: chi compromette Windchill non ruba solo dati, ottiene la proprietà intellettuale che tiene in piedi intere linee produttive, spesso condivise con fornitori e terze parti a valle della catena. È esattamente il tipo di software “orizzontale ma invisibile” che Cl0p ha sempre preferito, sul modello già visto con MOVEit nel 2023: individuare una falla in un prodotto enterprise diffuso, sfruttarla in massa prima che le patch si diffondano, poi monetizzare i dati sottratti con estorsioni multiple.

La falla: CVE-2026-12569, CVSS 9.3La vulnerabilità alla base della campagna è un caso di improper input validation legato alla deserializzazione di dati non attendibili in Windchill, che consente a un attaccante remoto e non autenticato di eseguire codice arbitrario con una singola richiesta malformata. Secondo l’advisory diffusa da ricercatori di threat intelligence (ecrime.ch) e ripresa dagli analisti, l’affiliato Cl0p osservato in queste settimane concatena due debolezze distinte: una falla di information disclosure nel WSDL di FlexPLM, che permette di mappare gli endpoint e raccogliere informazioni utili sull’istanza target, e una vulnerabilità nel servlet di login di Windchill, che consente di bypassare l’autenticazione e ottenere RCE. Il risultato è una catena di exploit pienamente “unauthenticated to RCE”, il tipo di primitiva che i gruppi ransomware più organizzati amano weaponizzare in pochi giorni.

PTC ha comunicato la vulnerabilità il 17 giugno 2026, rilasciando le prime patch il giorno successivo dopo aver confermato exploitation attiva in the wild. CISA ha inserito CVE-2026-12569 nel proprio Known Exploited Vulnerabilities (KEV) catalog il 25 giugno, imponendo alle agenzie federali statunitensi la remediation entro il 28 giugno: è la prima vulnerabilità di un prodotto PTC ad entrare nel KEV. In Germania, il BSI e la polizia federale (BKA) hanno avvisato direttamente le aziende esposte già dalla notte del 17 giugno, un déjà-vu rispetto a un’altra vulnerabilità RCE nelle stesse piattaforme (CVE-2026-4681) divulgata a marzo 2026.

Dalla falla alla webshell: la firma operativa dell’attaccoUna volta ottenuta l’esecuzione di codice, gli operatori osservati droppano webshell JSP persistenti seguendo uno schema di naming riconoscibile: file con nome esadecimale a 16 caratteri collocati sotto il percorso di login di Windchill. Da lì gestiscono comandi da remoto, effettuano attività di file-listing (lasciando spesso una traccia in un file temporaneo) ed esfiltrano dati prima di passare alla fase di estorsione, con email inviate direttamente alle organizzazioni colpite nei settori Manufacturing, Automotive, Aerospace e Retail/Apparel. Non risultano, al momento, evidenze pubbliche di deployment di ransomware “classico” con cifratura dei file: lo schema resta quello, tipico di Cl0p dal 2023 in poi, di furto massivo di dati seguito da doppia estorsione senza necessariamente criptare gli ambienti compromessi.

Due righe per i difensori: rischio supply chain, non solo perimetraleIl vero elemento di rischio geopolitico e industriale qui non è la singola azienda compromessa, ma l’effetto a cascata: Windchill e FlexPLM sono spesso condivisi con OEM, fornitori Tier 1 e partner di co-design. Un accesso non autorizzato ai repository PLM significa potenziale esposizione di disegni tecnici, specifiche di materiali, cicli di produzione e roadmap di prodotto — informazioni che hanno valore sia per la criminalità organizzata in cerca di leva estorsiva, sia, in scenari più sensibili (difesa, aerospazio), per attori interessati allo spionaggio industriale. È lo stesso pattern di rischio già visto con gli attacchi a piattaforme di file transfer enterprise: la superficie non è l’endpoint dell’utente, ma il software B2B che nessuno vede ma su cui si regge la produzione.

Applicare immediatamente le patch PTC per Windchill e FlexPLM (rilasciate dal 18 giugno 2026) su tutte le versioni supportate.

Verificare la presenza di webshell nel percorso /Windchill/login/ con nomi esadecimali a 16 caratteri.

Analizzare i log HTTP per richieste POST anomale verso gli endpoint di login e per l’header X-windchill-req.

Bloccare al perimetro gli indirizzi IP noti come infrastruttura di comando e controllo.

Limitare l’esposizione diretta a Internet dell’endpoint di login Windchill dove operativamente possibile, instradando l’accesso tramite VPN o gateway con MFA.

Effettuare un controllo retrospettivo dei log di accesso per individuare eventuali esfiltrazioni avvenute prima della patch.

Indicatori di compromissione# Indirizzi IP associati all'infrastruttura d'attacco
172.111.38.31
216.152.148.54
104.243.35.131
74.50.76.146
5.180.41.35 # C2 - bloccare immediatamente al perimetro

Pattern webshell

/Windchill/login/[0-9a-f]{16}.jsp

Hash file webshell (SHA-256)

55a1eb4c2d3da04376df39d7ba832569c6af1a37a0cf2b95f754ac898023a30c

Marcatore di attivita di file-listing dell'attaccante

/tmp/flst.txt (o nella working directory di Windchill)

Header HTTP sospetto usato dagli operatori

X-windchill-req: *
Per i team di sicurezza che gestiscono ambienti PLM esposti, il messaggio è chiaro: la finestra tra disclosure pubblica e weaponization da parte di gruppi come Cl0p si è ormai ridotta a giorni, non settimane. Chi non ha ancora patchato Windchill o FlexPLM dovrebbe considerare l’ambiente potenzialmente già compromesso e agire di conseguenza, con hunting retroattivo prima ancora del solo deployment della patch.

Duecento server sequestrati, un arresto in Indonesia e oltre 1.800 clienti criminali lasciati improvvisamente senza il loro strumento di lavoro preferito. Con l’Operazione “Olympus Blade”, le autorità tedesche e statunitensi hanno inferto uno dei colpi più duri mai assestati contro l’industria del phishing-as-a-service, smantellando l’infrastruttura di Kratos, la piattaforma che negli ultimi due anni ha permesso a criminali con competenze tecniche minime di colpire centinaia di migliaia di vittime in 35 paesi.

Un kit “chiavi in mano” per rubare account MicrosoftKratos non era un semplice kit di phishing statico, ma una piattaforma completa di Phishing-as-a-Service (PhaaS) venduta in abbonamento e pagabile in criptovaluta. Chi acquistava una licenza riceveva l’accesso a un pannello web e a uno shop su Telegram da cui gestire le proprie campagne, registrare nuovi domini civetta e monitorare le credenziali raccolte in tempo reale. Il prodotto di punta erano pagine di login false, quasi indistinguibili dagli originali, che imitavano i portali di autenticazione Microsoft 365.

La caratteristica che ha reso Kratos particolarmente pericoloso agli occhi degli investigatori tedeschi non era però la semplice raccolta di username e password, ormai capacità minima per qualunque kit di phishing del 2026, ma l’implementazione di tecniche Adversary-in-the-Middle (AiTM). Il kit si interponeva tra la vittima e il vero portale Microsoft, inoltrando le richieste di autenticazione in tempo reale e catturando, oltre alle credenziali, anche i cookie di sessione validi dopo il completamento della MFA. Questo permetteva agli operatori di dirottare sessioni già autenticate, aggirando di fatto l’autenticazione a due fattori senza doverla “rompere” tecnicamente: la si scavalcava semplicemente rubando il token già emesso dal legittimo processo di login.

La scala del danno: 15.000 campagne al meseSecondo la Procura Generale di Francoforte (ZIT) e il Bundeskriminalamt (BKA), che hanno guidato le indagini in collaborazione con l’FBI, Kratos veniva utilizzato da oltre 1.800 clienti criminali per condurre in media 15.000 campagne di phishing al mese, con vittime confermate in almeno 35 paesi, concentrate soprattutto in Europa e Stati Uniti. Gli inquirenti stimano che l’operatore del servizio abbia incassato almeno 300.000 euro dal 2024 a oggi, esclusivamente tramite canoni di abbonamento: una cifra che dà la misura di quanto sia diventato profittevole il modello “as-a-service” applicato al crimine informatico, dove il gestore della piattaforma monetizza l’accesso allo strumento senza dover mai toccare personalmente i dati rubati dai propri clienti.

Il modello di business di Kratos rispecchia da vicino quello di altri kit AiTM emersi negli ultimi anni, come Tycoon2FA ed EvilProxy, confermando una tendenza consolidata: il phishing contro gli account Microsoft 365 aziendali resta uno dei vettori di accesso iniziale più redditizi per i broker di accessi, che poi rivendono le credenziali rubate a gruppi ransomware o le usano per frodi sul Business Email Compromise.

L’operazione: da Francoforte a GiacartaL’azione di contrasto, ribattezzata Operation Olympus Blade, ha coinvolto il sequestro di oltre 200 server usati per ospitare l’infrastruttura di distribuzione e le pagine di phishing generate dai clienti della piattaforma. Sul sito ufficiale di Kratos è comparso un banner di sequestro che informa gli utenti del trasferimento della proprietà del dominio all’FBI, prassi ormai standard nelle operazioni congiunte USA-Europa contro le infrastrutture criminali online.

La parte più significativa dell’operazione, dal punto di vista dell’attribuzione, è però l’arresto in Indonesia dello sviluppatore e amministratore tecnico della piattaforma. Si tratta di un elemento tutt’altro che scontato: la maggior parte dei kit PhaaS che vengono smantellati porta al sequestro dell’infrastruttura, ma raramente all’identificazione fisica e alla cattura di chi ne cura lo sviluppo, spesso protetto da più livelli di anonimizzazione e da rivenditori intermedi che fanno da schermo. La collaborazione tra BKA, FBI e le autorità indonesiane suggerisce un lavoro di attribuzione durato mesi, probabilmente basato sull’analisi dei flussi di pagamento in criptovaluta e sulla correlazione tra gli account amministrativi della piattaforma e l’identità reale del suo operatore.

Due righe per i difensoriIl takedown di Kratos rimuove un attore significativo dall’ecosistema PhaaS, ma non elimina la tecnica sottostante. Le organizzazioni che si affidano a Microsoft 365 dovrebbero considerare questo caso un promemoria per rivedere le proprie difese contro il phishing AiTM, che per definizione bypassa l’MFA basata su codici OTP o push notification semplici:

Adottare chiavi di sicurezza hardware FIDO2/WebAuthn o passkey, le uniche forme di MFA resistenti al furto di sessione tramite AiTM, poiché legano l’autenticazione all’origine del dominio.

Abilitare policy di Conditional Access che valutino segnali di rischio come token replay da IP o dispositivi anomali rispetto alla sessione originale di login.

Configurare la durata dei token di sessione e i criteri di revoca automatica in caso di cambio di posizione geografica o fingerprint del dispositivo.

Monitorare i log di Entra ID / Azure AD per pattern di accesso anomali, come login riusciti seguiti da immediata modifica delle regole di inoltro della posta, tipica fase successiva al furto di sessione.

Diffidare di email che rimandano a portali di login Microsoft con URL leggermente anomali o hosting su domini di terze parti, anche quando la pagina è visivamente identica all’originale.

Resta inoltre da chiedersi quanti cloni o eredi diretti di Kratos emergeranno nei prossimi mesi: la storia recente dei takedown PhaaS, da 16shop a Caffeine, mostra che la domanda di questi kit da parte della criminalità di basso profilo non si esaurisce con la cattura di un singolo operatore, ma semplicemente si sposta verso il prossimo servizio disponibile sui forum underground e sui canali Telegram dedicati.

Un impianto di spionaggio finora sconosciuto ha trasformato uno degli strumenti più banali della vita d’ufficio, il calendario di Microsoft 365, in un canale di comando e controllo. Si chiama HollowGraph, non sfrutta alcuna vulnerabilità software e per questo è quasi impossibile da rilevare con i controlli di rete tradizionali: il traffico che porta gli ordini dell’attaccante e i file rubati è, a tutti gli effetti, traffico legittimo verso le API di Microsoft Graph.

A scoprirlo è stata Group-IB, che ha pubblicato l’analisi tecnica il 20 luglio 2026 dopo aver individuato l’impianto su almeno 12 macchine compromesse, di cui solo tre attivamente in comunicazione con l’attaccante durante la finestra di osservazione. Il traffico della vittima analizzata copre il periodo dal 3 giugno al 9 luglio 2026, e la casella di posta usata per l’esfiltrazione appartiene a un’organizzazione israeliana. Un’impronta piccola e selettiva, che i ricercatori leggono come spionaggio mirato piuttosto che criminalità opportunistica, anche se la tecnica potrebbe essere riutilizzata su scala molto più ampia.

Il calendario come dead dropHollowGraph è una DLL .NET che supporta solo due comandi, get e send, e non contatta mai direttamente un server dell’attaccante per ricevere istruzioni. Al loro posto usa il calendario della casella compromessa come dead drop bidirezionale: per ricevere i comandi, interroga un evento specifico piazzato dall’operatore e datato 2050-05-13, una data così lontana nel futuro che nessun utente lo scoprirebbe mai scorrendo la propria agenda, e ne legge le istruzioni da un file allegato.

Per l’esfiltrazione il processo si inverte: il malware cifra il file rubato, crea un proprio evento altrettanto lontano nel tempo e carica i dati come uno o più allegati. L’intero scambio è protetto da uno schema ibrido RSA più AES-256, con coppie di chiavi separate per il canale di comando in entrata e per quello di esfiltrazione in uscita. Chi osservasse solo i log di rete vedrebbe esclusivamente chiamate alle API Microsoft Graph, indistinguibili dal traffico generato da un client Outlook qualsiasi.

Il secondo canale: DNS tunneling per restare viviPerché l’accesso a Graph resti valido nel tempo, HollowGraph mantiene un secondo canale, più grezzo ma altrettanto insidioso. Via DNS, il malware aggiorna periodicamente le credenziali dell’applicazione registrata su Entra ID (Azure AD): tenant ID, client ID, client secret e la casella di posta bersaglio. Questi valori vengono decodificati da record AAAA IPv6 restituiti da un dominio controllato dall’attaccante, cloudlanecdn[.]com, e scritti in un file camuffato da log di routine, logAzure.txt. A differenza del traffico sul calendario, qui le credenziali applicative viaggiano in chiaro, il che rende questo canale un punto di osservazione prezioso per i difensori.

Chi c’è dietro: Cavern e l’ombra di TeheranGroup-IB collega HollowGraph al framework backdoor modulare Cavern con alta confidenza, sulla base della sintassi di comando condivisa e di corrispondenze nella logica di tasking interna. Cavern era stato documentato all’inizio di luglio da Check Point, che lo ha attribuito a un cluster legato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) soprannominato Cavern Manticore, con sovrapposizioni note verso i gruppi iraniani MuddyWater e Lyceum.

Il legame però riguarda il codice, non necessariamente l’operatore di questa specifica campagna: Group-IB è stata esplicita nel dire di non poter attribuire con sicurezza questa attività a un attore già noto, segnalando solo una sovrapposizione a bassa confidenza con Lyceum, sottogruppo dell’iraniano OilRig. La geografia della vittima, un’organizzazione israeliana, viene trattata dai ricercatori come dato sul bersaglio e non come prova di attribuzione.

Va detto che nascondere il comando e controllo dentro servizi Microsoft fidati non è una novità assoluta: caselle Outlook, cartelle bozze e OneDrive sono già stati abusati in passato con logiche simili. Ciò che rende HollowGraph interessante è aver scelto l’angolo cieco più remoto possibile, un evento di calendario piantato 24 anni nel futuro, in un momento in cui la difesa si concentra sempre di più sul monitoraggio delle identità cloud e delle applicazioni OAuth piuttosto che sui contenuti stessi delle caselle di posta.

Perché conta per i difensoriNon c’è una vulnerabilità Microsoft da patchare: HollowGraph vive su un account compromesso e sulle normali funzionalità dell’API Graph, il che è esattamente ciò che lo rende difficile da individuare. Il lavoro va fatto sul piano dell’identità e dei permessi applicativi, non su quello delle patch. Group-IB raccomanda di restringere e verificare le applicazioni OAuth con credenziali client che possono raggiungere Graph, allertare sulla creazione di nuovi client secret e applicare la consueta igiene su Entra ID: Conditional Access, rotazione delle credenziali e rilevamento di token anomali.

Cercare eventi di calendario con data remota 2050-05-13

Verificare oggetti che siano un GUID nudo o seguano schemi tipo Event ID: o Boss{..}ID{..}

Individuare allegati con nome File{n}.txt

Auditare le modifiche al calendario generate da un’applicazione anziché da una persona (eventi creati, allegati caricati, oggetti rinominati via app)

Monitorare query DNS AAAA insolitamente frequenti verso un singolo dominio, con sottodomini lunghi e ad alta entropia

Cercare il dominio cloudlanecdn[.]com e il file di configurazione logAzure.txt

L’operatore dietro questa campagna resta senza nome, e il traffico della vittima risultava ancora attivo il 9 luglio. Vale la pena controllare fin da ora quegli eventi datati nel remoto futuro: è esattamente lì che nessun analista avrebbe mai pensato di guardare.

Indicatori di compromissioneDominio C2 (DNS tunneling): cloudlanecdn[.]com
File di configurazione: logAzure.txt
Evento calendario esca: data 2050-05-13
Pattern oggetto evento: GUID nudo / "Event ID:" / "Boss{..}ID{..}"
Allegati di comando: File{n}.txt
Framework correlato: Cavern (Cavern Manticore / MOIS-linked, overlap MuddyWater e Lyceum)
Finestra di attività osservata: 3 giugno - 9 luglio 2026
Set completo di IoC e hash: report tecnico Group-IB, "HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels"

Si parla di:

Toggle

Per quasi due anni un gruppo criminale ha pubblicato su Steam videogiochi apparentemente innocui — tra cui BlockBlasters, Dashverse, Lunara e PirateFi — che nascondevano malware capace di svuotare i portafogli cripto delle vittime. Il 15 luglio 2026 l’FBI ha arrestato il primo membro pubblicamente noto dell’operazione: Zyaire Dontaevious Zamarion Wilkins, 21 anni, di North Lauderdale, Florida, noto online come Sibel.eth. A incastrarlo non è stata un’indagine sulla blockchain, ma un dettaglio molto più terreno: un ordine di cibo a domicilio pagato con una gift card comprata con Bitcoin rubato.

Uno schema attivo da maggio 2024Secondo la denuncia penale di 15 pagine depositata a Seattle — sede scelta non a caso, essendo la città più vicina al quartier generale di Valve a Bellevue — lo schema ha infettato circa 8.000 dispositivi e sottratto almeno 220.000 dollari da circa 80 portafogli di criptovalute, tra maggio 2024 e febbraio 2026. Il tasso di successo, poco sopra l’1% dei dispositivi infettati, non è casuale: gli otto giochi elencati nell’atto d’accusa venivano promossi su Discord, Telegram, X e LinkedIn, e i complici usavano bot per identificare utenti con portafogli cripto consistenti e contattarli direttamente, invece di affidarsi alla sola diffusione di massa.

Wilkins, secondo l’accusa, non ha scritto il malware ma ne ha finanziato lo sviluppo e curato la promozione. Chat Signal sequestrate a casa dello sviluppatore del malware — non identificato nell’atto d’accusa e a oggi non incriminato — collegano Wilkins, sotto lo pseudonimo Sibel.eth, a un pagamento di 10.000 dollari per l’acquisto di un trojan ad accesso remoto (RAT) e a discussioni su come indurre le vittime ad approvare transazioni che ne svuotavano i portafogli.

Il precedente di BlockBlasters e i fondi di beneficenza rubatiNon è la prima volta che questo cluster di giochi malevoli fa notizia. I ricercatori ZachXBT e il collettivo vx-underground avevano già stimato che il solo BlockBlasters avesse sottratto oltre 150.000 dollari a un numero di vittime compreso tra 261 e 478, incluso un episodio particolarmente odioso nel settembre 2025: 32.000 dollari donati per curare un tumore, rubati dal portafoglio di una streamer Twitch che stava raccogliendo fondi per le proprie cure oncologiche. L’FBI aveva iniziato a cercare pubblicamente le vittime di questi giochi infetti a marzo 2026, e Steam negli ultimi due anni ha visto una serie costante di incidenti simili, incluso il caso Chemia, un gioco in accesso anticipato che nascondeva tre ceppi di malware diversi: cryptojacking, infostealer e una backdoor per installare ulteriore malware in futuro.

Dalla blockchain a Uber Eats: come è stato individuatoLa parte più istruttiva del caso, dal punto di vista investigativo, è la catena di tracciamento. Gli inquirenti hanno seguito i Bitcoin rubati fino a un portafoglio dello schema che li ha convertiti in oltre 150 gift card tramite Bitrefill, un servizio che permette di acquistare buoni regalo con criptovalute. Una parte consistente di quelle gift card è stata spesa su Uber Eats. Una richiesta formale (subpoena) inviata a Uber ha permesso di collegare le gift card a un account che riceveva consegne proprio all’abitazione della famiglia Wilkins a North Lauderdale e agli indirizzi frequentati dall’indagato all’Università della Florida Occidentale.

Quando gli agenti hanno perquisito l’abitazione, una settimana prima dell’arresto, hanno sequestrato diversi dispositivi e tre seed phrase di portafogli cripto, una delle quali relativa a un wallet Monero — la criptovaluta privacy-oriented spesso usata proprio per rendere più difficile questo tipo di tracciamento. La cronologia delle transazioni di Wilkins, secondo l’atto d’accusa, mostra un flusso complessivo di 382.000 dollari in criptovalute inviate o ricevute, ben oltre i 220.000 dollari attribuiti direttamente allo schema contestato.

TimelineMaggio 2024 – febbraio 2026: periodo di attività dello schema, otto giochi infetti distribuiti su Steam

Settembre 2025: BlockBlasters svuota il portafoglio di una streamer Twitch che raccoglieva fondi per cure oncologiche (32.000 dollari)

Marzo 2026: l’FBI rende pubblica la ricerca di vittime dei giochi Steam infetti

Inizio luglio 2026: perquisizione dell’abitazione di Wilkins a North Lauderdale, sequestro di dispositivi e seed phrase

15 luglio 2026: arresto di Zyaire Wilkins e deposito della denuncia penale presso il tribunale federale di Seattle

Cosa resta apertoWilkins deve rispondere di cospirazione per l’ottenimento di informazioni tramite computer a scopo di profitto privato, un capo d’accusa che prevede fino a dieci anni di carcere. Ma la parte tecnica dell’operazione resta scoperta: lo sviluppatore del RAT e del malware che infettava i giochi non è nominato nell’atto d’accusa e, a oggi, non risulta incriminato, nonostante la sua abitazione sia già stata perquisita. È un pattern comune nelle indagini su cybercrime organizzato attorno alle criptovalute: chi finanzia e promuove viene identificato per primo, spesso tramite un errore operativo banale, mentre chi scrive il codice — più attento all’anonimato tecnico ma non necessariamente a quello finanziario — richiede più tempo.

Per i difensori, il caso conferma due lezioni già note ma sistematicamente ignorate: primo, la promozione mirata via bot verso utenti con portafogli consistenti rende inefficaci le difese basate solo sul volume di download o sulle recensioni Steam; secondo, ogni conversione di criptovaluta rubata in un servizio che tocca il mondo reale — gift card, delivery, e-commerce — riapre una superficie di tracciamento che l’uso di Monero a monte non riesce a chiudere del tutto. Per chi acquista giochi indie su Steam, resta valida la raccomandazione di isolare il portafoglio cripto su un dispositivo separato da quello usato per il gaming, e di trattare con sospetto qualsiasi titolo nuovo che chieda permessi di sistema non giustificati dal gameplay.

Indicatori e riferimenti del casoIndagato: Zyaire Dontaevious Zamarion Wilkins, 21 anni, North Lauderdale (FL)
Alias online: Sibel.eth
Capo d'imputazione: cospirazione per ottenimento di informazioni tramite computer
a scopo di profitto privato (fino a 10 anni)
Foro competente: Tribunale federale di Seattle, WA

Giochi Steam associati allo schema:
BlockBlasters, Dashverse, Lunara, PirateFi (+ 4 titoli aggiuntivi non ancora resi noti)

Canali di promozione: Discord, Telegram, X, LinkedIn
Servizio di conversione: Bitrefill (BTC -> gift card, 150+ carte, prevalenza Uber Eats)
Wallet sequestrati: 3 seed phrase, incl. 1 wallet Monero
Flusso cripto totale osservato sul conto dell'indagato: ~382.000 USD
Perdite attribuite allo schema: ~220.000 USD da ~80 wallet, ~8.000 dispositivi infettiFonti: denuncia penale depositata presso il tribunale federale di Seattle, prima riportata da WPLG Local 10; ricostruzione tecnica di Tom’s Hardware (17 luglio 2026); dati sulle perdite di BlockBlasters da ZachXBT e vx-underground.

Si parla di:

Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione datasetIl punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno scriptCiò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensoriLa parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificatoHugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidenteSettimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.

Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.

16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.

Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.

Due righe per i difensoriQuesto incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.

Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.

Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.

Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.

Indicatori e dettagli tecnici notiTarget: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.coHugging Face raccomanda a chi utilizza la piattaforma di ruotare i propri access token e rivedere l’attività recente sui rispettivi account. L’azienda ha inoltre chiarito di stare ancora completando la valutazione di eventuali impatti su dati di partner o clienti, con notifiche dirette previste per le parti coinvolte.

Cinque anni e mezzo di carcere ciascuno. È questa la cifra con cui la giustizia britannica ha chiuso, almeno sul fronte penale, uno degli attacchi informatici più dirompenti mai subiti da un’infrastruttura critica del Regno Unito: l’intrusione del 2024 in Transport for London, l’authority che gestisce la mobilità dell’intera Londra. Owen Flowers, 18 anni, e Thalha Jubair, 20, sono stati condannati il 16 luglio 2026 dalla Woolwich Crown Court. Sono, secondo l’accusa, i primi ad essere condannati per la Section 3ZA del Computer Misuse Act — la fattispecie più grave della legge britannica sui crimini informatici — e la National Crime Agency (NCA) definisce il loro caso il più grande procedimento per cybercrime mai affrontato dai tribunali del Paese.

Chi sono Flowers e Jubair, e cosa hanno fattoI due sono descritti dalla NCA come membri di primo piano di Scattered Spider, il collettivo criminale tracciato anche come Octo Tempest, UNC3944 e 0ktapus, responsabile secondo gli inquirenti di centinaia di attacchi tra il 2022 e il 2025. La Crown Prosecution Service (CPS) è più cauta nell’attribuzione diretta, notando che gli imputati hanno rivendicato in vari momenti l’appartenenza al gruppo senza che questo costituisse, di per sé, la base dell’accusa.

L’intrusione in TfL è avvenuta tra il 31 agosto e il 3 settembre 2024. L’attacco ha reso inutilizzabili 148 sistemi dell’authority, costringendo tutti i 27.000 dipendenti a recarsi fisicamente in un ufficio per il reset delle credenziali — non essendo più possibile farlo da remoto in sicurezza. Sono stati compromessi anche il sistema di rimborsi Oyster (inclusi, per circa 5.000 persone, numeri di conto bancario e codici sort code), il servizio Dial-a-Ride per i cittadini con disabilità, il canale dei pagamenti digitali e le domande per le Oyster photocard agevolate per bambini e giovani. NCA e CPS stimano il danno complessivo, tra perdite e costi di ripristino, in 29 milioni di sterline.

Un rischio sistemico da 56 miliardi di sterlineIl dato più inquietante emerso dal processo riguarda ciò che sarebbe potuto succedere e non è successo. Secondo la ricostruzione dell’accusa, le conversazioni tra i due imputati suggerivano l’intenzione di cancellare l’accesso al termine dell’operazione, ma nessuno può dire con certezza cosa avessero realmente pianificato. La NCA stima che uno shutdown riuscito della rete di TfL — che gestisce in media 9 milioni di spostamenti al giorno — avrebbe potuto costare all’economia britannica fino a 56 miliardi di sterline. Uno scenario rimasto ipotetico solo perché TfL, rendendosi conto della compromissione, ha scelto di disattivare preventivamente la propria rete per contenere gli attaccanti.

I due si sono dichiarati colpevoli il 22 giugno 2026, il primo giorno del processo, evitando così il dibattimento. Hanno ammesso il reato sulla base di aver agito in modo “reckless” — sconsiderato — rispetto al rischio di causare o creare un pericolo significativo per il benessere umano, elemento costitutivo della Section 3ZA.

Come sono stati identificatiFlowers è stato arrestato per la prima volta il 6 settembre 2024, tre giorni dopo la fine dell’intrusione in TfL, nella sua abitazione a Walsall. Al momento dell’arresto, gli agenti NCA lo hanno sorpreso mentre era ancora attivo su due ulteriori obiettivi: le reti delle organizzazioni sanitarie statunitensi SSM Health Care Corporation e Sutter Health. Tra i dispositivi sequestrati — laptop, computer desktop, hard disk e chiavette USB — un portatile Acer conteneva uno screenshot della connettività di rete verso l’infrastruttura TfL e diversi video, registrati dallo stesso Flowers, che mostravano Jubair muoversi all’interno dei sistemi dell’authority londinese durante l’attacco. I due comunicavano in tempo reale su Telegram e condividevano uno spazio di lavoro online.

L’accusa ha dimostrato che Flowers era collegato al server remoto usato per lanciare tutte e tre le intrusioni, con prove ricavate dai suoi stessi dispositivi. Le informazioni che collegano Jubair all’attacco TfL sono state invece ottenute all’estero, con la collaborazione di autorità giudiziarie di altri Paesi — un dettaglio che la CPS non ha specificato ulteriormente. Jubair, arrestato il 16 settembre 2025, ha un secondo procedimento ancora aperto negli Stati Uniti: un atto d’accusa depositato nel New Jersey lo collega a circa 120 intrusioni di rete e almeno 47 vittime statunitensi tra maggio 2022 e settembre 2025, per oltre 115 milioni di dollari in riscatti pagati, incluse violazioni ai danni di un’infrastruttura critica USA e dei tribunali federali. Su questo fronte rischia fino a 95 anni di carcere; nessuna delle comunicazioni ufficiali diffuse finora affronta il tema dell’estradizione.

Scattered Spider è davvero finita?La NCA sostiene che l’azione contro i due abbia “sostanzialmente fermato” il gruppo, citando una valutazione di Microsoft secondo cui gli arresti ne avrebbero degradato in modo significativo la capacità operativa. Ma la stessa agenzia ammette che altri criminali potrebbero continuare a usare il marchio “Scattered Spider” per rivendicare nuovi attacchi. Non è un’ipotesi remota: a gennaio 2026 Mandiant ha documentato l’espansione di un’operazione di estorsione a marchio ShinyHunters che replica lo stesso modello — vishing verso i dipendenti, pagine di phishing per rubare credenziali SSO e codici MFA, enrollment di un dispositivo dell’attaccante per bypassare l’autenticazione multifattore.

È proprio questo il punto debole che accomuna la maggior parte dei casi riconducibili a Scattered Spider: non un exploit tecnico sofisticato, ma la manipolazione dei processi di help desk — reset password, gestione dei dispositivi MFA — con tecniche di social engineering telefonico mirate e ben documentate.

Due righe per i difensoriIl caso TfL resta un caso di scuola su come un’infrastruttura critica possa essere messa in ginocchio non da uno zero-day, ma da processi organizzativi vulnerabili al fattore umano. Alcune indicazioni pratiche per ridurre l’esposizione a gruppi con TTP simili a Scattered Spider:

Verificare sempre l’identità con procedure fuori banda (callback su numero verificato, verifica video) prima di eseguire reset password, modifiche MFA o enrollment di nuovi dispositivi richiesti telefonicamente all’help desk.

Limitare la possibilità per il personale di help desk di eseguire reset critici senza approvazione di un secondo operatore (four-eyes principle).

Monitorare enrollment MFA anomali, specialmente se avvengono subito dopo un reset password.

Coinvolgere le forze dell’ordine tempestivamente in caso di incidente: secondo la NCA, la collaborazione precoce di TfL è stata determinante per l’esito del procedimento.

Segmentare le reti operative critiche (biglietteria, pagamenti, servizi per l’utenza vulnerabile) da quelle amministrative, per limitare l’impatto di una compromissione laterale.

Fonti: The Hacker News, National Crime Agency.

Non serve colpire una centrale elettrica per mettere in ginocchio una filiera critica: basta un ransomware ben piazzato nei sistemi produttivi di un’azienda che imbottiglia latte. Il 16 luglio 2026 Coca-Cola ha comunicato alla SEC che la sua controllata Fairlife ha sospeso la produzione negli Stati Uniti dopo un attacco ransomware che ha colpito i sistemi legati alla produzione stessa. Un episodio che, al netto delle dimensioni del marchio coinvolto, racconta molto sullo stato di sicurezza dell’OT nel settore alimentare.

Cosa è successoFairlife, con sede a Chicago, è il marchio di latte ultrafiltrato di proprietà di Coca-Cola, noto anche per le linee Core Power Protein Shakes e Nutrition Plan. Nel filing 8-K depositato presso la Securities and Exchange Commission, Coca-Cola ha dichiarato che soggetti non autorizzati hanno avuto accesso a una parte dei sistemi di Fairlife, inclusi quelli legati alla produzione, in un attacco che l’azienda descrive esplicitamente come ransomware. Le operazioni negli stabilimenti statunitensi sono state temporaneamente sospese; la produzione in Canada, gestita separatamente, non risulta invece impattata.

Coca-Cola ha attivato i protocolli di incident response e business continuity, coinvolto consulenti esterni e notificato le forze dell’ordine, precisando che qualità e sicurezza del prodotto non sono state compromesse. Al momento della scrittura, la società non ha reso noto quale gruppo ransomware sia responsabile, se siano stati sottratti dati né se sia stata ricevuta una richiesta di riscatto. Nessuna gang ransomware nota ha ancora rivendicato l’attacco, un silenzio che nel settore viene letto come tipico delle prime fasi di un negoziato, prima che gli estorsori tornino a farsi vivi minacciando la pubblicazione di eventuali dati sottratti.

Non è un caso isolato: la filiera alimentare nel mirinoL’attacco a Fairlife arriva in un contesto in cui il comparto food & beverage è bersaglio ricorrente del ransomware, spesso proprio perché la convergenza IT/OT nelle linee di produzione rende gli impianti fragili: basta bloccare i sistemi SCADA o MES che orchestrano il confezionamento per fermare intere linee, anche senza toccare la sicurezza alimentare in senso stretto. Il precedente più noto resta l’attacco del 2021 a JBS, il colosso mondiale della carne, costretto a fermare impianti in Nord America e Australia e a pagare 11 milioni di dollari di riscatto al gruppo REvil. Nella sola finestra delle ultime 48 ore, la stessa dinamica si è ripetuta altrove: in Giappone, un attacco informatico a un operatore logistico ha svuotato le cucine di migliaia di ristoranti per un blocco nelle consegne di prodotti alimentari, mentre il colosso giapponese dei surgelati Nichirei ha segnalato la disruzione delle proprie operazioni per un incidente informatico separato.

Il filo comune è la dipendenza di filiere alimentari globalizzate da sistemi IT centralizzati per pianificazione della produzione, gestione ordini e logistica: quando quei sistemi vengono cifrati o resi inaccessibili, l’impatto si propaga rapidamente dagli scaffali dei supermercati alle cucine dei ristoranti, ben oltre il perimetro aziendale colpito.

Perché conta anche per chi non produce latteIl caso Fairlife è interessante per i difensori non tanto per i dettagli tecnici, che Coca-Cola non ha ancora reso pubblici, quanto per la dinamica di disclosure e per l’esposizione di un brand multimiliardario a un rischio operativo concreto tramite una controllata. Il filing SEC evidenzia un punto spesso sottovalutato nei risk assessment: la segmentazione tra rete IT aziendale e rete OT di produzione, quando esiste, va verificata regolarmente, perché un attacco che compromette “solo” i sistemi IT può comunque paralizzare la produzione se i due domini condividono directory service, credenziali o piattaforme di orchestrazione.

Per le aziende manifatturiere, specialmente nel food & beverage dove i margini di tolleranza su tempi di fermo sono minimi per ragioni di deperibilità delle materie prime, le priorità restano quelle già emerse dai casi JBS e Nichirei: backup offline testati e realmente isolati (non solo replicati su un secondo datacenter raggiungibile dalla stessa rete), piani di failover manuale per le linee di produzione critiche, segmentazione rigorosa tra reti corporate e reti OT/ICS, e accordi di incident response pre-negoziati con forze dell’ordine e consulenti forensi, in modo da non partire da zero quando il tempo conta più di ogni altra cosa.

Verificare che i backup dei sistemi MES/SCADA siano realmente air-gapped e non solo “logicamente separati”

Testare periodicamente scenari di failover manuale per le linee di produzione più critiche

Mappare le dipendenze condivise (Active Directory, VPN, orchestrazione cloud) tra rete IT e rete OT

Predisporre in anticipo contatti con FBI/law enforcement locale e retainer di incident response per ridurre i tempi di reazione

Cosa manca ancora al quadroAl momento della pubblicazione, mancano ancora elementi chiave per una piena attribuzione: nome della gang ransomware, vettore di accesso iniziale, eventuale esfiltrazione di dati e ammontare della richiesta di riscatto. Continueremo a seguire l’evoluzione del caso Fairlife, aggiornando l’articolo qualora emergano rivendicazioni o dettagli tecnici da fonti di threat intelligence.

Stato indicatori al 18/07/2026:

• Gruppo ransomware responsabile: non identificato pubblicamente
• Vettore di accesso iniziale: non divulgato
• Esfiltrazione dati: non confermata
• Richiesta di riscatto: non divulgata
• Sistemi impattati: infrastrutture di produzione Fairlife (solo USA)
• Sistemi non impattati: produzione Fairlife Canada, qualita/sicurezza prodotto

Riferimento normativo: SEC Form 8-K depositato da The Coca-Cola Company il 16/07/2026

Immaginate di collegare il vostro Ledger o Trezor per una transazione di routine, digitare il PIN, e vedere comparire sullo schermo del wallet una richiesta di “recovery” della seed phrase — identica, pixel per pixel, a quella che l’app mostrerebbe in caso di reale malfunzionamento. Solo che non è l’app a parlare: è OkoBot, un framework modulare scoperto dal team GReAT di Kaspersky, che si inietta direttamente nel processo Electron di Ledger Live e Trezor Suite per mostrare pagine di phishing hard-coded e rubare la frase di recupero da dentro l’applicazione legittima.

Un framework, non un semplice trojanAttivo almeno da aprile 2025 e ancora operativo, OkoBot non è un singolo malware ma un’infrastruttura modulare che conta oltre venti payload e impianti diversi, orchestrati tramite un tunnel SSH verso un server controllato dagli attaccanti. Tra le funzioni disponibili: raccolta di file locali, esecuzione di comandi remoti, download di estensioni browser arbitrarie, furto di wallet crypto, keylogging, registrazione video della finestra attiva e, ovviamente, furto di seed phrase. Kaspersky rileva i vari componenti con firme distinte — Trojan-Downloader.Win32.TookPS, Trojan.Win64.BypassUAC, Trojan-Banker.Script.Agent.gen, Backdoor.Win32.TeviRat, Trojan-PSW.Win64.Stealer, Trojan-Spy.Win64.Keylogger — segno che si tratta di un ecosistema criminale maturo e in continua evoluzione, non di un singolo eseguibile.

La catena di infezione: da TookPS al tunnel SSHTutto parte da TookPS, un downloader PowerShell che i ricercatori Kaspersky avevano già documentato in campagne precedenti mascherato da software popolare (UltraViewer, AutoCAD, Ableton). TookPS installa un client SSH sulla macchina della vittima, apre una connessione verso un server controllato dagli attaccanti e inoltra la porta del demone SSH locale. Dopo un intervallo di attesa, un bot SSH automatizzato si collega alla porta inoltrata, raccoglie informazioni di base sul sistema — nome utente, antivirus installato, indirizzo IP, versione del sistema operativo — e in base al profilo della vittima decide quali dei venti moduli successivi distribuire. È una catena a quattro stadi pensata per essere modulare e selettiva: non tutte le vittime ricevono lo stesso payload, riducendo il rumore e la superficie di rilevamento generica.

SeedHunter e OkoSpyware: il cuore del furtoIl modulo più insidioso per chi possiede crypto è SeedHunter. Monitora costantemente i processi attivi in cerca di Trezor Suite, Ledger Wallet o Ledger Live; quando li trova, si inietta nel processo e aggancia (“hook”) le funzioni interne Electron dell’applicazione. Alla connessione di un wallet hardware Trezor o Ledger, SeedHunter attiva le funzioni agganciate per mostrare una pagina di phishing hard-coded per il “recupero” della seed phrase — con un layout diverso e specifico per ciascun tipo di wallet, per massimizzare la credibilità. La vittima crede di interagire con la propria app di sempre; in realtà sta digitando le 12 o 24 parole della propria frase di recupero direttamente nelle mani degli attaccanti.

Accanto a SeedHunter opera OkoSpyware, un modulo più recente che cattura keystroke e stream video della finestra dell’applicazione target — utile sia per rubare credenziali digitate manualmente sia per raccogliere materiale di intelligence sulla vittima (abitudini, saldi, altre app finanziarie in uso).

I vettori: ClickFix e repository GitHub trojanizzatiL’infezione iniziale avviene per due strade parallele. La prima è un classico attacco ClickFix: la vittima trova un sito o un annuncio che simula un errore di sistema e la invita a “risolverlo” copiando e incollando un comando in una finestra di esecuzione (di solito PowerShell aperto tramite il prompt “Esegui” di Windows) — un pattern di social engineering che sta esplodendo in popolarità perché elude molti controlli antivirus basati su file, dato che non c’è alcun eseguibile scaricato in un primo momento.

La seconda strada è più insidiosa per un pubblico tecnico: repository GitHub che spacciano software legittimo. In un caso documentato da Kaspersky, un repository pubblicizzato come “SQL Server Management Studio” distribuiva in realtà una copia ricompilata di Audacity, il noto editor audio open source, con un impianto malevolo incorporato in una delle sue librerie. Il repository è rimasto attivo da fine marzo 2025 a giugno, tempo sufficiente per infettare sviluppatori e power user che scaricano software direttamente da GitHub confidando (a torto) nella reputazione della piattaforma come garanzia di autenticità del codice.

I numeri della campagnaAd oggi OkoBot ha colpito centinaia di vittime in oltre 25 paesi, con la concentrazione più alta in Brasile, Vietnam, Canada, Messico e Turchia — una geografia coerente con altre campagne di crimeware finanziario che privilegiano mercati con adozione crypto retail elevata e risposta delle forze dell’ordine relativamente più lenta rispetto a USA ed Europa occidentale. La campagna, secondo Kaspersky, è tuttora attiva al momento della pubblicazione della ricerca.

Due righe per i difensoriDiffidare sistematicamente da qualsiasi istruzione che chieda di copiare e incollare comandi in PowerShell o nel prompt “Esegui” per “risolvere un errore”: è la firma comportamentale di ClickFix, indipendentemente dal sito che la propone.

Scaricare software critico (wallet manager, tool di sviluppo) esclusivamente dai domini ufficiali dei vendor, verificando hash e firme digitali dei pacchetti anche quando la fonte sembra GitHub o un repository con molte stelle.

Trattare qualunque richiesta di inserimento della seed phrase come un evento anomalo per definizione: né Ledger né Trezor la richiedono mai via software per operazioni di routine. La seed phrase va scritta solo su supporto fisico, mai digitata su un computer connesso.

Monitorare, lato endpoint, connessioni SSH in uscita non autorizzate e port-forwarding anomali verso IP esterni, dato che l’intera catena OkoBot dipende da un tunnel SSH stabilito dal downloader iniziale.

Applicare application allow-listing sugli endpoint che gestiscono wallet crypto, impedendo l’iniezione di codice in processi Electron non firmati o modificati rispetto al binario ufficiale.

Indicatori di compromissione# Firme di rilevamento Kaspersky associate alla campagna OkoBot
Trojan-Downloader.Win32.TookPS.*
Trojan.Win64.BypassUAC.*
Trojan-Banker.Script.Agent.gen
Trojan.Win32.Dllhijack.*
Backdoor.Win32.TeviRat.*
Trojan-PSW.Win64.Stealer.*
Trojan-Spy.Win64.Keylogger.*
Trojan-Spy.Win64.Agent.*
Trojan.Win64.Agent.*

Comportamenti da monitorare (EDR/SOC)

• Esecuzione PowerShell innescata da clipboard / dialogo "Esegui" (pattern ClickFix)
• Installazione non richiesta di client SSH (es. OpenSSH) seguita da
  port-forwarding verso host esterno sconosciuto
• Iniezione di codice in processi Ledger Live / Trezor Suite (Electron)
• Hook di funzioni Electron in processi di wallet manager
• Traffico SSH persistente in uscita su porte non standard verso
  infrastruttura non aziendale

Vettori di distribuzione noti

• Repository GitHub che spacciano software legittimo (es. build
  trojanizzate di Audacity presentate come "SQL Server Management Studio")
• Siti/annunci ClickFix che simulano errori di sistema o CAPTCHA falliti
  Fonte tecnica completa e IoC estesi: Securelist (Kaspersky GReAT)Il caso OkoBot conferma una tendenza che i team di threat intelligence osservano da tempo: i criminali informatici stanno spostando lo sforzo ingegneristico dal furto di credenziali generiche all’attacco mirato ai flussi applicativi di prodotti di sicurezza specifici — in questo caso i wallet hardware, pensati proprio per essere “air-gapped” e immuni al malware sul computer host. Iniettarsi nell’app companion anziché nel dispositivo fisico è un modo elegante per aggirare quella barriera senza doverla rompere davvero.