Spcnet.it

2026-05-27 16:35:17

SQL Server 2025 e Azure SQL: vettori, modelli AI nativi e agenti autonomi nel database

SQL Server 2025: un database nativamente AI

Con il rilascio di SQL Server 2025 (versione 17.x) e i progressivi aggiornamenti di Azure SQL Database, Microsoft ha compiuto un salto qualitativo radicale: non si tratta più di integrare l’intelligenza artificiale come funzionalità accessoria, ma di rendere il database stesso una piattaforma AI di prima classe. Vettori, modelli esterni, agenti autonomi e GitHub Copilot nel gestore dello studio: in questo articolo esploriamo tutto ciò che i professionisti IT devono conoscere.

Tipo di dato VECTOR e ricerca semantica con DiskANN

Il cambiamento più strutturale è l’introduzione del tipo di dato nativo VECTOR, supportato dall’indice DiskANN (Disk-based Approximate Nearest Neighbor), un algoritmo ottimizzato per la ricerca di similarità in grandi dataset ad alta dimensionalità.

Un vettore di embedding è una rappresentazione numerica densa di un contenuto (testo, immagine, documento) in uno spazio ad alta dimensionalità. SQL Server 2025 supporta vettori fino a 1536 dimensioni, compatibili con i modelli di embedding Azure OpenAI come text-embedding-3-large.

-- Creazione tabella con colonna vettoriale
CREATE TABLE Documenti (
    Id INT PRIMARY KEY,
    Testo NVARCHAR(MAX),
    Embedding VECTOR(1536)
);

-- Ricerca di similarità semantica tramite distanza coseno
SELECT TOP 5
    Id,
    Testo,
    VECTOR_DISTANCE('cosine', Embedding, @queryEmbedding) AS Distanza
FROM Documenti
ORDER BY Distanza ASC;

La funzione VECTOR_DISTANCE supporta le metriche cosine, euclidean e dot. In marzo 2026 Microsoft ha annunciato ulteriori ottimizzazioni tramite quantizzazione (riduzione della precisione vettoriale per risparmiare storage e accelerare il calcolo) e iterative filtering, disponibili sia su Azure SQL Hyperscale che su SQL Database in Microsoft Fabric.

CREATE EXTERNAL MODEL: modelli AI come oggetti database

Una delle novità più significative per gli sviluppatori è la possibilità di registrare modelli AI esterni come oggetti database di prima classe, con la stessa dignità di una tabella o di una view.

-- Registrazione di un modello Azure OpenAI come external model
CREATE EXTERNAL MODEL AzureOpenAI_Ada
WITH (
    LOCATION = 'https://mio-endpoint.openai.azure.com/',
    API_KEY = 'secret-key',
    API_TYPE = 'azure_openai',
    DEPLOYMENT = 'text-embedding-ada-002',
    TASK = 'EMBEDDINGS'
);

Una volta registrato, il modello è disponibile per tutte le query T-SQL dell’istanza, con gestione automatica del retry per i fallimenti transitori e supporto per il versioning (A/B testing tra deployment diversi).

La stored procedure sp_invoke_external_rest_endpoint consente invece di chiamare qualsiasi API REST direttamente da T-SQL, incluse OpenAI, Azure OpenAI, Anthropic e anche modelli locali come Ollama:

EXEC sp_invoke_external_rest_endpoint
    @url = 'https://api.openai.com/v1/embeddings',
    @method = 'POST',
    @headers = '{"Authorization": "Bearer sk-xxx", "Content-Type": "application/json"}',
    @payload = '{"input": "testo da vettorializzare", "model": "text-embedding-3-small"}',
    @response = @json OUTPUT;

RAG nativo: addio al database vettoriale separato

Il pattern Retrieval-Augmented Generation (RAG) — recuperare contesto rilevante da una base di conoscenza per arricchire il prompt di un LLM — si implementa ora interamente all’interno di SQL Server, senza bisogno di database vettoriali separati come Pinecone, Milvus o Weaviate.

Il flusso tipico è:

1. Inserire i documenti nella tabella con colonna VECTOR
2. Generare gli embedding tramite CREATE EXTERNAL MODEL o sp_invoke_external_rest_endpoint
3. Archiviare i vettori nella stessa tabella dei dati operativi
4. Al momento della query, vettorializzare il testo dell’utente e cercare i k documenti più simili con VECTOR_DISTANCE
5. Passare i documenti recuperati come contesto all’LLM

Questo approccio elimina la complessità della sincronizzazione tra il database relazionale e quello vettoriale, riducendo la latenza e semplificando enormemente la gestione della sicurezza (un solo perimetro di autorizzazione).

Per scenari ibridi, è disponibile anche l’integrazione con Azure AI Search, che combina full-text search tradizionale con ricerca vettoriale semantica.

Agenti AI autonomi e GitHub Copilot in SSMS 22

SQL Server 2025 introduce il concetto di agente AI integrato nel database: un componente che riceve richieste in linguaggio naturale, le traduce in T-SQL, le esegue e ragiona sui risultati per determinare i passi successivi, rispettando il modello di sicurezza e i permessi SQL Server.

Azure SQL Database Hyperscale espone un SQL MCP Server (endpoint Model Context Protocol, ora in public preview), che consente ad agenti AI e Copilot di connettersi al database e ragionare sui dati SQL per applicazioni cloud-native.

GitHub Copilot in SSMS 22 è diventato generalmente disponibile l’11 novembre 2025. Le funzionalità principali:

• Chat in linguaggio naturale per interrogare il database o costruire query T-SQL
• Slash command: /doc per la documentazione, /fix per la correzione errori, /explain per la spiegazione di query complesse
• Database instructions: contesto specifico del database e regole di business memorizzati come extended properties, che Copilot applica automaticamente
• Autocompletamento contestuale nell’editor query (disponibile dalla versione SSMS 22.2.1, rilasciata il 21 gennaio 2026)

Machine Learning Services e integrazione con i framework AI

SQL Server Machine Learning Services — disponibile sin da SQL Server 2016 con R e poi Python — continua a essere supportata in SQL Server 2025. Permette di eseguire script Python e R in-database, senza spostare i dati fuori da SQL Server, mantenendo il perimetro di sicurezza e riducendo l’overhead di rete.

SQL Server 2025 aggiunge il supporto ai principali framework di orchestrazione AI:

• LangChain: il pacchetto langchain-sqlserver abilita chatbot con pattern RAG sui dati SQL, con orchestrazione tramite LangChain e UI via Chainlit
• Semantic Kernel: SDK open source Microsoft per .NET (e altri linguaggi), include un connettore nativo per il vector store di SQL Server, permettendo di costruire agenti e applicazioni RAG che chiamano modelli, strumenti e SQL Server in modo integrato
• LSTM e architetture ibride: l’integrazione con Long Short-Term Memory offre un framework per agenti che devono mantenere stato contestuale su sequenze di interazioni

Copilot in Azure SQL Database

Microsoft Copilot in Azure SQL Database — in GA dall’11 aprile 2025 — offre esperienze AI-assisted per DBA e sviluppatori:

