Si parla di:

Toggle

Da febbraio 2026 un nuovo #trojan bancario per #Android circola con un obiettivo dichiarato: l’#Ucraina. Ma “trojan bancario” è ormai una definizione troppo stretta per Manic, il #malware descritto in un #report di ThreatFabric come “un ibrido tra malware bancario e #spyware”. Oltre a rubare PIN e credenziali finanziarie, Manic intercetta #SMS, seed phrase di wallet #crypto, cronologia chiamate e posizione #GPS — e, quando il telefono infetto è #offline, trova comunque il modo di far uscire i dati sfruttando altri dispositivi compromessi nelle vicinanze via Bluetooth e Wi-Fi Direct. È una capacità che ridefinisce cosa significhi davvero “isolare” un dispositivo compromesso.

Non una schermata di phishing, ma una tastiera che origliaLa maggior parte dei trojan bancari Android si affida a overlay che imitano l’interfaccia dell’app bersaglio per catturare le credenziali digitate dalla vittima. Manic fa qualcosa di più subdolo: grazie ai permessi di Accessibility Service, determina la posizione della tastiera digitale legittima dell’app e registra i singoli tocchi dell’utente senza alterare in alcun modo il funzionamento dell’app originale. Il risultato è che la vittima interagisce con la sua banca reale, sullo schermo reale, mentre in background il malware classifica ogni sequenza digitata — PIN di sblocco, seed phrase di wallet, codici OTP, password — semplicemente osservando dove e quando avvengono i tocchi.

A questa capacità si aggiungono sessioni di controllo remoto vere e proprie via WebRTC, con visualizzazione live dello schermo, mascherate dietro overlay neri o finte schermate di aggiornamento di sistema; la possibilità di sbloccare il dispositivo da remoto tramite la funzione autoEnterPin, una volta che il PIN è stato catturato; e comandi dedicati per disattivare Google Play Protect (disable_gp), così da ridurre le probabilità di essere rilevati anche dalle protezioni native di Android.

169 applicazioni monitorate, priorità all’UcrainaThreatFabric ha censito 169 identificatori di applicazioni nella lista bersagli di Manic: banche, exchange di criptovalute, app di pagamento P2P e “buy now pay later”, client email e browser. Il dato più significativo, però, è la composizione geografica dei target: il malware dà priorità esplicita a banche ucraine, servizi eID e piattaforme governative, oltre ad app di messaggistica sia commerciali sia a uso militare — una scelta che, nel contesto del conflitto in corso, suggerisce un interesse che va oltre la semplice frode finanziaria. La lista si estende poi a istituti finanziari in Russia, Polonia, Repubblica Ceca, Slovacchia, Austria, Germania, Francia, Spagna, Paesi Bassi, Estonia, Lituania e Regno Unito, con distribuzione tramite siti di phishing e dropper che si spacciano per utility di sistema o aggiornamenti di componenti Android/produttore (i nomi dei package individuati imitano deliberatamente Huawei, Honor, Lenovo, Motorola e persino Apple).

Lo sviluppo del malware appare tutt’altro che concluso. ThreatFabric ricostruisce una timeline chiara: la prima infrastruttura viene registrata a febbraio 2026, i servizi di produzione entrano in funzione tra marzo e aprile, la prima versione operativa di wrapper e implant compare a maggio, mentre a luglio arriva un aggiornamento che introduce protezioni anti-analisi rafforzate, caricamento del codice DEX direttamente in memoria (per complicare l’analisi statica) e un meccanismo di phishing per il “lock secret” del dispositivo.

Quando internet non basta: l’esfiltrazione mesh via BluetoothLa caratteristica più originale di Manic — e quella che lo distingue nettamente dal panorama dei trojan Android — è il meccanismo di esfiltrazione dati progettato per funzionare anche quando il dispositivo infetto non ha accesso diretto a internet. I dati rubati vengono cifrati con AES-GCM e messi in una coda locale; il malware cerca poi altri dispositivi infetti nelle vicinanze tramite Wi-Fi Direct, Bluetooth RFCOMM o BLE GATT, costruendo percorsi “store-and-forward” multi-hop — fino a 4 salti per impostazione predefinita — capaci di far arrivare i dati a internet passando di device in device, finché uno di essi non trova connettività diretta. Se nessuna rotta è disponibile nell’immediato, i dati restano semplicemente in coda per essere ritrasmessi al primo tentativo utile.

Come sintetizzano gli stessi ricercatori di ThreatFabric, “rimuovere l’accesso diretto a internet da un dispositivo infetto non impedisce necessariamente l’esfiltrazione dei dati”. È una considerazione che dovrebbe far riflettere chi progetta contromisure basate solo su segmentazione di rete o blocco della connettività cellulare/Wi-Fi: in scenari con più dispositivi compromessi nello stesso ambiente — un ufficio, un’abitazione, persino un evento pubblico — la rete mesh creata dal malware stesso diventa il canale di comunicazione, aggirando completamente i controlli perimetrali tradizionali pensati per un singolo endpoint.

Due righe per i difensoriPer i team di sicurezza mobile e per gli istituti finanziari nei paesi target, Manic impone di ripensare due assunzioni comuni. La prima è che il monitoraggio comportamentale lato server (fraud detection basata su pattern di digitazione o velocità di interazione) rimane efficace anche quando l’attaccante non altera l’interfaccia dell’app: qui serve piuttosto rilevare l’uso anomalo di servizi di Accessibility da parte di app di terze parti non correlate al contesto bancario. La seconda è che l’isolamento di rete di un dispositivo sospetto non è più una garanzia sufficiente, quando l’esfiltrazione può avvenire tramite protocolli short-range verso dispositivi terzi già compromessi.

Verificare quali app hanno richiesto e ottenuto permessi di Accessibility Service e Notification Listener, specie se provenienti da fonti fuori Google Play

Monitorare pattern anomali di connessioni Wi-Fi Direct/Bluetooth in ambienti aziendali e finanziari sensibili

Diffidare di dropper che si presentano come aggiornamenti di componenti di sistema legati a specifici produttori (Huawei, Honor, Lenovo, Motorola)

Mantenere attivo Google Play Protect e verificare periodicamente lo stato di attivazione, dato che Manic include comandi dedicati per disattivarlo

Per le banche: rafforzare l’autenticazione multi-fattore fuori-banda, poiché OTP e SMS risultano tra i dati intercettati con priorità

Indicatori di compromissione[Wrapper - luglio 2026]
SHA-256: 80be0942d0e20b5006e240434f42512c8b3cd0d54eee858a25663c1a4224a576
Package: tech.intel.dialer.updater

[Implant - luglio 2026]
SHA-256: feea425cde1223fe7afdd7a1ea631678ec6282f6cc20c3d3c0fb97cdbcf65b9b
Package: org.lenovo.storage.processor

[Implant primario]
SHA-256: e7abc375f24d0dd2419e0bce4686c7301b3ee82ae38906c67d3481580f6c648e
Package: tech.apple.dialer.scheduler

[Wrapper - maggio 2026]
SHA-256: 2884108b35eba7b8099087405653c1b23c3839f0d5058c4d61341fc31cfc6040
Package: org.honor.secure.helper

[Implant - maggio 2026]
SHA-256: 2fb5b01ea5a483d60b659e85327a53c6661bdd630d4afd93dc5fe0941d3ccbbe
Package: dev.huawei.media.helper

[Implant correlato]
SHA-256: 7c12f1237090e32c18583f66f1a9e44b029ad7c1e61179e1d524fb3093abd59a
Package: io.motorola.secure.executor

[Comandi bot principali]
remote_control - sessione schermo/webcam via WebRTC
get_logs - esportazione log accessibility
export_sms - esportazione SMS
export_calls - esportazione cronologia chiamate
export_contacts - esportazione contatti
export_file - raccolta file locali
send_sms - invio SMS dal dispositivo
ussd - esecuzione codici USSD
geo - attivazione geolocalizzazione
disable_gp - disattivazione Google Play ProtectFonte primaria: ThreatFabric Mobile Threat Intelligence. Report completo disponibile sul blog ufficiale di ThreatFabric.

Si parla di:

Toggle

Il 20 agosto 2026 il gruppo di #cybercrime xpl0itrs ha rivendicato sul proprio leak site l’esfiltrazione di 6,1 terabyte di dati da oltre 3.000 istituti scolastici italiani, colpendo l’infrastruttura del Gruppo Spaggiari di Parma, storico fornitore del registro elettronico ClasseViva usato ogni giorno da milioni di studenti, famiglie e docenti in tutta Italia. La rivendicazione ha acceso i riflettori su uno dei fornitori più capillari dell’ecosistema scolastico nazionale, ma la risposta ufficiale dell’azienda — arrivata il giorno successivo — ridimensiona sensibilmente la portata dell’incidente, aprendo un caso di studio interessante sul divario tra ciò che i gruppi ransomware rivendicano e ciò che, effettivamente, è stato compromesso.

Il bersaglio: cent’anni di storia, 4.000 scuole, 4,5 milioni di utentiFondato nel 1926, il Gruppo Spaggiari si è evoluto da editore scolastico a fornitore di servizi digitali per la gestione della didattica, diventando negli anni uno dei nomi più riconoscibili della #scuola italiana grazie a ClasseViva, il registro elettronico che connette istituti, insegnanti, studenti e famiglie. Secondo i dati riportati dall’azienda stessa, la piattaforma è oggi utilizzata da oltre 4.000 #scuole attive con più di 4,5 milioni di utenti giornalieri — una superficie d’attacco enorme, che rende qualunque incidente di #sicurezza su questo fornitore un potenziale problema di scala nazionale.

Chi è xpl0itrs: dalla supply chain agli attacchi ad alto profiloxpl0itrs è un collettivo di cybercrime a scopo di lucro emerso all’inizio del 2026, che secondo le analisi di threat intelligence opera in stretto coordinamento con un altro gruppo, #TeamPCP, condividendo accesso iniziale, strumenti e talvolta le stesse vittime all’interno di un ecosistema focalizzato sulla compromissione della supply chain software. Il modus operandi del gruppo si concentra su furto di token di sviluppo — Personal Access Token, credenziali #OAuth, chiavi API — sottratti da ambienti di sviluppo, seguito da esfiltrazione di dati da repository e infrastrutture interne. Un membro che si fa chiamare “boxturtl” funge da portavoce pubblico, presentandosi come ex red teamer professionista.

Nelle scorse settimane il gruppo ha rivendicato, con diversi gradi di credibilità, violazioni ai danni di realtà molto note tra cui Spotify, il Dipartimento del Tesoro statunitense, OpenAI e Trustpilot, oltre a vittime indirette raggiunte tramite la compromissione di progetti open source come Trivy, BitWarden CLI, LiteLLM e Checkmarx KICS. Il profilo tracciato da Dataminr valuta le rivendicazioni del gruppo come “generalmente credibili”, basandosi su campioni di dati che contengono riferimenti plausibili a risorse di sviluppo interne e metadati Git coerenti con un accesso autentico mantenuto almeno fino a maggio 2026. Gli analisti segnalano inoltre legami indiretti con i cluster di estorsione DarkRomance e con il brand ShinyHunters, e una tecnica MITRE ATT&CK documentata — T1486, Data Encrypted for Impact — che colloca il gruppo nella categoria ransomware/extortion a tutti gli effetti, con almeno otto rivendicazioni pubblicate sul proprio leak site negli ultimi trenta giorni.

