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

Spcnet.it

2026-04-28 16:40:16

Visual Studio Code 1.118: Agents app, Copilot CLI avanzato e TypeScript 7.0 in anteprima

La build Insiders di Visual Studio Code è arrivata alla versione 1.118, con un pacchetto di aggiornamenti concentrati soprattutto sullo sviluppo agente, sull’integrazione con Copilot CLI e sul supporto anticipato a TypeScript 7.0. Queste note coprono le modifiche introdotte tra il 21 e il 26 aprile 2026.

Agents app: SSO condiviso con VS Code

Da questa build, l’Agents app di VS Code supporta la condivisione del Single Sign-On (SSO) con Visual Studio Code su Windows. L’autenticazione è bidirezionale: se esegui il logout da una delle due applicazioni, l’operazione si propaga automaticamente all’altra. Questo elimina la necessità di autenticarsi separatamente nei due ambienti, rendendo più fluido il lavoro che alterna editor e agenti.

Sempre nell’Agents app, da questa versione viene rispettato lo stato di workspace trust già impostato in Visual Studio Code. Non è quindi più necessario ridefinire le autorizzazioni di fiducia del workspace quando si passa da un contesto all’altro.

Supporto per sessioni Claude Code nell’Agents app

Una novità rilevante per chi usa agenti IA nel proprio flusso di sviluppo: l’Agents app integra ora il supporto per le sessioni di Claude Code. Questo significa che puoi avviare e gestire sessioni di Claude Code direttamente dall’interno di VS Code, senza passare al terminale o a un’applicazione separata.

Per navigare rapidamente tra le sessioni aperte nell’Agents app sono stati aggiunti nuovi keybinding: Ctrl+1 e Ctrl+2 permettono di passare tra le sessioni senza dover usare il mouse.

Skill tool per le personalizzazioni agente e context: fork

Il sistema di personalizzazione degli agenti si arricchisce di un nuovo skill tool per le agent customizations. Insieme a questa funzione, è stato introdotto il supporto per context: fork, che permette di isolare il contesto di una skill in un ramo separato. Questo offre maggiore controllo su quali informazioni vengono condivise tra skill diverse durante una sessione agente.

Il menu di creazione delle personalizzazioni chat mostra ora anche descrizioni esplicative per ciascuna posizione di skill, aiutando gli sviluppatori a scegliere il tipo corretto di personalizzazione senza dover consultare la documentazione.

Copilot CLI: selezione automatica del modello e badge

Copilot CLI ha ricevuto il supporto per la selezione automatica del modello (auto model). Questa funzione analizza il contesto della richiesta e sceglie automaticamente il modello più adatto, senza che l’utente debba specificarlo manualmente.

Nelle risposte Copilot CLI visualizzate nel pannello chat è ora presente un badge con il nome del modello che ha gestito la richiesta. Questa piccola aggiunta è utile per chi vuole tenere traccia di quale modello viene effettivamente usato nelle diverse situazioni, soprattutto con l’auto-selezione attiva.

Sul fronte dell’infrastruttura, il Copilot CLI SDK risolve ora node-pty direttamente da VS Code tramite hostRequire, eliminando la necessità di copiare i binari di node-pty nella cartella prebuilds dell’SDK durante la build o al runtime. Questo semplifica il packaging e riduce i potenziali problemi di compatibilità tra versioni.

Le sessioni nel Copilot CLI SDK usano ora le API session-title del CLI come sorgente di verità per i nomi delle sessioni, garantendo nomi coerenti tra l’interfaccia della chat e il log delle sessioni.

TypeScript 7.0: opt-in alle nightly

Per chi vuole vivere sul filo del rasoio: VS Code 1.118 introduce la possibilità di opt-in alle nightly di TypeScript 7.0. Per abilitarlo è sufficiente modificare l’impostazione typescript.experimental.useTsgo nelle preferenze utente o workspace. Si ricorda che TypeScript 7.0 è basato sul nuovo compilatore riscritto in Go (annunciato con TS 7.0 Beta), che promette velocità circa 10 volte superiori rispetto al compilatore attuale — ma è ancora in fase sperimentale.

Supporto encoding CP857

Aggiunto il supporto per la codifica CP857 (Code Page 857, usata per il turco nella vecchia codifica DOS). Un’aggiunta di nicchia, ma apprezzabile per chi lavora con legacy codebase o file di testo in quel formato.

Accessibility nel terminale

Sono stati introdotti miglioramenti all’accessibilità per il question carousel delle azioni del terminale, garantendo una navigazione più fluida per gli utenti che usano screen reader o altri strumenti assistivi.

Come aggiornare alla build Insiders

Se vuoi testare queste funzionalità prima del rilascio stabile, puoi scaricare la VS Code Insiders build dal sito ufficiale. La versione Insiders si affianca a quella stabile e può essere usata in parallelo.

# Su Linux, tramite snap:
sudo snap install --classic code-insiders

# Su Windows/macOS: scarica l'installer dalla pagina ufficiale


Tieni presente che le funzionalità descritte in queste note riguardano la build Insiders e potrebbero cambiare prima del rilascio stabile del ciclo 1.118.

---

Fonte: Visual Studio Code 1.118 Release Notes — Visual Studio Code Team, aggiornato al 27 aprile 2026.

Download Visual Studio Code Insiders

For early adopters, you can get the latest release of VS Code each day with the Insiders Build. Available on Mac, Linux and Windows.

^{code.visualstudio.com}

(in)sicurezza digitale

2026-04-28 16:42:16

Xu Zewei estradato dall’Italia: il contractor MSS cinese dietro HAFNIUM e Silk Typhoon davanti alla giustizia americana

Un contractor cinese al servizio del Ministero della Sicurezza dello Stato è atterrato ieri a Houston in manette: Xu Zewei, 34 anni, è stato estradato dall’Italia negli Stati Uniti dopo l’arresto avvenuto a Milano nel 2025. L’indictment da nove capi di imputazione lo collega direttamente alla campagna HAFNIUM — ribattezzata Silk Typhoon — che tra il 2020 e il 2021 ha compromesso quasi 13.000 organizzazioni in tutto il mondo, inclusi laboratori di ricerca sul COVID-19 e migliaia di server Microsoft Exchange.

Chi è Xu Zewei e per chi lavorava

Xu Zewei non era un hacker solitario che operava dal suo appartamento: secondo l’accusa del Dipartimento di Giustizia americano, era un operativo contrattualizzato dello Shanghai State Security Bureau (SSSB), la divisione locale del MSS (Ministry of State Security), l’equivalente cinese della CIA. La sua copertura era Shanghai Powerock Network Co., Ltd., una delle decine di società-schermo che Pechino utilizza per mantenere una distanza plausibile dalle operazioni offensive di intelligence.

Il modello operativo è ormai collaudato: il MSS ingaggia hacker freelance o dipendenti di aziende private attraverso contratti formali, garantendo ai contractor protezione istituzionale e compenso economico, mentre lo Stato mantiene la negabilità. Lo stesso schema era già emerso con i gruppi APT40 e APT41, con accuse formali di DOJ risalenti al 2020 e al 2022.

La campagna HAFNIUM: zero-day su Exchange come arma di massa

Il nome HAFNIUM compare per la prima volta nei report Microsoft nel marzo 2021, quando l’azienda di Redmond divulga quattro vulnerabilità zero-day in Exchange Server (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) già sfruttate attivamente in natura. La catena di exploit, denominata ProxyLogon, consente a un attaccante remoto non autenticato di prendere il controllo completo di un server Exchange vulnerabile esposto su Internet.

La finestra tra la divulgazione e il patching di massa fu devastante: in pochi giorni, i threat actor legati a HAFNIUM scaricarono web shell su decine di migliaia di server in tutto il mondo. Le web shell — tipicamente file ASPX nascosti in directory come /aspnet_client/ — garantivano accesso persistente e permettevano di:

• Accedere alle caselle di posta elettronica degli utenti senza autenticazione
• Muoversi lateralmente all’interno della rete bersaglio
• Esfiltrare intere cartelle di e-mail, credenziali e documenti interni
• Installare ulteriori impianti malware per la persistenza a lungo termine

