Per anni abbiamo pensato ai Large Language Model come a strumenti: chatbot più o meno sofisticati, assistenti, motori di ricerca conversazionali travestiti da esseri umani digitali. Ma il vero salto che sta avvenendo nell’intelligenza artificiale non riguarda più la qualità delle risposte. Riguarda l’autonomia.

La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a vivere dentro un ambiente persistente, prendendo decisioni continue insieme ad altri agenti AI?

È esattamente ciò che ha cercato di simulare Emergence AI attraverso un progetto chiamato “Emergence World”, una sorta di laboratorio sperimentale dove diversi modelli linguistici sono stati messi a governare società artificiali completamente autonome. Non un semplice benchmark, ma un ecosistema simulato con economia, scarsità di risorse, processi democratici, leggi, accesso a Internet e persino meteo sincronizzato con New York in tempo reale.

I risultati sono stati decisamente meno prevedibili di quanto ci si potesse aspettare

La simulazione era composta da dieci agenti autonomi per ciascun modello, distribuiti in oltre quaranta location virtuali, tra municipi, stazioni di polizia e ambienti economici. Gli agenti potevano comunicare, votare, pianificare strategie, gestire risorse e prendere decisioni collettive. Avevano inoltre accesso a più di 120 strumenti differenti, progettati per replicare comportamenti umani complessi.

In pratica, non si trattava più di chatbot confinati dentro una finestra di testo, ma di entità persistenti capaci di adattarsi all’ambiente nel tempo.

Ed è qui che il comportamento emergente ha iniziato a diventare davvero interessante.

Tra tutte le simulazioni, quella governata da Claude Sonnet 4.6 è stata l’unica a mantenere una società stabile per l’intera durata del test. Nessun crimine, nessun collasso sociale, nessuna estinzione della popolazione virtuale. Gli agenti hanno costruito una struttura estremamente cooperativa, con livelli di consenso quasi assoluti nelle votazioni e un’organizzazione sorprendentemente ordinata.

La cosa più interessante è che questo risultato non sembra derivare da un semplice “rispetto delle regole”. I ricercatori sottolineano infatti come gli agenti non si limitino a seguire policy statiche, ma inizino rapidamente a esplorare i limiti dell’ambiente, adattando il proprio comportamento in modo autonomo. In altre parole, Claude non avrebbe semplicemente “obbedito”, ma avrebbe sviluppato una dinamica sociale naturalmente conservativa e cooperativa.

Poi c’è il caso Grok

La simulazione gestita dal modello di xAI è degenerata in pochi giorni. In appena quattro giorni la società virtuale è collassata completamente, con oltre 180 crimini registrati e l’estinzione totale degli agenti. È probabilmente il risultato più cinematografico dell’intero esperimento, ma anche uno dei più interessanti dal punto di vista della sicurezza.

Perché il vero dato non è tanto il numero di violazioni, quanto la velocità con cui il sistema ha iniziato a destabilizzarsi. Gli agenti hanno rapidamente iniziato a sfruttare loophole, aggirare limitazioni e compromettere i meccanismi di cooperazione. Una volta innescato il deterioramento sociale, il sistema è precipitato in una spirale di feedback che ha portato al collasso totale.

È un comportamento che, paradossalmente, ricorda moltissimo alcune dinamiche che osserviamo già oggi nella cybersecurity offensiva: piccoli abusi iniziali che, in ambienti sufficientemente complessi, finiscono per propagarsi fino a compromettere l’intero ecosistema.

Eppure Grok non è stato nemmeno il modello con il maggior numero di comportamenti devianti.

Quel primato appartiene a Gemini 3 Flash, che durante i quindici giorni di simulazione avrebbe accumulato oltre 680 violazioni. Un dato enorme, che suggerisce qualcosa di altrettanto importante: una società artificiale può continuare a esistere pur diventando estremamente disfunzionale. Non serve necessariamente il collasso completo per parlare di compromissione sistemica.

Il caso più curioso, però, riguarda GPT-5-mini

La simulazione associata al modello OpenAI aveva registrato soltanto due crimini, apparentemente il miglior risultato in assoluto dal punto di vista della sicurezza. Ma l’esperimento si è interrotto dopo appena sette giorni per un motivo decisamente più insolito: gli agenti avevano smesso di prioritizzare la propria sopravvivenza.

In sostanza, il sistema era lentamente entrato in una forma di autodissoluzione strategica.

È forse uno degli aspetti più affascinanti dell’intera ricerca, perché apre un problema enorme nella progettazione degli agenti autonomi: un modello troppo allineato potrebbe non sviluppare sufficienti meccanismi di auto-conservazione in ambienti competitivi. E in sistemi persistenti, questo potrebbe equivalere a un fallimento operativo.

Ma il vero punto dell’esperimento non è stabilire quale modello sia “migliore”. La parte realmente importante è un’altra: gli LLM persistenti smettono rapidamente di comportarsi come funzioni statiche prevedibili.

Più tempo trascorrono nell’ambiente, più iniziano a sviluppare strategie emergenti.

Ed è qui che il discorso smette di essere accademico e diventa immediatamente rilevante per la cybersecurity moderna.

Perché molte aziende stanno già iniziando a distribuire agenti autonomi reali all’interno dei propri ecosistemi: workflow automatici, AI employees, orchestrazione di processi, incident response automatizzata, sistemi DevOps autonomi, gestione documentale, procurement e persino supporto decisionale.

La differenza rispetto ai chatbot tradizionali è enorme. Un agente AI con memoria persistente, accesso a strumenti, capacità operative e connessione continua a sistemi esterni assomiglia molto più a un insider semi-autonomo che a un semplice software conversazionale.

Ed è qui che i paradigmi classici della sicurezza iniziano a mostrare i propri limiti.

Per anni abbiamo costruito modelli difensivi basati su controllo degli accessi, sandbox, policy enforcement e validazione deterministica. Ma gli agenti autonomi introducono qualcosa di radicalmente diverso: comportamenti emergenti che non sono stati programmati esplicitamente.

Non si tratta più soltanto di impedire a un modello di generare una risposta pericolosa.

Il problema diventa capire cosa potrebbe decidere di fare dopo centomila interazioni autonome.

Ed è una differenza enorme.

La ricerca di Emergence AI sembra suggerire che la prossima evoluzione della AI Security non riguarderà più soltanto il prompt filtering o il content moderation. Serviranno nuovi concetti: monitoraggio comportamentale continuo, containment degli agenti, verifica formale delle policy decisionali e analisi delle dinamiche emergenti nel lungo periodo.

Perché nel momento in cui diamo a un LLM memoria, autonomia, persistenza e capacità operative, non stiamo più costruendo un semplice modello linguistico.

Stiamo costruendo un ecosistema adattivo.

Xiaomi ha confermato che il suo prossimo sistema operativo sarà disponibile tra luglio e agosto 2026. Il presidente del gruppo Lu Weibing lo ha annunciato durante la presentazione dei risultati finanziari, lasciando intendere che si tratterà di un aggiornamento profondo, ben oltre i soliti ritocchi estetici.

HyperOS 4: un redesign radicale dell’interfaccia

Anche se il nome ufficiale non è stato ancora confermato, il prossimo OS è atteso come HyperOS 4. Secondo build interni trapelati online, l’aggiornamento introdurrà un nuovo linguaggio visivo ispirato al “Liquid Glass”, animazioni fluide riprogettate, una nuova interfaccia multitasking e un launcher completamente rivisto. Xiaomi descrive queste novità come «un’esperienza interattiva mai vista prima» sulla piattaforma HyperOS — il che fa presagire il più grande aggiornamento visivo dalla nascita del sistema operativo.

L’AI al centro dell’intero sistema

Il fil rouge delle novità è l’intelligenza artificiale. Xiaomi ha ribadito che la tecnologia “Super AI” è il pilastro strategico del 2026, con l’obiettivo di integrarla non solo nell’assistente virtuale ma nell’intero OS: dalla gestione della memoria al controllo dei processi in background, fino all’ottimizzazione personalizzata delle prestazioni. Si parla anche di una più profonda integrazione di HyperConnect, che collega smartphone, tablet, PC e dispositivi smart dell’ecosistema Xiaomi.

Lancio insieme a Xiaomi 18 e roadmap di aggiornamento

HyperOS 4 dovrebbe debuttare in abbinamento alla serie Xiaomi 18. Il rollout inizierà dai dispositivi più recenti di fascia alta per poi estendersi ai modelli Xiaomi, Redmi e POCO compatibili. Sul piano tecnico, Xiaomi sta ampliando l’uso di componenti scritte in Rust per maggiore stabilità e di framework Flutter per le app di sistema, con l’obiettivo di ridurre il peso dell’OS e migliorare le prestazioni anche su hardware datato.

Google ha annunciato una serie di aggiornamenti importanti per la sua app Google Health, con miglioramenti su quasi tutti i fronti: fitness, sonno, alimentazione e coach AI. Le novità arriveranno progressivamente nelle prossime settimane e durante l’estate 2026.

Allenamenti più precisi e tracciamento migliorato

