Spcnet.it

2026-05-11 17:15:53

Copilot Studio accelera con .NET 10 su WebAssembly: fingerprinting automatico e AOT ottimizzato

Microsoft Copilot Studio è uno strumento di low-code per la creazione di agenti AI, e uno dei suoi punti di forza è l’esecuzione di logica C# direttamente nel browser tramite .NET WebAssembly (WASM). Di recente, il team di Copilot Studio ha completato la migrazione del motore WASM da .NET 8 a .NET 10 — e i risultati sono più che soddisfacenti. In questo articolo analizziamo in dettaglio cosa è cambiato, perché vale la pena migrare anche per le vostre applicazioni Blazor e WebAssembly, e quali ottimizzazioni concrete offre .NET 10 in questo ambito.

Il contesto: C# nel browser con .NET WebAssembly

Qualche mese fa il team di Copilot Studio aveva già pubblicato un post tecnico su come utilizzano .NET e WebAssembly per eseguire codice C# nel browser, mostrando i guadagni ottenuti passando da .NET 6 a .NET 8. Ora il ciclo si ripete con il salto a .NET 10, e la migrazione è stata descritta come sorprendentemente semplice.

Aggiornare un’applicazione WASM da .NET 8 a .NET 10 è sostanzialmente una questione di modificare il TargetFramework nei file .csproj e verificare la compatibilità delle dipendenze. Per Copilot Studio, il percorso è stato esattamente questo, e il build .NET 10 è già in produzione.

Fingerprinting automatico degli asset: addio script PowerShell personalizzati

Una delle novità più apprezzate di .NET 10 per le applicazioni WebAssembly è il fingerprinting automatico degli asset WASM. Quando si pubblica un’applicazione WebAssembly, ogni risorsa include ora un identificatore univoco nel nome del file, garantendo sia il cache-busting che l’integrità senza alcun intervento manuale.

Prima di .NET 10, Copilot Studio — come molte app WASM — doveva:

• Leggere il manifest blazor.boot.json pubblicato per enumerare tutti gli asset.
• Eseguire uno script PowerShell personalizzato per rinominare ogni file aggiungendo un hash SHA256.
• Passare un argomento integrity esplicito lato JavaScript al momento del caricamento di ogni risorsa.

Con .NET 10, tutto questo è storia. Le risorse vengono importate direttamente da dotnet.js, i fingerprint fanno parte dei nomi di file pubblicati, e l’integrità è validata automaticamente. Il team ha potuto eliminare lo script di rinomina personalizzato e rimuovere l’argomento integrity dal loader JavaScript lato client.

Tip: Se caricate il runtime .NET WASM all’interno di un WebWorker, impostate dotnetSidecar = true durante l’inizializzazione per garantire il corretto avvio nel contesto worker.

Output AOT più piccolo con WasmStripILAfterAOT

L’altra novità di spicco per .NET WASM in .NET 10 è che WasmStripILAfterAOT è ora abilitato per default per le build AOT. Dopo la compilazione ahead-of-time dei metodi .NET in WebAssembly, il codice IL (Intermediate Language) originale non è più necessario a runtime: .NET 10 lo elimina dall’output pubblicato per default. In .NET 8 questa impostazione esisteva ma era disattivata.

Copilot Studio adotta una strategia di packaging più sofisticata. Per ottenere il meglio sia in termini di avvio rapido che di performance a regime, spedisce un singolo pacchetto NPM che contiene sia un motore JIT (per l’avvio veloce) che un motore AOT (per la massima velocità di esecuzione). A runtime, Copilot Studio carica JIT e AOT in parallelo: il motore JIT gestisce le interazioni iniziali, poi cede il controllo all’AOT non appena è pronto. I file identici tra i due modi vengono deduplicati per mantenere il pacchetto compatto.

Poiché WasmStripILAfterAOT produce assembly AOT che non corrispondono più alle controparti JIT, meno file possono essere condivisi tra i due motori:

• Su .NET 8: 59 file condivisi tra JIT e AOT.
• Su .NET 10: solo 22 file condivisi.

L’effetto netto sul pacchetto Copilot Studio è un aumento di dimensione di circa il 15%. In pratica l’impatto per gli utenti finali è contenuto, poiché il motore JIT resta quello scaricato ed eseguito per primo: l’interattività iniziale non è compromessa. Il download AOT è circa 6% (~200 ms) più lento su una LAN veloce e circa 17% (~5 secondi) più lento su una connessione 4G — tutto in background, dopo che l’app è già operativa.

I risultati di performance

I benefici a runtime superano ampiamente il costo in termini di packaging per i workload di Copilot Studio:

• ~20% più veloce nell’esecuzione alla prima chiamata (cold path).
• ~5% più veloce nelle chiamate successive (warm path).

I guadagni sono più visibili negli agenti grandi e complessi (“big bots”), dove il codice AOT compilato fa il grosso del lavoro. Per workload più semplici i miglioramenti sono comunque presenti ma più contenuti.

Come migrare la vostra app a .NET 10

Se avete un’applicazione Blazor o .NET WebAssembly su .NET 8, vale la pena provare .NET 10. Ecco i passi essenziali:

1. Aggiornate <TargetFramework> a net10.0 e aggiornate i riferimenti a pacchetti Microsoft.AspNetCore.*, Microsoft.Extensions.* e System.*.
2. Rimuovete eventuale logica personalizzata di rinomina degli asset o plumbing per l’integrity — il fingerprinting è ora integrato.
3. Se compilate in AOT, beneficerete automaticamente del nuovo default WasmStripILAfterAOT.

Se avete bisogno di supporto per l’aggiornamento, GitHub Copilot app modernization for .NET può analizzare la soluzione, pianificare l’aggiornamento e applicare le modifiche necessarie.

Conclusione

La migrazione di Copilot Studio a .NET 10 è l’ennesima conferma che ogni release di .NET porta WebAssembly a essere più veloce, più leggero e più semplice da distribuire. La rimozione dello script di fingerprinting personalizzato è un piccolo ma significativo esempio di come il framework stia maturando: quello che prima richiedeva custom tooling è ora built-in. Se state ancora su .NET 8, questo è il momento giusto per valutare il salto.

Fonte: Copilot Studio gets faster with .NET 10 on WebAssembly — Daniel Roth, .NET Blog

Copilot Studio gets faster with .NET 10 on WebAssembly - .NET Blog

Microsoft Copilot Studio recently upgraded its .NET WebAssembly engine to .NET 10. The migration was straightforward, simplified deployment, and delivered another round of meaningful performance gains for end users.

^{Daniel Roth (.NET Blog)}

Spcnet.it

2026-05-11 16:15:22

Durable Workflows nel Microsoft Agent Framework: da console app ad Azure Functions

Il Microsoft Agent Framework (MAF) è un framework open source multi-linguaggio pensato per costruire, orchestrare e distribuire agenti AI. Con le ultime versioni, il framework ha introdotto un modello di programmazione a workflow che permette di comporre più agenti e unità di lavoro in pipeline multi-step. In questo articolo vedremo come funziona questo modello, come aggiungere durabilità ai workflow e come fare il deploy su Azure Functions.

Il modello di programmazione a Workflow

Il sistema si basa su due concetti fondamentali: Executor e WorkflowBuilder.

Executor: l’unità di lavoro

Un Executor è la granularità minima del workflow. Riceve un input tipizzato, lo elabora e produce un output. Si crea estendendo Executor<TInput, TOutput>:

internal sealed class OrderLookup() : Executor<OrderCancelRequest, Order>("OrderLookup")
{
    public override async ValueTask<Order> HandleAsync(
        OrderCancelRequest message,
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        await Task.Delay(TimeSpan.FromMilliseconds(100), cancellationToken);
        return new Order(
            Id: message.OrderId,
            OrderDate: DateTime.UtcNow.AddDays(-1),
            IsCancelled: false,
            CancelReason: message.Reason,
            Customer: new Customer(Name: "Mario", Email: "mario@example.com"));
    }
}

internal sealed class OrderCancel() : Executor<Order, Order>("OrderCancel")
{
    public override async ValueTask<Order> HandleAsync(
        Order message, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        await Task.Delay(TimeSpan.FromMilliseconds(200), cancellationToken);
        return message with { IsCancelled = true };
    }
}

internal sealed class SendEmail() : Executor<Order, string>("SendEmail")
{
    public override ValueTask<string> HandleAsync(
        Order message, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        return ValueTask.FromResult(
            $"Email di cancellazione inviata per l'ordine {message.Id} a {message.Customer.Email}.");
    }
}

I parametri di tipo definiscono il contratto: TInput è ciò che riceve dal passo precedente, TOutput è ciò che passa al passo successivo. Il framework verifica la compatibilità dei tipi a compile time.

WorkflowBuilder: il grafo di esecuzione

Il WorkflowBuilder collega gli executor in un grafo diretto. Si definiscono gli archi tra executor e si ottiene un oggetto Workflow immutabile:

OrderLookup orderLookup = new();
OrderCancel orderCancel = new();
SendEmail sendEmail = new();

Workflow cancelOrder = new WorkflowBuilder(orderLookup)
    .WithName("CancelOrder")
    .WithDescription("Cancella un ordine e notifica il cliente")
    .AddEdge(orderLookup, orderCancel)
    .AddEdge(orderCancel, sendEmail)
    .Build();

Esecuzione in-process

Per eseguire il workflow senza dipendenze esterne si usa InProcessExecution.RunStreamingAsync. Restituisce uno StreamingRun che emette eventi man mano che ogni step completa:

var cancelRequest = new OrderCancelRequest(OrderId: "123", Reason: "Colore errato");

await using StreamingRun run = await InProcessExecution.RunStreamingAsync(
    cancelOrder, input: cancelRequest);

await foreach (WorkflowEvent evt in run.WatchStreamAsync())
{
    if (evt is ExecutorCompletedEvent completed)
        Console.WriteLine($"{completed.ExecutorId}: {completed.Data}");
}

Bastano i pacchetti NuGet Microsoft.Agents.AI e Microsoft.Agents.AI.Workflows. Nessuna infrastruttura, nessun Docker, solo una console app .NET.