Il furto della ricerca sul COVID-19

Uno degli aspetti più inquietanti dell’indictment riguarda il targeting specifico di organizzazioni impegnate nella ricerca contro il COVID-19. Secondo i pubblici ministeri, Xu e i suoi co-cospiratori hanno attaccato istituti di ricerca, università e aziende farmaceutiche con l’obiettivo esplicito di sottrarre dati su vaccini, trattamenti e protocolli diagnostici. Le operazioni si collocano tra febbraio 2020 — quando il virus inizia a diffondersi globalmente — e giugno 2021, coprendo l’intero arco della corsa mondiale al vaccino.

L’FBI aveva avvisato già nel maggio 2020 che attori legati alla Cina stavano tentando di rubare proprietà intellettuale sulla ricerca pandemica, ma l’entità della campagna è emersa solo con le indagini successive. La sovrapposizione temporale tra la crisi sanitaria e le operazioni di spionaggio informatico solleva interrogativi scomodi sul ruolo dell’intelligence cinese nel tentativo di acquisire un vantaggio tecnologico e strategico durante la pandemia.

Il ruolo dell’Italia e l’estradizione

L’arresto di Xu Zewei a Milano nel 2025 rappresenta uno dei casi più significativi di cooperazione giudiziaria italo-americana in ambito cybercrime. L’Italia non è nuova a questo tipo di operazioni: negli anni ha collaborato con Washington per l’estradizione di figure legate al crimine informatico organizzato, ma un caso di hacking state-sponsored cinese di questa portata è inedito. L’estradizione, completata il 26 aprile 2026, pone l’imputato davanti alla corte federale di Houston per rispondere a un’accusa in nove capi.

La reazione di Pechino è stata prevedibile: il portavoce del Ministero degli Esteri ha definito le accuse “fabricate” e “pura finzione politica”, ribadendo la posizione di principio secondo cui la Cina “si oppone fermamente a qualsiasi forma di attività hacker”. Una narrativa difficile da sostenere di fronte a un indictment dettagliato che menziona infrastrutture, tool e vittime specifiche.

Da HAFNIUM a Silk Typhoon: l’evoluzione del gruppo

Microsoft ha ribattezzato HAFNIUM come Silk Typhoon nell’ambito del nuovo schema tassonomico che assegna nomi di fenomeni atmosferici agli attori state-sponsored. Il gruppo ha continuato ad operare dopo il 2021, espandendo il target set a infrastrutture governative, difesa, think tank e provider di servizi IT. Il pattern operativo rimane coerente: sfruttamento rapido di vulnerabilità zero-day o N-day in prodotti edge (VPN, firewall, server di posta) per ottenere accesso iniziale, seguito da movimenti laterali silenziosi e esfiltrazione prolungata.

Indicatori di compromissione (campagna HAFNIUM/ProxyLogon)

# CVE sfruttate nella campagna ProxyLogon
CVE-2021-26855  # SSRF pre-auth su Exchange (porta 443)
CVE-2021-26857  # Deserializzazione insicura su Unified Messaging
CVE-2021-26858  # Scrittura arbitraria post-auth su Exchange
CVE-2021-27065  # Scrittura arbitraria post-auth su Exchange

# Percorsi tipici delle web shell depositate
/aspnet_client/
/aspnet_client/system_web/
/owa/auth/
/ecp/auth/

# User-Agent noti usati da HAFNIUM
ExchangeServicesClient/0.0.0.0
python-requests/2.25.1

# Hash SHA-256 di web shell documentate
811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d

Implicazioni e raccomandazioni per i difensori

Il caso Xu Zewei riafferma un principio fondamentale nella difesa contro gli APT state-sponsored: la deterrenza giuridica, per quanto lenta, funziona come segnale. Ogni indictment pubblicato dal DOJ erode la narrazione di impunità che alimenta la proliferazione dei contractor hacker. Per i team di sicurezza, le lezioni operative sono chiare:

• Patch velocity sugli asset perimetrali: la finestra tra divulgazione CVE e compromissione attiva si è ridotta a ore. I server Exchange, i dispositivi VPN e i firewall esposti su Internet devono essere patchati entro 24-48 ore da ogni advisory critico.
• Hunting proattivo per web shell: strumenti come Microsoft Safety Scanner, MSERT e le regole YARA pubblicate da CISA permettono di rilevare web shell note anche dopo settimane di compromissione silente.
• Monitoraggio dell’esfiltrazione DNS e HTTPS: i gruppi cinesi tendono a usare canali legittimi per il C2 (cloud storage, servizi di posta). Il behavioral analytics sul traffico outbound è più affidabile delle signature statiche.
• Segmentazione degli ambienti di ricerca sensibili: laboratori R&D, dati clinici e proprietà intellettuale vanno isolati in segmenti con controlli di accesso stringenti e logging pervasivo.

Il caso è anche un promemoria del valore delle partnership internazionali: senza la cooperazione dell’Italia, Xu Zewei sarebbe probabilmente ancora libero. La caccia ai contractor MSS non si ferma qui.

netzpolitik.org

2026-04-28 13:35:41

Während in Brüssel viel von digitaler Souveränität gesprochen wird, bleibt die Finanzierung der Projekte, die diese verwirklichen sollen, ungewiss. Michiel Leenaars von der niederländischen @nlnet Foundation gibt Einblicke in seine Arbeit zur Förderung von Alternativen und erläutert, was er von der EU erwartet.

netzpolitik.org/2026/europaeis…

„Jede Form von Abhängigkeit ist schlecht“

^{Anna Ströbele Romero (netzpolitik.org)}

Spcnet.it

2026-04-28 10:22:24

AI locale in un’estensione Chrome con Transformers.js e Manifest V3: architettura pratica

Hugging Face ha pubblicato una guida dettagliata su come costruire un’estensione Chrome che esegue modelli AI direttamente nel browser, senza server esterni, usando Transformers.js e Manifest V3 (MV3). Il progetto di riferimento è una browser assistant basata su Gemma 4 E2B, open source e già disponibile sul Chrome Web Store. Vediamo in dettaglio l’architettura e le scelte tecniche che rendono fattibile questo approccio.

Perché AI locale in un’estensione?

L’inferenza locale porta vantaggi concreti: nessun dato dell’utente inviato a server esterni, latenza ridotta dopo il download iniziale del modello, funzionamento offline. Il limite storico era la complessità di integrare modelli ONNX direttamente in un’estensione browser. Transformers.js risolve questo problema esponendo un’API familiare (ispirata alla libreria Python di HuggingFace) che gira interamente nel browser tramite WebAssembly e WebGPU.

Architettura MV3: tre contesti, tre ruoli

Manifest V3 impone un’architettura a contesti separati, ognuno con accesso e ciclo di vita differenti. Il progetto usa tre entry point distinti:

• Background service worker (background.ts): il piano di controllo. Gestisce il ciclo di vita dell’agente, l’inizializzazione dei modelli, l’esecuzione dei tool e i servizi condivisi come feature extraction. I modelli Transformers.js vengono caricati e mantenuti qui.
• Side panel (sidebar/): il layer di interazione con l’utente. Chat input/output, streaming degli aggiornamenti, controlli di setup.
• Content script (content.ts): il bridge con la pagina web. Estrae contenuto dal DOM e gestisce l’evidenziazione di elementi.

La regola di design è chiara: orchestrazione pesante nel background, UI e logica di pagina leggeri. Questo evita di caricare il modello più volte, mantiene l’interfaccia reattiva e rispetta i confini di sicurezza di Chrome.

Contratto di messaggistica tipato

Con contesti separati, la comunicazione avviene tramite messaggi. Il progetto li tipizza con enum in src/shared/types.ts:

// Side panel verso background
enum BackgroundTasks {
  CHECK_MODELS,
  INITIALIZE_MODELS,
  AGENT_GENERATE_TEXT,
  AGENT_GET_MESSAGES,
  AGENT_CLEAR,
  EXTRACT_FEATURES
}

// Background verso side panel
enum BackgroundMessages {
  DOWNLOAD_PROGRESS,
  MESSAGES_UPDATE
}