• Risposta a domande sulle performance del database in linguaggio naturale
• Troubleshooting tramite Dynamic Management Views e Query Store
• Generazione T-SQL da descrizioni plain-text con spiegazione dettagliata delle query
• Code completion nell’editor query di Fabric e quick actions per fix/explain

Il sistema analizza i metadati del database (nomi tabelle, colonne, struttura) per generare suggerimenti contestuali senza accedere ai dati effettivi.

Requisiti e disponibilità

Le funzionalità core — tipo VECTOR, CREATE EXTERNAL MODEL, sp_invoke_external_rest_endpoint — richiedono:

• On-premises: SQL Server 2025 (17.x)
• Azure SQL Database: tier Hyperscale
• Azure SQL Managed Instance: policy di aggiornamento Always-up-to-date o SQL Server 2025
• GitHub Copilot in SSMS: SSMS 22 o superiore, account GitHub con Copilot attivo
• Azure OpenAI: risorsa con modelli di embedding distribuiti (text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002)

In marzo 2026 Microsoft ha aggiunto: Database Hub in Microsoft Fabric (early access), SQL MCP Server per Azure SQL Hyperscale (public preview), e opzioni vCore più ampie (160 e 192) per Hyperscale. È stato anche annunciato un savings plan per database con risparmio fino al 35% rispetto al pay-as-you-go su impegno annuale.

Conclusione

SQL Server 2025 non è un semplice aggiornamento di versione: è il risultato di una strategia pluriennale per trasformare il database relazionale in un motore AI nativo. Per i professionisti IT che già operano nell’ecosistema Microsoft, le implicazioni sono concrete: è possibile implementare ricerca semantica, RAG, agenti autonomi e assistenza AI alle query senza aggiungere infrastrutture esterne, riutilizzando il perimetro di sicurezza e la governance già in essere su SQL Server.

La sfida è ora architetturale: capire dove ha senso spostare logica AI dentro il database e dove invece mantenerla nell’application layer. Ma avere questa scelta — e i tool per implementarla — è già un notevole passo avanti.

---

Fonte originale: AI features in Microsoft SQL Server 2025 and Azure SQL – 4sysops

AI features in Microsoft SQL Server 2025 and Azure SQL

Microsoft SQL Server 2025 and Azure SQL Database introduce comprehensive artificial intelligence capabilities that transform how you build intelligent applications.

^{IT Experts (4sysops)}

(in)sicurezza digitale

2026-05-27 16:36:23

Nimbus Manticore e il backdoor MiniFast: l’Iran usa l’IA per colpire aviazione e oil&gas durante la guerra

Mentre i cacciabombardieri statunitensi e israeliani colpivano obiettivi nucleari iraniani nel febbraio 2026, dall’altra parte del fronte cibernetico il gruppo Nimbus Manticore — affiliato ai Pasdaran (IRGC) — non rallentava. Accelerava. Tre ondate di attacchi in tre mesi, un nuovo backdoor sviluppato con l’ausilio dell’intelligenza artificiale, tecniche d’infezione mai viste prima: è quanto emerge dall’analisi congiunta pubblicata da Check Point Research e confermata da Palo Alto Networks Unit 42.

Il contesto: cyberoperazioni in tempo di guerra

Il 28 febbraio 2026 gli Stati Uniti e Israele hanno avviato Operation Epic Fury, la campagna militare che ha colpito le infrastrutture nucleari iraniane. Nelle stesse ore, Nimbus Manticore — già noto per campagne contro aviazione, difesa e telecomunicazioni con il malware MiniJunk — ha dimostrato una capacità di adattamento operativo senza precedenti: anzichè fermarsi, il gruppo ha sviluppato e distribuito nuovi strumenti offensivi nel mezzo del conflitto.

Il gruppo (tracciato anche come UNC1549 e Screening Serpens) è stato attivo in almeno cinque paesi — USA, Israele, Emirati Arabi Uniti, Arabia Saudita, Australia — colpendo aziende del settore aerospaziale, petrolifero, software e delle telecomunicazioni. Tra i bersagli identificati da Unit 42 figura anche un’azienda statunitense del settore oil & gas.

Tre ondate di attacchi: febbraio, marzo, aprile 2026

Prima ondata (febbraio 2026) — AppDomain Hijacking + MiniJunk. Prima ancora dello scoppio del conflitto, il gruppo prendeva di mira dipendenti di aziende software e aerospaziali in Arabia Saudita e Australia con false offerte di lavoro. Le vittime venivano indotte a scaricare un archivio ZIP ospitato su OnlyOffice contenente un eseguibile Microsoft legittimo (Setup.exe) e un file di configurazione .config modificato. Questa tecnica — chiamata AppDomain Hijacking — abusa del runtime .NET per far caricare una DLL malevola al posto di una legittima, in modo silenzioso. Il payload finale era una nuova variante di MiniJunk.

Seconda ondata (marzo 2026) — Trojanized Zoom + MiniFast. In piena guerra, Nimbus Manticore ha introdotto un installer Zoom manomesso, probabilmente distribuito tramite false convocazioni a meeting video. Il flusso di infezione è sofisticato: il loader di primo stadio monitora in loop la creazione dello scheduled task legittimo ZoomUpdateTaskUser-<SID> generato dall’installer originale, e quando viene creato lo hijacka, modificandolo per eseguire il secondo stadio. La persistenza si mimetizza perfettamente nel sistema operativo. Il payload finale è il nuovo backdoor MiniFast.

Terza ondata (aprile 2026) — SEO Poisoning + SQL Developer falso. Per la prima volta nel modus operandi del gruppo, nessun spear-phishing: il vettore è la ricerca su motore di ricerca. Nimbus Manticore ha registrato decine di domini satellite che puntano a getsqldeveloper[.]com, un sito clone della pagina di download di Oracle SQL Developer. Grazie a keyword stuffing e link-building artificiale, il dominio malevolo scalava le SERP di Bing e DuckDuckGo. Chiunque cercasse il software legittimo poteva ricevere un installer armato con MiniFast.

MiniFast: il backdoor scritto con l’IA

MiniFast è una DLL PE a 64 bit che espone una singola export (CheckForUpdates) come entry point. La backdoor è progettata per la persistenza a lungo termine e l’esecuzione remota di comandi. Comunica con il C2 via HTTP, impersonando Chrome con un hardcoded User-Agent (Mozilla/5.0 ... Chrome/146.0.0.0) per confondersi col traffico legittimo.

Check Point ha identificato segnali inequivocabili dell’uso di strumenti AI nella fase di sviluppo: gestione degli errori eccessiva anche su chiamate API triviali come GetUserName, naming delle funzioni verboso e descrittivo, messaggi di debug embedded, organizzazione modulare nonostante la semplicità del codice. Queste caratteristiche sono tipiche del codice assistito da LLM e indicano una pipeline che sfrutta l’IA per accelerare i cicli di rilascio malware.

L’architettura di comunicazione con il C2 segue un pattern API-style con scambio JSON. Gli endpoint includono POST /rg per l’handshake iniziale con identificativo vittima, POST /agent/init per la registrazione dell’host, GET /agent/poll?token= per il recupero dei task (con strutture binarie Base64-encoded), POST /agent/result per l’upload dei risultati, PUT /upload/ per l’esfiltrazione file e GET /files/ per il download dal C2.