Aggiungere la durabilità con DurableTask

L’esecuzione in-process perde lo stato se il processo termina. Per workflow di produzione — che devono sopravvivere ai riavvii, girare per ore e rimanere osservabili — si aggiunge il pacchetto Microsoft.Agents.AI.DurableTask:

dotnet add package Microsoft.Agents.AI.DurableTask --prerelease
dotnet add package Microsoft.DurableTask.Client.AzureManaged
dotnet add package Microsoft.DurableTask.Worker.AzureManaged
dotnet add package Microsoft.Extensions.Hosting

Il runtime durable fornisce:

• Esecuzione stateful e durabile: il workflow sopravvive ai riavvii del processo
• Checkpointing automatico: il progresso viene salvato dopo ogni step
• Esecuzione distribuita: gli executor possono girare su macchine diverse
• Orchestrazioni long-running: i workflow possono durare minuti, ore o giorni
• Osservabilità: dashboard integrata per monitorare e gestire le esecuzioni

Il punto chiave è che la definizione del workflow non cambia. Si usa lo stesso WorkflowBuilder, cambia solo l’hosting:

string dtsConnectionString = "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None";

IHost host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.ConfigureDurableWorkflows(
            workflowOptions => workflowOptions.AddWorkflow(cancelOrder),
            workerBuilder: builder => builder.UseDurableTaskScheduler(dtsConnectionString),
            clientBuilder: builder => builder.UseDurableTaskScheduler(dtsConnectionString));
    })
    .Build();

await host.StartAsync();

IWorkflowClient workflowClient = host.Services.GetRequiredService<IWorkflowClient>();
IAwaitableWorkflowRun run = (IAwaitableWorkflowRun)await workflowClient
    .RunAsync(cancelOrder, new OrderCancelRequest("12345", "Colore errato"));

string? result = await run.WaitForCompletionAsync<string>();
Console.WriteLine($"Workflow completato: {result}");

Per lo sviluppo locale si avvia il DTS Emulator in Docker:

docker run -d --name dts-emulator   -p 8080:8080 -p 8082:8082   mcr.microsoft.com/dts/dts-emulator:latest

La dashboard è disponibile su http://localhost:8082 e mostra la timeline di ogni executor, gli input/output per ciascun step e lo stato delle esecuzioni.

Fan-Out / Fan-In con agenti AI

Uno dei pattern più potenti è il fan-out/fan-in: più agenti AI elaborano lo stesso input in parallelo, poi un executor aggrega i risultati. MAF supporta l’uso diretto di agenti AI come executor tramite il metodo estensione AsAIAgent:

AIAgent physicist = chatClient.AsAIAgent(
    "Sei un esperto di fisica. Rispondi in 2-3 frasi concise.", "Physicist");

AIAgent chemist = chatClient.AsAIAgent(
    "Sei un esperto di chimica. Rispondi in 2-3 frasi concise.", "Chemist");

Workflow workflow = new WorkflowBuilder(parseQuestion)
    .WithName("ExpertReview")
    .AddFanOutEdge(parseQuestion, [physicist, chemist])
    .AddFanInBarrierEdge([physicist, chemist], aggregator)
    .Build();

Con il runtime durable, il fisico potrebbe eseguire su una VM e il chimico su un’altra. Se il processo si riavvia a metà esecuzione, gli agenti già completati non vengono rieseguiti grazie al checkpointing.

Deploy su Azure Functions

Per il deploy serverless si aggiunge il pacchetto Microsoft.Agents.AI.Hosting.AzureFunctions. I vantaggi:

• Scaling serverless: Azure Functions scala automaticamente in base al carico
• HTTP endpoint automatici: ogni workflow registrato ottiene un HTTP trigger, senza scrivere controller o routing
• Supporto MCP: i workflow possono essere esposti come MCP tool con un singolo flag, rendendoli scopribili da altri agenti AI
• Zero boilerplate: il pacchetto genera orchestratori e activity function automaticamente

Conclusioni

Il Microsoft Agent Framework propone un’astrazione pulita per costruire workflow di agenti AI: si definisce il grafo una volta sola, e si sceglie il runtime — in-process per lo sviluppo, durable per la produzione, Azure Functions per il serverless. La separazione netta tra definizione del workflow e modalità di hosting è il punto di forza dell’approccio: consente di passare da un prototipo locale a un’orchestrazione distribuita con modifiche minime al codice.

Il framework è open source e in evoluzione rapida. Il codice di esempio completo è disponibile nella repository GitHub del Microsoft Agent Framework.

Fonte originale: Durable Workflows in the Microsoft Agent Framework — .NET Blog, Shyju Krishnankutty

Durable Workflows in the Microsoft Agent Framework - .NET Blog

Build durable AI agent workflows with the Microsoft Agent Framework. Define once, run in-process or on Azure Functions with serverless scaling and durability.

^{Shyju Krishnankutty (.NET Blog)}

Spcnet.it

2026-05-11 15:14:34

Kubernetes v1.36: Sharded List and Watch lato server per cluster ad alta scala

Con la crescita dei cluster Kubernetes verso decine di migliaia di nodi, i controller che osservano risorse ad alta cardinalità come i Pod si scontrano con un limite di scalabilità ben preciso. Kubernetes v1.36 introduce in alpha una soluzione elegante: il Server-Side Sharded List and Watch (KEP-5866), che sposta il filtraggio upstream nell’API server, riducendo drasticamente il traffico verso ogni replica di un controller.

Il problema: scaling client-side

Alcuni controller, come kube-state-metrics, supportano già lo sharding orizzontale: ogni replica è assegnata a una porzione dello spazio delle chiavi e scarta gli oggetti che non le appartengono. Questo approccio funziona dal punto di vista della correttezza, ma non risolve il problema di scala:

• N repliche × stream completo: ogni replica deserializza ed elabora ogni evento, poi scarta ciò che non le compete
• La banda di rete scala con le repliche, non con la dimensione dello shard
• CPU sprecata: il costo di deserializzazione è sostenuto per la frazione scartata

In sintesi, scalare orizzontalmente il controller moltiplica il costo per replica invece di ridurlo.

La soluzione: sharding lato server

Il Server-Side Sharded List and Watch risolve il problema spostando il filtraggio nell’API server. Ogni replica comunica all’API server quale intervallo di hash è di sua competenza, e l’API server invia solo gli eventi corrispondenti.

La feature aggiunge un campo shardSelector a ListOptions. I client specificano un intervallo di hash tramite la funzione shardRange():

shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')

L’API server calcola un hash FNV-1a a 64 bit deterministico del campo specificato e restituisce solo gli oggetti il cui hash ricade nell’intervallo [start, end). Questo vale sia per le risposte di list che per i flussi di eventi watch.

La funzione di hash produce lo stesso risultato su tutte le istanze dell’API server, quindi la feature è sicura anche con più repliche dell’API server.

I percorsi di campo attualmente supportati sono object.metadata.uid e object.metadata.namespace.

Utilizzo pratico nei controller

I controller tipicamente usano informer per fare list e watch sulle risorse. Per fare lo sharding del carico, ogni replica inietta il shardSelector nelle ListOptions usate dai suoi informer tramite WithTweakListOptions:

import (
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/informers"
)

shardSelector := "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

factory := informers.NewSharedInformerFactoryWithOptions(
    client,
    resyncPeriod,
    informers.WithTweakListOptions(func(opts *metav1.ListOptions) {
        opts.ShardSelector = shardSelector
    }),
)

Per un deployment con 2 repliche, i selettori dividono lo spazio degli hash a metà:

// Replica 0: metà inferiore dello spazio di hash
"shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

// Replica 1: metà superiore dello spazio di hash
"shardRange(object.metadata.uid, '0x8000000000000000', '0x10000000000000000')"

Una singola replica può anche coprire range non contigui usando ||:

"shardRange(object.metadata.uid, '0x0000000000000000', '0x4000000000000000') || " +
"shardRange(object.metadata.uid, '0x8000000000000000', '0xc000000000000000')"

Verificare che il server supporti il selettore

Quando l’API server onora un shard selector, la risposta list include un campo shardInfo nel metadata della risposta che riporta il selettore applicato:

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "10245",
    "shardInfo": {
      "selector": "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"
    }
  },
  "items": [ ... ]
}

Se shardInfo è assente, il server non ha applicato il shard selector e il client ha ricevuto la collezione completa non filtrata. In questo caso, il client deve essere pronto a gestire il risultato completo — ad esempio applicando un filtraggio client-side per scartare gli oggetti fuori dal proprio shard.

Come abilitarla e stato della feature

Questa feature è in alpha in Kubernetes v1.36 e richiede di abilitare il feature gate ShardedListAndWatch sull’API server:

--feature-gates=ShardedListAndWatch=true

Non è ancora consigliata per ambienti di produzione, ma rappresenta un’opportunità preziosa per i team che gestiscono cluster di grandi dimensioni di iniziare i test e fornire feedback al SIG API Machinery.

Implicazioni architetturali

L’impatto di questa feature va oltre la semplice riduzione del traffico di rete. Cambia il modello mentale con cui si progettano controller scalabili:

• Efficienza reale: il costo per replica diminuisce proporzionalmente al numero di shard, invece di aumentare
• Scalabilità lineare: aggiungere repliche riduce effettivamente il carico su ciascuna
• Semplicità implementativa: lo sharding è dichiarativo — si specifica l’intervallo, l’API server fa il resto
• Compatibilità hash deterministica: FNV-1a garantisce distribuzione uniforme e risultati coerenti su più API server

Conclusioni

Il Server-Side Sharded List and Watch è una di quelle feature che risolvono un problema reale per chi opera cluster Kubernetes di grandi dimensioni. Spostare il filtraggio nell’API server è la scelta architetturalmente corretta: elimina il lavoro inutile alla radice invece di cercare di ottimizzarlo lato client.

Per i controller author e gli operatori di cluster grandi, vale la pena iniziare a sperimentare con questa feature sin da ora, contribuendo feedback al team di SIG API Machinery tramite il canale #sig-api-machinery su Kubernetes Slack.