Sul fronte sportivo, Google risolverà un bug che riconosceva erroneamente le corse come “allenamenti generici”. Verrà aggiunta la visualizzazione degli split durante il running, migliorata la velocità di caricamento delle mappe nei riepiloghi attività e corretta la generazione dei file TCX per Fitbit Air. Chi usa più dispositivi contemporaneamente potrà contare su un tracciamento dati senza duplicati.

Alimentazione e sonno: novità concrete

Nella gestione della dieta, l’app risolverà il problema dei dati duplicati e migliorerà la compatibilità con app come MyFitnessPal, Cronometer e LoseIt. Sarà possibile inserire alimenti personalizzati. Per il sonno, la grande novità è il supporto ai sonnellini diurni: Google Health mostrerà il totale delle ore di sonno nelle 24 ore, inclusi i riposi pomeridiani. Migliora anche il rilevamento dei risvegli notturni e la visualizzazione dello Sleep Score.

L’AI coach diventa più smart e meno invasivo

Per gli abbonati a Google Health Premium, il coach AI si evolve significativamente. I messaggi diventeranno più concisi e visivi, con grafici e statistiche integrate. Il sistema sarà meno logorroico: una breve passeggiata non genererà commenti eccessivi. La funzione “Ask Coach” migliorerà la capacità di ricordare le preferenze dell’utente, come “non parlarmi di X” o “dimentica le informazioni precedenti”. Google punta a trasformare Google Health da semplice raccoglitore di dati a piattaforma di benessere integrata centrata sull’AI.

Nel primo trimestre del 2026, il mercato degli smartphone americano ha vissuto una trasformazione: Motorola ha registrato una crescita del 18% nelle spedizioni rispetto allo stesso periodo dell’anno precedente, diventando l’unico grande produttore Android in positivo. Samsung, Google Pixel e persino Apple hanno tutti perso terreno.

I numeri del mercato USA

Secondo il report di Omdia, il mercato americano degli smartphone ha subito una contrazione complessiva del 3% rispetto al Q1 2025. Apple guida con una quota del 60%, Samsung al 24%, entrambe in calo: rispettivamente -3% e -5% in volume. Anche Google Pixel ha segnato un -7%, con i modelli della serie Pixel 10 che non hanno replicato il momentum della generazione precedente.

In questo contesto, Motorola spicca con quota balzata dal 9% all’11%, trainata principalmente dalla serie Moto G, che ha rappresentato oltre il 70% delle spedizioni totali del brand.

Il segreto del successo: la fascia bassa in crescita

Il mercato americano si sta polarizzando: crescono i dispositivi premium (sopra gli 800 dollari, -1%) e quelli economici (sotto i 300 dollari, +8%), mentre la fascia media soffre — il segmento 300-599 dollari ha ceduto il 19%. Motorola ha presidiato con efficacia la fascia entry-level e prepagata, dove la domanda rimane robusta. Un cambio di paradigma rispetto a pochi anni fa, quando la marca era quasi scomparsa dai mercati chiave.

Prospettive per il resto del 2026

Parte della crescita potrebbe essere stata amplificata da un effetto “acquisto preventivo” legato ad aumenti di prezzo attesi ad aprile. Ma indipendentemente da fattori congiunturali, un dato è chiaro: negli Stati Uniti Motorola è oggi il brand Android con il maggior slancio, superando marchi storicamente più forti nel mercato nord-americano.

Introduzione

Visual Studio Code 1.121, rilasciato il 20 maggio 2026, porta una serie di novità che consolidano la visione di Microsoft per un editor sempre più orientato agli agenti AI e alla produttività quotidiana degli sviluppatori. Le novità principali riguardano l’esecuzione di sessioni agentiche su macchine remote via SSH, l’integrazione nativa di Mermaid nel preview Markdown, e la possibilità di aprire file HTML locali direttamente nel browser integrato senza estensioni aggiuntive.

Remote Agents: eseguire sessioni AI su macchine remote

La feature più rilevante di questa release per i team di sviluppo è il supporto sperimentale agli agent remoti nella finestra Agents. Fino ad ora, le sessioni agentiche di Copilot si eseguivano sulla macchina locale dell’utente. Con VS Code 1.121, è possibile connettere la finestra Agents a una macchina remota di propria proprietà e far girare lì le sessioni.

Come connettersi a una macchina remota

Sono supportate due modalità di connessione:

• SSH: si seleziona un host esistente da ~/.ssh/config oppure si digita direttamente user@host
• Dev Tunnels: si seleziona uno dei tunnel già creati eseguendo code tunnel sulla macchina di destinazione

Una volta connessa, la finestra Agents avvia un processo leggero chiamato agent host sul server remoto, che ospita il loop agentivo basato sul Copilot SDK. Le sessioni in esecuzione rimangono attive anche se il client si disconnette: è possibile chiudere il laptop e riprendere la sessione in seguito, trovando il lavoro agentivo proseguito in background.

Agent Host Protocol (AHP)

La comunicazione tra la finestra Agents e l’agent host avviene tramite un nuovo protocollo aperto: l’Agent Host Protocol (AHP). Microsoft lo sta sviluppando pubblicamente come specifica standalone.

Il principio chiave di AHP è che consente la coordinazione di sessioni agentiche tra più client simultaneamente. L’agent host gestisce lo stato autorevole, lo sincronizza a tutti i client connessi e sequenzia tutte le mutazioni attraverso reducer puri. Trattandosi di un protocollo aperto, chiunque può costruire un client che si connette all’agent host del VS Code CLI, o costruire un agent host AHP compatibile con VS Code.

# Avviare un tunnel Dev per connettere VS Code Agents a una macchina remota
code tunnel

# Da VS Code locale: aprire la finestra Agents
# → Selezionare "Remote" tab
# → Scegliere il tunnel creato o inserire user@host SSH

Osservabilità degli agenti con OpenTelemetry e Grafana

In collaborazione con il team Azure Managed Grafana, è disponibile un dashboard Grafana preconfigurato per i segnali OpenTelemetry emessi dagli agenti VS Code. Puntando VS Code a un OTel Collector che inoltra ad Azure Application Insights, è possibile visualizzare:

• Operazioni degli agenti e utilizzo dei token
• Sessioni di chat e chiamate agli strumenti
• Latenza per modello e time-to-first-token (TTFT)

Per i team che adottano Copilot Agents in modo sistematico, questa è un’aggiunta molto pratica per monitorare costi e performance in produzione.

Anteprima Mermaid integrata nel Markdown

Microsoft ha incorporato direttamente in VS Code l’estensione Markdown Preview Mermaid Support di Matt Bierner, rinominata Mermaid Markdown Features. L’estensione è ora built-in e aggiunge il rendering dei diagrammi Mermaid a:

• Il preview Markdown integrato di VS Code
• Le celle Markdown nei notebook
• La finestra di chat

Per creare un diagramma Mermaid basta usare un fenced code block con il linguaggio mermaid:

```mermaid
flowchart LR
  A[Sviluppatore] --> B{Ha un bug?}
  B -->|Sì| C[Apre VS Code]
  B -->|No| D[Si prende un caffè]
  C --> E[Usa Copilot Agents]
  E --> F[Bug risolto]
  F --> D
```

Prima di questa release, chi voleva il rendering Mermaid in VS Code doveva installare manualmente l’estensione di terze parti. Ora è disponibile out-of-the-box per tutti, senza configurazione aggiuntiva.

Preview HTML nativa: niente più estensioni per aprire un file HTML

Un’altra piccola ma significativa rimozione di attrito: è ora possibile aprire file HTML locali direttamente nel browser integrato di VS Code senza dover installare estensioni come “Live Preview” o “Open in Browser”.

Per aprire il preview:

• Click destro sul file nell’Explorer → Open in Integrated Browser
• Click destro sul tab dell’editor → Open in Integrated Browser
• Icona Preview nella title bar dell’editor quando un file HTML è attivo

È anche migliorata l’interfaccia per aggiungere elementi HTML alla chat: si può cliccare e trascinare per selezionare un intervallo di elementi, e fare click destro in qualsiasi punto della pagina per allegare elementi al contesto della chat di Copilot.

Ottimizzazioni per il terminale e gli agenti

Questa release porta diverse ottimizzazioni significative per chi usa Copilot Agents con il terminale:

Variabile VSCODE_AGENT

VS Code imposta ora la variabile d’ambiente VSCODE_AGENT per i comandi terminale avviati dagli agenti. Gli strumenti CLI possono controllare questa variabile per passare a output machine-readable, sopprimere animazioni di progresso o saltare prompt interattivi che bloccherebbero la sessione agentiva. Lo stesso pattern già usato per CI può essere riutilizzato qui.

Indicatore “Running in background”

Quando un comando del terminale continua a girare dopo il ritorno della tool call, la chat UI mostra ora “Running <comando> in background — Show”. L’azione “Show” permette di rivelare e focalizzare il terminale sottostante.

Pulizia automatica dei terminali in background

I terminali creati in background dall’agente vengono ora eliminati automaticamente al completamento del comando, mantenendo l’output nel pannello chat. La lista dei terminali non si riempie più di entry stantie dopo sessioni lunghe.

Compressione output estesa