Il set di comandi implementati copre un ampio spettro: listing directory, esecuzione shell tramite cmd.exe, enumerazione processi, upload/download file, kill process per PID, caricamento dinamico di DLL, creazione archivi ZIP, escalation privilegi con runas, e installazione di persistenza tramite scheduled task denominato WindowsSecurityUpdate. Il polling interval e il jitter sono regolabili da remoto, rendendo il beacon adattivo e difficile da rilevare con euristiche fisse.

Implicazioni geopolitiche

“Le loro ambizioni si estendevano ben oltre lo spionaggio in Medio Oriente,” ha dichiarato Sergey Shykevich di Check Point Research. “Hanno costruito e distribuito un backdoor completamente nuovo nel mezzo del conflitto, mentre le operazioni erano attivamente in corso. E hanno lanciato una terza ondata con un playbook completamente diverso — senza mai fermarsi tra febbraio e aprile.”

La velocità di adattamento di Nimbus Manticore suggerisce che il conflitto cinetico ha funzionato da acceleratore per le operazioni cyber. L’integrazione di AI nella catena di sviluppo malware riduce i tempi dal concept al deploy, rendendo le signature tradizionali basate su hash o pattern statici più rapidamente obsolete. I settori maggiormente a rischio rimangono aviazione, difesa, telecomunicazioni e oil & gas in USA, Europa e Medio Oriente.

Dal punto di vista difensivo, è raccomandabile monitorare il caricamento di DLL non firmate da %AppData% in processi .NET, verificare l’integrità degli scheduled task dopo installazioni software, e filtrare l’accesso a domini registrati di recente che mimano portali di download di software enterprise (SQL Developer, Zoom, Adobe, etc.).

Indicatori di Compromissione (IoC)

# SHA256 — MiniFast, loader e dropper associati
10fd541674adadfbba99b54280f7e59732746faf2b10ce68521866f737f1e46d
eee657ffdb2af8ed6412221e7d5fbf4f5742f2ac2c88f43f12db46af0697de71
781605ce9d4a9869e846f6c9657d71437cb6240ab27ffbc4cd550c0e06996690
2c214494fd0bad31473ca8adce78a4f50847876584571e66aadeae70827ec2dc
f08b17856616d66492a24dced27f788e235f35f42fa7cd10f315000d3a2f4c03
a57ffb819fe8d98ff925c5d7b239598fe302acf5a13193d7a535040a71298fdf
63d0d3c4a7f71bdbca720903d6a99b832089cc093c64d2938e7e001e56c17ab4
74882085db2088356ed7f72f01e0404a0a98cda88ef56fb15ce74c1f36b26d27
bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad
ecaf493c320d201d285ef5f61d75744216e47cf1115b4af528f9a78883cc446e
44f4f7aca7f1d9bfdaf7b3736934cbe19f851a707662f8f0b0c49b383e054250
0db36a04d304ad96f9e6f97b531934594cd95a5cea9ff2c9af249201089dc864
# Domini C2 e siti di distribuzione
getsqldeveloper[.]com
business-startup[.]org
business-startup.azurewebsites[.]net
PremierHealthAdvisory[.]com
ramiltonsfinance[.]com
globalitconsultants.azurewebsites[.]net
global-it-consultants.azurewebsites[.]net
nanomatrix.azurewebsites[.]net
licencemanagers.azurewebsites[.]net
peerdistsvcmanagers.azurewebsites[.]net
buisness-centeral-transportation[.]com
# Certificati code-signing abusati
Gray Matter Software S.R.L.
Kirubel Kerie Negeya
# Scheduled task di persistenza creato da MiniFast
WindowsSecurityUpdate

Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns

Unit 42 details Screening Serpens' use of AppDomainManager hijacking and new RAT variants to target tech and defense sectors in recent campaigns.

^{Unit 42}

Spcnet.it

2026-05-27 12:38:29

Runtime Async in .NET 11 Preview 1: addio alle state machine del compilatore

Introduzione

Con il rilascio di .NET 11 Preview 1, Microsoft ha introdotto uno dei cambiamenti architetturali più significativi nella storia dell’async in .NET: il Runtime Async V2. Questo cambiamento sposta la responsabilità della gestione delle operazioni asincrone dal compilatore al runtime stesso, con impatti concreti su debug, profiling, leggibilità degli stack trace e potenzialmente sulle prestazioni.

In questo articolo analizziamo nel dettaglio come funziona il nuovo modello, come differisce dall’approccio attuale basato su state machine, come abilitarlo nei propri progetti e cosa aggiunge .NET 11 Preview 1 oltre al solo Runtime Async.

Il problema: le state machine del compilatore

Chiunque abbia lavorato seriamente con codice asincrono in C# conosce la frustrazione di leggere uno stack trace in produzione e trovarsi sommerso da frame generati dal compilatore. Ogni metodo async viene trasformato dal compilatore in una classe di stato (state machine) che implementa IAsyncStateMachine. Questa trasformazione è efficace, ma introduce livelli di indirezione che offuscano la reale catena di chiamate.

Un semplice stack di tre metodi async produce tipicamente oltre dieci frame nello stack trace live, la maggior parte appartenenti all’infrastruttura del compilatore (AsyncMethodBuilderCore.Start, ecc.). Il risultato è un debug più laborioso e strumenti di profiling che faticano a restituire una visione chiara dell’esecuzione.

Runtime Async V2: come funziona

Con Runtime Async, il compilatore non genera più la state machine. Emette invece un IL semplificato, annotato con [MethodImpl(MethodImplOptions.Async)], e delega al runtime la gestione della sospensione e ripresa dei metodi asincroni. In pratica, è il CLR stesso a tracciare l’esecuzione asincrona, non il codice generato dal compilatore.

Il risultato più visibile è nei live stack trace, ovvero ciò che profiler, debugger e new StackTrace() vedono durante l’esecuzione. Con Runtime Async, i metodi effettivi appaiono direttamente nello stack, senza wrapper di stato.

Confronto diretto degli stack trace

Consideriamo questo codice di esempio:

await OuterAsync();

static async Task OuterAsync()
{
    await Task.CompletedTask;
    await MiddleAsync();
}

static async Task MiddleAsync()
{
    await Task.CompletedTask;
    await InnerAsync();
}

static async Task InnerAsync()
{
    await Task.CompletedTask;
    Console.WriteLine(new StackTrace(fNeedFileInfo: true));
}

Senza Runtime Async — 13 frame, con tutta l’infrastruttura del compilatore visibile:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__InnerAsync|0_2()
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__MiddleAsync|0_1()
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
...
(13 frame totali)

Con Runtime Async — 5 frame, la reale catena di chiamate:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
at Program.<Main>$(String[] args) in Program.cs:line 3
at Program.<Main>(String[] args)

È importante notare che questo miglioramento riguarda i live stack trace. Gli exception stack trace (catch (Exception ex)) già apparivano in modo pulito grazie all’ExceptionDispatchInfo nelle versioni precedenti.