// Background verso content script
enum ContentTasks {
  EXTRACT_PAGE_DATA,
  HIGHLIGHT_ELEMENTS,
  CLEAR_HIGHLIGHTS
}

Il flusso tipico è: la side panel invia AGENT_GENERATE_TEXT, il background aggiunge il messaggio alla conversazione, esegue l’inferenza, poi emette MESSAGES_UPDATE alla side panel che ri-renderizza.

Integrazione di Transformers.js: dove gira l’inferenza

L’estensione usa due modelli con ruoli distinti, definiti in src/shared/constants.ts:

• Text generation (LLM): onnx-community/gemma-4-E2B-it-ONNX, formato q4f16 – responsabile delle risposte chat e dell’esecuzione dell’agente.
• Feature extraction (embedding): un modello separato per estrarre vettori da testi di pagina, usato per operazioni semantiche.

Entrambi i modelli vengono inizializzati e cachati nel background service worker. Il download avviene al primo avvio e i pesi rimangono nella cache del browser (via Cache API), così le sessioni successive partono istantaneamente. Il progresso del download viene trasmesso alla side panel tramite l’evento DOWNLOAD_PROGRESS.

Agent loop e tool calling

L’estensione implementa un loop agente completo. La classe Agent gestisce la cronologia dei messaggi e il ciclo di ragionamento:

// Flusso semplificato di Agent.runAgent
while (true) {
  const response = await model.generate(chatMessages);

  if (response.hasToolCall) {
    const toolResult = await executeTool(response.toolCall);
    chatMessages.push({ role: "tool", content: toolResult });
  } else {
    // Risposta finale
    break;
  }
}

I tool disponibili includono EXTRACT_PAGE_DATA (estrae il testo dalla pagina corrente via content script) e HIGHLIGHT_ELEMENTS (evidenzia elementi nel DOM). L’interfaccia dei tool è definita con schema JSON per permettere al modello di invocarli correttamente.

Build e packaging: Vite e MV3

Il progetto usa Vite per il build, con configurazione custom per generare entry point separati per background, side panel e content script. I modelli ONNX non sono inclusi nel bundle dell’estensione (sarebbero troppo grandi), ma vengono scaricati da Hugging Face Hub al primo avvio.

Un dettaglio pratico importante: i service worker MV3 possono essere terminati dal browser in qualsiasi momento quando inattivi. Bisogna gestire la persistenza dello stato (conversazione, modelli inizializzati) in modo da riprendere correttamente al risveglio del worker. Il progetto usa chrome.storage.session per lo stato effimero e chrome.storage.local per i dati persistenti tra sessioni.

Considerazioni pratiche prima di adottare questo approccio

Prima di replicare questa architettura in un progetto reale, vale la pena considerare alcune limitazioni:

• Dimensione modello: Gemma 4 E2B in q4f16 pesa diversi gigabyte. Il download iniziale richiede una connessione affidabile e spazio disco significativo nel profilo Chrome.
• Compatibilità hardware: le prestazioni variano molto tra macchine. Su hardware senza GPU decente, l’inferenza può essere lenta anche con quantizzazione aggressiva.
• Ciclo di vita service worker: Chrome può terminare il background worker dopo 5 minuti di inattività. Gestire il riavvio e la reinizializzazione del modello è parte non banale dell’implementazione.
• Review del Chrome Web Store: le estensioni con funzionalità AI vengono esaminate più attentamente; documentare chiaramente cosa fa il modello e dove girano i dati accelera il processo di approvazione.

Conclusione

L’architettura descritta da HuggingFace è solida e dimostra che eseguire AI locale in un’estensione Chrome è fattibile oggi con Transformers.js. Il codice sorgente dell’estensione Gemma 4 Browser Assistant è disponibile su GitHub come riferimento completo, con implementazione reale di tool calling, streaming e gestione del ciclo di vita MV3. Per chi vuole portare funzionalità AI nelle proprie estensioni senza dipendere da API esterne, questo progetto è un ottimo punto di partenza.

---

Fonte: How to Use Transformers.js in a Chrome Extension – Hugging Face Blog, 23 aprile 2026

How to Use Transformers.js in a Chrome Extension

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

^{Nico Martin (Hugging Face)}

(in)sicurezza digitale

2026-04-27 18:19:25

LockBit 5.0 in Escalation: dalla Banca delle Banche Centrali Latinoamericane alle logistiche Europee

LockBit 5.0 — nome in codice ChuongDong — non è la resurrezione di un brand cybercriminale: è la prova che i ransomware-as-a-service più organizzati si evolvono più velocemente delle operazioni delle forze dell’ordine che li contrastano. Nell’ultima settimana di aprile 2026, la gang ha rivendicato colpi su un istituto finanziario fondato dalle banche centrali latinoamericane, su società di logistica tedesche e su numerose altre vittime in Europa, Asia e nelle Americhe. Un’analisi tecnica e operativa della minaccia più attiva del momento.

Storia e resurrezione: da Operation Cronos a LockBit 5.0

Nel febbraio 2024, la joint task force internazionale Operation Cronos — guidata dall’NCA britannica con la partecipazione di Europol, FBI e polizie di altri dieci paesi — aveva inflitto quello che sembrava un colpo definitivo all’ecosistema LockBit: server sequestrati, chiavi di decryption pubblicate, affiliati arrestati in Polonia e Ucraina, e il volto del presunto admin “LockBitSupp” esposto pubblicamente.

La risposta del gruppo è arrivata con una certa prevedibilità: già nel settembre 2025, LockBit ha annunciato sul forum dark web RAMP la versione 5.0, coincidendo con il sesto anniversario dell’operazione. A distanza di circa sette mesi dal lancio, il quadro è chiaro: il gruppo ha ripreso la sua cadenza operativa, con oltre 100 vittime rivendicate sulla nuova data leak site (DLS) e attività in costante escalation nel 2026.

Architettura tecnica: cosa c’è di nuovo in LockBit 5.0

LockBit 5.0 è costruito su un’architettura a due componenti principali, un Loader e un modulo Ransomware, con una separazione netta tra funzioni di delivery e payload di cifratura.

Il Loader decifra il payload ransomware usando XOR combinato con compressione LZ e lo esegue direttamente in memoria, senza mai scrivere il binario cifrato su disco — una tecnica che complica notevolmente l’analisi forense e il rilevamento da parte degli antivirus tradizionali.

Sul fronte cifratura, la versione 5.0 introduce significativi miglioramenti rispetto alla 4.0:

• Cifratura differenziale basata sulla dimensione dei file: per i file più grandi viene cifrata solo una porzione, massimizzando la velocità dell’attacco e comprimendo la finestra di risposta per i difensori.
• Modulo di cancellazione delle Shadow Copy aggiornato: basato su codice derivato da Conti, ora utilizza le VSS API native di Windows invece degli strumenti da riga di comando, riducendo le tracce nel log degli eventi.
• Patching di EtwEventWrite: disabilita in memoria il Windows Event Tracing for Windows (ETW), cieco di fatto i sistemi di SIEM e EDR che si affidano ai provider nativi.
• Controlli di geolocalizzazione e locale: i campioni escludono automaticamente i sistemi nei paesi della CIS (Comunità degli Stati Indipendenti), un pattern tipico degli operatori ransomware di madrelingua russa.
• Estensioni randomizzate a 16 caratteri: i file cifrati ricevono un’estensione generata casualmente per ogni campagna, impedendo il rilevamento basato su signature statiche.

Multi-piattaforma: Windows, Linux e VMware ESXi nel mirino

Una delle novità più significative di LockBit 5.0 è l’espansione cross-platform. Il gruppo ha sviluppato tre varianti distinte — per Windows, Linux e VMware ESXi — che possono essere deployate in modo coordinato su tutta l’infrastruttura di una vittima.

La variante ESXi è progettata specificamente per cifrare i datastore delle macchine virtuali, paralizzando interi ambienti virtualizzati in un singolo passaggio. Per un’organizzazione enterprise che fa affidamento su VMware, questo significa che server, applicazioni critiche e database possono essere resi inaccessibili simultaneamente, moltiplicando la pressione a pagare il riscatto.