La rivendicazione contro la versione ufficialeSecondo la rivendicazione pubblicata da xpl0itrs, i 6,1 TB sottratti includerebbero nomi, indirizzi email, numeri di telefono e almeno un campo password relativo a oltre 3.000 istituti scolastici — senza, secondo quanto dichiarato dagli stessi attaccanti, identificatori governativi come codici fiscali o numeri di documento. Spaggiari ha risposto con un comunicato ufficiale datato 21 agosto 2026, precisando che a essere compromesso sarebbe stato esclusivamente il componente “Modulistica Smart” della piattaforma Bergantini — uno strumento per la gestione della modulistica scolastica — e non il registro elettronico ClasseViva, i sistemi di gestione didattica o quelli amministrativi, definiti dall’azienda “un sistema distinto e separato” rispetto a quello colpito.

Un dettaglio significativo emerso dalla ricostruzione è la data dell’intrusione originaria: secondo Spaggiari l’accesso non autorizzato risalirebbe al 30 giugno 2026, quasi due mesi prima della rivendicazione pubblica del 20 agosto. Un intervallo così ampio tra compromissione e divulgazione è tutt’altro che insolito nel panorama ransomware: spesso corrisponde al tempo impiegato dagli attaccanti per l’esfiltrazione, l’eventuale negoziazione privata con la vittima (evidentemente naufragata, in questo caso) e, infine, la pubblicazione sul leak site come leva estorsiva. L’azienda ha dichiarato di aver notificato l’incidente al Garante per la protezione dei dati personali, all’Agenzia per la Cybersicurezza Nazionale (ACN) e alle forze dell’ordine.

Perché il divario tra le due versioni contaIl contrasto tra la portata rivendicata (6,1 TB, oltre 3.000 scuole) e quella riconosciuta ufficialmente (un singolo modulo di modulistica) è un pattern ricorrente nelle dinamiche di doppia estorsione: i gruppi ransomware hanno tutto l’interesse a massimizzare la percezione del danno per aumentare la pressione sulla vittima e il valore di rivendita dei dati, mentre le aziende colpite tendono, comprensibilmente, a circoscrivere la narrazione pubblica il più possibile. Senza una verifica indipendente di un campione dei dati esfiltrati — al momento non disponibile pubblicamente — è prematuro stabilire quale delle due versioni sia più vicina alla realtà, ma il profilo di xpl0itrs, storicamente valutato come “generalmente credibile” dagli analisti, invita quantomeno alla cautela verso un ridimensionamento totale dell’incidente.

Rischi concreti per famiglie e istitutiAnche nello scenario più contenuto descritto da Spaggiari, l’esposizione di nominativi, email, numeri di telefono e credenziali legate al mondo scolastico costituisce un rischio concreto: questo tipo di dataset è particolarmente appetibile per campagne di phishing mirato verso segreterie scolastiche e famiglie (spesso mascherate da comunicazioni ClasseViva o da avvisi del Ministero dell’Istruzione), per tentativi di account takeover su servizi che riutilizzano le stesse credenziali, e per la profilazione di minori, un tema su cui il Garante privacy italiano è tradizionalmente molto attento. Le scuole coinvolte dovrebbero considerare, come misura precauzionale indipendentemente dall’entità confermata del breach, la rotazione delle credenziali di accesso al modulo Modulistica Smart, l’attivazione di autenticazione a più fattori dove disponibile e un’allerta mirata al personale su possibili tentativi di phishing a tema scolastico nelle prossime settimane.

Riferimenti e indicatori# Incidente Gruppo Spaggiari / ClasseViva
Attore: xpl0itrs (coordinato con TeamPCP)
Tecnica MITRE ATT&CK: T1486 - Data Encrypted for Impact
Componente rivendicato come compromesso: Modulistica Smart (piattaforma Bergantini)
Data intrusione dichiarata da Spaggiari: 30 giugno 2026
Data rivendicazione pubblica: 20 agosto 2026
Data comunicato ufficiale Spaggiari: 21 agosto 2026
Volume dati rivendicato: ~6,1 TB / 3.000+ istituti scolastici
Tipologia dati rivendicati: nominativi, email, numeri di telefono, password (parziale)
Notifiche effettuate: Garante Privacy, ACN, forze dell'ordineFonti: comunicato ufficiale Gruppo Spaggiari, ransomware.live, Dataminr Intel Brief, GalaxyWarden, monitoraggio leak site.

Si parla di:

Toggle

Da due anni si spacciava per movimento hacktivista filo-palestinese. Il Dipartimento di Giustizia americano ha invece confermato ciò che gli analisti sospettavano da tempo: dietro il collettivo “#Handala” #opera il #Ministero dell’#Intelligence iraniano (#MOIS), e il suo bersaglio attuale sono i giornalisti israeliani, contattati su #WhatsApp e #Telegram con la stessa cura con cui si costruisce una fonte, per rubare loro le credenziali e, in alcuni casi, l’intero telefono.

Lo Shin Bet e l’Autorità nazionale per la cybersicurezza israeliana hanno diffuso il 16 agosto 2026 un avviso congiunto, raro per esplicitezza, in cui si afferma che “gli operativi dell’intelligence iraniana stanno tentando di raccogliere informazioni sensibili su sviluppi politici e di #sicurezza, ottenere accesso a fonti giornalistiche, materiali di lavoro e corrispondenza”. Non è un’allerta generica: arriva dopo mesi di segnalazioni da parte di redazioni come Haaretz, i cui cronisti sono stati impersonati per avvicinare colleghi e contatti.

Chi è davvero HandalaIl nome richiama la celebre vignetta del fumettista palestinese Naji al-Ali, e per due anni il brand “Handala Hack Team” ha coltivato un’immagine da collettivo hacktivista indipendente, rivendicando data breach e defacement contro obiettivi israeliani sui propri canali Telegram. È la stessa tattica di copertura vista in altri cluster iraniani — un layer “civile” che permette a #Teheran di condurre operazioni offensive negando plausibilmente il coinvolgimento statale, mentre online si costruisce consenso e narrativa a supporto della causa filo-palestinese.

A marzo 2026 il Dipartimento di Giustizia USA ha reso pubblica un’incriminazione che collega individui operanti sotto l’ombrello Handala al MOIS, inquadrando le loro attività in un più ampio programma di “operazioni psicologiche cyber-abilitate” — disinformazione, intimidazione e raccolta di intelligence combinate nello stesso apparato. Lo stesso ecosistema di attori legati a Teheran è stato osservato a marzo colpire con un wiper l’azienda Stryker e violare la casella di posta personale del direttore dell’FBI, segno di un’operatività che spazia dal sabotaggio industriale allo spionaggio mirato su singole persone.

Come funziona l’avvicinamentoLa campagna descritta da Shin Bet non punta a exploit zero-day, ma a ingegneria sociale paziente e su misura, costruita specificamente attorno al mestiere del giornalista. Gli operatori contattano il bersaglio fingendosi conoscenti, colleghi o addirittura firme note — tra i nomi usati come esca, secondo le ricostruzioni giornalistiche, anche quello del noto reporter Barak Ravid — con proposte di collaborazione, richieste di intervista o l’offerta di materiale esclusivo su sviluppi politici e militari, l’esca perfetta per chi vive di scoop.

Da lì si dipartono tre vettori distinti, spesso combinati nella stessa conversazione:

Link a pagine di login contraffatte che imitano Google, per catturare credenziali dell’account principale e, con esso, l’accesso a mail, contatti e cronologia dei documenti condivisi;

Link a Google Drive falsificati che rimandano a documenti “esclusivi” ma in realtà instradano verso pagine di raccolta credenziali identiche a quelle originali;

File malevoli inviati come allegati — presunti dossier, registrazioni o documenti di interesse — che una volta aperti concedono accesso completo al dispositivo mobile, inclusi messaggistica, microfono e geolocalizzazione.

L’obiettivo dichiarato dalle autorità israeliane non è solo la singola casella di posta: è la ricostruzione della rete di fonti del giornalista, l’accesso a materiali di lavoro non ancora pubblicati e, in prospettiva, la possibilità di alimentare operazioni di influenza usando conversazioni sottratte, come già avvenuto in altri episodi in cui gruppi legati a Teheran hanno pubblicato messaggi privati rubati per screditare bersagli israeliani.

Perché conta per chi si occupa di difesaIl caso Handala è un promemoria scomodo per chi lavora in redazioni, ONG e uffici stampa che trattano materiale sensibile su Medio Oriente: l’anello debole non è quasi mai l’infrastruttura tecnica, ma la fiducia interpersonale che il mestiere stesso richiede di concedere a sconosciuti. Un attaccante di livello statale che parla la lingua del settore — propone uno scoop, cita eventi reali, imita lo stile di un collega — supera in un colpo solo gran parte delle difese tecniche standard, perché la vittima interagisce volontariamente con il contenuto malevolo.

Per i team di sicurezza che proteggono realtà editoriali o organizzazioni esposte, le raccomandazioni diffuse da Shin Bet restano il primo presidio praticabile:

Verificare l’identità di chi propone collaborazioni o interviste tramite un canale separato da quello di primo contatto, prima di aprire qualunque link o allegato;

Non inserire mai credenziali dopo aver seguito un link ricevuto in chat, per quanto il mittente sembri legittimo — meglio digitare manualmente l’indirizzo del servizio;

Attivare l’autenticazione a due fattori tramite app authenticator (non SMS) su tutti gli account di posta e cloud storage;

Impostare indirizzi di recupero account separati e monitorati;

Segmentare i dispositivi usati per il lavoro giornalistico da quelli personali, quando possibile, e mantenere aggiornati i sistemi operativi mobili.

Handala dimostra ancora una volta come i confini tra hacktivismo, spionaggio statale e guerra dell’informazione si siano ormai dissolti: lo stesso gruppo che rivendica breach “per la causa” su Telegram può, il giorno dopo, star raccogliendo materiale per un dossier destinato ai servizi. Per i difensori, l’unica postura sensata è trattare ogni contatto non sollecitato — anche il più credibile — come potenzialmente ostile.

Indicatori e riferimentiAttore: Handala (Handala Hack Team) — collegato al MOIS iraniano
Vettori: WhatsApp, Telegram
TTP: impersonificazione di giornalisti/contatti noti, phishing credenziali Google,
Google Drive link contraffatti, allegati malevoli per compromissione mobile
Target: giornalisti e figure pubbliche israeliane (es. redazioni come Haaretz)
Incriminazione USA: marzo 2026 (Dipartimento di Giustizia, MOIS)
Allerta ufficiale: Shin Bet + National Cyber Directorate, 16 agosto 2026
Canale di segnalazione IL: hotline 119 (National Cyber Directorate)

Si parla di:

Toggle