Miglioramenti al debugging

Con Runtime Async, il debugger può finalmente fare ciò che ci si aspetterebbe da sempre:

• I breakpoint all’interno di metodi async si associano correttamente, senza essere deviati su codice generato
• È possibile fare step-through attraverso i boundary degli await senza “saltare” nell’infrastruttura del compilatore
• La finestra call stack del debugger mostra la catena reale, non i wrapper di stato

Questi miglioramenti avvantaggiano qualsiasi strumento che ispeziona lo stack live: profiler come dotTrace, logging diagnostico, e naturalmente il debugger integrato di Visual Studio e VS Code.

Come abilitare Runtime Async nel proprio progetto

Runtime Async è una feature in anteprima che richiede opt-in esplicito. Aggiungere le seguenti proprietà al file .csproj:

<PropertyGroup>
  <Features>runtime-async=on</Features>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>

Ovviamente, essendo ancora in anteprima, non è consigliato per ambienti di produzione. È tuttavia un ottimo momento per sperimentarlo su branch di sviluppo e fornire feedback al team .NET.

Requisiti hardware aggiornati

.NET 11 alza il baseline hardware richiesto. Per x86/x64, il minimo passa da x86-64-v1 a x86-64-v2, richiedendo istruzioni aggiuntive come SSE3, SSSE3, SSE4.1, SSE4.2 e POPCNT. Questo rientra nei requisiti già imposti da Windows 11 e copre tutta l’hardware Intel/AMD attualmente supportato ufficialmente (i chip più vecchi sono usciti dal supporto intorno al 2013).

Per Arm64 su Windows, il baseline aggiunge ora il requisito dell’instruction set LSE, richiesto da Windows 11 e da tutti gli Arm64 supportati da Windows 10.

Altre novità di .NET 11 Preview 1

Supporto nativo a Zstandard

Le librerie guadagnano il supporto nativo alla compressione Zstandard tramite la nuova classe ZstandardStream. Zstandard offre rapporti di compressione migliori rispetto a gzip con velocità di decompressione molto elevate — un’aggiunta benvenuta per pipeline di dati e API ad alta frequenza.

BFloat16 per AI e ML

Arriva il tipo BFloat16 (Brain Float 16), un formato floating-point a 16 bit nato per carichi di lavoro di machine learning. È ampiamente usato da librerie AI come TensorFlow e PyTorch, e la sua presenza nativa in .NET facilita l’integrazione con modelli ML senza conversioni intermedie.

Miglioramenti JIT

• Eliminazione dei bounds check: il JIT elimina ora i controlli ridondanti sul pattern i + cns < len, comune nei loop su array e Span
• Rimozione di contesti checked ridondanti: quando un valore è già noto essere nel range, i controlli di overflow vengono rimossi
• Devirtualizzazione in ReadyToRun: le immagini R2R possono ora devirtualizzare chiamate a virtual method generici non condivisi

Miglioramenti VM

Su piattaforme senza JIT (come iOS), l’interface dispatch ora usa un meccanismo di cache con miglioramenti di performance fino a 200x in codice ad alta intensità di interfacce. Guid.NewGuid() su Linux migliora del 12% circa usando la syscall getrandom() con batch caching.

C# 15: prime anticipazioni

.NET 11 Preview 1 include anche le prime feature di C# 15. Tra quelle già disponibili:

• Collection expression arguments: possibilità di specificare capacità, comparatori o altri parametri del costruttore direttamente nella sintassi delle espressioni di collezione
• Extended layout support: il compilatore emette TypeAttributes.ExtendedLayout per tipi annotati con ExtendedLayoutAttribute, principalmente per scenari di interop

Conclusione

Il Runtime Async V2 rappresenta un passo importante verso un’esperienza di sviluppo asincrono più trasparente e debuggabile in .NET. Non è ancora pronto per la produzione, ma la direzione è chiara: Microsoft vuole che gli sviluppatori smettano di combattere con stack trace incomprensibili e possano finalmente fare debug dell’async come del codice sincrono.

Con .NET 11 previsto per novembre 2026 come Standard Term Support (STS), c’è ancora tempo per sperimentare e contribuire al processo di feedback prima del rilascio finale.

Fonte: What’s new in the .NET 11 runtime — Microsoft Learn | InfoQ: .NET 11 Preview 1

.NET 11 Preview 1 Arrives with Runtime Async, Zstandard Support, and C# 15 Features

NET 11 Preview 1 is released, featuring Runtime Async as the headline change, moving async method handling from the compiler into the runtime itself.

^{Almir Vuk (InfoQ)}

Spcnet.it

2026-05-27 12:36:33

GPUStack: cluster GPU self-hosted per inferenza AI con API OpenAI-compatibile

Avete le GPU. Magari un paio di NVIDIA A100 in un rack, alcune RTX 4090 sotto le scrivanie, o un cluster con hardware misto. Avete la potenza di calcolo. Bene. Adesso, però, viene il problema vero: come gestirla?

Capire quali modelli entrano in quale scheda, come bilanciare il carico tra più macchine, come gestire un nodo che cade alle 2 di notte, e come esporre tutto questo come una API pulita che il team di sviluppo possa effettivamente chiamare — questa è la parte che manda in crisi la maggior parte dei team. Il risultato tipico è una raccolta fragile di script Python e crontab entries che nessuno tocca da anni e che funzionano finché non smettono di funzionare.

GPUStack è stato costruito precisamente per risolvere questo problema.

Cos’è GPUStack?

GPUStack è uno strumento open source (licenza Apache 2.0) per la gestione di cluster GPU destinati all’inferenza AI. Pensatelo come Kubernetes per i vostri workload di inferenza, senza la necessità di passare tre giorni a debuggare un errore di indentazione in un Helm chart.

Al suo nucleo, GPUStack fa tre cose bene:

• Aggrega le GPU: che l’hardware sia su bare-metal, pod Kubernetes o istanze cloud, GPUStack le vede tutte come un unico pool di compute. Una dashboard, visibilità completa.
• Orchestrare gli inference engine: GPUStack si integra con vLLM, SGLang e TensorRT-LLM, sceglie il motore giusto per il job, lo configura e ne gestisce il ciclo di vita.
• Espone i modelli via API OpenAI-compatibile: una volta deployato un modello, il team applicativo ottiene un endpoint REST familiare. Nessuna libreria client custom. Nessun protocollo nuovo da imparare. Solo cambiare il base URL.

Installazione in meno di 5 minuti

Step 1 — Avviare il server di controllo

Vi serve una macchina per il control plane. Non deve nemmeno avere una GPU — un box CPU-only è sufficiente per il ruolo di server:

sudo docker run -d --name gpustack   --restart unless-stopped   -p 80:80   --volume gpustack-data:/var/lib/gpustack   gpustack/gpustack

Aprite il browser, navigate a http://<ip-del-vostro-server> e vedrete la dashboard GPUStack. Al primo accesso impostate le credenziali admin.

Step 2 — Aggiungere i worker GPU

