Google, FBI Disrupt NetNut Residential Proxy Network Powered by Millions of Devices

Google, the FBI, and other organizations coordinated in a joint effort to dismantle NetNut, a massive residential proxy network.

Also known as Popa, NetNut is believed to consist of more than 2 million Android devices such as smart TVs and streaming boxes, that have been infected through trojanized applications and malware such as Badbox 2.0.

The network’s operator, linked to the publicly-traded Israeli firm Alarum Technologies Ltd, rented the residential proxies to various threat actors, including cybercriminal and espionage groups.

In a single week in June, Google observed 316 distinct threat clusters using NetNut to hide their locations in password-spray attacks and to access victim environments.

“We believe our coordinated actions have caused significant degradation to NetNut’s proxy network and its business operations, reducing the available pool of devices for the proxy operator by millions,” Google said.

As part of the operation, the internet giant disabled Google accounts and associated services used for command-and-control (C&C), dismantling the botnet’s backend infrastructure.

Advertisement. Scroll to continue reading.

Additionally, it disabled the infected applications via Google Play Protect and automatically warned victims of the threat. Google also shared threat intelligence with industry partners and law enforcement.

According to Google, NetNut is not only selling access to the residential proxy network under its own brand, but also operates a reseller program, allowing other popular brands to whitelabel the NetNut botnet.

The NetNut takedown follows the January disruption of IPIDEA, and is expected to have a ripple effect across the ecosystem.

“What we have observed is that when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller. We recognize that creating a lasting disruption in this fluid ecosystem means we must scale our efforts to target the infrastructure of several interconnected providers,” Google says.

Related: Google Sues Operators of 10-Million-Device Badbox 2.0 Botnet

Related: 15,000 WordPress Websites Cleaned Up in SocGholish Botnet Takedown

Related: Dutch Police Dismantle Massive 17-Million-Device Botnet

Related: GlassWorm Botnet Disrupted

Related: Aisuru and Kimwolf DDoS Botnets Disrupted in International Operation

https://www.securityweek.com/google-fbi-disrupt-netnut-residential-proxy-network-powered-by-millions-of-devices/




Intelligence russa e app di messaggistica: il phishing ora punta alle chiavi di backup di Signal

L’intelligence ucraina conferma e amplia l’allarme statunitense: i servizi russi non rompono la crittografia delle app di messaggistica, ma convincono le vittime a consegnare le chiavi che proteggono i loro backup. Il bersaglio sono funzionari, militari, politici e attivisti in Ucraina, Europa e Stati Uniti. La svolta operativa più recente riguarda in modo specifico Signal; WhatsApp rientra nel quadro più ampio di targeting, non in questa singola tattica.

Il 27 giugno il Servizio di Sicurezza dell’Ucraina (SSU) ha reso noto, in un comunicato su Telegram, di avere ricostruito insieme all’FBI una campagna di lungo corso condotta dai servizi di intelligence russi per violare gli account di messaggistica di obiettivi ad alto valore informativo. Lo SSU non attribuisce l’attività a uno specifico gruppo, ma la inquadra come operazione sistematica di spionaggio: l’obiettivo dichiarato è accedere a informazioni militari, politiche ed economiche scambiate dagli utenti e sottrarne i dati personali. La tecnica di ingresso è un SMS che si finge il bot di assistenza della piattaforma e induce la vittima a rivelare le proprie credenziali.

La comunicazione ucraina arriva il giorno dopo l’aggiornamento congiunto FBI e CISA del 26 giugno, l’avviso
I-062626-PSA
, che rivede il precedente PSA di marzo e introduce l’elemento operativo più rilevante. Gli attori non si limitano più a carpire codici di verifica o PIN dell’account, né a collegare dispositivi controllati dall’aggressore: ora puntano a farsi consegnare la Backup Recovery Key, la chiave che cifra la copia di backup delle conversazioni. Chi ottiene quella chiave può ripristinare il backup, leggere la cronologia di messaggi privati e di gruppo e prendere il controllo dell’account.

Il punto tecnico: non è una falla di Signal

L’FBI è esplicito su un aspetto che conviene tenere fermo per non amplificare letture distorte: gli attori hanno compromesso singoli account, non la crittografia delle applicazioni né le applicazioni stesse. Il perimetro violato è quello del recupero e del backup, non quello del protocollo end-to-end. La leva resta l’inganno: i messaggi-esca riprodotti nell’avviso si presentano come comunicazioni ufficiali di Signal e guidano passo passo l’utente a generare la chiave di recupero e a incollarla in chat, con la promessa di evitare la perdita di messaggi o di sincronizzare un backup a rischio.

Il flusso documentato dall’FBI presuppone due passaggi: prima la vittima attiva il backup seguendo la finta comunicazione (Figura 1 dell’avviso, etichettata Sample Phishing Message 1), poi consegna la chiave di recupero (Figura 2). Entrambi i messaggi-esca ricalcano i passaggi dell’interfaccia di Signal (impostazioni, backup, visualizzazione della chiave), e proprio per questo la nuova tattica delle chiavi di backup va circoscritta a Signal, mentre il riferimento a WhatsApp resta valido per la campagna nel suo insieme.

C’è un dettaglio che alza la posta sul piano della persistenza. Se la vittima condivide la Backup Recovery Key, quella chiave resta valida anche dopo la ricreazione dell’account sullo stesso numero di telefono: l’aggressore potrebbe quindi rientrare in un secondo momento. L’unica contromisura indicata è generare una nuova chiave nelle impostazioni, operazione che invalida la precedente per i download futuri; resta però il fatto che un backup già scaricato dall’attaccante non si annulla. La separazione tra ciò che si può ancora proteggere e ciò che è già compromesso è netta, e va comunicata con altrettanta chiarezza agli utenti a rischio.

Attribuzione e nomi cluster