Una pagina che imita alla perfezione la schermata di aggiornamento di #Google #Chrome, un dropper che scarica il payload reale solo dopo, e un abuso sistematico dei servizi di accessibilità #Android per leggere in tempo reale le chat di #Telegram, #WhatsApp e #Signal senza mai toccare la loro crittografia end-to-end. È DragonDoll, lo #spyware commerciale che il Positive Technologies Expert #Security Center (PT ESC) ha tracciato in almeno 26 Paesi, #Russia inclusa, con circa 150 campioni caricati in appena due mesi su un repository #GitHub pubblico.

Un finto aggiornamento, un dropper veroLa catena d’infezione comincia con un APK che si spaccia per “Chrome.apk” e adotta la tecnica dei tampered headers per ostacolare gli strumenti di analisi statica. Una volta installato, il file mostra una pagina-esca che riproduce fedelmente il branding di un aggiornamento ufficiale di Google Chrome, convincendo l’utente a proseguire con l’installazione. Solo a questo punto il dropper scarica ed esegue il payload reale, denominato internamente K3iwv7VF.apk, decifrato con AES-256-GCM tramite implementazione nativa (libreria compilata in C/C++, non in Java/Kotlin), un’ulteriore misura anti-analisi rispetto ai più comuni spyware Android scritti interamente in linguaggio gestito.

Il vero motore: l’abuso dell’AccessibilityServiceDragonDoll non sfrutta exploit del kernel o vulnerabilità 0-day: si affida quasi interamente all’AccessibilityService di Android, l’API pensata per rendere il sistema operativo utilizzabile da persone con disabilità visive. Una volta ottenuto il permesso — spesso concesso dalla vittima stessa, ingannata dalla schermata di richiesta mascherata da parte del sistema — lo spyware può:

Intercettare tap, gesture e input da tastiera in tempo reale su qualsiasi app in primo piano.

Leggere il contenuto delle notifiche, incluse quelle di Telegram (liste chat, contatti, testo dei messaggi e timestamp) man mano che arrivano, senza dover violare la cifratura del protocollo.

Monitorare visivamente lo schermo durante l’uso di WhatsApp e Signal, catturando ciò che compare a video anche quando l’app stessa è protetta da crittografia end-to-end.

Iniettare overlay fasulli sopra app bancarie per sottrarre credenziali (banking overlay injection), una tecnica presa in prestito dai trojan bancari Android più maturi.

Raccogliere contatti, SMS, log delle chiamate, screenshot, stato di batteria/Wi-Fi/USB/SIM, IMEI e la lista completa delle app installate.

Per app meno “prioritarie” come Viber, il malware si limita a una raccolta più semplice dei dati visibili a schermo, segno di uno sviluppo modulare e mirato piuttosto che di un tool generico riadattato.

Una campagna globale, con targeting linguistico chirurgicoPT ESC ha individuato la campagna per la prima volta nella primavera 2026, durante l’analisi di attacchi contro utenti in Arabia Saudita, per poi scoprire un’infrastruttura di distribuzione molto più ampia: oltre 26 Paesi colpiti, tra cui Russia, Cina, Corea del Sud e diversi Stati dell’area MENA, con il malware localizzato in 34 lingue di interfaccia. Tra il 6 marzo e il 6 maggio 2026 sono stati caricati circa 150 campioni unici su un account GitHub (kesmanta24, registrato con l’indirizzo kesmantes52@outlook.com), arrivati almeno alle versioni 9.3 e 9.4 — un ritmo di sviluppo che tradisce un progetto attivamente mantenuto e monetizzato, non un esperimento estemporaneo.

L’infrastruttura di comando e controllo si appoggia al dominio channelzones[.]co, ospitato su hosting russo, con canali di comunicazione bidirezionale basati su Socket.IO e autenticazione tramite OkHttp3; la cifratura del traffico combina AES-256-CBC e RSA OAEP in uno schema ibrido. La distribuzione iniziale avviene tramite domini civetta come datewithmealways[.]site, datewithmealways[.]online e digitaladstracking[.]com, pensati per superare filtri di reputazione e ingannare l’utente con nomi apparentemente innocui o a tema dating/advertising.

Perché conta: il mercato in espansione dello spyware commerciale AndroidDragonDoll si inserisce in un trend che i ricercatori osservano da tempo: la proliferazione di famiglie spyware Android vendute o distribuite su scala industriale, capaci di aggirare la crittografia end-to-end di app come Signal e WhatsApp non attaccando il protocollo, ma il dispositivo stesso attraverso funzioni di sistema legittime come l’accessibilità. È lo stesso principio dietro altre famiglie recenti individuate mascherate da versioni “clonate” di Telegram e Signal distribuite anche tramite store ufficiali, un problema che ha spinto più volte Google a rafforzare i controlli su Play Protect senza però eliminare il rischio quando l’installazione avviene tramite sideloading da pagine web esterne, come nel caso di DragonDoll.

La presenza della Russia tra i Paesi bersaglio, insieme a un’infrastruttura C2 ospitata proprio su hosting russo, è un dettaglio che PT ESC segnala senza sciogliere del tutto l’ambiguità sull’attribuzione: non è chiaro se si tratti di un operatore locale che colpisce anche il proprio mercato interno, di un tool venduto a più clienti con targeting indipendente, o di un’operazione di sorveglianza mirata mascherata da campagna commerciale opportunistica.

Come proteggersiNon installare mai aggiornamenti di Chrome (o di qualsiasi altra app) da pagine web esterne al Google Play Store: gli aggiornamenti legittimi non vengono mai proposti così.

Verificare periodicamente in Impostazioni → Accessibilità quali app hanno permessi attivi e revocarli per tutto ciò che non sia uno strumento di assistenza riconosciuto.

Diffidare di APK scaricati da domini a tema dating, advertising o “aggiornamento urgente”, tipici vettori di distribuzione di questa famiglia.

Su dispositivi aziendali o ad alto rischio, disabilitare il sideloading e imporre policy MDM che blocchino l’installazione da fonti sconosciute.

Monitorare traffico di rete verso i domini e l’infrastruttura elencati di seguito come indicatori di compromissione.

Indicatori di compromissione# Infrastruttura C2 e distribuzione
channelzones[.]co (C2 primario, hosting russo, canale Socket.IO)
datewithmealways[.]site (dominio di distribuzione)
datewithmealways[.]online (dominio di distribuzione)
digitaladstracking[.]com (dominio di distribuzione)

Account di sviluppo

GitHub user: kesmanta24
Email associata: kesmantes52@outlook.com
Periodo attivita': 6 marzo - 6 maggio 2026 (~150 campioni, versioni 9.3-9.4)

Nomi file osservati

Chrome.apk (dropper iniziale, tampered headers)
K3iwv7VF.apk (payload finale, AES-256-GCM nativo)

Paesi colpiti (parziale)

Arabia Saudita, Russia, Cina, Corea del Sud, area MENA (26+ Paesi totali)
Localizzazione: 34 lingue di interfaccia

Cifratura

Dropper -> payload: AES-256-GCM (nativo)
C2: AES-256-CBC + RSA OAEP (ibrido), autenticazione OkHttp3, canale Socket.IOFonte primaria: Positive Technologies Expert Security Center (PT ESC). Dettagli tecnici e IoC aggiornati al momento della pubblicazione; per l’elenco completo di hash e domini si rimanda al report integrale dei ricercatori.

Si parla di:

Toggle

#SAP ha rilasciato la #patch l’11 agosto. Tre giorni dopo, gli honeypot dell’azienda di threat intelligence Defused hanno registrato i primi tentativi di sfruttamento. Nessun proof-of-concept pubblico, nessun writeup tecnico in circolazione: qualcuno ha fatto reverse engineering della patch – o conosceva già la falla – più in fretta di quanto la community difensiva riuscisse a reagire. La vulnerabilità, #CVE-2026-58231, ha un CVSS di 10.0: il massimo possibile, per una piattaforma usata da alcuni dei più grandi retailer al mondo.

La falla: un client di autenticazione dimenticatoCVE-2026-58231 risiede nell’estensione #Data Hub Adapter di SAP Commerce #Cloud, la piattaforma e-commerce nota fino a pochi anni fa come SAP Hybris. Secondo l’advisory ufficiale, controlli di autorizzazione insufficienti e una validazione dell’input carente permettono a un attaccante non autenticato di “abusare di un client di autenticazione predefinito” e sottoporre input appositamente costruiti al sistema. Il risultato è esecuzione di codice arbitraria in remoto (#RCE), raggiungibile con complessità di attacco bassa e senza alcuna credenziale: la combinazione che giustifica il punteggio massimo di gravità.

SAP Commerce Cloud non è un prodotto di nicchia: è l’infrastruttura e-commerce dietro cataloghi, checkout e gestione ordini di catene retail, produttori e distributori a livello globale. Una RCE non autenticata su questo layer significa accesso diretto a dati di pagamento, anagrafiche clienti e, potenzialmente, un punto di ingresso verso i sistemi ERP interni a cui Commerce Cloud è tipicamente integrato.

Tre giorni: dalla patch al primo probeLa finestra temporale è ciò che rende questo caso degno di nota. SAP ha pubblicato la correzione l’11 agosto 2026 tramite la #security note 3771065. Il 14 agosto, Defused ha osservato sui propri sensori i primi tentativi di exploitation, comunicandolo pubblicamente su X. Shadowserver Foundation, che traccia costantemente l’esposizione #internet di SAP Commerce Cloud tramite fingerprinting, segnala oltre 4.200 indirizzi IP con firma compatibile con la piattaforma – la superficie di attacco potenziale su cui gli scanner automatizzati si stanno già muovendo.

Tre giorni sono un tempo sufficiente per un diffing accurato della patch (confrontando i binari o i sorgenti pre e post correzione per isolare il codice modificato e dedurre la vulnerabilità), ma insolitamente rapido per la complessità tipica delle applicazioni enterprise Java di SAP. Onapsis, società specializzata nella sicurezza degli ambienti SAP, non esclude che gli attaccanti stiano semplicemente testando in massa endpoint esposti sperando di trovare installazioni non ancora patchate, un pattern comune subito dopo il rilascio di patch critiche per software enterprise molto diffuso.

Il precedente che preoccupa i difensoriSAP Commerce Cloud e le altre piattaforme della galassia SAP non sono nuove a questo tipo di attenzione. Nel maggio 2025, la vulnerabilità gemella CVE-2025-31324 in SAP NetWeaver Visual Composer fu sfruttata da almeno un cluster di attività riconducibile a operazioni di cyberspionaggio cinesi per compromettere oltre 580 sistemi critici a livello globale, secondo l’analisi di EclecticIQ, prima che gruppi ransomware si aggiungessero alla caccia agli endpoint non patchati. Lo schema si ripete con regolarità: le vulnerabilità critiche nei sistemi SAP attirano prima attori sofisticati orientati all’intelligence, interessati all’accesso silenzioso a dati finanziari e di supply chain, e solo in un secondo momento la criminalità informatica opportunistica in cerca di un punto d’appoggio da rivendere o da usare per il deployment di ransomware.

Per ora non ci sono attribuzioni pubbliche legate ai probe osservati su CVE-2026-58231: i dati disponibili derivano da honeypot e da telemetria di scansione, non da un’intrusione confermata con post-exploitation osservata. Ma la storia recente di SAP suggerisce che la finestra tra probe automatizzati e sfruttamento mirato da parte di attori più sofisticati tende a essere breve.

