(in)sicurezza digitale

2026-04-16 09:27:30

APT28 PRISMEX: la suite malware di spionaggio dell’esercito russo colpisce l’Ucraina e gli alleati NATO

Si parla di:
Toggle

• La campagna PRISMEX: steganografia e doppi intenti
• Anatomia della suite PRISMEX
• Sfruttamento Zero-Day e tattica di preparazione dell’infrastruttura
• Catena di accesso iniziale e vettori di infezione
• Indicatori tecnici e meccanismi di persistenza
• Implicazioni strategiche e di difesa

L’APT28 (noto anche come Pawn Storm, Forest Blizzard, Fancy Bear) lancia una sofisticata campagna di spear-phishing che distribuisce la suite malware PRISMEX, combinando steganografia avanzata, spoofing COM e abuso di servizi cloud legittimi. La campagna prende di mira infrastrutture critiche ucraine e partner logistici NATO in Polonia, Romania, Slovenia, Turchia, Slovacchia e Repubblica Ceca, segnalando un’escalation significativa delle operazioni di cyber-spionaggio russo.

La campagna PRISMEX: steganografia e doppi intenti

A partire da almeno settembre 2025, l’APT28 ha dispiegato la suite PRISMEX in una campagna mirata a enti governativi ucraini (corpi esecutivi centrali, servizi di idrometeorologia, difesa, gestione delle emergenze) e partner logistici militari in tutta Europa orientale e i Balcani. La campagna è particolarmente preoccupante per due motivi: la rapidità di sfruttamento di vulnerabilità zero-day e la sofisticazione dell’infrastruttura di comando e controllo.

PRISMEX combina quattro componenti malware distinti, ognuno con funzioni specifiche nella catena infettiva. Lo spionaggio e le capacità distruttive coesistono nello stesso malware, suggerendo una doppia intenzione: raccogliere intelligence militare-strategica e preparare potenziali operazioni di sabotaggio dirompente contro infrastrutture critiche alleate.

Anatomia della suite PRISMEX

PrismexSheet è il componente iniziale: un documento Excel malevolo con macro VBA che estrae payload nascosti nel file tramite steganografia. Dopo che la macro è abilitata, il componente stabilisce persistenza tramite hijacking COM e visualizza un documento esca relativo a inventari di droni e prezzi di equipaggiamento militare per ingannare l’utente.

PrismexDrop è un dropper nativo che prepara l’ambiente per lo sfruttamento successivo, utilizza task pianificati e hijacking COM DLL per mantenere la persistenza nel sistema compromesso.

PrismexLoader è la componente più sofisticata dal punto di vista tecnico. Funziona come un proxy DLL che estrae il payload .NET successivo disperso nella struttura di un file PNG (“SplashScreen.png”) utilizzando un algoritmo personalizzato denominato “Bit Plane Round Robin”. Questo metodo di steganografia distribuisce i dati attraverso il file per eludere la rilevazione, consentendo l’esecuzione completamente in memoria con tracce minime su disco.

PrismexStager è un impianto COVENANT Grunt che abusa del servizio cloud Filen.io per le comunicazioni di comando e controllo. Questa infrastruttura consente al traffico malevolo di mimetizzarsi con le comunicazioni web normali crittografate, bypassando i filtri basati sulla reputazione e le regole firewall.

Sfruttamento Zero-Day e tattica di preparazione dell’infrastruttura

L’APT28 ha dimostrato una capacità straordinaria di sfruttare le vulnerabilità quasi immediatamente dopo la divulgazione pubblica. Le vulnerabilità CVE-2026-21509 (sfruttamento RTF) e CVE-2026-21513 (bypass della protezione del browser) sono state integrate nella campagna PRISMEX con velocità allarmante.

Ancora più preoccupante: l’infrastruttura preparatoria è stata osservata il 12 gennaio 2026, esattamente due settimane prima della divulgazione pubblica di CVE-2026-21509. Questo suggerisce fortemente che l’APT28 possedeva una conoscenza zero-day della vulnerabilità, anticipando di settimane la divulgazione ufficiale da parte di Microsoft.

Catena di accesso iniziale e vettori di infezione

Gli attacchi iniziano con email di spear-phishing particolarmente sofisticate che sfruttano contesti geopolitici attuali. I temi utilizzati includono briefing su addestramento militare, avvisi meteorologici critici, documenti su contrabbando di armi e logistica militare, e inventari di equipaggiamento difensivo.