Sul fronte dell’attribuzione conviene muoversi con cautela, perché le diverse fonti usano etichette diverse. L’FBI parla di più cluster riconducibili ai servizi russi (RIS), tra cui ufficiali dell’FSB inseriti nella Guardia di Frontiera e soggetti che operano per conto delle forze militari, e li traccia pubblicamente come UNC5792
e UNC4221
. Lo SSU, dal canto suo, non nomina un gruppo. Le ondate di attacco analoghe contro utenti Signal e WhatsApp sono state ricondotte in letteratura ai cluster noti come Star Blizzard, UNC5792
(parzialmente sovrapponibile a UAC-0195
per il CERT-UA) e UNC4221
(equivalente a UAC-0185
): nomenclature da incrociare con prudenza, perché la stessa attività può comparire sotto sigle differenti a seconda del fornitore di intelligence o dell’agenzia nazionale.

Va segnalato anche un punto su cui è facile inciampare leggendo l’avviso: la frase che attribuisce gli attacchi a hacker dall’Iran e da Paesi post-sovietici non è una valutazione dell’FBI, ma testo del messaggio-esca riprodotto nell’avviso, ossia parte stessa della truffa.

Perché interessa lettori europei e italiani

La campagna non è un fatto di cronaca confinato al fronte ucraino. L’FBI include tra i bersagli funzionari governativi statunitensi e internazionali, personale militare, figure politiche e giornalisti; lo SSU estende esplicitamente il perimetro a Europa e Stati Uniti, e anche a profili personali di cittadini ucraini.

Per chiunque, in ambito istituzionale, di difesa o giornalistico europeo, usi le app di messaggistica come canale di lavoro, il modello di rischio cambia: la superficie da presidiare non è la cifratura del messaggio, ma il ciclo di vita di sessioni attive, backup e chiavi di recupero. È lo stesso terreno su cui si gioca, da anni, la sicurezza della messaggistica sicura, e che il cyber spionaggio russo ha imparato a sfruttare combinando ingegneria sociale e infrastruttura di intelligence.

Le indicazioni difensive restano elementari ma dirimenti: rivedere periodicamente le sessioni attive e disconnettere i collegamenti sconosciuti, attivare la verifica a due fattori, non scansionare QR ricevuti da utenti non noti e, soprattutto, non comunicare mai codici di conferma, PIN, password o chiavi di recupero, per quanto la richiesta appaia urgente o ufficiale. Come ricorda l’FBI, l’assistenza legittima delle app non chiede codici dentro l’applicazione e non invia link per verificare o ripristinare un account.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/intelligence-russa-chiavi-di-backup-messaggistica/




Chinese Framework Powers 200,000 Scam Sites

More than 200,000 websites are using investment scam templates built with the Chinese open source framework Uni-App, Infoblox reports.

A cross-platform development toolkit, Uni-App allows developers to create Vue.js codebases that can be deployed as mobile and desktop applications, or as mobile-optimized websites simultaneously.

Widely used in China and supported by a developer ecosystem, the framework powers thousands of legitimate products, and its maker DCloud does not appear to be involved in its fraudulent use.

However, Infoblox discovered that threat actors are selling investment scam templates, and that numerous scam websites using such templates appear linked to the same cluster of activity.

“Beyond the technical connections, we also uncovered patterns in the growth of the DCloud investment sites, along with coordinated dips in new domain registrations seen across scam websites on diverse hosts, an indication of a centralized owner facing disruption or making coordinated changes across all their DCloud investment scam sites,” the cybersecurity firm notes.

Infoblox identified over 236,000 second-level domains powering the scam infrastructure, ranging from fake crypto exchanges to fake gambling, brand impersonation, WhatsApp phishing, and multi-language pig-butchering websites.

Advertisement. Scroll to continue reading.

Among them is the infamous RainbowEx platform, a fake cryptocurrency platform that made international headlines after thousands of residents of a small Argentine town were duped into pouring money into it.

Hosted across numerous providers, the scam second-level domains have been launched since mid-2022, with an increase observed since late 2024, after the RainbowEx scandal.

“After October 2024, that figure jumped to roughly 15,000 newly observed sites per month at peak. The framework appears to have become a known platform within the scam-operator ecosystem due to the coverage it received by major news outlets,” Infoblox notes.

The largest portion of DCloud-fingerprinted sites consists of investment scam domains, run by multiple unrelated operators, “possibly dozens, even hundreds,” the cybersecurity firm says.

In addition to fake cryptocurrency exchanges and ‘deposit-and-trade’ platforms, they also include crypto wallet drainers, prediction-market and gambling impersonators, messaging platform phishing, and other phishing and credential-harvesting sites.

Lightning Shared Scooter Co. (LSSC), an operation that likely caused millions of dollars in losses in the US, was also using Uni-App. It promised investors sharp increases in passive revenue through funding a high-tech scooter-sharing company, and increased its sense of legitimacy through physical storefronts.

A similar scooter-investment operation, Yuechi Sharing Technology Ltd. (YST), currently active in Australia, New Zealand, and the United States, also has a frontend built using the Uni-App framework. YST, Infoblox says, has legitimate registration paperwork but is connected to a network of other investment-scam websites.

“For the last two years, there’s been a dramatic scaling up of scam websites using the DCloud framework, and operators of these sites continue to launch complex real-world schemes to trick victims. It’s overdue to holistically track threat actors operating in this ecosystem and attempt to identify commonalities that indicate shared ownership of the sites,” Infoblox notes.

Related: In Other News: Palo Alto Recruiter Scam, Anti-Deepfake Chip, Google Sets 2029 Quantum Deadline

Related: Google, Meta, Microsoft Among Signatories of Pact to Combat Scams

Related: Meta Launches New Protection Tools as It Helps Disrupt Scam Centers

Related: Researchers Expose Network of 150 Cloned Law Firm Websites in AI-Powered Scam Campaign