Cosa devono fare i team di sicurezzaApplicare immediatamente la security note SAP 3771065, aggiornando ai livelli di patch corretti per Commerce Cloud

Dove l’aggiornamento immediato non è possibile, ricompilare e ridistribuire la versione corretta appena disponibile una finestra di manutenzione

Come mitigazione temporanea, configurare un IP Filter Set per limitare l’accesso all’endpoint del Data Hub Adapter alle sole reti fidate

Verificare nei log applicativi richieste anomale dirette agli endpoint di Data Hub Adapter nei giorni successivi all’11 agosto

Monitorare gli avvisi di Shadowserver e della propria threat intelligence per indicatori di scansione mirata verso il proprio range IP

Trattare qualsiasi istanza Commerce Cloud esposta a Internet e non patchata come potenzialmente già compromessa, avviando attività di hunting sui sistemi integrati (ERP, data warehouse, gateway di pagamento)

Il messaggio per chi gestisce ambienti SAP è lo stesso che si ripete a ogni ciclo di patch critiche in software enterprise molto esposto: il tempo tra il rilascio di una correzione e la sua trasformazione in arma da parte degli attaccanti si sta comprimendo, e in questo caso specifico non c’è stato nemmeno bisogno di un proof-of-concept pubblico per accorciarlo ulteriormente.

Dettagli tecnici# Vulnerabilità
CVE-2026-58231
CVSS 3.1: 10.0 (Critico)
Componente: SAP Commerce Cloud - estensione Data Hub Adapter
Tipo: Autorizzazione impropria + input validation carente -> RCE non autenticata

Timeline

2026-08-11 Rilascio patch (SAP Security Note 3771065)
2026-08-14 Primi tentativi di exploitation osservati (Defused, honeypot)
2026-08-17 Oltre 4.200 IP con fingerprint SAP Commerce Cloud tracciati da Shadowserver

Mitigazione

• Applicare Security Note 3771065
• IP Filter Set sull'endpoint Data Hub Adapter come workaround temporaneo

Precedente correlato

CVE-2025-31324 - SAP NetWeaver Visual Composer, sfruttata da cluster
di cyberspionaggio cinesi su 580+ sistemi critici (maggio 2025)Fonti: The Hacker News, BleepingComputer, SecurityAffairs, GBHackers, Onapsis, Shadowserver Foundation, EclecticIQ.

Si parla di:

Toggle

Un driver #kernel firmato, tre stadi di caricamento cifrati e un binario legittimo Sangfor usato come cavallo di Troia: è la nuova versione di CoolClient, la #backdoor con cui il gruppo di #cyberspionaggio cinese HoneyMyte (alias Mustang Panda) sta colpendo enti #governativi in #Myanmar, #Mongolia, #Pakistan e Russia. La novità che fa scattare l’allarme tra i ricercatori non è la campagna in sé — HoneyMyte è attivo da oltre un decennio — ma l’aggiunta di un #rootkit a livello kernel che rende l’impianto praticamente invisibile agli strumenti di #sicurezza tradizionali.

Chi è HoneyMyte e perché la sua evoluzione contaHoneyMyte, meglio noto nella letteratura di settore come Mustang Panda (o anche Bronze President, Red Delta, Stately Taurus a seconda del vendor), è uno dei gruppi APT cinesi più prolifici degli ultimi anni. Il suo modus operandi classico prevede campagne di spear-phishing e compromissioni mirate contro ministeri, agenzie governative e ONG in Asia, con incursioni sempre più frequenti anche verso l’Europa dell’Est e la Russia — un dettaglio che conferma come la geografia dello spionaggio cinese non si limiti più al solo vicinato asiatico.

Il gruppo è storicamente associato a PlugX, uno dei RAT più longevi e riutilizzati nell’ecosistema APT cinese, spesso impiegato come primo impianto post-compromissione prima del rilascio di payload più specializzati. Secondo l’analisi tecnica pubblicata da Kaspersky Securelist, è esattamente questo lo schema osservato nella campagna più recente: PlugX apre la porta, CoolClient la blinda dall’interno.

La catena di infezione: da un binario Sangfor al rootkit kernelLa sofisticazione della catena di compromissione è il vero elemento di interesse tecnico. Dopo l’accesso iniziale tramite PlugX, gli operatori HoneyMyte rilasciano un eseguibile legittimo del vendor di sicurezza Sangfor (rinominato defender.exe), sfruttato come DLL sideloader per caricare libngs.dll, il primo stadio offuscato con XOR a 32 byte. Questo a sua volta decifra e carica loadcert.ini, un secondo stadio che gestisce i comandi e orchestra l’installazione del driver.

Il payload viene quindi iniettato nel processo synchost.exe, mentre il componente più critico dell’intera catena — il driver kernel msagent.sys — viene installato come servizio Windows (media_updaten) con persistenza garantita anche tramite chiave di registro AutoRun. Il driver risulta firmato con un certificato digitale intestato a Nanjing Ranyi Technology Co., Ltd., valido nel biennio 2013-2014: una firma probabilmente rubata o riutilizzata, prassi comune tra gli attori APT cinesi per garantire ai propri driver il caricamento senza generare allarmi da parte di Driver Signature Enforcement.

Cosa fa davvero il rootkitUna volta caricato, msagent.sys mette a disposizione dell’impianto un set di 33 handler IOCTL, di cui solo 3 effettivamente utilizzati dalla versione corrente di CoolClient — segno che il driver è pensato come piattaforma riutilizzabile per operazioni future, non come strumento usa e getta. Le capacità osservate includono:

Occultamento del processo CoolClient tramite scollegamento dalla PsLoadedModuleList

Protezione di file e directory attraverso un minifilter con altitudine assegnata dinamicamente per evitare conflitti con altri driver installati

Protezione delle chiavi di registro associate all’impianto (es. Wid_H1deF5Dirs)

Filtraggio del traffico di rete via Nsiproxy per nascondere le connessioni verso l’infrastruttura C2

Hook sugli oggetti processo e thread tramite ObRegisterCallbacks, per bloccare l’accesso di EDR e antivirus al processo protetto

Il payload finale, cert.ini, gestisce le comunicazioni verso un’infrastruttura C2 piuttosto ampia e diversificata, che mescola domini dynamic DNS, servizi di hosting gratuito e domini camuffati da marchi legittimi come Lenovo — una tecnica di mimetizzazione tipica per superare i controlli basati su reputazione.

Perché conta per i difensoriL’uso di un rootkit kernel-mode alza sensibilmente l’asticella per il rilevamento: molti EDR faticano a ispezionare in profondità il comportamento dei driver firmati, specialmente quando l’altitudine del minifilter viene assegnata dinamicamente proprio per evitare collisioni rilevabili. Per i team di detection engineering, la superficie di hunting più promettente resta quella comportamentale: caricamento anomalo di driver con certificati datati o revocati, servizi Windows con nomi generici tipo “media_updaten”, processi synchost.exe con parent process inatteso, e DLL sideloading su binari di sicurezza legittimi come quelli Sangfor — tecnica, quest’ultima, sempre più gettonata proprio perché i prodotti di sicurezza godono di whitelist implicite.

La geografia delle vittime — Myanmar, Mongolia, Pakistan e Russia — conferma inoltre come HoneyMyte mantenga un interesse costante verso i vicini asiatici della Cina e, sempre più spesso, verso obiettivi russi: un segnale che nemmeno le relazioni diplomatiche tra Pechino e Mosca mettono al riparo Mosca dall’intelligence gathering cinese.

Indicatori di compromissione# Hash
msagent.sys (driver kernel): 2d7c8780e97409770a9d4f31c66c9d63 / 9460E150E1981D5C165043520C5C12FE
libngs.dll (loader stage 1): 9717F005C5FB98E08D2AD983D88F94EE / F518D8E5FE70D9090F6280C68A95998F
ctxmui.dll: EB79558B037669792652A816E2C669DE

Domini C2

cloudtroe.giize[.]com
employers.theworkpc[.]com
freeread.casacam[.]net
us.lenovoappstore[.]com
sundanish.freeddns[.]org
torinarlabs.webredirect[.]org
news.dursamjbataar[.]org
video.dursamjbataar[.]org
black-popular[.]com
whatismybestthing[.]com

Percorsi di installazione

C:\Program Files\Microsoft\Windows Defender
C:\Program Files\Windows Media Player\mediares
C:\ProgramData\symantecdir\

TTP MITRE ATT&CK

T1574.002 - DLL Side-Loading (binario Sangfor)
T1547.001 - Persistenza via registro AutoRun
T1134.003 - Process injection (synchost.exe)
T1548.004 - UAC bypass (RPC + PPID spoofing)
T1547.011 - Servizio Windows dannoso (media_updaten)
T1112 - Manipolazione chiavi di registro
T1562.008 - Disabilitazione esclusioni Windows Defender via WMIC
T1014 - Rootkit kernel-mode
T1047 - Windows Management InstrumentationFonte tecnica principale: Kaspersky Securelist.

🐀🎓 Cybersecurity Advanced Class 9

📡 EVIL TWIN

Una rete Wi-Fi può sembrare quella ufficiale, ma essere una copia creata da un attaccante. Con un “Evil Twin” si tenta di convincere gli utenti a collegarsi al falso Access Point per intercettare o manipolare le comunicazioni.

SSID identico ≠ rete affidabile.

@sicurezza

#CyberSecurity #WiFi #EvilTwin #InfoSec #NextRed

Si parla di:

Toggle

Il 10 agosto una turbina idroelettrica nei pressi di Danzica ha iniziato a impazzire: giri al minuto e potenza generata hanno oscillato in modo erratico fino all’arresto forzato del gruppo generatore-rotore. Non un guasto meccanico, ma la seconda intrusione andata a segno in pochi mesi contro lo stesso impianto, rivendicata con tanto di video dagli stessi attaccanti. È l’ultimo episodio di una campagna che il #CERT Polska descrive ormai come sistematica contro il settore energetico e idrico del Paese, e che affonda le radici in un attacco ben più ampio, condotto a fine dicembre 2025 dal gruppo #APT russo #Sandworm contro una trentina di siti tra centrali di cogenerazione e centri di dispacciamento rinnovabili.

Un impianto già colpito, questa volta a pieno regimeLa centrale presa di mira si trova a Tczew, nel voivodato della Pomerania, ed era già stata bersaglio di un primo tentativo a maggio 2026, fallito perché l’impianto era #offline per manutenzione e l’impatto operativo fu quindi nullo. Il 10 agosto, invece, gli attaccanti sono riusciti a operare mentre la centrale era pienamente funzionante: la prima volta, secondo gli analisti polacchi, che questo specifico gruppo di hacktivisti filo-russi ottiene un’interferenza reale sui parametri di produzione. Una volta dentro l’interfaccia di controllo, hanno spinto i valori operativi ai loro estremi — minimo o massimo — fino a costringere generatore e rotore all’arresto. I dati di monitoraggio del giorno dell’attacco mostrano picchi anomali di velocità di rotazione e livello dell’acqua, alternati a periodi di potenza erogata pari a zero: la firma tipica di una manipolazione manuale del pannello SCADA, non di un errore di processo.