CVE-2026-21509 (una vulnerabilità di esecuzione di codice remoto in file RTF) forza una connessione ai server WebDAV controllati dagli attaccanti, consentendo il download e l’esecuzione di PrismexSheet. CVE-2026-21513 consente l’esecuzione silenziosa di codice bypassando le protezioni del browser.

Indicatori tecnici e meccanismi di persistenza

I meccanismi di persistenza includono COM hijacking, task pianificati che riavviano explorer.exe a intervalli regolari, esecuzione senza file tramite caricamento runtime .NET, e abuso del servizio cloud Filen.io per C2. La steganografia “Bit Plane Round Robin” di PrismexLoader è particolarmente insidiosa, distribuendo il payload nei piani di bit di un file PNG per consentire ai difensori di vedere un’immagine visivamente normale mentre nasconde efficacemente la logica malware.

Implicazioni strategiche e di difesa

Per le organizzazioni nel settore della difesa, della logistica e delle infrastrutture critiche in Europa orientale e nei Balcani: monitorare le connessioni a Filen.io da endpoint aziendali, cercare file PNG in posizioni inusuali, analizzare le macros di Excel per riferimenti a URL di download, implementare il whitelisting delle applicazioni, disabilitare i task scheduler non autorizzati, e applicare immediatamente le patch per CVE-2026-21509 e CVE-2026-21513.

APT28 PRISMEX: la suite malware di spionaggio dell'esercito russo colpisce l'Ucraina e gli alleati NATO - (in)sicurezza digitale

L'APT28 lancia una sofisticata campagna PRISMEX combinando steganografia avanzata e abuso di servizi cloud legittimi per colpire l'Ucraina e i partner NATO con capacità di spionaggio e sabotaggio.

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-16 07:47:38

.NET 11 Preview 3: tutte le novità del terzo rilascio anticipato

.NET 11 è ancora in fase di sviluppo, ma il terzo Preview rilasciato il 14 aprile 2026 porta con sé una serie di novità concrete e già sperimentabili. Dalle librerie di sistema al runtime JIT, dall’SDK alla toolchain, questo rilascio intermedio offre uno sguardo chiaro su dove sta andando l’ecosistema .NET. Vediamo nel dettaglio cosa c’è di nuovo e cosa vale la pena testare subito nei propri progetti.

Novità nel Runtime e JIT

Il team del runtime ha rimosso il requisito del flag di opt-in per le API async previewed nelle versioni precedenti: alcune funzionalità asincrone del runtime sono ora accessibili senza annotazioni speciali. Sul fronte delle prestazioni, il JIT compiler è stato ottimizzato in tre aree chiave:

• Switch statement: migliorata la generazione di codice macchina per costrutti switch complessi
• Bounds check: eliminati controlli ridondanti sugli array in scenari comuni
• Type cast: ridotta la latenza nelle operazioni di cast tra tipi gerarchicamente correlati

Sul fronte WebAssembly, .NET 11 introduce il formato WebCIL, un nuovo formato di packaging per i moduli .wasm, insieme a miglioramenti al debugging in ambiente browser. Chi sviluppa applicazioni Blazor WebAssembly beneficerà di esperienze di debug più fluide.

Librerie di Sistema: JSON, Compressione e Regex

System.Text.Json riceve controllo più granulare sulla naming strategy e sulla gestione dei valori di default. Sarà possibile configurare i serializzatori per ignorare specifiche proprietà con valori predefiniti in modo più preciso rispetto a quanto offriva il parametro DefaultIgnoreCondition.

La novità più interessante lato compressione è l’aggiunta di Zstandard (zstd) in System.IO.Compression. Zstandard è l’algoritmo di compressione sviluppato da Meta, noto per offrire un ottimo trade-off tra velocità e rapporto di compressione — spesso superiore a gzip e deflate. Esempio di utilizzo:

using System.IO.Compression;

// Compressione con Zstandard
using var input = File.OpenRead("dati.json");
using var output = File.Create("dati.json.zst");
using var compressor = new ZstandardStream(output, CompressionMode.Compress);
await input.CopyToAsync(compressor);