https://www.securityweek.com/chinese-framework-powers-200000-scam-sites/




STOCKSTAY, la nuova backdoor di Turla che guarda anche alla politica estera italiana

Google Threat Intelligence Group (GTIG) ha pubblicato l’analisi di STOCKSTAY, una backdoor modulare in .NET sviluppata dal gruppo russo Turla almeno dal dicembre 2022 e impiegata in operazioni dal 2023 per attività di spionaggio contro organizzazioni governative e militari in Ucraina. Il dettaglio che rende la ricerca rilevante per il pubblico italiano è esplicito nel rapporto: tra gli obiettivi figurano anche entità interessate alla politica estera italiana, con campioni di sviluppo individuati in Italia e lure in lingua italiana a tema elettorale e affari esteri.

Turla è uno degli attori di cyber espionage più longevi e meglio profilati. Opera, secondo l’analisi GTIG, sotto diverse etichette assegnate dai vendor: SUMMIT per Google, Secret Blizzard per Microsoft, Venomous Bear per CrowdStrike, UAC-0194 per il CERT-UA. La sua infrastruttura storica, l’impianto Snake, è stata attribuita da CISA al Centro 16 dell’FSB, il servizio di sicurezza federale russo. Qui non si parla quindi di ransomware né di estorsione, ma di raccolta informativa di lungo periodo al servizio di un’agenzia statale, una qualifica che cambia il profilo di rischio e il perimetro dei potenziali bersagli.

Un impianto modulare costruito per restare nascosto

STOCKSTAY non è un singolo eseguibile, ma un ecosistema di componenti che dialogano tra loro tramite messaggi WM_COPYDATA
sul canale di inter-process communication di Windows. L’orchestratore (STOCKMARKET, internamente cor
) gestisce configurazione e tasking; un tunnel di rete proxy-aware (STOCKBROKER, internamente net
) isola tutto il traffico di comando e controllo dal resto dell’attività sull’host; un terzo modulo esegue i comandi ricevuti. A monte agisce un downloader, MARKETMAKER, che scarica i componenti, stabilisce persistenza tramite chiavi di registro e si maschera da MicrosoftUpdateOneDrive
per apparire legittimo.

La comunicazione con il server avviene su WebSocket sicuro, appoggiandosi alla libreria open source websocket-sharp
. Al primo avvio l’impianto genera una coppia di chiavi RSA a 4096 bit e un identificativo univoco di infezione, cifrando i dati in uscita prima dell’invio. Il file di configurazione si traveste da applicazione legittima per il monitoraggio dei mercati delle criptovalute, con descrizioni fasulle dei campi e URL di copertura, mentre i dati reali restano cifrati nei campi decoy.

GTIG ha inoltre individuato su GitHub un controller server-side in Python (basato su tornado) che gestisce l’interfaccia /ws
, spesso ospitato su piattaforme di hosting di terze parti come Render: l’impossibilità per il gestore della piattaforma di decifrare i messaggi in transito offusca la posizione dell’infrastruttura dedicata, un’architettura che ricorda quella multi-hop di KAZUAR.

Le funzioni offerte all’operatore sono quelle classiche dell’accesso remoto: enumerazione e prelievo di file per estensione (con archiviazione ZIP in memoria e base64 per l’esfiltrazione), cattura schermo, scrittura ed eliminazione di file e directory, esecuzione di comandi multipli. Nelle fasi avanzate, dopo la ricognizione, l’impianto viene configurato con environmental keying: gira solo su uno specifico host, utente o dominio, segno che a quel punto l’attaccante sa esattamente quale macchina sta colpendo, tipicamente grazie ad accessi già stabiliti con altri strumenti del gruppo come KAZUAR.

La sovrapposizione con KAZUAR e il nodo dei nomi cluster

GTIG colloca STOCKSTAY dentro l’arsenale di Turla evidenziando sovrapposizioni di codice e funzionali con KAZUAR, il toolkit analizzato da Microsoft a maggio: introdotto in STOCKSTAY ad aprile 2025, l’obfuscator K1MORPHER è stato poi osservato dal giugno 2025 anche nei campioni di KAZUAR, e GTIG legge l’evoluzione di STOCKSTAY come una tendenza a mimare le tecniche di offuscamento multi-classe di KAZUAR.

La stessa architettura a componenti separati per comunicazione, orchestrazione ed esecuzione richiama lo schema BRIDGE, KERNEL e WORKER già documentato in KAZUAR. Su queste basi GTIG valuta con confidenza moderata che STOCKSTAY e KAZUAR possano condividere, almeno in parte, lo stesso sviluppatore o team, con STOCKSTAY costruito a immagine di KAZUAR; l’attribuzione complessiva a Turla resta invece a confidenza alta.

È un buon promemoria operativo sul fronte attribuzione: i nomi dei cluster vanno sempre incrociati tra vendor, perché la stessa famiglia compare con etichette diverse, e ricostruire la genealogia di un toolkit incide direttamente sulle conseguenze, anche giuridiche, di un’attribuzione pubblica, come discusso nell’analisi sull’attribuzione degli attacchi cyber.

Le esche raccontano molto delle priorità del gruppo: ricorrono temi accademici e diplomatici, dai nomi di istituti universitari nei file RDP malevoli alla compromissione di una piattaforma di formazione a tema diplomatico, fino al product name DiplomacyEduAI
usato all’interno dei file MSI di installazione.

Perché interessa l’Italia

L’angolo italiano va riportato con la stessa cautela usata da GTIG. Campioni di sviluppo di STOCKSTAY sono stati identificati in Italia, Paesi Bassi, Polonia e Germania, anche se per la maggior parte delle infezioni precoci non è stato possibile confermare le vittime designate. Il caso più circostanziato risale al febbraio 2024: un file Copia.msi
, caricato su VirusTotal dall’Italia e mascherato da applicazione ILSpy, installava i componenti di STOCKSTAY e abilitava la persistenza via chiavi di registro. L’esca collegata richiamava il tema delle elezioni e l’organizzazione Circolo Degli Esteri, sodalizio legato al Ministero degli Affari Esteri e nato, secondo il sito ufficiale, per rappresentarlo.