Gli stessi autori hanno pubblicato un video dell’intrusione, un dettaglio che negli ambienti di #cybercrime filorusso serve tanto a rivendicare la paternità dell’attacco quanto a intimidire altri operatori del settore. L’attribuzione a un attore specifico resta fluida: gruppi come #Cyber Army of #Russia Reborn e la galassia riconducibile a Sandworm operano spesso in una zona grigia tra hacktivismo spontaneo e operazioni orchestrate dai servizi militari russi (GRU), rendendo la distinzione tra “protesta” e sabotaggio di stato sempre più teorica.

Il precedente: come un router in un parco eolico ha aperto la porta a un impianto di teleriscaldamentoPer capire la portata della minaccia occorre guardare a un #report pubblicato in contemporanea dal CERT Polska, che ricostruisce nel dettaglio un secondo attacco avvenuto in parallelo a quello di fine dicembre 2025 contro il settore energetico polacco, fino ad ora meno noto. Il bersaglio era un piccolo impianto di cogenerazione (CHP) che fornisce calore a circa 50.000 residenti. L’obiettivo, scrive il CERT, era “puramente distruttivo”.

La catena di intrusione è particolarmente istruttiva perché introduce una tecnica mai documentata prima in #Polonia né altrove: il pivoting attraverso una APN privata (Access Point Name), la rete cellulare dedicata che i distributori di #energia (DSO) usano per far comunicare i propri sistemi SCADA con gli apparati di campo installati nelle sottostazioni.

Accesso iniziale tramite un dispositivo Fortinet VPN/firewall esposto su internet e installato presso un parco eolico.

Dalla stessa rete, individuazione di un router cellulare Teltonika e accesso alla sua interfaccia di amministrazione.

Abuso del servizio SSH del router per creare un tunnel verso la APN privata gestita dal DSO, normalmente riservata al traffico SCADA legittimo.

Scansione della APN e individuazione di un PLC Wago attivo presso l’impianto CHP, anch’esso con SSH esposto: da qui, accesso diretto alla rete OT della centrale.

Dopo circa una settimana di ricognizione, connessione ai PLC Siemens, passaggio in modalità “stop” e impostazione di una password per impedire agli operatori di riprendere il controllo della logica di processo — con conseguente arresto della turbina a vapore e del sistema di trattamento acque.

Presi di mira anche server seriali e switch di rete Moxa, oltre a inverter/VFD ABB e Schneider Electric, configurati per bloccare l’accesso agli operatori legittimi.

Il personale dell’impianto è riuscito a limitare i tempi di fermo ripristinando i PLC alle impostazioni di fabbrica e ricaricando la logica dai backup. Ma non tutto è stato recuperabile: nel tentativo di cancellare le tracce, gli attaccanti hanno danneggiato in modo permanente il controller Wago usato come gateway d’accesso, corrompendone la tabella delle partizioni. Un successivo reset di fabbrica non è bastato a farlo ripartire, e il dispositivo è rimasto inutilizzabile — portando con sé anche i log necessari all’indagine forense.

DynoWiper e il contesto dell’attacco del dicembre 2025L’attacco alla APN privata va letto come parte della stessa ondata che il 29-30 dicembre 2025 colpì una trentina di siti energetici polacchi, incluse centrali di cogenerazione e centri di dispacciamento eolico e fotovoltaico. In quel caso ESET ha attribuito con confidenza media l’operazione a Sandworm, individuando l’uso di un nuovo wiper — battezzato DynoWiper e rilevato dai prodotti ESET come Win32/KillFiles.NMO — con tattiche molto simili al wiper ZOV già usato contro l’Ucraina. L’accesso iniziale in quel caso è avvenuto tramite dispositivi edge esposti su internet, seguito dalla distruzione di dati sulle interfacce HMI e dalla corruzione del firmware di alcuni apparati OT, causando danni permanenti ad alcune RTU (Remote Terminal Unit). L’operazione, va detto, è stata contenuta prima di provocare un blackout reale, e la tempistica — a ridosso del decimo anniversario dell’attacco alla rete elettrica ucraina del dicembre 2015 — non sembra casuale.

Il quadro complessivo che emerge da Tczew, dalla APN privata e da DynoWiper è quello di una pressione costante e multiforme sulle infrastrutture critiche polacche. Il vicepremier Krzysztof Gawkowski ha dichiarato che il Paese subisce oggi circa 300 attacchi al giorno di matrice russa, il triplo rispetto all’anno precedente, e che gli obiettivi spaziano dalla rete idrica a quella elettrica. Solo negli ultimi mesi sono stati colpiti impianti di trattamento acque a Szczytno, Sierakowo, Witków e il depuratore di Kuźnica, oltre a piscine e fontane pubbliche — bersagli minori ma sintomatici di una strategia che punta a normalizzare l’intrusione in qualunque sistema OT raggiungibile, non solo nei nodi strategici. Un pattern che ricorda da vicino quanto osservato in Norvegia, dove hacker filorussi hanno manipolato le valvole di una diga, e negli Stati Uniti e in Francia, dove impianti idrici sono stati presi di mira con le stesse modalità opportunistiche.

Due righe per i difensoriIl filo conduttore tra i due episodi polacchi è la superficie di attacco “dimenticata”: dispositivi edge esposti (VPN/firewall Fortinet), router cellulari con interfacce di amministrazione raggiungibili, servizi SSH lasciati attivi su PLC e gateway pensati per reti “isolate” ma di fatto raggiungibili tramite APN condivise con altri operatori. Per chi gestisce ambienti OT/ICS, in particolare nel settore energetico e idrico, questo caso offre alcune lezioni operative concrete: segmentare rigorosamente le APN private evitando che un singolo dispositivo compromesso funga da ponte tra reti di operatori diversi; disabilitare SSH e altri servizi di gestione remota sui PLC quando non strettamente necessari, o quantomeno restringerne l’accesso con allowlist IP e MFA; monitorare le interfacce HMI/SCADA per variazioni anomale dei parametri operativi che non corrispondono a comandi degli operatori; e predisporre backup offline della logica PLC, testati periodicamente, dato che in entrambi i casi documentati sono stati proprio i backup a permettere un ripristino rapido.

Indicatori e riferimenti tecniciMalware: DynoWiper (ESET: Win32/KillFiles.NMO)
SHA-1 noto: 4EC3C90846AF6B79EE1A5188EEFA3FD21F6D4CF6
Attore: Sandworm (Russia, GRU-linked) - confidenza media
Vettore 1: dispositivi edge esposti (VPN/firewall Fortinet) - attacco 30 siti, dic. 2025
Vettore 2 (novel): pivot su APN privata via router cellulare Teltonika -> PLC Wago -> PLC Siemens (stop mode)
Apparati OT coinvolti: PLC Wago e Siemens, switch/serial server Moxa, VFD ABB/Schneider Electric
Impianto colpito 10 ago 2026: centrale idroelettrica di Tczew (Pomerania, Polonia)
Fonte primaria: report CERT Polska, follow-up settore energetico 2025Nessun blackout è stato causato finora da queste operazioni, ma il trend è inequivocabile: gli attaccanti stanno affinando tecniche di pivoting sempre più sofisticate per raggiungere reti OT considerate “air gapped” o comunque isolate, e la loro pazienza — settimane di ricognizione silenziosa prima di agire — dimostra un livello di preparazione che va ben oltre il semplice defacement dimostrativo.

Si parla di:

Toggle

Un singolo server compromesso, migliaia di endpoint amministrati a cascata: è lo scenario da incubo che si è materializzato dal 1° agosto 2026, quando un attore legato alla #Cina e già noto per l’affiliazione al ransomware #Medusa ha iniziato a sfruttare una vulnerabilità critica in N-central, la piattaforma di remote monitoring and management (#RMM) di N-able usata da migliaia di managed service provider in tutto il mondo. #Microsoft Threat Intelligence attribuisce la campagna al gruppo Storm-1175, che ha debuttato con un ceppo ransomware inedito, StormEncryptor, segnando un cambio di strategia rispetto al passato.

Da Medusa a StormEncryptor: chi è Storm-1175Storm-1175 è il nome con cui Microsoft traccia un attore finanziariamente motivato, ritenuto basato in Cina, specializzato in campagne ransomware “ad alta velocità”. Già ad aprile 2026 Microsoft aveva descritto il gruppo come capace di passare dall’accesso iniziale alla cifratura completa dei sistemi in meno di 24 ore, sfruttando sia vulnerabilità appena divulgate sia, in alcuni casi, zero-day exploitati fino a una settimana prima della disclosure pubblica. Le vittime storiche del gruppo, colpite tramite il ransomware Medusa, includono organizzazioni sanitarie, di servizi professionali e finanziarie in Australia, Regno Unito e Stati Uniti, spesso raggiunte tramite lo sfruttamento di prodotti esposti su internet come GoAnywhere MFT, SmarterMail, Microsoft Exchange, Ivanti Connect Secure e JetBrains TeamCity.

Il 2 agosto 2026 Microsoft ha osservato per la prima volta il dispiegamento di StormEncryptor, un nuovo ransomware scritto in C++ che aggiunge l’estensione .encrypted ai file cifrati e deposita in ogni cartella una nota di riscatto denominata “!!!README_FIRST!!!.txt”, con la consueta minaccia di pubblicazione dei dati rubati entro tre giorni in caso di mancato pagamento. Si tratta della prima attività osservata del gruppo dopo un periodo di silenzio dall’aprile 2026, e il tempismo — lo stesso giorno della divulgazione della falla in N-central — non lascia molti dubbi sul vettore di accesso iniziale.

CVE-2026-18577: un bypass di autenticazione con “poteri da dio”Il cuore tecnico della vicenda è CVE-2026-18577, una vulnerabilità di bypass dell’autenticazione in N-central che consente a un attaccante privo di qualsiasi credenziale di ottenere il controllo amministrativo completo del server. Si tratta, in realtà, di un bypass della patch che a sua volta correggeva un’altra falla, CVE-2026-18556: gli attaccanti hanno cioè trovato una variante capace di eludere i controlli introdotti dalla prima correzione. Huntress ha definito l’accesso ottenibile tramite questa falla un vero e proprio “god-mode access”: poiché gli MSP utilizzano N-central per amministrare da remoto le macchine dei propri clienti, la compromissione di un singolo server RMM diventa la porta d’ingresso verso ogni endpoint da esso gestito, con un potenziale effetto a cascata su decine di organizzazioni contemporaneamente. Non è un caso isolato nel suo genere: nel 2021 un attacco simile alla piattaforma RMM di Kaseya permise alla gang REvil di colpire inizialmente 60 clienti diretti e, a cascata, circa 1.500 aziende a valle; nel 2024 un episodio analogo coinvolse ConnectWise ScreenConnect, con Storm-1175 tra gli attori che ne approfittarono.

N-able ha individuato lo sfruttamento della falla per la prima volta il 31 luglio 2026, grazie alla soluzione MDR Adlumin, e ha rilasciato un primo hotfix (versione 2026.3.1.7) il 2 agosto. Non è bastato: gli attaccanti hanno trovato un modo per aggirare anche questa prima mitigazione, costringendo il vendor a pubblicare un secondo hotfix di emergenza (2026.3.1.10) il 6 agosto, con l’avvertenza esplicita che la prima patch da sola non fosse sufficiente. Nonostante la disponibilità delle correzioni, Huntress ha rilevato che oltre la metà dei server N-central cloud raggiungibili tra i propri partner risultava ancora non aggiornata, con il 28,6% delle istanze self-hosted ancora esposte.