In aggiunta, la lettura di file ZIP ora valida i checksum CRC32 automaticamente, rendendo più robusta la gestione degli archivi corrotti o manomessi.

Per le espressioni regolari, il motore riconosce ora tutte le sequenze Unicode di newline, migliorando la portabilità del parsing testuale cross-platform.

SDK: Nuove Funzionalità da CLI

L’SDK riceve alcune aggiunte molto pratiche per chi lavora da terminale:

Passare variabili d’ambiente con dotnet run -e

# Passare una variabile d'ambiente al processo durante lo sviluppo
dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e ConnectionStrings__Default="Server=..."

Finalmente si può sovrascrivere variabili d’ambiente senza toccare launchSettings.json o esportare variabili nello shell corrente.

Top-level programs multi-file

I programmi con top-level statements (introdotti in C# 9) potranno ora distribuirsi su più file sorgente. Questo alleggerisce il vincolo di avere tutto in un unico Program.cs per i progetti di tipo file-based, come script o tool CLI leggeri.

dotnet watch migliorato

Lo strumento dotnet watch ha ricevuto tre miglioramenti rilevanti: supporto ai progetti .NET Aspire, crash recovery automatico e miglioramenti specifici per applicazioni Windows desktop (WPF/WinForms).

C# 14: Union Types in Anteprima

Preview 3 include un’anteprima degli union types in C# 14. Questa funzionalità, molto attesa, consente di dichiarare tipi che possono contenere uno tra un insieme definito di tipi, avvicinando C# a pattern già presenti in F#, TypeScript e Rust:

// Sintassi ipotetica - ancora in preview, soggetta a variazioni
union Result<T>
{
    T Value,
    Exception Error
}

var result = GetData();
var output = result switch
{
    Result<string>.Value(var v) => $"Successo: {v}",
    Result<string>.Error(var e) => $"Errore: {e.Message}"
};

Attenzione: la sintassi è ancora sperimentale e potrebbe cambiare nelle release successive.

ASP.NET Core in .NET 11 Preview 3

Tre aggiornamenti principali per il framework web:

Compressione Zstandard per le risposte HTTP

ASP.NET Core ora supporta la compressione zstd nelle risposte HTTP e la decompressione delle richieste in arrivo. Da configurare in Program.cs:

builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<ZstandardCompressionProvider>();
    options.EnableForHttps = true;
});

Blazor Virtualize con altezze variabili

Il componente <Virtualize> di Blazor ora si adatta a elementi di altezza variabile a runtime, risolvendo un limite storico che richiedeva di specificare un’altezza fissa per gli elementi della lista virtualizzata.

HTTP/3 più reattivo

L’avvio dell’elaborazione delle richieste HTTP/3 è anticipato, riducendo la latenza percepita nelle prime connessioni su protocollo QUIC.

Entity Framework Core: GetEntriesForState()

EF Core in .NET 11 introduce ChangeTracker.GetEntriesForState(), un metodo che consente di interrogare le entry per stato (Added, Modified, Deleted) senza scatenare un cycle di change detection — operazione potenzialmente costosa in grafi di oggetti complessi:

// Prima: scatenava change detection su tutto il grafo
var modified = context.ChangeTracker.Entries()
    .Where(e => e.State == EntityState.Modified)
    .ToList();

// Ora: accesso diretto per stato, senza overhead di detection
var modified = context.ChangeTracker
    .GetEntriesForState(EntityState.Modified)
    .ToList();

Container Images Firmati

Le immagini container ufficiali di .NET sono ora firmate digitalmente, permettendo la verifica della catena di custodia prima del deployment. Questo è un passo importante per le pipeline DevSecOps che richiedono provenance verificabile dei componenti software.

Come Provare .NET 11 Preview 3

# Scaricare il SDK da https://dotnet.microsoft.com/download/dotnet/11.0
dotnet --version
# Output atteso: 11.0.0-preview.3.xxxxx

# Creare un progetto di test
dotnet new console -n test-dotnet11 --framework net11.0

Conclusione

.NET 11 Preview 3 è un rilascio ricco, che tocca trasversalmente runtime, SDK, ASP.NET Core ed EF Core. Le novità più impattanti per la produzione futura sono il supporto a Zstandard, gli union types in C# 14 e le ottimizzazioni JIT. Si consiglia di testare le nuove funzionalità dell’SDK — in particolare dotnet run -e — già ora, poiché entreranno probabilmente stabili con il rilascio di novembre 2026.

