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

(in)sicurezza digitale

2026-04-15 08:24:04

Drift Protocol: il più grande furto DeFi del 2026 perpetrato da hacker nord-coreani con una campagna di social engineering durata 6 mesi

Si parla di:
Toggle

• La campagna di social engineering: una sofisticazione raramente vista
• Il meccanismo di attacco: abuso della durable nonce
• Impatto geopolitico e implicazioni per la sicurezza DeFi
• Raccomandazioni difensive

Il 1° aprile 2026, gli hacker nord-coreani legati al gruppo UNC4736 hanno condotto uno dei più sofisticati attacchi di social engineering contro la piattaforma DeFi Drift Protocol, drenando ben 285 milioni di dollari e dimostrando la capacità dello stato-nazione di infiltrarsi negli ecosistemi finanziari decentralizzati. L’attacco, iniziato sei mesi prima in autunno del 2025, ha sfruttato le “durable nonces” di Solana per ottenere il controllo amministrativo della piattaforma.

La campagna di social engineering: una sofisticazione raramente vista

I threat actor nord-coreani hanno dimostrato una competenza tecnica straordinaria e una conoscenza approfondita del funzionamento di Drift Protocol. La campagna è iniziata con l’istituzione di un gruppo Telegram dove gli attaccanti hanno costruito una presenza operativa credibile all’interno dell’ecosistema. Per mesi, hanno intrattenuto conversazioni autentiche con i contributori di Drift riguardanti strategie di trading e integrazioni di vault, comportamenti indistinguibili da quelli di veri trader istituzionali. Gli attaccanti hanno depositato oltre 1 milione di dollari di propri fondi per aumentare la credibilità.

Questa fase preparatoria rappresenta un cambio fondamentale nelle tattiche di APT state-sponsored: da attacchi prevalentemente tecnici a operazioni ibride che combinano ingegneria sociale sofisticata con sfruttamento tecnico. Il gruppo, noto anche come AppleJeus, Citrine Sleet, Golden Chollima e Gleaming Pisces, ha dimostrato di comprendere a fondo i processi sociali interni alle organizzazioni target.

Il meccanismo di attacco: abuso della durable nonce

Una volta guadagnato l’accesso, gli attaccanti hanno sfruttato una caratteristica tecnica di Solana nota come “durable nonce” per indurre i membri del Drift Security Council a pre-firmare transazioni che avrebbero eventualmente loro trasferito il controllo amministrativo. Il passo successivo è stato cruciale: gli attaccatori hanno inserito nella whitelist un token artificiale e privo di valore (CVT) come collaterale valido. Hanno quindi depositato 500 milioni di token CVT e li hanno utilizzati per prelevare 285 milioni di dollari in asset reali inclusi USDC, SOL e ETH.

Timeline Attacco:
- Settembre 2025: Inizio social engineering
- Febbraio-Marzo 2026: Conversazioni integrate nel sistema
- 1 Aprile 2026: Esecuzione dell'attacco
- 12 minuti: Drenaggio di 285 milioni di dollari
- Poche ore: Bridging dei fondi verso Ethereum

Impatto geopolitico e implicazioni per la sicurezza DeFi

Questo attacco è il secondo più grande exploit nella storia di Solana, superato solo dal compromesso della Wormhole bridge di 326 milioni di dollari nel 2022. Rappresenta anche un’escalation allarmante nella strategia nord-coreana di acquisizione di valute estere per aggirare le sanzioni internazionali. La Corea del Nord è stata storicamente limitata nell’accesso al sistema finanziario globale, rendendo i furti da piattaforme DeFi un’alternativa redditizia per il finanziamento delle operazioni dello stato.

Gli esperti di sicurezza sono preoccupati dal precedente stabilito da questa operazione. Se gli attaccatori nord-coreani possono infiltrarsi con successo nelle più sofisticate piattaforme DeFi attraverso il social engineering, nessun ecosistema blockchain è completamente immune. Le implicazioni si estendono oltre la sicurezza tecnica: dimostrano come i processi umani rimangono il punto debole più critico anche nei sistemi decentralizzati progettati per eliminare la fiducia.

Raccomandazioni difensive

