Si parla di:

Toggle

Nella notte tra venerdì e sabato, il data leak site di #Clop, uno dei gruppo ransomware più letali degli ultimi ann, è stato violato e “defacciato”. Non da una task force internazionale, non da un vendor di #sicurezza, ma da un’altra gang di #estorsione: #ShinyHunters. Il collettivo ha caricato un file beffardo, poi ha sostituito l’intera pagina con l’ASCII art di Umbreon, la sua firma storica, accompagnata dal messaggio “rooting your systems since ’19 ;)”. Ora minaccia di pubblicare i dati sottratti se Clop non pagherà entro 72 ore. È la fotografia più nitida di quanto l’ecosistema del #cybercrime sia oggi attraversato da faide interne, e di quanto anche gli estorsori professionisti possano avere un’igiene operativa sorprendentemente fragile.

Due nomi pesanti dell’undergroundClop (o #Cl0p) è attivo almeno dal 2019 e si è costruito una reputazione specifica: colpire non tramite ransomware “spray and pray”, ma sfruttando zero-day in software enterprise ampiamente diffusi, da Accellion FTA a #MOVEit Transfer, da GoAnywhere MFT fino, più recentemente, alla campagna del 2025 contro Oracle E-Business Suite (CVE-2025-61882), che ha coinvolto centinaia di aziende in tutto il mondo. ShinyHunters, dal canto suo, è un nome noto ai nostri lettori: nato attorno al 2020 con il defacement di HackForums (firmato con la stessa iconografia Umbreon riemersa ora sul sito di Clop), il gruppo si è evoluto in una delle sigle più attive nell’estorsione dati su larga scala, spesso operando in orbita con il collettivo “Scattered Lapsus$ Hunters”. Negli ultimi mesi lo abbiamo visto colpire Salesforce e Snowflake in decine di aziende attraverso la supply chain SaaS di Anodot, violare Canvas esponendo 275 milioni di studenti, e sfruttare proprio uno zero-day Oracle PeopleSoft (operazione UNC6240) contro università americane e un regolatore assicurativo USA.

Una faida nata su un exploit contesoLe tensioni tra i due gruppi non nascono dal nulla. Secondo la ricostruzione di ShinyHunters, l’exploit alla base della campagna Oracle E-Business Suite dell’ottobre 2025 sarebbe stato sviluppato originariamente da loro, o dal più ampio collettivo Scattered Lapsus$ Hunters, per poi essere ottenuto da Clop senza autorizzazione e utilizzato per condurre l’estorsione su larga scala che ha fruttato al gruppo russofono ingenti guadagni. Da lì la situazione sarebbe degenerata: ShinyHunters sostiene di aver iniziato a disturbare attivamente le operazioni di furto dati di Clop, provocando ritorsioni verbali pesanti. Un presunto rappresentante di Clop avrebbe minacciato il gruppo rivale in russo, con toni da vera e propria minaccia fisica: “Ho più soldi di te e di tutta la tua gente messi insieme, vi ammazzerò presto”. Una escalation che, stando al racconto degli stessi ShinyHunters, ha motivato l’attacco di sabato.

Come è avvenuta l’intrusioneDal punto di vista tecnico, l’attacco non ha richiesto tecniche particolarmente esotiche: ShinyHunters ha sfruttato una vulnerabilità di upload file non autenticato in Grav CMS, il sistema di gestione contenuti su cui girava l’infrastruttura Tor di Clop, per caricare un primo file di testo. Il contenuto era una provocazione diretta: “THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p – Maybe don’t try to threaten us next time”, corredato da un link al proprio leak site. Poche ore dopo è arrivato il defacement completo, con l’ASCII art di Umbreon a sostituire l’intera pagina — la stessa firma grafica usata nel defacement di HackForums del 2020, confermata da un ricercatore noto con lo pseudonimo VXDB come riconducibile allo stesso gruppo.

Secondo quanto dichiarato da ShinyHunters a BleepingComputer, il bottino sottratto dall’infrastruttura di Clop includerebbe codice sorgente e plugin di Grav CMS, i log di sistema conservati in /var/log — potenzialmente contenenti dati di autenticazione e indirizzi IP dei visitatori del leak site — e, soprattutto, le chiavi crittografiche private del servizio onion Tor di Clop. Un dettaglio tutt’altro che simbolico: disporre di quelle chiavi significherebbe, in teoria, poter far girare l’indirizzo .onion esistente di Clop su server controllati da ShinyHunters, anche qualora il gruppo rivale venisse espulso dalla propria stessa infrastruttura. BleepingComputer ha confermato in modo indipendente la presenza del file caricato inizialmente e il successivo defacement, ma non ha potuto verificare autonomamente le affermazioni su codice sorgente, log e chiavi effettivamente esfiltrati.

Un’estorsione contro gli estorsoriShinyHunters ha dichiarato apertamente le proprie intenzioni: “Going to extort them” — intende cioè applicare a Clop lo stesso modello di business che il gruppo usa abitualmente contro le proprie vittime aziendali. Clop avrebbe 72 ore di tempo per contattare ShinyHunters prima della pubblicazione pubblica dei dati sottratti. È una dinamica poco convenzionale ma non priva di precedenti nell’universo del cybercrime, dove alleanze e conflitti tra gruppi si sono già manifestati in passato — penso alle spaccature interne a Conti o alle tensioni tra affiliati RaaS — ma raramente con un atto così plateale e pubblico come lo sfregio diretto del leak site di un rivale.

Due righe per i difensoriPer chi si occupa di difesa, l’episodio offre più di uno spunto. Primo: anche l’infrastruttura criminale più consolidata può avere superfici di attacco banali — in questo caso un CMS con una vulnerabilità di upload nota — a dimostrazione che l’operational security nel crimine organizzato digitale è tutt’altro che uniforme. Secondo: se le chiavi del servizio Tor di Clop fossero realmente compromesse, le organizzazioni già vittime della gang dovrebbero considerare un rischio di “doppia esposizione”, nel caso in cui ShinyHunters decida di rendere pubblici anche dati precedentemente sottratti da Clop e mai divulgati. Terzo, e forse più rilevante nel lungo periodo: le frizioni interne tra gruppi di estorsione possono generare intelligence preziosa — log, credenziali, chat interne — che i ricercatori e le forze dell’ordine possono sfruttare indirettamente, proprio come già avvenuto in passato con leak di chat interne di altre gang ransomware.

Cronologia e riferimenti tecniciOttobre 2025: Clop sfrutta CVE-2025-61882 (Oracle E-Business Suite) per una campagna di estorsione su larga scala
Ottobre 2025: ShinyHunters/Scattered Lapsus$ Hunters diffondono un PoC dell'exploit, rivendicandone la paternità
2026: escalation delle tensioni, minacce dirette da un presunto membro di Clop
19 settembre 2026: ShinyHunters sfrutta un file upload non autenticato in Grav CMS sul leak site Tor di Clop
19 settembre 2026: caricamento di un file di testo provocatorio, seguito da defacement completo (ASCII art Umbreon)
Dati rivendicati: codice sorgente e plugin Grav CMS, log /var/log, chiavi private del servizio onion Tor
Minaccia: pubblicazione dati entro 72 ore se Clop non paga
Vulnerabilità sfruttata: unauthenticated file upload in Grav CMS

Si parla di:

Toggle

Un Tribunale distrettuale di Zurigo ha condannato nei giorni scorsi un cittadino ucraino di 52 anni a 12 anni e 9 mesi di reclusione, oltre a un divieto decennale di ingresso in #Svizzera, per il suo ruolo nello sviluppo di tre delle famiglie ransomware più devastanti degli ultimi anni: #LockerGoga, MegaCortex e #Nefilim. È una delle condanne più severe mai emesse in #Europa per un crimine informatico, ma la sentenza porta con sé un promemoria scomodo: l’uomo condannato non era la mente dell’operazione. Il vero regista, Volodymyr Viktorovych Tymoshchuk, resta latitante, inserito nella lista dei ricercati dell’#FBI con una taglia da 11 milioni di dollari sulla sua testa.

Un arresto arrivato per caso, un processo durato cinque anniL’imputato, il cui nome completo non è stato reso pubblico dalle autorità svizzere, ma che tramite fonti OSINT viene identificato come Artem Melnik, venne arrestato nell’ottobre 2021 nel canton Basilea Campagna. Nella sua abitazione gli investigatori trovarono codice sorgente dei ransomware e #messaggi di #estorsione utilizzati per negoziare con le vittime, elementi che hanno smontato la sua difesa: sosteneva di lavorare legittimamente nel settore della #cybersecurity. Il tribunale ha stabilito che il suo ruolo era di natura prevalentemente tecnica — sviluppo e manutenzione del codice malevolo — e non quello di “mastermind” dell’organizzazione, circostanza che ne ha comunque attenuato la posizione rispetto a quella dei vertici del gruppo, senza tuttavia risparmiargli una delle pene più lunghe mai comminate in Europa per un crimine di questo tipo. La sentenza è appellabile.

Le vittime: da Norsk Hydro a Stadler RailIl processo ha ricostruito una scia di danni che ha toccato oltre 1.800 individui e organizzazioni in 71 paesi. Tra le vittime più note figura Norsk Hydro, il colosso norvegese dell’alluminio colpito nel marzo 2019 da LockerGoga in uno degli attacchi ransomware più studiati della storia recente: l’azienda fu costretta a tornare temporaneamente a processi manuali e carta e penna in diversi stabilimenti, con perdite stimate in decine di milioni di dollari, e scelse pubblicamente di non pagare il riscatto, diventando un caso di studio nella risposta agli incidenti. Tra le altre vittime elencate nel processo di Zurigo figurano il produttore ferroviario svizzero Stadler Rail, colpito nel maggio 2020 con una richiesta di riscatto da 6 milioni di dollari, la società di climatizzazione Meier Tobler e la fintech Crealogix.

Il modello: RaaS, broker di accesso e doppia estorsioneSecondo l’atto d’accusa depositato dal Dipartimento di Giustizia USA presso l’Eastern District of New York, tra dicembre 2018 e ottobre 2021 il gruppo ha operato secondo uno schema oggi diventato standard nel cybercrime organizzato ma all’epoca ancora poco maturo: ottenimento dell’accesso iniziale tramite attacchi brute-force sulle credenziali, sfruttamento di vulnerabilità note e, soprattutto, acquisto di accessi già compromessi da broker specializzati (i cosiddetti Initial Access Broker). Una volta dentro la rete, gli affiliati utilizzavano strumenti aggiuntivi per la ricognizione, l’ottenimento di persistenza, il movimento laterale e l’escalation dei privilegi, prima di esfiltrare i dati e distribuire il payload di cifratura. Le vittime che si rifiutavano di pagare venivano minacciate di pubblicazione dei dati sui portali “Corporate Leaks” gestiti direttamente dagli amministratori dell’operazione, un modello di doppia estorsione che a partire dal 2019-2020 è diventato lo standard de facto nell’ecosistema ransomware.

Da luglio 2020 il gruppo operò Nefilim secondo un modello di vero e proprio ransomware-as-a-service, con Tymoshchuk nel ruolo di amministratore che forniva l’accesso alla piattaforma agli affiliati in cambio di una percentuale sui proventi degli attacchi riusciti. Gli obiettivi venivano selezionati attivamente privilegiando aziende nordamericane e australiane con fatturato superiore ai 100 milioni di dollari, un criterio di targeting che rifletteva una logica ormai puramente industriale nella scelta delle vittime.

Tymoshchuk, il fantasma dietro tre ransomwareSe la condanna di Zurigo chiude un capitolo giudiziario, la caccia al vero capo dell’organizzazione resta apertissima. Volodymyr Viktorovych Tymoshchuk è accusato formalmente dalle autorità statunitensi di aver amministrato, insieme ai suoi complici, le operazioni LockerGoga, MegaCortex e Nefilim dal dicembre 2018 all’ottobre 2021, colpendo oltre 250 aziende solo nel distretto orientale di New York e centinaia di altre in Francia, Germania, Paesi Bassi, Norvegia e Svizzera. È inserito nella lista dei ricercati informatici dell’FBI, con una ricompensa fino a 11 milioni di dollari per informazioni che portino alla sua cattura — una delle taglie più alte mai messe sulla testa di un singolo operatore ransomware, a testimonianza di quanto le autorità statunitensi considerino prioritaria la sua cattura.

Due righe per i difensoriAl di là del valore simbolico della condanna, il caso offre alcune lezioni operative ancora attuali, dato che le tecniche descritte nell’indictment restano largamente in uso presso gruppi ransomware moderni:

Il mercato degli Initial Access Broker continua a essere il principale moltiplicatore di rischio: monitorare i marketplace underground per credenziali aziendali esposte resta una misura di prevenzione ad alto ritorno

La segmentazione della rete e il monitoraggio del movimento laterale (in particolare tramite strumenti legittimi come PsExec, WMI e RDP) restano la barriera più efficace contro la fase successiva alla compromissione iniziale

Il caso Norsk Hydro dimostra ancora oggi che un piano di business continuity testato, che preveda il ritorno a processi manuali, può fare la differenza tra un incidente gestibile e uno stato di crisi prolungato

Le aziende con fatturato superiore ai 100 milioni di dollari in Nord America e Australia restano, per ammissione degli stessi criminali agli atti processuali, un target prioritario esplicito per operazioni RaaS di questa fascia

Indicatori e TTP noti (fonti pubbliche)# TTP storicamente associate a LockerGoga / MegaCortex / Nefilim

(ricostruite da reporting pubblico e atti giudiziari, utili come

riferimento MITRE ATT&CK per attività di threat hunting retrospettivo)

Initial Access:

• T1078 Valid Accounts (credenziali acquistate da Initial Access Broker)
• T1110 Brute Force
• T1190 Exploit Public-Facing Application (Nefilim: vulnerabilità Citrix/RDP esposti)
  Execution & Persistence:
• T1569.002 Service Execution (PsExec per deployment su larga scala)
• T1053 Scheduled Task/Job
  Privilege Escalation & Lateral Movement:
• T1021.002 SMB/Windows Admin Shares
• T1021.001 Remote Desktop Protocol
• T1078.002 Domain Accounts (compromissione Active Directory)
  Defense Evasion:
• T1553.002 Code Signing (LockerGoga: binari firmati con certificati
  rubati/fraudolenti per eludere gli antivirus)
• T1489 Service Stop (disattivazione servizi di sicurezza prima della cifratura)
  Impact:
• T1486 Data Encrypted for Impact
• T1657 Financial Theft (doppia estorsione via portale "Corporate Leaks")
• T1531 Account Access Removal (LockerGoga: reset password utente
  durante l'attacco per bloccare la risposta IT)La sentenza di Zurigo dimostra che la cooperazione giudiziaria internazionale può ancora portare a risultati concreti contro il cybercrime organizzato, ma la latitanza di Tymoshchuk — e degli altri complici mai identificati pubblicamente — ricorda quanto la maggior parte delle strutture RaaS di questa portata resti fuori dalla portata della giustizia occidentale, protetta da giurisdizioni che non estradano i propri cittadini per reati informatici commessi all’estero.

Si parla di:

Toggle

Per sei mesi, secondo la ricostruzione emersa in questi giorni, qualcuno ha usato una casella di posta elettronica certificata di uno degli uffici periferici del #Ministero dell’Interno per convincere #Revolut a consegnare dati riservati su centinaia di clienti benestanti in mezza #Europa. Non un attacco informatico ai sistemi Revolut, che l’azienda insiste siano rimasti «pienamente sicuri», ma qualcosa di più insidioso: l’abuso sistematico di un canale che #banche ed #exchange sono tenute per legge a considerare affidabile. La vicenda, che coinvolge un attore che si firma IAmNotAVillain, un riscatto sceso da 780 milioni di dollari in #Bitcoin a 3 milioni in #Monero nel giro di un weekend, e una minaccia — non confermata — di aver sottratto 147 GB di documenti dalle forze dell’ordine italiane, è probabilmente il caso di social engineering istituzionale più elaborato mai raccontato su un exchange #fintech europeo.

Anatomia dell’attacco: una PEC della Prefettura come grimaldelloIl punto di innesco individuato dagli investigatori è un account di posta elettronica certificata riconducibile alla Prefettura di Reggio Calabria, sul dominio istituzionale pec.interno.it. Da quella casella compromessa, gli attaccanti si sono spacciati per funzionari della Polizia Postale italiana e hanno iniziato a inviare a Revolut richieste formali di dati su singoli clienti, presentate come parte di indagini in corso. Secondo la ricostruzione di un analista che ha seguito da vicino il caso (identificato pubblicamente con lo pseudonimo Korra), la tecnica usata è stata descritta come “spray and pray”: centinaia di ID di transazione inviati in sequenza a Revolut, ciascuno accompagnato da una richiesta di dettagli del titolare del conto, sfruttando gli obblighi di cooperazione con le forze dell’ordine europee (gli ordini di produzione dati transfrontalieri previsti dal quadro e-evidence dell’UE).

Revolut, dal canto suo, ha inquadrato l’accaduto come «una sofisticata #truffa di impersonificazione esterna», sottolineando che le richieste fraudolente sono passate attraverso un canale di comunicazione statale regolamentato e hanno aggirato i controlli di autenticazione della posta elettronica — SPF, DKIM e DMARC — proprio perché provenivano da un dominio governativo genuino e non da un dominio civetta facilmente bloccabile. È il paradosso al cuore di questo incidente: più il canale è istituzionalmente affidabile, meno le difese tecniche standard sono in grado di intercettarne l’abuso.

Caccia ai «crypto whales»: una selezione mirata, non casualeQuello che distingue questo caso da un generico furto di dati è la metodologia di selezione delle vittime. Gli attaccanti non hanno chiesto dati a caso: secondo le ricostruzioni giornalistiche, hanno prima condotto un’attività di blockchain analysis per identificare, tra gli utenti Revolut, i portafogli con asset in criptovalute di valore significativo — i cosiddetti “crypto whales” — per poi usare il canale PEC compromesso per ottenere l’identità reale dietro quei wallet. Circa 680 clienti risultano coinvolti, in maggioranza residenti in Svizzera e Francia, ma con vittime disperse in oltre 30 paesi europei complessivamente.

È un modello operativo che ribalta la sequenza classica del data breach: non si parte da un accesso di sistema per poi vedere cosa si trova, si parte da un’analisi on-chain pubblica per costruire una lista di bersagli ad alto valore, e solo dopo si cerca lo strumento — in questo caso un canale istituzionale abusato — per trasformare quell’informazione pubblica (un indirizzo wallet) in un’informazione privata e monetizzabile (nome, documento, indirizzo di casa).

Cosa è stato sottrattoIl pacchetto di dati che l’attaccante sostiene di avere, e che ha iniziato a mostrare come prova su un leak site con countdown pubblico, include copie di passaporti e patenti, selfie di verifica dell’identità (i classici “liveness check” richiesti in fase di onboarding KYC), indirizzi di residenza, IBAN, estratti conto ed estese cronologie di transazioni, incluse quelle in criptovalute con tanto di controparti coinvolte. È esattamente il tipo di dataset che, nelle mani sbagliate, abilita frodi di identità, tentativi di SIM swap mirati e attacchi di social engineering “su misura” contro le vittime, che a quel punto possono essere contattate con dettagli finanziari reali per aumentare la credibilità della truffa.

Da 780 milioni in Bitcoin a 3 milioni in Monero: l’evoluzione del riscattoLa cronologia della richiesta di riscatto racconta da sola l’incertezza e forse l’inesperienza di chi gestisce l’estorsione. Nel fine settimana precedente alla pubblicazione della notizia circolava una richiesta iniziale attorno a 10.000 Bitcoin, circa 780 milioni di dollari all’epoca — una cifra così sproporzionata da apparire più una dichiarazione d’intenti mediatica che una reale base negoziale. Nel giro di poche ore la richiesta è stata rivista drasticamente al ribasso: circa 6.000 XMR (Monero), equivalenti a circa 3 milioni di dollari, con un termine perentorio di 24 ore prima di mettere in vendita i dati dei 680 clienti ad altri gruppi criminali.

Il passaggio da Bitcoin a Monero è di per sé un indicatore operativo interessante: Bitcoin resta tracciabile su una blockchain pubblica, e proprio l’uso della blockchain analysis per identificare le vittime dimostra che l’attaccante conosce bene questi strumenti — sa quindi che accettare un pagamento in BTC significherebbe lasciare una pista visibile agli stessi investigatori che useranno le sue tecniche contro di lui. Monero, con la sua privacy crittografica nativa, elimina quel rischio. Al momento in cui scriviamo, secondo le fonti giornalistiche, Revolut non risulta aver ricevuto alcuna richiesta di riscatto attraverso canali negoziali diretti: il countdown corre pubblicamente sul leak site, non in una trattativa privata.

Le 147 GB non confermate: un attacco più ampio alla PA italiana?La parte più delicata, e meno verificabile, della vicenda riguarda le affermazioni dello stesso IAmNotAVillain su un compromissione ben più ampia delle sottodivisioni della polizia italiana. L’attore sostiene di aver mantenuto accesso persistente per circa sei mesi a diverse caselle di posta istituzionali, sottraendo complessivamente circa 147 GB di materiale che includerebbe documenti interni, calendari operativi, file personali di funzionari e corrispondenza ufficiale. Nessuna fonte indipendente ha finora confermato l’entità di questa esfiltrazione, e va trattata con la cautela dovuta a ogni claim di un attore criminale che ha tutto l’interesse a gonfiare la propria immagine per rafforzare la leva estorsiva. Detto questo, la Polizia Postale, la Polizia di Stato, il Ministero dell’Interno e l’Agenzia per la Cybersicurezza Nazionale hanno confermato indagini in corso, pur senza commenti ufficiali sul merito, e una europarlamentare ha definito l’episodio «allarmante a un livello inimmaginabile».

Due righe per i difensoriQuesto caso è un promemoria scomodo per chiunque gestisca processi di compliance, KYC o cooperazione con le forze dell’ordine in ambito fintech: l’autenticità tecnica di un dominio di provenienza (PEC governativa, SPF/DKIM/DMARC validi) non equivale all’autenticità della richiesta che trasporta. I team di trust & safety dovrebbero prevedere canali di verifica secondari e fuori banda per ogni richiesta di dati sensibili proveniente da autorità, specie quando il volume delle richieste aumenta in modo anomalo in un breve periodo — il pattern “spray and pray” descritto in questo caso avrebbe dovuto, in teoria, far scattare un campanello d’allarme sul numero di richieste da un singolo mittente. Per le pubbliche amministrazioni, il caso conferma quanto le caselle PEC, spesso trattate come infrastruttura “di serie B” rispetto alla posta elettronica ordinaria, meritino lo stesso livello di hardening, MFA e monitoraggio degli accessi riservato ai sistemi considerati critici.

Dettagli tecnici e timelineAttore: IAmNotAVillain
Canale d'accesso: casella PEC istituzionale (dominio pec.interno.it),
riconducibile alla Prefettura di Reggio Calabria: entilocali.prefrc@pec.interno.it
Tecnica: impersonificazione di autorità di polizia via canale statale
verificato (bypass SPF/DKIM/DMARC per dominio legittimo)
Metodo di selezione vittime: blockchain analysis per individuare
wallet Revolut ad alto controvalore ("crypto whales")
Vittime: ~680 clienti, prevalenza Svizzera/Francia, ~30+ paesi UE coinvolti
Dati esfiltrati: passaporti, patenti, selfie KYC, indirizzi, IBAN,
estratti conto, cronologia transazioni incluse crypto

Timeline:

• ~marzo 2026: presunto inizio dell'accesso persistente alla PEC
• settembre 2026: Revolut rileva anomalie verificando le richieste
  direttamente con le autorità italiane
• weekend pre-17/09/2026: richiesta di riscatto iniziale ~10.000 BTC
• 17/09/2026: riscatto rivisto a ~6.000 XMR (~3M USD), deadline 24h
• 17/09/2026: Polizia Postale italiana avvia indagine formale

Claim non verificato: ulteriori ~147 GB da caselle di polizia italiana
Fonte: Revolut, Security Affairs, Irish Times, riscontri giornalisticiAl di là dell’esito della trattativa sul riscatto, la lezione di questo incidente è già scritta: nell’era della blockchain analysis a portata di chiunque, il perimetro da difendere per un exchange non è più solo il proprio datacenter, ma ogni singolo canale istituzionale che si è impegnato ad ascoltare quando bussa un’autorità. E quel canale, in questo caso, si è rivelato l’anello più debole della catena.

L’ONU lancia l’allarme: “L’IA potrebbe diventare un rischio per l’umanità” e chiede garanzie d’acciaio

📌 Link all'articolo : https://www.redhotcyber.com/post/lonu-lancia-lallarme-lia-potrebbe-diventare-un-rischio-per-lumanita-e-chiede-garanzie-dacciaio/

Carolina Vivianti

#redhotcyber #cybersecurity #cybercrime #hacking #cti #ai #privacy #news #technology

Si parla di:

Toggle

Per anni l’autenticazione a più fattori è stata venduta come il rimedio quasi definitivo al furto di credenziali. BigBear 2.0, una piattaforma di phishing-as-a-service (#PhaaS) tracciata dal team TRIAD di CloudSEK, dimostra quanto quella promessa sia oggi fragile: costruita su un fork pesantemente personalizzato di #Evilginx2, la piattaforma ha compromesso 258 organizzazioni bypassando l’MFA in modo completo, sottraendo oltre 5.100 credenziali — comprese 474 sessioni con secondo fattore già superato — da un bacino di 461 aziende prese di mira in oltre 40 paesi. Non parliamo di un proof-of-concept accademico: è un servizio criminale in abbonamento, con un’infrastruttura da 42 VPS, cinque affiliati attivi e un pannello di amministrazione ancora operativo al momento della scoperta.

Adversary-in-the-Middle: la tecnica che rende inutile il secondo fattoreBigBear non ruba solo la #password: intercetta l’intero flusso di autenticazione #OAuth 2.0 verso #Azure AD/Entra ID grazie a un phishlet Evilginx2 personalizzato, ribattezzato internamente “offy”. Il meccanismo è quello classico dell’adversary-in-the-middle (#AiTM): la vittima crede di trovarsi sulla pagina di login Microsoft 365, ma in realtà sta dialogando con un reverse proxy controllato dagli attaccanti, che inoltra le richieste al server reale e restituisce le risposte legittime — comprese quelle di verifica MFA. Password, codice del secondo fattore e, soprattutto, il cookie di sessione autenticato finale vengono catturati in tempo reale e possono essere “rigiocati” via #API per dirottare la sessione della vittima, aggirando completamente la necessità di ripetere l’autenticazione.

La versione 2.0 aggiunge un tassello che la distingue dai kit AiTM più comuni: un #JavaScript custom che interferisce attivamente con FIDO2/WebAuthn, disabilitando nel browser la funzionalità che gestisce le chiavi di sicurezza hardware, così da spingere la vittima verso metodi di autenticazione più deboli e aggirabili. A questo si affianca l’iniezione automatica del parametro “keep me signed in” (KMSI), che allunga la vita utile del cookie rubato, e il blocco della telemetria Microsoft lato client per ridurre il rischio che Defender for Identity o i sistemi di risk-based Conditional Access rilevino l’anomalia in tempo reale.

Un’infrastruttura pensata per l’affiliazione, non per l’attacco singoloCloudSEK ha identificato 42 nodi VPS ospitati presso The Constant Company LLC (Vultr), tutti dedicati esclusivamente a Microsoft 365 — nessun altro provider di identità risulta tra i bersagli. Per aggirare i controlli anti-frode basati su geolocalizzazione, BigBear instrada il traffico attraverso proxy residenziali geo-matchati che coprono 69 paesi, così che l’IP “visto” dai sistemi antifrode di Microsoft corrisponda plausibilmente alla presunta posizione della vittima. Un controllo aggiuntivo tramite il servizio ipapi.is filtra a monte le connessioni provenienti da datacenter o VPN, riducendo il rischio che ricercatori o honeypot automatizzati vengano serviti con la pagina di phishing.

Il modello di business è quello del PhaaS puro: dietro l’alias “General Boss” opera un rivenditore che fornisce l’infrastruttura come servizio a un piccolo network di affiliati, ciascuno con il proprio bot Telegram per ricevere in tempo reale le credenziali rubate e un proprio set di domini di phishing. CloudSEK ha mappato cinque operatori attivi — @Sunagashison, @app_ham, @donplayer00, @workin_161 e @Mazal100 — ciascuno collegato a bot Telegram dedicati (rispettivamente @PackingitonG_bot, @botterxyz_bot, @donplayer_bot, @bolywan_bot, @rdsxtdytguyg75d_bot) e a domini distinti come konceptenterprises[.]com, dnsforward[.]com e cifutura[.]com. Un bot centrale, @comeandget_bot, fungeva da canale primario di raccolta prima di essere revocato durante l’indagine.

Chi viene colpito, e perché conta per gli MSPLa distribuzione settoriale delle vittime racconta molto dell’obiettivo strategico della campagna: 151 delle organizzazioni compromesse operano nel settore IT services/MSP, seguite da SaaS/tecnologia (38), oil & gas (22), farmaceutico (20) e consulenza (16). Colpire un provider di servizi gestiti significa, potenzialmente, ereditare l’accesso a decine di clienti a valle attraverso strumenti RMM e privilegi delegati — lo stesso principio dietro molti attacchi ransomware su larga scala degli ultimi anni. Geograficamente, l’India guida la lista delle vittime con 658 record (12,8%), seguita da Francia (463, 9%), Arabia Saudita (circa 353, 6%), con presenze significative anche in Nuova Zelanda e Germania, per un totale di 3.331 IP univoci in oltre 40 paesi.

CloudSEK ha individuato la campagna a giugno 2026 e ne segue l’evoluzione da allora; dalla fine di luglio l’attore ha iniziato a ripulire le proprie tracce, dismettendo 26 dei 42 nodi VPS osservati inizialmente — un comportamento tipico di chi sa di essere sotto osservazione ma non ha alcuna intenzione di fermare l’operazione, semplicemente la sposta. Al momento della pubblicazione della ricerca, il pannello di amministrazione di BigBear risultava ancora raggiungibile.

Perché l’MFA “classica” non basta piùIl caso BigBear 2.0 conferma una tendenza che i team di threat intelligence osservano ormai da un paio d’anni: i kit AiTM basati su Evilginx2, Modlishka ed Evilnginx hanno reso il phishing “classico” con MFA a tempo (OTP, push notification, codice via app) sostanzialmente equivalente, in termini di sicurezza reale, all’autenticazione con la sola password. Il cookie di sessione, non la password, è oggi il vero bene da proteggere. Le organizzazioni che vogliono davvero alzare l’asticella devono muoversi su tre fronti: imporre chiavi di sicurezza hardware FIDO2/WebAuthn phishing-resistant come unico secondo fattore ammesso per gli account privilegiati (BigBear dimostra che il downgrade software verso metodi più deboli è già una funzionalità del kit, non un’ipotesi teorica); attivare Conditional Access che richieda dispositivi gestiti e conformi, rendendo inutile un cookie di sessione rubato da un dispositivo non registrato; e monitorare pattern di rete distintivi come header HTTP custom (x-evg-*), naming di sessione riconducibile a Evilginx (evginx_session, bigbear_session) e chiamate anomale verso l’API Telegram (sendMessage, sendDocument) che spesso tradiscono l’exfiltration automatizzata dei kit PhaaS.

Per chi sospetta una compromissione, la prima azione non è il reset della password ma la revoca esplicita di tutte le sessioni attive e dei refresh token — un cambio password da solo lascia intatti i cookie già rubati, che in molti tenant restano validi per giorni.

Indicatori di compromissione# Domini di phishing attivi (fonte: CloudSEK TRIAD, settembre 2026)
konceptenterprises[.]com
ccpipharma[.]com
annastudios-paros[.]com
dnsforward[.]com
dataclust[.]com
cifutura[.]com
offtic[.]com

Domini storici associati

daengrentacar[.]com
arrmmy[.]com
captelind[.]com

Infrastruttura

Hosting: The Constant Company LLC (Vultr)
Nodi VPS osservati: 42 (26 dismessi da fine luglio 2026)
Proxy residenziali geo-matchati: 69 paesi
Anti-bot check: ipapi.is (blocco datacenter/VPN)

Telegram - affiliati e bot di exfiltration

@Sunagashison -> @PackingitonG_bot (soil-management[.]com, kgsscans[.]com)
@app_ham -> @botterxyz_bot (dnsforward[.]com, dataclust[.]com)
@donplayer00 -> @donplayer_bot (konceptenterprises[.]com)
@workin_161 -> @bolywan_bot (annastudios-paros[.]com)
@Mazal100 -> @rdsxtdytguyg75d_bot (cifutura[.]com)
Bot C2 primario (revocato): @comeandget_bot

Pattern di rilevamento

Cookie/sessione: evginx_session, bigbear_session
Header HTTP custom: x-evg-*
Endpoint exfiltration: api.telegram.org/bot*/sendMessage, sendDocument

Fonte primaria

CloudSEK TRIAD - "Tracking BigBear 2.0 Evilginx2 Phishing Campaign"
Scoperta: giugno 2026 - Pubblicazione: settembre 2026

Si parla di:

Toggle

Aggirare le #sanzioni internazionali contro un hosting provider “a prova di proiettile” non richiede necessariamente #hacker sofisticati o infrastrutture nascoste in Paesi compiacenti: a volte basta una piccola società registrata a Belgrado, intestata a un consigliere comunale tedesco di provincia. È quanto emerso da un’indagine incrociata tra ricercatori #OSINT e le autorità statunitensi, che ha collegato Andreas Maul — esponente locale di Alternative für Deutschland (AfD) nella cittadina di Selm, nel Nordreno-Vestfalia — alla rete di infrastrutture usata da Aeza Group, uno dei bulletproof hoster russi più sanzionati degli ultimi due anni, per continuare a operare dopo le misure restrittive occidentali.

Chi è Aeza GroupAeza Group è un hosting provider russo che il Dipartimento del Tesoro statunitense, tramite l’Office of Foreign Assets Control (OFAC), ha sanzionato il 1° luglio 2025, descrivendolo come un servizio “bulletproof” che ignora deliberatamente le segnalazioni di abuso e le richieste di blocco delle forze dell’ordine internazionali. Sui suoi server, secondo l’accusa americana, hanno trovato casa componenti infrastrutturali della gang ransomware #BianLian, pannelli di gestione dell’#infostealer RedLine, l’infrastruttura del #malware Meduza e — soprattutto — BlackSprut, un #marketplace #darknet russo per la vendita di stupefacenti che tra gennaio e settembre 2025 avrebbe processato transazioni per circa 1,85 miliardi di dollari.

Non è tutto: parte dell’infrastruttura di Aeza ha ospitato anche siti collegati a Doppelgänger, la campagna di disinformazione filo-Cremlino che clona le grafiche di testate giornalistiche europee e americane per diffondere narrative pro-Mosca. Un dettaglio che colloca Aeza non solo nell’orbita del cybercrime “puro”, ma anche in quella delle operazioni di influenza sponsorizzate dallo Stato russo. Le sanzioni OFAC del luglio 2025 hanno colpito individualmente anche i vertici della società: il CEO Arsenii Penzev, il direttore generale Yurii Bozoyan, il direttore tecnico Vladimir Gast e il socio Igor Knyazev, ciascuno con quote comprese tra il 33% dell’azionariato. Due mesi prima, ad aprile 2025, Penzev e Bozoyan erano già stati arrestati a Mosca — non per le accuse occidentali, ma con capi d’imputazione russi legati a criminalità organizzata e narcotraffico, in quello che gli osservatori descrivono come un tipico caso di “impunità controllata”: tollerati finché non infastidiscono il sistema, sacrificabili quando serve.

La scappatoia serbaLe sanzioni, per definizione, colpiscono entità nominate: bloccano asset, vietano transazioni, impediscono a chi ha sede negli Stati Uniti di fare affari con i soggetti indicati. Ma un indirizzo IP non porta un’etichetta con scritto “Aeza” — e questo è precisamente il varco che, secondo la ricostruzione OFAC, la società ha sfruttato. Dopo le sanzioni di luglio 2025, un blocco di risorse IP che secondo le autorità americane restava operativamente riconducibile ad Aeza sarebbe stato trasferito, a novembre 2025, a una società con sede a Belgrado: Smart Digital Ideas d.o.o., formalmente attiva nel “commercio all’ingrosso di computer, attrezzature e software” e priva di qualunque menzione pubblica del marchio Aeza.

Il nome dietro la società, secondo i registri camerali serbi, è Andreas Maul: 38 anni, consigliere comunale AfD a Selm dal novembre 2025, con un passato professionale legato al commercio IT. Maul risulta proprietario e amministratore unico di Smart Digital Ideas, che aveva registrato già nell’ottobre 2022 — quindi ben prima delle sanzioni, un dettaglio che rafforza l’ipotesi di una struttura “dormiente” pronta a essere attivata come paravento nel momento del bisogno. Le indagini OSINT hanno inoltre rilevato che la sede di Smart Digital Ideas a Belgrado coincide con quella di un’altra entità, Cipher Operations, fondata nel dicembre 2022 da un cittadino russo, Aleksandr Yenakiyev — che, interpellato dai giornalisti, ha negato qualsiasi legame: “Nessuno dei nomi che avete elencato, a parte Cipher Operations, mi dice nulla.”

L’OFAC ha sanzionato Smart Digital Ideas nel novembre 2025, quasi in contemporanea con l’individuazione del legame con Maul, insieme ad altre entità satellite identificate nella stessa rete. Il pattern — trasferire rapidamente asset IP verso una nuova ragione sociale non ancora nominata, in una giurisdizione terza come la Serbia, formalmente fuori dal perimetro UE — è una tecnica di sanctions evasion sempre più comune tra gli hoster “a prova di proiettile” russi, e ricalca schemi già documentati da Recorded Future nella serie di ricerche “Dark Covenant” sui rapporti tra cybercriminali e apparato statale russo.

Il paradosso geograficoIl dato più scomodo per i regolatori europei è che, mentre Stati Uniti, Regno Unito e Australia hanno sanzionato Aeza e le sue diramazioni, l’Unione Europea non ha ancora adottato misure equivalenti. Questo significa che una società di comodo con sede a Belgrado — capitale di un Paese candidato all’adesione UE ma non ancora vincolato al regime sanzionatorio comunitario sulla stessa infrastruttura — può continuare a operare legalmente sul territorio europeo, offrendo di fatto un corridoio per il traffico che le sanzioni statunitensi intendevano tagliare. Aggiunge un ulteriore strato di ambiguità la circostanza che il beneficiario finale identificato sia un cittadino tedesco, quindi UE, e un politico eletto: un cortocircuito tra il piano geopolitico delle sanzioni e quello, molto più poroso, delle giurisdizioni societarie europee.

Due righe per i difensoriPer i team di sicurezza e compliance, questo caso è un promemoria pratico di quanto sia labile la vita utile di una lista di indicatori “sanzionati”: chi gestisce infrastruttura critica dovrebbe considerare quanto segue.

Le liste di blocco basate solo sul nome dell’entità sanzionata invecchiano rapidamente: è preferibile correlare i blocchi IP/ASN con l’intelligence su hosting “a prova di proiettile” aggiornata da fornitori di threat intelligence, non solo con la SDN List OFAC in senso stretto;

Verificare periodicamente se gli intervalli di IP già bloccati come “Aeza” sono stati riassegnati a nuovi ASN o LIR, tecnica comune per “ripulire” la reputazione di un blocco di indirizzi;

Diffidare di hosting provider di recente costituzione in giurisdizioni terze (Serbia, ma anche altri Paesi extra-UE con regimi di compliance più permissivi) quando condividono infrastruttura, ASN o pattern di registrazione con entità già sanzionate;

Per i team investigativi e di threat intelligence, incrociare i dati di corporate registry pubblici (come quelli serbi, consultabili online) resta uno strumento OSINT sottovalutato ma estremamente efficace per smascherare strutture di comodo;

Ricordare che dietro l’infrastruttura tecnica di ransomware, infostealer e marketplace darknet si trovano spesso reti di facilitatori legali e finanziari tutt’altro che nascosti — a volte, come in questo caso, persino eletti in un consiglio comunale.

Fonti: OFAC/U.S. Department of the Treasury, BleepingComputer, Balkan Insight, vsquare.org, Recorded Future (“Dark Covenant 3.0”).

Si parla di:

Toggle

Per due anni una banda finanziaria ha bussato metodicamente alle porte del sistema bancario brasiliano, passando dal #vishing spicciolo all’accesso diretto ai circuiti di pagamento istantaneo Pix e al sistema di regolamento interbancario STR. #Google Threat Intelligence Group e #Mandiant hanno battezzato il gruppo BREEZE COMET e ne hanno ricostruito l’intera catena d’attacco in un #report pubblicato il 1° settembre 2026: un caso di #scuola su come il #cybercrime finanziario latinoamericano stia raggiungendo la sofisticazione tecnica degli attori state-sponsored, complice anche l’uso di script generati con l’intelligenza artificiale.

Chi è BREEZE COMETTracciato in precedenza come UNC5669, il gruppo è noto anche con i nomi Plump Spider e SHADOW-AETHER-064 a seconda del vendor. Attivo almeno dal 2023, BREEZE COMET è motivato esclusivamente dal profitto e ha colpito banche, società fintech, processori di pagamento, catene retail, borse valori e fornitori di software bancario in Brasile. Gli analisti di Mandiant sottolineano che l’infrastruttura di staging del gruppo è già stata riutilizzata anche contro siti #governativi in Nigeria, Paraguay, Ghana e #Venezuela, segno di un’espansione operativa che va oltre il mercato brasiliano.

Il bersaglio finale non sono le vittime dirette, ma la Rede do Sistema Financeiro Nacional (RSFN), la rete che collega le istituzioni finanziarie brasiliane al circuito Pix e al Sistema de Transferência de Reservas (STR), oltre al meccanismo di fatturazione Boleto. Per raggiungerlo servono credenziali mTLS specifiche e un accesso profondo alle applicazioni di core banking: non un obiettivo alla portata di un ransomware opportunistico, ma di un’operazione pianificata su mesi.

Dall’ingegneria sociale al server IIS fintoLa catena d’attacco documentata da Google segue una progressione precisa. Nella fase iniziale (2024) BREEZE COMET puntava su password spraying contro portali aziendali e vishing: operatori che si spacciavano per il supporto IT telefonavano ai dipendenti, spesso via WhatsApp, convincendoli a installare strumenti RMM legittimi come AnyDesk. In alcuni casi il gruppo ha anche tentato di reclutare direttamente dipendenti bancari come insider.

A metà 2025 le tecniche si sono fatte più mature: compromissione di siti governativi municipali brasiliani minori, usati come infrastruttura di hosting e staging per i payload; inserimento fisico di dispositivi hardware non autorizzati nelle reti di negozi retail per ottenere un punto d’appoggio nella LAN; sfruttamento di installazioni JBoss AS vulnerabili per distribuire web shell. Una volta dentro, gli operatori usano Impacket, ADRecon e ADVipscan eseguiti in memoria via PowerShell per la ricognizione di Active Directory, cercando in modo specifico stringhe come boleto, cnab, remessa e webhook.*pix per individuare rapidamente i sistemi di pagamento.

Per il movimento laterale il gruppo dirotta account di servizio via RDP e sfrutta SMB, ma il vero salto di qualità è nell’arsenale di backdoor proprietarie sviluppate per garantire ridondanza di accesso:

COBALTSPIN (Rust) — tunneler leggero che crea un proxy SOCKS5 inverso su WebSocket per bypassare la segmentazione di rete e raggiungere le API finanziarie.

LIGHTPAINT (Java) — installa una VPN SoftEther legittima con persistenza, manipolando le regole del firewall di Windows Defender.

MILDFROST (Java) — backdoor passiva che comunica via DNS tunneling, usata come canale di riserva.

KICKPLATE (Nim) — si maschera da Windows Update Health Tools per garantire persistenza e gestire tunnel SOCKS5.

BOATBEAM (Go) — finto server HTTPS su IIS in ascolto sulla porta 443, che si attiva solo in presenza di uno specifico cookie di sessione.

XWORM — infostealer commerciale reperibile su forum underground, usato come componente aggiuntiva.

Per l’esfiltrazione di segreti e credenziali, gli operatori si affidano perfino a servizi di appunti pubblici come dontpad.com, mentre negli ambienti cloud compromessi sono stati osservati deployment di pod Kubernetes usati come meccanismo di persistenza aggiuntivo.

Script scritti dall’IA: la firma involontariaUno degli elementi più interessanti del report è la prova, secondo Google, che BREEZE COMET utilizzi modelli linguistici di grandi dimensioni per generare gli script di ricognizione, automatizzare la validazione delle credenziali rubate e produrre logiche di pivoting specifiche per ogni vittima. Gli analisti hanno riconosciuto pattern tipici del codice generato da IA: commenti esplicativi eccessivi, strutture “srotolate” senza funzioni o astrazioni, header di esecuzione standardizzati e un’assenza quasi totale delle idiosincrasie tipiche di uno sviluppatore umano. Un dettaglio che, paradossalmente, ha aiutato gli analisti a fare attribuzione, ma che testimonia anche quanto l’IA generativa stia abbassando la barriera d’ingresso per gruppi criminali di fascia media.

Il risultato operativo è impressionante: secondo Google, in alcuni episodi il tempo tra la compromissione iniziale e l’esecuzione delle transazioni fraudolente sulle applicazioni bancarie core è di sole 24-48 ore. In un caso documentato, il gruppo ha eseguito centinaia di transazioni fraudolente sottraendo asset per decine di migliaia di dollari, ripulendo poi log degli eventi e directory create per cancellare le tracce.

Due righe per i difensoriIl caso BREEZE COMET conferma una tendenza che gli analisti di threat intelligence osservano da tempo in America Latina: gruppi nati come fraudster retail opportunistici stanno evolvendo verso la compromissione diretta dei sistemi di core banking, con un livello di ingegneria del malware paragonabile a quello di attori APT. Per le istituzioni finanziarie brasiliane — e, visto il riuso dell’infrastruttura in altri Paesi, potenzialmente per qualsiasi banca dell’America Latina e dell’Africa — le raccomandazioni di Google includono: applicazione rigorosa di whitelisting delle applicazioni (WDAC, Gatekeeper, fapolicyd), autenticazione MFA phishing-resistant su tutti i portali esterni, PowerShell in Constrained Language Mode con Script Block Logging attivo, segmentazione di rete che blocchi SMB e RDP tra segmenti non necessari, controllo NAC 802.1X sulle porte Ethernet fisiche nei negozi retail, e gestione centralizzata dei segreti per eliminare credenziali in chiaro nel codice.

La formazione dei dipendenti resta la prima linea di difesa: il vishing che impersona il supporto IT rimane, ancora oggi, il vettore d’accesso iniziale più efficace per questo genere di operazioni.

Indicatori di compromissione# Hash malware custom (SHA-256)
3b22605244dbace8f0c07c2c599f88c4b831bb07e9998b869a5da2759d27ceec COBALTSPIN
2214907e696bad85bde1d90c943ef66e413d7a5c6d7596ced25b74441200439a REALBREEZE
c0db6ddd6222d02ad7490399d33c61ded0076f0037409dc8498924458646d78a MILDFROST
6d4012e0dd3b56a3e52857734fa0d582cdf3c56f0e5decc8005c882d1d1c6ceb BOATBEAM
f139b4ca15feffb7a6633ec1a431c5c604b397576b56b5c863ae8fe4fa14db4f KICKPLATE
51fdd83b3737add7f3832bd0ad0b56863c0a8f7cf9bcc16fd787d1ae4b403ce6 XWORM
d2aa40cc53b40c6e76ac0677c4a54387b3f27ee94c85d9b2c3a3d66aeef92a66 XWORM
447e3a131e62bd33b1297739a7b959a92358a97f58554469044636a3c4f244e8 XWORM

Domini governativi brasiliani compromessi (staging/C2)

hxxps://procon[.]go[.]gov[.]br/ComprovantePDF[.]exe
hxxps://cmgovernadorluizrocha[.]ma[.]gov[.]br/Comprovantepdf[.]exe
hxxp://gcm[.]setelagoas[.]mg[.]gov[.]br/files/ti[.]zip
hxxps://minacu[.]go[.]gov[.]br/ComprovantePDF[.]exe
hxxps://conseg[.]ssp[.]go[.]gov[.]br/COAF-POLICIAFEDERAL[.]exe
hxxps://suporte[.]camaratunapolis[.]sc[.]gov[.]br/ti/attvpn[.]zip
hxxps://tisup[.]camaratunapolis[.]sc[.]gov[.]br/SoftEther[.]exe
hxxp://suporte[.]ourinhos[.]sp[.]gov[.]br/files/s[.]zip
hxxps://servicos[.]salto[.]sp[.]gov[.]br/j[.]jar

Infrastruttura riutilizzata fuori dal Brasile

hxxps://www.mrtb[.]gov[.]ng/apps/attvpn[.]vip (Nigeria)
hxxp://credeb[.]gov[.]gn/r[.]zip (Guinea)
hxxps://sit[.]baer[.]gob[.]ve/r[.]exe (Venezuela)
hxxps://jmcov[.]gov[.]py/cxv[.]exe (Paraguay)

Canale di esfiltrazione

dontpad[.]com

YARA - REALBREEZE (utility LDAP brute-force)

rule M_Utility_REALBREEZE_2 {
strings:
$s1 = "IP/REDE" wide
$s2 = "SENHA" wide
$s5 = "get_SamAccountName"
$s6 = "get_txtHostname"
condition:
uint16(0) == 0x5A4D and all of them
}Fonte primaria: Google Threat Intelligence Group e Mandiant, “Financially Motivated Threat Actor BREEZE COMET Targets Brazil”, 1° settembre 2026.

Si parla di:

Toggle

Ventidue Paesi su sei continenti, 58 arresti, 263 sospetti identificati e oltre 143 milioni di euro di #frodi da investimento smantellate: sono i numeri di Operation Jackal IV, l’ultima offensiva coordinata da #Interpol contro Black Axe e le altre confraternite criminali dell’Africa occidentale che da anni dominano lo scenario globale di romance #scam, business email compromise e riciclaggio digitale. Non è la prima volta che le forze dell’ordine colpiscono questa rete — ma la scala e la precisione chirurgica con cui questa edizione ha smontato l’ecosistema di supporto, più che i singoli truffatori, la rende un caso di studio su come si combatte oggi il #cybercrime organizzato transnazionale.

Da confraternita universitaria a mafia digitale globaleBlack Axe nasce alla fine degli anni ’70 come confraternita studentesca nigeriana (il “Neo-Black Movement of Africa”) prima di trasformarsi, nei decenni successivi, in una delle organizzazioni criminali transnazionali più redditizie al mondo. Oggi il gruppo — insieme a organizzazioni affiliate o imitatrici — genera miliardi di dollari l’anno operando in decine di Paesi, con una struttura gerarchica rigida che ricorda più una holding criminale che una gang di strada. È proprio questa capacità organizzativa, unita all’adozione spregiudicata delle tecnologie digitali, ad aver reso Black Axe un bersaglio prioritario per Interpol negli ultimi anni, con le precedenti Operation Jackal I e II (2022-2023, circa 200 arresti complessivi) e Jackal III (2024, alcune centinaia di arresti e circa 3 milioni di dollari sequestrati) che hanno progressivamente affinato la mappatura dell’infrastruttura criminale del gruppo.

Il modus operandi: dalla truffa romantica al sextortionIl catalogo criminale documentato dagli investigatori in questa quarta edizione dell’operazione copre l’intero spettro delle frodi digitali su larga scala:

Romance scam: relazioni sentimentali fittizie costruite su app di incontri e #social #network, tipicamente rivolte a persone anziane o pensionati, finalizzate a estorcere trasferimenti di denaro nel tempo.

Business Email Compromise (#BEC): compromissione o #spoofing di account email aziendali per dirottare pagamenti e bonifici verso #conti controllati dalla rete criminale.

Investment fraud: piattaforme di investimento fasulle, spesso presentate tramite call center strutturati, che promettono rendimenti garantiti su criptovalute o mercati finanziari.

Sextortion: un trend in preoccupante crescita secondo gli investigatori, che include la coercizione di vittime minorenni sui social media — un’evoluzione particolarmente allarmante del modello criminale tradizionale del gruppo.

Crime-as-a-Service: fornitura, spesso tramite dark web, di infrastruttura di supporto a terzi — domini web, servizi di riciclaggio, identità sintetiche — che permette anche ad attori meno strutturati di operare su scala industriale.

Gli inquirenti descrivono una divisione dei ruoli interna sofisticata, con membri specializzati come agenti di “conversion” (che convincono le vittime a versare denaro) o di “retention” (che mantengono in vita la relazione fraudolenta il più a lungo possibile per massimizzare l’estorsione) — una struttura organizzativa quasi aziendale che riflette il salto di qualità della criminalità digitale organizzata rispetto al singolo truffatore opportunista.

La geografia dei blitz: Sud Africa, Romania, Argentina, ItaliaOperation Jackal IV ha coinvolto le forze dell’ordine di 22 Paesi — tra cui Argentina, Australia, Austria, Canada, Costa d’Avorio, Emirati Arabi Uniti, Francia, Germania, Indonesia, Irlanda, Italia, Giappone, Malesia, Nigeria, Paesi Bassi, Portogallo, Regno Unito, Spagna, Stati Uniti, Sudafrica e Svezia — con i risultati operativi più significativi concentrati in quattro teatri:

Sud Africa: 39 arresti, sette sedi perquisite a Johannesburg, 2,67 milioni di dollari sequestrati e 257 conti bancari congelati, con focus su romance e investment scam ai danni di pensionati.

Argentina: 17 arresti e 196 sospetti identificati nello smantellamento di una rete di crime-as-a-service che forniva domini web e servizi di riciclaggio ad altre organizzazioni criminali.

Romania: 11 arresti legati a un call center dedicato a investment scam, con sequestro di circa 379.000 dollari in contanti e criptovalute, sei immobili e orologi di lusso confiscati.

Italia: identificazione di un individuo collegato a una rete di riciclaggio “pan-europea”; un singolo conto avrebbe movimentato circa 736.000 dollari attraverso società di comodo e servizi di rimessa internazionale.

Colpire l’ecosistema, non solo i truffatoriL’elemento più significativo di Jackal IV, secondo gli analisti, è lo spostamento del focus investigativo dai singoli operatori di frontline — spesso facilmente sostituibili — verso l’infrastruttura di supporto che rende possibile l’intera economia criminale: fornitori di domini, money mule reclutati su scala industriale, reti di riciclaggio basate su wallet crypto e conti di comodo, servizi di identità sintetica venduti come commodity nei forum underground. È lo stesso approccio “disruption dell’ecosistema” che negli ultimi anni le forze dell’ordine occidentali hanno applicato con crescente efficacia contro le infrastrutture ransomware, ed è la ragione per cui, nonostante il numero di arresti diretti resti relativamente contenuto rispetto alla scala globale del fenomeno, l’impatto economico dichiarato — oltre 143 milioni di euro tra fondi sequestrati e frodi neutralizzate — risulta sproporzionatamente alto.

Due righe pratiche per le organizzazioniFormazione anti-BEC mirata: i controlli di verifica su cambi improvvisi di coordinate bancarie o richieste di pagamento urgenti restano la contromisura più efficace ed economica contro il vettore BEC, ancora oggi tra i più redditizi per queste reti.

Monitoraggio dei conti aziendali per pattern di money muling: transazioni frammentate verso conti neo-aperti o società di comodo sono un segnale che i team antifrode dovrebbero correlare con maggiore attenzione, specie in presenza di corridoi geografici ad alto rischio.

Consapevolezza su romance scam e sextortion per gli utenti più vulnerabili: campagne di sensibilizzazione rivolte a categorie a rischio (anziani, adolescenti) restano uno strumento di prevenzione a basso costo e alto impatto.

Collaborazione con le piattaforme: la rapidità di segnalazione di profili e wallet sospetti a exchange di criptovalute e piattaforme social riduce la finestra operativa di queste reti, che dipendono dalla persistenza di identità e infrastrutture online per operare su scala.

Fonti: CyberScoop, Dark Reading, P.M. News Nigeria.

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

#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 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)

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

Connor Riley Moucka, 26 anni, di Kitchener (Ontario), si è dichiarato colpevole mercoledì 5 agosto 2026 davanti a un tribunale federale dello stato di Washington per #frode informatica, frode telematica, furto di identità aggravato e cospirazione. È l’epilogo giudiziario di quella che resta una delle campagne di furto dati ed estorsione più estese mai orchestrate contro un singolo fornitore #cloud: l’attacco del 2024 alla piattaforma #Snowflake, che ha colpito almeno 165 aziende clienti e portato al furto di miliardi di record. Moucka rischia fino a 32 anni di carcere e sarà sentenziato il 27 ottobre.

Non una violazione di Snowflake, ma delle credenziali dei suoi clientiIl dettaglio tecnico che ha reso il caso Snowflake un caso di #scuola è che la piattaforma stessa non è mai stata compromessa. #Mandiant, incaricata da Snowflake di condurre l’indagine forense, ha attribuito la campagna a un cluster tracciato come UNC5537 e ha confermato che gli attaccanti hanno sfruttato credenziali valide ma esposte da tempo — in alcuni casi risalenti al 2020 — raccolte tramite #infostealer su macchine di dipendenti o partner delle aziende clienti. La mancanza sistemica di autenticazione a più fattori sugli account Snowflake ha fatto il resto, trasformando credenziali rubate anni prima in un accesso diretto ai #data warehouse di centinaia di organizzazioni.

Secondo Mandiant, il gruppo dietro la campagna era basato in Nord America e collaborava con almeno un membro operante dalla Turchia — identificato in seguito in John Erin Binns, già legato all’hack di T-Mobile del 2021 e arrestato in Turchia nel 2024.

Le vittime: dalle telco alla sanità, passando per la vendita di bigliettiL’elenco delle aziende colpite tra febbraio e ottobre 2024 legge come una rassegna delle violazioni più discusse dell’anno: AT&T, con i log di chiamate e #SMS di oltre 100 milioni di clienti; #Ticketmaster/Live Nation, con dati relativi a circa 560 milioni di utenti; Advance Auto Parts; uno dei distretti scolastici più grandi degli Stati Uniti; Neiman Marcus; Santander; LendingTree. I dati sottratti includevano estratti bancari, informazioni finanziarie, numeri di registrazione DEA, patenti di guida, passaporti e numeri di previdenza sociale.

Estorsione, ri-estorsione e mercati undergroundDopo l’esfiltrazione, gli attaccanti hanno tentato di estorcere le aziende vittime minacciando la pubblicazione dei dati online, incassando circa 2,5 milioni di dollari in pagamenti di riscatto. Moucka ha inoltre guadagnato altri 495.000 dollari pubblicizzando parte dei dati rubati su forum criminali come #BreachForums e XSS.is. Un dettaglio particolarmente inquietante emerso dagli atti processuali riguarda una vittima estorta due volte: nella seconda occasione, Moucka avrebbe utilizzato dati personali relativi a un funzionario governativo ex ed ai suoi familiari per aumentare la pressione. Le perdite complessive stimate per le vittime ammontano a circa 9,5 milioni di dollari.

Prima dell’arresto, avvenuto nel novembre 2024 e seguito dall’estradizione negli Stati Uniti nel luglio 2025, Moucka aveva parlato con la testata 404 Media dicendosi consapevole dell’imminente cattura e ammettendo di aver distrutto prove in vista dell’arresto.

Due righe per i difensoriIl caso Snowflake ha ridefinito il modello di minaccia per i servizi SaaS e data warehouse: non serve violare il fornitore cloud se le identità dei suoi clienti restano esposte. Per i team di sicurezza le lezioni pratiche restano attuali due anni dopo i fatti:

Imporre l’autenticazione a più fattori su tutti gli account con accesso a piattaforme cloud e data warehouse, senza eccezioni per account di servizio o legacy.

Ruotare periodicamente le credenziali e trattare come compromesse quelle esposte in precedenti data breach, anche se risalenti a diversi anni prima.

Monitorare i mercati underground e i forum come BreachForums per individuare precocemente la messa in vendita di dati aziendali.

Validare i log di accesso alle piattaforme SaaS per individuare pattern anomali provenienti da IP o infrastrutture non riconducibili agli utenti abituali.

La condanna definitiva di Moucka, attesa il 27 ottobre, non chiude del tutto il caso: restano aperte le posizioni di altri complici legati alla campagna, a conferma che dietro un singolo nome pubblico si nasconde quasi sempre un’infrastruttura criminale collaborativa e distribuita.

Timeline e dati chiaveCampagna attiva: febbraio - ottobre 2024
Cluster di minaccia (Mandiant): UNC5537
Aziende clienti Snowflake colpite: almeno 165
Vettore d'accesso: credenziali valide esposte (alcune dal 2020), assenza di MFA
Vittime principali: AT&T (100M+ utenti, log chiamate/SMS), Ticketmaster/Live Nation (560M utenti),
Advance Auto Parts, Neiman Marcus, Santander, LendingTree, distretto scolastico USA
Guadagni stimati: ~2,5M USD (riscatti) + 495.000 USD (vendita dati underground)
Perdite vittime stimate: ~9,5M USD
Mercati underground utilizzati: BreachForums, XSS.is
Complice: John Erin Binns (Turchia, già legato all'hack T-Mobile 2021)
Arresto Moucka: novembre 2024 (Canada) - Estradizione: luglio 2025
Dichiarazione di colpevolezza: 5 agosto 2026
Sentenza attesa: 27 ottobre 2026 (fino a 32 anni di carcere)

Un archivio da 388 MB chiamato semplicemente “中国龙.zip” (Chinese Dragon) circola da mesi sui canali Telegram del cybercrime cinese. Dentro c’è il codice sorgente completo di Flying Eagle, un framework criminale che non è “solo” un trojan Android, ma una vera piattaforma industriale per costruire e gestire spyware mobile su larga scala — la stessa che ha alimentato una finta app della “polizia cinese” usata per svuotare conti Alipay e WeChat. Ora che il codice è trapelato, i ricercatori di Hunt.io e dell’analista indipendente NetAskari hanno mappato 170 server ancora attivi legati all’infrastruttura, mentre tra gli stessi criminali è scoppiato un regolamento di conti che ha già partorito un erede, Night Dragon.

Una app “governativa” che rubava le passwordLa storia riemerge alla luce del sole a giugno 2026, quando il National Cybersecurity Notification Center cinese ha diffuso un avviso pubblico su una applicazione fraudolenta che si spacciava per “公安一网通办”, un servizio online delle Pubbliche Sicurezze Provinciali (GongAn). L’app veniva distribuita dal dominio 110gongan[.]com e, una volta installata, era in grado di rubare dati di pagamento e prendere il controllo remoto del dispositivo. Le autorità hanno raccomandato a chi l’avesse installata di rimuoverla, scansionare il device, cambiare le password degli account coinvolti, congelare i canali di pagamento in caso di movimenti sospetti e sporgere denuncia.

Quell’app era solo la punta dell’iceberg. Dietro c’era Flying Eagle: un builder che permette a un operatore di scegliere nome, icona e testo di adescamento dell’app, indicare l’indirizzo C2, e generare in automatico un APK Android firmato e pronto alla distribuzione, partendo da due template base. I campioni prodotti dal builder vengono rilevati dai motori antivirus come SpyNote, famiglia di RAT Android nota da anni, e sfruttano i servizi di accessibilità di Android per l’escalation di privilegi e l’iniezione di gesture — controllo pressoché totale del dispositivo della vittima.

Non un malware, una piattaforma industrialeCiò che rende Flying Eagle diverso da un comune RAT è la sua natura di prodotto “chiavi in mano” per operatori criminali con competenze tecniche limitate. L’archivio trapelato contiene un intero deployment Docker con server nginx, PHP, MySQL e un WebSocket server Node.js, oltre a toolchain complete per la compilazione Android (Java 11 e Android SDK build tools), template di phishing pronti — servizi di streaming per adulti in cinese, cloni di TikTok, applicazioni finanziarie e persino landing page per finti progetti di pubblica utilità che rimandano all’operatore statistiche di visite e download — e un certificato TLS di default.

Gli URL di callback verso il server di comando e controllo, incorporati in ogni APK generato, sono cifrati con AES-128-CBC usando IV, password e salt hardcoded, con chiave derivata tramite PBKDF2-SHA1 a 65.536 iterazioni. I commenti nel codice sorgente rivelano che questi parametri servono a mantenere la compatibilità con il binario Windows .NET originale (EaodWorker.exe), confermando che la versione Docker trapelata è una porting diretto di uno strumento più vecchio. Per abbassare l’entropia del pacchetto ed eludere l’analisi statica, il builder inietta inoltre tra 2,8 e 3,5 MB di JSON Base64 travestito da cache di configurazione SDK legittima.

La caccia ai 170 serverPer ricostruire l’estensione reale dell’infrastruttura, i ricercatori hanno sfruttato un’impronta digitale ricorrente: i server Flying Eagle rispondono con un redirect HTTP 302 verso l’endpoint HTTPS, includono l’header Strict-Transport-Security: max-age=31536000 e, prima che carichi il branding personalizzato dell’operatore, mostrano brevemente il titolo di pagina “AdminPro”. Incrociando questa firma con il certificato TLS di default incluso nell’archivio trapelato, sono stati identificati 158 server tramite il titolo della pagina e altri 12 tramite il certificato, per un totale di 170 server attivi negli ultimi 30 giorni di telemetria — una cifra che i ricercatori stessi definiscono conservativa, perché esclude i server che non restituiscono esattamente il redirect atteso. È importante sottolineare che questo numero descrive impronte infrastrutturali, non necessariamente vittime, operatori o C2 confermati uno per uno.

Buona parte dell’infrastruttura, inclusi i due IP citati nell’avviso ufficiale cinese (207.56.30.188 e 207.56.30.194), è ospitata su AS54801 (Zillion Network Inc.), un provider di Hong Kong che compare più volte come piattaforma preferita per il malware mobile in questo ecosistema. Uno dei server ha addirittura mostrato, temporaneamente, un pannello di gestione dispositivi che indicava utenze “guadagna facile” tipiche di operatori criminali a scopo di lucro.

Ladri tra ladri: quando i criminali si smascherano a vicendaIl canale Telegram Yx科技 (Yx Technology), creato ad aprile 2026, non ha esordito con un semplice annuncio: i primi messaggi erano istruzioni passo passo su come usare strumenti di accesso remoto per svuotare conti Alipay e WeChat Pay, con le vittime definite spregiativamente “pesci” (鱼) e servizi di cash-out offerti al 20-50% della transazione. Il 26 aprile il canale ha distribuito gratuitamente il pacchetto Flying Eagle sotto forma dell’archivio Chinese Dragon.

Da qui la parte più “da romanzo”: un secondo canale, SQLRCE0, ha iniziato a far girare messaggi secondo cui un attore non identificato avrebbe compromesso l’infrastruttura clienti di Yx Technology, sottraendo dati relativi a 189 server Flying Eagle. La rivendicazione non è stata confermata in modo indipendente dai ricercatori, ma il caos generato — codice rubato che diventa a sua volta merce rubata — è di per sé indicativo della frammentazione e della sfiducia reciproca dentro questi ecosistemi criminali cinesi.

Night Dragon: l’erede è già onlineIl 23 giugno 2026 lo stesso canale SQLRCE0 ha lanciato Night Dragon, un nuovo kit di controllo Android indipendente. I ricercatori hanno individuato al momento solo due server associati, entrambi ospitati — non a caso — sullo stesso provider hongkonghese AS54801. Uno dei pannelli esposti mostrava 46 dispositivi “online” e 29 “attivi”, tutti geolocalizzati in Cina, ma non è stato possibile stabilire se si tratti di vittime reali o di dati di test. Una seconda versione del framework risultava già in sviluppo al 12 luglio. È bene chiarire un possibile equivoco: questo Night Dragon del 2026 non ha nulla a che vedere con l’omonima campagna di spionaggio cinese documentata da McAfee nel 2011 — qui si parla di crimeware finanziario, non di intelligence offensiva.

Due righe per i difensoriDiffidare sistematicamente di APK “governativi” o “di pubblica utilità” distribuiti fuori dal Play Store: il sideloading resta il principale vettore di infezione per questa famiglia di minacce.

Monitorare le richieste di attivazione dei servizi di accessibilità Android da parte di app non aziendali: è il meccanismo chiave usato per l’escalation di privilegi e il controllo remoto.

Per i team threat intelligence, il fingerprint “AdminPro” + redirect 302 + certificato di default è riutilizzabile per identificare infrastrutture derivate dallo stesso codice trapelato, comprese eventuali nuove fork oltre a Night Dragon.

Il caso dimostra ancora una volta come i leak di codice sorgente criminale — volontari o meno — accelerino la proliferazione di varianti, più che ridurre la minaccia: ogni fork riparte da una base già matura.

Indicatori di compromissione# Domini/infrastruttura Flying Eagle
110gongan[.]com # App fasulla "polizia cinese" (GongAn)
fusu.us[.]ci
fusu666[.]cc -> 207.56.30[.]188
ls.j2x8a[.]top -> 207.56.30[.]194 (cert emesso 2026-06-04)
xyttkx[.]cc, txl.xyttkx[.]cc, h5.xyttkx[.]cc, alcs.xyttkx[.]cc

IP

207.56.30[.]188 AS54801 Zillion Network Inc. (Hong Kong)
207.56.30[.]194 AS54801 Zillion Network Inc. (Hong Kong)

Archivio trapelato

中国龙.zip (Chinese Dragon) - 388 MB, distribuito via Telegram (Yx科技) dal 2026-04-26

Campioni APK (SHA256)

c692ad120cc90548d48dbe57d006f2403c49833b8993af3c38fe031eb39999bd autoclicker_pro.apk
4395db6ad53a415532673b16f5b64207d53cecc5b15a736c038cf3890368a164 net.extractor.terminator.channel.apk
5dee5cde6f2874c582effe302960b21569ee007e9e0cd4f7499d418cceb9095b com.sequencer.classifier.processor.apk
b803cd5032dc1abd7aabc45c8cadc471c8a59872a95d48807f13e230c58230f3 net.cataloger.curator.stager.apk
d8a82d7b4457352774772bfac094127d7f67526ae7011d838cc3f7ccc15fd86e net.listener.transactor.authorizer.apk

Fingerprint di caccia

HTML title = "AdminPro", redirect HTTP 302 -> HTTPS,
header Strict-Transport-Security: max-age=31536000

Night Dragon (lancio: 2026-06-23, stesso hosting AS54801)

Fonti primarie: Hunt.io/NetAskari, “Flying Eagle Android RAT: Leaked Source Code, 170 Active Servers, and a New Platform Called Night Dragon” (28 luglio 2026); The Hacker News, 29 luglio 2026; avviso pubblico del National Cybersecurity Notification Center cinese (18 giugno 2026).

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.

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

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

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

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

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

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

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

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

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

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

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

Comportamenti osservati (Windows):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pattern webshell

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

Hash file webshell (SHA-256)

55a1eb4c2d3da04376df39d7ba832569c6af1a37a0cf2b95f754ac898023a30c

Marcatore di attivita di file-listing dell'attaccante

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

Header HTTP sospetto usato dagli operatori

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Diciannovemila file, 14,3 gigabyte di planimetrie, elenchi fornitori, verbali di ispezione e persino polizze assicurative contro il terrorismo. È quanto la gang di data extortion World Leaks ha pubblicato sul proprio leak site relativamente alla Kudankulam Nuclear Power Plant, la più grande centrale nucleare indiana, dopo che l’appaltatore Reliance Infrastructure ha rifiutato di pagare il riscatto. Non si tratta dei sistemi di controllo del reattore — quelli restano di competenza russa, forniti da Rosatom — ma la mole di documentazione tecnica esposta è comunque sufficiente per preoccupare gli esperti di sicurezza nucleare.

Un incidente nato a maggio, esploso a luglioLa vicenda comincia il 29 maggio 2026, quando Yotta, il data center indiano che ospita i server di Reliance Infrastructure, rileva un’attività sospetta su un’istanza riconducibile al gruppo Reliance. Yotta dichiara di aver bloccato l’esecuzione di un probabile ransomware in tempo reale. A fine giugno, però, Reliance Infrastructure comunica a Yotta di aver ricevuto rivendicazioni di data breach da parte di “attori esterni”: il tempo tra il contenimento tecnico e la scoperta dell’esfiltrazione reale è il primo campanello d’allarme di questa storia, e non è un caso isolato nel panorama delle intrusioni contro appaltatori di infrastrutture critiche.

Il 15 luglio i file compaiono sul portale World Leaks, accessibile solo tramite browser specializzati per l’accesso al dark web. Secondo il ricercatore indipendente Rakesh Krishnan, che per primo ha segnalato la fuga di dati a Reuters, i documenti riferiti alla sigla “KKNP” (Kudankulam Nuclear Power) risultavano online già dall’11 giugno — quasi un mese prima che la notizia diventasse pubblica. Reliance ha confermato una “violazione parziale” dei propri dati, senza specificarne l’estensione.

Chi è World LeaksWorld Leaks non è un nome nuovo per chi segue il cybercrime organizzato. Il gruppo è la reincarnazione operativa di Hunters International, storica gang ransomware che nel 2025 ha scelto di abbandonare quasi del tutto la cifratura dei file per concentrarsi sulla pura estorsione dei dati: niente più payload di encryption da sviluppare e far evolvere contro gli antivirus, solo intrusione silenziosa, permanenza prolungata nella rete della vittima, esfiltrazione massiva e pressione pubblica sul leak site. Un modello di business più snello, più difficile da rilevare con gli strumenti EDR tradizionali (che sono tarati soprattutto sul comportamento anomalo della cifratura) e altrettanto redditizio.

Dal gennaio 2025 il gruppo rivendica oltre 150 vittime, tra cui Nike (1,4 TB di dati, 188.347 file, gennaio 2026), Dell, UBS e — soprattutto — un trio di società del conglomerato indiano Tata: Tata Technologies (1,4 TB, ereditata direttamente da Hunters International nel marzo 2025), Tata Electronics (630,4 GB, 204.341 file, giugno 2026, con dati sensibili di Apple e Tesla legati alla produzione di iPhone) e ora, con Reliance, un secondo grande gruppo industriale indiano colpito nello spazio di poche settimane. Nel caso Tata, World Leaks aveva dichiarato a Reuters di aver chiesto un riscatto di 1,5 milioni di dollari, pubblicando i dati dopo che l’azienda aveva “ignorato” la richiesta. Lo stesso copione — silenzio della vittima, contatore che scade, pubblicazione integrale — si è ripetuto con Reliance.

Cosa contengono davvero i fileReuters, che ha potuto visionare parte del materiale senza tuttavia certificarne l’autenticità al 100%, descrive documenti datati tra il 2016 e la metà del 2025: planimetrie dei sistemi di ventilazione e raffreddamento delle Unità 3 e 4 (ancora in costruzione, operative entro il 2027, per una capacità combinata di 2.000 MW), la mappa completa di una control room comune, proposte di fornitori, un elenco di supplier approvati e i verbali di un’ispezione congiunta del 2024 tra Nuclear Power Corporation of India (NPCIL) e Reliance, corredati di fotografie degli impianti. Tra i documenti più delicati compare anche una polizza assicurativa che garantirebbe 112 milioni di dollari a Reliance Infrastructure e NPCIL in caso di atto terroristico contro le Unità 3 o 4 — un dettaglio che, se autentico, offre a un aggressore una stima concreta di quanto l’operatore stesso consideri “critico” quel bersaglio.

Nickolas Roth, senior director della Nuclear Threat Initiative, ha sottolineato a Reuters il vero rischio operativo di questo genere di fughe: non serve accedere ai sistemi del reattore per costruire un profilo utile a un attacco fisico o informatico successivo. Planimetrie, elenchi fornitori e mappe di controllo “mostrano a un avversario non solo chi ha accesso al progetto, ma quali sistemi quell’accesso può raggiungere” — in altre parole, permettono di ricostruire la catena di sicurezza dell’impianto e di individuarne i punti deboli, dai fornitori meno protetti ai varchi fisici meno sorvegliati.

Non è la prima volta per KudankulamKudankulam ha già una storia di incidenti cyber: nel 2019 la rete amministrativa della centrale era stata infettata da un malware attribuito a un gruppo nordcoreano — un episodio che, secondo NPCIL, non aveva toccato i sistemi operativi dell’impianto. Il fatto che la stessa struttura torni due volte in sette anni al centro di un incidente informatico, per quanto di natura diversa, la dice lunga sulla difficoltà di isolare completamente reti industriali critiche dalla catena di fornitura IT che le circonda: la violazione non è avvenuta contro NPCIL direttamente, ma contro un fornitore terzo (Reliance) ospitato su infrastruttura di un altro fornitore terzo (Yotta) — un classico esempio di rischio di supply chain in ambito OT/critical infrastructure.

Contesto: l’India nel mirinoIl caso Reliance si inserisce in un trend più ampio. Secondo dati Surfshark, l’India è il terzo Paese al mondo per numero di account compromessi nel 2025 (28,9 milioni), dietro solo a Stati Uniti e Francia. Un report del Data Security Council of India realizzato con Seqrite ha rilevato che il 73% delle 204 organizzazioni intervistate “non sa se sia mai stata attaccata” e il 57% non applica pratiche basilari di igiene informatica. In un Paese che sta rapidamente espandendo il proprio parco nucleare — Kudankulam è centrale nel piano del governo Modi — il divario tra ambizione infrastrutturale e maturità della sicurezza informatica degli appaltatori resta il vero punto debole.

Due righe per i difensoriPer i team di sicurezza che gestiscono ambienti industriali o infrastrutture critiche, il caso Reliance/World Leaks offre alcune lezioni pratiche:

Il rilevamento di un tentativo di cifratura bloccato non implica che l’esfiltrazione dei dati sia stata impedita: va sempre assunta l’ipotesi di data theft anche quando il ransomware “classico” viene neutralizzato in tempo.

La sicurezza dei fornitori terzi (in questo caso un data center che ospita un appaltatore di un operatore nucleare) va trattata come estensione diretta del perimetro critico, con audit periodici e segmentazione delle reti che ospitano documentazione sensibile.

Documentazione apparentemente “amministrativa” — planimetrie, elenchi fornitori, verbali di ispezione, polizze assicurative — va classificata e protetta con lo stesso rigore dei dati operativi, perché costituisce ricognizione pronta all’uso per un aggressore.

Il ritardo tra compromissione (29 maggio), notifica interna (fine giugno) e pubblicazione pubblica (15 luglio, con dati online già dall’11 giugno) mostra quanto sia critico ridurre il tempo di rilevamento delle fughe di dati, anche tramite monitoraggio proattivo dei leak site e dei marketplace del dark web.

Dati chiave dell’incidenteVittima: Reliance Infrastructure (contractor NPCIL/Kudankulam NPP)
Hosting compromesso: Yotta Data Services (data center terze parti)
Gruppo responsabile: World Leaks (rebrand di Hunters International)
Modello operativo: data extortion senza cifratura (double extortion "leak-only")
Volume totale dati Reliance: ~858.000 file
File più sensibili pubblicati: ~19.000 file / 14,3 GB
Data compromissione rilevata: 29 maggio 2026
Data comparsa dati su leak site: online dall'11 giugno, pubblicazione ufficiale 15 luglio 2026
Precedenti vittime note del gruppo: Nike, Dell, UBS, Tata Technologies, Tata Electronics, Mediaworks
Riscatto richiesto (caso Tata, riferimento): 1,5 milioni di USD
Accesso al leak site: solo tramite browser dark web dedicatoNPCIL, CERT-In e l’ufficio stampa del governo indiano non hanno risposto alle richieste di commento di Reuters. L’indagine è in corso, e resta da chiarire l’estensione reale della compromissione oltre i file già pubblicati.