Le vittime di aprile 2026: da Bladex alle logistiche europee

La settimana del 26-27 aprile 2026 ha visto LockBit 5.0 rivendicare una serie di attacchi di profilo elevato, in particolare:

• Bladex (Panama): istituto finanziario multinazionale fondato direttamente dalle banche centrali dei paesi latinoamericani e caraibici. LockBit ha annunciato la pubblicazione dei dati entro 14-15 giorni. Un attacco a un istituto con questo profilo istituzionale ha implicazioni che vanno ben oltre il singolo incidente.
• Merlo Teleskoplader (Germania): produttore tedesco di macchinari industriali; la rivendicazione include potenziale esfiltrazione di dati tecnici e commerciali.
• D. Heinrichs Logistic GmbH (Bremerhaven, Germania): provider logistico nel porto di Bremerhaven, nodo strategico per il commercio europeo.

La concentrazione di vittime tedesche nel settore logistico/industriale suggerisce una campagna mirata, o quantomeno che gli affiliati di LockBit 5.0 stiano attivamente prendendo di mira la filiera produttiva e logistica europea.

Indicatori di compromissione e pattern di attacco

# File system indicators (Windows)
%TEMP%\ReadMeForDecrypt.txt         # Ransom note (naming convention LockBit 5.0)
*.{16-char random extension}         # File cifrati con estensione randomizzata
# Processi sospetti (behavior indicators)
vssadmin.exe (chiamate VSS API native invece di CLI)
wevtutil.exe (possibile log clearing pre-cifratura)
wmic.exe shadowcopy delete
# ETW patching (in-memory)
EtwEventWrite patched -> NOP sled   # Disabilita event tracing Windows
# Geolocation check (CIS exclusion)
GetUserDefaultLCID() / GetLocaleInfoW()  # Controllo locale pre-esecuzione
# Network indicators
Comunicazioni C2 su infrastrutture TOR
Data exfiltration pre-cifratura via tool personalizzato (data theft stage)
# Loader behavior
XOR + LZ decompression in memoria
Nessuna scrittura del payload cifrato su disco (fileless execution)

Il modello RaaS e la resilienza di LockBit

La sopravvivenza di LockBit alle operazioni delle forze dell’ordine non è un caso: è il risultato di un modello RaaS (Ransomware-as-a-Service) progettato con ridondanza in mente. Gli affiliati — decine di gruppi criminali indipendenti che noleggiano il malware in cambio di una percentuale dei riscatti — possono continuare a operare anche quando l’infrastruttura centrale viene sequestrata. Quando il codice e le build vengono trapelate o ricostruite, il lancio di una nuova versione diventa relativamente rapido.

LockBit 5.0 dimostra anche una capacità di adattamento tecnico reale: il patching in memoria di ETW, l’uso delle VSS API invece dei comandi shell, e l’architettura modulare cross-platform non sono aggiornamenti cosmetici ma miglioramenti mirati a sopravvivere agli EDR e ai SIEM di nuova generazione.

Raccomandazioni per i difensori

• Proteggere i backup offline e immutabili: la strategia più efficace contro LockBit rimane avere copie fuori dalla portata del ransomware. I backup connessi alla rete sono sempre stati l’obiettivo primario degli operatori.
• Monitorare le API di Volume Shadow Copy: rilevare chiamate anomale alle VSS API da processi inusuali, non solo l’esecuzione di vssadmin.
• EDR con visibilità sulle patch in-memory: i provider che monitorano l’integrità del codice in memoria (PatchGuard bypass, EtwEventWrite tampering) hanno significativamente più chance di rilevare LockBit 5.0 prima dell’esecuzione del payload.
• Segmentazione rigorosa degli ambienti VMware: i datastore ESXi non devono essere accessibili da host che non abbiano una necessità operativa diretta.
• Threat hunting basato su estensioni randomizzate: configurare alert su mass-rename di file con estensioni sconosciute nei file server critici.
• Verifica della geolocation check: se in un ambiente vengono rilevati controlli di locale da processi inusuali, potrebbe indicare una fase di reconnaissance pre-attivazione del payload.

LockBit 5.0 non è un fantasma del passato. È una minaccia attiva, tecnicamente evoluta e operativamente resiliente. L’attacco a Bladex — un’istituzione finanziaria nata per volontà delle banche centrali di un’intera regione del mondo — è il segnale che nessun settore, nessuna dimensione aziendale e nessuna geografia è fuori dal mirino del gruppo più prolifico del ransomware mondiale.

Spcnet.it

2026-04-27 13:55:45

CodeAct e Hyperlight: agenti AI piu veloci con meno chiamate al modello nel .NET Agent Framework

Chi lavora con agenti AI su basi .NET sa bene che il vero collo di bottiglia non è spesso la qualità del modello, ma il numero di round trip tra il modello stesso e i tool. Un agente che deve recuperare dati, filtrarli, fare calcoli e assemblare un risultato finisce tipicamente per eseguire cinque o sei chiamate separate al modello, ognuna con la propria latenza e il proprio costo in token. Microsoft ha presentato una soluzione concreta a questo problema: CodeAct, ora disponibile nel pacchetto alpha agent-framework-hyperlight.

Il problema: troppi turni, troppa latenza

Nel flusso tradizionale, un agente ragiona come segue: chiede al modello quale tool usare, esegue quel tool, rimanda il risultato al modello, il quale decide il prossimo tool, e così via. Questo schema modello → tool → modello → tool moltiplica la latenza e il consumo di token con ogni step aggiuntivo. Su task composti da tre, quattro o cinque operazioni concatenate (tipico nelle pipeline di data wrangling, elaborazione report, lookup incrociati), il costo diventa significativo.

CodeAct risolve il problema in modo elegante: invece di chiedere al modello di scegliere un tool alla volta, gli viene offerto un singolo tool speciale chiamato execute_code. Il modello esprime l’intero piano come un breve programma Python, che viene eseguito una volta sola in un ambiente sandbox. Il risultato? Latenza ridotta del ~50% e consumo di token calato di oltre il 60% su workload rappresentativi, secondo i dati pubblicati da Microsoft.

Hyperlight: sandbox micro-VM per sicurezza senza compromessi

La parte che rende CodeAct praticabile in produzione è Hyperlight: una tecnologia Microsoft che avvia una micro-VM isolata per ogni esecuzione di codice generato dal modello. Il codice Python prodotto dall’LLM gira dentro questa sandbox, senza accesso al filesystem host, alla rete o a qualsiasi risorsa non esplicitamente autorizzata. I tool reali invece continuano a girare nel runtime dell’applicazione, con tutti i permessi necessari.

Il bridge tra sandbox e tool avviene tramite la funzione call_tool(...): quando il codice nella sandbox chiama call_tool("nome_tool", ...), Hyperlight instrada la chiamata verso il tool nel processo principale, ne ritorna il risultato nella sandbox, e il programma continua. Il codice generato dall’AI rimane isolato; solo i tool verificati e distribuiti dallo sviluppatore hanno accesso reale alle risorse.

Come si integra CodeAct nel proprio agente

Il setup è sorprendentemente compatto. Dopo aver installato i pacchetti agent-framework e agent-framework-hyperlight:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict:
    # Restituisce il meteo corrente per una citta
    return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
    tools=[get_weather],
    approval_mode="never_require",
)

agent = Agent(
    client=client,
    name="CodeActAgent",
    instructions="Sei un assistente utile.",
    context_providers=[codeact],
)

result = await agent.run(
    "Ottieni il meteo di Seattle e Amsterdam e confrontali."
)


HyperlightCodeActProvider si occupa di due cose in automatico: registra il tool execute_code ad ogni run dell’agente, e inietta nel system prompt le istruzioni sulla sandbox e sui tool disponibili via call_tool(...).

Gestione delle approvazioni: chi controlla cosa

Agent Framework distingue due modalità di approvazione per i tool:

• never_require: il framework invoca il tool automaticamente.
• always_require: ogni chiamata viene sospesa in attesa di un’approvazione human-in-the-loop.

