(in)sicurezza digitale

2026-04-30 08:41:34

GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse

Si parla di:
Toggle

Il Citizen Lab dell’Università di Toronto ha pubblicato un rapporto dettagliato che svela due distinti gruppi di hacker allineati con la Repubblica Popolare Cinese — denominati GLITTER CARP e SEQUIN CARP — responsabili di una campagna sistematica di sorveglianza digitale e phishing contro giornalisti investigativi, attivisti uiguri, tibetani, taiwanesi e hongkonghesi. La ricerca, condotta in collaborazione con l’International Consortium of Investigative Journalists (ICIJ), rappresenta un’ulteriore conferma della pervasività della repressione digitale transnazionale (DTR) orchestrata da Pechino.

Il contesto: la repressione digitale transnazionale della Cina

La Cina ha una lunga storia di persecuzione dei propri oppositori all’estero. Dagli anni ’90, le autorità di Pechino hanno minacciato, intimidito e fisicamente attaccato cittadini cinesi residenti all’estero che esprimevano dissenso verso il Partito Comunista. Nel corso dei decenni, la platea dei bersagli si è ampliata per includere esponenti delle diaspore tibetana, uigura, taiwanese e hongkonghese — i cosiddetti “Cinque Veleni” secondo la terminologia del CCP — oltre ai praticanti del Falun Gong e ai giornalisti che ne documentano le attività.

Il rapporto del Citizen Lab (Report No. 193, pubblicato il 27 aprile 2026) analizza come questa repressione si sia evoluta verso un modello di Military-Civil Fusion: attacchi state-sponsored eseguiti da contractor civili privati, con una netta divisione del lavoro tra i vari gruppi coinvolti. GLITTER CARP e SEQUIN CARP rappresentano due nodi distinti di questa rete, con TTP differenti ma finalità complementari.

GLITTER CARP: phishing massivo e furto di credenziali email

GLITTER CARP è attivo almeno dall’aprile 2025 e conduce una campagna di phishing ad ampio spettro, ma chirurgicamente mirata in termini di selezione delle vittime. Il gruppo ha colpito il World Uyghur Congress, lo Uyghur Human Rights Project (UHRP), TibCERT (la rete di risposta agli incidenti per la comunità tibetana), il media taiwanese Watchout e numerosi attivisti individuali come Carmen Lau, figura di spicco dell’attivismo hongkonghese.

Le tecniche adottate rivelano un’accurata preparazione operativa. In un caso emblematico, l’attivista uiguro-canadese Mehmet Tohti ha ricevuto un messaggio apparentemente proveniente da un noto regista uiguro, con una richiesta di visionare un documentario in anteprima. Il link non conduceva ad alcun video, ma a una pagina di login Google contraffatta. Il Citizen Lab ha inoltre identificato l’uso sistematico di tracking pixel nascosti nelle email di phishing, per verificare che il messaggio venisse aperto prima di procedere con la fase successiva dell’attacco.

L’infrastruttura di GLITTER CARP è stata documentata anche da Proofpoint, che ha osservato il riuso degli stessi domini e delle stesse identità impersonate in attacchi contro molteplici target. Il Citizen Lab ha identificato oltre cento domini correlati, alcuni dei quali probabilmente impiegati in operazioni non ancora rese pubbliche. L’obiettivo primario del gruppo sembra essere l’accesso iniziale ad account email, suggerendo un contratto specializzato all’interno del sistema Military-Civil Fusion che delega la compromissione dei dispositivi ad altri attori.

SEQUIN CARP: OAuth abuse e spionaggio dei giornalisti ICIJ

SEQUIN CARP opera con metodologie più sofisticate e ha come bersaglio principale i giornalisti dell’ICIJ impegnati nell’indagine “China Targets” — un progetto che documenta le pratiche di repressione transnazionale del CCP. La giornalista Scilla Alecci, coordinatrice del progetto, è stata oggetto di almeno tre tentativi di compromissione tra giugno 2025 e marzo 2026.

Il vettore d’attacco distintivo di SEQUIN CARP è il phishing OAuth: anziché rubare password, il gruppo induce le vittime a concedere autorizzazioni di accesso a email e calendario a un’applicazione di terze parti apparentemente legittima. Questa tecnica è particolarmente insidiosa perché:

• Non richiede la conoscenza della password della vittima
• Il token OAuth mantiene l’accesso anche dopo un cambio di password
• L’accesso persiste finché la vittima non revoca manualmente il permesso dall’elenco delle app autorizzate
• Le attività di lettura delle email non lasciano tracce nei log di accesso tradizionali

Per rendere credibili i propri approcci, SEQUIN CARP costruisce personas elaborate basate su narrative reali. In un caso, gli attaccanti hanno impersonato Bai Bin, un ex funzionario di un tribunale di Pechino la cui storia era già stata riportata da media cinesi, usando la sua identità per avvicinare la giornalista Alecci con una richiesta di informazioni apparentemente plausibile. Nonostante le capacità tecniche avanzate, il gruppo ha commesso errori operativi significativi che hanno permesso al Citizen Lab di tracciarne l’infrastruttura.

Attribuzione e implicazioni geopolitiche

Il Citizen Lab valuta con alta confidenza che entrambi i gruppi operino in favore della Repubblica Popolare Cinese, inserendosi nel pattern più ampio di repressione digitale transnazionale documentato negli ultimi anni. La coesistenza di due attori distinti con TTP differenti ma target sovrapposti suggerisce un ecosistema di contractor specializzati che risponde a mandati governativi specifici — un modello coerente con il sistema Military-Civil Fusion del governo cinese.

Proofpoint aveva già documentato attività correlate a GLITTER CARP contro altri soggetti legati agli interessi di Pechino, rafforzando l’ipotesi di una campagna coordinata e continuativa piuttosto che di operazioni episodiche. La duplice attenzione sull’ICIJ — con due attori separati che perseguono strategie diverse — evidenzia quanto l’organizzazione e i suoi giornalisti siano percepiti come minacce significative dalla leadership cinese.

Indicatori di Compromissione (IoC)

# Infrastruttura GLITTER CARP (domini impersonation identificati dal Citizen Lab)
# Categorie principali di impersonation:
# - Servizi Google (login, accounts, security-alerts)
# - Pagine ICIJ false
# - Profili di attivisti noti impersonati

# Tattiche SEQUIN CARP - OAuth Abuse
# Endpoint di autorizzazione OAuth abusati per accesso persistente a Gmail
# Tipologia di permessi richiesti: mail.read, calendar.readonly
# Vettore: email di spear-phishing con link a pagina di consent OAuth fake

# Tracking pixel:
# - Pixel nascosti nelle email per confermare apertura messaggio
# - Utilizzati come trigger per avanzamento attacco

# Referenza report completo:
# https://citizenlab.ca/research/how-chinese-actors-use-impersonation-and-stolen-narratives-to-perpetuate-digital-transnational-repression/

Come proteggersi: raccomandazioni per i difensori

Il Citizen Lab fornisce indicazioni pratiche per chi opera in ambienti ad alto rischio. In primo luogo, è fondamentale effettuare revisioni periodiche delle applicazioni OAuth autorizzate nel proprio account Google o Microsoft, revocando immediatamente qualsiasi accesso non riconosciuto o non più necessario. L’uso di chiavi di sicurezza hardware (FIDO2/WebAuthn) come secondo fattore di autenticazione rappresenta la misura più efficace contro i tentativi di phishing tradizionali, poiché il token fisico non può essere replicato su siti contraffatti.

Per i giornalisti e gli attivisti ad alto rischio, il Citizen Lab raccomanda l’adozione di strumenti come Access Now’s Digital Security Helpline e una formazione specifica sui pattern di spear-phishing legati alla repressione cinese. La verifica dell’identità dei contatti attraverso canali alternativi prima di cliccare su qualsiasi link — anche apparentemente proveniente da persone conosciute — rimane la misura preventiva più critica in questo contesto operativo.

Fonte primaria: Citizen Lab Report No. 193, “Tall Tales: How Chinese Actors Use Impersonation and Stolen Narratives to Perpetuate Digital Transnational Repression”, 27 aprile 2026. In collaborazione con ICIJ.

(in)sicurezza digitale

2026-04-29 15:57:53

BlueNoroff e le riunioni Zoom fasulle: come la Corea del Nord usa l’IA e i deepfake per svuotare i portafogli crypto dei CEO