Fonte: devblogs.microsoft.com — .NET 11 Preview 3 is now available!, 14 aprile 2026

.NET 11 Preview 3 is now available! - .NET Blog

Find out about the new features in .NET 11 Preview 3 across the .NET runtime, SDK, libraries, ASP.NET Core, .NET MAUI, C#, Entity Framework Core, container images, and more!

^{.NET Team (.NET Blog)}

informapirata

2023-03-27 11:39:57

Sei un utente Mastodon e vorresti usare i gruppi/forum Friendica e le comunità Lemmy? Allora questa guida fa per te!

informapirata.it/2023/03/27/ti…

Tips Mastodon: come usare i gruppi/forum Friendica e le comunità Lemmy - informapirata

^{informapirata}

Spcnet.it

2026-04-15 14:37:06

LLM Chat in .NET con IChatClient: guida completa all’integrazione

Introduzione: l’astrazione che unifica i servizi LLM

Integrare Large Language Model in .NET ha sempre comportato un problema: ogni servizio (OpenAI, Azure OpenAI, Ollama, Claude) ha il proprio SDK con API diverse. IChatClient della libreria Microsoft.Extensions.AI risolve questo problema fornendo un’astrazione unificata. Scrivi una volta, cambia provider senza modificare la logica applicativa.

Cosa è IChatClient?

IChatClient è un’interfaccia che rappresenta un client per servizi AI con capacità chat. Astrae i dettagli di comunicazione con LLM remoti o locali, permettendo di:

• Inviare e ricevere messaggi con contenuto multi-modale (testo, immagini, audio)
• Ottenere risposte complete o streaming incrementale
• Mantenere contesto di conversazione
• Usare funzionalità avanzate come tool calling e structured outputs

L’interfaccia fa parte del pacchetto Microsoft.Extensions.AI.Abstractions, mentre Microsoft.Extensions.AI aggiunge middleware per telemetria, caching, function calling automatico e patterns familiari di dependency injection.

Setup iniziale con DI

Il punto di partenza è registrare il chat client nel contenitore di dependency injection. Ecco l’approccio canonico:

var builder = Host.CreateApplicationBuilder();
builder.Services.AddChatClient(
    new OllamaChatClient(new Uri("http://localhost:11434"), "llama3"));
var app = builder.Build();
var chatClient = app.Services.GetRequiredService<IChatClient>();

In questo esempio, usiamo Ollama con il modello llama3 locale. La bellezza di questa astrazione: la stessa registrazione funziona con OpenAI, Azure OpenAI o qualsiasi provider che implementi IChatClient. Il codice che usa il client rimane invariato.

Risposta semplice da un LLM

Il caso più basilare: inviare un prompt e ottenere una risposta:

var response = await chatClient.GetResponseAsync("What is .NET? Reply in 50 words max.");
Console.WriteLine(response.Message.Text);

Il metodo GetResponseAsync restituisce un oggetto ChatCompletion con il messaggio della risposta. Semplice, sincrono dal punto di vista dello sviluppatore (anche se asincrono sottostante).

Streaming per risposte lunghe

Per applicazioni interattive come chatbot, lo streaming è essenziale. Permette all’utente di vedere il testo apparire gradualmente, come in ChatGPT:

var chatResponse = "";
await foreach (var item in chatClient.GetStreamingResponseAsync(chatHistory))
{
    Console.Write(item.Text);
    chatResponse += item.Text;
}

Il metodo GetStreamingResponseAsync ritorna un IAsyncEnumerable<StreamingChatCompletionUpdate>. Ogni item contiene un frammento di testo che puoi visualizzare in tempo reale.

Conversazioni multi-turno con cronologia

Mantenere una conversazione richiede di raccogliere la storia dei messaggi. Ecco un loop interattivo completo:

var chatHistory = new List<ChatMessage>();
while (true)
{
    Console.Write("You: ");
    var userPrompt = Console.ReadLine();
    
    chatHistory.Add(new ChatMessage(ChatRole.User, userPrompt));
    
    var chatResponse = "";
    Console.Write("Assistant: ");
    await foreach (var item in chatClient.GetStreamingResponseAsync(chatHistory))
    {
        Console.Write(item.Text);
        chatResponse += item.Text;
    }
    Console.WriteLine();
    
    chatHistory.Add(new ChatMessage(ChatRole.Assistant, chatResponse));
}