Con CodeAct, la logica cambia leggermente. I tool registrati su HyperlightCodeActProvider non vengono esposti direttamente al modello come tool di primo livello: il modello vede solo execute_code e raggiunge gli altri tool scrivendo call_tool("nome", ...) nel programma Python. L’approvazione, se richiesta, si applica all’intero blocco di codice, non alle singole chiamate interne.

La regola pratica è chiara: i tool puri e sicuri (lookup dati, calcoli, chiamate read-only) vanno passati al provider, così il modello li può comporre in un unico turno. I tool con side effect (invio email, scrittura su sistemi in produzione, transazioni economiche) vanno tenuti sull’agente direttamente con approval_mode="always_require", così il modello li deve invocare esplicitamente uno per uno.

Quando conviene usare CodeAct

CodeAct non è la soluzione giusta per ogni agente. I benefici massimi si ottengono con task che coinvolgono molte operazioni concatenate e chainabili: data wrangling, generazione report, lookup multipli, calcoli intermedi. Se il task dell’agente si risolve quasi sempre con una o due chiamate a tool, il guadagno è marginale.

È anche importante considerare che il codice Python generato dal modello deve essere revisionabile: uno dei vantaggi collaterali di CodeAct è che l’intero piano dell’agente è concentrato in un singolo blocco di codice leggibile e auditabile, invece di essere distribuito su una catena di messaggi di tool-call.

Conclusione

CodeAct con Hyperlight rappresenta un’evoluzione pragmatica nell’architettura degli agenti AI su .NET: meno turni, meno token, stessa qualità. Il pattern è disponibile oggi nel pacchetto alpha agent-framework-hyperlight, pronto per essere sperimentato su workload interni prima di adottarlo in produzione. Chi sta già usando Agent Framework e si trova a costruire pipeline di tool-calling complesse troverà probabilmente il guadagno di latenza immediato e concreto.

---

Fonte: CodeAct in Agent Framework: Faster Agents with Fewer Model Turns – Microsoft Dev Blogs, 23 aprile 2026

CodeAct in Agent Framework: Faster Agents with Fewer Model Turns | Microsoft Agent Framework

Explore the hyperlight codeact agent framework and streamline your tool-calling sequences with enhanced performance.

^{Eduard van Valkenburg (Microsoft Agent Framework)}

Spcnet.it

2026-04-27 11:00:43

LangChain.js per sviluppatori JavaScript: corso gratuito per costruire agenti AI

Volete costruire agenti AI con JavaScript che vadano oltre le semplici chat? Agenti che ragionano, chiamano strumenti esterni e interrogano knowledge base in modo autonomo? Microsoft ha pubblicato un corso gratuito e open source per fare esattamente questo: LangChain.js for Beginners, 8 capitoli con oltre 70 esempi TypeScript eseguibili.

Se già conoscete Node.js, npm, TypeScript e async/await, non avete bisogno di passare a Python per sviluppare applicazioni AI. LangChain.js vi mette a disposizione i componenti necessari — chat model, tool, agenti, retrieval e molto altro — senza dover cablare tutto da zero.

Perché LangChain.js?

LangChain.js è come avere un negozio di ferramenta completamente fornito a portata di mano. Invece di fabbricare ogni strumento dal metallo grezzo, prendete quello che serve dallo scaffale e iniziate a costruire. La libreria astrae l’integrazione con vari LLM (OpenAI, Azure OpenAI, Anthropic e altri), standardizza l’interfaccia per tool e agenti, e fornisce primitive per la costruzione di pipeline RAG.

Il vantaggio rispetto a Python? Zero friction per chi già lavora nell’ecosistema JavaScript/TypeScript. Stessi strumenti di build, stesso toolchain CI/CD, stessa base di codice.

Struttura del corso: un approccio agent-first

La maggior parte dei tutorial su LangChain inizia con document loader ed embedding. Questo corso arriva agli agenti e ai tool presto, perché è lì che si trovano i sistemi AI in produzione. Gli agenti decidono cosa fare, quando usare strumenti, e se hanno bisogno di cercare dati.

Capitoli 1-3: fondamenta

La prima chiamata a un LLM, chat model, streaming, prompt template e output strutturati con schemi Zod. Contenuto classico, ma necessario prima che le cose si facciano interessanti.

Capitolo 4: Function Calling e Tool

Qui l’AI smette di parlare e inizia a fare. Si insegna al modello a chiamare funzioni personalizzate, e lui ragiona su quando usarle. Esempio pratico:

import { ChatOpenAI } from "@langchain/openai";
import { tool } from "@langchain/core/tools";
import { z } from "zod";

const weatherTool = tool(
  async ({ city }) => {
    // chiamata a una API meteo reale
    return `Il meteo a ${city} è soleggiato, 22°C`;
  },
  {
    name: "get_weather",
    description: "Ottieni le condizioni meteo correnti per una città",
    schema: z.object({
      city: z.string().describe("Il nome della città"),
    }),
  }
);

const model = new ChatOpenAI({ model: "gpt-4o" });
const modelWithTools = model.bindTools([weatherTool]);

const result = await modelWithTools.invoke(
  "Che tempo fa a Milano?"
);
console.log(result.tool_calls);

Capitolo 5: Agenti con pattern ReAct

Un LLM risponde a domande. Un agente ragiona attraverso i problemi, sceglie i tool giusti ed esegue piani multi-step. Il capitolo 5 mostra come costruire agenti con il pattern ReAct (Reason + Act): il modello alterna tra pensiero esplicito e azioni concrete fino a raggiungere la risposta finale.

import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { ChatOpenAI } from "@langchain/openai";

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: "gpt-4o" }),
  tools: [weatherTool, searchTool, calculatorTool],
});

const response = await agent.invoke({
  messages: [{ role: "user", content: "Pianifica un itinerario a Roma per domani" }],
});
console.log(response.messages.at(-1)?.content);

Capitolo 6: MCP — Model Context Protocol

Il Model Context Protocol sta diventando lo standard per connettere l’AI a servizi esterni. Il capitolo guida alla costruzione di server MCP e al collegamento degli agenti tramite trasporti HTTP e stdio. È un’abilità sempre più richiesta man mano che l’ecosistema AI aziendale matura.

Capitoli 7 e 8: RAG agentivo

I capitoli finali portano documenti, embedding e ricerca semantica, poi combinano tutto in Agentic RAG. L’agente decide quando cercare nella knowledge base e quando rispondere direttamente da ciò che già conosce.

È una distinzione importante. Il RAG tradizionale è come lo studente che sfoglia il libro di testo per ogni domanda, anche “Quanto fa 2+2?”. Il RAG agentivo è lo studente intelligente che risponde alle domande semplici a memoria e apre il libro solo quando ne ha davvero bisogno. Il risultato: risposte più veloci, costi inferiori (meno ricerche di embedding non necessarie) e un’esperienza complessivamente migliore.

Come iniziare

Il corso è open source su GitHub. Per iniziare bastano tre comandi:

# Clona il repository
git clone https://github.com/microsoft/generative-ai-with-javascript

# Installa le dipendenze
cd generative-ai-with-javascript/lessons/08-langchain/
npm install

# Configura la chiave API
cp .env.example .env
# Aggiungi AZURE_OPENAI_API_KEY o OPENAI_API_KEY nel file .env

# Esegui il primo esempio
npx ts-node chapter1/01-first-llm-call.ts

Ogni capitolo include spiegazioni concettuali con analogie concrete, esempi di codice eseguibili immediatamente, sfide pratiche per testare la comprensione e punti chiave per consolidare l’apprendimento.

A chi è rivolto

Il corso si rivolge a sviluppatori JavaScript/TypeScript che conoscono npm install e async/await. Non è richiesta esperienza precedente in AI o machine learning. Ogni capitolo inizia con un’analogia del mondo reale per ancorare il concetto prima di qualsiasi codice.

Per chi già lavora su applicazioni .NET o backend e vuole esplorare il lato AI senza cambiare linguaggio, questo corso rappresenta il punto di ingresso ideale: nessun boilerplate Python, nessun ambiente virtuale da gestire, solo TypeScript e strumenti già familiari.