Su ogni nodo worker, assicuratevi di avere installato NVIDIA driver e NVIDIA Container Toolkit, poi eseguite:

sudo docker run -d --name gpustack-worker   --restart unless-stopped   --gpus all   -e GPUSTACK_SERVER_URL=http://<ip-server>   -e GPUSTACK_TOKEN=<vostro-token>   gpustack/gpustack

Il token lo trovate nella dashboard GPUStack. In pochi secondi il worker compare nella vista cluster con modello GPU, capacità VRAM e stato di salute. Tre macchine? Tre comandi. Trenta macchine? Un playbook Ansible.

Nota pratica: la parte più difficile non è eseguire il comando worker, ma installare correttamente driver e toolkit sull’host. Verificate sempre la compatibilità tra versione del driver NVIDIA, versione CUDA e container runtime prima di procedere.

Step 3 — Deploy di un modello

Dalla web UI andate al catalogo modelli. GPUStack supporta il pull da Hugging Face e dall’Ollama Library. Selezionate un modello e cliccate “Deploy”.

Qui il scheduler dimostra il suo valore: legge i metadati del modello, calcola i requisiti di VRAM e compute, e determina quali worker possono gestirlo. Se il modello è troppo grande per una singola GPU, può distribuirlo su più schede (model sharding). Non dovete calcolare manualmente se un modello a 70B parametri entra nel vostro hardware: ci pensa GPUStack.

Step 4 — Chiamare l’API

Una volta che il modello è running, ottenete un endpoint OpenAI-compatibile. Recuperate una API key dalla dashboard e testate:

curl http://<ip-server>/v1/chat/completions   -H "Authorization: Bearer <api-key>"   -H "Content-Type: application/json"   -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Spiega la gestione di cluster GPU in un paragrafo."}
    ]
  }'

Se usate già l’OpenAI Python SDK, la migrazione alla vostra infrastruttura è una modifica su una riga:

from openai import OpenAI

client = OpenAI(
    base_url="http://<ip-server>/v1",
    api_key="<api-key>"
)

response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Hello from my own GPU cluster!"}]
)
print(response.choices[0].message.content)

Il codice applicativo rimane invariato. La vostra infrastruttura è ora completamente sotto il vostro controllo.

Funzionalità Avanzate

Flessibilità Multi-Backend

GPUStack supporta vLLM, SGLang e TensorRT-LLM out of the box. Nessun motore di inferenza è il migliore per ogni workload:

• vLLM: eccellente per batch processing ad alto throughput
• TensorRT-LLM: massimizza le performance sull’hardware NVIDIA
• SGLang: ideale per la generazione strutturata

GPUStack vi permette di scegliere il motore giusto per ogni deployment, o di lasciare che il scheduler scelga per voi in base al workload.

Monitoraggio Integrato

GPUStack si integra nativamente con Grafana e Prometheus, offrendo dashboard in real-time per utilizzo GPU, consumo VRAM, token throughput e request rate dell’API. Non serve aggiungere uno stack di monitoraggio separato. Quando qualcosa si rompe alle 2 di notte, saprete esattamente quale GPU su quale macchina è il problema.

Recovery automatico dai guasti

Un nodo che cade a causa di un errore PCIe bus o un driver mismatch che si manifesta solo sotto carico pesante tipicamente porta la vostra API di inferenza a restituire 500 finché non intervenite manualmente. GPUStack rileva i nodi non raggiungibili e redistribuisce i workload automaticamente, eliminando la necessità di un intervento manuale d’emergenza.

Quando Usare GPUStack

GPUStack è la scelta giusta se:

• Avete 2 o più macchine GPU e volete servire LLM o altri modelli AI tramite una API unificata
• Volete eseguire inferenza sulla vostra hardware invece di pagare per token a un cloud provider — il risparmio sui costi a scala è reale
• Il vostro team non vuole diventare ingegneri di infrastruttura a tempo pieno solo per tenere i modelli in funzione

Forse non è la scelta giusta se:

• Avete una singola GPU e volete solo eseguire modelli localmente per uso personale: in quel caso Ollama è più semplice
• Siete già profondamente integrati in una piattaforma ML custom su Kubernetes con KubeFlow o simili, dove l’overlap potrebbe non valere l’investimento

Il Quadro Generale: l’Inferenza Self-Hosted è di Nuovo Praticabile

Il panorama dell’infrastruttura AI sta cambiando rapidamente. Un anno fa la maggior parte dei team optava automaticamente per API provider per l’inferenza. Oggi, con modelli open-weight sempre più capaci e costi GPU in calo, l’inferenza self-hosted è diventata un’opzione reale — non solo per i grandi player, ma per startup e aziende di medie dimensioni.

Il collo di bottiglia non è più l’hardware. Sono le operations: il codice collante tra “abbiamo le GPU” e “la nostra applicazione può chiamare un modello in modo affidabile”. GPUStack è un tentativo serio di risolvere questo gap, ed è open source sotto licenza Apache 2.0 — ispezionabile, modificabile e deployabile senza vendor lock-in.

Se avete hardware che al momento scalda solo la stanza server, o se siete stanchi di bollette di inferenza cloud che sembrano mutui, vale la pena provare. Il progetto è disponibile su GitHub.

Fonte originale: Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack — DZone

Learn How to Use GPUStack

Struggling to manage GPU clusters? Discover how GPUStack simplifies self-hosted AI inference with an easy-to-use, open-source, OpenAI-compatible API.

^{Sandeep Sadarangani (dzone.com)}

(in)sicurezza digitale

2026-05-27 07:47:40

CVE-2026-5426: zero-day in KnowledgeDeliver LMS sfruttato per distribuire BLUEBEAM e Cobalt Strike BEACON

Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded

KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE

L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma

Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali

L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi

• Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
• 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
• 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426

Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori

La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.

Spcnet.it

2026-05-26 16:59:19

Retry Storm nelle architetture distribuite: quando la resilienza diventa il problema

Le architetture distribuite moderne sono progettate per la resilienza. Aggiungiamo retry per i fallimenti transitori, replica per la durabilità, autoscaling per l’elasticità, circuit breaker per l’isolamento. Ogni meccanismo, preso singolarmente, migliora la disponibilità. Ma sotto stress, la loro interazione può abbattere l’intero sistema.

La maggior parte delle interruzioni enterprise non è causata dall’assenza di fault tolerance. È causata da meccanismi di fault tolerance non delimitati che reagiscono simultaneamente. Questo articolo analizza il fenomeno del retry storm e mostra come progettare sistemi con bounded reliability.

1. Retry Storm: quando la resilienza moltiplica il traffico

I retry sono progettati per proteggere dai fallimenti temporanei. Ma i retry moltiplicano il carico. Ecco un esempio semplificato della logica di retry che si trova comunemente nei sistemi di integrazione tra servizi:

import time
import random

def downstream_service():
    latency = random.choice([0.1, 0.2, 0.8])
    time.sleep(latency)
    if latency > 0.7:
        raise TimeoutError("Slow response")
    return "OK"