Su questo punto il rapporto è netto e va riferito senza forzature: GTIG non valuta che l’attore stesse prendendo di mira le elezioni italiane, bensì che usasse esche a tema elettorale e diplomatico per colpire individui e organizzazioni italofone con interesse per gli affari esteri. La distinzione conta, perché trasforma la notizia da allarme su una presunta interferenza elettorale in ciò che davvero documenta: l’attenzione costante di un attore statale russo verso chi, in Italia, ruota attorno alla diplomazia e alla politica estera.

Cosa cambia per i difensori

Per chi opera nella pubblica amministrazione, nella difesa o in enti e organizzazioni con un mandato sugli affari internazionali, STOCKSTAY conferma alcune costanti su cui calibrare detection e threat hunting: persistenza via registro abbinata a un downloader che si finge aggiornamento Microsoft, traffico di comando e controllo incapsulato in WebSocket cifrati e instradabili via proxy aziendale, staging su piattaforme di hosting legittime per nascondere l’infrastruttura reale.

L’impiego di environmental keying nelle fasi finali indica inoltre che, quando l’impianto compare, l’avversario è già dentro: la finestra utile per intercettarlo si gioca a monte, sulle esche a tema accademico e diplomatico e sui file RDP recapitati via phishing. Il quadro si somma alla pressione di altri attori statali, come lo spionaggio cinese parallelo documentato negli stessi giorni, e ridisegna la superficie di rischio per l’intero comparto pubblico.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/stockstay-turla-backdoor-spionaggio/




Data breach Trenitalia: esposti dati di contatto e di viaggio dei passeggeri, alto il rischio phishing

Il data breach Trenitalia, comunicato il 26 giugno, espone i dati di contatto e di viaggio di una parte dei passeggeri. La principale compagnia ferroviaria italiana ha inviato ai clienti interessati una email con oggetto “Comunicazione di violazione dei dati personali ai sensi dell’art. 34 del Regolamento UE 679/2016”, attribuendo l’accesso non autorizzato ai database dei titoli di viaggio a “soggetti esterni non identificati”; al termine delle verifiche tecniche, spiega l’azienda nella comunicazione inviata agli interessati, sono state individuate le persone potenzialmente coinvolte. L’azienda, contattata dalla stampa, ha collocato l’origine dell’incidente nell’ottobre 2025: la ricostruzione tecnica degli accessi e l’identificazione degli interessati hanno richiesto mesi prima dell’invio delle comunicazioni.

Va detto subito ciò che, secondo la stessa Trenitalia, non è stato compromesso: i dati di accesso agli account, le credenziali personali e le informazioni di pagamento come numero della carta, data di scadenza o codice di sicurezza. Non risultano, al momento, rivendicazioni note né elementi che qualifichino l’evento come ransomware: la società parla di accesso non autorizzato ai database dei titoli di viaggio.

Data breach Trenitalia: quali dati sono coinvolti

La violazione potrebbe aver interessato, qualora presenti nei sistemi associati al titolo di viaggio, diverse categorie di dati personali: dati anagrafici e identificativi (nome, cognome, data e luogo di nascita del passeggero e dell’eventuale acquirente); recapiti di contatto come indirizzo email e numero di telefono; informazioni sul viaggio, tra cui tratta, data, orario e numero del titolo; codice della carta fedeltà associata al biglietto; società o ente datore di lavoro; tipologia di offerta o servizio associata al titolo di viaggio e i dati necessari per fruirne; estremi del documento d’identità; dati tecnici connessi alla generazione del titolo di viaggio. L’ampiezza esatta della platea coinvolta non è stata quantificata ufficialmente. Si tratta, nel complesso, di informazioni che descrivono chi viaggia, come raggiungerlo e quando: un profilo prezioso per chi voglia confezionare comunicazioni fraudolente credibili.

Notifica a Garante e CSIRT, denuncia alla Procura

Trenitalia dichiara di aver adottato immediatamente le misure per contenere l’incidente, interrompendo l’intrusione e rafforzando i controlli sui sistemi. L’accaduto è stato notificato al Garante per la protezione dei dati personali e al CSIRT Italia, e una denuncia è stata presentata alla Procura della Repubblica presso il Tribunale di Roma per avviare le indagini. La società richiama l’articolo 34 del GDPR e le Linee guida EDPB n. 9/2022 (versione 2.0 del 28 marzo 2023) sulla notifica delle violazioni di dati personali, spiegando che la ricostruzione degli accessi e l’identificazione dei clienti hanno richiesto tempo: un passaggio che illustra bene le tempistiche e le valutazioni di rischio dietro la notifica al Garante e la comunicazione agli interessati.

Il rischio vero: phishing su misura

Proprio perché non sono in gioco password o dati di pagamento, il pericolo più concreto si sposta sull’inganno. Recapiti e dettagli di viaggio sono il materiale ideale per costruire messaggi credibili: la stessa Trenitalia avverte i clienti della possibilità di ricevere email, SMS o telefonate che facciano riferimento a viaggi reali, invitando a non fornire dati personali o finanziari e a verificare sempre il mittente. È la logica dello spear phishing, la truffa personalizzata che usa informazioni autentiche della vittima per abbassarne la guardia. La società ricorda che non contatterà mai i clienti per chiedere password o dati di pagamento e ha attivato un servizio dedicato tramite il webform “Privacy – Gestione dei dati personali”.