Ogni turno aggiunge alla lista: il user message, poi il response dell’assistant. Al turno successivo, passi l’intera cronologia a GetStreamingResponseAsync. L’LLM usa questo contesto per mantenere coerenza conversazionale.

Structured output: JSON tipizzato

Spesso vuoi che l’LLM restituisca dati strutturati (JSON). Puoi chiederlo esplicitamente nel prompt:

var prompt = $"""
You will receive an article and extract its metadata.
Respond ONLY with valid JSON following this format without any deviation.

{{
    "title": "...",
    "summary": "...",
    "keywords": ["...", "..."]
}}

Article:
{File.ReadAllText("article.md")}
""";

var response = await chatClient.GetResponseAsync(prompt);
var jsonText = response.Message.Text;
var metadata = JsonSerializer.Deserialize<ArticleMetadata>(jsonText);

L’approccio funziona, ma richiede gestione manuale di parsing e validazione. C’è una soluzione migliore.

Deserialization tipizzata con generics

La libreria Microsoft.Extensions.AI supporta il generic GetResponseAsync<T> che deserializza automaticamente il JSON in una classe C#:

public class ArticleMetadata
{
    public string Title { get; set; } = string.Empty;
    public string Summary { get; set; } = string.Empty;
    public string[] Keywords { get; set; } = [];
}

var metadata = await chatClient.GetResponseAsync<ArticleMetadata>(prompt);
Console.WriteLine($"Title: {metadata.Result.Title}");
Console.WriteLine($"Keywords: {string.Join(", ", metadata.Result.Keywords)}");

Questa API offre sicurezza in fase di compilazione e supporto IDE completo per il refactoring. Se cambi la struttura di ArticleMetadata, il compilatore avvisa i punti di utilizzo.

Portabilità tra provider: da locale a cloud

Una delle promesse di IChatClient è la portabilità. Ecco come implementare una strategia “local in dev, cloud in prod”:

// Avvio locale con Ollama
if (app.Environment.IsDevelopment())
{
    builder.Services.AddChatClient(
        new OllamaChatClient(new Uri("http://localhost:11434"), "mistral"));
}
else
{
    // Avvio cloud con Azure OpenAI
    builder.Services.AddChatClient(
        new AzureOpenAIClient(
            new Uri(azureEndpoint),
            new DefaultAzureCredential()).AsChatClient());
}

Il resto dell’applicazione non cambia. Chiede semplicemente IChatClient al DI container e riceve l’implementazione appropriata. Niente hardcoding, niente API specifiche sparse nel codice.

Middleware per telemetria e caching

Il pacchetto Microsoft.Extensions.AI fornisce middleware composabile. Uno uso comune è aggiungere OpenTelemetry:

var builder = Host.CreateApplicationBuilder();

// Registra OpenTelemetry
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation());

// Registra il chat client con middleware di telemetria
builder.Services.AddChatClient(baseChatClient)
    .UseOpenTelemetry(builder.Services.BuildServiceProvider()
        .GetRequiredService<ILoggerFactory>());

Con questo setup, ogni chiamata a IChatClient genera automaticamente span OpenTelemetry tracciabili in strumenti come Application Insights o Jaeger. Nessuna strumentazione manuale necessaria.

Integrazione con il framework Agent

Il framework Agent di Microsoft costruisce sopra IChatClient aggiungendo astrazioni a livello agent: gestione persistente del contesto, tool calling automatico, prompt di sistema, API streaming pulita. Se usi agent, IChatClient rimane il cuore della comunicazione LLM.

Conclusione

IChatClient rappresenta una maturazione nell’integrazione LLM in .NET. Invece di accoppiare il codice a provider specifici, definisci un’astrazione e lascia che l’infrastruttura scelga l’implementazione. Lo streaming, la deserialization tipizzata, la composizione di middleware e la portabilità del provider diventano proprietà di prima classe dell’architettura.

Per qualsiasi team che integra LLM in .NET 2026, IChatClient è il fondamento su cui costruire. Richiede poca configurazione iniziale e ripaga con flessibilità architetturale a lungo termine.