• Implementare un rigoroso processo di due diligence multi-strato per nuovi partner commerciali, inclusa la verifica in-person di identità
• Stabilire un team di analisti di minacce dediti a verificare la credibilità di nuove entità che richiedono accesso ai sistemi critici
• Utilizzare sistemi di multisig con controlli temporali per qualsiasi transazione che comporti il trasferimento di controllo amministrativo
• Implementare monitoraggio comportamentale per rilevare pattern anomali nelle transazioni pre-firmate
• Condurre red team esercizi regolari focalizzati su vettori di social engineering contro il personale chiave

Il compromesso di Drift Protocol dimostra che la Corea del Nord ha costruito le capacità tecniche e le risorse per condurre sofisticate operazioni cyberfinanza, rappresentando una minaccia crescente non solo per il settore DeFi ma per l’intero ecosistema blockchain globale.

Drift Protocol: il più grande furto DeFi del 2026 perpetrato da hacker nord-coreani con una campagna di social engineering durata 6 mesi - (in)sicurezza digitale

Il 1° aprile 2026, hacker nord-coreani hanno drenato 285 milioni di dollari da Drift Protocol attraverso una campagna di social engineering durata 6 mesi, sfruttando la durable nonce di Solana per ottenere il controllo amministrativo della piattaform…

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

ᴮᵉⁿ ᴿᵒʸᶜᵉVOTE IN THE PRIMARIES

2026-04-14 23:21:53

Mylena Masache and the #frog #species she discovered *while an undergrad* at Pontificia Universidad Católica del #Ecuador in #Quito

She and her colleagues named the frog after Neisi Dajomes, the first Ecuadorian woman to win Olympic gold, at the Tokyo 2020 Games: Nymphargus dajomesae

The species is a glassfrog and is a sign of a much larger #amphibian hotspot in the Cordillera del Cóndor

Mylena is now in grad school at UC Berkeley

journals.plos.org/plosone/arti…

#science #biology #zoology

A secret from a hidden world: A new glassfrog of the genus Nymphargus (Anura: Centrolenidae) from Cordillera del Cóndor, Ecuador

The genus Nymphargus is the most speciose of the family Centrolenidae with 44 species. In this study, we describe a new species of Nymphargus and present an updated phylogeny.

^{journals.plos.org}

Spcnet.it

2026-04-14 12:10:20

Azure MCP Server 2.0: 276 strumenti per integrare Azure negli agenti AI

Il Model Context Protocol (MCP) sta rapidamente diventando lo standard de facto per consentire agli agenti AI di interagire con servizi e strumenti esterni. Microsoft ha appena rilasciato la versione 2.0 stabile di Azure MCP Server, un passo significativo che porta a 276 strumenti distribuiti su 57 servizi Azure direttamente accessibili da qualsiasi agente o IDE compatibile con MCP.

Cos’è Azure MCP Server?

Azure MCP Server è un’implementazione del Model Context Protocol che funge da ponte tra gli agenti AI e l’ecosistema Azure. Invece di dover scrivere codice di integrazione personalizzato per ogni servizio, un agente AI può semplicemente “scoprire” e utilizzare i tool messi a disposizione dal server MCP, che includono operazioni di provisioning, deployment, monitoraggio e diagnostica su decine di servizi Azure.

L’idea centrale è quella di rendere le operazioni su Azure talmente naturali per un agente AI quanto lo è per un programmatore umano navigare sul portale Azure o usare la CLI. La versione 2.0 segna la transizione da una release preview a un prodotto stabile e pronto per l’uso in produzione.

Le principali novità della versione 2.0

Deployment remoto self-hosted

La novità più significativa di questa release è il supporto al deployment remoto. Nelle versioni precedenti, il server MCP doveva girare localmente sulla macchina dello sviluppatore. Con la 2.0, è possibile distribuire Azure MCP Server come servizio centralizzato, accessibile da tutto il team o dall’intera organizzazione tramite trasporto HTTP.

Questo cambia radicalmente le possibilità di adozione enterprise: invece di configurare ogni sviluppatore individualmente, il team di platform engineering può mantenere un’istanza centralizzata con configurazione e governance coerenti. Meno deriva di configurazione, più sicurezza, un unico punto di aggiornamento.

Integrazione con Microsoft Foundry e flusso OBO