Per chi si occupa di sicurezza, il caso conferma che una violazione senza dati finanziari non è una violazione minore: l’esposizione di contatti e abitudini di viaggio alimenta campagne di frode mirata che possono colpire a distanza di settimane. Trenitalia rientra inoltre tra i soggetti essenziali per il Paese ai sensi della direttiva NIS2, e un episodio simile mostra quanto la superficie d’attacco di queste realtà comprenda ormai l’intera base clienti, non solo i sistemi operativi del trasporto. La difesa, lato utente, resta la verifica del canale e del mittente prima di cliccare; lato organizzazioni, il monitoraggio delle ondate di phishing che sfruttano il marchio Trenitalia nei prossimi giorni.

Un contesto più ampio: la notifica parallela di Trenitalia Tper

L’episodio si inserisce in una sequenza che ha interessato l’ecosistema informatico del gruppo Ferrovie dello Stato. Nello stesso arco temporale dell’origine dichiarata dall’azienda, tra fine novembre e dicembre 2025 era emerso un attacco ad Almaviva, fornitore IT del gruppo FS, con l’esfiltrazione di circa 2,3 terabyte di dati poi comparsi su un forum della rete Tor e riconducibili a numerose società del gruppo, Trenitalia inclusa.

Va tenuta distinta una seconda notifica, formalmente autonoma. Trenitalia Tper S.c.a.r.l., società che gestisce il servizio regionale in Emilia-Romagna, ha inviato nelle settimane precedenti una propria comunicazione ai sensi dell’art. 34 GDPR a clienti e dipendenti, con lo stesso impianto: accesso non autorizzato da parte di soggetti esterni non identificati, esclusione di credenziali e dati di pagamento, avviso sul rischio di phishing mirato. La comunicazione Tper differisce però da quella nazionale su punti verificabili: notifica al solo Garante con generico rimando alle Autorità competenti, assistenza tramite numero telefonico dedicato anziché webform, nessun richiamo alle Linee guida EDPB, invio via SMS anziché email. Si tratta quindi di due soggetti giuridici distinti e di due comunicazioni separate. Allo stato, le aziende non hanno dichiarato un nesso ufficiale tra le notifiche e l’attacco ad Almaviva: la coincidenza temporale è documentata, mentre l’attribuzione a un’unica matrice resta una ricostruzione non confermata.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/data-breach-trenitalia-passeggeri-phishing/




Microsoft and Allies Smash Shared Infrastructure of Amadey and StealC Malware

Microsoft, law enforcement, and several cybersecurity companies have collaborated to take down infrastructure shared by two widely used malware families: Amadey and StealC.

The action, part of the long-running Operation Endgame, involved the use of AI, legal action, and the exploitation of a vulnerability in a malware control panel, and resulted in hundreds of domains and servers being targeted for takedown. 

While many cybercrime operations have been disrupted in recent years as part of Operation Endgame, this one stands out because law enforcement and companies targeted what they described as the “cybercrime assembly line”. 

Making the rounds since 2018, Amadey is a malware-as-a-service loader that gives threat actors access to systems, enabling them to deliver secondary payloads. StealC is an infostealer that has been around since 2023, helping cybercriminals obtain credentials, cryptocurrency wallets, cookies, and other valuable data.

Amadey and StealC have often been used together — the former has enabled hackers to gain access to systems, while the latter has been used to steal information from the breached systems.

AI-powered analysis of the two malware families revealed that they use the same command-and-control (C&C) infrastructure, making it easier for Microsoft and its partners to conduct takedown activities.

Advertisement. Scroll to continue reading.

“This operation marked a shift in strategy: instead of focusing solely on individual threats, Europol, law enforcement and judicial authorities, as well as private industry partners disrupted the entire chain that allows cyberattacks to scale,” said Europol.

More than 25 million unique credentials stolen from over 385,000 systems were seized, and 18,000 compromised computers were identified and secured. Europol said crypto assets valued at more than $47 million were identified and flagged to restrict their use.

Researchers also discovered a vulnerability in the StealC C&C panel that enabled uploading a web shell to the server. While this flaw was exploited to collect data in support of the takedown operation, there is evidence that a StealC affiliate also used it to steal other affiliates’ data.

Microsoft, Europol, ESET, Bitsight, IBM X-Force, Proofpoint, and Japan’s Mitsui Bussan Secure Directions (MBSD) have published blog posts describing the action taken against Amadey and StealC.

The announcement comes shortly after law enforcement and cybersecurity companies worked together to take down the SocGholish botnet. 

Related: Russian Initial Access Broker Behind FortiBleed Campaign

Related: New ‘Mistic’ RAT Opens Door to Several Ransomware Families

Related: CryptoBandits Malware Doubles as a Backdoor, Abuses Tor

https://www.securityweek.com/microsoft-and-allies-smash-shared-infrastructure-of-amadey-and-stealc-malware/




Third DraftKings Hacker Sentenced to 18 Months in Prison

A third man charged for his role in a 2022 hacking attack on the sports and betting website DraftKings has been sentenced to prison, the Justice Department announced on Tuesday.

The DOJ has not named the targeted site, describing it as a fantasy sports and betting website, but its description of the attack matches the 2022 credential-stuffing attack targeting DraftKings. In that attack, hackers accessed more than 60,000 accounts using usernames and passwords obtained from other breaches.

Once they gained access to a DraftKings account, the cybercriminals either withdrew the available funds or sold access to the account on online marketplaces.

The third suspect charged in this case is Nathan Austad, aka Snoopy, who pleaded guilty in December 2025. He has now been sentenced to 18 months in prison and three years of supervised release. He has also been ordered to pay roughly $1.8 million in restitution and forfeiture. 

According to the DOJ, Austad and his accomplices stole approximately $600,000 from 1,600 DraftKings accounts. 

Austad also set up a website to sell compromised accounts, and investigators identified his cryptocurrency accounts, which had roughly $465,000, including funds from his criminal activities. 

Advertisement. Scroll to continue reading.