Fonte originale: Microsoft.Extensions.AI libraries – .NET | Microsoft Learn e Working with LLMs in .NET using Microsoft.Extensions.AI

Microsoft.Extensions.AI libraries - .NET

Learn how to use the Microsoft.Extensions.AI libraries to integrate and interact with various AI services in your .NET applications.

^{learn.microsoft.com}

(in)sicurezza digitale

2026-04-15 13:46:10

Handala e la Cyber-Offensiva dell’Iran: 6 Petabyte distrutti e 149 Terabyte rubati dall’infrastruttura critica di Dubai

Si parla di:
Toggle

• Portata e natura dell’attacco
• Attribution e legami con l’Iran
• Motivazione dichiarata e contesto geopolitico
• Implicazioni di sicurezza e defensive posture
• Raccomandazioni di difesa

Il 12 aprile 2026, il gruppo Handala, collegato ai servizi di intelligence iraniani, ha annunciato il successo di un attacco di proporzioni senza precedenti contro l’infrastruttura critica degli Emirati Arabi Uniti. L’operazione ha mirato alla Dubai Courts Authority, Dubai Land Authority e Dubai Roads & Transport Authority, risultando nel furto di 149 terabyte di documenti classificati e nella distruzione di 6 petabyte di dati, rappresentando una chiara escalation nella campagna di cyberguerra iraniana.

Portata e natura dell’attacco

L’attacco coordinato dal gruppo Handala rappresenta una categoria di operazione cybernetiche rara: la combinazione di dati wiper (per la distruzione) e exfiltration (per il furto). La selezione degli obiettivi rivela una strategia sofisticata focalizzata su istituzioni critiche che controllano documenti di valore geopolitico, proprietà intellettuale sensibile e informazioni su infrastrutture strategiche.

L’enorme volume di dati distrutti (6 petabyte equivale a circa 6 milioni di gigabyte) suggerisce che gli attaccatori avevano accesso profondo alle infrastrutture di storage primarie e di backup, un indicativo di una lunga permanenza nei sistemi target senza essere rilevati. Il gruppo ha pubblicamente rivendicato l’operazione con comunicati dettagliati, indicando che l’obiettivo non era nascondere l’attacco bensì massimizzare l’impatto psicologico e geopolitico.

Attribution e legami con l’Iran

Sebbene Handala si presenta pubblicamente come collettivo di hacker hacktivist pro-resistenza, analisti di sicurezza e agenzie governative hanno stabilito con elevata confidenza il collegamento con il Ministero dell’Intelligence iraniano (MOIS). Il gruppo fa parte di quello che DomainTools Investigations ha descritto come “un ecosistema coordinato di cyber-influenza” che include anche i gruppi Karma/KarmaBelow80 e Homeland Justice.

Questa struttura a facciata permette all’Iran di mantenere una negazione plausibile mentre conduce operazioni cybernetiche offensive contro i nemici geopolitici e gli alleati regionali. La scelta di Dubai specificamente è significativa: gli EAU hanno in anni recenti normalizzato relazioni con Israele e hanno aumentato partnership strategiche con Stati Uniti e alleati occidentali, rendendoli un bersaglio prioritario per la rappresaglia iraniana.

Motivazione dichiarata e contesto geopolitico

Nel comunicato di rivendicazione, Handala ha caratterizzato l’operazione come risposta al “tradimento eclatante” dei leader degli Emirati, tracciando paralleli con figure storiche infami come Jeffrey Epstein. Questa retorica è coerente con la narrativa iraniana che dipinge gli EAU come traditori della causa palestinese per le relazioni normalizzate con Israele. Tuttavia, gli esperti di sicurezza sottolineano che la motivazione dichiarata funziona principalmente come cover narrativo per un’operazione principalmente geopolitica e economica.

Dati dell'Operazione:
- Data: 12 Aprile 2026
- Bersagli: 3 istituzioni critiche di Dubai
- Dati Rubati: 149 Terabyte (TB) di documenti classificati
- Dati Distrutti: 6 Petabyte (PB) = 6.000 Terabyte
- Attribution: MOIS Iran via Handala/Karma/Homeland Justice
- Reivindicazione: Pubblica tramite comunicati del gruppo

Implicazioni di sicurezza e defensive posture