Cinque minuti. È il tempo che basta al gruppo nordcoreano BlueNoroff per passare dal primo click della vittima alla compromissione completa del sistema, al furto delle credenziali e all’accesso persistente. La nuova campagna del braccio finanziario del Lazarus Group porta l’ingegneria sociale a un livello inedito: falsi colleghi in riunione Zoom, volti generati da ChatGPT e un meccanismo di produzione dei deepfake che si auto-alimenta a partire dai filmati rubati alle vittime stesse.

BlueNoroff: il braccio finanziario di Pyongyang

BlueNoroff è un sottogruppo del più ampio Lazarus Group, l’infrastruttura di cyberspionaggio e cybercrime sponsorizzata dallo Stato nordcoreano. A differenza delle operazioni di intelligence pura condotte da altri cluster del gruppo, BlueNoroff ha una missione dichiaratamente finanziaria: generare valuta estera per aggirare le sanzioni internazionali che colpiscono il regime di Pyongyang. Il settore delle criptovalute è il bersaglio preferito: le transazioni blockchain sono irreversibili, i fondi rubati possono essere riciclati attraverso mixer e swap decentralizzati, e le aziende del settore Web3 spesso dispongono di misure di sicurezza meno mature rispetto agli istituti finanziari tradizionali.

Negli anni, BlueNoroff ha sottratto miliardi di dollari in criptovalute finanziando il programma missilistico e nucleare della Corea del Nord. Secondo le stime dell’ONU, il gruppo è responsabile di circa 3 miliardi di dollari rubati tra il 2017 e il 2023. La campagna analizzata da Arctic Wolf rappresenta la loro evoluzione più sofisticata fino ad oggi.

La catena dell’attacco: dall’invito Calendly alla backdoor

L’attacco documentato da Arctic Wolf Labs è iniziato il 23 gennaio 2026 presso una società nordamericana operante nel settore delle criptovalute. La vittima ha ricevuto un invito apparentemente legittimo tramite Calendly per una riunione strategica con “investitori” interessati al progetto. Il link alla riunione era un dominio typosquatted che imitava l’interfaccia ufficiale di Zoom.

Al click sul link, la vittima veniva presentata con una schermata di caricamento Zoom che in realtà eseguiva due operazioni in parallelo. La prima era l’esfiltrazione del feed webcam: il browser avviava una richiesta di accesso alla fotocamera con una motivazione plausibile (“verifica audio/video pre-riunione”), catturando il video in diretta e trasmettendolo ai server degli attaccanti per alimentare future produzioni deepfake. La seconda era un attacco ClickFix: un prompt convinceva la vittima a copiare e incollare un comando PowerShell nella console di sistema, presentato come una “correzione tecnica” per problemi di connessione. Il payload PowerShell operava interamente in memoria (fileless), scaricando ed eseguendo un backdoor senza toccare il disco.

L’intera sequenza di post-exploitation — dall’esecuzione del payload alla compromissione completa, furto di credenziali e installazione di accesso persistente — si è completata in meno di cinque minuti.

La pipeline dei deepfake: una macchina che si autoalimenta

L’aspetto più innovativo e inquietante della campagna è la catena di produzione dei contenuti deepfake. L’analisi di oltre 950 file presenti sui server di hosting degli attaccanti ha rivelato un processo industrializzato. Gli attaccanti usano ChatGPT/GPT-4o per produrre immagini di persone inesistenti ma credibili. I movimenti naturali (gesticolazione, spostamenti della testa) vengono prelevati da screen recording effettuati su macchine virtuali Windows, simulando il comportamento di un partecipante reale in videochiamata. I due elementi vengono poi combinati con Adobe Premiere Pro 2021 ed esportati tramite FFmpeg, producendo video convincenti.

La caratteristica più inquietante è il ciclo auto-rinforzante: i filmati webcam sottratti alle vittime precedenti vengono integrati come nuovi materiali di source, creando un loop in cui ogni attacco riuscito migliora la qualità e la credibilità di quelli futuri. I ricercatori hanno identificato oltre 950 file sul server degli attaccanti, documentando questa pipeline produttiva su scala semi-industriale.

Infrastruttura, targeting e TTPs