The other individuals charged for the DraftKings attack are Kamerin Stokes, sentenced to 30 months in prison in April 2026, and Joseph Garrison, sentenced to 18 months in prison in early 2024.

Authorities made public some of the messages exchanged by the three men, indicating they clearly knew they were committing a crime.

“The defendants acknowledged the federal investigation into their conduct while they were committing their crimes, even having the hubris to say the FBI could not do anything about it.  They were wrong,” said Jay Clayton, US Attorney for the Southern District of New York. “Austad’s prison sentence today demonstrates the commitment of the DOJ, the FBI, and all our federal partners to protecting our on-line markets.”

Related: Algerian Man Extradited to US for Running Cybercrime Marketplaces

Related: Russian Initial Access Broker Behind FortiBleed Campaign

Related: Ukrainian Man Pleads Guilty in US to Conti Ransomware Charges

https://www.securityweek.com/third-draftkings-hacker-sentenced-to-18-months-in-prison/




New ‘Mistic’ RAT Opens Door to Several Ransomware Families

An initial access broker (IAB) linked to multiple ransomware families has been using a new remote access trojan (RAT) in recent attacks, Broadcom’s Symantec and Carbon Black threat hunter team reports.

The threat actor, tracked as Woodgnat and KongTuke, and active since at least May 2024, is known to have ties to ransomware groups such as Qilin, Interlock, Rhysida, Akira, 8Base, and Black Basta.

Starting in April 2026, Woodgnat has been deploying the new Backdoor.Mistic RAT against the networks of organizations across multiple industries, including education, insurance, IT, and professional services.

Previously, the threat actor was observed deploying the ModeloRAT in attacks targeting other entities.

“The targeting appears to be opportunistic, with the attackers casting a wide net and then assessing which organizations they could sell access to rather than focusing on a single sector,” Broadcom’s researchers say.

Also tracked as MLTBackdoor, Mistic provides attackers with typical capabilities, including file download and upload, file manipulation, folder creation, and code execution. The attackers can also modify the frequency at which the malware checks for new commands and can instruct it to terminate itself.

Advertisement. Scroll to continue reading.

Woodgnat has been deploying the backdoor as a DLL, executing it via sideloading. In a recent attack, the threat actor also deployed a credential stealer alongside Mistic.

Additional tools observed in the intrusion include Curl, Reg.exe, Net (net.exe), PowerShell, Certutil, and WMIC (Windows Management Instrumentation), for data exfiltration, registry manipulation, network resource management, command execution, reconnaissance, lateral movement, file download, and browser certificate installation.

The IAB is known for distributing malware via compromised WordPress sites and for relying on social engineering to entice users into executing attacker-supplied commands, including the ClickFix, FileFix, and CrashFix techniques.

“In each case the victim is ultimately tricked into running an attacker-supplied PowerShell command. While the initial compromise may be opportunistic, the attackers profile the machines for potential interest to determine their value and if they can sell access to them,” Broadcom’s threat hunter team says.

Since April 2026, the threat actor has also been using helpdesk and IT-support lures delivered via Microsoft Teams to convince victims into executing malicious code.

Related: Russian Initial Access Broker Behind FortiBleed Campaign

Related: Hackers Exploiting Cisco Unified CM Vulnerability

Related: Microsoft Teams Relay Servers Abused in DragonForce Ransomware Attack

Related: Over 1.4 Million Accounts Disrupted in Cybercrime Crackdown

https://www.securityweek.com/new-mistic-rat-opens-door-to-several-ransomware-families/




What the Latest ShinyHunters Breaches Reveal About Modern Cyberattacks

The latest wave of breaches attributed to the ShinyHunters cybercrime collective (e.g., University of Nottingham, DentaQuest, 7-Eleven, Medtronic, and Wynn Resorts), reinforces a hard truth security leaders can no longer ignore: attackers are increasingly bypassing traditional perimeter defenses and targeting identities, authentication workflows, SaaS integrations, and trusted access paths instead of exploiting software vulnerabilities directly.

Over the past several months, ShinyHunters has been linked to attacks involving Salesforce environments, Snowflake customers, SaaS integrations, and identity platforms such as Okta. Researchers and incident responders have consistently observed the same pattern: stolen credentials, compromised OAuth tokens, social engineering, vishing, and abuse of legitimate access privileges.

This is not merely another breach trend. It is evidence that identity has become the primary battleground in enterprise security.

The Evolution of the ShinyHunters Playbook

Historically, attackers focused on exploiting unpatched systems or deploying malware to gain persistence. Today’s identity-centric threat actors operate differently. Instead of “breaking in,” they log in.

Recent investigations into ShinyHunters-related campaigns reveal repeated use of:

Advertisement. Scroll to continue reading.
  • Infostealer-harvested credentials
  • Multi-factor authentication (MFA) fatigue and vishing attacks
  • Compromised SaaS integrations
  • OAuth token abuse
  • Excessive permissions in cloud applications
  • Misconfigured identity and guest-access settings
  • Third-party trust exploitation
  • Help desk impersonation

In the Salesforce Experience Cloud campaign disclosed earlier this year, attackers reportedly exploited overly permissive guest-user configurations to extract CRM data from public-facing portals. Salesforce emphasized that the issue stemmed from identity and access misconfigurations rather than a platform vulnerability.

Similarly, the Snowflake-related attacks associated with ShinyHunters leveraged stolen credentials and third-party integrations rather than weaknesses in Snowflake’s infrastructure itself. Investigators noted that many affected organizations lacked strong MFA enforcement and visibility into abnormal authentication behavior.

The same pattern has appeared across attacks targeting SaaS ecosystems, analytics providers, and cloud-connected applications. Once attackers obtain a valid identity or session token, they can often move laterally and access sensitive data without triggering traditional security controls.

Why Traditional Security Controls Are Failing

These attacks expose a growing gap in many enterprise security architectures.

