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

Fedimedia Italia APS - Web

2026-03-30 17:14:11

Fedimedia firma la lettera aperta per Mantenere Android Libero, unisciti alla battaglia “keep android open” per liberare lo smartphone

Oggi il controllo degli smartphone è sempre più concentrato nelle mani di poche grandi aziende. Anche un sistema che nasce libero come Android rischia di essere progressivamente chiuso, regolato e trasformato in uno strumento sotto controllo centralizzato, ma qualcosa si sta muovendo.

Fedimedia Italia APS è parte attiva del movimento internazionale keep android open che non si limita a denunciare, ma lavora concretamente insieme ad alcune delle più importanti realtà del mondo open source e del free software per difendere un futuro digitale libero, aperto e decentralizzato ed è fra i firmatari della lettera aperta a google per mantenere l’ecosistema android aperto.

Per questa campagna abbiamo attivato un banner in alto con un conto alla rovescia: il tempo che resta a un Android davvero libero. Un segnale chiaro per sensibilizzare tutte le persone su quanto sta accadendo e sull’urgenza di non restare a guardare.

👉 Se credi anche tu che la tecnologia debba essere al servizio delle persone e non il contrario puoi fare un passo concreto:

Sostieni Fedimedia e partecipa al movimento per la liberazione della tecnologia. Bastano pochi secondi per lasciare il tuo interesse tramite il modulo di contatto. e venire aggiornato sulle azioni intraprese da fedimedia e dal movimento Keep Android Open.

La lettera che abbiamo indirizzato al movimento Keep Android Open

Gentili promotori della campagna KeepAndroidOpen,

con grande interesse e condivisione dei valori espressi nella vostra lettera aperta a Google, scriviamo per aderire ufficialmente alla vostra iniziativa in difesa di un Android libero, aperto e indipendente da controlli centralizzati.

Fedimedia Italia APS nasce per promuovere unecosistema digitale basato su principi di libertà, decentralizzazione e sovranità tecnologica. Come associazione che si batte per un web etico e indipendente dalle Big Tech, non possiamo che sostenere con forza la vostra opposizione alla registrazione obbligatoria degli sviluppatori.

Perchè non dovrebbero vincolare lo sviluppo di app su qualsiasi dispositivo ?

Ci piace pensare ad Android come a una tela di pittore, ai dispositivi come a pennelli e alle app come a colori: chi produce gli strumenti non può pretendere di controllare l’arte che ne scaturisce, né tantomeno imporre agli artisti di registrarsi presso un unico fornitore per poter creare.

La libertà di espressione digitale, proprio come quella artistica, non può essere soggetta a permessi o a gatekeeper. Imporre una registrazione centralizzata significa trasformare una piattaforma aperta in un sistema chiuso a chi non autorizzato da voi, dove la creatività e l’innovazione sono ostaggi di regole arbitrarie e di interessi commerciali.

Per noi, la decentralizzazione e l’apertura non sono solo scelte tecniche, ma valori fondanti: ogni sviluppatore, ogni utente, ogni comunità deve poter operare senza dover chiedere il permesso a un’unica autorità. La vostra battaglia è anche la nostra, perché difendere Android significa difendere il diritto di tutti a un futuro digitale pluralista, trasparente e rispettoso dei diritti fondamentali.

Con questa email, vi comunichiamo quindi la nostra piena adesione alla campagna KeepAndroidOpen. Siamo pronti a sostenervi nella diffusione dei vostri obiettivi, a partecipare attivamente alle iniziative promosse e a collaborare per costruire alternative concrete che preservino la libertà e l’apertura di Android, valori che condividiamo profondamente.

Rimaniamo a disposizione per qualsiasi ulteriore passo o azione collettiva.

Cordiali saluti,
Fedimedia Italia APS

Qui di seguito la lettera aperta indirizzata ai vertici di Google

Questa è la traduzione della lettera aperta a Google indirizzata ai fondatori, CEO e dirigenti Google

Dat</code><code>a</code><code>:</code><code> </code><code>24 febbraio</code><code> 2026</code><code>A</code><code>:</code><code> </code><code>Sundar Pichai, Chief Executive Officer, Google</code><code>A</code><code>:</code><code> </code><code>Sergey Brin, Founder and Board Member, Google</code><code>A</code><code>:</code><code> </code><code>Larry Page, Founder and Board Member, Google</code><code>A</code><code>: Vijaya Kaza, General Manager for App & Ecosystem Trust, Google</code><code>CC:</code><code> </code><code>Regulatory authorities, policymakers, and the Android developer community</code><code>Re:</code><code> </code><code>Mandatory Developer Registration for Android App Distribution

---