Considerazioni finali

LangChain.js ha raggiunto una maturità che lo rende adatto a progetti di produzione. Il corso di Microsoft colma un gap reale: la maggior parte della documentazione e dei tutorial sull’AI generativa è orientata a Python. Avere un percorso strutturato, gratuito e orientato agli agenti per l’ecosistema JavaScript è un vantaggio concreto per chi già lavora in questo stack.

Se state valutando come integrare capacità AI nelle vostre applicazioni Node.js o Deno, o se volete costruire un copilota interno per il vostro team, questo è il punto di partenza più pragmatico disponibile oggi.

---

Fonte originale: LangChain.js for Beginners: A Free Course to Build Agentic AI Apps with JavaScript — Microsoft for Developers

LangChain.js for Beginners: A Free Course to Build Agentic AI Apps with JavaScript - Microsoft for Developers

Want to build AI agents with JavaScript that go beyond basic chat completions? Agents that reason, call tools, and pull from knowledge bases on their own?

^{Yohan Lasorsa (Microsoft for Developers)}

(in)sicurezza digitale

2026-04-27 10:59:28

UNC6692 usa Microsoft Teams per distribuire SNOW: email bombing, impersonazione helpdesk e compromissione del dominio Active Directory

Si parla di:
Toggle

Non serve uno zero-day quando si puo’ semplicemente telefonare. O meglio: mandare un messaggio su Microsoft Teams fingendo di essere il supporto IT aziendale. E’ questa la filosofia operativa di UNC6692, un gruppo di minaccia documentato da Google Threat Intelligence Group (GTIG) e Mandiant il 22 aprile 2026, che ha sviluppato una delle catene di intrusione piu’ efficaci osservate di recente: zero vulnerabilita’ software sfruttate, impatto devastante.

La catena di attacco: dalla casella di posta al dominio compromesso

La campagna di UNC6692 si articola in piu’ fasi con una logica narrativa precisa, progettata per sfruttare i processi cognitivi delle vittime anziche’ le vulnerabilita’ del software. Tutto inizia tra fine dicembre 2025 e i mesi successivi con un’operazione di email bombing: le vittime — prevalentemente dipendenti senior (77% dei casi rilevati) — si trovano improvvisamente sommerse da migliaia di email spam, un’inondazione che paralizza l’attivita’ lavorativa e genera panico.

Nel momento di massima confusione, arriva il soccorso: un messaggio su Microsoft Teams da un account che si presenta come tecnico del supporto IT interno. L’attaccante offre assistenza per il problema email e guida la vittima attraverso una sequenza di azioni apparentemente legittime. Il punto critico e’ il click su un link che porta a una pagina di phishing ospitata su un bucket Amazon S3 — presentata come “Mailbox Repair and Sync Utility v2.1.5”. L’URL su S3 non e’ in lista di blocco di quasi nessun proxy aziendale, e il dominio amazonaws.com gode di alta reputazione nei sistemi di URL filtering.

La suite SNOW: tre strumenti, un’unica operazione

Il download dalla pagina di phishing avvia l’esecuzione di un binario AutoHotKey (RegSrvc.exe) che funge da dropper per l’ecosistema SNOW, una suite malware modulare composta da tre componenti distinti, ciascuno con un ruolo specializzato nella catena di compromissione.

SNOWBELT e’ un backdoor basato su JavaScript, distribuito come estensione Chromium (directory: SysEvents). Viene installato in modalita’ non-supervised attraverso policy forzate, non tramite il Chrome Web Store. Si maschera sotto nomi come “MS Heartbeat” o “System Heartbeat”. Una volta attivo nel browser della vittima, intercetta sessioni autenticate, cookie, token OAuth e qualsiasi credenziale inserita nelle form web. Comunica con il C2 tramite richieste verso bucket S3 in us-east-2, usando un VAPID key fisso come identificatore.

SNOWGLAZE e’ un tunneler Python compatibile con Windows e Linux. La sua funzione primaria e’ creare un tunnel WebSocket autenticato tra il sistema della vittima e l’infrastruttura C2 dell’attaccante, tipicamente un sottodominio Heroku. Questo tunnel permette all’attaccante di instradare traffico RDP, PsExec e altri protocolli attraverso una connessione apparentemente legittima verso Heroku, eludendo i controlli firewall.

SNOWBASIN e’ il backdoor persistente per il controllo remoto completo: esecuzione di comandi via cmd.exe o PowerShell, cattura di screenshot, upload/download di file e auto-terminazione. E’ SNOWBASIN che gestisce la fase di post-exploitation, una volta che il foothold iniziale e’ stabilito.

Post-exploitation: dal PC della vittima al domain controller

L’analisi di Mandiant descrive una sequenza di post-exploitation metodica e aggressiva. Dopo l’installazione della suite SNOW, l’attaccante utilizza SNOWGLAZE per stabilire una sessione PsExec verso il sistema compromesso, poi avvia una scansione della rete locale alla ricerca di sistemi raggiungibili su porte 135 (RPC), 445 (SMB) e 3389 (RDP). Una volta identificato un server di backup, SNOWGLAZE viene usato per instradare una sessione RDP verso di esso.

Sul server di backup avviene la fase critica: l’attaccante usa Windows Task Manager per eseguire il dump del processo LSASS (Local Security Authority Subsystem Service), catturando in chiaro tutti gli hash delle password degli account autenticati sul sistema, inclusi account privilegiati con accesso al dominio Active Directory. Il file di dump viene esfiltrato via LimeWire attraverso il tunnel SNOWGLAZE. Con gli hash estratti, e’ possibile effettuare attacchi pass-the-hash per autenticarsi come qualsiasi account del dominio, portando alla compromissione completa dell’infrastruttura AD.

Indicatori di compromissione (IoC)

# URL phishing (pattern)
https://service-page-[ID]-outlook.s3.us-west-2.amazonaws.com/update.html?email=

# C2 SNOWGLAZE (WebSocket)
wss://sad4w7h913-b4a57f9c36eb[.]herokuapp[.]com:443/ws

# C2 SNOWBELT (pattern URL S3)
https://[a-f0-9]{24}-[0-9]{6,7}-[0-9]{1}.s3.us-east-2.amazonaws[.]com

# SNOWBELT VAPID Key
BJkWCT45mL0uvV3AssRaq9Gn7iE2N7Lx38ZmWDFCjwhz0zv0QSVhKuZBLTTgAijB12cgzMzqyiJZr5tokRzSJu0

# File sospetti (dropper)
RegSrvc.exe    # binario AutoHotKey rinominato
Protected.ahk  # script AHK malevolo

# Directory estensione Chrome malevola
SysEvents/  # in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions

# Hash SHA256
SNOWGLAZE: 2fa987b9ed6ec6d09c7451abd994249dfaba1c5a7da1c22b8407c461e62f7e49
SNOWBELT background.js: 7f1d71e1e079f3244a69205588d504ed830d4c473747bb1b5c520634cc5a2477

Attribuzione e contesto

UNC6692 e’ classificato da Google/Mandiant come UNC (Uncategorized): non e’ ancora stata stabilita un’attribuzione definitiva a un paese o gruppo noto. Il profilo operativo mostra tuttavia caratteristiche interessanti: capacita’ di sviluppo malware custom elevate, pazienza tattica (la campagna di email bombing precede l’attacco di settimane) e una chiara preferenza per obiettivi aziendali con accesso privilegiato a infrastrutture IT. L’assenza di exploit zero-day puo’ indicare sia un operatore esperto che preferisce metodi OPSEC-sicuri, sia un gruppo finanziariamente motivato che ha ottimizzato il rapporto costo/impatto delle proprie operazioni.

Consigli per i difensori