La versione 2.0 introduce il supporto per il flusso On-Behalf-Of (OBO), noto anche come OpenID Connect delegation. Questo meccanismo consente al server MCP di chiamare le API Azure usando il contesto dell’utente autenticato, mantenendo la separazione delle identità e rispettando i permessi RBAC assegnati al singolo utente.

L’integrazione con Microsoft Foundry consente di usare le managed identity direttamente, semplificando la gestione delle credenziali in ambienti cloud-native senza dover gestire segreti esplicitamente.

Security hardening

Con il passaggio a stable, Microsoft ha rafforzato significativamente la sicurezza del server:

• Validazione endpoint più rigorosa
• Protezioni contro pattern di injection nei tool di query
• Controlli di isolamento più stringenti

Questi miglioramenti sono essenziali per l’adozione in contesti enterprise dove la superficie di attacco deve essere minimizzata.

Supporto sovereign cloud

Azure MCP Server 2.0 è ora configurabile per operare su Azure US Government e Azure operated by 21Vianet (il cloud sovrano cinese), ampliando notevolmente la portata per organizzazioni soggette a requisiti di sovranità dei dati.

Come installare e usare Azure MCP Server

Il server è disponibile attraverso diversi canali di distribuzione, adatti a scenari diversi:

Via IDE extension

La via più semplice per gli sviluppatori è attraverso le estensioni per i principali IDE:

• Visual Studio Code
• Visual Studio
• IntelliJ / Eclipse
• Cursor

Una volta installata l’estensione, il server MCP viene configurato automaticamente e i tool Azure diventano disponibili nell’assistente AI del tuo IDE.

Via GitHub Copilot CLI o Claude Code

Per chi lavora da terminale, Azure MCP Server si integra nativamente con GitHub Copilot CLI e Claude Code, consentendo di gestire risorse Azure direttamente dalla riga di comando con il supporto dell’AI.

Via Docker (deployment self-hosted)

Per il deployment remoto centralizzato, Microsoft fornisce un’immagine Docker ufficiale:

# Scarica l'immagine Docker
docker pull mcr.microsoft.com/azure-mcp-server:latest

# Esegui il server localmente
docker run -p 8080:8080 mcr.microsoft.com/azure-mcp-server:latest


La documentazione completa per il self-hosting è disponibile su aka.ms/azmcp/self-host.

Panoramica degli strumenti disponibili

Con 276 tool distribuiti su 57 servizi Azure, la copertura è notevolmente ampia. Gli strumenti coprono l’intero ciclo di vita delle risorse cloud:

• Provisioning e deployment: creare e configurare risorse Azure (VM, App Service, AKS, ecc.)
• Monitoraggio e diagnostica: interrogare Azure Monitor, Log Analytics, Application Insights
• Gestione identità: interagire con Microsoft Entra ID, gestire service principal e managed identity
• Storage e database: operazioni su Blob Storage, Cosmos DB, Azure SQL
• Networking: configurazione di VNet, DNS, load balancer
• Servizi AI: integrazione con Azure OpenAI, AI Foundry, Cognitive Services

Implicazioni per il workflow degli sviluppatori

L’arrivo di Azure MCP Server 2.0 stabile ha implicazioni concrete per i team di sviluppo che usano Azure:

Meno context switching: gli sviluppatori possono interrogare lo stato dei loro servizi Azure, diagnosticare problemi e persino deployare aggiornamenti senza uscire dall’IDE o passare al portale Azure.

Automazione conversazionale: invece di ricordare i comandi esatti della Azure CLI, è possibile descrivere in linguaggio naturale l’operazione desiderata e lasciare che l’agente AI formuli la chiamata corretta al tool MCP.

Governance centralizzata: con il deployment self-hosted, le organizzazioni possono controllare centralmente quali tool sono disponibili, chi può usarli e in che contesto, mantenendo audit trail completi.

Conclusione

Azure MCP Server 2.0 rappresenta un passo maturo verso l’integrazione dell’AI nei workflow operativi su cloud. Il supporto al deployment remoto e al flusso OBO erano i due tasselli mancanti per l’adozione enterprise, e la loro disponibilità in una release stabile apre scenari concreti di adozione su larga scala.