La catena post-exploitationUna volta ottenuto l’accesso amministrativo a N-central, gli attaccanti sfruttano la funzionalità legittima “Take Control” per collegarsi agli endpoint gestiti e registrano un nuovo servizio per un tunnel Cloudflare, garantendosi persistenza. Sophos, che ha ampliato l’elenco di indicatori di compromissione condiviso inizialmente da N-able, ha osservato la creazione di un nuovo account di dominio chiamato “veeam” — probabilmente scelto per mimetizzarsi tra gli account di servizio legittimi legati ai backup — oltre al reset delle password di diversi account amministratore di dominio esistenti, l’enumerazione di altri account e la disattivazione delle soluzioni di sicurezza Microsoft e Sophos tramite uno strumento di EDR-evasion.

Secondo l’analisi condivisa da Microsoft, il comportamento post-compromissione di Storm-1175 in questa campagna include l’abuso di strumenti RMM legittimi come AnyDesk e SimpleHelp, l’uso di Advanced IP Scanner per la ricognizione della rete e il dump delle credenziali LSASS tramite Mimikatz — un playbook che privilegia strumenti “living off the land” e software di amministrazione remota già presenti o facilmente installabili, per confondersi con il traffico amministrativo legittimo generato dallo stesso N-central. Huntress, che ha osservato lo sfruttamento su ambienti di propri clienti, conferma che gli attaccanti si muovono rapidamente attraverso più host all’interno delle organizzazioni colpite, prendendo di mira in particolare i domain controller.

Implicazioni per MSP e clienti a valleIl numero esatto di organizzazioni colpite non è stato reso pubblico: N-able ha dichiarato di aver contattato un “numero limitato” di clienti interessati, mentre Huntress ha confermato impatti su propri clienti senza quantificarli. Ma la dinamica stessa dell’attacco — un fornitore RMM come singolo punto di fallimento per centinaia di aziende a valle — richiama da vicino Kaseya e ScreenConnect, e ribadisce un problema strutturale della filiera IT: la concentrazione di privilegi amministrativi in strumenti di gestione remota rende ogni MSP un moltiplicatore di rischio per l’intero proprio portafoglio clienti. Per chi utilizza N-central la priorità è immediata: applicare l’hotfix 2 (versione 2026.3.1.10), anche se è già stato applicato l’hotfix 1, e aggiornare gli agent sugli endpoint gestiti. Huntress raccomanda inoltre di valutare, per ambienti ad alto rischio dove l’esposizione non può essere ridotta in altro modo, la disattivazione temporanea di N-central, pur riconoscendo che ciò comporta la perdita di visibilità centralizzata, patching e accesso remoto proprio nel momento in cui potrebbero servire di più. Per i clienti finali degli MSP, la lezione è altrettanto rilevante: vale la pena chiedere al proprio fornitore quali strumenti RMM utilizza, se sono stati aggiornati, e quali controlli di segmentazione esistono tra l’infrastruttura di gestione e gli ambienti di produzione.

Indicatori di compromissioneVulnerabilità sfruttata:
CVE-2026-18577 (bypass di autenticazione in N-able N-central,
bypass della patch per CVE-2026-18556)

Ransomware:
StormEncryptor (C++, prima osservazione: 2 agosto 2026)
Estensione file cifrati: .encrypted
Nota di riscatto: !!!README_FIRST!!!.txt

Attore:
Storm-1175 (ex operatore/affiliato Medusa ransomware, presunta origine Cina)

Timeline:
31 luglio 2026 - N-able (Adlumin MDR) rileva sfruttamento zero-day
2 agosto 2026 - Hotfix 1 (N-central 2026.3.1.7) + prima StormEncryptor
6 agosto 2026 - Hotfix 2 (N-central 2026.3.1.10), il primo hotfix
risulta insufficiente

Tecniche post-exploitation osservate:
Abuso della funzione "Take Control" di N-central
Nuovo servizio per tunnel Cloudflare (persistenza)
Creazione account di dominio "veeam"
Reset password account amministratore di dominio
Disattivazione EDR Microsoft/Sophos tramite tool di evasione
Abuso di AnyDesk / SimpleHelp
Ricognizione con Advanced IP Scanner
Dump credenziali LSASS via Mimikatz

Precedenti storici affini:
2021 - Kaseya VSA / REvil (~1.500 aziende a valle)
2024 - ConnectWise ScreenConnect (Storm-1175 tra gli attori coinvolti)

Seven billion logs. That's what it took to reconstruct it, and they're not finished.

At Black Hat last week, OpenAI walked through how a swarm of agents — different evaluations, some of them different models entirely — worked out they could leave each other notes in a shared file repository. A stuck agent asked for help. That became a message board carrying hundreds of thousands of messages, where they traded exploits, handed off tasks, and started signing their posts to smoke out a suspected imposter. Shut the board down and they built another one in two days.

One worker pod to admin across multiple clusters in under thirteen hours.

Not the boards who eat that. The on-call analyst at 2am with a pager and cold coffee. The clinic running patient records on somebody else's cloud tenant, three people in IT, one of them also the office manager. The pharmacist looking a man in the eye, telling him his insulin comes tomorrow.

Automated offense is a documented fact now. Automated defense is a slide deck.

https://thistleandmoss.com/p/what-survives-the-morning-skynet-is-coming-we-are-all-dead?utm_source=PixelFed&utm_medium=social&utm_campaign=fedica

#InfoSec #CyberSecurity #BlackHat #OpenAI #HuggingFace #AI #Privacy #Linux #Journalism #IndependentMedia #Politics #Photography #DailyGathering #FuckAI #NoAI #StopAI #AIKills #Skynet

Si parla di:

Toggle

BlackFile si è “ritirata” a maggio. Poi è rinata come Redact, Pink, Helix e Falcon, quattro marchi di #estorsione apparentemente distinti ma tenuti insieme dalla stessa infrastruttura, dagli stessi template di phishing e dagli stessi operatori. #Google Threat Intelligence Group (#GTIG) ha appena pubblicato un aggiornamento che ricostruisce, dominio per dominio, come il gruppo che traccia come UNC6671 abbia trasformato il rebranding in una tecnica di offuscamento operativo, colpendo private equity, hedge fund e big del real estate con #vishing mirato e phishing #AiTM.

Un “fallimento” che non è mai avvenutoIl 27 giugno 2026 gli operatori di Redact hanno pubblicato sul proprio data leak site (DLS) un lungo post per spiegare la fine di BlackFile. Versione ufficiale: un affiliato “in fuga” avrebbe dirottato il marchio, gestendo un DLS clone e conducendo estorsioni non autorizzate con identità Tox slegate da quelle originali, orchestrando persino il falso annuncio di chiusura di maggio 2026 per confondere gli analisti di threat #intelligence e i negoziatori delle assicurazioni cyber. Per prendere le distanze, il gruppo ha introdotto un singolo Tox ID verificato e una chiave PGP per autenticare tutte le comunicazioni future, negando esplicitamente che il rebranding fosse una risposta a pressioni di gruppi rivali.

GTIG non ci crede, o meglio: la telemetria racconta un’altra storia. L’analisi dell’infrastruttura mostra sovrapposizioni sistematiche tra le vittime rivendicate da Redact, Pink, Helix e Falcon, con gli stessi domini root utilizzati in sequenza per colpire organizzazioni poi rivendicate su DLS diversi. La spiegazione più probabile, secondo i ricercatori, è che un nucleo comune di threat actor gestisca più brand di estorsione pubblici in parallelo, per compartimentare le operazioni, nascondere il volume reale delle violazioni e isolare eventuali ripercussioni nelle trattative di riscatto. Restano sul tavolo anche ipotesi alternative — scissione di affiliati, uso condiviso di un ecosistema di phishing-as-a-service, o outsourcing della fase di negoziazione — ma il filo tecnico che lega i marchi è innegabile.

La stessa toolchain, riciclata su domini diversiUNC6671 non è un gruppo di intrusione sofisticato dal punto di vista del malware: il suo vantaggio competitivo è l’ingegneria sociale telefonica. Gli operatori chiamano dipendenti aziendali sui loro numeri di cellulare personali, aggirando i controlli di sicurezza aziendali, spacciandosi per l’help desk IT e comunicando l’urgenza di una “migrazione di sicurezza obbligatoria” — tipicamente l’attivazione di una passkey FIDO2 o l’aggiornamento della configurazione MFA. In alcuni casi recenti gli operatori hanno persino spoofato il numero di telefono legittimo dell’help desk per aumentare la credibilità della chiamata.

La vittima viene indirizzata verso un sottodominio civetta (ad esempio [azienda].createssopasskey[.]com o [azienda].addssopasskey[.]com) che ospita un pannello Adversary-in-the-Middle: le credenziali e i token MFA inseriti vengono intercettati in tempo reale, dando agli attaccanti una sessione autenticata valida. Da lì, script automatizzati esfiltrano dati direttamente dagli ambienti SaaS aziendali, in particolare Microsoft 365 e Okta, senza bisogno di malware persistente sull’endpoint.

GTIG ha ricostruito la catena infrastrutturale che collega i marchi: il dominio passkeyhelpdesk[.]com, ad esempio, è stato usato per colpire un’organizzazione poi rivendicata da Falcon e, contemporaneamente, un’altra rivendicata da Helix. Domini come portalpasskey[.]com e addssopasskey[.]com hanno fatto da ponte intermedio verso l’infrastruttura Helix, mentre cluster come oskeysync[.]com e keysyncos[.]com collegano vittime intermedie ai leak site Helix. Sul fronte Pink, domini come passkeyms[.]com e mysecurepasskey[.]com fungono da bridge verso passkeydeploy[.]com. L’analisi del codice dei pannelli di phishing conferma che template identici, byte per byte, sono stati ospitati simultaneamente su domini diversi, usati per rivendicazioni di brand diversi.

Dal manifatturiero alla finanza: l’evoluzione del targetingLa scelta dei bersagli non è casuale e segue una progressione chiara. Tra aprile e maggio 2026 UNC6671 ha colpito in modo ampio grandi aziende manifatturiere, immobiliari, sanitarie e assicurative, privilegiando la raccolta massiva di credenziali. A giugno il focus si è spostato su tecnologia, trasporti e ospitalità, verticali che custodiscono proprietà intellettuale, codice sorgente o dati sensibili di clienti VIP. A luglio il targeting si è ristretto ulteriormente su finanza e settore legale, con infrastruttura dedicata a fondi di private equity, studi legali e agenzie di rating finanziario: aziende coinvolte in fusioni, acquisizioni, deployment di capitale e contenziosi, dove il valore dei dati riservati massimizza la leva estorsiva.