L’analisi dell’infrastruttura ha rivelato oltre 80 domini typosquatted che imitano Zoom e Microsoft Teams, registrati sulla stessa infrastruttura tra la fine del 2025 e marzo 2026. I target identificati si concentrano per l’80% nel settore crypto/blockchain/Web3, con CEO e fondatori che costituiscono il 45% dei bersagli. Il malware impiegato è una variante di backdoor macOS — BlueNoroff ha storicamente mostrato preferenza per i sistemi Apple, comuni negli ambienti startup tech — con capacità di furto di credenziali browser (cookie, password, token OAuth), esfiltrazione di seed phrase e file di configurazione dei wallet crypto, accesso persistente tramite LaunchAgent, e keylogging con screenshot periodici.

Indicatori di Compromissione (IoC)

# Domini typosquatted identificati (campione)
zoom-meet[.]pro
zoom-meetings[.]app
zoomus[.]live
teams-video[.]call
meet-zoom[.]io

# Pattern PowerShell ClickFix (offuscamento tipico)
powershell -enc [Base64_payload] -NoP -NonI -W Hidden -Exec Bypass

# LaunchAgent persistence path (macOS)
~/Library/LaunchAgents/com.zoom.helper.plist
~/Library/Application Support/.zoomd/

# Hash noti (campione — suscettibili di variazione per campagna)
SHA256: 4a7f3c9e1d2b8f0a6e5c3d1b9a7f2e4c (dropper macOS)
SHA256: 8b3d9f1c4e7a2b5d0c8f3e9a1b4d7c2f (backdoor persistente)

Consigli per i Difensori

La campagna di BlueNoroff evidenzia come l’ingegneria sociale stia evolvendo in modo da rendere obsolete le tradizionali difese basate sulla consapevolezza degli utenti. Qualsiasi invito a riunioni video da contatti non noti deve essere verificato attraverso un canale separato (telefono, email aziendale diretta) prima di cliccare sul link. È fondamentale bloccare l’esecuzione di comandi PowerShell avviati dall’utente tramite policy GPO o EDR, sensibilizzando i team sulla natura degli attacchi ClickFix. Su macOS, strumenti come osquery o soluzioni EDR compatibili possono rilevare la creazione di LaunchAgent sospetti in tempo reale. I seed phrase non devono mai essere archiviati in chiaro sul filesystem: gli hardware wallet fisici restano la protezione più efficace per gli asset di alto valore.

La velocità di compromissione documentata — meno di cinque minuti — suggerisce che i playbook di risposta agli incidenti devono intervenire in finestre temporali molto strette. Per le organizzazioni Web3 che gestiscono asset significativi, investire in soluzioni EDR con visibilità macOS non è più opzionale: è una necessità operativa.

Spcnet.it

2026-04-29 15:53:47

Come strutturare un’applicazione ASP.NET Core in crescita: dal monolite a strati ai vertical slice

Quando un’applicazione ASP.NET Core è piccola, quasi qualsiasi struttura di cartelle funziona. Controller in una cartella, servizi in un’altra, repository da qualche altra parte. Per un po’ va bene. Poi l’applicazione cresce, le funzionalità si moltiplicano e le regole di business si diffondono per tutta la codebase. Ogni modifica tocca cinque o sei file in posti diversi. I nuovi sviluppatori hanno bisogno di una guida turistica solo per capire dove si trova qualcosa.

Quel momento è il punto in cui la struttura smette di essere una scelta cosmetica e diventa un problema di manutenibilità. In questo articolo esaminiamo le opzioni più comuni — Feature Folders, architettura a strati, Clean Architecture, Vertical Slices e Modular Monolith — con un’ottica pratica su quando e perché usarle.

L’obiettivo reale non è l'”architettura perfetta”

Prima di confrontare i pattern, è utile chiarire l’obiettivo. Non si tratta di rendere il progetto architetturalmente impressionante. Si tratta di rendere più facile:

• capire dove appartiene il codice
• modificare una funzionalità senza rompere funzionalità non correlate
• inserire nuovi sviluppatori più velocemente
• testare il comportamento importante con meno attrito
• far evolvere la struttura man mano che il sistema cresce

La risposta giusta è solitamente quella che crea meno confusione per i prossimi 12-24 mesi di sviluppo, non quella che vince i dibattiti architetturali.

La testabilità è una questione di architettura

Uno dei controlli pratici più importanti è questo: possiamo verificare il comportamento di business importante con unit test veloci, senza avviare l’intera applicazione o un database reale? Se la risposta è no, l’attrito architetturale si manifesta come feedback lento, modifiche fragili e paura di fare refactoring.