Traditional tools such as firewalls, endpoint protection, and signature-based detection were designed to identify malicious code or anomalous network activity. But identity-based attacks frequently appear legitimate because attackers use valid credentials, approved APIs, and authorized applications.

To many security systems, a compromised employee account accessing Salesforce from a browser session looks indistinguishable from normal business activity.

That is exactly why identity has become the preferred attack vector.

Modern enterprises now operate in highly distributed environments spanning cloud platforms, SaaS applications, contractors, partners, and remote workforces. Every identity — human or machine — can serve as a gateway for attackers.

Attackers understand this reality better than most organizations do.

Identity Threat Detection Changes the Equation

The shift toward identity-driven attacks requires a corresponding shift in defense strategy.

Identity threat detection and risk mitigation has emerged as a critical capability for organizations seeking to detect and stop attacks that bypass conventional defenses. Unlike point-in-time identity verification, identity threat detection analyzes the full pattern of interactions associated with a credential, as well as activity across other identities and credentials within the environment, to identify indicators of compromise and malicious behavior. Rather than focusing solely on endpoints or network traffic, identity threat detection continuously monitors identity systems, authentication activity, privilege escalation, and access behavior across hybrid environments to detect and mitigate identity-based threats.

This approach enables organizations to identify suspicious activity such as:

  • Impossible travel or anomalous login behavior
  • MFA manipulation attempts
  • Bot-based attacks
  • Deepfake attacks
  • SIM swap
  • OAuth token abuse
  • Privilege escalation
  • Dormant or orphaned accounts being activated
  • Lateral movement across access channels
  • Suspicious authentication patterns tied to social engineering

More importantly, identity threat detection provides context.

Security teams need to understand not only who authenticated, but whether the behavior aligns with expected patterns, what resources were accessed, whether the identity was recently elevated, and whether downstream SaaS applications or integrations create additional risk exposure.

In the case of the ShinyHunters campaigns, many attacks likely could have been disrupted earlier through better detection of identity anomalies, token misuse, or unusual privilege behavior before large-scale data exfiltration occurred.

The Rise of Trust Exploitation

One of the most concerning aspects of recent ShinyHunters operations is the abuse of trusted relationships.

Threat actors increasingly target vendors, integrations, support workflows, and identity providers because compromise at one point can cascade across multiple organizations. Researchers analyzing recent campaigns observed attackers leveraging third-party SaaS providers and integration platforms to gain access into downstream customer environments. This creates a dangerous multiplier effect.

A single compromised identity, contractor account, or OAuth integration can provide attackers with legitimate access to hundreds of connected systems. Traditional network segmentation offers limited protection in these scenarios because trust relationships themselves become the attack path.

Organizations therefore need visibility not only into employee identities, but also into non-human identities, API connections, service accounts, and federated access relationships across their ecosystems.

Security Leaders Must Rethink Identity Protection

The lesson from the latest ShinyHunters breaches is not simply that attackers are becoming more sophisticated. It is that enterprise security strategies must evolve beyond the assumption that authenticated users are inherently trustworthy.

Identity can no longer be treated solely as an access management function. It must become a core security discipline.

That means organizations should prioritize:

  • Continuous identity monitoring
  • Risk-based authentication
  • Strong phishing-resistant MFA
  • Least-privilege access enforcement
  • OAuth and token governance
  • Detection of abnormal identity behavior

Conclusion

The modern attack chain increasingly begins and ends with identity.

Groups like ShinyHunters are demonstrating that attackers do not necessarily need malware or zero-day exploits to cause massive damage. In many cases, all they need is a trusted login, an overlooked permission, or a compromised token.

The organizations that recognize this shift — and invest accordingly in identity threat detection and response — will be far better positioned to stop the next generation of attacks before they become the next headline.

Related: Kodak Admits Data Breach After ShinyHunters Hack Claims

Related: ShinyHunters Claims Council of Europe Hack

Related: University of Nottingham Confirms Breach After Hackers Leak Data

Related: Hackers Leak DentaQuest Information Impacting 2.6 Million

https://www.securityweek.com/what-the-latest-shinyhunters-breaches-reveal-about-modern-cyberattacks/




Miasma: worm nei pacchetti npm di Red Hat, sviluppatori nel mirino

Per secoli si è creduto che le pestilenze viaggiassero nell’aria: un miasma, un alito corrotto che si insinuava nei polmoni senza volto né origine, e contaminava prima ancora di farsi vedere. Un’idea sbagliata sulla medicina, ma un’intuizione perfetta sul contagio.

Chi ha battezzato l’ultima variante del worm Shai-Hulud lo sapeva: i repository che il malware genera per trafugare i dati recano una sola, eloquente descrizione, “Miasma: The Spreading Blight“. Il flagello dilagante. Non un nome scelto a caso, ma un manifesto. Perché è esattamente così che agisce: una corruzione che si respira con la filiera del software, si diffonde a ogni installazione come un fiato malato e si porta via credenziali, ambienti di build e strumenti di sviluppo prima che lo sviluppatore si accorga del contagio.

Attacco supply chain npm, Red Hat conferma l’accaduto

Un nuovo attacco supply chain npm ha colpito i pacchetti pubblicati sotto il namespace ufficiale @redhat-cloud-services
: il 1° giugno 2026 i ricercatori di Wiz Research hanno identificato almeno 32 pacchetti compromessi con una variante del worm Shai-Hulud ribattezzata Miasma, dal nome dei repository di esfiltrazione creati dal malware con la descrizione “Miasma: The Spreading Blight”. I pacchetti coinvolti totalizzano circa 80.000 download settimanali secondo la stima di Wiz, circa 117.000 secondo i conteggi di Aikido ripresi dalla stampa di settore (le stime divergono per metodologia); le versioni compromesse accertate a fine ricognizione sono 96.