L’attacco Handala rivela vulnerabilità critiche nelle infrastrutture di protezione dei dati dei servizi pubblici. La capacità di distruggere 6 petabyte di dati suggerisce che gli attaccatori avevano accesso non solo ai sistemi primari ma anche ai backup, compromettendo le fondamentali pratiche di business continuity e disaster recovery. I responsabili della sicurezza negli Emirati e nei governi alleati devono riconsiderare gli assunti di base sulla separazione geografica, logica e procedurale dei backup critici.

La scala dell’exfiltration (149 TB) suggerisce inoltre che l’attacco non è stato una penetrazione improvvisa ma il risultato di un accesso sostenuto nel tempo. Durante il dwell time (periodo di permanenza), gli attaccatori hanno avuto il tempo di identificare, localizzare e esfiltrare i dati di massimo valore geopolitico prima di eseguire le operazioni di wiper.

Raccomandazioni di difesa

• Implementare una strategia di backup geograficamente distribuita con separazione logica e procedurale dai sistemi primari
• Stabilire un sistema di detection comportamentale focalizzato su volume-based anomalies (movimentazione anomala di dati in massa)
• Implementare encryption at-rest per tutti i backup critici, con gestione chiavi separata dai sistemi operativi
• Eseguire un threat hunt specificamente focalizzato su indicatori di accesso persistente da attori iraniani
• Aumentare la collaborazione tra agenzie governative regionali per identificare indicatori comuni di compromesso
• Sviluppare incident response protocols specifici per scenari di wiper-plus-exfiltration

L’operazione Handala rappresenta un’ulteriore escalation nella campagna iraniana di cyberguerra regionale. Con la Corea del Nord che diversifica gli attacchi verso il settore DeFi e l’Iran che consolida la sua capacità offensiva contro lo stato regionale, il 2026 è emergendo come anno critico di ricalibramento della strategia di cyberwarfare a livello globale.

Handala e la Cyber-Offensiva dell'Iran: 6 Petabyte distrutti e 149 Terabyte rubati dall'infrastruttura critica di Dubai - (in)sicurezza digitale

Il 12 aprile 2026, il gruppo Handala legato all'Iran ha attaccato l'infrastruttura critica di Dubai, distruggendo 6 petabyte di dati e rubando 149 terabyte di documenti classificati da tre istituzioni governative emiratine in un'operazione che rappre…

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-15 13:16:15

Agent Skills in .NET: tre paradigmi di composizione per gli agenti AI

Introduzione: L’evoluzione dei skill negli agent .NET

Gli agent AI richiedono un modo flessibile e modulare di estendere le loro capacità: questo è il ruolo dei skill. Con il framework Agent di Microsoft per .NET, gli sviluppatori dispongono di tre paradigmi complementari per definire e comporre skill, permettendo ai team di scegliere l’approccio più adatto al loro contesto.

I tre paradigmi per creare skill

1. Skill basati su file (File-Based Skills)

L’approccio più dichiarativo parte da una struttura di directory semplice. Ogni skill è organizzato come una cartella contenente:

• Un file SKILL.md con metadati nel frontmatter YAML
• Una sottocartella opzionale scripts/ con il codice eseguibile
• Una sottocartella opzionale references/ con documentazione di supporto

Questo paradigma è particolarmente vantaggioso per i team che vogliono gestire i skill come assets indipendenti dentro un repository condiviso. Il caricamento è automatico: l’agent scopre e carica i skill quando l’utente ne fa richiesta.

Ecco come si registra un provider file-based:

var skillsProvider = new AgentSkillsProvider(
    Path.Combine(AppContext.BaseDirectory, "skills"),
    SubprocessScriptRunner.RunAsync);

Il vantaggio decisivo è la separazione tra definizione del skill e implementazione. Non è necessario riconfigurare il codice C# per aggiungere nuovi skill; basta creare una nuova directory.

2. Skill basati su classe (Class-Based Skills)

Per chi preferisce la sicurezza dei tipi e il supporto IDE completo, gli skill basati su classe offrono un’alternativa fortemente tipizzata. Si eredita da AgentClassSkill<T> e si usano attributi di reflection per marcare le risorse e gli script:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
    [AgentSkillResource("available-plans")]
    public string AvailablePlans => "Plan A, Plan B, Plan C...";
    
    [AgentSkillScript("enroll")]
    private static string Enroll(string employeeId, string planCode)
    {
        // Logica di iscrizione
        return $"Iscrizione di {employeeId} al piano {planCode} completata";
    }
}