Per i team che già usano GitHub Copilot o altri agenti AI nel loro IDE, la barriera di ingresso è minima: basta installare l’estensione e il ricco catalogo di tool Azure diventa immediatamente disponibile. Per chi vuole andare oltre, il deployment self-hosted offre la flessibilità necessaria per integrarlo nei flussi platform engineering più sofisticati.

Fonte originale: Announcing Azure MCP Server 2.0 Stable Release — Sandeep Sen, Microsoft Azure SDK Blog

Announcing Azure MCP Server 2.0 Stable Release for Self-Hosted Agentic Cloud Automation

Azure MCP Server 2.0 introduces self‑hosted remote deployment for secure agentic workflows using standardized tools across Azure services.

^{Sandeep Sen (Azure SDK Blog)}

(in)sicurezza digitale

2026-04-14 12:08:51

Phishing SPID contro le Pubbliche Amministrazioni: CERT-AGID smonta la campagna che usa siti WordPress legittimi per rubare credenziali istituzionali

Un’istanza WordPress compromessa, loghi dell’Agenzia delle Entrate e del Sistema Pubblico d’Identità Digitale riprodotti con precisione millimetrica, link personalizzati con l’email della vittima pre-compilata: CERT-AGID ha rilevato una nuova campagna di phishing che prende di mira le Pubbliche Amministrazioni italiane, con l’obiettivo di sottrarre credenziali SPID e accessi istituzionali. L’analisi tecnica rivela un attacco che sfrutta l’infrastruttura legittima per eludere i filtri antispam e conquistare la fiducia delle vittime.

Il Vettore: un’infrastruttura legittima trasformata in arma

Il primo elemento che distingue questa campagna dalle operazioni di phishing più rudimentali è la scelta dell’infrastruttura. Gli attaccanti non hanno registrato domini malevoli evidenti — hanno invece compromesso un server WordPress legittimo (documentato all’indirizzo wp-dev.typhur.com/agenziaentrate/), sfruttandone la reputazione consolidata per eludere i filtri antispam e i sistemi di blacklist automatici.

Un sito web legittimo offre agli attaccanti tre vantaggi competitivi fondamentali: certificati HTTPS validi che mostrano il lucchetto verde nel browser delle vittime, una reputazione di dominio già stabilita che bypassa i filtri di sicurezza email, e la capacità di ospitare contenuto HTML arbitrario che replica fedelmente le interfacce istituzionali italiane. Il vettore di compromissione del WordPress è quasi certamente legato a plugin o temi non aggiornati — il vettore più comune per questo tipo di hijacking.

Anatomia dell’attacco: come funziona la truffa SPID

La catena di attacco documentata da CERT-AGID si articola in più fasi progettate per massimizzare la credibilità e minimizzare i campanelli d’allarme per la vittima:

• Fase 1 — Email di spearphishing personalizzata: la vittima riceve una comunicazione che la invita ad accedere alla propria area riservata dell’Agenzia delle Entrate-Riscossione. Il link contenuto nell’email è personalizzato e include già l’indirizzo email del destinatario come parametro URL.
• Fase 2 — Pagina di login pre-compilata: cliccando il link, la vittima atterra su una pagina che replica fedelmente il portale dell’Agenzia delle Entrate, completa di loghi ufficiali di AdE, SPID e AgID. La casella email è già compilata con il proprio indirizzo — un elemento che abbassa drasticamente il livello di sospetto e aumenta la probabilità di inserimento della password.
• Fase 3 — Harvesting delle credenziali: al momento dell’invio, la password viene trasmessa ai server degli attaccanti. La vittima viene quindi reindirizzata al sito reale dell’Agenzia delle Entrate dove appare un messaggio di errore simulato — un “errore di sistema generico” che rende plausibile la necessità di reinserire le credenziali.
• Fase 4 — Accesso istituzionale: con le credenziali SPID compromesse, gli attaccanti ottengono potenzialmente accesso a tutti i servizi della Pubblica Amministrazione collegati all’identità digitale: portali fiscali, documenti istituzionali, sistemi interni delle PA.

Target primario: Pubbliche Amministrazioni