Noi, le organizzazioni sottoscritte che rappresentano la società civile, le istituzioni no-profit e le aziende tecnologiche, scriviamo per esprimere la nostra ferma opposizione alla politica annunciata da Google, che richiede a tutti gli sviluppatori di app Android di registrarsi in maniera centralizzata presso Google per poter distribuire applicazioni al di fuori del Google Play Store e che entrerà in vigore in tutto il mondo nei prossimi mesi.

Pur riconoscendo l’importanza della sicurezza della piattaforma e della sicurezza degli utenti, la piattaforma Android include già diversi meccanismi di sicurezza che non richiedono una registrazione centralizzata. Iniettare forzatamente un modello di sicurezza estraneo, in contrasto con la storica natura aperta di Android, minaccia l’innovazione, la concorrenza, la privacy e la libertà degli utenti. Esortiamo Google a ritirare questa policy e a collaborare con le comunità open source e della sicurezza per trovare alternative meno restrittive.

Le nostre preoccupazioni

1. Controllo oltre lo Store di Google

Android è storicamente caratterizzato come una piattaforma aperta in cui utenti e sviluppatori possono operare indipendentemente dai servizi di Google. La politica di registrazione degli sviluppatori proposta modifica radicalmente tale rapporto, richiedendo agli sviluppatori che desiderano distribuire app tramite canali alternativi (i propri siti web, app store di terze parti, sistemi di distribuzione aziendali o trasferimenti diretti) di richiedere prima l’autorizzazione a Google attraverso una procedura di verifica obbligatoria, che prevede l’accettazione dei termini e delle condizioni di Google, il pagamento di una quota e il caricamento di un documento di identità rilasciato dal governo.

Ciò estende l’autorità di controllo di Google oltre il proprio marketplace, estendendola a canali di distribuzione in cui non ha alcun ruolo operativo legittimo. Gli sviluppatori che scelgono di non utilizzare i servizi di Google non dovrebbero essere costretti a registrarsi e a sottoporsi al giudizio di Google. Centralizzare la registrazione di tutte le applicazioni a livello mondiale conferisce inoltre a Google nuovi poteri per disattivare completamente qualsiasi app desideri, per qualsiasi motivo, per l’intero ecosistema Android.

2. Barriera all’ingresso e ostacolo all’innovazione

La registrazione obbligatoria crea ostacoli e barriere all’ingresso, in particolare per:

• Gli sviluppatori individuali e i piccoli team con risorse limitate
• I progetti open source che si basano su collaboratori volontari
• Gli sviluppatori in aree geografiche con accesso limitato all’infrastruttura di registrazione di Google
• Gli sviluppatori focalizzati sulla privacy che evitano gli ecosistemi di sorveglianza
• La risposta alle emergenze e le organizzazioni umanitarie che richiedono un rapido intervento
• Gli attivisti che lavorano per la libertà di Internet in paesi che criminalizzano ingiustamente tale lavoro
• Gli sviluppatori in paesi o aree in cui Google non può consentire loro di registrarsi a causa di sanzioni
• I ricercatori e gli accademici che sviluppano applicazioni sperimentali
• Le applicazioni aziendali e governative interne che non sono mai state pensate per un’ampia distribuzione pubblica

Ogni ulteriore ostacolo burocratico riduce la diversità nell’ecosistema software e concentra il potere nelle mani di grandi attori affermati che possono assorbire più facilmente tali costi di conformità.

3. Problemi di privacy e sorveglianza

Richiedere la registrazione a Google crea un database completo di tutti gli sviluppatori Android, indipendentemente dal fatto che utilizzino o meno i servizi Google. Ciò solleva seri interrogativi su:

• Quali informazioni personali devono fornire gli sviluppatori
• Come queste informazioni saranno archiviate, protette e utilizzate
• La possibilità che questi dati possano essere soggetti a richieste governative o procedimenti legali
• La modalità con cui l’attività degli sviluppatori possa essere monitorata nell’intero ecosistema
• L’impatto che comporta per gli sviluppatori che lavorano su applicazioni che tutelano la privacy o che sono politicamente sensibili

Gli sviluppatori dovrebbero avere il diritto di creare e distribuire software senza sottoporsi a inutili controlli o sorveglianza.

4. Rischi di applicazione arbitraria e chiusura dell’account

Gli attuali processi di revisione delle app di Google sono stati criticati per la scarsa trasparenza del processo decisionale, l’applicazione incoerente delle norme e i meccanismi di ricorso limitati. L’estensione di questo sistema a tutti i dispositivi certificati Android comporta i seguenti rischi:

• Rifiuto arbitrario o sospensione senza chiara giustificazione
• Sistemi automatizzati che prendono decisioni consequenziali con una supervisione umana insufficiente
• Sviluppatori che perdono la possibilità di distribuire app su tutti i canali a causa di una singola decisione aziendale non verificabile
• Considerazioni politiche o competitive che influenzano l’approvazione della registrazione
• Impatto sproporzionato sulle comunità emarginate e applicazioni controverse ma legali

Un singolo punto di vulnerabilità controllato da una sola azienda è l’antitesi di un ecosistema software sano e competitivo.

5. Implicazioni anticoncorrenziali

Questo requisito consente a Google di raccogliere informazioni su tutte le attività di sviluppo Android, tra cui:

• Quali app vengono sviluppate e da chi
• Le strategie di distribuzione e modelli di business alternativi
• Le minacce competitive ai servizi di Google
• Le tendenze di mercato e preferenze degli utenti al di fuori dell’ecosistema di Google

Questa asimmetria informativa fornisce a Google notevoli vantaggi competitivi, le consente di anticipare, copiare e indebolire prodotti e servizi concorrenti e potrebbe sollevare numerose questioni in materia di antitrust.

6. Problemi normativi

Le autorità di regolamentazione di tutto il mondo, tra cui la Commissione Europea, il Dipartimento di Giustizia degli Stati Uniti e le autorità garanti della concorrenza in diverse giurisdizioni, hanno esaminato con sempre maggiore attenzione la capacità delle piattaforme dominanti di privilegiare i propri servizi e limitare la concorrenza, richiedendo maggiore apertura e interoperabilità. Notiamo inoltre crescenti preoccupazioni circa l’intervento normativo che aumenta la sorveglianza di massa, ostacolando la libertà del software, l’apertura di Internet e la neutralità dei dispositivi.

Invitiamo Google a trovare modi alternativi per conformarsi agli obblighi normativi, promuovendo modelli che rispettino la natura aperta di Android senza aumentare il controllo dei gatekeeper sulla piattaforma.

Le misure esistenti sono sufficienti

La piattaforma Android include già diversi meccanismi di sicurezza che non richiedono la registrazione centrale:

• Funzionalità di sicurezza a livello di sistema operativo, sandbox delle applicazioni e sistemi di autorizzazione
• Avvisi utente per le applicazioni installate direttamente (o “sideloaded”)
• Google Play Protect (che gli utenti possono scegliere di abilitare o disabilitare)
• Certificati di firma dello sviluppatore che stabiliscono la provenienza del software

Non è stata presentata alcuna prova che queste misure di sicurezza siano insufficienti a continuare a proteggere gli utenti Android come hanno fatto per tutti i diciassette anni di esistenza di Android. Se la preoccupazione di Google è realmente la sicurezza piuttosto che il controllo, dovrebbe investire nel miglioramento di questi meccanismi esistenti anziché creare nuovi colli di bottiglia e centralizzare il controllo.

La nostra petizione

Invitiamo Google a:

1. Abrogare immediatamenteil requisito obbligatorio di registrazione dello sviluppatore per la distribuzione a terze parti.
2. Avviare un dialogo trasparentecon la società civile, gli sviluppatori e gli enti regolatori sui miglioramenti della sicurezza Android, nel rispetto dell’apertura e della concorrenza.
3. Impegnarsi a favore della neutralità della piattaformaassicurando che Android rimanga una piattaforma realmente aperta in cui il ruolo di Google come fornitore della piattaforma non sia in conflitto con i suoi interessi commerciali.

Nel corso degli anni, Android si è evoluto in un’infrastruttura tecnologica fondamentale al servizio di centinaia di governi, milioni di aziende e miliardi di cittadini in tutto il mondo. Consolidare e centralizzare unilateralmente il potere di approvare il software nelle mani di un’unica azienda che può esimersi da una reale responsabilità e rendicontabilità è antitetico ai principi della libertà di pensiero, è un affronto al software libero, è una barriera insormontabile alla concorrenza ed è una minaccia universale alla sovranità digitale.

Imploriamo Google di invertire la rotta, porre fine al programma di verifica degli sviluppatori e iniziare a collaborare con la più ampia comunità degli sviluppatori per promuovere gli obiettivi di sicurezza senza sacrificare i principi di massima apertura in base ai quali è stato realizzato Android. La forza dell’ecosistema Android è storicamente basata sulla sua architettura aperta e Google deve impegnarsi per ripristinare il suo ruolo di fedele custode di tale fiducia.

Fedimedia Italia APS

Fedimedia Italia APS nasce per costruire un ecosistema digitale e sociale dove tecnologia, diritti e ambiente coesistono in armonia.

^{glowingmug (Fedimedia Italia APS - Web)}

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