Fonte originale: Kubernetes v1.36: Server-Side Sharded List and Watch — Kubernetes Blog, Jeffrey Ying

Kubernetes v1.36: Server-Side Sharded List and Watch

As Kubernetes clusters grow to tens of thousands of nodes, controllers that watch high-cardinality resources like Pods face a scaling wall.

^Kubernetes

Spcnet.it

2026-05-11 14:13:53

Costruire un MCP Server in C#: agenti AI con contesto reale usando il Model Context Protocol

Uno degli ostacoli più concreti nel lavorare con agenti AI è la mancanza di contesto reale: i modelli linguistici hanno una conoscenza “congelata” nel tempo e non hanno accesso ai vostri dati aziendali, alle vostre API interne o agli strumenti specifici del dominio. Il Model Context Protocol (MCP) nasce per risolvere esattamente questo problema, standardizzando il modo in cui applicazioni e agenti AI si scambiano contesto e strumenti. In questo articolo vediamo come i developer .NET possono costruire un MCP Server in C# e integrarlo con agenti AI come GitHub Copilot.

Cos’è il Model Context Protocol

MCP è un protocollo aperto — originariamente sviluppato da Anthropic e ora supportato da numerose aziende tech — che definisce un linguaggio comune tra agenti AI e endpoint specializzati. L’idea è semplice: un MCP Server espone tool (funzioni invocabili), resource (dati strutturati) e prompt (template riutilizzabili) che un agente AI può scoprire e usare dinamicamente. Il risultato è un’integrazione grounded e sicura, in cui l’agente sa cosa può fare e con quali dati lavorare.

Per i developer .NET c’è una buona notizia: esiste un SDK C# ufficiale per MCP che rende la costruzione di server e client MCP relativamente semplice, integrabile con il familiare ecosistema di Microsoft.Extensions.

Struttura base di un MCP Server in C#

Il punto di partenza è un’applicazione console .NET. Le dipendenze NuGet necessarie nel file .csproj sono:

<ItemGroup>
  <PackageReference Include="ModelContextProtocol" Version="*" />
  <PackageReference Include="Microsoft.Extensions.Hosting" Version="*" />
</ItemGroup>

Il pacchetto ModelContextProtocol fornisce le API per creare server e client MCP, mentre l’integrazione con Microsoft.Extensions.AI consente di collegare i tool a modelli AI tramite le astrazioni standard di .NET.

Definire i Tool con gli attributi MCP

La magia di MCP in C# passa attraverso due attributi principali: [McpServerToolType] applicato alla classe e [McpServerTool] applicato ai metodi. Ecco un esempio minimale con un tool Echo:

using ModelContextProtocol.Server;
using System.ComponentModel;

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Restituisce il messaggio ricevuto al mittente.")]
    public static string Echo(string message) => $"Hai detto: {message}";
}

L’attributo [Description] è fondamentale: il testo viene esposto all’agente AI come documentazione del tool, influenzando direttamente se e quando l’agente decide di invocarlo. Scrivete descrizioni chiare e precise.

Vediamo ora un tool più realistico che chiama un’API HTTP e restituisce dati JSON:

using System.ComponentModel;
using System.Net.Http.Json;
using System.Text.Json;
using ModelContextProtocol.Server;

[McpServerToolType]
public static class PostDataTool
{
    [McpServerTool, Description("Recupera un elenco di post di esempio dall'API.")]
    public static async Task<string> GetSamplePosts()
    {
        using var client = new HttpClient
        {
            BaseAddress = new Uri("https://jsonplaceholder.typicode.com")
        };
        var posts = await client.GetFromJsonAsync<List<Post>>("/posts");
        return JsonSerializer.Serialize(posts ?? new List<Post>());
    }
}

public class Post
{
    public int Id { get; set; }
    public string? Title { get; set; }
    public string? Body { get; set; }
}

Configurare il server in Program.cs

La configurazione del server MCP avviene in Program.cs, sfruttando il generic host di .NET:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = Host.CreateApplicationBuilder(args);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()   // trasporto stdio per uso locale / VS Code
    .WithToolsFromAssembly();     // scoperta automatica di tutti i [McpServerToolType]

await builder.Build().RunAsync();

Il trasporto stdio è il più comune per server locali e per l’integrazione con VS Code. Per scenari più avanzati (server HTTP remoti, autenticazione OAuth) l’SDK supporta trasporti SSE e altri meccanismi.

Registrare il server in VS Code

Per rendere il server MCP disponibile a VS Code e a GitHub Copilot, create un file .vscode/mcp.json nella root del progetto:

{
  "servers": {
    "MyMcpServer": {
      "type": "stdio",
      "command": "dotnet",
      "args": [
        "run",
        "--project",
        "/percorso/completo/MyMcpServer.csproj"
      ]
    }
  }
}

VS Code legge questo file e avvia automaticamente il server MCP quando necessario. I tool vengono esposti nella chat di GitHub Copilot con il prefisso #NomeServer.

Testare con l’MCP Inspector

Prima di integrare il server con un agente AI reale, è utile verificarne il funzionamento con l’MCP Inspector, uno strumento interattivo basato su Node.js con frontend React. Non richiede installazione: basta eseguire:

npx @modelcontextprotocol/inspector

Dall’Inspector potete connettervi al vostro server .NET, esplorare i tool esposti, invocarli con parametri di test e verificare le risposte JSON — tutto senza dover aprire VS Code.

Integrazione con GitHub Copilot in modalità agente

Con il server registrato in mcp.json, GitHub Copilot in modalità Agent può scoprire e invocare i vostri tool. Nella chat è sufficiente fare riferimento a un tool con #NomeServer_NomeTool, oppure chiedere all’agente di completare un compito e lasciare che sia lui a decidere quali tool usare.

L’agente chiederà conferma prima di eseguire qualsiasi tool (a meno che non abbiate abilitato l’approvazione automatica per la sessione), e il risultato viene usato come contesto per la risposta successiva. Questo pattern è particolarmente potente quando il tool restituisce dati specifici del dominio — configurazioni di sistema, query a database interni, stati di pipeline CI/CD — che il modello non potrebbe altrimenti conoscere.

Scenari pratici per developer .NET

Alcuni use case concreti per un MCP Server in C#:

• Query al database aziendale: esporre viste o stored procedure come tool MCP per permettere all’agente di rispondere a domande sui dati reali.
• Integrazione con sistemi interni: wrappare API REST o servizi WCF legacy come tool MCP senza riscrivere nulla.
• Automazione DevOps: tool per interrogare lo stato di pipeline, deployment o metriche di monitoring direttamente dalla chat dell’agente.
• Contesto di progetto: esporre convenzioni architetturali, ADR (Architecture Decision Records) o specifiche di dominio come risorse MCP per guidare la generazione di codice.

Conclusione

Il Model Context Protocol è ancora in evoluzione, ma le fondamenta sono solide e l’adozione sta crescendo rapidamente. Per i developer .NET, l’SDK C# rende la costruzione di MCP Server accessibile e naturale, senza allontanarsi dalle convenzioni del framework. Investire oggi nel capire MCP significa essere pronti quando gli agenti AI diventeranno parte integrante del workflow di sviluppo quotidiano — e quel momento è già più vicino di quanto sembri.

Fonti: MCP Magic: Building Tool-Enabled AI Agents with C# — Visual Studio Magazine; Build & Leverage MCP Servers in C# for AI-Driven Development — Uno Platform

Build & Leverage MCP Servers in C# for AI-Driven Development

Let's dive into how .NET developers can build MCP Servers and leverage them in AI workflows.

^{Sam Basu (Uno Platform)}

(in)sicurezza digitale

2026-05-11 14:19:22

UAT-8302: il nuovo APT cinese con arsenale condiviso che spia governi su tre continenti

Cisco Talos ha svelato UAT-8302, un gruppo APT con nexus cinese che condivide un toolkit malware con almeno sei altri threat actor legati a Pechino. Dalla fine del 2024 a oggi, il gruppo ha silenziosamente compromesso enti governativi in Sud America e Sud-Est Europa, usando una catena d’attacco modulare che combina backdoor .NET personalizzate, strumenti Rust e impianti RAT avanzati — tutti con radici nell’ecosistema cyber-offensivo della Cina.

Un gruppo nuovo, un arsenale già conosciuto

Il 5 maggio 2026, i ricercatori di Cisco Talos hanno pubblicato l’analisi completa di UAT-8302, un cluster di attività che operava nell’ombra da oltre diciotto mesi prima di essere formalmente identificato. Ciò che rende questo threat actor particolarmente interessante non è solo chi ha colpito, ma come lo ha fatto: il gruppo ha fatto largo uso di malware già documentato in campagne di altri attori cinesi, costruendo un arsenale di strumenti condivisi che suggerisce un ecosistema coordinato tra hacking group legati allo Stato.

Talos valuta con alto grado di confidenza che UAT-8302 sia un APT a nexus cinese il cui obiettivo primario è ottenere e mantenere accessi persistenti e a lungo termine presso entità governative e organizzazioni correlate in tutto il mondo. Le vittime documentate includono ministeri e agenzie governative in Sud America (attive dalla fine del 2024) e Europa sud-orientale (documentate nel 2025).

La catena d’infezione: dall’exploit iniziale alla persistenza

I ricercatori sospettano che UAT-8302 sfrutti vulnerabilità zero-day e N-day in applicazioni web per ottenere l’accesso iniziale, anche se i vettori precisi non sono stati confermati in tutti i casi analizzati. Una volta ottenuto il foothold, la kill chain si sviluppa con metodologia da manuale per operazioni di spionaggio a lungo termine:

• Ricognizione estensiva: mapping della rete, enumerazione degli host e dei servizi esposti usando lo scanner open-source gogo, strumento popolare nell’ecosistema offensivo sinofono.
• Lateral movement: sfruttamento di Impacket per movimento laterale, accesso a credenziali e persistenza attraverso protocolli Windows.
• Distribuzione del payload finale: deployment di una o più famiglie malware personalizzate a seconda del target e dell’obiettivo dell’operazione.