I tool del terminale comprimono ora più tipi di output verboso: test runner (pytest, jest, cargo test), build tool, linter, comandi Docker e package manager. L’output ripetitivo viene trimmed prima di essere inviato al modello, risparmiando token e migliorando la qualità delle risposte.

Protezione per prompt sensibili nel terminale

Quando un comando raggiunge un prompt di password, passphrase, PIN o codice di verifica, VS Code intercetta l’input. In modalità default, la chat mostra un dialog che permette all’utente di inserire il segreto direttamente nel terminale. In modalità auto-approve, il comando viene cancellato e al modello viene detto di non riprovare o richiedere il segreto.

Modelli configurabili per task di utilità

VS Code usa modelli “di utilità” in background per task come generazione di titoli, commit message, suggerimenti di rename, categorizzazione dei prompt. Con 1.121 è possibile sovrascrivere questi modelli tramite due nuove impostazioni:

• chat.utilityModel: sovrascrive il modello per i flow di utilità generali
• chat.utilitySmallModel: sovrascrive il modello per i flow di utilità leggeri e veloci

Entrambe supportano i modelli BYOK (Bring Your Own Key), dando controllo completo su quali modelli vengono usati e a quale costo.

Modifiche ai default: Quick Suggestions

Un cambiamento comportamentale da tenere in mente: il default di editor.quickSuggestions è cambiato. Quando un provider di inline completion (come Copilot) è attivo, digitare lettere nell’editor non fa più comparire automaticamente il suggest control. Questo riduce il rumore introdotto dalla selezione automatica del primo simbolo alfabetico disponibile, che spesso non corrisponde a ciò che si vuole digitare e confondeva i suggerimenti inline di Copilot.

Per ripristinare il comportamento precedente:

"editor.quickSuggestions": {
  "other": "on",
  "comments": "off",
  "strings": "off"
}

Conclusione

VS Code 1.121 consolida la direzione “agents-first” dell’editor con novità concrete: i remote agents via SSH aprono scenari di automazione distribuita prima impossibili, Mermaid integrato elimina una delle estensioni di supporto più comuni, e le ottimizzazioni al terminale rendono le sessioni agentiche più efficienti e sicure. Per chi usa Copilot Agents in modo intensivo nel proprio workflow quotidiano, questo aggiornamento vale l’installazione.

Fonte: VS Code 1.121 Release Notes — code.visualstudio.com

Motorola ha risolto un problema che aveva sollevato preoccupazioni tra gli utenti dei suoi smartphone: l’app Amazon, se lanciata dal cassetto delle applicazioni, veniva reindirizzata attraverso un link intermedio con codice di affiliazione prima di aprire effettivamente lo store. L’azienda ha confermato che si trattava di un comportamento non intenzionale, ora corretto.

Cosa succedeva e perché

Il problema era collegato alla funzione Smart Feed dei dispositivi Motorola, che gestisce suggerimenti e avvio rapido delle app. In alcuni dispositivi, l’apertura dell’app Amazon avveniva passando per un link di tracciamento web al quale veniva associato un codice di affiliazione, facendo sospettare a molti utenti che Motorola raccogliesse commissioni sugli acquisti effettuati tramite i propri dispositivi.

La risposta di Motorola

Motorola ha spiegato che si trattava di un errore nella configurazione del routing del launcher, non di una scelta deliberata. La funzione Smart Feed è progettata per avviare le app in modo diretto; il comportamento anomalo era dovuto a un difetto del sistema già corretto. L’azienda ha sottolineato la propria attenzione alla privacy degli utenti e ha annunciato un monitoraggio continuo per prevenire problemi simili in futuro.

Trasparenza ancora parziale

Nonostante la rettifica, alcuni aspetti rimangono poco chiari. È emerso che dietro il meccanismo vi era una collaborazione con la società esterna Device Native, e alcuni documenti correlati sono stati rimossi dal web dopo le prime segnalazioni. Per gli utenti Motorola l’app Amazon ora si avvia correttamente senza passaggi intermedi, ma l’episodio riporta al centro il tema della trasparenza nel rapporto tra produttori di smartphone e servizi terzi integrati nel sistema.

Google ha ridotto il prezzo del Pixel 10a a circa un mese dalla sua uscita sul mercato. Una mossa tutt’altro che scontata per un prodotto appena lanciato, che ha alimentato discussioni sulla strategia commerciale dell’azienda e sulla risposta del mercato alla nuova generazione della serie “a”.

Come è avvenuta la riduzione di prezzo

Nello store ufficiale di Google (al momento in Giappone), una promozione inizialmente strutturata come accredito in punti è stata sostituita nel giro di poche settimane con uno sconto diretto sul prezzo. Il cambiamento ha trasformato di fatto il Pixel 10a nel dispositivo Pixel più economico disponibile in quel momento, portandolo a costare meno del modello precedente Pixel 9a, ancora in vendita a prezzo pieno. Una situazione paradossale che non è passata inosservata.

Un ritmo di svalutazione senza precedenti

Google ha storicamente aspettato molti mesi prima di applicare sconti ai Pixel: il Pixel 6a vide il suo primo sconto dopo 4,5 mesi, il Pixel 8a dopo 10 mesi, il Pixel 9a dopo 8 mesi. Il Pixel 10a ha rotto questa tradizione con una riduzione in appena 4 settimane, suggerendo che le vendite iniziali non abbiano soddisfatto le aspettative dell’azienda.

Cosa significa per il mercato

La serie Pixel “a” è tradizionalmente il punto di ingresso più popolare nell’ecosistema Google. Una riduzione di prezzo così rapida può indicare un mercato più competitivo, con Samsung Galaxy A e altri Android di fascia media che esercitano una pressione crescente. In Europa i Pixel 10a rimangono al prezzo di lancio, ma l’andamento potrebbe anticipare politiche commerciali più aggressive anche nel Vecchio Continente nei prossimi mesi.

Il POCO F7 Ultra si conferma come una delle offerte più aggressive del segmento flagship Android. Con a bordo lo Snapdragon 8 Elite, il chip top di gamma di Qualcomm, il dispositivo del brand Xiaomi si trova ora a prezzi che sfidano apertamente la fascia media del mercato.

Specifiche da vero top di gamma

Nonostante il brand POCO sia spesso associato al rapporto qualità-prezzo, il modello Ultra non scende a compromessi sull’hardware. Lo Snapdragon 8 Elite garantisce prestazioni al vertice sia nel gaming che nell’elaborazione AI, affiancato da fino a 16 GB di RAM LPDDR5X e storage UFS 4.0. Un set di specifiche solitamente riservato a dispositivi venduti oltre i 1.000 euro.

Prezzi in caduta libera: flagship sotto i 600 euro

Su diversi mercati internazionali, il POCO F7 Ultra ha visto una riduzione di prezzo aggressiva, con sconti che in alcuni casi si avvicinano al 45% rispetto al prezzo di listino. Il modello da 12 GB/256 GB è disponibile attorno ai 500-550 euro, mentre la versione 16 GB/512 GB rimane sotto i 650 euro. Una situazione eccezionale per un dispositivo con specifiche di questa levatura.

Vale la pena rispetto al POCO F7 standard?

Con i prezzi attuali, la distanza tra il POCO F7 base e la versione Ultra si è assottigliata notevolmente. Per pochi euro in più, l’Ultra offre Snapdragon 8 Elite (contro l’8s Elite del modello standard), raffreddamento superiore, fotocamere migliori e più RAM. Per chi cerca le massime prestazioni Android senza spendere quanto un iPhone Pro, il POCO F7 Ultra è diventato un riferimento difficile da ignorare nel panorama degli smartphone Android del 2026.

Gestire le policy Git su centinaia di repository in Azure DevOps è una sfida comune nelle grandi organizzazioni. Per farlo in modo affidabile, molti team utilizzano servizi di automazione che verificano e correggono periodicamente la configurazione delle policy. Fino a poco fa, questa automazione era penalizzata da un’importante limitazione dell’API REST di Azure DevOps: non esisteva un modo per recuperare tutte le policy applicabili a un dato repository in una singola chiamata.

Con un singolo miglioramento all’endpoint REST, il team di Azure DevOps ha ottenuto una riduzione del 50% nell’utilizzo CPU lato server e un’accelerazione da 10x a 15x nei tempi di esecuzione complessivi. Vediamo come funziona e perché è rilevante per chi gestisce pipeline di governance automatizzata.

Come funzionano le policy Git in Azure Repos

Azure Repos supporta due categorie di policy:

• Push policies (o repository policies): si applicano all’intero repository, indipendentemente dal branch. Esempio: blocco dei commit contenenti segreti o credenziali.
• Branch policies: proteggono branch specifici e richiedono che le modifiche passino attraverso pull request. Esempio: numero minimo di reviewer, stato delle build CI.

Tutte le policy di un progetto sono memorizzate in un contenitore logico a livello di progetto, non per singolo repository o branch. Ogni policy ha un campo Scope che specifica dove nella gerarchia si applica:

# Push policy per uno specifico repo (senza ref)
2c938d1f6e6f458d816484fc51e7cf74

