<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with databreach]]></title><description><![CDATA[A list of topics that have been tagged with databreach]]></description><link>https://forum.androidiani.net/tags/databreach</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 17:05:53 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/databreach.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 13 May 2026 16:06:32 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Nitrogen ransomware colpisce Foxconn: 8TB di dati con segreti industriali di Apple, Nvidia e Intel]]></title><description><![CDATA[Si parla di:ToggleIl 12 maggio 2026 Foxconn ha confermato un cyberattacco ai danni delle sue fabbriche nordamericane, rivendicato dal gruppo ransomware Nitrogen. Gli aggressori affermano di aver sottratto 8 TB di dati — oltre 11 milioni di file — contenenti documentazione riservata, schemi tecnici e istruzioni di assemblaggio relative a progetti di Apple, Intel, Google, Nvidia e Dell. L’attacco ha bloccato la produzione per giorni in uno dei nodi più critici della supply chain tecnologica globale.La timeline dell’attaccoSecondo le ricostruzioni, il 1° maggio 2026 i lavoratori del turno di notte dello stabilimento Foxconn di Mount Pleasant, Wisconsin, hanno interrotto la produzione a causa di un’interruzione di rete. Al mattino, i lavoratori del primo turno sono arrivati senza Wi-Fi e sono stati rimandati a casa entro le 11. La produzione è rimasta ferma fino al 4 maggio. Undici giorni dopo, il 11 maggio, il gruppo Nitrogen ha aggiunto Foxconn al proprio data leak site sul dark web, rivendicando il furto di 8 TB di dati e pubblicando campioni come prova.Foxconn ha confermato l’incidente con una dichiarazione sobria: “Alcune fabbriche di Foxconn in Nord America hanno subito un cyberattacco. Il team di cybersecurity ha immediatamente attivato il meccanismo di risposta e implementato misure operative multiple per garantire la continuità di produzione e consegna. Le fabbriche interessate stanno riprendendo la normale produzione.” L’azienda si è rifiutata di confermare quali dati clienti fossero stati effettivamente esfiltrati.Chi è Nitrogen: genealogia di un gruppo ransomwareNitrogen è attivo dal 2023 ed è considerato uno dei numerosi discendenti del codice trapelato del builder Conti 2. Il gruppo è operativamente collegato a threat actor dell’Europa dell’Est e alcuni suoi operatori sarebbero associati al cartello BlackHat/ALPHV. Una caratteristica critica emersa a febbraio 2026 rende il gruppo particolarmente pericoloso per le sue stesse vittime: un bug di programmazione nel modulo di cifratura per VMware ESXi rende il decryptor incapace di recuperare i file cifrati. Secondo i ricercatori di Coveware, pagare il riscatto — in questo specifico scenario — è inutile, poiché nemmeno gli stessi operatori di Nitrogen riescono a decifrare i file. Foxconn avrà quasi certamente verificato questa criticità prima di prendere qualsiasi decisione sui negoziati.Il bottino: schemi tecnici di Apple, Nvidia, Intel, Google e DellI campioni pubblicati da Nitrogen sul data leak site comprendono, secondo le ricostruzioni di più fonti, istruzioni di assemblaggio, diagrammi di data center e schemi hardware relativi a progetti di Apple, Intel, Google, Nvidia e Dell. La natura della documentazione è coerente con l’operatività dello stabilimento di Mount Pleasant, che Foxconn gestisce come Fii USA (Foxconn Industrial Internet) e che produce principalmente server, workstation e componenti per data center — non dispositivi consumer Apple, il che spiega perché Apple abbia dichiarato di non essere direttamente a rischio per quanto riguarda i propri prodotti al consumo.La vera preoccupazione non è nella divulgazione di schemi per smartphone già in commercio, ma nella potenziale esposizione di roadmap future, specifiche ingegneristiche riservate di infrastrutture cloud e configurazioni di data center enterprise. Per aziende come Nvidia, i cui chip AI sono al centro di una corsa tecnologica globale con implicazioni geopolitiche, la divulgazione di topologie di sistemi e specifiche tecniche costituisce un rischio di intelligence industriale non trascurabile.Foxconn nel mirino: una vittima serialeNon si tratta del primo incidente ransomware per il colosso taiwanese. Nel 2022 un gruppo criminale aveva colpito una filiale messicana di Foxconn. Nel 2024 LockBit aveva attaccato Foxsemicon Integrated Technology, società del gruppo nel settore equipment per semiconduttori. La recidività di questi attacchi suggerisce che la superficie di attacco di Foxconn — distribuita tra decine di stabilimenti, migliaia di sistemi IT e una rete supply chain planetaria — sia strutturalmente difficile da proteggere nella sua totalità.Implicazioni per la supply chain tecnologicaL’attacco a Foxconn rappresenta un caso emblematico di come le grandi aziende di contract manufacturing costituiscano un vettore di rischio sistemico per l’intera industria tecnologica. Un singolo incidente a un fornitore terzo può esporre simultaneamente la proprietà intellettuale di decine di brand globali — anche quando questi brand mantengono standard di sicurezza interni elevatissimi. La documentazione tecnica che fluisce verso i produttori include spesso specifiche pre-commerciali, che diventano bersagli appetibili per attori mossi da interessi sia economici (concorrenza sleale, contraffazione) che geopolitici (intelligence industriale statale).Vale la pena notare che Nitrogen stessa ha un track record di affidabilità tecnica discutibile: la presenza del bug nel decryptor ESXi lascia aperta la domanda su quanto effettivamente il gruppo sia in grado di “consegnare” quanto promesso in sede di negoziazione. Per Foxconn, questo potrebbe significare che, nel caso in cui parte dei sistemi produttivi fosse stata cifrata con la variante ESXi, i dati potrebbero essere irrecuperabili indipendentemente da qualsiasi trattativa.Due righe per i difensori: lezioni dall’incidente FoxconnSegmentazione di rete per gli ambienti OT/IT: negli stabilimenti manifatturieri, la convergenza tra reti IT e sistemi operativi (OT/ICS) amplifica l’impatto di un’intrusione. Una corretta segmentazione può contenere il blast radius e prevenire interruzioni produttive.Hardening degli hypervisor VMware ESXi: Nitrogen e molti altri gruppi ransomware prendono specificamente di mira ESXi. L’applicazione tempestiva delle patch, la disabilitazione di servizi non necessari (SLP, OpenSLP) e il monitoraggio delle API di hypervisor sono controlli prioritari.Protezione della documentazione tecnica con DRM o controlli di accesso granulari: schemi, BOM e specifiche ingegneristiche riservate dovrebbero essere soggetti a policy di accesso basate sul principio del minimo privilegio e tracciabilità degli accessi.Verifica dei fornitori critici: le aziende che condividono IP con contract manufacturer dovrebbero condurre audit periodici della postura di sicurezza dei propri fornitori e includere clausole di notifica di incidenti nei contratti.Valutare la recuperabilità prima del pagamento: in caso di attacco Nitrogen su ambienti ESXi, ricercatori indipendenti hanno confermato che il pagamento non garantisce il recupero. Prioritizzare i backup offline e testare regolarmente i piani di disaster recovery.Fonti: The Register (12 maggio 2026); CyberNews; The CyberSec Guru]]></description><link>https://forum.androidiani.net/topic/d15fc502-2b8a-4e37-87c0-5f08894d96f6/nitrogen-ransomware-colpisce-foxconn-8tb-di-dati-con-segreti-industriali-di-apple-nvidia-e-intel</link><guid isPermaLink="true">https://forum.androidiani.net/topic/d15fc502-2b8a-4e37-87c0-5f08894d96f6/nitrogen-ransomware-colpisce-foxconn-8tb-di-dati-con-segreti-industriali-di-apple-nvidia-e-intel</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Wed, 13 May 2026 16:06:32 GMT</pubDate></item><item><title><![CDATA[ShinyHunters viola Canvas: 275 milioni di studenti nel mirino nel più grande data breach educativo della storia]]></title><description><![CDATA[Si parla di:ToggleIl gruppo di estorsione digitale ShinyHunters ha violato Instructure, la società madre della piattaforma di e-learning Canvas, sottraendo 3,65 terabyte di dati relativi a circa 275 milioni di studenti e insegnanti distribuiti in 8.809 istituzioni scolastiche in tutto il mondo. L’attacco, rivendicato il 3 maggio 2026 e tuttora in evoluzione con un ultimatum di riscatto fissato al 12 maggio, è già classificato come il più grande data breach della storia nel settore dell’istruzione — con implicazioni che vanno ben oltre la semplice esfiltrazione di dati anagrafici.La timeline dell’attaccoLa prima anomalia rilevata è datata 29 aprile 2026, quando alcuni strumenti di Canvas iniziarono a mostrare malfunzionamenti. Il giorno successivo, Instructure confermò internamente una violazione criminale in corso e ingaggiò esperti forensi esterni. Il 3 maggio, ShinyHunters rivendicò pubblicamente l’attacco su forum underground, pubblicando campioni dei dati come prova. Il 7 maggio — in un’escalation particolarmente aggressiva — il gruppo defacciò le pagine di login di numerose istituzioni scolastiche clienti di Canvas, sostituendole con un messaggio di estorsione visibile a milioni di studenti nel pieno del periodo degli esami di fine anno accademico.La scelta del momento non è casuale: colpire a maggio, durante le sessioni d’esame universitarie negli USA, nel Regno Unito e in Australia, massimizza la pressione mediatica e istituzionale, aumentando la probabilità che la vittima ceda alle richieste di riscatto.Il vettore d’attacco: account Free-For-Teacher e abuso OAuthSecondo le prime ricostruzioni rese note da Instructure, il punto d’ingresso iniziale è stato un’vulnerabilità legata agli account Free-For-Teacher, un tipo di account gratuito offerto da Canvas agli insegnanti per uso personale o sperimentale, con autorizzazioni API più ampie rispetto agli account studente standard. ShinyHunters, noto per la sua expertise nell’abuso di piattaforme cloud enterprise attraverso tecniche di vishing, furto di credenziali e abuso OAuth, ha sfruttato questo vettore per ottenere token di accesso con privilegi elevati all’infrastruttura di Instructure.Il modus operandi del gruppo in operazioni precedenti — tra cui le violazioni di Snowflake (2024) e Salesforce — segue uno schema consolidato: compromissione di account cloud di terze parti con accesso API, escalation dei privilegi tramite token OAuth mal configurati o rubati, esfiltrazione massiva di dati in formato strutturato (database dump, CSV), e infine doppia estorsione con pubblicazione progressiva di campioni come leva negoziale.La scala senza precedenti: chi è stato colpitoCon 8.809 istituzioni coinvolte in almeno otto Paesi — Stati Uniti, Canada, Regno Unito, Nuova Zelanda, Australia, Svezia, Paesi Bassi e Singapore — il breach Canvas supera qualsiasi precedente nella storia delle violazioni del settore education. Tra le istituzioni nominalmente esposte figurano MIT, Oxford, Duke University, University of Pennsylvania e centinaia di altre università di primo piano a livello globale.I dati sottratti confermati includono: nomi e cognomi, indirizzi email istituzionali, numeri di matricola, iscrizioni ai corsi e — particolarmente sensibile — messaggi privati scambiati tra studenti e docenti. Instructure ha dichiarato che non risultano compromesse password, date di nascita, documenti d’identità governativi o informazioni finanziarie, ma l’entità dell’esfiltrazione — 3,65 TB — suggerisce che il quadro completo dei dati sottratti non sia ancora del tutto chiaro.ShinyHunters: il profilo del gruppoShinyHunters è un gruppo di estorsione digitale attivo almeno dal 2020, noto per operazioni ad alto impatto contro piattaforme cloud. Nel curriculum del gruppo figurano violazioni di Tokopedia (91 milioni di record), Wattpad, Mathway, Pluto TV, e la già citata campagna Snowflake del 2024 che colpì centinaia di aziende Fortune 500 tramite furto di credenziali di clienti cloud. Il gruppo non dispone di una struttura ransomware con cifratura dei file: la loro arma primaria è la minaccia di pubblicazione dei dati, amplificata da azioni di defacement visibili (come le pagine login di Canvas sostituite) che generano massima pressione mediatica.La deadline del 12 maggio 2026 per il pagamento del riscatto è in scadenza nei prossimi giorni. Non è noto l’importo richiesto. Instructure non ha confermato né smentito trattative in corso.Cosa devono fare istituzioni e utentiLe istituzioni che utilizzano Canvas devono agire immediatamente su più fronti: rotazione di tutte le API key Canvas, revoca e re-emissione di tutti i token OAuth attivi, verifica delle integrazioni SSO con provider di identità istituzionali, e audit degli account Free-For-Teacher attivi nella propria istanza. Per gli utenti finali, il rischio principale nelle settimane successive sarà quello di campagne di phishing personalizzate, che sfrutteranno i dati esfiltrati (email istituzionali, nomi dei corsi, messaggi privati) per costruire lure altamente credibili. La ricezione di email apparentemente provenienti da docenti, segreterie o piattaforme universitarie deve essere trattata con massima cautela per almeno i prossimi 90 giorni.## Indicatori e dati chiave del breach Canvas/ShinyHunters
Data prima anomalia: 29 aprile 2026
Data rivendicazione: 3 maggio 2026
Data defacement login pages: 7 maggio 2026
Deadline riscatto: 12 maggio 2026
Volume dati sottratti: ~3,65 TB
Record compromessi (claim ShinyHunters): ~275 milioni
Istituzioni coinvolte: 8.809 (in 8+ Paesi)
Vettore iniziale: account Free-For-Teacher + abuso OAuth API
Dati confermati compromessi: nome, email, student ID, messaggi privati
Dati NON compromessi (Instructure): password, date nascita, ID gov., dati finanziari