L’arsenale malware: cinque famiglie per un unico attore

L’elemento più significativo di UAT-8302 è la varietà e la sofisticazione del suo toolkit. Il gruppo ha impiegato almeno cinque famiglie malware distinte, molte delle quali condivise con altri gruppi a nexus cinese:

NetDraft / NosyDoor

NetDraft (noto anche come NosyDoor) è una backdoor .NET che Talos descrive come una variante portata in C# del malware FINALDRAFT (alias Squidoor), sviluppato originariamente dal cluster Jewelbug/REF7707/CL-STA-0049. La caratteristica tecnica più rilevante è il suo meccanismo di C2: NetDraft utilizza la Microsoft Graph API per comunicare con il suo server di comando e controllo, usando OneDrive come canale covert. Un eseguibile legittimo viene usato per side-load una DLL malevola, che a sua volta decodifica NetDraft da un file di dati allegato ed esegue il codice nel contesto del processo corrente — una tecnica che rende l’impianto invisibile a molti prodotti EDR non configurati per monitorare l’uso anomalo delle API Microsoft.

SNOWRUST e VShell

Talos ha identificato SNOWRUST, una variante Rust di SNOWLIGHT, come stager di secondo livello. SNOWRUST decodifica ed esegue il shellcode di SNOWLIGHT incorporato per scaricare il payload finale — VShell (alias VSHELL) — da un server C2 in formato XOR-encoded. VShell è un RAT (Remote Access Trojan) documentato in numerose campagne cinesi precedenti e offre capacità complete di controllo remoto della macchina vittima.

CloudSorcerer v3.0

CloudSorcerer (versione 3.0) è una famiglia malware che Kaspersky aveva già documentato nel 2024 in attacchi contro entità governative russe. La comparsa della stessa famiglia in operazioni di UAT-8302 contro target diversi suggerisce non solo condivisione di codice, ma potenzialmente condivisione di infrastruttura o almeno di sviluppatori tra gruppi diversi dell’ecosistema APT cinese.

SNAPPYBEE / DeedRAT e ZingDoor

Le famiglie SNAPPYBEE (noto anche come DeedRAT) e ZingDoor sono state deployate congiuntamente in alcune campagne. SNAPPYBEE è una backdoor modulare con capacità di caricamento di plugin, già associata ad altri gruppi cinesi. ZingDoor, scritto in Go, completa il quadro con funzionalità di tunneling e proxy che facilitano la creazione di canali C2 resilienti.

Un ecosistema APT condiviso: la vera novità

Il dato più preoccupante che emerge dall’analisi Talos riguarda il modello operativo sottostante: UAT-8302 condivide il proprio arsenale con almeno sei altri gruppi APT a nexus cinese. Questo non è solo un’indicazione di affiliazione statale, ma suggerisce un’infrastruttura di sviluppo e distribuzione malware centralizzata, probabilmente gestita da un’entità governativa — plausibilmente correlata al Ministero della Sicurezza dello Stato (MSS) o all’Esercito Popolare di Liberazione (PLA).

Questa condivisione ha implicazioni pratiche per i difensori: il rilevamento di una singola famiglia (ad es. NetDraft) in un’organizzazione non significa necessariamente stare di fronte a UAT-8302 — potrebbe essere qualsiasi altro degli attori che usano lo stesso toolkit. Questo rende l’attribuzione più difficile e richiede un approccio di detection basato sul comportamento piuttosto che sulle singole firme malware.

Implicazioni geopolitiche

La scelta dei target — governi sudamericani e dell’Europa sud-orientale — riflette le priorità strategiche della Cina in due aree geografiche di crescente importanza. Il Sud America è al centro degli interessi economici e diplomatici di Pechino (BRI, accordi bilaterali, infrastrutture). L’Europa sud-orientale, con paesi come Serbia, Bulgaria e Romania, rappresenta un nodo critico per le ambizioni cinesi di influenza in Europa orientale, specialmente in un contesto di tensioni con NATO e UE.

Indicatori di compromissione (IoC)

Cisco Talos ha pubblicato IoC completi nel report ufficiale. Di seguito i principali indicatori tecnici associati alle famiglie malware di UAT-8302:

# Famiglie malware associate a UAT-8302
NetDraft / NosyDoor  — .NET backdoor, C2 via MS Graph API / OneDrive
SNOWRUST             — stager Rust, variante di SNOWLIGHT
VShell / VSHELL      — RAT multi-funzione, C2 XOR-encoded payload
CloudSorcerer v3.0   — backdoor condivisa con campagne Russia-targeting
SNAPPYBEE / DeedRAT  — backdoor modulare Go, plugin-based
ZingDoor             — tunneling/proxy Go-based

# Tecniche MITRE ATT&CK osservate
T1190 — Exploit Public-Facing Application (initial access)
T1574.002 — DLL Side-Loading (NetDraft loader)
T1071.001 — Application Layer Protocol: Web (MS Graph C2)
T1027 — Obfuscated Files or Information
T1078 — Valid Accounts (post-compromise credential abuse)
T1021 — Remote Services / Lateral Movement (Impacket)
T1082 — System Information Discovery
T1083 — File and Directory Discovery

# Tool open-source utilizzati
gogo      — scanner di rete popolare nell'ecosistema offensivo sinofono
Impacket  — toolkit Python per SMB/Kerberos/lateral movement

Due righe per i difensori

Dati i vettori e le tecniche osservate, le organizzazioni governative e le infrastrutture critiche dovrebbero prioritizzare le seguenti misure difensive. In primo luogo, monitorare il traffico verso Microsoft Graph API e OneDrive per accessi anomali da processi di sistema o applicazioni non standard — NetDraft usa questo canale per mascherare il C2 tra traffico legittimo. In secondo luogo, implementare controlli di DLL sideloading verificando che gli eseguibili firmati non carichino DLL da percorsi non standard. In terzo luogo, rilevare l’uso di Impacket attraverso il monitoraggio di traffico SMB/DCE-RPC anomalo, autenticazioni Kerberos insolite e creazione di servizi remoti. Infine, tenere aggiornate le applicazioni web esposte su internet, poiché UAT-8302 sfrutta CVE noti e zero-day per l’accesso iniziale.

Il report completo di Cisco Talos con IoC estesi è disponibile su blog.talosintelligence.com.

UAT-8302 and its box full of malware

Cisco Talos is disclosing UAT-8302, a sophisticated, China-nexus advanced persistent threat (APT) group targeting government entities in South America since at least late 2024 and government agencies in southeastern Europe in 2025.

^{Jungsoo An (Cisco Talos Blog)}

(in)sicurezza digitale

2026-05-11 15:20:51

ShinyHunters viola Canvas: 275 milioni di studenti nel mirino nel più grande data breach educativo della storia

Il gruppo di estorsione digitale ShinyHunters ha violato Instructure, la società madre della piattaforma di e-learning Canvas, sottraendo 3,65 terabyte di dati relativi a circa 275 milioni di studenti e insegnanti distribuiti in 8.809 istituzioni scolastiche in tutto il mondo. L’attacco, rivendicato il 3 maggio 2026 e tuttora in evoluzione con un ultimatum di riscatto fissato al 12 maggio, è già classificato come il più grande data breach della storia nel settore dell’istruzione — con implicazioni che vanno ben oltre la semplice esfiltrazione di dati anagrafici.

La timeline dell’attacco

La prima anomalia rilevata è datata 29 aprile 2026, quando alcuni strumenti di Canvas iniziarono a mostrare malfunzionamenti. Il giorno successivo, Instructure confermò internamente una violazione criminale in corso e ingaggiò esperti forensi esterni. Il 3 maggio, ShinyHunters rivendicò pubblicamente l’attacco su forum underground, pubblicando campioni dei dati come prova. Il 7 maggio — in un’escalation particolarmente aggressiva — il gruppo defacciò le pagine di login di numerose istituzioni scolastiche clienti di Canvas, sostituendole con un messaggio di estorsione visibile a milioni di studenti nel pieno del periodo degli esami di fine anno accademico.

La scelta del momento non è casuale: colpire a maggio, durante le sessioni d’esame universitarie negli USA, nel Regno Unito e in Australia, massimizza la pressione mediatica e istituzionale, aumentando la probabilità che la vittima ceda alle richieste di riscatto.

Il vettore d’attacco: account Free-For-Teacher e abuso OAuth

Secondo le prime ricostruzioni rese note da Instructure, il punto d’ingresso iniziale è stato un’vulnerabilità legata agli account Free-For-Teacher, un tipo di account gratuito offerto da Canvas agli insegnanti per uso personale o sperimentale, con autorizzazioni API più ampie rispetto agli account studente standard. ShinyHunters, noto per la sua expertise nell’abuso di piattaforme cloud enterprise attraverso tecniche di vishing, furto di credenziali e abuso OAuth, ha sfruttato questo vettore per ottenere token di accesso con privilegi elevati all’infrastruttura di Instructure.

Il modus operandi del gruppo in operazioni precedenti — tra cui le violazioni di Snowflake (2024) e Salesforce — segue uno schema consolidato: compromissione di account cloud di terze parti con accesso API, escalation dei privilegi tramite token OAuth mal configurati o rubati, esfiltrazione massiva di dati in formato strutturato (database dump, CSV), e infine doppia estorsione con pubblicazione progressiva di campioni come leva negoziale.

La scala senza precedenti: chi è stato colpito

Con 8.809 istituzioni coinvolte in almeno otto Paesi — Stati Uniti, Canada, Regno Unito, Nuova Zelanda, Australia, Svezia, Paesi Bassi e Singapore — il breach Canvas supera qualsiasi precedente nella storia delle violazioni del settore education. Tra le istituzioni nominalmente esposte figurano MIT, Oxford, Duke University, University of Pennsylvania e centinaia di altre università di primo piano a livello globale.