L’aspetto più allarmante della campagna, come sottolineato da CERT-AGID, è la natura del target primario: non utenti consumer generici, ma dipendenti e funzionari delle Pubbliche Amministrazioni italiane. Questa scelta non è casuale. Le credenziali SPID di un funzionario PA offrono un accesso privilegiato a sistemi interni, documenti riservati e portali interistituzionali che un account privato non avrebbe. La compromissione di un account PA può diventare il punto di partenza per movimenti laterali all’interno dei sistemi governativi, attacchi BEC (Business Email Compromise) verso altre istituzioni, e persino accessi a dati sensibili di cittadini.

MITRE ATT&CK: mappatura delle tecniche

• T1566.002 — Phishing: Spearphishing Link: link personalizzati con l’email della vittima pre-inserita per massimizzare la credibilità
• T1078 — Valid Accounts: compromissione di account SPID legittimi per accesso a sistemi istituzionali
• T1190 — Exploit Public-Facing Application: compromissione del server WordPress tramite vulnerabilità in plugin/temi per uso come infrastruttura di phishing
• T1036 — Masquerading: replica accurata dell’interfaccia di portali governativi legittimi (AdE, SPID, AgID)
• T1589.002 — Gather Victim Identity Information: Email Addresses: utilizzo di indirizzi email pre-identificati nei link personalizzati

Indicatori di Compromissione (IoC)

# Domini malevoli identificati
agenziadelleentrate.live          # Dominio typosquatting principale
wp-dev.typhur.com/agenziaentrate/ # WordPress compromesso usato come host
# Dominio mittente email
@propiski.com                     # Utilizzato come sender domain nelle email di phishing
# Dominio di reindirizzamento
sushicool.net                     # Usato come redirect dopo la sottrazione delle credenziali
# File IoC ufficiale CERT-AGID
phishing_AdE_10_04_26.json        # Disponibile tramite feed ufficiale CERT-AGID

Il contesto: una campagna seriale contro l’Identità Digitale italiana

Questa campagna non nasce dal nulla. L’Agenzia delle Entrate ha emesso un avviso ufficiale già il 30 marzo 2026, segnalando campagne attive che sfruttano impropriamente i loghi di AdE, SPID e AgID. La storia recente mostra un pattern ricorrente: gli attori malevoli hanno identificato nel sistema SPID un bersaglio appetibile perché rappresenta la chiave di accesso unificata ai servizi digitali della PA italiana. Compromettere uno SPID significa potenzialmente accedere a decine di portali governativi con un’unica credenziale.

La tecnica di compromissione di siti WordPress legittimi come piattaforma di phishing è altrettanto consolidata: consente di sfruttare la reputazione del dominio ospitante e i certificati TLS validi per superare i controlli automatici, scaricando il costo di mantenimento dell’infrastruttura sull’ignaro proprietario del sito compromesso.

Raccomandazioni per i difensori e le Pubbliche Amministrazioni

• MFA obbligatoria su tutti gli account istituzionali: l’autenticazione a due fattori vanifica il phishing di credenziali anche quando la vittima inserisce username e password sulla pagina falsa
• Formazione specifica sul phishing SPID: i dipendenti PA devono sapere che l’Agenzia delle Entrate non chiede mai credenziali via email; l’accesso ai portali fiscali va effettuato sempre digitando manualmente l’URL o utilizzando bookmark certificati
• Monitoraggio del feed IoC CERT-AGID: l’integrazione automatica del feed JSON di CERT-AGID nei propri sistemi di sicurezza permette il blocco in tempo reale dei domini malevoli identificati
• Verifica dell’URL nel browser: prima di inserire qualsiasi credenziale SPID, verificare che l’URL nella barra del browser corrisponda esattamente al dominio ufficiale (agenziaentrate.gov.it)
• Audit CMS e aggiornamento plugin: le organizzazioni che gestiscono siti WordPress devono implementare processi di patch management rigorosi per evitare che le proprie infrastrutture vengano weaponizzate come piattaforme di phishing
• Segnalazione a CERT-AGID: eventuali email sospette che impersonano l’Agenzia delle Entrate vanno segnalate immediatamente all’indirizzo dedicato di CERT-AGID per l’aggiornamento del feed IoC

Il CERT-AGID ha già avvisato le organizzazioni coinvolte e richiesto il takedown delle pagine di phishing identificate. Tuttavia, data la natura delle campagne di phishing — che spesso cambiano rapidamente infrastruttura per sopravvivere ai takedown — il monitoraggio continuo rimane essenziale.