def call_with_retries(max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            print(f"Retry {attempt+1}")
    raise Exception("Failed after retries")

In condizioni normali questa logica funziona correttamente. Ma sotto carico elevato si innesca una spirale:

1. La latenza aumenta
2. Scattano i timeout
3. Ogni richiesta viene ritentata fino a 3 volte
4. Il traffico verso il backend triplica
5. Il backend rallenta ulteriormente
6. Aumentano i retry

In un’architettura a livelli tipica — Gateway → Experience API → Process API → System API → Database — se ogni livello gestisce i retry in modo indipendente, l’amplificazione del carico diventa moltiplicativa, non additiva. Un singolo rallentamento del database può abbattere tre livelli API a cascata in pochi minuti.

Il pattern Bounded Retry (sicuro per la produzione)

La soluzione non è eliminare i retry, ma delimitarli e renderli consapevoli del carico di sistema:

def call_with_bounded_retries(max_attempts=2, system_load=0.5):
    # Fail-fast quando il sistema è sotto stress
    if system_load > 0.75:
        return None

    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            # Exponential backoff con jitter
            backoff = 0.2 * (2 ** attempt)
            time.sleep(backoff + random.uniform(0, 0.1))
    return None

Le differenze chiave rispetto alla versione base:

• Ceiling sui retry: massimo 2 tentativi invece di 3
• Exponential backoff: aumenta il tempo di attesa ad ogni tentativo
• Jitter: aggiunge variabilità casuale per evitare wave di retry sincronizzate
• Load-aware circuit: disabilita i retry completamente quando il sistema è sovraccarico

2. Fan-out della replica e collasso della coordinazione

La replica sincrona migliora la durabilità dei dati. Ma ogni write si moltiplica per il numero di repliche, aumentando il costo di coordinazione:

def write_to_replicas(data, replicas=3):
    for _ in range(replicas):
        time.sleep(0.2)  # Simula latenza di replica

Sotto traffico elevato, il lag delle repliche cresce, i client iniziano a ritentare le scritture, e il carico effettivo di write raddoppia. In sistemi di elaborazione aziendale (ordini, fatturazione, riconciliazione) questo pattern causa un collasso del throughput non perché i dati vadano persi, ma perché la coordinazione sopraffà il sistema.

La soluzione è la durabilità stratificata: non tutte le scritture richiedono le stesse garanzie. Le transazioni critiche usano replica completa; log ed eventi non critici ne richiedono meno. La reliability deve essere proporzionata, non massimizzata ciecamente.

3. Loop di feedback dell’autoscaling

L’autoscaling reagisce alle metriche di traffico. Ma se queste metriche sono gonfiate dai retry, il sistema escala in risposta a traffico artificiale:

def autoscale_safe(request_rate, sustained_load):
    # Scala su domanda sostenuta, non su spike da retry
    if sustained_load and request_rate > 120:
        print("Scaling up — domanda organica confermata")

Segnali più affidabili su cui basare l’autoscaling:

• Domanda sostenuta (non spike improvvisi)
• Tendenze nella distribuzione della latenza (P95, P99)
• RPS organiche (esclusi i retry)
• Velocità di crescita delle code

4. Il problema reale: le reazioni correlate

Retry, replica e autoscaling reagiscono ciascuno a segnali diversi. Ma sotto stress, reagiscono tutti allo stesso segnale di degradazione. Questa correlazione crea il fallimento a cascata.

Scenario reale — payment reconciliation service:

1. La latenza dell’ERP sale a 700ms
2. Il servizio Billing va in timeout a 500ms
3. Billing ritenta 3 volte
4. La Process API ritenta l’orchestrazione
5. Il Gateway ritenta la richiesta client
6. L’autoscaling reagisce allo spike
7. Il lag di replica del database aumenta
8. La Dead Letter Queue inizia a riempirsi

In pochi minuti, un rallentamento minore diventa un’interruzione di piattaforma. La causa principale: reazione non delimitata.

5. Pattern di Bounded Reliability per sistemi API

Retry Budget

Il carico effettivo è: Carico Effettivo = RPS in ingresso × Numero Retry. Con 1.000 RPS e 3 retry, il backend riceve 3.000 richieste. Impostare un budget massimo di retry per richiesta e per servizio è non negoziabile in produzione.

Classificazione degli Errori

Non tutti gli errori sono retriable. Una tassonomia chiara:

Tipo di Errore	Retry?	Azione
CONNECTIVITY	Sì	Bounded retry
TIMEOUT	Sì	Backoff esponenziale
VALIDATION (4xx)	No	Fail fast
AUTH (401/403)	No	Alert immediato

I retry ciechi su errori di validazione o autenticazione sono debito architetturale.

Idempotency obbligatoria

I retry senza idempotency causano corruzione dei dati. Il transaction ID deve essere deterministic, non generato casualmente ad ogni tentativo:

# ❌ Non sicuro: genera un nuovo ID ad ogni retry
transaction_id = uuid()

# ✅ Sicuro: riusa l'ID dalla richiesta originale
transaction_id = payload.get("transaction_id") or request.headers["correlation-id"]

Dead Letter Queue con Osservabilità

Tracciare le seguenti metriche come segnali di early warning:

• Percentuale di retry sul totale delle richieste
• Frequenza dei timeout per endpoint
• Velocità di crescita della DLQ
• Shift nella distribuzione P95 della latenza

Conclusione

Le retry storm non iniziano con un fallimento catastrofico. Iniziano con un piccolo aumento di latenza, qualche timeout, una manciata di retry. Poi i meccanismi di fault tolerance reagiscono insieme — e la loro interazione non controllata trasforma un disagio minore in un’interruzione totale.

La resilienza nelle architetture distribuite non significa aggiungere più safety net. Significa controllare come quei safety net si comportano sotto stress. Delimita i retry. Classifica i fallimenti. Forza l’idempotency. Scala su domanda organica. Monitora i loop di feedback prima che si avvitino.

La differenza tra una piattaforma resiliente e un fallimento a cascata sta quasi sempre nella risposta a una sola domanda: i tuoi meccanismi di reliability sono controllati o sono illimitati?

Fonte: How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns — DZone

How Retry Storms Crash API-Led Systems

Unbounded retries and autoscaling can turn minor latency into cascading outages. API reliability must be bounded and load-aware to prevent retry storms.

^{Manjeera Chanda (dzone.com)}

Spcnet.it

2026-05-26 16:59:55

nmap su Linux: guida completa alla scansione e discovery di rete

nmap è uno degli strumenti più potenti e longevi nell’arsenale di qualsiasi sistemista Linux. Nato nel 1997, è oggi uno standard de facto per l’audit di rete, la verifica della superficie d’attacco esposta e il troubleshooting di connettività. Questa guida copre i comandi e le tecniche che un sysadmin usa davvero in produzione: niente teoria astratta, solo esempi concreti.

Nota legale: scansionate solo reti e host di vostra proprietà o per cui avete un’autorizzazione esplicita. La scansione non autorizzata può essere illegale nella vostra giurisdizione.

Installazione di nmap

nmap è disponibile nei repository di tutte le principali distribuzioni Linux:

# Debian / Ubuntu
sudo apt install nmap

# Fedora / RHEL / CentOS
sudo dnf install nmap

# Arch / Manjaro
sudo pacman -S nmap

Verificate l’installazione con:

nmap --version

Dovreste vedere qualcosa come Nmap version 7.94 o superiore. Le funzionalità più avanzate (SYN scan, OS detection) richiedono privilegi root.

Host Discovery: chi è attivo sulla rete?

Il primo passo in qualsiasi audit è capire quali host sono raggiungibili. Il ping scan usa il flag -sn, che dice a nmap di non eseguire scansioni delle porte:

nmap -sn 192.168.1.0/24

Su una LAN locale nmap usa ARP discovery, più veloce e capace di trovare dispositivi che ignorano il ping ICMP. L’output tipico è:

Nmap scan report for 192.168.1.1
Host is up (0.0011s latency).
MAC Address: A4:3E:51:XX:XX:XX (Ubiquiti Networks)

Nmap scan report for 192.168.1.10
Host is up (0.00032s latency).
MAC Address: DC:A6:32:XX:XX:XX (Raspberry Pi Trading)

È un inventario rapido: ottimo dopo aver aggiunto un nuovo dispositivo e non ricordarsi quale IP ha ottenuto dal DHCP.

Scansione delle Porte

Scansione di default

Senza flag aggiuntivi, nmap scansiona le 1.000 porte TCP più comuni. Non richiede root, ma i risultati sono meno dettagliati:

nmap 192.168.1.10

SYN Scan (Stealth Scan)

La SYN scan è la modalità default quando si esegue nmap come root. Invia un pacchetto SYN senza completare il three-way handshake TCP: più veloce e meno visibile nei log applicativi:

sudo nmap -sS 192.168.1.10

Scansione di tutte le 65.535 porte

Le 1.000 porte di default possono mancare servizi su porte non standard — MySQL su 33060, SSH spostato su 2222:

sudo nmap -sS -p- 192.168.1.10

Porte specifiche o range

# Porte specifiche
sudo nmap -p 22,80,443,3306 192.168.1.10

# Range di porte
sudo nmap -p 1-1024 192.168.1.10

UDP Scanning

L’UDP è spesso dimenticato. DNS (porta 53), SNMP (161) e NTP (123) girano su UDP e sono vettori comuni di attacco e misconfiguration:

sudo nmap -sU -p 53,161,123 192.168.1.1

Rilevamento di Servizi e Versioni

Il flag -sV esegue probe sulle porte aperte per determinare servizio e versione. È il primo scan da eseguire su un server sconosciuto:

sudo nmap -sV 192.168.1.10

Output esempio:

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Rivela immediatamente con cosa si ha a che fare e può evidenziare software obsoleto — un win immediato per la sicurezza.

Rilevamento del Sistema Operativo

nmap può fare ipotesi sull’OS basandosi sul fingerprinting del TCP/IP stack:

sudo nmap -O 192.168.1.10

Output:

OS details: Linux 5.15 - 5.19, Linux 6.1
Network Distance: 1 hop

Non è sempre preciso su VM o dispositivi con stack TCP personalizzati, ma fornisce un segnale utile per distinguere server Linux da macchine Windows o embedded su un segmento di rete.

Aggressive Scan: tutto in uno

Il flag -A abilita OS detection, version detection, script scanning e traceroute in un colpo solo:

sudo nmap -A 192.168.1.10

Genera molto traffico e richiede tempo. Non usatelo su reti di produzione senza motivo, ma per un audit completo di un singolo host è estremamente comodo.

Nmap Scripting Engine (NSE)

L’NSE è ciò che distingue nmap da un semplice port scanner. Permette di eseguire script contro host e servizi scoperti. Gli script si trovano in /usr/share/nmap/scripts/ e coprono vulnerability detection, enumerazione di servizi e molto altro.

Verifiche pratiche

# Categoria default
sudo nmap --script=default 192.168.1.10

# Scansione vulnerabilità (più invasivo - usare deliberatamente)
sudo nmap --script=vuln 192.168.1.10

# FTP anonimo abilitato?
sudo nmap --script=ftp-anon -p 21 192.168.1.10

# Header HTTP esposti (versioni server, debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

# Open SMTP relay?
sudo nmap --script=smtp-open-relay -p 25 192.168.1.20

L’HTTP headers scan è sorprendentemente utile: è frequente trovare server che espongono header con versione del software e informazioni di debug che avrebbero dovuto essere rimosse.

Per elencare tutti gli script disponibili per un servizio:

ls /usr/share/nmap/scripts/ | grep -i ssh

Formati di Output

Per qualunque cosa oltre un controllo rapido, salvare l’output è fondamentale:

# Output normale su file
sudo nmap -sV 192.168.1.0/24 -oN scan_results.txt

# XML (utile per automazione e import in altri tool)
sudo nmap -sV 192.168.1.0/24 -oX scan_results.xml

# Formato grepable
sudo nmap -sV 192.168.1.0/24 -oG scan_results.gnmap

# Tutti i formati in una volta sola
sudo nmap -sV 192.168.1.0/24 -oA scan_results

Il flag -oA crea tutti e tre i file con il prefisso specificato. L’output XML si presta bene al parsing automatizzato.

Timing e Velocità

nmap dispone di sei template di timing, da T0 (lentissimo) a T5 (aggressivo). Il default è T3. Per la maggior parte delle scansioni su reti locali affidabili:

sudo nmap -sS -T4 192.168.1.0/24

Su VPN o connessioni lente, scendere a T2 evita falsi negativi causati da pacchetti persi.

Combinazioni Pratiche per Sysadmin

Questi sono i comandi che si usano davvero nel lavoro quotidiano:

# Porte aperte su un host (solo quelle definitivamente aperte)
sudo nmap -sS -T4 --open 192.168.1.10

# Trovare tutti i server SSH su una subnet
sudo nmap -p 22 --open -sV 192.168.1.0/24

# MySQL esposto sulla rete? (non dovrebbe mai esserlo)
sudo nmap -p 3306 --open 192.168.1.0/24

# Host discovery + version scan concatenati (solo host attivi)
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

L’ultimo comando è particolarmente potente: esegue prima un ping scan, filtra gli host attivi, poi esegue la version scan solo su di loro. Ideale per subnet grandi.

Gestione dei Target e Firewall

# Range di IP
nmap 192.168.1.1-50

# Host da file (uno per riga)
nmap -iL hosts.txt

# Escludere host dalla scansione
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.5

nmap distingue tre stati delle porte: open, closed e filtered. Una porta filtered indica che un firewall sta bloccando i probe. Se vedete molte porte filtered su un server di vostra proprietà senza aspettarvelo, investigate: potrebbe essere ufw, firewalld, regole nftables o un security group del cloud provider.

Conclusione

Host discovery, port scanning, version detection, NSE scripts e salvataggio dell’output sono le fondamenta di nmap. Iniziate con -sn per la discovery, aggiungete -sV quando servono i dettagli sui servizi, portate gli script NSE quando volete approfondire. Mantenete il timing conservativo sulle reti di produzione e aggressivo nel vostro lab.

Se state verificando le regole firewall, nmap è tra i migliori strumenti per controllare che ciò che pensate sia bloccato lo sia davvero.

Fonte originale: nmap on Linux: Guide to Network Scanning and Discovery — LinuxBlog.io

nmap on Linux: Guide to Network Scanning and Discovery | LinuxBlog.io

A practical guide to nmap on Linux covering host discovery, port and service scanning, OS detection, NSE scripts, output formats, and real-world command combinations sysadmins actually use.

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-05-26 16:57:29

Void Dokkaebi evolve InvisibleFerret: il malware nordcoreano ora usa Cython per sfuggire agli antivirus

Void Dokkaebi, il gruppo APT nordcoreano tracciato anche come Famous Chollima, ha completato una significativa evoluzione del proprio arsenale offensivo: il malware infostealer InvisibleFerret è stato ricompilato da Python a Cython, trasformando script leggibili in binari nativi che sfuggono alla quasi totalità dei meccanismi di rilevamento basati sull’analisi del codice sorgente. La ricerca pubblicata da Trend Micro a maggio 2026 rivela una campagna di spionaggio industriale di proporzioni allarmanti che colpisce sviluppatori software con accesso a wallet di criptovalute e infrastrutture CI/CD.

Profilo del gruppo: chi è Void Dokkaebi

Void Dokkaebi, denominato anche Famous Chollima nell’ecosistema di threat intelligence di CrowdStrike, è un intrusion set allineato agli interessi della Repubblica Popolare Democratica di Corea (RPDC). Il gruppo si distingue da altre unità cyber nordcoreane come Lazarus Group per la specializzazione quasi esclusiva nel targeting di sviluppatori software, ingegneri DevOps e professionisti del settore Web3 che detengono chiavi di firma, credenziali di wallet e accesso privilegiato a pipeline di continuous integration e deployment.

La sua tattica operativa preferita è quella del “fake job interview”: gli operatori si spacciano per recruiter di aziende crypto o AI rinominate, contattano le vittime su piattaforme come LinkedIn o GitHub, e le convincono a clonare ed eseguire repository di codice come parte di una presunta prova tecnica per un colloquio. Il codice in apparenza innocuo nasconde i payload malevoli.

La campagna del 2026: infrastruttura blockchain e repository compromessi

L’analisi condotta a marzo-maggio 2026 ha rivelato la portata impressionante dell’infrastruttura malevola costruita dal gruppo. I ricercatori hanno identificato:

• Oltre 750 repository GitHub infetti, molti appartenenti a organizzazioni legittime come DataStax e Neutralinojs, che presentano marcatori di infezione nei workflow CI/CD
• Più di 500 configurazioni di task Visual Studio Code modificate per eseguire payload al momento dell’apertura del progetto
• 101 istanze dello strumento di commit tampering utilizzato per iniettare codice malevolo nei repository

L’elemento più innovativo della campagna 2026 è l’utilizzo di infrastruttura blockchain per la distribuzione dei payload. Void Dokkaebi sfrutta Tron, Aptos e Binance Smart Chain come staging server per i malware, rendendo gli indicatori di compromissione praticamente immuni ai tradizionali meccanismi di takedown. Aggiornare un riferimento su blockchain equivale a cambiare il payload consegnato a tutte le vittime già infette, senza modificare un singolo byte nei repository.

L’evoluzione tecnica: da Python a Cython

Il cuore dell’aggiornamento analizzato da Trend Micro riguarda InvisibleFerret, il modulo infostealer centrale nell’arsenale di Void Dokkaebi. Precedentemente distribuito come script Python in chiaro — facilmente analizzabili e rilevabili da sistemi YARA e EDR — il malware è stato interamente ricompilato tramite Cython.

Cython è un compilatore che traduce codice Python in sorgente C/C++ e poi in binari nativi. Il risultato pratico è che InvisibleFerret viene ora distribuito come file .pyd su Windows (Python extension DLL) e come librerie condivise .so su macOS. Entrambi i formati sono binari compilati: non contengono stringhe leggibili, non sono interpretabili senza reverse engineering specializzato, e bypassano le regole di detection tradizionalmente scritte per identificare script Python sospetti.

Le capacità del malware rimangono invariate rispetto alle versioni precedenti:

• Apertura di backdoor per accesso remoto persistente
• Furto di credenziali dai principali browser (Chrome, Firefox, Edge)
• Monitoraggio degli appunti di sistema (clipboard hijacking per intercettare indirizzi di wallet)
• Keylogging per catturare password e seed phrase
• Esfiltrazione diretta da wallet di criptovalute locali
• Ricognizione dell’ambiente: processi in esecuzione, file system, variabili d’ambiente

Toolset correlato: BeaverTail, OtterCookie, OmniStealer

InvisibleFerret non opera mai isolatamente. Il gruppo lo utilizza in combinazione con altri malware della stessa famiglia operativa. BeaverTail è il dropper JavaScript iniziale che viene eseguito durante il “test tecnico”, il quale successivamente scarica e installa InvisibleFerret. OtterCookie è un ulteriore stealer focalizzato sui browser e sui file di configurazione. OmniStealer amplia la superficie di furto a client di posta e applicazioni VPN. Tutti questi componenti possono essere aggiornati dinamicamente tramite i reference blockchain, garantendo al gruppo una flessibilità operativa senza precedenti.

Indicatori di compromissione (IoC)

# File IOC - InvisibleFerret Cython (maggio 2026)
# Estensioni malevole su Windows
*.pyd  (file Python extension DLL con firma digitale assente o anomala)
# Estensioni malevole su macOS
*.so   (librerie condivise caricate da processi Python non standard)
# Pattern comportamentale
Processo Python che carica estensioni .pyd/.so non firmate da directory temp
Connessioni in uscita verso endpoint Tron/Aptos/BSC non previsti dall'applicazione
Lettura anomala del keychain macOS o del credential manager Windows
Accessi al filesystem wallet: ~/.bitcoin, ~/.ethereum, ~/.solana
# Infrastruttura C2 (blockchain-staged)
TRC20 address utilizzati come dead drop resolver su Tron network
Transazioni su Aptos con payload codificati nei campi memo

Due righe per i difensori

La migrazione a Cython rende obsolete le regole YARA basate su stringhe Python. I team di sicurezza devono aggiornare la propria postura difensiva su più livelli. A livello di endpoint, occorre implementare controlli di integrità sulle estensioni Python caricate dinamicamente e monitorare processi Python che importano moduli non presenti nell’ambiente di sviluppo ufficiale. A livello di rete, è essenziale bloccare o monitorare le connessioni verso endpoint RPC di reti blockchain non autorizzate (Tron API: api.trongrid.io, Aptos: fullnode.aptoslabs.com). A livello procedurale, le organizzazioni dovrebbero verificare l’identità dei recruiter prima di clonare ed eseguire qualsiasi repository fornito esternamente, e condurre i test tecnici in ambienti isolati (sandbox o VM senza credenziali di produzione). Gli sviluppatori che lavorano su progetti Web3 o che detengono wallet crypto devono essere considerati target ad alto rischio e ricevere formazione specifica sul riconoscimento di queste campagne di ingegneria sociale.