I dati sottratti confermati includono: nomi e cognomi, indirizzi email istituzionali, numeri di matricola, iscrizioni ai corsi e — particolarmente sensibile — messaggi privati scambiati tra studenti e docenti. Instructure ha dichiarato che non risultano compromesse password, date di nascita, documenti d’identità governativi o informazioni finanziarie, ma l’entità dell’esfiltrazione — 3,65 TB — suggerisce che il quadro completo dei dati sottratti non sia ancora del tutto chiaro.

ShinyHunters: il profilo del gruppo

ShinyHunters è un gruppo di estorsione digitale attivo almeno dal 2020, noto per operazioni ad alto impatto contro piattaforme cloud. Nel curriculum del gruppo figurano violazioni di Tokopedia (91 milioni di record), Wattpad, Mathway, Pluto TV, e la già citata campagna Snowflake del 2024 che colpì centinaia di aziende Fortune 500 tramite furto di credenziali di clienti cloud. Il gruppo non dispone di una struttura ransomware con cifratura dei file: la loro arma primaria è la minaccia di pubblicazione dei dati, amplificata da azioni di defacement visibili (come le pagine login di Canvas sostituite) che generano massima pressione mediatica.

La deadline del 12 maggio 2026 per il pagamento del riscatto è in scadenza nei prossimi giorni. Non è noto l’importo richiesto. Instructure non ha confermato né smentito trattative in corso.

Cosa devono fare istituzioni e utenti

Le istituzioni che utilizzano Canvas devono agire immediatamente su più fronti: rotazione di tutte le API key Canvas, revoca e re-emissione di tutti i token OAuth attivi, verifica delle integrazioni SSO con provider di identità istituzionali, e audit degli account Free-For-Teacher attivi nella propria istanza. Per gli utenti finali, il rischio principale nelle settimane successive sarà quello di campagne di phishing personalizzate, che sfrutteranno i dati esfiltrati (email istituzionali, nomi dei corsi, messaggi privati) per costruire lure altamente credibili. La ricezione di email apparentemente provenienti da docenti, segreterie o piattaforme universitarie deve essere trattata con massima cautela per almeno i prossimi 90 giorni.

## Indicatori e dati chiave del breach Canvas/ShinyHunters
Data prima anomalia: 29 aprile 2026
Data rivendicazione: 3 maggio 2026
Data defacement login pages: 7 maggio 2026
Deadline riscatto: 12 maggio 2026
Volume dati sottratti: ~3,65 TB
Record compromessi (claim ShinyHunters): ~275 milioni
Istituzioni coinvolte: 8.809 (in 8+ Paesi)
Vettore iniziale: account Free-For-Teacher + abuso OAuth API
Dati confermati compromessi: nome, email, student ID, messaggi privati
Dati NON compromessi (Instructure): password, date nascita, ID gov., dati finanziari

## Azioni immediate per amministratori Canvas
1. Ruotare tutte le Canvas API key
2. Revocare e re-emettere i token OAuth attivi
3. Verificare integrazioni SSO e provider identità
4. Auditare account Free-For-Teacher attivi
5. Abilitare MFA per tutti gli account amministrativi

Spcnet.it

2026-05-11 12:12:11

Quando i prompt diventano shell: vulnerabilità RCE negli AI agent framework

Gli agenti AI hanno cambiato radicalmente il modello di minaccia delle applicazioni basate su LLM. Finché un modello si limita a generare testo, le vulnerabilità rimangono nel dominio del contenuto. Ma non appena lo si dota di plugin (o tool) — lettura di file, query su database, esecuzione di script — il perimetro si espande. Una prompt injection non è più un problema di risposta inappropriata: può diventare un primitivo di esecuzione di codice arbitrario.

Il team di Microsoft Defender Security Research ha pubblicato un’analisi dettagliata di due vulnerabilità critiche scoperte in Semantic Kernel, il framework open source di Microsoft per la costruzione di agenti AI. Entrambe le vulnerabilità — già corrette — avrebbero consentito a un attaccante di ottenere RCE (Remote Code Execution) sul sistema che eseguiva l’agente, partendo semplicemente da un prompt malevolo.

Il problema di fondo: i framework AI si fidano troppo dell’output del modello

I framework come Semantic Kernel, LangChain e CrewAI agiscono come “sistema operativo” per gli agenti AI: astraggono l’orchestrazione del modello, gestiscono il routing verso i plugin e traducono il linguaggio naturale in chiamate a funzione strutturate. Questa convenienza ha un costo nascosto: ogni vulnerabilità nel modo in cui il framework mappa l’output del modello verso i tool di sistema porta un rischio sistemico.

Il modello AI stesso non è il problema — si comporta esattamente come progettato, parsando il linguaggio naturale in schemi di tool calling. Il problema sta nel fatto che il framework e i tool si fidano ciecamente dei dati così ottenuti.

CVE-2026-26030: In-Memory Vector Store e la pericolosità di eval()

La prima vulnerabilità riguarda il Search Plugin di Semantic Kernel quando usa l’In-Memory Vector Store con la configurazione predefinita.

Lo scenario di attacco richiede due condizioni:

1. L’attaccante deve avere un vettore di prompt injection — ovvero la capacità di influenzare gli input dell’agente
2. L’agente deve usare il Search Plugin con l’In-Memory Vector Store come backend

Radice tecnica del problema

La funzione di filtro predefinita dell’In-Memory Vector Store è implementata come espressione lambda Python eseguita tramite eval(). Per una ricerca tipica come “Find hotels in Paris”, il filtro generato è:

new_filter = "lambda x: x.city == 'Paris'"

Il parametro kwargs[param.name] — il valore di city — è controllato dall’output del modello AI, senza alcuna sanitizzazione. È un classico injection sink. Chiudendo la stringa e aggiungendo codice Python arbitrario, l’attaccante può trasformare una semplice query in payload eseguibile.

Il tentativo di mitigazione con blocklist — e il suo fallimento

I developer di Semantic Kernel avevano anticipato il rischio e implementato una blocklist che parsava il filtro in un Abstract Syntax Tree (AST) prima dell’esecuzione. Il validator:

• Permetteva solo espressioni lambda
• Rifiutava import e definizioni di classi
• Cercava identificatori pericolosi (eval, exec, open, __import__…)
• Eseguiva il codice in un ambiente ristretto con __builtins__ svuotati

I ricercatori hanno trovato un bypass completo. Il payload di exploit sfruttava quattro debolezze architetturali della blocklist:

1. Nomi mancanti nella blocklist: attributi come __name__, load_module, system e la classe BuiltinImporter non erano presenti nella lista nera
2. Il check strutturale passava: il payload era avvolto in una lambda valida, quindi isinstance(tree.body, ast.Lambda) restituiva True
3. __builtins__ vuoto era irrilevante: il payload partiva da tuple(), che esiste indipendentemente dall’ambiente dei builtin, e risaliva la gerarchia dei tipi Python per raggiungere funzionalità pericolose senza mai chiamare una builtin direttamente
4. Nessun controllo su ast.Subscript: anche se un nome bloccato fosse stato necessario, si sarebbe potuto accedere con notazione bracket (obj['__class__'] invece di obj.__class__), creando un nodo ast.Subscript ignorato dalla validazione

Il risultato pratico: un singolo prompt malevolo era sufficiente per lanciare calc.exe sul sistema che eseguiva l’agente, senza exploit del browser, allegati malevoli o memory corruption.

La lezione generale: le blocklist nei linguaggi dinamici sono fragili

Python (e linguaggi dinamici in generale) offre troppa flessibilità per essere gestita efficacemente con una lista nera. La gerarchia di classi del runtime, la riflessione, i dunders e le notazioni alternative rendono qualsiasi blocklist incompleta per definizione.

CVE-2026-25592: scrittura arbitraria di file tramite SessionsPythonPlugin

La seconda vulnerabilità riguarda il SessionsPythonPlugin, che permette agli agenti di eseguire codice Python in sessioni di Azure Container Apps. Il plugin accetta un nome di file come parametro controllato dall’LLM — senza validazione del percorso — e lo usa per scrivere file nel filesystem del container. Attraverso path traversal (es. ../../etc/cron.d/payload), un attaccante con accesso al vettore di prompt injection potrebbe scrivere file arbitrari in posizioni sensibili del sistema.

La mitigazione applicata da Semantic Kernel

Dopo la responsible disclosure al MSRC, il team di Semantic Kernel ha implementato una correzione multilivello per CVE-2026-26030, sostituendo la blocklist con un approccio allowlist a quattro strati:

1. Allowlist dei tipi AST: solo costrutti sicuri sono permessi — comparazioni, logica booleana, aritmetica, letterali
2. Allowlist delle chiamate a funzione: anche i nodi di chiamata AST permessi vengono verificati per assicurarsi che invochino solo funzioni sicure
3. Blocklist degli attributi pericolosi: traversata della gerarchia di classi bloccata esplicitamente (__class__, __subclasses__)
4. Restrizione sui nodi Name: solo il parametro della lambda (es. x) è accettabile come identificatore; riferimenti a os, eval, type e simili vengono rifiutati

Come sapere se si è vulnerabili

Si è esposti a CVE-2026-26030 se:

• Si usa il pacchetto Python semantic-kernel
• La versione del framework è precedente alla 1.39.4
• L’agente usa l’In-Memory Vector Store con funzionalità di filtro abilitata come backend per il Search Plugin

Per verificare la versione installata:

pip show semantic-kernel

Per aggiornare:

pip install --upgrade semantic-kernel

Raccomandazioni per gli sviluppatori di agenti AI

Questa ricerca offre lezioni importanti per chiunque stia costruendo applicazioni con agenti AI:

• Non trattare l’output del modello come dati fidati: qualsiasi valore che passa dal modello AI a un tool deve essere trattato come input non fidato, validato e sanitizzato come si farebbe con input da un utente esterno
• Preferire allowlist alle blocklist: nelle valutazioni di codice dinamico, le blocklist sono intrinsecamente incomplete. Un allowlist di costrutti permessi è molto più robusto
• Evitare eval() con input derivati dall’LLM: se il requisito è eseguire espressioni dinamiche, usare AST parsing con validazione rigorosa o, meglio, un motore di espressioni dedicato con capacità limitate
• Applicare il principio del minimo privilegio: i plugin degli agenti dovrebbero avere solo le autorizzazioni strettamente necessarie; un plugin che scrive file non dovrebbe mai avere accesso all’intero filesystem
• Monitorare i vettori di prompt injection: qualsiasi fonte esterna che l’agente legge (email, documenti, pagine web, risultati di ricerca) è un potenziale vettore di attacco
• Tenere aggiornati i framework: le vulnerabilità nei framework AI si stanno moltiplicando rapidamente; aggiornare regolarmente e seguire i bollettini di sicurezza dei vendor è essenziale