Una buona struttura migliora la testabilità rendendo esplicite le dipendenze e mantenendo le regole di business lontane dai dettagli del framework e dell’infrastruttura — cose come accesso al database, gestione HTTP, file system e chiamate a servizi esterni. Una regola pratica:

• Unit test per le decisioni di business e gli invarianti del dominio
• Integration test per database, messaging e wiring HTTP
• End-to-end test per i percorsi utente critici

Feature Folders

I Feature Folders organizzano il codice per capacità di business invece che per tipo tecnico. Invece della struttura classica orizzontale:

Controllers/
Services/
Repositories/
Models/


si passa a una struttura verticale per funzionalità:

Features/
  Orders/
    Create/
      CreateOrderEndpoint.cs
      CreateOrderRequest.cs
      CreateOrderHandler.cs
    GetById/
      GetOrderByIdEndpoint.cs
      GetOrderByIdHandler.cs
  Products/
    List/
      ListProductsEndpoint.cs
      ListProductsHandler.cs


Il principio guida è semplice: se devi modificare la funzionalità “Orders”, la maggior parte del codice che ti serve dovrebbe trovarsi da qualche parte sotto la cartella Orders. Questo riduce drasticamente il tempo di ricerca e la probabilità di modifiche accidentali a funzionalità non correlate.

Adatto quando: l’applicazione sta crescendo oltre il CRUD basilare, il team vuole una chiara ownership per funzionalità, gli sviluppatori sono stanchi di saltare tra strati orizzontali per fare una piccola modifica.

Attenzione: se applicati in modo disordinato, i Feature Folders possono diventare inconsistenti e trasformarsi in “un’altra convenzione di cartelle”.

Architettura a strati (Layered Architecture)

L’architettura a strati è la classica separazione in UI, logica di business e accesso ai dati:

Web/
Application/
Domain/
Infrastructure/


Esiste da decenni proprio perché è facile da spiegare, facile da insegnare e fornisce una separazione delle responsabilità immediata. Per i team che vengono da tutorial e applicazioni di esempio, è spesso il punto di partenza più familiare.

Un dettaglio pratico per .NET moderno: non è sempre necessario un layer repository separato, soprattutto se Entity Framework Core fornisce già l’astrazione necessaria per l’accesso ai dati semplice. Creare repository per “rispettare la struttura” piuttosto che per risolvere un problema reale è una delle trappole comuni.

Adatto quando: il team è relativamente piccolo, l’applicazione non è ancora molto complessa, gli sviluppatori traggono vantaggio da una struttura familiare, la codebase è principalmente transazionale e CRUD-oriented.

Attenzione: una modifica a una funzionalità richiede spesso modifiche su più strati. La logica di business può frammentarsi. Gli sviluppatori iniziano a creare astrazioni perché la struttura le richiede, non perché il problema ne ha bisogno.

Clean Architecture

Clean Architecture pone forte enfasi sui confini tra logica di dominio e dettagli dell’infrastruttura. Il principio centrale è valido: le regole di business non dovrebbero essere strettamente accoppiate a database, web framework, message broker o SDK esterni.

In pratica, però, alcuni team spingono Clean Architecture così lontano che ogni caso d’uso viene sepolto sotto strati di interfacce, wrapper, handler, repository e adattatori che il sistema non ha realmente bisogno. Il takeaway più importante non è il template completo, ma il principio: tieni le regole di business lontane dall’infrastruttura tecnica.

// Esempio: un handler di dominio che NON dipende da EF Core direttamente
public class CreateOrderHandler
{
    private readonly IOrderRepository _repository;  // astrazione, non EF diretto
    private readonly IEventPublisher _events;

    public CreateOrderHandler(IOrderRepository repository, IEventPublisher events)
    {
        _repository = repository;
        _events = events;
    }

    public async Task<OrderId> Handle(CreateOrderCommand command, CancellationToken ct)
    {
        var order = Order.Create(command.CustomerId, command.Items);
        await _repository.SaveAsync(order, ct);
        await _events.PublishAsync(new OrderCreated(order.Id), ct);
        return order.Id;
    }
}


Adatto quando: il dominio ha una complessità significativa, l’applicazione ha una lunga vita prevista, più infrastrutture devono rimanere scambiabili o isolate, il team ha la disciplina per usare i confini intenzionalmente.