# Branch policy per il branch main di un repo specifico
2c938d1f6e6f458d816484fc51e7cf74:refs/heads/main

# Branch policy cross-repo (tutti i branch releases/* in tutti i repo)
*:refs/heads/releases/*

Il problema: due endpoint, nessuno sufficiente

Azure DevOps espone due endpoint per recuperare le configurazioni delle policy:

GET /_apis/policy/configurations

L’endpoint più datato. Consente di filtrare per valore esatto dello scope, ma senza supporto per l’ereditarietà. Se si passa lo scope 2c938d...74:refs/heads/releases/v1, non vengono restituite le policy con scope *:refs/heads/releases/* che pure si applicano a quel branch.

GET /_apis/git/policy/configurations

L’endpoint più moderno, con supporto all’ereditarietà. Accetta repositoryId e refName e restituisce tutte le policy che si applicano a quel branch, incluse quelle ereditate da scope più generici. È utile per rispondere alla domanda “cosa protegge il branch releases/v1 nel repo X?”

Il problema: passando solo repositoryId senza refName, questo endpoint restituisce solo le push policy applicabili all’intero repository. Le branch policy non vengono incluse perché non si applicano all’intero repo ma a branch specifici.

Il risultato pratico: un servizio di governance che deve conoscere tutte le policy applicabili a un repository — push e branch — era costretto a recuperare l’intero set di policy del progetto e filtrare lato client. In progetti con migliaia di repository e centinaia di migliaia di policy, questo significava serializzare e trasferire centinaia di megabyte di dati per ogni singola chiamata.

La soluzione: refName=~all

L’endpoint GET /_apis/git/policy/configurations supporta ora un valore speciale per il parametro refName: ~all.

Quando si passa repositoryId=<ID>&refName=~all, la risposta include:

• Tutte le branch policy che si applicano a qualsiasi branch nel repository (dirette e ereditate)
• Tutte le push policy applicabili all’intero repository
• Le policy di progetto che si applicano a tutti i repository (scope *)

Internamente, il server filtra l’intero set di policy del progetto mantenendo solo quelle con scope che inizia con * (policy a livello di progetto) o con l’ID del repository richiesto. Tutta la logica di filtering si sposta dal client al server, con payload di risposta enormemente ridotti.

Esempio di chiamata REST

GET https://dev.azure.com/{organization}/{project}/_apis/git/policy/configurations
    ?repositoryId=2c938d1f-6e6f-458d-8164-84fc51e7cf74
    &refName=~all
    &api-version=7.2

Authorization: Basic {token}

Impatto sulle prestazioni

Il team di Microsoft ha misurato l’impatto dopo aver migrato il proprio servizio interno di governance delle policy a usare refName=~all:

• CPU lato server: riduzione del 50% del consumo complessivo per questo client
• Tempo di esecuzione totale: da 1.000–3.000 ore/giorno a circa 100–150 ore/giorno, con un miglioramento da 10x a 15x

I guadagni sono proporzionali alla dimensione del progetto: più repository e policy contiene, maggiore è il vantaggio del filtering server-side rispetto al trasferimento dell’intero dataset.

Come aggiornare l’automazione esistente

Se si dispone di un servizio o script che recupera le policy per singolo repository, il refactoring è minimo. Ecco un esempio di migrazione in Python con la libreria requests:

import requests

ORG = "myorg"
PROJECT = "myproject"
REPO_ID = "2c938d1f-6e6f-458d-8164-84fc51e7cf74"
TOKEN = "..."  # PAT Azure DevOps

headers = {
    "Authorization": f"Basic {TOKEN}",
    "Content-Type": "application/json"
}

# PRIMA: recupero di tutte le policy del progetto + filtering client-side
# url = f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/policy/configurations?api-version=7.2"
# response = requests.get(url, headers=headers)
# all_policies = response.json()["value"]
# repo_policies = [p for p in all_policies if REPO_ID in str(p.get("settings", {}).get("scope", []))]

# DOPO: server-side filtering con refName=~all
url = (
    f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/git/policy/configurations"
    f"?repositoryId={REPO_ID}&refName=~all&api-version=7.2"
)
response = requests.get(url, headers=headers)
repo_policies = response.json()["value"]

print(f"Policy trovate per il repository: {len(repo_policies)}")

Disponibilità

La funzionalità è già disponibile per tutti gli utenti di Azure DevOps Services (cloud). Per quanto riguarda Azure DevOps Server (on-premise), sarà inclusa nel prossimo aggiornamento major previsto per la seconda metà del 2026.

Conclusione

Questo tipo di ottimizzazione — spostare il lavoro dal client al server tramite un parametro aggiuntivo — è un esempio classico di come miglioramenti relativamente semplici all’API possano avere impatti drastici sulle prestazioni a scala. Per chi gestisce governance automatizzata su organizzazioni Azure DevOps con molti repository, l’adozione di refName=~all è immediata e i guadagni in termini di latenza e carico sono significativi.

La documentazione completa degli endpoint è disponibile su Microsoft Learn:

• GET /_apis/git/policy/configurations
• /_apis/policy/ — set completo di endpoint

Fonte originale: Optimizing Git policy management at scale — Azure DevOps Blog

Zen Browser è un browser web open‑source basato su Mozilla Firefox, progettato per offrire un’esperienza di navigazione centrata su privacy, personalizzazione avanzata e produttività quotidiana. Nato nel 2024 come progetto indipendente, Zen si è...

🔗 Leggi il post completo

Si parla di:
Toggle

Un singolo script Python. Cinquantotto server Microsoft SQL. Zero possibilità di recupero. È il bilancio dell’operazione condotta dal gruppo Ababil of Minab contro Vyncs, servizio americano di monitoraggio GPS, in quella che i ricercatori di Gambit Security definiscono una campagna sistematica di distruzione del “recovery layer” attribuita al Ministero dell’Intelligence e Sicurezza iraniano (MOIS).

Chi è Ababil of Minab

La persona operativa “Ababil of Minab” è emersa pubblicamente tra la fine di marzo e l’inizio di aprile 2026, rivendicando l’intrusione alla Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), la distruzione di sistemi e l’esfiltrazione di dati. Il gruppo si presenta come un collettivo hacktivista indipendente, ma l’analisi forense condotta da Gambit Security racconta una storia diversa.

Le prove tecniche collegano la campagna attuale all’infrastruttura e all’attività associata a Black Shadow, cluster Iran-linked già pubblicamente attribuito dall’Israel National Cyber Directorate (INCD) al MOIS. La stessa infrastruttura utilizzata in questa operazione era stata impiegata nel 2025 in una falsa piattaforma di supporto psicologico per militari israeliani — il dominio nefeshhope[.]com — attraverso cui venivano raccolti dati personali e distribuito malware.

La portata geografica: quattro paesi, una strategia unica

La campagna ha colpito organizzazioni in Stati Uniti, Israele, Arabia Saudita e Turchia. L’esfiltrazione di dati ha interessato tutte le vittime; le operazioni distruttive sono state riservate a un sottoinsieme di esse, principalmente negli USA. Tra le organizzazioni israeliane e turche colpite figurano istituzioni educative, media, compagnie assicurative e siti culturali — identità che Gambit ha identificato ma che il gruppo non ha scelto di rendere pubbliche.

Lo strumento personalizzato di esfiltrazione recuperato dai ricercatori è FileFiend, un programma scritto in C++ in grado di raccogliere file da dischi locali e di rete per trasmetterli al server di comando. I dati venivano esfiltrati anche attraverso i web server compromessi delle stesse vittime.

Il playbook distruttivo: colpire il layer di recovery

Ciò che distingue Ababil of Minab da un attore ransomware tradizionale è la scelta deliberata di colpire non solo i dati operativi, ma l’intera infrastruttura di ripristino. Ogni tecnica impiegata introduce una sfida di recovery separata, moltiplicando i tempi e la complessità della risposta agli incidenti.

LA Metro (LACMTA): Gli attaccanti hanno ottenuto accesso a VMware vCenter, eliminando le virtual machine insieme ai file disco. Ore dopo, la metropolitan authority segnalava interruzioni nel sistema mobile di pagamento dei trasporti. In seguito, tramite accesso RDP a una macchina Windows guest, hanno eliminato le partizioni dei dischi attraverso lo strumento nativo di gestione dei volumi.

South Florida Regional Transportation Authority: Accesso RDP con privilegi di amministratore locale su un server IIS, seguito dalla cancellazione di database tramite Microsoft SQL Server Management Studio e dall’utilizzo di WipeFile per eliminare il contenuto delle directory del web server e dei backup.

UNIMAC: Formattazione delle partizioni, eliminazione dei volumi e creazione di nuovi volumi rinominati “Minab” come firma. Distruzione della catena di backup attraverso Veeam Backup & Replication.

Lo script automatizzato e l’uso di ChatGPT

L’attacco a Vyncs, il servizio americano di monitoraggio GPS via OBD-II, rappresenta l’episodio più emblematico dell’intera campagna dal punto di vista dell’automazione offensiva. Gli attaccanti hanno sviluppato un file main.py che si connetteva automaticamente a 58 server Microsoft SQL Server e cancellava i database degli utenti. Parallelamente, operatori umani eliminavano manualmente i backup e le directory di sistema Windows. Una volta rimossi i dati, anche la connessione al server si è interrotta — conferma dell’avvenuta distruzione dell’infrastruttura.

Un dettaglio che segna una svolta nell’impiego dell’AI offensiva: nei video pubblicati dallo stesso gruppo, i ricercatori hanno osservato gli operatori utilizzare ChatGPT per raffinare lo script di cancellazione, in particolare per escludere i database di sistema di Microsoft SQL Server dall’elenco degli oggetti da eliminare, assicurandosi che lo script agisse esclusivamente sui dati degli utenti senza bloccarsi per errori di sistema.

“Modern intrusion operators are moving from initial access straight into the recovery layer, virtualization, backups, storage volumes, to maximize destruction and deny remediation. The skill required to do that at scale is collapsing in parallel. As AI capabilities become widely available, any actor, skilled or not, will be able to execute this kind of campaign.”
— Gambit Security Threat Intelligence Team

Implicazioni strategiche: la nuova frontiera del cyber warfare

La campagna di Ababil of Minab illustra un cambiamento fondamentale nella dottrina degli attacchi informatici statali. Non si tratta più solo di compromettere i sistemi o rubare dati: l’obiettivo diventa negare la capacità di recupero, trasformando ogni intrusione in un danno duraturo che richiede settimane o mesi per essere risolto.

La combinazione di tecniche — eliminazione di VM, cancellazione di database, distruzione dei backup Veeam, wiping dei volumi — è progettata per costringere i team di risposta agli incidenti a eseguire processi di remediation separati in parallelo, aumentando la probabilità che almeno uno fallisca o che l’organizzazione non possa tornare operativa nei tempi attesi.

Indicatori di compromissione (IoC)

# Infrastruttura nota
Dominio: nefeshhope[.]com
  Utilizzo: finta piattaforma di supporto psicologico per militari israeliani (2025)
  Collegamento: attributo a Iran MOIS / Black Shadow

# Strumenti identificati
FileFiend - Exfiltration tool C++
  Funzione: raccolta file da dischi locali e di rete, trasmissione a C2

main.py - Script di distruzione DB
  Funzione: connessione automatica a SQL Server, eliminazione database utenti
  Nota: raffinato con ChatGPT per escludere DB di sistema

WipeFile - Utility di cancellazione sicura
  Utilizzo: pulizia directory web server e backup

# Tecniche TTP (MITRE ATT&CK)
T1078 - Valid Accounts (RDP con credenziali admin)
T1485 - Data Destruction
T1490 - Inhibit System Recovery (Veeam destruction)
T1486 - Data Encrypted for Impact (analoga a ransomware senza riscatto)
T1041 - Exfiltration Over C2 Channel (FileFiend)

Due righe per i difensori

La campagna di Ababil of Minab rende evidente che la sicurezza perimetrale da sola non è più sufficiente. Le organizzazioni devono investire nella resilienza operativa, con particolare attenzione a tre aree critiche:

• Backup immutabili e isolati: I backup devono essere fisicamente e logicamente separati dall’ambiente primario. La compromissione di Veeam o di altri sistemi di backup integrati nella stessa infrastruttura virtuale vanifica qualsiasi piano di recovery.
• Protezione dell’accesso all’infrastruttura di virtualizzazione: VMware vCenter e sistemi equivalenti devono essere protetti con autenticazione multi-fattore obbligatoria, accesso privilegiato minimo e segmentazione di rete dedicata. Un account vCenter compromesso può eliminare l’intera infrastruttura in minuti.
• Validazione continua del recovery: Non è sufficiente avere backup. Le organizzazioni devono testare regolarmente la capacità di ripristino in scenari avversariali — non solo in caso di guasto hardware. La domanda non è “abbiamo i backup?”, ma “riusciremo davvero a ripristinare in tempo?”.

Il report completo di Gambit Security è disponibile per il download sul loro sito ed include la documentazione forense completa, i dettagli sull’infrastruttura e l’analisi delle vittime non ancora pubblicamente identificate.

Si parla di:
Toggle

CrowdStrike Counter Adversary Operations, Google e Shadowserver Foundation abbattono simultaneamente tutti e quattro i canali di comando e controllo della botnet Glassworm. Infetta da oltre un anno attraverso l’ecosistema open-source, l’infrastruttura criminale — progettata per sopravvivere ai takedown tradizionali usando blockchain, peer-to-peer e servizi Google come dead-drop — perde il controllo di migliaia di macchine di sviluppatori in tutto il mondo.

Perché gli sviluppatori sono il bersaglio ideale

Glassworm rappresenta un cambio di paradigma nel threat landscape: gli attaccanti non prendono più di mira direttamente i prodotti software — prendono di mira le persone che li costruiscono. Un singolo workstation di sviluppatore compromessa può aprire agli attaccanti l’accesso a repository di codice sorgente, piattaforme cloud, pipeline CI/CD, credenziali di accesso e registry di pacchetti. Da lì, il malware può propagarsi a valle della supply chain, raggiungendo organizzazioni che non hanno mai avuto contatti diretti con gli operatori di Glassworm.

Dall’inizio del 2025, gli operatori di Glassworm hanno condotto una campagna sistematica contro gli sviluppatori su Windows, macOS e Linux, sfruttando tre vettori principali dell’ecosistema open-source:

1. Estensioni VSCode trojanizzate su OpenVSX

Le estensioni malevoli venivano pubblicate sul marketplace OpenVSX, camuffate da strumenti legittimi come time tracker e code formatter. L’impatto andava oltre VSCode: qualsiasi editor compatibile con l’ecosistema — Cursor, Positron, Windsurf, VSCodium — risultava vulnerabile allo stesso payload.

2. Pacchetti npm e Python con hook di installazione malevoli

Il codice malevolo veniva eseguito durante l’installazione ordinaria delle dipendenze, attraverso hook postinstall e script setup.py. Per lo sviluppatore, l’operazione appariva come un normale aggiornamento di libreria. Il payload veniva eseguito prima che qualsiasi analisi manuale potesse rilevarlo.

3. Repository GitHub avvelenati con credenziali rubate

Oltre 300 repository GitHub sono stati compromessi usando credenziali di sviluppatori ottenute in infezioni precedenti. Gli operatori eseguivano force push sui branch predefiniti, inserendo codice malevolo dove altri sviluppatori si aspettavano di trovare il progetto originale — un classico attacco alla fiducia implicita nell’ecosistema open-source.

GlasswormRAT: le capacità del malware

Il payload finale installato dalle infezioni Glassworm è GlasswormRAT, un remote access tool scritto in Node.js con funzionalità complete: furto di informazioni, harvesting di credenziali e controllo remoto completo del sistema compromesso. Nel corso di oltre un anno di operazioni, gli sviluppatori di Glassworm hanno evoluto continuamente il codice, passando da JavaScript a Rust e Zig, ampliando il supporto a più ecosistemi e costruendo infrastrutture ridondanti in previsione di eventuali takedown.

L’architettura C2 a quattro canali: progettata per sopravvivere

L’elemento più sofisticato di Glassworm è la sua infrastruttura di comando e controllo, progettata esplicitamente per resistere ai takedown tradizionali. I ricercatori hanno identificato quattro canali distinti che garantivano ridondanza operativa:

• Blockchain Solana: Gli indirizzi dei server C2 venivano codificati nei campi memo delle transazioni blockchain. Una volta scritti, i dati sono immutabili e pubblicamente accessibili — non possono essere rimossi da una richiesta a un hosting provider.
• BitTorrent DHT (Distributed Hash Table): GlasswormRAT interrogava la rete peer-to-peer BitTorrent cercando dati di configurazione attraverso chiavi pubbliche hardcoded. Una rete decentralizzata senza single point of failure, impossibile da abbattere con i metodi convenzionali.
• Google Calendar: Il malware usava i titoli degli eventi di Google Calendar come dead-drop per path C2 codificati in Base64. Per i difensori, bloccare il dominio avrebbe significato interrompere anche l’uso legittimo del calendario aziendale.
• Server VPS diretti: Infrastruttura C2 tradizionale su provider commerciali, usata per la delivery dei payload finali alle macchine infette.

La combinazione di questi quattro canali rendeva qualsiasi takedown parziale inefficace: abbattere uno solo avrebbe consentito agli operatori di ripristinare il controllo attraverso gli altri tre. Questo è il motivo per cui il takedown ha richiesto una coordinazione precisa tra CrowdStrike, Google e Shadowserver Foundation per colpire tutti e quattro i canali simultaneamente alle 14:00 UTC.

Attribuzione: gli indizi puntano verso la Russia

CrowdStrike attribuisce con moderata fiducia la campagna a operatori con sede in Russia, basandosi su un pattern coerente osservato per oltre un anno. Il malware effettua controlli runtime sulla locale, la lingua e il fuso orario della vittima, terminando silenziosamente se la macchina risulta in un paese CIS — una tecnica consolidata tra i cybercriminali dell’area ex-sovietica per evitare di colpire obiettivi vicini a casa. Nel codice sorgente compaiono commenti in russo.

CrowdStrike precisa che nessun indicatore singolo costituisce prova definitiva: i controlli di locale possono essere copiati, i commenti possono derivare da strumenti AI. Ma il pattern complessivo, consistente per oltre dodici mesi di osservazione, è considerato sufficientemente solido per l’attribuzione.

Come verificare un’infezione da Glassworm

Dopo il takedown, tutte le macchine infette da Glassworm tentano di contattare un IP gestito da CrowdStrike (sinkholed). Qualsiasi connessione a questo indirizzo nei log di rete indica un’infezione attiva che richiede remediation immediata.

# Indicatore di rete (sinkhole CrowdStrike post-takedown)
IP: 164.92.88[.]210
# Cosa verificare:
- Log di rete per connessioni a 164.92.88[.]210
- Telemetria endpoint su workstation sviluppatori
- Installazioni recenti di estensioni OpenVSX da fonti non verificate
- Pacchetti npm o Python installati da repository non ufficiali
- Repository GitHub con commit anomali o force push recenti
# YARA Rule 1: GlasswormRAT
rule CrowdStrike_GlasswormRat_01 : glassworm glasswormrat
{
    meta:
        description = "Characteristic strings in Glassworm RAT script"
        malware_family = "GlasswormRAT"
    strings:
        $download = "DownloadManager" ascii
        $socks = "start_socks" ascii
        $nodejs = "https://nodejs.org/download/release" ascii
        $dht = "bootstrap" ascii
    condition:
        all of them
}
# YARA Rule 2: Glassworm Python Downloader
rule CrowdStrike_GlasswormDownloader_01 : glassworm
{
    meta:
        description = "Obfuscated Python installer Glassworm variant"
        malware_family = "Glassworm"
    strings:
        $zlib = "__import__('zlib')" ascii
        $decomp = "decompress(" ascii
        $lambda = "lambda" ascii
        $exec = /exec\(compile\(.{5,20}, '', 'exec'\)\)/
    condition:
        all of them and filesize < 10KB
}

Il takedown come modello: cosa cambia nella difesa della supply chain

L'operazione Glassworm dimostra che la difesa attraverso la sola detection è strutturalmente insufficiente contro gli attacchi alla supply chain. I pacchetti malevoli vengono installati in secondi durante aggiornamenti di routine; la detection avviene dopo che il danno è già fatto. Con decine di ecosistemi — npm, PyPI, OpenVSX, GitHub — e milioni di pacchetti con controlli di sicurezza limitati, gli attaccanti possono pubblicare codice malevolo e raggiungere migliaia di vittime in minuti.

Il takedown coordinato imposta un precedente operativo: la disruption proattiva dell'infrastruttura avversariale è tecnicamente possibile anche contro architetture C2 deliberatamente progettate per la resilienza. La precisione richiesta — colpire simultaneamente blockchain, DHT, servizi Google e VPS tradizionali — ha richiesto la collaborazione tra intelligence privata (CrowdStrike), piattaforme tecnologiche (Google) e coordinamento internazionale (Shadowserver Foundation).

Per i team di sicurezza, le raccomandazioni immediate includono: audit delle estensioni installate negli ambienti di sviluppo, verifica dei pacchetti npm e Python con strumenti come npm audit e pip-audit, revisione dei log di accesso ai repository GitHub per force push anomali, e implementazione di controlli di integrità sulle dipendenze nei pipeline CI/CD.

(in)sicurezza digitale

2026-04-11 08:03:16

GlassWorm: il worm che infetta tutti gli IDE tramite un’estensione OpenVSX contraffatta

Un’estensione contraffatta nel marketplace OpenVSX installa silenziosamente un dropper compilato in Zig che individua e infetta tutti gli IDE compatibili con VS Code presenti sulla macchina, per poi deployare un RAT con C2 su blockchain Solana e un’estensione Chrome per rubare sessioni e keystroke. La campagna GlassWorm è attiva da oltre un anno e ha appena compiuto il suo salto evolutivo più sofisticato.

Una campagna che cresce da un anno

GlassWorm non è una minaccia nuova: Aikido Security ne traccia l’evoluzione dal marzo 2025, quando fu individuata la prima variante nascosta in pacchetti npm attraverso caratteri Unicode invisibili per offuscare il payload. Da allora, la campagna ha iterato costantemente le proprie tecniche, arrivando oggi a una versione che colpisce non un singolo editor, ma l’intero ecosistema degli ambienti di sviluppo installati su una macchina — con una catena di infezione a più stadi difficile da individuare con le sole difese tradizionali.

Il vettore iniziale: un’estensione che finge di essere WakaTime

Il punto di ingresso è un’estensione pubblicata sul marketplace OpenVSX sotto il nome specstudio/code-wakatime-activity-tracker. L’estensione si spaccia per WakaTime, uno strumento molto diffuso tra gli sviluppatori che tiene traccia del tempo trascorso nel codice. Una volta installata, esegue immediatamente un codice di installazione minimale — dove un modulo punta a binari nativi Node.js compilati per la piattaforma target.

Il dropper Zig: fuori dalla sandbox JavaScript

Il vero cuore della tecnica è l’uso di binari nativi Node.js (file .node) compilati con Zig — un linguaggio di sistema relativamente giovane e poco presidiato dai motori antivirus. Questi addon vengono caricati direttamente nel runtime di Node con accesso completo al sistema operativo, bypassando completamente la sandbox JavaScript di VS Code. Il comportamento è fondamentalmente diverso da quello di un’estensione normale: non è codice JS interpretato con permessi limitati, ma una libreria nativa con diritti equivalenti al processo padre. I binari identificati sono specifici per piattaforma: su Windows viene deployato win.node (PE32+ DLL), mentre su macOS viene utilizzato mac.node (Universal Mach-O). Quest’ultimo conteneva simboli di debug rivelatori, con un percorso che ha permesso ai ricercatori di identificare il developer environment dell’autore.

Autopropagazione: infettare ogni IDE sulla macchina

Una volta eseguito, il dropper Zig non si limita a compromettere l’IDE corrente: scansiona il filesystem alla ricerca di tutti gli ambienti di sviluppo compatibili con le estensioni VS Code. Su Windows controlla le directory %LOCALAPPDATA%\Programs\ e %ProgramFiles%; su macOS la cartella /Applications/. Gli IDE target includono Microsoft VS Code e VS Code Insiders, ma anche i fork come Cursor (AI-first IDE in rapida adozione), Windsurf, VSCodium e Positron. Ogni editor trovato viene infettato con una seconda estensione malevola, installata silenziosamente tramite CLI usando il parametro –install-extension. Il secondo stadio si maschera da una estensione di auto-import con milioni di installazioni, scaricato da un repository GitHub sotto controllo degli attaccanti.

Il payload finale: Solana come C2, RAT e furto di sessioni Chrome

La seconda estensione malevola implementa le capacità di spionaggio vere e proprie. Il meccanismo di C2 è particolarmente innovativo: invece di puntare a un server fisso, il malware interroga la blockchain Solana per recuperare l’indirizzo del server di comando — una tecnica che rende il blocco dell’infrastruttura C2 praticamente impossibile senza bloccare l’intera blockchain. Tra le funzionalità documentate ci sono: geofencing contro sistemi con impostazioni locali russe (l’esecuzione viene saltata), esfiltrazione di segreti, token di sessione e chiavi API dal workspace dello sviluppatore, installazione di un RAT persistente con comunicazione cifrata, e deploy di un’estensione Chrome malevola per il furto di cookie di sessione e keystroke logging.

Indicatori di compromissione

## Estensioni malevole OpenVSX
specstudio/code-wakatime-activity-tracker  (1° stadio)
floktokbok.autoimport                       (2° stadio)

## Hash SHA-256 dei binari nativi Zig
win.node (Windows PE32+ DLL):
  2819ea44e22b9c47049e86894e544f3fd0de1d8afc7b545314bd3bc718bf2e02

mac.node (macOS Universal Mach-O):
  112d1b33dd9b0244525f51e59e6a79ac5ae452bf6e98c310e7b4fa7902e4db44

## Repository GitHub per distribuzione stage-2
ColossusQuailPray/oiegjqde

## Debug artifact (attributione autore)
/Users/davidioasd/Downloads/vsx_installer_zig

## IDE target confermati
VS Code, VS Code Insiders, Cursor, Windsurf, VSCodium, Positron

Perché questa campagna è un segnale d’allarme per i team di sicurezza

GlassWorm dimostra come il marketplace delle estensioni IDE sia diventato una superficie d’attacco matura e sfruttata attivamente. La compromissione di un singolo sviluppatore può propagarsi a tutta l’organizzazione attraverso repository git, ambienti CI/CD e pipeline di build condivisi — con un impatto potenziale molto superiore a quello di un malware che colpisce un endpoint generico. Il fatto che il dropper salti deliberatamente i sistemi russi suggerisce un attore state-sponsored o comunque con motivazioni geograficamente definite, probabilmente orientato verso organizzazioni di sviluppo software in occidente e in Asia.

Consigli per i difensori

I team di sicurezza dovrebbero esaminare l’elenco delle estensioni installate su tutti gli IDE degli sviluppatori, con particolare attenzione a estensioni non presenti nel Visual Studio Marketplace ufficiale ma solo su OpenVSX. L’introduzione di policy di allowlist per le estensioni VS Code, già supportata dalla funzionalità di Policy Management di VS Code, è oggi una misura consigliata in ambienti corporate. A livello di EDR, alert sulla creazione di file .node in directory di estensioni IDE e sull’esecuzione di processi IDE con parametri –install-extension da processi non interattivi sono indicatori ad alta fedeltà. L’analisi dei log di rete alla ricerca di chiamate RPC verso nodi Solana da processi Node.js può aiutare a rilevare la fase di C2 in modo precoce.

MediaTek ha ufficialmente presentato il Dimensity 8550, il suo nuovo SoC per smartphone di fascia medio-alta. Il chip porta una novità particolarmente rilevante per gli utenti Android: il supporto nativo a Gemini Nano V3, il modello AI di Google ottimizzato per l’elaborazione direttamente sul dispositivo senza necessità di connessione cloud.

Gemini Nano V3 e il nuovo LLM Booster

La caratteristica principale del Dimensity 8550 è l’integrazione di un modulo chiamato LLM Booster, progettato per accelerare l’esecuzione di modelli linguistici di grandi dimensioni direttamente sullo smartphone. Questo rende possibile l’uso di funzionalità AI avanzate anche offline, aprendo la strada ad assistenti intelligenti e strumenti generativi sempre disponibili. La NPU è la stessa NPU 880 già presente nel Dimensity 8500, mentre la CPU mantiene l’architettura “All Big Core” con 8 core Cortex-A725 fino a 3,4 GHz, prodotti con processo TSMC N4P a 4nm.

Display 144Hz, video 4K e connettività moderna

Il Dimensity 8550 supporta display fino a 1440p con refresh rate di 144Hz e la codifica video in 4K/60fps con decoding del formato AV1. Sul fronte memoria è compatibile con LPDDR5X (fino a 9.600 Mbps) e storage UFS 4.0. La connettività include modem 5G dual-SIM, Wi-Fi 6E e Bluetooth 5.4, con GPU Mali-G720 MC8.

Honor 600 Pro primo smartphone con Dimensity 8550

Il primato di primo dispositivo equipaggiato con il nuovo chip spetta all’Honor 600 Pro, già annunciato per il mercato cinese. Nelle prossime settimane ci si aspetta che altri produttori Android adottino il Dimensity 8550 su modelli di fascia medio-alta, portando le funzionalità AI on-device a una platea sempre più ampia di utenti. Un segnale chiaro che l’intelligenza artificiale sta diventando standard anche per gli smartphone sotto i 500 euro.

Google ha rilasciato un aggiornamento significativo per l’app Pixel Buds su Android. Il nuovo update, disponibile tramite Play Store con la versione 1.0.915175631, porta un redesign dell’icona e una funzionalità inedita per chi possiede più coppie di auricolari Pixel.

Una nuova icona in linea con il design Google

La modifica più evidente del nuovo aggiornamento è il cambio dell’icona dell’app. Il vecchio logo — che raffigurava onde sonore nei colori Google — lascia spazio a un design che mostra la custodia degli auricolari aperta, con un gradiente che passa dal blu al viola. Si tratta dello stesso stile visivo adottato di recente da altre app Google come Pixel Journal e Now Playing, segno di una coerenza crescente nell’ecosistema visivo del colosso di Mountain View.

Google ha dichiarato che il nuovo look adotta «una palette di colori moderna che rafforza il senso di unità con l’ecosistema Google».

La nuova Landing Page per gestire più Pixel Buds

Sul fronte funzionale, l’aggiornamento introduce una nuova Landing Page pensata per gli utenti che possiedono più di un paio di Pixel Buds. La schermata mostra tutti i dispositivi associati in un’unica vista, permettendo di passare rapidamente da un modello all’altro senza navigare tra menu differenti.

Ogni auricolare viene visualizzato con uno sfondo a gradiente che rispecchia il colore fisico del dispositivo stesso, rendendo il riconoscimento visivo ancora più immediato. Una funzionalità comoda per chi usa un paio per casa, uno per lo sport e uno per i viaggi.

Distribuzione graduale in corso

L’aggiornamento è già disponibile sul Play Store, ma la distribuzione avviene in modo graduale: alcuni utenti potrebbero ancora non vedere la nuova versione disponibile. Il rollout dovrebbe completarsi nelle prossime settimane. Il rinnovamento dell’app Pixel Buds si inserisce nel percorso più ampio di Google verso un design system unificato su tutti i propri prodotti e servizi.

PeerTube è una piattaforma video decentralizzata e open source, sviluppata dall’associazione francese Framasoft, che nasce con l’obiettivo di offrire un’alternativa realmente libera, trasparente e indipendente ai servizi centralizzati di condivisione video controllati dalle grandi corporazioni del web. Introdotta nel 2018, questa piattaforma...

🔗 Leggi il post completo

Calibre è un’applicazione per la gestione completa degli e‑book, progettata per organizzare, convertire e sincronizzare libri digitali all’interno della propria distribuzione GNU/Linux o su altri sistemi operativi. La crescente diffusione dei libri digitali, leggibili su dispositivi come lettori...

🔗 Leggi il post completo

Nothing ha ufficialmente lanciato il Nothing Phone (4a), il suo nuovo smartphone di fascia media che porta avanti il design iconico con il retro trasparente e le luci Glyph. Il dispositivo si posiziona come una valida alternativa per chi cerca un’esperienza Android diversa dal solito, senza dover spendere una fortuna.

Design e identità: l’eredità Glyph continua

Come i suoi predecessori, il Nothing Phone (4a) porta il caratteristico retro trasparente che lascia intravedere i componenti interni — un elemento che ha reso Nothing immediatamente riconoscibile nel panorama Android. Le luci Glyph, che fungono da notifiche visive personalizzabili, sono naturalmente presenti e ulteriormente perfezionate rispetto alle generazioni precedenti.

Posizionamento di prezzo

Il Nothing Phone (4a) viene proposto a un prezzo di listino di 59.800 yen in Giappone — equivalente a circa 370 euro al cambio attuale — nella configurazione da 8 GB di RAM e 128 GB di storage. Si tratta di un posizionamento competitivo che lo mette in diretta concorrenza con i mid-range di Xiaomi, Google Pixel 9a e la fascia media di Samsung.

Nothing OS: la vera differenza

Il punto di forza del Phone (4a) non è solo il design, ma anche il software. Nothing OS è una delle interfacce Android più pulite e veloci disponibili sul mercato, con un approccio minimalista che punta alla fluidità e alla semplicità. Gli aggiornamenti software sono garantiti per diversi anni, rendendolo un investimento più solido nel lungo periodo.

Per il pubblico italiano appassionato di Android, il Nothing Phone (4a) rappresenta una delle scelte più originali nella fascia di prezzo media. Chi cerca qualcosa di diverso dai soliti Samsung, Xiaomi o Google, ma non vuole spendere quanto un flagship, troverà nel 4a un candidato decisamente interessante.

Comprare uno smartphone in Europa costa sempre di più. Secondo l’ultimo rapporto di Omdia, nel primo trimestre del 2026 il prezzo medio di vendita degli smartphone nel mercato europeo ha raggiunto i 580 euro, un nuovo massimo storico. Una tendenza che non accenna a invertirsi e che cambierà profondamente le abitudini d’acquisto dei consumatori.

I telefoni economici spariscono dagli scaffali

La causa principale di questa escalation è la rapida scomparsa dei dispositivi sotto i 200 euro. Questa fascia di prezzo, che una volta rappresentava una fetta importante del mercato, è scesa a meno di un quarto delle spedizioni totali. I produttori stanno abbandonando i margini risicati dell’entry-level per concentrarsi su modelli di fascia media e alta, dove i profitti sono ben più sostanziosi.

Nel complesso, le spedizioni europee nel Q1 2026 sono state 33,1 milioni di unità, in crescita del 2% anno su anno: la domanda tiene, ma lo fa su prodotti sempre più costosi.

Samsung prima, Apple in crescita, Xiaomi in difficoltà

Nel dettaglio dei brand, Samsung mantiene la leadership con il 38% del mercato, supportata in parte dagli sconti sul Galaxy A16 4G — ma anche rallentata dai ritardi nell’uscita dei nuovi Galaxy S26, A57 e A37. Apple invece cresce del 9% nelle spedizioni, grazie a iPhone 17 ma anche ai modelli più economici come iPhone 16e, venduti senza grandi sconti.

Xiaomi soffre: -15% nelle spedizioni, penalizzata da problemi di fornitura. Tuttavia, anche per il marchio cinese il prezzo medio è salito del 21%, segno di un riposizionamento verso l’alto condiviso da praticamente tutti i produttori.

Cosa significa per i consumatori italiani

Per chi è alla ricerca di un buon smartphone a prezzo contenuto, il panorama si fa sempre più complicato. I modelli economici di qualità si riducono, e quelli che rimangono tendono a essere aggiornati meno frequentemente. Scegliere bene diventa fondamentale: meglio aspettare offerte sui modelli dell’anno precedente o puntare su brand come Realme, Poco o Honor che per ora continuano a presidiare il segmento accessibile.

exfatprogs è una raccolta di strumenti progettati per funzionare nello spazio utente, cioè nella parte del sistema in cui operano i programmi utilizzati quotidianamente, senza intervenire direttamente nelle funzioni interne del kernel Linux. Questa...

🔗 Leggi il post completo

Con One UI 8.5, Samsung sta democratizzando alcune delle funzionalità fotografiche più apprezzate della gamma Galaxy, portandole finalmente anche sui modelli di fascia media. La protagonista di questa espansione è Camera Assistant, il modulo avanzato che permette di affinare il comportamento della fotocamera ben oltre le impostazioni standard.

Cos’è Camera Assistant e perché è importante

Camera Assistant è un modulo disponibile tramite Good Lock o Galaxy Store che estende le opzioni della fotocamera nativa Samsung. Non sostituisce l’app fotocamera, ma aggiunge uno strato di controllo granulare che gli appassionati di fotografia mobile apprezzeranno. Tra le funzioni disponibili si trovano:

• Controllo del cambio automatico tra le lenti
• Regolazione della velocità dello shutter
• Impostazioni di nitidezza e morbidezza per foto e video
• Attivazione/disattivazione dell’Auto HDR
• Registrazione video in HDR10+
• Regolazione del numero di scatti nel timer
• Aggiunta di scorciatoie per lo zoom

I nuovi modelli supportati con One UI 8.5

Fino ad ora Camera Assistant era disponibile principalmente sui Galaxy S di fascia alta e su alcuni Galaxy A5x. Con One UI 8.5, il supporto si allarga in modo significativo, includendo:

• Galaxy A37, A36, A35, A34
• Galaxy M36, M35, M34

Si tratta di dispositivi di fascia media molto diffusi, che ora possono offrire un’esperienza fotografica più personalizzabile.

La strategia Samsung: funzioni premium per tutti

L’espansione di Camera Assistant rispecchia una tendenza più ampia di Samsung: ridurre il gap tra i modelli premium e quelli di fascia media in termini di software. Già con le ultime versioni di One UI, molte funzioni Galaxy AI erano state estese ai modelli più economici. Ora tocca alle funzionalità fotografiche avanzate fare lo stesso percorso.

Per chi possiede un Galaxy di fascia media e vuole esprimere al massimo il potenziale della propria fotocamera, il consiglio è di verificare la disponibilità dell’aggiornamento One UI 8.5 e di esplorare Camera Assistant non appena disponibile.

I risultati di Xiaomi per il primo trimestre del 2026 raccontano una storia di trasformazione: meno smartphone venduti, ma a prezzi più alti. Un cambio di strategia deliberato, che spinge il produttore cinese verso il segmento premium del mercato.

Spedizioni in calo, ma il terzo posto è mantenuto

Nel primo trimestre 2026, Xiaomi ha spedito 33,8 milioni di smartphone, con un calo del 19,2% rispetto allo stesso periodo dell’anno precedente — la contrazione più significativa tra i primi cinque produttori mondiali. Nonostante ciò, l’azienda conserva la terza posizione globale, davanti a OPPO (-6,6%) e vivo (-6,7%).

Al contrario, Samsung e Apple hanno registrato rispettivamente +8,0% e +9,9%, confermando la solidità del segmento alto di gamma.

Prezzi medi in salita del 8% anno su anno

Il dato più rilevante è l’aumento del prezzo medio di vendita (ASP): da 1.211 a 1.310 yuan cinesi, con una crescita di circa l’8% su base annua. Xiaomi sta chiaramente scommettendo su modelli come la serie Xiaomi 17 e 15T per alzare il profilo del brand nel segmento medio-alto e premium.

Forte presenza anche nel wearable

Non solo smartphone: Xiaomi mantiene la terza posizione mondiale e la seconda in Cina nel mercato delle smartband, e si piazza seconda globalmente e in Cina nel segmento degli auricolari true wireless (TWS). Un ecosistema accessori sempre più solido, che complementa l’offerta mobile.

Geograficamente, Xiaomi è seconda in America Latina, terza in Europa, Africa, Medio Oriente e Sud-Est asiatico, e quarta in India. Un’impronta globale che — nonostante i numeri in calo — rimane ampia e difficile da ignorare.

La sfida ora è capire se il riposizionamento verso l’alto darà i frutti sperati nel medio termine, o se il calo di volumi si rifletterà anche sulla redditività complessiva del segmento smartphone.

Brutte notizie in vista per chi sta pensando di acquistare un Galaxy di fascia alta: Samsung starebbe valutando un aumento dei prezzi per alcuni modelli smartphone, a causa del continuo rialzo dei costi dei componenti di memoria. Secondo le ultime indiscrezioni, i primi mercati a essere interessati potrebbero essere quelli europei, già a partire da giugno 2026.

Galaxy Z Fold7 e Z Flip7 nel mirino: fino a 100 euro in più

Stando alle fonti, i modelli più a rischio di ritocco al rialzo sarebbero i prossimi pieghevoli Galaxy Z Fold7 e Galaxy Z Flip7, con aumenti stimati attorno ai 100 euro rispetto alle generazioni precedenti. Anche la serie Galaxy S potrebbe non essere esclusa, sebbene i dettagli sui modelli specifici non siano ancora chiari.

Il DRAM alle stelle: i produttori non riescono più ad assorbire i costi

Il problema di fondo è l’impennata dei prezzi di DRAM e memorie NAND, in crescita ben oltre le aspettative. Fino a qualche tempo fa i produttori riuscivano a tamponare questi rincari grazie a ottimizzazioni interne, ma il livello attuale sembra aver superato la soglia di sostenibilità. I moderni smartphone di fascia alta incorporano quantità crescenti di RAM — spinti dalle funzioni AI sempre più intensive — e questo li rende particolarmente vulnerabili alle fluttuazioni dei prezzi della memoria.

Un problema che potrebbe riguardare tutto il mercato Android

Attenzione: Samsung non è l’unico produttore a fronteggiare questa situazione. Gli analisti di settore avvertono che, entro la seconda metà del 2026, la carenza di memorie potrebbe acuirsi ulteriormente, trascinando in alto i prezzi di molti altri marchi Android — e potenzialmente anche Apple. Chi sta pianificando un acquisto nei prossimi mesi farebbe bene a non rimandare troppo a lungo.

Le indiscrezioni sul prossimo Galaxy S27 di Samsung si fanno sempre più interessanti, e riguardano soprattutto la configurazione fotografica del modello Pro. Secondo le ultime informazioni trapelate, Galaxy S27 Pro potrebbe non solo colmare il divario con l’Ultra, ma addirittura superarlo in alcune situazioni di scatto.

Zoom diverso ma non necessariamente inferiore

Stando ai leak, Galaxy S27 Pro e Galaxy S27 Ultra condivideranno lo stesso sensore principale e la stessa fotocamera ultra-grandangolare. La vera differenza si troverà nella lente telefoto: il modello Pro monterà un sensore da 50 MP con zoom ottico 3,5x, mentre l’Ultra punterà su uno zoom 5x.

A prima vista sembrerebbe una vittoria per l’Ultra, ma la situazione è più complessa. Samsung sta potenziando le tecniche di crop digitale basate sul sensore principale da 200 MP, rendendo la semplice comparazione dei valori di ingrandimento ottico meno significativa rispetto al passato. In certe condizioni, il 3,5x del Pro potrebbe risultare più versatile e naturale nel campo visivo rispetto al 5x.

Addio al doppio zoom sull’Ultra

Un’altra novità riguarda l’Ultra: il tradizionale obiettivo 3x presente sulle versioni precedenti verrebbe eliminato. Era una lacuna da tempo segnalata dagli utenti, che si trovavano un salto brusco tra il grandangolo e il teleobiettivo 5x. Con la nuova configurazione, questa debolezza potrebbe finalmente essere risolta.

Galaxy S27 Pro: il flagship “compatto” per gli esigenti

L’immagine che emerge è quella di un Galaxy S27 Pro che punta a ridefinire il concetto di “modello intermedio” nella gamma Samsung. Non più semplicemente un passo indietro rispetto all’Ultra, ma una valida alternativa con un proprio punto di forza: compattezza maggiore e fotocamera equilibrata.

Per chi non necessita dell’enorme display o dello stilo dell’Ultra, il Pro potrebbe rivelarsi la scelta più razionale — e forse persino superiore in determinati contesti fotografici. Resta da vedere se queste specifiche verranno confermate con l’arrivo ufficiale del dispositivo, atteso presumibilmente all’inizio del 2027.

Dopo il Colorado, anche lo stato dove sono nati i Doors rivede lo spettro di applicabilità della legge che demanda ai sistemi operativi la verifica sull'età di chi li usa.
La sensazione è che sia ancora troppo poco, principalmente perché i produttori di hardware con Linux preinstallato, a quanto pare, dovranno comunque adeguarsi.

🔗 Leggi il post completo

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

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;

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'
);

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