Un challenge per mettersi alla prova

Microsoft ha anche pubblicato un CTF challenge interattivo che permette di testare l’exploit su un agente Semantic Kernel di esempio in modo sicuro e controllato. È un ottimo modo per capire concretamente il vettore di attacco senza rischiare sistemi reali.

Conclusione

La transizione degli agenti AI da generatori di testo a sistemi che operano attivamente sull’infrastruttura richiede un cambio di mentalità nella sicurezza. Le vulnerabilità come CVE-2026-26030 e CVE-2026-25592 mostrano che i rischi sono reali e concreti: un prompt malevolo può diventare RCE. Aggiornare Semantic Kernel alla versione 1.39.4 o superiore è la priorità immediata; rivedere l’architettura dei propri agenti alla luce del principio di minimo privilegio è il passo successivo.

Microsoft ha annunciato una serie di ricerche simili su altri framework AI (LangChain, CrewAI e altri) — ulteriori pubblicazioni sono previste nelle prossime settimane.

Fonte: When prompts become shells: RCE vulnerabilities in AI agent frameworks — Microsoft Defender Security Research Team (7 maggio 2026)

When prompts become shells: RCE vulnerabilities in AI agent frameworks | Microsoft Security Blog

New research exposes how prompt injection in AI agent frameworks can lead to remote code execution. Learn how these vulnerabilities work, what’s impacted, and how to secure your agents.

^{Microsoft Defender Security Research Team (Microsoft Security Blog)}

(in)sicurezza digitale

2026-05-11 12:17:30

DAEMON Tools compromesso: supply chain attack dal sito ufficiale con backdoor QUIC RAT e 100+ paesi colpiti

Si parla di:
Toggle

Dal 8 aprile 2026, chiunque abbia scaricato DAEMON Tools dal sito ufficiale ha potuto ricevere un installer trojanizzato — firmato digitalmente dal produttore — che installa silenziosamente una backdoor con capacità di comunicazione su sette protocolli diversi, tra cui QUIC e HTTP/3. Kaspersky ha svelato l’operazione a maggio: migliaia di tentativi di infezione in oltre 100 paesi, con targeting chirurgico su enti governativi, scientifici e industriali in una seconda fase. Sullo sfondo, i ricercatori puntano verso un attore di lingua cinese.

Il vettore d’attacco: il sito ufficiale come arma

DAEMON Tools è uno dei software di emulazione dischi più diffusi al mondo, con decine di milioni di utenti. La sua ubiquità lo rende un bersaglio ideale per un attacco supply chain: compromettere il sito ufficiale significa trasformare uno strumento di fiducia in un vettore di distribuzione malware su scala globale.

Secondo l’analisi pubblicata da Kaspersky su Securelist, i ricercatori hanno identificato che le versioni da 12.5.0.2421 a 12.5.0.2434 di DAEMON Tools distribuite dal sito ufficiale del produttore — AVB Disc Soft — contenevano componenti binari modificati con codice malevolo. La finestra di compromissione è iniziata almeno dall’8 aprile 2026 e l’attacco era ancora attivo al momento della divulgazione pubblica avvenuta intorno al 6 maggio 2026.

Anatomia tecnica: tre binari compromessi, un’unica catena d’attacco

Gli attaccanti hanno manomesso tre componenti specifici all’interno del pacchetto di installazione:

• DTHelper.exe — componente helper principale del software
• DiscSoftBusServiceLite.exe — servizio di sistema lanciato all’avvio del sistema
• DTShellHlp.exe — helper per le funzioni di shell integration

L’elemento più insidioso è che tutti e tre i file risultano ancora firmati digitalmente con certificati validi di AVB Disc Soft. Questo significa che i controlli di firma digitale standard — inclusi quelli di Windows SmartScreen e la maggior parte degli antivirus basati su reputazione — non avrebbero segnalato nulla di anomalo al momento dell’installazione. Solo una soluzione EDR con analisi comportamentale avanzata avrebbe potuto identificare l’attività malevola in fase di esecuzione.

Ogni volta che uno di questi binari viene lanciato — e dato che DiscSoftBusServiceLite.exe è un servizio Windows, ciò avviene automaticamente ad ogni avvio del sistema — la backdoor si attiva e stabilisce comunicazione con il server C2.

Il payload di prima fase: information stealer silenzioso

Nella maggior parte dei sistemi infetti, l’attivazione della backdoor comporta innanzitutto l’esecuzione di un info-stealer di prima fase che raccoglie i seguenti dati di profilazione del sistema:

• Indirizzo MAC e hostname della macchina
• Software installato ed elenco processi in esecuzione
• Configurazione di rete (interfacce, IP, gateway)
• Locale di sistema e impostazioni geografiche

Questi dati vengono trasmessi al server C2 e con ogni probabilità utilizzati per selezione e triage delle vittime: non tutti i sistemi infetti ricevono il payload avanzato. Kaspersky ha rilevato che solo un numero limitato di macchine — stimato in una dozzina di sistemi su migliaia di infezioni — ha ricevuto il secondo stage, il che indica targeting altamente selettivo.

QUIC RAT: la backdoor di secondo livello

I sistemi selezionati ricevono QUIC RAT, un impianto avanzato che prende il nome dal protocollo di trasporto di Google su cui si basa come canale C2 preferenziale. La caratteristica tecnica distintiva di QUIC RAT è la sua resilienza nei canali di comunicazione: il malware supporta ben sette protocolli C2 distinti, da usare in modo adattivo a seconda dell’ambiente della vittima:

• HTTP e HTTPS — per ambienti con proxy web standard
• UDP e TCP raw — per connessioni dirette a bassa latenza
• WSS (WebSocket Secure) — per bypassare firewall che bloccano connessioni non-HTTP
• QUIC (HTTP/3 su UDP) — il protocollo eponimo, difficile da ispezionare con DPI tradizionale
• DNS — per ambienti con filtering aggressivo, usando richieste DNS come canale covert

Questa flessibilità rende QUIC RAT particolarmente difficile da bloccare con soluzioni di network security tradizionali: anche in ambienti con firewalling aggressivo, il malware può adattarsi dinamicamente al protocollo consentito.

Sul fronte delle funzionalità offensive, QUIC RAT è capace di iniettare payload malevoli nei processi notepad.exe e conhost.exe — due processi legittimi di Windows particolarmente adatti al process injection per la loro ubiquità e bassa visibilità in ambienti non monitorati.

La scala dell’operazione

A partire dall’inizio di aprile 2026, Kaspersky ha rilevato diverse migliaia di tentativi di installazione di payload malevoli attraverso DAEMON Tools compromesso, con vittime distribuite in oltre 100 paesi e territori. La distribuzione geografica è significativa: il maggior numero di infezioni è stato rilevato in Russia, Brasile, Turchia, Spagna, Germania, Francia, Italia e Cina.

La composizione delle vittime rivela la natura dell’operazione: circa il 90% dei sistemi infetti appartiene a utenti privati, mentre il restante 10% corrisponde a sistemi aziendali e organizzativi. È plausibile che la grande massa di utenti privati funzionasse come copertura e rumore di fondo, mentre gli attaccanti erano in realtà interessati alla percentuale aziendale — che in termini assoluti, su migliaia di infezioni, rappresenta comunque centinaia di potenziali target di interesse.

Kaspersky ha specificato che tra le organizzazioni colpite dalla seconda fase con QUIC RAT figurano enti governativi, istituti di ricerca scientifica e aziende manifatturiere.

Attribuzione: tracce verso un attore sinofono

Kaspersky non attribuisce formalmente l’attacco a un gruppo specifico, ma i ricercatori hanno rilevato stringhe in lingua cinese nel payload di prima fase. Questo, combinato con la sofisticazione operativa dell’attacco, la selezione dei target di seconda fase e la natura delle vittime prioritizzate, suggerisce un attore di lingua cinese — potenzialmente un gruppo APT state-sponsored, anche se al momento non è possibile escludere un cybercriminale con capacità avanzate.

Il pattern di targeting selettivo e il profilo delle vittime di alto valore sono però più coerenti con operazioni di intelligence che con motivazioni puramente economiche.

Indicatori di compromissione (IoC)

# Versioni DAEMON Tools compromesse
Versioni affette: 12.5.0.2421 — 12.5.0.2434

# Binari manomessi (firmati da AVB Disc Soft)
DTHelper.exe
DiscSoftBusServiceLite.exe
DTShellHlp.exe

# Protocolli C2 usati da QUIC RAT
HTTP, HTTPS, UDP, TCP, WSS (WebSocket Secure), QUIC/HTTP3, DNS

# Tecniche MITRE ATT&CK
T1195.002 — Supply Chain Compromise: Software Supply Chain
T1553.002 — Subvert Trust Controls: Code Signing (signed malicious binaries)
T1071     — Application Layer Protocol (multi-protocol C2)
T1572     — Protocol Tunneling (QUIC/DNS channels)
T1055     — Process Injection (notepad.exe / conhost.exe)
T1082     — System Information Discovery (first-stage profiling)
T1018     — Remote System Discovery

# Nota: IoC hash completi disponibili su Securelist
# https://securelist.com/daemon-tools-backdoor/

Come verificare se si è stati colpiti