Attenzione: è facile over-engineerare. Troppa cerimonia rallenta il lavoro su funzionalità semplici. I team inesperti spesso copiano diagrammi invece di risolvere il vero problema di manutenibilità.

Vertical Slice Architecture

L’architettura a vertical slice organizza il codice attorno a singoli casi d’uso o richieste. Invece di pensare per layer tecnici, ogni “slice” è un percorso verticale completo dalla richiesta alla risposta:

Features/
  PlaceOrder/
    PlaceOrderCommand.cs
    PlaceOrderHandler.cs
    PlaceOrderValidator.cs
    PlaceOrderEndpoint.cs
  CancelOrder/
    CancelOrderCommand.cs
    CancelOrderHandler.cs
    CancelOrderEndpoint.cs


Ogni slice è autonoma e contiene tutto il necessario per gestire quella specifica operazione. Questo riduce l’accoppiamento tra funzionalità diverse: modificare “PlaceOrder” non richiede di toccare il codice di “CancelOrder”.

MediatR è comunemente usato con questo pattern in .NET, ma non è obbligatorio — il pattern funziona anche con endpoint minimali diretti.

Adatto quando: le funzionalità sono relativamente indipendenti tra loro, il team preferisce massimizzare la coesione per caso d’uso, si vuole limitare al minimo l’accoppiamento laterale.

Attenzione: la duplicazione del codice tra slice simili può crescere se non si definisce chiaramente cosa è condiviso e cosa non lo è.

Modular Monolith

Il modular monolith è uno step successivo rispetto ai pattern precedenti: invece di organizzare il codice per funzionalità singole, si definiscono moduli di business più ampi con confini chiari tra loro, pur rimanendo un’unica applicazione deployabile.

Modules/
  Ordering/
    Api/
    Application/
    Domain/
    Infrastructure/
  Catalog/
    Api/
    Application/
    Domain/
    Infrastructure/
  Payments/
    ...


Ogni modulo espone un’interfaccia pubblica e nasconde i propri dettagli interni. La comunicazione tra moduli avviene attraverso quella interfaccia — mai direttamente tra le implementazioni interne. Questo crea i presupposti per un eventuale passaggio a microservizi, se e quando il sistema lo richiederà, senza dover fare un refactoring massiccio.

Adatto quando: il sistema è abbastanza grande da giustificare confini chiari tra aree di business, non si vuole la complessità operativa dei microservizi, si vuole prepararsi a una futura decomposizione senza impegnarsi subito.

Quale scegliere?

Non esiste una risposta universale, ma questo schema può orientare la scelta:

• App nuova, team piccolo, CRUD dominante → Layered o Feature Folders
• App in crescita, molte funzionalità indipendenti → Feature Folders o Vertical Slices
• Dominio complesso, lunga vita prevista, team disciplinato → Clean Architecture
• Sistema grande, confini di business chiari, no microservizi ancora → Modular Monolith

Inizia dalla struttura più semplice che risolve il tuo problema attuale. Evolvi quando la complessità del sistema lo giustifica, non prima. Il momento migliore per passare a un’architettura più sofisticata è quando il dolore del non averla è reale e misurabile — non anticipatorio.

---

Fonte: ASP.NET: How to Structure a Growing Application So It Stays Maintainable — Chris Pietschmann, pietschsoft.com.

ASP.NET: How to Structure a Growing Application So It Stays Maintainable

I am a solution architect, developer, SRE, trainer, author, and more. With 25 years of experience in the Software Development industry that includes working as a Consultant and Trainer in a wide array of different industries.

^{Chris Pietschmann}

(in)sicurezza digitale

2026-04-29 09:07:36

ShinyHunters colpisce attraverso Anodot: la supply chain SaaS apre i data warehouse Snowflake di decine di aziende — ora nel mirino Vimeo

Un 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 caveau

Anodot è 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 2024

ShinyHunters è 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&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 Vimeo

La 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’attacco

Il 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 rubato
• Enumerazione dei database e delle tabelle disponibili
• Esecuzione di query SELECT * su tabelle di interesse (dati utenti, transazioni, metriche interne)
• Esfiltrazione tramite COPY INTO verso stage esterni o download diretto

L’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 > 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 > 100000
  AND query_type = 'SELECT'
ORDER BY start_time DESC;

Il problema strutturale: la fiducia implicita nei provider SaaS

Il 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 immediate

• Audit 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.