La campagna UNC6692 mette in evidenza lacune difensive comuni negli ambienti enterprise. Sul fronte delle policy Microsoft Teams, e’ fondamentale limitare la possibilita’ per utenti esterni di contattare dipendenti interni tramite Teams: configurare una allowlist dei tenant esterni autorizzati e’ il primo passo. Sul fronte della protezione da email bombing, implementare rate limiting e filtri anti-spam aggressivi con alert su aumenti anomali di volume per singolo account. Per la protezione del browser, deployare policy Group Policy che blocchino l’installazione di estensioni Chrome non approvate e monitorare la creazione di nuove directory in %LOCALAPPDATA%. Monitorare il traffico verso sottodomini Heroku e bucket S3 non registrati come legittimi nel proprio inventario cloud. Infine, proteggere LSASS con Credential Guard su tutti i sistemi Windows 10/11 e Server 2019+: questa misura da sola avrebbe bloccato la fase piu’ critica dell’attacco documentato.

La campagna UNC6692/SNOW e’ un esempio paradigmatico di come il perimetro piu’ difficile da difendere non sia tecnico, ma umano: un dipendente stressato da un’inondazione di spam e “soccorso” da un collega del supporto IT e’ una vittima quasi inevitabile, indipendentemente dalla sofisticazione dell’infrastruttura di sicurezza aziendale.

Spcnet.it

2026-04-26 18:13:43

State Pattern in C#: guida decisionale con esempi pratici

Gli oggetti cambiano comportamento in base al loro stato interno continuamente. Un documento passa da bozza a revisione a pubblicato. Un personaggio di un gioco alterna tra inattivo, in corsa e in attacco. Un pagamento transita da pending ad autorizzato a catturato. La domanda quando usare lo State Pattern in C# emerge nel momento in cui la logica condizionale inizia a ramificarsi sullo stesso campo stato in metodo dopo metodo — e ogni nuovo stato obbliga a toccare più file.

In questo articolo troverete una guida decisionale pratica per il pattern State in C#: quando merita davvero il suo posto e quando soluzioni più semplici — enum o flag booleani — bastano e avanzano.

Cos’è lo State Pattern e cosa fa davvero

Lo State Pattern consente a un oggetto di cambiare il proprio comportamento quando il suo stato interno cambia. Dall’esterno sembra che l’oggetto abbia cambiato classe. Invece di sparpagliare istruzioni if e switch in ogni metodo che dipende dallo stato corrente, si incapsula il comportamento di ciascuno stato in una propria classe. L’oggetto delega al state object attivo in quel momento.

La struttura coinvolge tre ruoli:

• Context — mantiene un riferimento allo state object corrente e vi delega il comportamento
• State interface — dichiara i metodi che ogni stato deve implementare
• Concrete state classes — implementano l’interfaccia con il comportamento specifico del loro stato

Quando avviene una transizione, il context sostituisce il riferimento al proprio state object. Questo approccio elimina i blocchi condizionali che crescono ogni volta che si aggiunge uno stato nuovo.

Segnali che indicano che avete bisogno dello State Pattern

Non ogni oggetto con un campo status ha bisogno dello State Pattern. Tuttavia certi code smell sono segnali forti che il pattern ripulirà il design.

La logica condizionale si ramifica sullo stesso stato ovunque

Questo è il trigger principale. Quando vedete lo stesso switch o if-else che controlla _status in tre, quattro o dieci metodi diversi, il vostro oggetto sta gestendo le transizioni di stato nel modo più difficile. Ogni nuovo stato significa toccare ciascuno di quei metodi.

Avete regole di transizione complesse

Se le transizioni valide dipendono dallo stato attuale — e alcune azioni devono lanciare eccezioni o essere semplicemente ignorate a seconda di dove ci si trova — il pattern State rende queste regole esplicite invece di affogarle in condizionali.

Ogni stato ha un comportamento distinto

Quando lo stato influenza come si comporta un metodo, non soltanto se eseguirlo, il pattern vale l’investimento. Ciascuna classe stato diventa un luogo coeso che racchiude tutto il comportamento per quella condizione.

Scenario 1: gestione degli ordini (comportamento condizionale complesso)

Ecco un esempio di elaborazione ordini con lo State Pattern:

public interface IOrderState
{
    void Submit(OrderContext context);
    void Cancel(OrderContext context);
    void Ship(OrderContext context);
    void Deliver(OrderContext context);
}

public sealed class OrderContext
{
    public IOrderState CurrentState { get; private set; }
    public string OrderId { get; }

    public OrderContext(string orderId)
    {
        OrderId = orderId;
        CurrentState = new PendingState();
    }

    public void TransitionTo(IOrderState state)
    {
        Console.WriteLine(
            $"Order {OrderId}: " +
            $"{CurrentState.GetType().Name} -> " +
            $"{state.GetType().Name}");
        CurrentState = state;
    }

    public void Submit() => CurrentState.Submit(this);
    public void Cancel() => CurrentState.Cancel(this);
    public void Ship()   => CurrentState.Ship(this);
    public void Deliver() => CurrentState.Deliver(this);
}

public sealed class PendingState : IOrderState
{
    public void Submit(OrderContext context)
    {
        Console.WriteLine("Ordine inviato per elaborazione.");
        context.TransitionTo(new ProcessingState());
    }

    public void Cancel(OrderContext context)
    {
        Console.WriteLine("Ordine annullato prima dell'invio.");
        context.TransitionTo(new CancelledState());
    }

    public void Ship(OrderContext context) =>
        throw new InvalidOperationException("Impossibile spedire un ordine in attesa.");

    public void Deliver(OrderContext context) =>
        throw new InvalidOperationException("Impossibile consegnare un ordine in attesa.");
}

Notate come PendingState sappia esattamente cosa fare (o non fare) per ogni azione. Non c’è nessuno switch nello stato: il polimorfismo gestisce tutto.

Scenario 2: workflow e gestione dei processi

Un caso d’uso classico è la gestione di una domanda con audit trail integrato:

public interface IApplicationState
{
    string StatusName { get; }
    void Review(ApplicationContext context);
    void Approve(ApplicationContext context);
    void Reject(ApplicationContext context);
    void RequestInfo(ApplicationContext context);
}

public sealed class ApplicationContext
{
    public IApplicationState CurrentState { get; private set; }
    public string ApplicantName { get; }
    public List<string> AuditLog { get; } = new();

    public ApplicationContext(string applicantName)
    {
        ApplicantName = applicantName;
        CurrentState = new SubmittedState();
        Log("Domanda inviata");
    }

    public void TransitionTo(IApplicationState state)
    {
        Log($"Transizione a {state.StatusName}");
        CurrentState = state;
    }

    public void Log(string message) =>
        AuditLog.Add($"[{DateTime.UtcNow:u}] {message}");
}

L’audit trail viene aggiornato automaticamente a ogni transizione, senza duplicazione di codice nei metodi chiamanti.

Scenario 3: gestione dello stato di un personaggio in un gioco

I giochi sono un esempio naturale: un personaggio che alterna tra IdleState, RunningState, AttackingState e DyingState beneficia enormemente di questo pattern, poiché ciascuno stato ha logica di input e di update completamente diversa.

Quando NON usare lo State Pattern

Il pattern non è sempre la risposta giusta. Evitate di applicarlo nei seguenti casi:

• Stati booleani semplici: se l’oggetto ha solo attivo e inattivo, un campo booleano è più chiaro e diretto.
• Pochi stati senza transizioni significative: se avete due o tre stati con poco comportamento differenziato, gli enum bastano.
• La logica di transizione è esterna all’oggetto: se le decisioni di cambio stato appartengono a un orchestratore esterno, il pattern State aggiunge complessità senza benefici.

State Pattern vs alternative: quando scegliere cosa

Un enum con un switch è la scelta giusta quando gli stati sono pochi, stabili e il comportamento differisce solo su una o due dimensioni. Appena gli stati crescono, il comportamento diverge significativamente per metodo, o le transizioni diventano complesse, è il momento di passare al pattern State.

Il pattern State non è la stessa cosa del pattern Strategy: Strategy cambia l’algoritmo usato per una singola operazione, mentre State cambia il comportamento complessivo dell’oggetto al variare della condizione interna. Possono tuttavia lavorare insieme: una transizione di stato può emettere eventi che degli Observer gestiscono.

Integrazione con Dependency Injection