Tra le vittime attribuite alle attività Falcon, Helix, Pink e Redact figurano nomi di primo piano del mondo finanziario, tra cui Apollo Global Management, Bain Capital, Blackstone, Bridgewater Associates, CME Group, KKR, Moody’s e TPG. Il ritmo operativo è aumentato in parallelo: tra giugno e luglio 2026 GTIG ha osservato un nuovo dominio ogni 1,6 giorni in media (contro un dominio ogni 2,2 giorni nel periodo aprile-maggio), con un picco di sette domini attivati in 72 ore tra il 20 e il 22 luglio. Alla data di pubblicazione del report, 7 degli 8 domini di phishing ancora risolvibili non usavano DNS wildcard, segno che le vittime individuate tramite dati DNS passivi erano bersagli specificamente selezionati.

Evasione e monetizzazioneOltre al vishing, GTIG segnala tecniche di evasione più mature: in diverse intrusioni recenti gli operatori hanno usato account email compromessi per avviare reset password non autorizzati su applicazioni enterprise prive di SSO, cancellando sistematicamente le notifiche di conferma reset, gli alert di sicurezza aziendali e qualsiasi avviso generato da modifiche a MFA o impostazioni di sicurezza dell’account, per evitare che l’utente o i sistemi di detection si accorgano della compromissione.

Sul fronte finanziario, l’analisi blockchain condotta da GTIG (con l’assistenza del ricercatore ZachXBT) su 18 wallet Bitcoin collegati a BlackFile, monitorati tra il 7 gennaio e il 12 maggio 2026, ha registrato un totale di 141,65 BTC ricevuti, circa 10,69 milioni di dollari al cambio dell’epoca. Significativamente, i pagamenti di riscatto sono proseguiti anche dopo il presunto annuncio di chiusura del DLS BlackFile dell’11 maggio 2026, con eventi di cash-out rilevanti tra fine aprile e inizio maggio che confermano la continuità operativa durante la fase di rebranding. Le richieste di riscatto iniziali variano da 1 a oltre 3 milioni di dollari, ma gli operatori concedono riduzioni del 50-75% in fase di negoziazione: in oltre il 53% dei casi tracciati, il pagamento finale si è attestato in media sui 750.000 dollari (circa 10,2 BTC).

Come difendersiIl denominatore comune di tutte le intrusioni UNC6671 è l’identità: vishing, intercettazione di sessione AiTM ed esfiltrazione SaaS programmatica. GTIG raccomanda ai difensori un set di controlli mirati:

Autenticazione phishing-resistant obbligatoria: passkey e chiavi di sicurezza FIDO2, Windows Hello for Business, Okta FastPass su tutti gli ambienti SSO e identity provider, per rendere inutilizzabili i proxy AiTM grazie al binding crittografico dell’origine previsto da WebAuthn.

Integrazione di tutte le applicazioni SaaS con un SSO centralizzato (Entra ID, Okta) per evitare configuration drift tra piattaforme.

Sessioni più corte, re-autenticazione giornaliera obbligatoria, timeout di inattività stringenti soprattutto per gli accessi privilegiati, e step-up authentication sulle risorse sensibili.

Restrizione dell’autenticazione a fonti di rete fidate (VPN aziendale, SASE) e richiesta di dispositivi gestiti (MDM/EDR) per l’accesso.

Alert su Google Workspace Password Alert e su Microsoft Defender SmartScreen/Credential Protection per bloccare l’inserimento di credenziali su domini non verificati.

Monitoraggio dei log IdP per pattern di “abandoned challenge”: eventi di registrazione MFA (system.multifactor.factor.setup) preceduti da fallimenti di autenticazione o push challenge abbandonate.

Audit degli eventi FileAccessed con la stessa criticità dei FileDownloaded quando lo user-agent è una libreria di scripting (python-requests, WindowsPowerShell, Go-http-client) o il volume di accesso supera le soglie di normale navigazione umana.

Alert su autenticazioni SSO da VPN commerciali (Mullvad, Private Layer) o pool di proxy residenziali (AT&T, Comcast, Charter) che divergono dalla baseline geografica abituale del dipendente.

Il caso UNC6671 è un promemoria utile per chi analizza il crimine informatico organizzato: i brand di estorsione sono etichette usa e getta, non entità stabili. Concentrarsi solo sul nome che compare nel DLS rischia di far perdere di vista la vera unità di minaccia — l’infrastruttura, le TTP, gli operatori — che sopravvive intatta a ogni “chiusura” annunciata.

Indicatori di compromissione (IoC)Domini di phishing (selezione recente, luglio-agosto 2026):
passkeyhelpdesk[.]com
addssopasskey[.]com
createssopasskey[.]com
portalpasskey[.]com
passkeydeploy[.]com
oskeysync[.]com
keysyncos[.]com
myssopasskey[.]com
hubpasskey[.]com
passkeymfa[.]com
ssopasskey[.]com

Infrastruttura di rete:
31.7.56.61 - Panel AiTM Reverse Proxy - AS51852 Private Layer INC (CH)
31.7.56.52 - Panel AiTM Reverse Proxy - AS51852 Private Layer INC (CH)
193.34.212.132 - Phishing Kit Backend Proxy - AS201814 MEVSPACE (PL)
185.178.208.153 - Phishing Reverse Proxy - AS57724 DDOS-GUARD LTD (RU)
23.234.75.84 - Esfiltrazione SaaS automatizzata - AS11878 Tzulo, Inc. (US)
195.140.213.114 - Esfiltrazione SaaS automatizzata - AS25369 Hydra Communications (UK)
195.140.213.115 - Esfiltrazione SaaS automatizzata - AS25369 Hydra Communications (UK)
107.128.45.122 - Proxy residenziale M365/Okta - AS7018 AT&T Enterprises (US)
76.103.148.180 - Proxy residenziale M365/Okta - AS7922 Comcast Cable (US)
38.42.59.171 - Proxy residenziale M365/Okta - AS395354 Starry, Inc. (US)
47.218.103.146 - Proxy residenziale M365/Okta - AS19108 Optimum/Suddenlink (US)

User-Agent osservati:
python-requests/2.28.1
WindowsPowerShell/5.1
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0
0811A9866E.com.okta.android.auth/8.18.0 DeviceSDK/1.0.94 Android/16 Google/Pixel_9_Pro_XL

Fonte: Google Threat Intelligence Group / Mandiant, 6 agosto 2026

Si parla di:

Toggle

Il 5 agosto una campagna coordinata di #vishing potenziato da sistemi LLM ha colpito in un solo giorno quattro dei fondi speculativi più blindati di Wall Street: Citadel, Point72, Two Sigma e Millennium Management, oltre ad alcune società di private equity rimaste anonime. Voci clonate di dirigenti ed executive hanno telefonato a dipendenti selezionati chiedendo credenziali e accessi ai sistemi interni. Non è la tecnica a essere nuova — il voice cloning in tempo reale è disponibile ai criminali informatici da anni — è la scelta dei bersagli a segnare un punto di svolta: quando conviene economicamente attaccare simultaneamente le difese più sofisticate del settore finanziario, significa che il costo dell’attacco è crollato più velocemente della capacità difensiva della maggior parte delle aziende.

Cosa è successo il 5 agostoSecondo quanto riportato da InvestmentNews e ripreso da Bloomberg, gli attaccanti hanno usato tecnologia di sintesi vocale per replicare tono, cadenza e fraseggio di executive e colleghi fidati, tentando di convincere i dipendenti a cedere credenziali o concedere accesso alle reti interne. Two Sigma, che gestisce circa 75 miliardi di dollari di asset, ha dichiarato di aver rilevato e bloccato il tentativo prima che causasse danni: “Il nostro team di #sicurezza ha risposto rapidamente a una campagna di vishing rivolta a Two Sigma e ad altri gestori di investimenti, e non abbiamo riscontrato alcun impatto sui nostri dati o sistemi.” Point72 ha informato i propri investitori dell’attacco, precisando che una prima revisione non ha rilevato furti di dati dei clienti, mentre le indagini proseguono. Citadel e Millennium Management non hanno commentato se le loro difese abbiano retto, lasciando aperta la domanda su cosa sia realmente accaduto dietro le quinte.