Chi ha installato o aggiornato DAEMON Tools tra aprile e inizio maggio 2026 dovrebbe verificare urgentemente la versione installata. Se rientra nell’intervallo 12.5.0.2421-12.5.0.2434, è necessario procedere come segue: disinstallare immediatamente DAEMON Tools e aggiornare all’ultima versione disponibile dal sito ufficiale (già corretta al momento della disclosure). Eseguire una scansione completa con una soluzione EDR aggiornata, monitorando in particolare attività anomale di notepad.exe e conhost.exe. Verificare la presenza di connessioni insolite su porta UDP 443 (QUIC) o traffico DNS anomalo verso domini non riconosciuti. Controllare il registro di sistema per servizi sospetti aggiunti da DiscSoftBusServiceLite.exe o varianti.

Il report tecnico completo di Kaspersky con hash SHA256 e IoC di rete è disponibile su Securelist. La press release ufficiale è su kaspersky.com.

Securelist | Kaspersky’s threat research and reports

The Securelist blog houses Kaspersky’s threat intelligence reports, malware research, APT analysis and statistics

^{Kaspersky (Securelist)}

(in)sicurezza digitale

2026-05-10 10:07:02

Silver Fox lancia ABCDoor: spear phishing con loader Rust personalizzato contro India e Russia, nuova backdoor Python in campo

Tra dicembre 2025 e febbraio 2026, il gruppo APT di matrice cinese noto come Silver Fox ha lanciato due ondate coordinate di spear phishing contro organizzazioni in India e Russia, sfruttando esche a tema fiscale costruite ad hoc per ciascun paese. Il vettore tecnico è un loader Rust modificato — una versione bespoke del framework open source RustSL — che distribuisce ValleyRAT (aka Winos 4.0) insieme a una backdoor Python finora inedito, denominato ABCDoor. La ricerca è stata pubblicata da Kaspersky Securelist e ripresa da The Hacker News il 4 maggio 2026. Più di 1.600 email di phishing sono state registrate tra inizio gennaio e inizio febbraio, con organizzazioni impattate nei settori industriale, consulenza, retail e trasporti.

Il profilo di Silver Fox: doppio binario tra cybercrime e spionaggio

Silver Fox è un gruppo APT cinese attivo almeno dal 2024, documentato inizialmente per campagne contro obiettivi in Cina, poi espanso verso Taiwan, Giappone, India e Russia. Secondo l’analisi di S2W, il gruppo ha sviluppato un «dual-track operational model» che conduce simultaneamente attività opportunistiche su larga scala — tipiche del cybercrime finanziario — e operazioni di spionaggio più mirate. L’adozione di lure personalizzate per ciascun paese bersaglio, con riferimenti puntuali ai sistemi fiscali locali, indica un livello di intelligence preliminare coerente con un’operazione state-sponsored o comunque sostenuta da risorse significative.

La catena d’attacco: phishing, RustSL, ValleyRAT, ABCDoor

Fase 1 — Delivery via phishing fiscale

Le email di phishing impersonano comunicazioni ufficiali dell’Income Tax Department of India (dicembre 2025) e successivamente dell’equivalente russo (gennaio 2026). Il messaggio contiene un PDF allegato con due link cliccabili che reindirizzano al download di un archivio ZIP o RAR ospitato su abc.haijing88[.]com. All’interno dell’archivio si trova un eseguibile che si maschera da PDF. In alcune varianti della campagna di dicembre, il codice malevolo è stato incorporato direttamente nell’allegato email, saltando il redirect esterno.

Fase 2 — RustSL loader: geofencing e anti-analysis

L’eseguibile è una versione modificata di RustSL, un framework open source per shellcode loader e bypass degli antivirus scritto in Rust. Silver Fox ha personalizzato il codice sorgente pubblicamente disponibile su GitHub, aggiungendo funzionalità non presenti nell’originale:

• Geofencing per paese: la versione originale di RustSL supporta solo la Cina come paese bersaglio; la variante Silver Fox estende la lista a India, Indonesia, Sud Africa, Russia e Cambogia (con versioni successive che aggiungono il Giappone). Il loader verifica la geolocalizzazione prima di procedere, abortendo l’esecuzione in caso di mismatch.
• Rilevamento di VM e sandbox: controlli ambientali standard per ostacolare l’analisi dinamica in ambienti di ricerca.
• Phantom Persistence: una variante del loader utilizza una tecnica di persistenza documentata per la prima volta nel giugno 2025 come «Phantom Persistence». Il meccanismo intercetta il segnale di shutdown del sistema, blocca la normale sequenza di spegnimento e forza un riavvio simulando un aggiornamento applicativo. Al successivo avvio dell’OS, il loader viene eseguito automaticamente.

# Infrastruttura C2 identificata
abc.haijing88[.]com          — hosting archivi payload
login-module.dll_bin         — componente core C2 di ValleyRAT
# Country list RustSL personalizzato (pre-19 gennaio 2026)
IN, ID, ZA, RU, KH
# Versioni successive aggiungono:
JP

Fase 3 — ValleyRAT (Winos 4.0)

Il payload crittografato scompattato da RustSL è ValleyRAT, noto anche come Winos 4.0, un framework malware modulare già utilizzato da Silver Fox in campagne precedenti. Il componente core, denominato login-module.dll_bin, gestisce le comunicazioni C2, l’esecuzione di comandi remoti e il recupero ed esecuzione di moduli aggiuntivi. È su questo layer modulare che viene distribuito ABCDoor.

Fase 4 — ABCDoor: la nuova backdoor Python

ABCDoor è una backdoor Python finora inedita, presente nell’arsenale di Silver Fox dal 19 dicembre 2024 e utilizzato in attacchi a partire da febbraio-marzo 2025. Viene distribuita come modulo personalizzato di ValleyRAT, dopo un secondo controllo di geofencing che filtra ulteriormente il target. Le capacità operative documentate da Kaspersky includono:

• Persistenza e aggiornamento/rimozione autonomo del backdoor
• Cattura di screenshot
• Controllo remoto di mouse e tastiera
• Operazioni sul file system (lettura, scrittura, esecuzione)
• Gestione dei processi di sistema
• Esfiltrazione del contenuto degli appunti (clipboard)
• Comunicazione C2 via HTTPS con server esterno

In varianti più recenti, osservate a partire da novembre 2025, ABCDoor viene distribuito anche tramite un loader JavaScript distribuito all’interno di archivi SFX (self-extracting) contenuti in ZIP allegati a email di phishing — un vettore alternativo che non richiede RustSL come intermediario.

Distribuzione geografica e settori impattati

Il maggior numero di attacchi è stato rilevato in India, Russia e Indonesia, seguiti da Sud Africa e Giappone. I settori più colpiti nelle ondate di gennaio-febbraio 2026 sono stati industriale, consulenza, retail e trasporti. La scelta di bersagliare contemporaneamente India e Russia — paesi con rapporti complessi con la Cina sia a livello diplomatico che commerciale — suggerisce un obiettivo di intelligence economica e politica piuttosto che un’operazione puramente finanziaria.

Connessione con campagne precedenti

Silver Fox aveva già utilizzato ValleyRAT in campagne precedenti, tipicamente contro obiettivi in Asia orientale. L’introduzione di RustSL come loader — con personalizzazioni sofisticate del codice sorgente open source — e la comparsa di ABCDoor come modulo aggiuntivo indicano un’evoluzione significativa delle capacità tecniche del gruppo. La tecnica di Phantom Persistence, che sfrutta il meccanismo di Windows per gli aggiornamenti che richiedono riavvio, è particolarmente interessante per la sua capacità di sopravvivere ai controlli di startup standard.

IoC e indicatori di compromissione

# Dominio C2 principale
abc.haijing88[.]com
# File chiave da monitorare
login-module.dll_bin        — componente core ValleyRAT C2
RustSL variants             — loader con geofencing integrato
# Pattern comportamentali (Phantom Persistence)
- Intercettazione segnale WM_QUERYENDSESSION/WM_ENDSESSION
- Registrazione come "pending file rename operation" al riavvio
- Esecuzione al boot mascherata da aggiornamento applicativo
# Vettore email
- Mittente che impersona Income Tax Department (India) o equivalente russo
- Allegato PDF con link a haijing88[.]com
- Archivio ZIP/RAR con eseguibile che simula PDF

Due righe per i difensori

• Bloccare il dominio abc.haijing88[.]com nei proxy web e nei firewall di uscita.
• Monitorare il comportamento di shutdown: processi che intercettano WM_QUERYENDSESSION o modificano PendingFileRenameOperations nel registry durante lo shutdown sono indicatori forti di Phantom Persistence.
• Email gateway: filtrare allegati PDF con link a domini registrati di recente e archivi SFX annidati in ZIP. Le esche fiscali sono stagionali ma prevedibili.
• EDR con visibilità sulle tecniche LotL: ABCDoor usa funzioni di sistema standard per operazioni di file system e controllo remoto; rilevarlo richiede behavioral analytics e non solo firma.
• Sandboxing con geolocalizzazione autentica: il geofencing di RustSL aborta in ambienti non corrispondenti ai paesi target. Sandbox configurate con IP di geolocalizzazione neutri potrebbero non triggerare il payload. Usare VPN con IP indiano, russo o indonesiano per l’analisi dinamica.

La campagna Silver Fox conferma una tendenza in atto: i gruppi APT cinesi stanno diversificando geograficamente i propri bersagli ben oltre i tradizionali obiettivi in Asia orientale, e stanno investendo nello sviluppo di tooling personalizzato — loader Rust bespoke, backdoor Python inediti, tecniche di persistenza innovative — che rende inefficaci le soluzioni di detection basate esclusivamente su signature statiche.

(in)sicurezza digitale

2026-05-09 17:44:54

Salt Typhoon nella PA italiana: Sistemi Informativi di IBM violata per due settimane, il cyberspionaggio cinese entra nella supply chain dello Stato