Red Hat ha confermato l’accaduto a The Register per bocca di un portavoce: i pacchetti malevoli sono stati rimossi dal registro npm e, secondo l’azienda, erano «strettamente limitati allo sviluppo interno»; al momento «non è stato identificato alcun impatto su ambienti di clienti o partner né sui sistemi di produzione Red Hat». L’indagine è però ancora in corso e Wiz classifica la campagna come minaccia attiva: il quadro va quindi considerato in evoluzione.

Come è avvenuta la compromissione

Il punto di ingresso accertato è l’account GitHub di un dipendente Red Hat. Secondo la ricostruzione di Wiz, l’account compromesso ha inviato commit orfani a tre repository dell’organizzazione RedHatInsights (frontend-components, javascript-clients e platform-frontend-ai-toolkit), aggirando la code review, in due ondate distinte nella stessa giornata.

I commit contenevano un workflow GitHub Actions minimale che si attivava su qualsiasi push: richiedeva un token OIDC con permesso id-token: write
, eseguiva un payload offuscato e pubblicava su npm le versioni avvelenate dei pacchetti, complete di attestazioni di provenienza SLSA formalmente valide. È un dettaglio rilevante: la firma di provenienza, nata proprio per dare garanzie sull’integrità della filiera, è stata prodotta dal flusso di build legittimo e non ha quindi offerto alcuna protezione.

Le versioni compromesse contenevano uno script preinstall che eseguiva automaticamente un file JavaScript pesantemente offuscato al momento dell’installazione del pacchetto, prima ancora che lo sviluppatore ne importasse il codice.

Cosa ruba Miasma e cosa cambia rispetto a Shai-Hulud

Il payload è derivato dal codice di Mini Shai-Hulud, il worm per npm che il gruppo criminale TeamPCP ha reso pubblico nelle settimane scorse. Le analisi convergenti di Wiz, Socket e altri vendor descrivono un ladro di credenziali ad ampio spettro: secret di GitHub Actions, token npm, credenziali cloud, materiale Kubernetes e Vault, chiavi SSH, credenziali Git e altri file sensibili presenti sulla macchina infetta.

I dati raccolti vengono compressi, cifrati ed esfiltrati su un doppio canale: quello primario è una POST HTTPS verso un endpoint mascherato da chiamata all’API di Anthropic (api.anthropic[.]com:443/v1/api, un percorso che non corrisponde all’API reale), un travestimento studiato per confondersi con il normale traffico verso i fornitori AI; in caso di fallimento il malware ripiega sulla Contents API di GitHub, committando i risultati cifrati in repository marcati con la descrizione “Miasma: The Spreading Blight”.

È qui che Miasma si comporta da worm in senso proprio: secondo l’analisi di StepSecurity, i token npm rubati vengono riusati per ripubblicare in autonomia versioni backdoor dei pacchetti a cui l’account vittima ha accesso, sfruttando il parametro bypass_2fa di npm per scavalcare anche l’autenticazione a due fattori. Ogni macchina infetta può così seminare da sola l’ondata successiva, senza ulteriore intervento dell’attaccante.

Due le novità principali rispetto alle ondate precedenti. La prima è l’aggiunta di collector dedicati alle identità cloud di Google Cloud e Microsoft Azure: non più solo furto di secret, ma censimento di tutte le identità a cui la macchina infetta ha accesso, segnale di un interesse crescente per l’accesso diretto agli ambienti cloud. La seconda è la generazione di un payload cifrato unico per ogni infezione, che rende gli indicatori di compromissione basati su hash validi solo per la singola versione di pacchetto e complica il lavoro di rilevamento.

Il malware mostra inoltre una notevole attenzione all’ambiente in cui gira: verifica la presenza di soluzioni di endpoint protection prima di agire, evita l’esecuzione sui sistemi configurati in lingua russa e stabilisce persistenza negli strumenti di sviluppo, iniettando un hook di sessione nella configurazione di Claude Code e un task con avvio automatico all’apertura della cartella nei progetti Visual Studio Code.

Attribuzione incerta

Le tattiche osservate coincidono con quelle di TeamPCP, il gruppo dietro le campagne Shai-Hulud. Proprio perché TeamPCP ha reso open source i propri strumenti, però, tutti i ricercatori coinvolti invitano alla prudenza: la sovrapposizione di tecniche non basta per un’attribuzione definitiva e non si può escludere un imitatore che riutilizza il codice pubblico. Secondo OX Security, citata da The Hacker News, la prima traccia della stringa “Miasma” risale al 29 maggio, indizio di una fase di test precedente all’attacco.

Cosa fare subito

Le organizzazioni che hanno installato una delle versioni compromesse devono assumere la compromissione: isolare gli host coinvolti, rimuovere le versioni malevole e ruotare tutte le credenziali potenzialmente esposte, inclusi token GitHub e npm, chiavi SSH e credenziali cloud. Socket sottolinea che disinstallare il pacchetto o cancellare la cartella node_modules non è una bonifica sufficiente, vista la persistenza negli strumenti di sviluppo: vanno verificati anche i file di configurazione di Claude Code, VS Code e i workflow GitHub. Per le pipeline CI/CD è raccomandata la sospensione delle esecuzioni interessate e l’invalidazione degli artefatti di build prodotti nella finestra di esposizione.

L’episodio si inserisce in un’ondata di attacchi alla supply chain software che negli ultimi due mesi ha toccato progetti come TanStack, Nx Console e migliaia di repository GitHub con la campagna Megalodon, al punto da spingere la statunitense CISA a pubblicare un alert dedicato il 28 maggio. La lezione per chi sviluppa software è ormai consolidata, anche alla luce degli obblighi in arrivo con il Cyber Resilience Act: dependency pinning, allowlist delle dipendenze, generazione di SBOM e monitoraggio degli ambienti di build non sono più buone pratiche opzionali, ma il perimetro minimo di difesa di una catena di fornitura sotto attacco costante.

Fonti

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/attacco-supply-chain-miasma/