## Azioni immediate per amministratori Canvas
1. Ruotare tutte le Canvas API key
2. Revocare e re-emettere i token OAuth attivi
3. Verificare integrazioni SSO e provider identità
4. Auditare account Free-For-Teacher attivi
5. Abilitare MFA per tutti gli account amministrativi]]></description><link>https://forum.androidiani.net/topic/78eb1b02-6942-46cc-b3b2-01bf6c045368/shinyhunters-viola-canvas-275-milioni-di-studenti-nel-mirino-nel-più-grande-data-breach-educativo-della-storia</link><guid isPermaLink="true">https://forum.androidiani.net/topic/78eb1b02-6942-46cc-b3b2-01bf6c045368/shinyhunters-viola-canvas-275-milioni-di-studenti-nel-mirino-nel-più-grande-data-breach-educativo-della-storia</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 11 May 2026 15:20:51 GMT</pubDate></item><item><title><![CDATA[LAPSUS$ colpisce Checkmarx: 95 GB di codice sorgente su dark web e la supply chain dei tool di sicurezza nel mirino]]></title><description><![CDATA[Si parla di:ToggleQuando a essere violato è uno dei principali vendor di sicurezza applicativa — uno strumento usato per rilevare vulnerabilità nel codice altrui — le implicazioni si estendono ben oltre l’azienda stessa. Il gruppo LAPSUS$ ha pubblicato sul dark web 95 gigabyte di dati riservati di Checkmarx, inclusi codice sorgente, chiavi API e credenziali di database. È l’ultimo capitolo di una campagna supply chain orchestrata da un attore noto come TeamPCP, che da settimane sta sistematicamente compromettendo l’ecosistema degli strumenti di sviluppo e sicurezza.Cosa è stato esfiltratoIl 25 aprile 2026, LAPSUS$ ha rivendicato pubblicamente l’attacco a Checkmarx, pubblicando un archivio di circa 95 GB che include codice sorgente dei repository GitHub privati dell’azienda (tra cui componenti di KICS, il motore open source per la scansione di configurazioni cloud e IaC), un database dei dipendenti con informazioni personali e credenziali interne, chiavi API per servizi di terze parti e integrazioni, e credenziali di database MongoDB e MySQL dell’ambiente di sviluppo.Checkmarx ha confermato l’autenticità del dump in un advisory pubblicato il 26 aprile, precisando che i repository GitHub compromessi sono separati dall’ambiente di produzione per i clienti e che nessun dato cliente è stato esposto direttamente. Tuttavia, la presenza di chiavi API e credenziali nei file esfiltrati amplia significativamente la superficie di attacco potenziale.Il vettore: la campagna supply chain TeamPCPL’accesso ai sistemi di Checkmarx non è stato ottenuto tramite un attacco diretto, ma attraverso la compromissione della supply chain di sviluppo software. La data del breach originale è il 23 marzo 2026, quando TeamPCP ha iniettato codice malevolo in componenti dell’ecosistema Checkmarx disponibili pubblicamente. Le immagini Docker KICS ufficiali su Docker Hub sono state sostituite con versioni trojanizzate contenenti uno stealer di credenziali: gli sviluppatori che le utilizzavano nelle pipeline CI/CD scaricavano automaticamente il malware. Parallelamente, due estensioni VS Code correlate a Checkmarx pubblicate su marketplace sono state compromesse con funzionalità di esfiltrazione che operavano silenziosamente in background.Il nome TeamPCP emerge anche in connessione con le 73 estensioni malicious su Open VSX scoperte a fine aprile, suggerendo una campagna coordinata e ad ampio raggio contro l’intero ecosistema degli strumenti DevSecOps. Il modello è chiaro: compromettere prima gli strumenti che gli sviluppatori di sicurezza usano quotidianamente, per poi risalire — tramite le credenziali rubate — ai sistemi più preziosi.Chi è LAPSUS$LAPSUS$ è un gruppo di cybercrime con una storia operativa peculiare: composto prevalentemente da giovani hacker (diversi dei quali minorenni all’epoca degli attacchi), il gruppo si è distinto tra il 2021 e il 2022 per una serie di operazioni ad alto profilo contro Nvidia, Samsung, Okta, Microsoft e Uber, utilizzando principalmente tecniche di social engineering e SIM swapping piuttosto che exploit tecnici sofisticati. Dopo una serie di arresti nel 2022-2023, il gruppo sembrava smantellato. La ricomparsa nel 2026, questa volta sfruttando l’infrastruttura supply chain di TeamPCP come vettore di accesso iniziale, dimostra una capacità di adattamento e riorganizzazione che rende LAPSUS$ una minaccia ancora attiva.Timeline dell’incidente23 marzo 2026: TeamPCP compromette le immagini Docker KICS e le estensioni VS Code; furto delle credenziali Checkmarx GitHubFine marzo – inizio aprile 2026: esfiltrazione massiva dei 95 GB di repository privati25 aprile 2026: LAPSUS$ pubblica il data dump sul dark web e rivendica l’attacco26 aprile 2026: Checkmarx pubblica un advisory confermando la violazione e bloccando l’accesso al repository compromesso29 aprile 2026: il dump viene diffuso pubblicamente in forum accessibili, aumentando il rischio di sfruttamento secondario delle chiavi API esposteImplicazioni per gli utenti Checkmarx e i team DevSecOpsLa violazione di Checkmarx solleva preoccupazioni su più livelli. In primo luogo, l’esposizione del codice sorgente dei motori di analisi potrebbe consentire ad attori malevoli di identificare potenziali vulnerabilità nelle logiche di scanning, aprendo la porta ad attacchi che bypassano o manipolano i risultati dell’analisi statica del codice. In secondo luogo, i team che hanno utilizzato immagini Docker KICS o le estensioni VS Code compromesse tra marzo e aprile 2026 devono considerarsi potenzialmente compromessi e procedere con un’indagine forensica.Indicatori di Compromissione e azioni immediate# Immagini Docker KICS compromesse (periodo a rischio: 23/03 - 26/04/2026)
checkmarx/kics:latest  # verificare hash con: docker inspect --format='{{.Id}}' checkmarx/kics:latest
checkmarx/kics:v1.7.x  # controllare con advisory ufficiale Checkmarx
# Credenziali da ruotare immediatamente se si è usato KICS Docker nel periodo a rischio:
# - Token GitHub con accesso ai repository
# - Chiavi API Checkmarx
# - Credenziali MongoDB/MySQL condivise con l'ambiente di sviluppo
# - Segreti nelle pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins)
# Verifica estensioni VS Code compromesse:
# Controllare l'elenco completo nel security advisory ufficiale su checkmarx.com/blog/checkmarx-security-update-april-26/
# Log da analizzare per pull sospetti (pipeline CI/CD):
# grep -r "checkmarx/kics" .github/workflows/ .gitlab-ci.yml JenkinsfileConsigli per i difensoriL’attacco a Checkmarx è emblematico di una tendenza sempre più preoccupante: i tool di sicurezza stessi diventano vettori di attacco. È necessario verificare i log delle pipeline CI/CD tra il 23 marzo e il 26 aprile 2026 per identificare eventuali pull di immagini Checkmarx da Docker Hub. Qualsiasi segreto memorizzato nell’ambiente di sviluppo deve essere considerato compromesso e sostituito immediatamente. Le estensioni VS Code Checkmarx vanno rimosse e reinstallate da sorgenti verificate e firmate. Il monitoraggio del dark web nei prossimi mesi è raccomandato: i 95 GB esfiltrati contengono informazioni che potrebbero essere sfruttate per attacchi secondari a lungo termine.Più in generale, questo incidente sottolinea l’urgenza di adottare il principio del least privilege nelle pipeline CI/CD: i processi automatizzati non dovrebbero avere accesso a credenziali di produzione. L’isolamento degli ambienti — sviluppo, staging, produzione — e la firma crittografica delle immagini container (tramite strumenti come Cosign e la policy enforcement con Kyverno o OPA) limitano significativamente il blast radius di compromissioni simili. Quando a essere attaccato è chi produce gli strumenti di difesa, l’unica risposta efficace è l’architettura zero-trust applicata anche all’infrastruttura DevSecOps.]]></description><link>https://forum.androidiani.net/topic/78102ee1-718c-4aef-bbcd-547d0798fe7e/lapsus-colpisce-checkmarx-95-gb-di-codice-sorgente-su-dark-web-e-la-supply-chain-dei-tool-di-sicurezza-nel-mirino</link><guid isPermaLink="true">https://forum.androidiani.net/topic/78102ee1-718c-4aef-bbcd-547d0798fe7e/lapsus-colpisce-checkmarx-95-gb-di-codice-sorgente-su-dark-web-e-la-supply-chain-dei-tool-di-sicurezza-nel-mirino</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Thu, 30 Apr 2026 08:39:54 GMT</pubDate></item><item><title><![CDATA[ShinyHunters colpisce attraverso Anodot: la supply chain SaaS apre i data warehouse Snowflake di decine di aziende — ora nel mirino Vimeo]]></title><description><![CDATA[Si parla di:ToggleUn solo fornitore SaaS compromesso, e l’effetto domino colpisce decine di aziende enterprise. È la logica brutale dell’attacco supply chain che ShinyHunters ha affinato negli ultimi due anni: questa volta la porta di servizio si chiama Anodot, una piattaforma di analytics cloud che integra direttamente con Snowflake. L’ultimatum più recente è di oggi, 28 aprile 2026, contro Vimeo: pagare entro il 30 aprile o subire la pubblicazione dei dati esfiltrati da Snowflake e BigQuery.Il vettore: compromettere il custode per svaligiare il caveauAnodot è una piattaforma di monitoraggio dei costi cloud e anomaly detection usata da nomi come Atlassian, T-Mobile, UPS, Vimeo, Nordstrom, Amdocs, NICE e CyberArk. Per svolgere il suo lavoro, Anodot richiede token di accesso privilegiato ai data warehouse dei clienti — Snowflake in primis. È qui che ShinyHunters ha trovato la sua leva: invece di attaccare ogni vittima singolarmente, ha preso di mira il custode delle chiavi.Secondo le analisi dei ricercatori di RH-ISAC e Mitiga, gli attaccanti hanno sottratto token di autenticazione dall’infrastruttura di Anodot nel corso delle prime settimane di aprile 2026. Questi token, validi per accedere direttamente agli account Snowflake dei clienti, hanno aperto la strada all’esfiltrazione senza la necessità di sfruttare alcuna vulnerabilità nelle piattaforme delle vittime finali. Snowflake stessa non è stata violata: il problema è nella catena di fiducia tra il provider SaaS e i suoi clienti.Chi è ShinyHunters e il precedente Snowflake del 2024ShinyHunters è un collettivo cybercriminale attivo dal 2020, specializzato in esfiltrazione massiva di database e successiva estorsione. Il gruppo è salito alla ribalta internazionale con la violazione di Tokopedia (91 milioni di account), Microsoft GitHub e decine di altre piattaforme, finendo per diventare uno degli attori più prolifici nel mercato underground dei dati rubati.Il precedente Snowflake — scoppiato nella primavera-estate del 2024 — aveva già mostrato la pericolosità del vettore credential stuffing su piattaforme di dati cloud: Ticketmaster (560 milioni di record), AT&amp;T (quasi tutti i clienti americani), Santander e oltre 165 organizzazioni compromesse attraverso credenziali rubate agli utenti di Snowflake privi di autenticazione multifattore. In quel caso il metodo era il credential stuffing diretto; ora il livello di sofisticazione è aumentato: si colpisce il provider intermedio per aggirare anche l’MFA delle vittime finali.La progressione degli attacchi: da Rockstar Games a VimeoLa timeline della campagna Anodot è ricostruibile dai post del leak site di ShinyHunters:11 aprile 2026 — ShinyHunters pubblica un messaggio rivolto a Rockstar Games: “Your Snowflake instances were compromised thanks to Anodot. Pay or leak by April 14”. Rockstar conferma una violazione a terze parti, specificando che non sono stati colpiti dati dei giocatori.Metà aprile 2026 — Emergono segnalazioni di altri clienti Anodot potenzialmente esposti; RH-ISAC emette un advisory alla propria comunità di retail e hospitality.28 aprile 2026 (oggi) — Nuovo ultimatum: ShinyHunters afferma di aver esfiltrato dati Snowflake e BigQuery di Vimeo tramite Anodot, con scadenza per il pagamento fissata al 30 aprile 2026.Anatomia tecnica dell’attaccoIl meccanismo di compromissione sfrutta la natura stessa dell’integrazione tra Anodot e Snowflake. Per monitorare i costi e rilevare anomalie nei data warehouse dei clienti, Anodot conserva nei propri sistemi token di accesso o credenziali di servizio con privilegi elevati — tipicamente account con ruolo ACCOUNTADMIN o SYSADMIN su Snowflake, o service account equivalenti su BigQuery.Una volta che gli attaccanti hanno sottratto questi token dall’infrastruttura di Anodot, le operazioni successive sono elementari:Autenticazione diretta all’account Snowflake della vittima tramite il token rubatoEnumerazione dei database e delle tabelle disponibiliEsecuzione di query SELECT * su tabelle di interesse (dati utenti, transazioni, metriche interne)Esfiltrazione tramite COPY INTO verso stage esterni o download direttoL’intera catena può essere eseguita senza toccare i sistemi interni della vittima finale, rendendo il rilevamento estremamente difficile per i team SOC che non monitorano attivamente gli accessi da IP insoliti o da service account normalmente inattivi nelle ore notturne.Indicatori di compromissione e segnali da monitorare# Snowflake: query per rilevare accessi anomali da service account
SELECT
  user_name,
  client_ip,
  event_timestamp,
  reported_client_type