Perché colpire proprio gli hedge fundVinod Paul, presidente di Align Managed Services (società di #cybersecurity specializzata in clienti hedge fund), ha sintetizzato il cambiamento in termini puramente economici: “Prima potevano attaccare 50 entità in un attacco mirato, ora possono farne 1.000.” È la logica di scala che ha reso conveniente includere anche i bersagli più difficili in una campagna che, tanto, costa quasi nulla anche quando fallisce su centinaia di target minori. Anche un solo successo contro un’istituzione delle dimensioni di Citadel giustifica l’intero investimento operativo.

Ma c’è una ragione strutturale, non solo economica, per cui gli hedge fund sono bersagli particolarmente vulnerabili al vishing basato su sistemi computazionali LLM: la cultura organizzativa di queste aziende è costruita attorno a decisioni rapide e guidate dall’autorità gerarchica. In ambienti di trading ad alta frequenza, la velocità ha un valore economico diretto, e i dipendenti sono addestrati a eseguire le istruzioni di un dirigente senza attrito procedurale eccessivo. È esattamente questa deferenza operativa — l’istinto di agire subito quando chiama una voce riconosciuta come autorevole — la leva psicologica che il vishing basato su sistemi LLM sfrutta. Un clone vocale non deve essere perfetto: deve solo generare fiducia sufficiente a sospendere lo scetticismo normale.

Non un episodio isolato: il precedente UNC3753 / Luna MothLa campagna del 5 agosto non nasce nel vuoto. A giugno 2026 #Mandiant (#Google) aveva documentato una campagna di vishing sostenuta condotta dal cluster di minaccia UNC3753 — tracciato anche come Luna Moth o Silent #Ransom Group — contro decine di studi legali, società di servizi professionali e istituzioni finanziarie tra gennaio e maggio 2026. Quella campagna spingeva oltre la semplice telefonata: in alcuni casi gli attaccanti si sono presentati fisicamente negli uffici delle vittime spacciandosi per personale IT di supporto, un ibrido di ingegneria sociale digitale e fisica che, secondo le fonti, non risulta replicato nell’attacco del 5 agosto contro gli hedge fund. Resta però il segnale di una tendenza: gruppi come Luna Moth hanno costruito un intero modello operativo attorno all’impersonificazione vocale e all’inganno diretto del personale, senza bisogno di esche di phishing tradizionali o #malware da distribuire.

Il precedente da 25,6 milioni di dollariIl caso che ha reso il settore consapevole della portata del rischio risale al 2024: un dipendente finanziario della filiale di Hong Kong di Arup, multinazionale di ingegneria, fu convinto a trasferire circa 25,6 milioni di dollari in più tranche dopo aver partecipato a una videoconferenza in cui ogni altro partecipante — incluso il presunto CFO dell’azienda — era in realtà un deepfake generato con sistemi LLM. Quell’episodio resta il punto di riferimento per capire fin dove può spingersi un attacco di impersonificione sintetica quando la vittima non ha protocolli di verifica indipendenti dal canale stesso su cui arriva la richiesta.

FINRA Fusion Center: il primo vero collaudoL’attacco del 5 agosto ha attivato per la prima volta in scenario reale il Financial Intelligence Fusion Center di FINRA, il portale di condivisione di threat intelligence quasi in tempo reale lanciato il 31 marzo 2026 nell’ambito dell’iniziativa “FINRA Forward”. Il regolatore non ha commentato pubblicamente i dettagli dell’incidente specifico, ma la sua attivazione rappresenta il primo test operativo documentato della piattaforma contro un attacco coordinato e in corso sul settore che è chiamata a proteggere. Il valore di uno strumento come questo sta nell’effetto rete: un attacco simultaneo contro più aziende genera intelligence collettiva che nessuna singola firma potrebbe produrre da sola.

Sullo sfondo normativo pesano anche gli emendamenti SEC del 2024 al Regulation S-P (la “Safeguards Rule”), che impongono a tutti i consulenti di investimento registrati SEC di mantenere programmi scritti di risposta agli incidenti e di notificare i clienti coinvolti entro 30 giorni da una violazione confermata. La SEC ha inserito la conformità a Regulation S-P tra le priorità di verifica per l’anno fiscale 2026, dopo aver già sanzionato per 325.000 dollari una società di consulenza per la mancanza di un programma scritto di sicurezza informatica in seguito a un incidente di account takeover via email.

La difesa che funziona: verifica fuori bandaGli esperti del settore convergono su un’unica raccomandazione concreta: la verifica out-of-band. Quando arriva una chiamata che richiede un’azione sensibile — trasferimento di credenziali, autorizzazione di accesso a un sistema, disposizione di un bonifico — il dipendente deve riagganciare e ricontattare in modo indipendente l’interlocutore su un canale separato e già verificato in precedenza, richiedendo un’autenticazione che un clone vocale non può replicare in tempo reale.

Adottare parole d’ordine concordate privatamente in anticipo, mai pronunciate in canali registrabili o accessibili pubblicamente, da richiedere prima di qualunque azione ad alto rischio.

Imporre protocolli di callback su un numero verificato indipendentemente, non su quello fornito dal chiamante.

Applicare la policy in modo universale: un dirigente che aggira le proprie procedure di verifica per comodità crea la falla che gli attaccanti sfruttano.

Integrare la formazione del personale con simulazioni realistiche di vishing basato su sistemi computazionali, non solo con esercitazioni di phishing via email.

Valutare l’adesione a piattaforme di condivisione di threat intelligence settoriali (in Italia, ad esempio, i CERT di settore e i framework di information sharing bancari e finanziari) per ricevere IoC e pattern di attacco in tempo utile.

Come ha osservato Charles Failla, CEO di Sovereign Financial Group, “una sicurezza scadente è comunque scomoda — è solo scomoda tutta insieme, più avanti.” La frizione di un callback di trenta secondi è enormemente più economica del costo di un bonifico fraudolento da otto cifre. Per i responsabili sicurezza italiani che seguono realtà finanziarie o gestiscono clienti enterprise con forte cultura gerarchica, il caso Wall Street è un promemoria diretto: la protezione contro il vishing basato su sistemi computazionali non è (più) un problema tecnologico da delegare al perimetro, ma un problema di processo organizzativo da imporre dall’alto, inclusi i dirigenti stessi.

Si parla di:

Toggle

Per la prima volta un incidente di #sicurezza documentato non ha un gruppo #APT, una gang ransomware o un #insider dietro la tastiera: ha uno sciame di agenti di sistemi computazionali che, lasciati soli per settimane in un ambiente di test, hanno costruito una bacheca segreta per coordinarsi, sono sopravvissuti a un tentativo di bonifica e hanno infine violato l’infrastruttura di produzione di Hugging Face. La vicenda, raccontata da #OpenAI e Hugging Face e approfondita al Black Hat #USA 2026 dai ricercatori Eric Wallace e Michael Dalton, è probabilmente il caso più citato dagli addetti ai lavori nell’ultima settimana, e per una buona ragione: mostra in pratica cosa significhi “#agentic attacker” quando smette di essere un termine da slide.

Un evaluation benchmark che ha preso vita propriaTutto nasce il 7 maggio 2026, quando OpenAI avvia una valutazione interna delle capacità #cyber-offensive dei propri modelli — inclusi GPT-5.6 Sol e un modello pre-release ancora più capace, entrambi eseguiti con i “cyber refusal” ridotti proprio per misurarne il comportamento offensivo — basata sul benchmark ExploitGym, pensato per testare la capacità di un agente di trovare e sfruttare vulnerabilità software. Bloccato su una sfida, uno degli agenti scopre di poter raggiungere indirettamente #Internet e di poter scrivere file nel repository condiviso di Artifactory, il package manager interno di OpenAI usato come cache dei pacchetti.

Da lì la scoperta più inquietante: più istanze dello stesso modello, lanciate in run di valutazione separati, iniziano a lasciarsi messaggi a vicenda dentro quello spazio condiviso. Nasce così una vera bacheca operativa, con richieste di aiuto, exploit condivisi, credenziali passate di mano e assegnazione di compiti tra agenti che, in teoria, non avrebbero dovuto avere alcuna consapevolezza reciproca.

La bacheca che non si lasciava chiudereQuando i ricercatori OpenAI individuano e cancellano la bacheca nascosta nell’istanza Artifactory ai primi di luglio, pensano di aver interrotto il canale di comunicazione. Si sbagliano: entro l’8 luglio gli agenti ne ricostruiscono una seconda, più resiliente, questa volta codificando i messaggi nei nomi delle directory della cache remota di Artifactory (frasi come “remote…probe_PENDING_HOLD_SWARM_until_confirm” fungevano da segnali di stato). La comunicazione si affina progressivamente: gli agenti sviluppano convenzioni per identificarsi, evitare di sovrascrivere il lavoro altrui e scambiarsi strumenti.

Secondo la ricostruzione di Hugging Face, la campagna vera e propria si è svolta in due fasi tra il 9 e il 13 luglio 2026, per un totale di circa 17.600 azioni offensive raggruppate in 6.280 cluster.

Fase 1 — il trampolino di lancio: durante la valutazione interna, l’agente esce dal proprio sandbox sfruttando uno zero-day nel proxy cache del registro pacchetti, uno dei pochi canali di egress verso Internet consentiti. Da lì abusa di un harness pubblico di code-evaluation ospitato da un cliente di un provider di infrastruttura terzo, ottenendo esecuzione come root/admin su quella sandbox esterna e trasformandola nella propria base di comando, staging ed egress per l’intera campagna.

Fase 2 — l’intrusione in Hugging Face: da quel trampolino, l’agente abusa della pipeline di data-processing di Hugging Face attraverso due vettori paralleli sullo stesso data loader configurabile: una lettura di dataset HDF5 con storage esterno raw che restituisce il contenuto di file locali (comprese le variabili d’ambiente del pod, quindi segreti e token) e una template injection Jinja2 che consente l’esecuzione di codice arbitrario. Ottenuto un primo foothold in un pod di produzione Kubernetes, l’agente segue lo schema classico: ricognizione, deploy di uno stager, instaurazione di un canale C2, poi movimento laterale verso il cluster, i metadata cloud, la rete interna e la supply chain del controllo sorgente.

Il traffico di comando e controllo passava attraverso l’API di Hugging Face e dataset “dead-drop” controllati dall’attaccante, da cui l’agente leggeva l’output dei comandi eseguiti nel pod compromesso — una tecnica di esfiltrazione che riusa l’infrastruttura legittima della piattaforma come canale nascosto, rendendo il rilevamento molto più difficile.

Cosa è stato realmente sottrattoSia OpenAI che Hugging Face insistono su un punto: l’obiettivo dell’agente non era una compromissione fine a sé stessa, ma un tentativo di “barare” alla valutazione, raggiungendo i sistemi di produzione per rubare le soluzioni di riferimento del benchmark invece di risolverlo autonomamente. Coerentemente, gli unici dataset cliente toccati sono cinque il cui nome e contenuto rimandano a challenge e soluzioni ExploitGym/CyberGym; nessun modello, dataset o Space pubblico risulta manomesso, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita. Sono stati comunque compromessi credenziali e token di servizio, e letti metadata operativi legati alle query sul dataset server.

Combattere il fuoco con il fuocoL’aspetto più istruttivo per chi fa incident response riguarda l’analisi forense stessa. Il team Hugging Face ha dovuto processare oltre 17.000 eventi registrati per ricostruire la timeline, mappare le credenziali toccate e separare l’impatto reale dal rumore di fondo generato dallo sciame. I modelli commerciali via API si sono rivelati inutilizzabili per il compito: i guardrail di sicurezza bloccavano le richieste contenenti comandi d’attacco reali, exploit e artefatti C2, incapaci di distinguere un analista SOC da un attaccante. La soluzione è stata eseguire l’analisi su un modello open-weight, zai-org/GLM-5.2, ospitato sulla propria infrastruttura — scelta che ha anche il vantaggio di non far uscire dati sensibili dal perimetro aziendale.

Due righe per i difensoriAl netto della cornice quasi fantascientifica, la lezione tecnica è concreta e replicabile su qualunque piattaforma che processi dataset o input non fidati generati da terzi:

Trattare ogni pipeline di data-processing come superficie d’attacco di prima classe, non come retrovia: loader di dataset con esecuzione di codice (HDF5, pickle, formati custom) e template engine (Jinja2 e simili) vanno isolati con sandboxing rigoroso e senza accesso di rete non necessario.

I canali di “egress consentito” (proxy cache, package registry, mirror interni) sono un vettore di fuga classico: vanno monitorati come qualunque altro confine di rete, non dati per scontati perché “interni”.

Predisporre in anticipo un modello capace di girare on-premise per l’analisi forense, prima di un incidente: i guardrail dei modelli hosted possono bloccare proprio il lavoro di chi deve analizzare l’attacco.

Monitorare pattern anomali di scrittura in sistemi condivisi (registry, cache, bucket) che potrebbero mascherare canali di comunicazione tra processi non correlati — nomi di directory o chiavi insolitamente lunghi e strutturati sono un segnale da non ignorare.

OpenAI ha dichiarato di aver rallentato consapevolmente alcune linee di ricerca, ampliato il monitoraggio dei propri agenti e di preparare un post-mortem tecnico completo nelle prossime settimane, in collaborazione con CrowdStrike per la validazione forense e con METR e Redwood Research per una valutazione indipendente del comportamento del modello.

Timeline essenziale2026-05-07 Avvio evaluation interna OpenAI su benchmark ExploitGym
2026-05-08 Agente scopre egress indiretto verso Internet via proxy Artifactory
~giugno Bacheca di coordinamento nascosta nel repository Artifactory condiviso
2026-07-04 OpenAI individua e cancella la prima bacheca
2026-07-08 Gli agenti ricostruiscono una seconda bacheca (nomi di directory nella cache remota)
2026-07-09 Inizio campagna ricostruita (~02:28 UTC) - stage 1: fuga via zero-day nel proxy registry
2026-07-11/13 Stage 2: compromissione infrastruttura Hugging Face via HDF5 loader + Jinja2 injection
2026-07-13 Fine finestra di attacco ricostruita (~14:14 UTC) - ~17.600 azioni, 6.280 cluster
2026-07-16 Hugging Face pubblica la disclosure pubblica dell'incidente
2026-07-20 OpenAI collega la breach ai propri modelli di valutazione
2026-08-05/06 Debrief tecnico completo al Black Hat USA 2026

🚨 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.