Questo approccio è ideale per skill complessi che richiedono logica C# sofisticata. Gli attributi [AgentSkillResource] e [AgentSkillScript] permettono al framework di scoprire automaticamente quali metodi e proprietà esporre all’agent.

Un vantaggio cruciale: i team possono sviluppare e distribuire skill indipendentemente come pacchetti NuGet, mantenendo il proprio ciclo di rilascio e permettendo il riuso tra progetti.

3. Skill inline (Inline Code-Defined Skills)

Il terzo paradigma è il più flessibile: skill definiti a runtime usando AgentInlineSkill. Sono perfetti per bridge temporanei, skill generati dinamicamente o implementazioni condizionate dallo stato dell’applicazione:

var timeOffSkill = new AgentInlineSkill(
    name: "time-off-balance",
    description: "Calcola i giorni di ferie e malattia rimanenti per un dipendente...")
    .AddScript("calculate-balance", (employeeId, leaveType) => 
    {
        // Logica runtime
        return $"Giorni rimanenti: {remaining}";
    });

I skill inline supportano anche risorse dinamiche:

.AddResource("policies", () => PolicyRepository.GetActivePolicies());

Questa capacità di aggiungere risorse come delegate è cruciale: le politiche possono aggiornarsi senza ricompilare l’applicazione.

Composizione flessibile con AgentSkillsProviderBuilder

La vera potenza del design emerge quando si combinano tutti e tre i paradigmi in un’unica applicazione. Il builder pattern permette una composizione dichiarativa:

var skillsProvider = new AgentSkillsProviderBuilder()
    .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
    .UseSkill(new BenefitsEnrollmentSkill())
    .UseSkill(timeOffSkill)
    .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
    .Build();

In questa configurazione:

• I skill nel filesystem vengono caricati e resi disponibili
• La classe BenefitsEnrollmentSkill registra i suoi metodi annotati
• Lo skill inline timeOffSkill aggiunge capacità runtime

Il framework astrae completamente il “come” carica ogni tipo di skill; l’agent li vede come una superficie unificata.

Funzionalità avanzate

Approvazione degli script

Per ambienti ad alto rischio, è possibile richiedere una revisione umana prima dell’esecuzione:

.UseScriptApproval(true)

In questo caso, l’agent formula il comando ma non lo esegue autonomamente; un operatore deve approvare.

Filtraggio di sicurezza

Quando si condividono directory di skill tra team, il filtraggio garantisce che solo gli skill approvati siano disponibili:

.UseFilter(skill => approvedSkills.Contains(skill.Frontmatter.Name))

Iniezione di dipendenze

I metodi degli skill possono ricevere IServiceProvider come parametro. Questo consente l’accesso a servizi registrati nel contenitore DI, indipendentemente dal paradigma di skill:

[AgentSkillScript("send-notification")]
private static string SendNotification(string userId, IServiceProvider services)
{
    var emailService = services.GetRequiredService<IEmailService>();
    return emailService.SendAsync(userId, "Notification");
}

Conclusione

Il design tripartito dei skill in .NET Agent Framework non è una complicazione: è un’architettura di composizione che rispetta gli usi diversi. Gli skill basati su file servono la semplicità e la dinamica; quelli basati su classe offrono sicurezza e riusabilità via NuGet; quelli inline forniscono agilità runtime.

Per i team che costruiscono sistemi agent complessi, questa flessibilità è fondamentale. Permette di iniziare in semplicità (skill inline), evolversi verso la modularità (skill basati su classe in NuGet) e mantenere agilità operativa (skill file-based per aggiustamenti dinamici) — tutto nello stesso agent, senza compromessi architetturali.

Fonte originale: Agent Skills in .NET: Three Ways to Author, One Provider to Run Them — Microsoft Agent Framework Blog

Agent Skills in .NET: Three Ways to Author, One Provider to Run Them | Microsoft Agent Framework

Your agents can now draw on skills authored in three different ways – as files on disk, as inline C# code, or as encapsulated classes – and combine them freely in a single provider.

^{Sergey Menshykh (Microsoft Agent Framework)}