Una domanda comune è se il pattern State si integri bene con la DI di ASP.NET Core. La risposta è sì, con qualche accorgimento: le classi stato concrete possono essere registrate nel contenitore DI, ma è consigliabile usare factory o ActivatorUtilities.CreateInstance per creare le istanze in modo da evitare cicli nel contenitore.

Conclusione

Lo State Pattern in C# risolve un problema preciso: oggetti il cui comportamento cambia radicalmente al variare dello stato interno, con transizioni complesse e comportamento specifico per stato. Prima di applicarlo, fate questa verifica rapida: contate quante volte controllate lo stesso campo di stato in metodi diversi. Se la risposta supera tre o quattro, probabilmente il pattern vi risparmierà mesi di manutenzione futura.

La regola d’oro rimane: preferite sempre la soluzione più semplice che risolve il problema. Un enum con uno switch è più leggibile di una gerarchia di classi per casi banali. Ma quando la complessità cresce, lo State Pattern offre un’architettura che scala senza sforzo.

---

Fonte originale: When to Use State Pattern in C#: Decision Guide with Examples — Dev Leader

When to Use State Pattern in C#: Decision Guide with Examples

Discover when to use state pattern in C# with real decision criteria, use case examples, and guidance on when simpler alternatives work better.

^{Nick Cosentino (Dev Leader)}

(in)sicurezza digitale

2026-04-26 18:11:56

GlassWorm muta ancora: 73 estensioni “sleeper” su Open VSX pronte a svegliarsi come malware

Una campagna di supply chain attack di nuova generazione non aspetta di essere scoperta: prima si mimetizza, poi colpisce. È questa la logica dietro GlassWorm, un attore malevolo che ha trasformato il marketplace Open VSX in un campo minato di estensioni apparentemente legittime, pronte ad attivarsi dopo settimane di apparente innocenza.

La nuova ondata: 73 estensioni sleeper identificate

Il 25 aprile 2026, i ricercatori di Socket hanno pubblicato un’analisi approfondita rilevando 73 nuove estensioni per Open VSX — il registry alternativo a Visual Studio Marketplace, utilizzato principalmente dagli sviluppatori di VSCodium e Eclipse Theia — che mostrano caratteristiche riconducibili alla campagna GlassWorm. Almeno sei di queste estensioni si sono già “svegliate”, aggiornandosi per distribuire payload malevoli, mentre le restanti rimangono classificate come sleeper ad alta confidenza in attesa di attivazione.

Il meccanismo è elegante nella sua perversità: le estensioni vengono pubblicate con codice pulito, superano i controlli automatici del marketplace, accumulano installazioni e fiducia degli utenti — poi, attraverso un aggiornamento silenzioso o aggiungendo una dipendenza malevola, si trasformano in vettori di malware. Nessun exploit, nessun CVE: pura abuso della fiducia nella supply chain del software.

Evoluzione di una campagna persistente

GlassWorm non è un attore nuovo. La campagna è attiva almeno dal tardo 2024, con escalation progressive che si sono succedute nel corso del 2025-2026. A dicembre 2025 furono rilevate le prime 24 estensioni impersonatrici; a febbraio 2026 si scoprì che un account sviluppatore compromesso era stato usato per propagare il malware; a marzo 2026 la campagna scalò a 72 estensioni attive su Open VSX con diffusione tramite abuso di dipendenze. L’ondata di aprile 2026 rappresenta dunque l’evoluzione più sofisticata finora osservata.

Gli obiettivi rimangono costanti: furto di segreti di sviluppo (API key, token, credenziali), svuotamento di wallet di criptovalute, e trasformazione dei sistemi infetti in proxy per ulteriori attività criminali. Il target primario sono sviluppatori che lavorano su macOS, Linux e Windows con ambienti basati su VS Code o suoi fork.

Tecniche di attacco: la profondità della sleeper strategy

L’analisi di Socket rivela una serie di pattern tecnici ricorrenti nell’attuale cluster di 73 estensioni. I publisher sono account GitHub neonati, con una o due repository pubbliche: una repository vuota con nome composto da otto caratteri casuali e una contenente il codice dell’estensione. Questo pattern serve a superare le verifiche di identità del marketplace, che richiedono un profilo GitHub associato.

Le estensioni impersonano utility popolari — ad esempio il language pack turco per VS Code — usando la stessa icona, un nome simile e contenuti copiati dal pacchetto legittimo. Una volta guadagnata la fiducia degli utenti, la delivery del malware avviene in due modalità principali: aggiornamento diretto dell’estensione per includere codice offuscato, oppure aggiunta di una dipendenza da un’estensione separata che contiene il loader GlassWorm, sfruttando il fatto che l’installazione di un’estensione può portare all’installazione automatica di tutte le sue dipendenze dichiarate.

I payload attivati al momento includono: VSIX malevoli ospitati su GitHub, binari nativi firmati con certificati rubati, JavaScript offuscato con tecniche di code splitting per sfuggire all’analisi statica. Il loader GlassWorm, una volta eseguito nell’ambiente VS Code, ha accesso allo stesso filesystem, alle variabili d’ambiente e ai token di sessione dell’IDE — un privilegio enorme che permette di esfiltrare le credenziali di ogni servizio cloud configurato nello strumento di sviluppo.

Contesto più ampio: l’ecosistema VS Code come vettore sistemico

GlassWorm rappresenta un sintomo di una vulnerabilità strutturale: gli ecosistemi di estensioni per editor di codice sono intrinsecamente difficili da proteggere. A differenza dei package manager come npm o PyPI, dove esiste una cultura più consolidata di analisi della sicurezza, i marketplace di estensioni IDE tendono ad avere meccanismi di revisione più leggeri e una percezione del rischio più bassa da parte degli utenti. Un desarrollatore che installa un’estensione VS Code raramente si chiede se stia introducendo un RAT nella propria workstation.

La tecnica della sleeper extension è particolarmente insidiosa perché richiede pazienza da parte dell’attaccante — una caratteristica tipica di campagne sponsorizzate da attori con risorse significative. Non è ancora stata stabilita un’attribuzione definitiva per GlassWorm, ma il livello di sofisticazione e persistenza suggerisce un gruppo criminale strutturato o un attore nation-state interessato alla compromissione di pipeline di sviluppo software.

Indicatori di compromissione (IoC)

# Pattern publisher malevoli (account GitHub)
- Account con repository vuota a nome di 8 caratteri esadecimali
- Account creati tra gennaio e aprile 2026 senza storia pubblica

# Pattern nomi estensioni sospette (esempi noti)
- Estensioni che impersonano language pack (es. Turkish Language Pack for VSCode)
- Estensioni con nomi che differiscono di un carattere da quelle legittime

# Comportamenti runtime sospetti
- Lettura di variabili d'ambiente (PATH, HOME, credenziali cloud)
- Connessioni in uscita verso bucket S3 su us-east-2 o us-west-2
- Caricamento dinamico di script da URL GitHub Raw

# Repository di tracking
https://socket.dev/glassworm-v2  (lista aggiornata estensioni maligne)

Consigli per i difensori

Per chi gestisce ambienti di sviluppo, alcune misure concrete. Prima di tutto, applicare policy di allowlist per le estensioni VS Code/VSCodium approvate, impedendo l’installazione di estensioni non verificate dall’organizzazione. Monitorare con strumenti come Socket o Phylum le dipendenze dei progetti, incluse quelle delle estensioni IDE. Configurare il traffico di rete delle workstation degli sviluppatori per rilevare connessioni anomale verso S3 bucket sconosciuti o hostname Heroku. Abilitare la telemetria degli IDE aziendali e integrarla nel SIEM per rilevare accessi insoliti al keychain o alle variabili d’ambiente. Infine, considerare l’adozione di ambienti di sviluppo containerizzati o in sandbox, dove l’impatto di un’estensione compromessa è limitato al container.

Socket mantiene una pagina dedicata al tracking di GlassWorm v2 con l’elenco aggiornato delle estensioni malevole identificate: consultarla periodicamente è una misura di igiene minima per chi usa Open VSX. La campagna è ancora attiva e il numero di sleeper non ancora attivati — stimato in oltre 60 — suggerisce che il peggio non sia ancora avvenuto.