Nelle prime ore del 3 maggio 2026, la notizia di un’intrusione ai danni di Sistemi Informativi — la società romana controllata al 100% da IBM Italia — ha attraversato le redazioni in modo fulmineo. Dietro all’attacco, secondo le ricostruzioni convergenti di più fonti e con la pista ancora aperta per le autorità inquirenti, ci sarebbe probabilmente, voce poi smentita, Salt Typhoon: il gruppo APT riconducibile all’apparato di sicurezza della Repubblica Popolare Cinese, già responsabile della violazione di nove operatori telecom statunitensi tra cui AT&T e Verizon. Questa volta, però, il bersaglio non è un’infrastruttura straniera: è il cuore tecnologico della Pubblica Amministrazione italiana. Doveroso ricordare che al momento, per quanto comunicato dall’azienda e per la posizione di IBM, l’attacco ha avuto successo per Sistemi Informativi SRL, senza colpire la supply chain sensibile e strategica che adesso andremo ad analizzare. Questo significa che i sistemi IBM al di fuori di Sistemi Informativi restano non coinvolti. Ma vediamo di che perimetro stiamo parlando.

Chi è Sistemi Informativi e perché è un bersaglio critico

Fondata nel 1979 e con sede a Roma, Sistemi Informativi opera come system integrator nei segmenti più sensibili della trasformazione digitale italiana. Tra i suoi committenti figurano INPS, INAIL, diversi ministeri, banche, operatori delle telecomunicazioni, aziende del comparto energetico e numerosi soggetti impegnati nelle iniziative del Piano Nazionale di Ripresa e Resilienza, dalla sanità digitale al cloud nazionale. Con circa 800 dipendenti, la società rappresenta uno snodo critico: compromettere un solo integrator di questa portata significa, in linea di principio, ottenere visibilità su contratti pubblici, credenziali di accesso, dati di milioni di cittadini, configurazioni di rete e dipendenze applicative di enti distanti per missione e per settore.

È esattamente il tipo di superficie d’attacco che le campagne di cyberspionaggio statale ricercano da anni. Non il rumore dell’esfiltrazione massiva, ma la visibilità silenziosa su un ecosistema intero.

La timeline dell’incidente

L’intrusione sarebbe avvenuta circa due settimane prima della sua scoperta e rivelazione pubblica, fissando l’inizio della compromissione intorno alla metà di aprile 2026. Una finestra temporale coerente con il modus operandi di Salt Typhoon, che predilige la persistenza silenziosa e l’esfiltrazione progressiva dei dati all’azione rumorosa e distruttiva tipica del ransomware.

• 3 maggio 2026: la testata Repubblica.it pubblica l’anticipazione dell’attacco. Il sito ufficiale di Sistemi Informativi risulta irraggiungibile.
• Sera del 3 maggio: IBM diffonde un comunicato ufficiale confermando l’intrusione, l’attivazione dei protocolli di incident response e il coinvolgimento di specialisti interni ed esterni. I sistemi sono stati stabilizzati, i servizi ripristinati.
• 3-4 maggio: il Ministro per la Pubblica Amministrazione Paolo Zangrillo dichiara che «tutti gli attori istituzionali competenti stanno portando avanti le procedure previste dalla normativa» e che ACN ha avviato ogni azione necessaria per definire origine e impatto dell’attacco.
• 5-6 maggio 2026: la Procura Antiterrorismo di Roma, coordinata dal procuratore Francesco Lo Voi, apre un fascicolo ipotizzando il reato di accesso abusivo a sistema informatico.
• 6 maggio: IBM fornisce un comunicato aggiuntivo precisando: «Ad oggi, non riteniamo che questa attività sia attribuibile a Salt Typhoon». La pista resta però aperta per gli investigatori.

Il profilo di Salt Typhoon: alias, TTP e campagne note

Salt Typhoon — tracciato anche come OPERATOR PANDA, RedMike, UNC5807, GhostEmperor, Earth Estries (Trend Micro), UNC2286 (Mandiant) e FamousSparrow (ESET) — è un cluster di attività malevole documentato nel joint advisory AA25-239A pubblicato dalla CISA il 27 agosto 2025, sottoscritto da NSA, FBI, Department of Defense Cyber Crime Center e partner internazionali tra cui l’Italia. L’advisory riconduce il cluster a tre aziende tecnologiche cinesi ritenute fornitrici del Ministero per la Sicurezza dello Stato e dell’Esercito Popolare di Liberazione: Sichuan Juxinhe Network Technology, Beijing Huanyu Tianqiong Information Technology e Sichuan Zhixin Ruijie Network Technology.

L’attribuzione formale data l’inizio delle operazioni almeno al 2021, mentre le prime ricostruzioni dell’industria ne collocano l’attività già al 2019. I settori bersaglio privilegiati sono le telecomunicazioni, la pubblica amministrazione, i trasporti, il comparto alberghiero e la difesa. La logica operativa è quella della raccolta di intelligence di lungo periodo, non dell’estorsione finanziaria: non distruggere, ma sapere, e sapere a lungo.

Vettori d’attacco e strumenti

Il joint advisory CISA chiarisce un aspetto tecnico rilevante: Salt Typhoon non utilizza in modo sistematico falle zero-day, ma sfrutta vulnerabilità CVE pubblicamente note e già corrette dai vendor, in danno di organizzazioni che non hanno applicato gli aggiornamenti. Tra le vulnerabilità prioritariamente sfruttate:

CVE-2024-21887 / CVE-2023-46805 — Ivanti Connect Secure e Policy Secure
CVE-2024-3400              — Palo Alto Networks PAN-OS GlobalProtect
CVE-2023-20198 / CVE-2023-20273 — Cisco IOS XE
CVE-2018-0171              — Cisco IOS e IOS XE

Sul versante del payload, il gruppo ricorre a utility come JumbledPath, capace di catturare il traffico di rete su dispositivi Cisco compromessi attraverso catene di jump host, e impiega tecniche Living off the Land (LotL) in cui l’attività malevola si confonde con il traffico legittimo prodotto da strumenti già presenti sul target. In Europa, Darktrace ha documentato nell’ottobre 2025 un’intrusione contro un grande operatore telecom europeo ottenuta sfruttando CVE su Citrix NetScaler Gateway, con movimento laterale verso host Citrix VDA, mascheramento tramite SoftEther VPN e installazione del backdoor SNAPPYBEE via DLL sideloading.

Supply chain della PA: il vero punto debole strutturale

L’episodio italiano si inserisce in un pattern consolidato. Negli ultimi due anni, gli attori statali ostili hanno spostato il fuoco dai bersagli finali ai loro fornitori tecnologici. Compromettere un fornitore unico che funge da snodo per decine di clienti istituzionali è un investimento offensivo di altissima resa. La PA italiana è esposta a una concentrazione di rischio strutturale: il numero ridotto di system integrator in grado di gestire progetti di scala nazionale crea un punto di accumulo della fiducia che, se compromesso, propaga la violazione attraverso l’intera filiera senza ulteriori intrusioni dirette.

I contratti pubblici raramente prevedono requisiti di sicurezza commisurati al ruolo strategico del fornitore: clausole di security by design, audit indipendenti, threat hunting continuo, segmentazione di rete tra ambienti di clienti diversi, gestione strutturata delle identità privilegiate. Il caso Sistemi Informativi imporrà, con ogni probabilità, una revisione profonda di queste pratiche per i fornitori di soggetti essenziali e importanti ai sensi della NIS2.

NIS2 e D.Lgs. 138/2024: il primo banco di prova reale

L’incidente cade nel primo quadrimestre di piena operatività del nuovo regime di notifica degli incidenti significativi introdotto dalla NIS2, recepita con il D.Lgs. 138/2024 e pienamente vigente dal 1° gennaio 2026. I soggetti essenziali e importanti devono trasmettere al CSIRT Italia una pre-notifica entro 24 ore dall’evidenza dell’incidente, una notifica completa entro 72 ore e una relazione finale entro un mese. Il caso Sistemi Informativi è il primo banco di prova di rilievo nazionale per l’intero sistema: come vengono gestiti gli adempimenti, con quale coordinamento tra ACN, Garante e operatori, con quali tempi e con quale trasparenza diventerà un precedente operativo per il sistema.

Salt, Volt, Flax: la pressione cinese sull’Europa è sistemica

L’incidente non è un episodio isolato: è il segmento europeo di una pressione sistemica articolata su più fronti. Salt Typhoon si concentra sull’intercettazione delle comunicazioni e sulla raccolta di intelligence presso carrier e fornitori IT. Volt Typhoon mira a posizionare implant nelle infrastrutture critiche civili statunitensi in una logica di prepositioning per scenari di crisi. Flax Typhoon, sanzionato dall’OFAC, costruisce botnet di dispositivi compromessi utilizzabili a copertura di ulteriori operazioni. La sovrapposizione delle tre campagne disegna un’architettura di pressione nella quale spionaggio, sabotaggio potenziale e infrastruttura offensiva convivono e si rafforzano reciprocamente.

Indicazioni pratiche per i difensori

• Patch management aggressivo sui perimeter device: le CVE sfruttate da Salt Typhoon sono note e corrette. La finestra di esposizione si chiude solo applicando gli aggiornamenti. Priorità assoluta a Ivanti, Palo Alto PAN-OS, Cisco IOS XE.
• Network segmentation e Zero Trust: in ambienti multi-cliente come quelli degli integrator, la segmentazione rigida tra tenant è l’unico modo per contenere il movimento laterale post-compromissione.
• Threat hunting sulle appliance perimetrali: rilevare JumbledPath e tecniche LotL richiede visibilità sul traffico di rete a livello di dispositivo, non solo sugli endpoint. NetFlow, logging di sistema e behavioral analytics sono prerequisiti.
• Revisione dei contratti con fornitori strategici: includere requisiti minimi di sicurezza, diritto di audit e obblighi di incident notification con tempistiche allineate alla NIS2.
• Condivisione di threat intelligence con CSIRT Italia: segnalare tempestivamente IoC e pattern d’attacco contribuisce alla difesa collettiva del sistema-Paese.

L’attacco di Salt Typhoon a IBM Italia non si misura soltanto dalla quantità di dati eventualmente esfiltrati, che resta a oggi non quantificabile. Il suo significato è strategico: conferma che la frontiera dell’attacco si è spostata sui fornitori unici di servizi pubblici, che i vettori d’ingresso più produttivi restano le appliance perimetrali con CVE pubblicate ma non corrette, e che la persistenza silenziosa — non il ransomware — è la firma delle operazioni che contano davvero.