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

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