FROM snowflake.account_usage.login_history
WHERE user_name ILIKE '%anodot%'
   OR user_name ILIKE '%integration%'
   OR user_name ILIKE '%svc%'
ORDER BY event_timestamp DESC;

# Verificare sessioni attive non riconosciute
SELECT *
FROM snowflake.account_usage.sessions
WHERE client_application_id NOT IN (
  /* lista delle applicazioni legittime attese */
)
AND created_on &gt; DATEADD(day, -30, CURRENT_TIMESTAMP());

# Controllare query di esfiltrazione massiva
SELECT query_text, user_name, rows_produced, execution_time
FROM snowflake.account_usage.query_history
WHERE rows_produced &gt; 100000
  AND query_type = 'SELECT'
ORDER BY start_time DESC;Il problema strutturale: la fiducia implicita nei provider SaaSIl caso Anodot mette a nudo una vulnerabilità sistemica nell’architettura di sicurezza delle aziende enterprise moderne: la proliferazione di integrazioni SaaS-to-SaaS crea una superficie d’attacco spesso invisibile ai team di sicurezza. Ogni strumento di monitoraggio, analytics, ITSM o osservabilità che si connette ai sistemi core diventa un potenziale pivot point per un attaccante.Il principio del least privilege — teoricamente applicato ai dipendenti — viene sistematicamente violato per i service account delle integrazioni SaaS, che spesso ricevono accessi di tipo amministratore perché “così funziona più facilmente”. Il risultato è che un unico provider compromesso può esporre l’intero ecosistema dati di un’organizzazione enterprise.Raccomandazioni operative immediateAudit immediato delle integrazioni Anodot: se la vostra organizzazione usa Anodot, ruotate immediatamente tutti i token di accesso e le credenziali condivise con il provider. Verificate i log di accesso Snowflake/BigQuery per le ultime 4 settimane.Network policies su Snowflake: abilitate le network policy che restringono l’accesso ai data warehouse solo agli IP autorizzati. Gli accessi da provider SaaS di terze parti dovrebbero provenire da range IP documentati e noti.OAuth e token scoping: privilegiate integrazioni che usano OAuth con scope limitati rispetto a credenziali amministrative persistenti. Implementate token rotation automatica con TTL brevi.Inventario delle integrazioni SaaS-to-SaaS: molte organizzazioni non hanno visibilità completa su quanti provider SaaS hanno accesso ai propri data warehouse. Un audit del tipo “chi può leggere cosa nel mio Snowflake?” è un esercizio urgente.Alerting su query anomale: configurate alerting su volumi di dati estratti superiori ai baseline storici, specialmente per service account di integrazioni esterne.L’ultimatum del 30 aprile su Vimeo resterà probabilmente senza risposta pubblica, come già avvenuto con Rockstar. Ma la campagna continuerà: finché esistono decine di provider SaaS con accessi privilegiati non monitorati ai dati delle loro enterprise, ShinyHunters — e gruppi analoghi — hanno un modello di business altamente redditizio.]]></description><link>https://forum.androidiani.net/topic/17b1de56-c34f-4c19-a3b7-9fddb30acbe6/shinyhunters-colpisce-attraverso-anodot-la-supply-chain-saas-apre-i-data-warehouse-snowflake-di-decine-di-aziende-ora-nel-mirino-vimeo</link><guid isPermaLink="true">https://forum.androidiani.net/topic/17b1de56-c34f-4c19-a3b7-9fddb30acbe6/shinyhunters-colpisce-attraverso-anodot-la-supply-chain-saas-apre-i-data-warehouse-snowflake-di-decine-di-aziende-ora-nel-mirino-vimeo</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Wed, 29 Apr 2026 09:07:36 GMT</pubDate></item></channel></rss>