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

Cos’è Azure MCP Server?

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

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

Le principali novità della versione 2.0

Deployment remoto self-hosted

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

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

Integrazione con Microsoft Foundry e flusso OBO

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

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

Security hardening

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

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

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

Supporto sovereign cloud

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

Come installare e usare Azure MCP Server

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

Via IDE extension

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

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

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

Via GitHub Copilot CLI o Claude Code

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

Via Docker (deployment self-hosted)

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

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

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


Panoramica degli strumenti disponibili

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

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

Implicazioni per il workflow degli sviluppatori

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

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

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

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

Conclusione

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

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

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

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

Il Vettore: un’infrastruttura legittima trasformata in arma

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

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

Anatomia dell’attacco: come funziona la truffa SPID

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

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

Target primario: Pubbliche Amministrazioni

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

MITRE ATT&CK: mappatura delle tecniche

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

Indicatori di Compromissione (IoC)

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

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

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

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

Raccomandazioni per i difensori e le Pubbliche Amministrazioni

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

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

Nel 2024 avevamo già parlato di Datafetch, uno script Bash progettato per mostrare informazioni di sistema direttamente dal terminale.Chi desidera recuperare quella prima analisi può leggerla qui: Datafetch – Strumento avanzato per la rilevazione...

🔗 Leggi il post completo

Si intensificano le indiscrezioni sul Motorola Edge 70 Pro, lo smartphone di fascia media-alta di Motorola che potrebbe essere presentato entro la fine di aprile. Nuovi leak hanno svelato il comparto fotografico, che si preannuncia come il vero punto di forza del dispositivo.

Tre fotocamere con grandangolo da 12mm e zoom 3,5x

Il modulo fotografico posteriore ha un design squadrato con tre obiettivi. La specifica più interessante riguarda l’ultra-grandangolare da 12mm di focale equivalente, una delle più ampie disponibili nella categoria — ideale per paesaggi, architettura e riprese in spazi ristretti. Il teleobiettivo offre invece uno zoom ottico 3,5x con stabilizzazione ottica (OIS).

Almeno uno dei sensori è prodotto da Sony (serie Lytia), una garanzia di qualità nella cattura dell’immagine grezza, specialmente in condizioni di scarsa illuminazione.

Design curato con più varianti di materiali

Motorola punterà su diversi materiali e colorazioni per differenziare le versioni. Il modello blu avrà una finitura tessuta anti-scivolo, mentre la variante marrone presenterà un effetto legno. Una scelta estetica originale che fa pensare a un prodotto con una certa attenzione al design.

Batteria da 6500mAh e ricarica da 90W

L’autonomia dovrebbe essere un punto di forza: il Motorola Edge 70 Pro è atteso con una batteria da 6500mAh, con ricarica rapida fino a 90W. Un’accoppiata che promette giornate di utilizzo intensivo senza preoccupazioni. Gli altri dettagli tecnici — processore, schermo, prezzo — saranno svelati al momento della presentazione ufficiale, attesa nelle prossime settimane.

Uno degli eterni difetti degli smartphone — la scarsa reattività del touchscreen quando le mani o lo schermo sono bagnati — potrebbe trovare una risposta concreta con l’OPPO A6s Pro, annunciato ufficialmente per il 14 aprile 2026. Il protagonista è una nuova tecnologia chiamata Super Rain Touch.

Super Rain Touch: cosa può fare

La tecnologia Super Rain Touch promette di rendere il display pienamente funzionante anche in condizioni di pioggia intensa. OPPO afferma che il sistema è stato progettato per resistere persino al livello “Red Rain” della scala meteo cinese, ovvero precipitazioni equivalenti a un monsone. In pratica, secondo il produttore, si può tranquillamente rispondere ai messaggi anche con lo smartphone bagnato sotto un nubifragio.

IP69K e robustezza per uso outdoor

La resistenza all’acqua è certificata IP69K, il massimo grado di protezione disponibile. Il dispositivo è progettato anche per resistere alle cadute accidentali, incluse quelle in pozze d’acqua. Una proposta chiaramente orientata a chi usa lo smartphone in ambienti difficili o all’aperto.

Specifiche tecniche del dispositivo

L’OPPO A6s Pro è un mid-range con display da 6,57 pollici Full HD e chip MediaTek Dimensity 6300. La fotocamera principale è da 50MP affiancata da un sensore da 2MP, mentre il selfie è da 16MP. Il punto forte lato batteria è la capacità da 7000mAh, con uno spessore di soli 8,3mm e un peso di 193g: numeri davvero notevoli per una batteria di questo taglio.

Il prezzo non è ancora stato comunicato, ma la fascia media è quella di riferimento. Se la tecnologia Super Rain Touch funziona davvero come promesso, questo OPPO potrebbe diventare la scelta di riferimento per chi vive in zone piovose o pratica sport all’aperto.

Lo Xiaomi 18 Pro non è ancora stato annunciato ufficialmente — la presentazione è attesa per settembre 2026 — ma il celebre leaker Digital Chat Station ha già condiviso alcune informazioni sul prossimo flagship di casa Xiaomi. Le aspettative sono altissime.

Batteria oltre i 7000mAh con ricarica da 100W

Il dato più sorprendente riguarda la batteria: lo Xiaomi 18 Pro monterà un accumulatore con capacità che inizia per “7”, e secondo le indiscrezioni supererà i 7000mAh. Abbinato alla ricarica rapida cablata da 100W e al supporto wireless, si prospetta uno smartphone capace di garantire un’autonomia eccellente senza rinunciare alla comodità della ricarica veloce.

Snapdragon 8 Elite Gen 6 a processo 2nm

Sotto la scocca batte il nuovo Snapdragon 8 Elite Gen 6, prodotto a 2nm — un salto generazionale rispetto ai chip attuali, con benefici attesi in termini di performance, efficienza energetica e capacità di elaborazione AI. Il chip dovrebbe essere presentato da Qualcomm intorno a settembre, rendendo lo Xiaomi 18 Pro uno dei primissimi smartphone ad adottarlo.

Doppia fotocamera da 200MP e display posteriore

Sul fronte fotografico, lo Xiaomi 18 Pro punterebbe su una configurazione con due sensori da 200 megapixel, più un obiettivo macro-teleobiettivo. Una configurazione ambiziosa che punta a coprire ogni scenario di scatto. Confermato anche il display posteriore, funzionalità già presente sui modelli precedenti, questa volta con funzioni ampliate rispetto al passato.

Il display principale frontale dovrebbe mantenersi intorno ai 6,4 pollici, in linea con la serie Xiaomi 18 standard. Mancano ancora molti mesi alla presentazione ufficiale, ma le premesse sono decisamente intriganti per chi cerca un top di gamma Android senza compromessi.

Xiaomi ha confermato la data di lancio del REDMI K90 Max: il 21 aprile 2026 alle 19:00 (ora cinese). Si tratta di uno smartphone pensato interamente per il gaming mobile competitivo, con specifiche che mettono al centro la velocità di risposta del touchscreen e le prestazioni grafiche.

Touchscreen da 3500Hz: che cosa significa davvero

La specifica più impressionante del REDMI K90 Max è il sampling rate istantaneo del display: 3500Hz. In pratica, il pannello campiona la posizione delle dita a una frequenza estrema, riducendo al minimo la latenza percepita tra il tocco e la risposta su schermo. Per il gaming competitivo — soprattutto in titoli FPS o di combattimento — si traduce in un vantaggio reale. Il sampling rate continuo è di 480Hz, già superiore alla quasi totalità degli smartphone sul mercato.

Incluso anche un giroscopio a 6 assi che opera a 400Hz, per rilevare i movimenti fisici dello smartphone con altissima precisione — essenziale per i giochi che usano la mira giroscopica. Il pannello ha superato test di 1 milione di tocchi consecutivi per la durabilità.

Display da 6,83 pollici a 165Hz e raffreddamento attivo

Lo schermo da 6,83 pollici supporta un refresh rate di 165Hz e raggiunge una luminosità di picco di 3500 nit. Ottimo per l’utilizzo in esterni e per percepire ogni frame durante il gioco.

Una delle caratteristiche più peculiari è la presenza di una ventola di raffreddamento interna: una soluzione rara nel mondo Android, che punta a gestire il calore generato durante le sessioni di gioco prolungate. Il sistema utilizza un condotto d’aria sigillato e una struttura metallica per dissipare il calore in modo efficiente, con garanzia di 6 anni.

Protezione IP66/68/69 inclusa

Sorprendentemente per un gaming phone, il REDMI K90 Max vanta anche la certificazione IP66, IP68 e IP69: resistenza alla polvere e all’acqua a più livelli. Il 21 aprile conosceremo processore, prezzo e gli altri dettagli rimasti in sospeso.

Il mercato globale degli smartphone ha registrato un calo del 6% nel primo trimestre del 2026, ma non tutti i produttori soffrono allo stesso modo. Google Pixel brilla in controtendenza con una crescita del 14%, confermando che la strategia fondata sull’intelligenza artificiale e sull’esperienza software sta pagando.

Il mercato globale frena: Samsung e Xiaomi perdono terreno

Secondo i dati di Counterpoint Research per il Q1 2026, il panorama non è incoraggiante. Apple mantiene la leadership con il 21% di market share e addirittura cresce del 5% grazie all’ottima performance della serie iPhone 17. Samsung resta seconda ma perde il 6% delle spedizioni, complice un lieve ritardo nel lancio della linea Galaxy S26. Xiaomi, terza nel ranking globale con il 12% di quota, subisce un calo ben più pesante: -19% rispetto allo stesso periodo dell’anno precedente.

Google Pixel e Nothing: le eccezioni positive

In questo scenario difficile, Google Pixel si distingue nettamente. Un +14% annuo dimostra che la proposta di valore del Pixel — fotografia computazionale, aggiornamenti tempestivi e funzionalità AI integrate — trova un pubblico in crescita. Non si tratta di numeri assoluti paragonabili ai colossi, ma la direzione è chiara.

Ancora più sorprendente la performance di Nothing, che registra addirittura un +25%. Il brand britannico punta su design originale, comunicazione diretta e un’identità forte, e i risultati sembrano premiarlo. I nuovi modelli lanciati di recente stanno aiutando a espandere la base utenti.

Cosa ci dice questo mercato

La lezione che emerge da questi dati è abbastanza netta: vincono i produttori che offrono qualcosa di distintivo. Non basta più un buono hardware; servono software di qualità, aggiornamenti costanti e funzionalità AI che migliorino concretamente la vita dell’utente. Google Pixel è forse il miglior esempio di questa formula. Le previsioni per il resto del 2026 restano conservative, con pressioni sul mercato che potrebbero durare almeno fino al 2027, ma chi ha una strategia software solida sembra poter navigare meglio la tempesta.

Il prossimo pieghevole di Motorola si avvicina. Il Razr 70 Ultra è stato al centro di diversi leak che ne hanno svelato le specifiche principali: un aggiornamento mirato, più che una rivoluzione, che punta sull’autonomia come principale novità.

La novità principale: batteria da 5000mAh

Il punto di forza del Razr 70 Ultra rispetto al predecessore è un incremento della batteria di circa il 6%, portando la capacità a 5000mAh. Per uno smartphone pieghevole — categoria storicamente penalizzata dall’autonomia a causa degli spazi ridotti — si tratta di un risultato notevole. La ricarica rapida via cavo rimane a 68W.

Specifiche tecniche: continuità con il modello precedente

Per il resto, il Razr 70 Ultra non si discosta molto dal modello attuale. Il processore resta lo Snapdragon 8 Elite, con 16GB di RAM e 512GB di storage. Le dimensioni da aperto sono circa 171,5×74,0×7,2mm per un peso di 199g.

Il display è ancora il punto di forza: cover display da circa 4 pollici e schermo interno da circa 7 pollici, con risoluzioni 1080×1272 e 2992×1224 rispettivamente. Il comparto fotografico mantiene la configurazione triple 50MP (principale, ultragrandangolare e selfie).

Presentazione attesa ad aprile, disponibile come “Razr Ultra 2026” in USA

Motorola punta tipicamente ad aprile per il lancio della serie Razr, e quest’anno non dovrebbe fare eccezione. Negli Stati Uniti, il modello sarà commercializzato con il nome Razr Ultra 2026. Chi cercava un restyling radicale rimarrà forse deluso, ma chi vuole un pieghevole affidabile con buona autonomia troverà nel Razr 70 Ultra una proposta solida.

Se Sony decidesse di ridurre la gamma Xperia a una sola serie, quale vorreste mantenere? Un sondaggio condotto da una testata giapponese ha posto questa domanda ai lettori, raccogliendo 206 risposte. Il risultato è interessante — e in parte sorprendente.

La situazione attuale di Xperia

Negli ultimi anni Sony ha ridotto progressivamente la sua gamma di smartphone. La serie Xperia 5 è stata di fatto interrotta, l’Xperia Ace non riceve nuovi modelli da anni, e oggi la lineup si concentra su due linee: l’Xperia 1 (flagship) e l’Xperia 10 (fascia media). Un assestamento comprensibile dal punto di vista aziendale, ma non necessariamente allineato ai desideri degli utenti.

I risultati del sondaggio

Ecco come si sono distribuite le preferenze tra i partecipanti al sondaggio:

• Xperia 1 Series: 48,1%
• Xperia 5 Series: 38,3%
• Xperia 10 Series: 8,7%
• Xperia Ace Series: 4,9%

L’Xperia 5 è ancora nel cuore degli utenti

Il risultato più interessante non è la vittoria dell’Xperia 1 — abbastanza prevedibile per un flagship — ma il 38,3% raccolto dall’Xperia 5, una serie che non esiste più. Quasi quattro utenti su dieci vorrebbero vederla tornare.

L’Xperia 5 rappresentava una formula rara sul mercato: prestazioni top in un formato compatto. In un’epoca in cui gli smartphone diventano sempre più grandi, quella combinazione è oggi praticamente assente. Il dato del sondaggio suggerisce che la domanda esiste ancora, e che Sony avrebbe potenzialmente un mercato da servire — se solo volesse coglierlo.

Vale la pena notare, infine, che l’Xperia 10 — la serie attualmente in commercio — riceve solo l’8,7% delle preferenze, meno di una serie non più prodotta da anni. Un messaggio chiaro agli occhi di chi legge questi numeri.

I possessori di Samsung Galaxy Watch stanno segnalando un problema sempre più diffuso: il consumo anomalo della batteria. Dalle ultime settimane, molti utenti riferiscono un calo drastico dell’autonomia, e i dati puntano verso un’unica causa: i Google Play Services.

Batteria dimezzata dopo un aggiornamento

La maggior parte delle segnalazioni indica che il problema si è presentato improvvisamente, spesso dopo un recente aggiornamento. Gli screenshot condivisi sulle community online mostrano chiaramente i Google Play Services come principale responsabile del consumo energetico, con picchi del tutto anomali rispetto al normale utilizzo.

In molti casi, orologi che in precedenza duravano diversi giorni con una singola carica ora non riescono ad arrivare nemmeno a metà dell’autonomia abituale. Un impatto concreto e tangibile sull’esperienza d’uso quotidiana.

Il problema colpisce più modelli

Non si tratta di un difetto isolato su un modello specifico: le segnalazioni riguardano diverse generazioni di Galaxy Watch. Alcuni utenti che possiedono più smartwatch Samsung confermano di aver riscontrato lo stesso problema su tutti i modelli, indipendentemente dalla versione del software.

Curioso anche il fatto che alcuni utenti abbiano riportato il problema senza aver installato alcun aggiornamento manuale, il che suggerisce che potrebbe essere coinvolto un aggiornamento silenzioso lato server o un’app aggiornata automaticamente in background.

Possibili soluzioni temporanee

Nella community si stanno diffondendo alcune possibili contromisure, come la pulizia della cache dei Google Play Services o il riavvio forzato dello smartwatch. In alcuni casi, il ripristino alle impostazioni di fabbrica ha risolto temporaneamente il problema, ma non sembra una soluzione definitiva valida per tutti.

Samsung non ha ancora rilasciato comunicati ufficiali sulla questione. Gli utenti attendono un aggiornamento che risolva il problema alla radice, considerando quanto sia fastidioso un malfunzionamento della batteria su un dispositivo che si indossa ogni giorno.

Lenovo ha ufficialmente annunciato il ritorno del brand Legion Phone nel mondo degli smartphone Android. Dopo quasi tre anni di assenza dal mercato, il marchio gaming di Lenovo è pronto a tornare con una nuova visione: trasformare lo smartphone da semplice strumento di intrattenimento a vera piattaforma AI per il gaming mobile.

Un addio e un ritorno inaspettato

Lenovo aveva lasciato il mercato degli smartphone gaming nel 2022, dopo il lancio della serie Legion Y70. Nel 2023, un portavoce della società aveva confermato ufficialmente la chiusura di questo segmento. Eppure, a sorpresa, il brand è tornato sui propri passi: un account ufficiale su WeChat ha annunciato il ritorno del Legion Phone con un nuovo modello chiamato Legion Phone Y70 Next Generation.

Intelligenza artificiale al centro del progetto

Il nuovo Legion Phone non vuole essere semplicemente uno smartphone potente. Lenovo lo posiziona come un dispositivo pensato per l'”era dell’AI”, capace di ottimizzare in tempo reale le prestazioni durante il gaming, gestire le impostazioni di gioco e garantire un’esperienza fluida grazie all’integrazione con l’ecosistema Legion.

Il design del nuovo modello è già trapelato online: le immagini mostrano uno smartphone con il logo Legion ben visibile sul pannello posteriore, con un’estetica chiaramente orientata al gaming. I dettagli tecnici completi saranno svelati in occasione della presentazione ufficiale.

Presentazione prevista a maggio 2026

L’annuncio ufficiale del Legion Phone Y70 Next Generation è atteso per maggio 2026. Il mercato degli smartphone gaming si è ridimensionato rispetto al picco degli anni precedenti, con pochi grandi player rimasti attivi. Il ritorno di Lenovo potrebbe riscaldare un settore che sembrava in declino, soprattutto se la proposta AI si rivelerà concreta e non solo marketing.

Il prossimo flagship di Sony si avvicina. Un dispositivo identificato come probabile Xperia 1 VIII ha superato la certificazione FCC negli Stati Uniti, con settimane di anticipo rispetto alla tempistica del modello precedente. Un segnale chiaro che la presentazione potrebbe avvenire prima del solito.

Il codice FCC conferma le origini Sony

Il dispositivo è stato registrato con l’ID FCC “PY7-30515Z”. Il prefisso PY7 è storicamente associato agli smartphone Sony, rendendo quasi certa l’attribuzione al brand giapponese. Le informazioni pubblicamente disponibili nella certificazione offrono qualche indizio sulle specifiche tecniche del nuovo modello.

Wi-Fi 7 e FeliCa: caratteristiche confermate

Tra le specifiche emerse dall’FCC, spicca il supporto al Wi-Fi 7, la connettività wireless di ultima generazione, che conferma la natura flagship del dispositivo. È stata confermata anche la presenza della tecnologia FeliCa (NFC per pagamenti contactless tipico del mercato giapponese), il che suggerisce si tratti di un modello destinato principalmente al Giappone, eventualmente importabile.

Il jack per le cuffie da 3,5mm sembra confermato anche questa volta, una caratteristica distintiva della linea Xperia che molti utenti apprezzano. Le bande LTE supportate risultano limitate, un pattern tipico dei modelli giapponesi certificati per utilizzo in roaming negli USA.

Camera rinnovata e possibile lancio anticipato

Le immagini delle cover già circolate in rete mostrano un modulo fotocamera posteriore riprogettato. Secondo le indiscrezioni, il cambiamento sarebbe dovuto a un sensore zoom di dimensioni maggiorate, con un impatto concreto sulle prestazioni fotografiche e non solo sull’estetica.

L’anno scorso, l’Xperia 1 VII ottenne la certificazione FCC a fine aprile, mentre la presentazione avvenne a maggio. Stavolta la certificazione è arrivata ad aprile già nelle prime settimane: se il pattern si ripete, il lancio dell’Xperia 1 VIII potrebbe anticipare di 1-2 settimane rispetto al 2025.

Si parla di:
Toggle

• La notte del 28 Febbraio: quando la guerra digitale diventa fisica
• APT35 e la dottrina della Pre-Posizione
• Il modello di conflitto a tre fasi
• L’ecosistema APT iraniano: non solo APT35
• Infrastruttura di attacco: offuscamento multi-livello
• Vulnerabilità sfruttate: un catalogo di CVE note
• Il significato strategico: un nuovo standard di conflitto ibrido
• Indicazioni per i difensori

Prima che i missili iraniani illuminassero il cielo di sette nazioni, un’altra guerra era già in corso nelle reti digitali di quei paesi. L’analisi della campagna condotta da APT35 rivela come il gruppo legato all’IRGC avesse sistematicamente compromesso le infrastrutture critiche di ogni paese successivamente colpito dall’Operazione Epic Fury, trasformando la cyber intelligence in un componente integrale della dottrina militare iraniana.

La notte del 28 Febbraio: quando la guerra digitale diventa fisica

Il 28 febbraio 2026, Stati Uniti e Israele hanno lanciato l’Operazione Epic Fury (denominata “Operazione Roaring Lion” dalla parte israeliana): oltre 1.250 obiettivi colpiti nelle prime 48 ore, infrastrutture nucleari iraniane distrutte, connettività internet dell’Iran ridotta all’1-4% dei livelli normali in quello che è stato definito il più grande cyberattacco della storia. Ma ciò che i rapporti di intelligence successivi hanno rivelato è ancora più preoccupante: l’Iran non si trovava impreparato. Per mesi, forse anni, i suoi gruppi APT affiliati all’IRGC e al MOIS avevano già mappato, compromesso e pre-posizionato capacità offensive nelle reti digitali di ogni paese che avrebbe poi colpito.

APT35 e la dottrina della Pre-Posizione

APT35 — conosciuto anche come Charming Kitten, Phosphorus, Magic Hound e Mint Sandstorm — è il gruppo cyber più rappresentativo dell’IRGC Intelligence Organisation (Unit 1500, Department 40), attivo almeno dal 2014. La sua caratteristica distintiva non è la sofisticazione tecnica delle singole operazioni, ma la pazienza strategica: operazioni di ricognizione prolungate, accesso silenzioso mantenuto per mesi o anni prima di un’attivazione.

Secondo le analisi di CloudSek e dei ricercatori di IT Nerd, APT35 aveva documentabilmente compromesso infrastrutture nei seguenti paesi prima dei bombardamenti:

• Giordania: accesso ai dati dell’aviazione civile e al Ministero della Giustizia
• Emirati Arabi Uniti: sistemi di aviazione e asset governativi a Dubai
• Arabia Saudita: documenti governativi e infrastrutture energetiche; il malware Shamoon ha distrutto circa 15.000 workstation nel settore energetico saudita prima delle operazioni cinetiche
• Kuwait, Bahrain, Qatar: attività di ricognizione e targeting operativo
• Israele: sistemi industriali e infrastrutture civili

Il modello di conflitto a tre fasi

L’analisi degli eventi suggerisce un modello di conflitto ibrido strutturato in tre fasi sequenziali, ormai consolidato nella dottrina iraniana:

• Fase 1 — Ricognizione estesa e silenziosa: compromissione di sistemi internet-facing (Exchange Server, VPN, Fortinet FortiOS), installazione di webshell, tunneling nascosto, raccolta di intelligence su reti, persone e infrastrutture critiche
• Fase 2 — Degradazione pre-cinetica: attivazione di malware wiper (come Shamoon) per distruggere workstation, esfiltrazione di documenti strategici, interruzione di servizi prima degli attacchi fisici
• Fase 3 — Coordinamento post-attacco: entro 24 ore dall’avvio delle operazioni militari, creazione di un “Electronic Operations Room” che ha coordinato oltre 60 gruppi hacktivist per colpire contemporaneamente infrastrutture governative, finanziarie e critiche

L’ecosistema APT iraniano: non solo APT35

APT35 non ha operato in isolamento. Il Tenable Research ha identificato 12 gruppi APT iraniani attivi nelle settimane e mesi precedenti l’Operazione Epic Fury, coordinati attraverso strutture parallele:

Gruppi IRGC-affiliati: Pioneer Kitten (Fox Kitten, UNC757), Imperial Kitten (Tortoiseshell, TA456), CyberAv3ngers — quest’ultimo specializzato nel targeting di sistemi OT e PLC nei sistemi idrici. Gruppi MOIS-affiliati: APT34/OilRig (nuova infrastruttura per attacchi ed esfiltrazione), MuddyWater/Mango Sandstorm (picco di attività nella rete nel settembre 2025, con server distribuiti in Russia, Estonia e UK), Banished Kitten/Void Manticore (usa la persona Handala, wiper-focused). Gruppi IRGC-IO: APT42 (credential harvesting tramite social engineering). Gruppi IRGC-CEC: Cotton Sandstorm (revival della persona Altoufan Team).

Infrastruttura di attacco: offuscamento multi-livello

Particolarmente sofisticata è stata l’architettura di infrastruttura impiegata per mascherare l’attribuzione. Netcrook ha documentato uno schema di offuscamento a tre livelli:

• Livello base: ISP iraniani (Sefroyek Pardaz Engineering) come punto di origine
• Bulletproof hosting: ALEXHOST in Moldova e RouterHosting LLC nel Wyoming (USA) come nodi intermedi
• Shell company layer: società fittizie come Cloudblast (registrata negli USA, operativa a Dubai) e UltaHost (registrazioni UK/USA) per la gestione dell’infrastruttura front-end

Questa architettura ha reso estremamente complessa l’attribuzione rapida e le azioni legali di takedown durante le operazioni.

Vulnerabilità sfruttate: un catalogo di CVE note

Il documento Tenable elenca 67 CVE sfruttate dai gruppi iraniani, incluse vulnerabilità ben note mai patchate da molte organizzazioni. Tra le più critiche:

# CVE sfruttate dai gruppi APT iraniani (selezione)
CVE-2021-26855  # Microsoft Exchange Server - ProxyLogon SSRF
CVE-2021-26858  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-26857  # Microsoft Exchange - insecure deserialization
CVE-2021-27065  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-44228  # Apache Log4j2 - Log4Shell RCE
CVE-2022-40684  # Fortinet FortiOS/FortiProxy - authentication bypass
CVE-2020-3153   # Cisco ASA - path traversal
# Malware famiglie associate
BellaCiao        # RAT/implant IRGC (codice sorgente esposto in leak)
Sagheb RAT       # Remote Access Trojan IRGC
Shamoon          # Wiper distruttivo (energia, Arabia Saudita)
# Malware ICS/OT
Custom PLC malware targeting Rockwell Automation (CyberAv3ngers)

Il significato strategico: un nuovo standard di conflitto ibrido

La vicenda dell’Operazione Epic Fury e della sua dimensione cyber non è semplicemente la cronaca di un conflitto mediorientale. È la dimostrazione concreta di come le operazioni cyber siano diventate componenti integrali — non accessorie — della dottrina militare degli stati autoritari. Il pre-posizionamento di APT35 nelle reti dei paesi bersaglio anni prima delle operazioni fisiche stabilisce un precedente: in futuri conflitti, qualsiasi attore statale disporrà presumibilmente di “porte di accesso” già aperte nelle infrastrutture avversarie.

Per i difensori occidentali, la lezione è chiara: la minaccia non inizia il giorno in cui i missili vengono lanciati. Inizia quando un webshell silenzioso viene installato su un server Exchange non patchato da sei mesi.

Indicazioni per i difensori

• Patch immediata dei sistemi internet-facing: Exchange, FortiOS, Cisco ASA, Log4j sono ancora vettori attivi
• Audit degli accessi amministrativi: verificare account privilegiati, in particolare su sistemi OT/ICS
• Webshell hunting: scansione proattiva per webshell su server web esposti, soprattutto su CMS e sistemi legacy
• Validazione della copertura di detection: testare le soluzioni EDR/XDR contro BellaCiao, Sagheb RAT e le tecniche di tunneling documentate
• Monitoraggio per nuova infrastruttura hacktivist: i gruppi come Handala e CyberAv3ngers si riorganizzano rapidamente dopo le operazioni

Nei sistemi distribuiti, la gestione di processi di business che si estendono su più servizi e nel tempo rappresenta una delle sfide più complesse. Il Pattern Saga nasce proprio per risolvere questo problema: coordinare una sequenza di operazioni distribuite in modo affidabile, garantendo la consistenza dei dati anche in caso di errori parziali.

In questo articolo esploriamo come implementare il Pattern Saga in .NET utilizzando Wolverine, un framework moderno che semplifica notevolmente la gestione di messaggi e workflow complessi grazie al suo approccio convention-driven.

Cos’è il Pattern Saga?

Il Pattern Saga è un meccanismo di gestione delle transazioni distribuite che sostituisce le transazioni ACID tradizionali nei sistemi a microservizi. Invece di eseguire una sequenza di operazioni come un’unica transazione atomica, la saga suddivide il processo in una serie di passi indipendenti, ciascuno con la propria logica di compensazione in caso di fallimento.

Il principio fondamentale è semplice: se un passo fallisce o va in timeout, la saga esegue la logica di compensazione invece di lasciare il sistema in uno stato inconsistente. Questo approccio è particolarmente utile per processi di lunga durata come:

• Onboarding di nuovi utenti con email di verifica
• Processi di ordine e pagamento in e-commerce
• Workflow di approvazione multi-step
• Processi di provisioning di risorse cloud

Perché Wolverine?

Wolverine è un framework per .NET che adotta un approccio convention-driven alla messaggistica e ai workflow. A differenza di soluzioni come MassTransit o Rebus, Wolverine gestisce automaticamente routing dei messaggi, persistenza dello stato e correlazione, senza richiedere un’estesa configurazione tramite DSL per state machine.

Le principali dipendenze per iniziare sono:

WolverineFx (5.16.2)
WolverineFx.Postgresql (5.16.2)
WolverineFx.RabbitMQ (5.16.2)

Configurazione del progetto

La configurazione di Wolverine richiede pochi passaggi. Nell’entry point dell’applicazione, si configura il framework per utilizzare RabbitMQ come message broker e PostgreSQL per la persistenza dello stato:

builder.Host.UseWolverine(options =>
{
    options.UseRabbitMqUsingNamedConnection("rmq")
        .AutoProvision()
        .UseConventionalRouting();

    options.Policies.DisableConventionalLocalRouting();
    options.PersistMessagesWithPostgresql(connectionString!);
});

• AutoProvision(): crea automaticamente exchange e code in RabbitMQ
• UseConventionalRouting(): instrada i messaggi in base ai nomi dei tipi
• DisableConventionalLocalRouting(): forza tutti i messaggi attraverso RabbitMQ
• PersistMessagesWithPostgresql(): archivia stato della saga e messaggi; crea una tabella per saga con serializzazione JSON

Definizione dei messaggi

Ogni passo della saga è rappresentato da un messaggio. Definiamo tutti i tipi di messaggio per un processo di onboarding utente:

public record SendVerificationEmail(Guid UserId, string Email);
public record VerificationEmailSent(Guid Id);
public record VerifyUserEmail(Guid Id);
public record SendWelcomeEmail(Guid UserId, string Email, string FirstName);
public record WelcomeEmailSent(Guid Id);
public record OnboardingTimedOut(Guid Id) : TimeoutMessage(5.Minutes());

Implementazione della classe Saga

La saga viene implementata come una classe che estende Saga. Lo stato viene mantenuto come proprietà della classe:

public class UserOnboardingSaga : Saga
{
    public Guid Id { get; set; }
    public string Email { get; set; } = string.Empty;
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public bool IsVerificationEmailSent { get; set; }
    public bool IsEmailVerified { get; set; }
    public bool IsWelcomeEmailSent { get; set; }
}

Il metodo Start: avvio della saga

Il metodo statico Start è il factory method che inizia la saga. Restituisce una tupla contenente l’istanza della saga, il comando iniziale e il messaggio di timeout pianificato:

public static (
    UserOnboardingSaga,
    SendVerificationEmail,
    OnboardingTimedOut) Start(
        UserRegistered @event,
        ILogger<UserOnboardingSaga> logger)
{
    var saga = new UserOnboardingSaga
    {
        Id = @event.Id,
        Email = @event.Email,
        FirstName = @event.FirstName,
        LastName = @event.LastName,
    };

    return (
        saga,
        new SendVerificationEmail(saga.Id, saga.Email),
        new OnboardingTimedOut(saga.Id));
}

Metodi Handle: gestione degli eventi

I metodi Handle elaborano i messaggi in arrivo. Se restituiscono void, aggiornano solo lo stato; se restituiscono un messaggio, causano l’invio del passo successivo:

public void Handle(VerificationEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email di verifica inviata per l'utente {UserId}", Id);
    IsVerificationEmailSent = true;
}

public SendWelcomeEmail Handle(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email verificata per l'utente {UserId}", Id);
    IsEmailVerified = true;
    return new SendWelcomeEmail(Id, Email, FirstName);
}

public void Handle(WelcomeEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Onboarding completato per l'utente {UserId}", Id);
    IsWelcomeEmailSent = true;
    MarkCompleted(); // Elimina lo stato dal database
}

Gestione del timeout e compensazione

Il timeout è un cittadino di prima classe in Wolverine. Se l’utente non verifica l’email entro 5 minuti, il handler del timeout gestisce la compensazione:

public void Handle(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    if (IsEmailVerified)
    {
        logger.LogInformation(
            "Timeout ignorato - email già verificata per {UserId}", Id);
        return;
    }

    logger.LogWarning(
        "Onboarding scaduto per {UserId} - email non verificata", Id);
    MarkCompleted();
}

Gestione dei messaggi “orfani” con NotFound

Wolverine richiede la gestione esplicita del caso in cui arrivi un messaggio per una saga già terminata, tramite metodi statici NotFound:

public static void NotFound(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogWarning("VerifyEmail ricevuto ma la saga {Id} non esiste più", command.Id);
}

public static void NotFound(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Timeout per la saga già completata {Id}", timeout.Id);
}

Correlazione dei messaggi e gestione della concorrenza

Wolverine correla automaticamente i messaggi alle istanze della saga cercando nell’ordine: attributo [SagaIdentity], proprietà {SagaTypeName}Id, oppure proprietà Id. Non è necessaria alcuna configurazione esplicita per i casi standard.

Per la concorrenza, Wolverine applica di default il controllo di concorrenza ottimistico: quando più messaggi per la stessa saga arrivano contemporaneamente, uno riesce mentre gli altri vengono ritentati automaticamente. Attenzione: non invocare IMessageBus.InvokeAsync() all’interno dei handler della stessa saga, ma usare sempre i messaggi in cascata (valori di ritorno) per evitare problemi con dati obsoleti.

Opzioni di persistenza

Wolverine supporta tre strategie per la persistenza dello stato della saga:

• Lightweight Storage: serializza lo stato come JSON in tabelle dedicate per saga, zero configurazione ORM
• Marten: archivia le saghe come documenti con concorrenza ottimistica e ID fortemente tipizzati
• Entity Framework Core: mappa le saghe su tabelle queryabili, abilitando commit in singola transazione con altri dati

Il flusso completo

Il percorso “happy path” dell’onboarding segue questi passi:

1. L’evento UserRegistered attiva il metodo Start()
2. Viene creata l’istanza della saga, inviato SendVerificationEmail e pianificato OnboardingTimedOut
3. VerificationEmailSent aggiorna lo stato della saga
4. VerifyUserEmail ricevuto, viene inviato in cascata SendWelcomeEmail
5. WelcomeEmailSent completa il workflow, la saga viene eliminata

Se VerifyUserEmail non arriva entro 5 minuti, OnboardingTimedOut gestisce la compensazione e termina la saga.

Conclusione

Wolverine offre un approccio sorprendentemente pulito all’implementazione del Pattern Saga in .NET. La scelta convention-driven elimina gran parte del boilerplate tipico di altri framework, consentendo di concentrarsi sulla logica di business. La gestione automatica di persistenza, routing e correlazione dei messaggi, unita al supporto nativo per timeout e compensazione, lo rende una scelta solida per workflow distribuiti complessi.

Per i team che lavorano con architetture a microservizi in .NET, Wolverine merita certamente una valutazione approfondita come alternativa moderna ai pattern tradizionali di orchestrazione.

Fonte originale: Implementing the Saga Pattern With Wolverine — Milan Jovanović

Nascosta nei termini di servizio di Microsoft per Copilot c’è una frase (sottolineata per giunta in grassetto) che farebbe sorridere un avvocato ma anche impallidire molti utilizzatori: “Copilot è solo per intrattenimento“. La clausola completa avverte che lo strumento può fare errori, potrebbe non funzionare come previsto e che gli utenti non dovrebbero affidarsi a...

🔗 Leggi il post completo

Trasformazioni Le Trasformazioni sono delle specie di filtri, nel senso che sono operazioni fatte sui pixel di un’immagine. Abbiamo un’immagine regolare, trasformazioni su tutti i livelli nell’immagine e menu in alto sui livelli, in modo che tu possa ridimensionare, ribaltare e ruotare l’intera immagine. Esiste anche lo Strumento Ritaglio, che riguarda solo la dimensione della tela, e lo...

🔗 Leggi il post completo

Il kernel GNU Linux-libre è una versione del kernel Linux appositamente modificata per garantire la massima libertà del software a chi desidera utilizzare un sistema operativo completamente privo di componenti proprietari. L’obiettivo centrale è offrire un ambiente interamente libero, in cui...

🔗 Leggi il post completo

Nel mese di aprile 2026, i ricercatori di sicurezza hanno identificato un attacco di supply chain sofisticato ai danni di CPUID, l’azienda dietro i popolarissimi tool di monitoraggio hardware CPU-Z e HWMonitor. Gli attaccanti hanno compromesso i server dell’azienda e reindirizzato i download ufficiali verso versioni malware. Per il corso di sei ore, gli utenti che scaricavano CPU-Z e HWMonitor dai siti ufficiali ricevevano un Remote Access Trojan precedentemente non documentato denominato STX RAT.

Questo incidente exemplifica una tendenza crescente nel panorama delle minacce informatiche: gli attaccanti hanno capito che il modo più efficace per ottenere una penetrazione di massa non è attaccare i singoli utenti, ma compromettere i software publisher e i loro canali di distribuzione. Se il software che stai scaricando oggi da un sito ufficiale contiene malware, la fiducia nella sicurezza della catena di distribuzione software crolla completamente.

Anatomia dell’attacco: come gli attaccanti hanno compromesso CPUID

A differenza di molti attacchi di supply chain che richiedono il compromesso dei sistemi di build e signing di un’azienda, gli attaccanti dietro questo incidente hanno adottato un approccio più mirato. Invece di cercare di infettare i binari finali di CPU-Z o HWMonitor (che sono firmati digitalmente), gli attaccanti hanno compromesso un’API secondaria utilizzata da CPUID per servire i link di download sul proprio sito web.

Modificando questa API, gli attaccanti hanno reindirizzato le richieste degli utenti verso file malevoli ospitati su Cloudflare R2. Le vittime pensavano di scaricare il software legittimo direttamente dal sito CPUID, ma ricevevano invece il malware. Non è stata trovata alcuna evidenza che gli attaccanti abbiano compromesso il processo di compilazione, il sistema di signing dei binari, o i server di controllo della versione di CPUID.

Il malware: STX RAT e le sue capacità

STX RAT è stato nominato da eSentire per la sua caratteristica firma tecnica: l’utilizzo consistente del byte STX come magic byte per prefisso nei messaggi diretti al command-and-control (C2).

Capacità di infostealer

Browser e credenziali web:

• Estrazione di password, cookie, e dati di autofill da Firefox, SeaMonkey, e browser basati su Chromium (Chrome, Edge, Brave, ecc.)
• Bypass potenziale di Application-Bound Encryption (ABE) sulle credenziali crittografate di Windows

Portafogli di criptovalute:

• Furto di chiavi private da Litecoin-Qt, Electrum, e altri wallet desktop
• Accesso a file di configurazione che contengono seed phrase o wallet backup

Credenziali client FTP:

• Estrazione di dati di accesso da FileZilla, WinSCP, e altri client FTP

Remote Desktop nascosto (HVNC)

Una capacità particolarmente insidiosa di STX RAT è il supporto per hidden VNC (Virtual Network Computing). Questo permette all’attaccante di:

• Avviare una sessione desktop virtuale nascosta che non è visibile agli utenti locali
• Controllare il mouse e la tastiera tramite l’API SendInput di Windows
• Eseguire applicazioni e navigare nel filesystem senza alcun indicatore visibile all’utente locale
• Accedere ai dati sensibili mentre l’utente legittimo è offline

I comandi supportati includono “starthvnc”, “keypress”, “mouseinput”, “mousewheel”, e “switchdesktop”, fornendo una suite completa di controllo remoto.

Tattica di delivery: DLL Sideloading

Il vettore di consegna del malware utilizza una tecnica classica pero ancora efficace: DLL sideloading (also known as DLL hijacking). Quando un utente scaricava il file trojanizzato da HWMonitor, conteneva:

• HWMonitor_x64.exe – Un file con nome legittimo (il binario vero di HWMonitor)
• CRYPTBASE.dll – Una DLL malevola che l’eseguibile legittimo carica automaticamente

Poiché Windows segue un ordine di ricerca delle DLL specifico, quando HWMonitor_x64.exe cerca di caricare CRYPTBASE.dll, trova prima la versione malevola nella stessa directory. Questo causa l’esecuzione del codice dell’attaccante con gli stessi privilegi dell’applicazione legittima.

Indicatori tecnici e infrastruttura C2

C2 Server: 95.216.51.236
Malware: STX RAT
Compromesso: 9-10 aprile 2026
Download malevoli: CPU-Z, HWMonitor versioni x64 e x86
DLL sideload: CRYPTBASE.dll

Inoltre, eSentire ha documentato che STX RAT supporta il routing del traffico C2 attraverso Tor per garantire anonimato, rendendo la tracciatura della comunicazione estremamente difficile.

Impatto e distribuzione

Kaspersky ha identificato oltre 150 vittime dirette dell’incidente CPUID. La distribuzione geografica mostra una concentrazione in Brasile, Russia, e Cina, con settori colpiti che includono: retail e e-commerce, manufacturing, consulting, telecomunicazioni, e agricoltura.

Il fatto che utenti in settori critici siano stati infetti suggerisce che STX RAT potrebbe essere utilizzato sia per cyber-spionaggio che per estorsione, poiché il malware combina capacità di reconnaissance (infostealing) con accesso remoto completo (HVNC).

Timeline dell’incidente

• 9 aprile 2026, ~15:00 UTC: Gli attaccanti modificano l’API di CPUID, reindirizzando i download
• 10 aprile 2026, ~10:00 UTC: CPUID scopre l’anomalia e ripristina l’API
• 10 aprile 2026: eSentire pubblica analisi tecnica del malware
• 13 aprile 2026: Kaspersky fornisce dati sulla distribuzione geografica

Raccomandazioni per le organizzazioni

• Verifica dell’integrità: Implementare processi di verifica dell’hash per tutti i software scaricati, anche da fonti ufficiali.
• Sandboxing: Eseguire software appena scaricati in ambienti virtuali isolati prima dell’installazione.
• Monitoraggio DLL loading: Implementare EDR in grado di rilevare il caricamento inusuale di DLL.
• Blocco C2: Aggiungere 95.216.51.236 alle blocklists firewall immediate.
• Credential rotation: Ruotare credenziali per chi ha scaricato HWMonitor/CPU-Z tra 9-10 aprile.
• Threat intelligence: Adottare YARA rules da eSentire per rilevare STX RAT in memoria.

Conclusione

L’incidente CPUID dimostra che la sicurezza della catena di distribuzione software non è negoziabile. Anche i siti ufficiali di società legittime possono essere compromessi. I defender devono adottare un mindset di “zero trust” verso qualsiasi software e implementare verifiche multi-strato di integrità e autenticità prima dell’esecuzione.

Chiunque abbia lavorato con .NET Aspire su progetti reali si è prima o poi scontrato con il classico errore: “Port 17370 is already in use”. Capita quando si prova ad avviare una seconda istanza dell’AppHost — magari su un altro branch, o in un altro terminale — e le porte predefinite sono già occupate dalla prima istanza in esecuzione. Con Aspire 13.2, questo problema ha finalmente una soluzione elegante: la modalità isolata (--isolated).

In questo articolo vediamo nel dettaglio come funziona questa nuova funzionalità, i casi d’uso pratici, e le altre novità rilevanti di questa release.

Il problema: conflitti di porta nello sviluppo parallelo

In un tipico progetto .NET Aspire, l’AppHost configura i binding delle porte per tutti i servizi nell’orchestrazione: la dashboard su una porta, l’API su un’altra, il database su un’altra ancora. Questi binding sono statici per default, e questo crea problemi immediati quando si vuole eseguire due istanze dello stesso AppHost contemporaneamente:

• Sviluppo su due branch in parallelo con git worktrees
• Test di integrazione che richiedono un AppHost “live” mentre si continua a sviluppare
• Agenti AI che creano automaticamente worktree separati per task paralleli
• Pipeline CI/CD locali che eseguono più istanze dello stesso progetto

La soluzione tradizionale era modificare manualmente i port binding nella configurazione — un approccio fragile, soggetto a errori e difficile da gestire in team.

La soluzione: la flag --isolated

Aspire 13.2 introduce la flag --isolated che risolve il problema alla radice. L’utilizzo è semplicissimo:

aspire run --isolated
# oppure
aspire start --isolated

1. Randomizzazione automatica delle porte

Invece di usare le porte definite staticamente nell’AppHost, ogni istanza isolata riceve un range di porte casuali disponibili. Dove un run normale potrebbe bindare i servizi su 8080, 8081, 8082, due istanze isolate potrebbero usare rispettivamente:

• Istanza 1: 15234, 15235, 15236
• Istanza 2: 22891, 22892, 22893

La cosa notevole è che il codice dell’applicazione non necessita alcuna modifica: il service discovery di Aspire risolve gli endpoint dinamicamente a runtime, quindi i servizi si “trovano” a prescindere dalle porte assegnate.

2. Isolamento dei user secrets

La configurazione rimane completamente separata per ogni istanza. Connection string, chiavi API e altre variabili d’ambiente non si “contaminano” tra run diversi, anche quando puntano a risorse Azure o database con nomi diversi. Questo è particolarmente importante in scenari di test dove ogni istanza deve operare in modo completamente autonomo.

Casi d’uso pratici

Git worktrees multipli

Il caso d’uso più comune: sviluppo su due branch in parallelo.

# Terminale 1 - branch principale
cd ~/projects/myapp-main
aspire run --isolated

# Terminale 2 - feature branch
cd ~/projects/myapp-feature-xyz
aspire run --isolated

Test di integrazione con AppHost live

Un pattern molto utile: eseguire test di integrazione contro un AppHost “live” mentre si continua a sviluppare sull’AppHost principale.

# AppHost per sviluppo interattivo
aspire run --isolated

# In un altro terminale: avvia i test che usano il loro AppHost dedicato
dotnet test --isolated-apphost

Sviluppo agentico

Questo è il caso d’uso che ha spinto direttamente lo sviluppo di questa feature. Gli agenti AI in VS Code Copilot possono creare automaticamente git worktree separati per task paralleli. Con --isolated, ogni agente può avviare il proprio AppHost nella sua directory di lavoro senza conflitti con la sessione principale dello sviluppatore.

Aspire 13.2 include anche il comando aspire agent init (rinominato da aspire mcp init) che configura automaticamente gli agenti per usare --isolated con i worktree git.

Nuovi comandi CLI in Aspire 13.2

La modalità isolata non è l’unica novità della CLI. Aspire 13.2 introduce una serie di nuovi comandi operativi che rendono la gestione delle istanze molto più potente:

aspire ps — lista delle istanze attive

Elenca tutti gli AppHost Aspire in esecuzione sulla macchina, con le relative informazioni (porte, stato, ID istanza). Utile specialmente quando si hanno più istanze isolate attive contemporaneamente e si vuole sapere cosa sta girando.

aspire ps
# Output:
# ID           PROJECT          STATUS    DASHBOARD
# abc123       myapp-main       Running   http://localhost:15234
# def456       myapp-feature    Running   http://localhost:22891

aspire describe — dettagli sulle risorse

Accede ai dettagli di una risorsa specifica direttamente dal terminale, senza dover aprire la dashboard:

aspire describe api
# Mostra endpoint, variabili d'ambiente, stato health, ecc.

aspire doctor — diagnostica dell’ambiente

Esegue un controllo completo dell’ambiente di sviluppo: verifica che tutte le dipendenze siano installate correttamente (Docker, .NET SDK, ecc.) e segnala eventuali problemi di configurazione.

aspire wait — attesa su uno stato specifico

Blocca l’esecuzione in script di automazione finché una risorsa non raggiunge uno stato specifico. Utile in pipeline CI/CD o in script di startup:

aspire run --isolated &
aspire wait --resource api --state Running
# Ora l'API è sicuramente up, posso eseguire i test

aspire export — export di telemetria e dati

Cattura telemetria e dati delle risorse in formato JSON per analisi offline o per integrazione con altri strumenti.

TypeScript AppHost in preview

Una delle novità più interessanti di Aspire 13.2 è il supporto preview per scrivere l’AppHost in TypeScript. Fino ad ora, l’AppHost era necessariamente un progetto C#. Con questa release, è possibile usare TypeScript con una sintassi idiomatica:

import { createBuilder } from '@aspire/hosting';

const builder = await createBuilder();

// Aggiunge Redis come risorsa
const cache = await builder.addRedis("cache");

// Aggiunge un servizio Node.js con dipendenza da Redis
const api = await builder.addNpmApp("api", "../api")
    .withReference(cache);

await builder.build().run();

Questa funzionalità è ancora in preview e non è raccomandata per produzione, ma è un segnale chiaro della direzione che sta prendendo Aspire: abbracciare anche gli sviluppatori TypeScript/Node.js, non solo quelli .NET.

Miglioramenti alla dashboard

Export e import di telemetria

La dashboard introduce un dialog centralizzato “Manage logs and telemetry” che permette di:

• Esportare risorse e telemetria come JSON
• Esportare variabili d’ambiente come file .env
• Importare dati da sessioni precedenti

API HTTP per telemetria

Nuovo endpoint /api/telemetry sulla dashboard che permette query programmatiche dei dati di telemetria con supporto streaming NDJSON. Utile per integrare la telemetria di Aspire con strumenti di monitoring esterni o script di analisi.

Impostazione parametri dalla UI

È ora possibile impostare i parametri delle risorse direttamente dalla dashboard, con opzione di salvataggio nei user secrets. Questo elimina la necessità di modificare manualmente i file di configurazione per cambiare un parametro durante il debug.

Miglioramenti al visualizzatore GenAI

Chi usa Aspire con workload AI troverà utili i miglioramenti al GenAI visualizer: migliore gestione di schemi complessi, payload troncati, testo non-ASCII e navigazione tra definizioni di tool.

Altre novità rilevanti

Endpoint MCP per i servizi

È possibile dichiarare server Model Context Protocol (MCP) direttamente nell’AppHost con il nuovo metodo WithMcpServer():

var api = builder.AddProject<Projects.MyApi>("api")
    .WithMcpServer("/mcp");

Docker Compose publishing stabile

L’integrazione con Docker Compose passa da prerelease a stabile. È ora possibile generare un docker-compose.yaml completo direttamente dal modello di app Aspire con aspire publish --format docker-compose.

Azure Virtual Network

Nuovo pacchetto Aspire.Hosting.Azure.Network per la gestione di reti virtuali Azure:

var vnet = builder.AddAzureVirtualNetwork("vnet");
var subnet = vnet.AddSubnet("web", "10.0.1.0/24");
var natGateway = vnet.AddNatGateway("nat");


Breaking changes da tenere a mente

Se stai aggiornando un progetto Aspire esistente a 13.2, ci sono alcune breaking changes da considerare:

1. Variabili Service Discovery: usano ora lo schema endpoint invece del nome endpoint
2. File di configurazione: preferenza per aspire.config.json unificato (migrazione automatica al primo run)
3. Comandi risorse: resource-start → start, resource-stop → stop
4. Dashboard API: ora opt-in per dashboard standalone
5. Pacchetto AIFoundry: Aspire.Hosting.Azure.AIFoundry → Aspire.Hosting.Foundry
6. WithSecretBuildArg: rinominato in WithBuildSecret

Per aggiornare, usa:

aspire update --self   # aggiorna la CLI
aspire update          # aggiorna i pacchetti del progetto

Conclusione

Aspire 13.2 è una release sostanziosa che affronta problemi concreti del workflow di sviluppo. La modalità --isolated è probabilmente la novità più impattante per il day-to-day: risolve un pain point reale in modo elegante, senza richiedere modifiche al codice dell’applicazione.

L’aggiunta del TypeScript AppHost in preview è un segnale importante della direzione di Aspire verso un ecosistema più inclusivo, mentre i nuovi comandi CLI (ps, describe, doctor, wait) rendono Aspire molto più adatto a workflow di automazione e sviluppo agentico.

Chi lavora già con Aspire troverà questo aggiornamento decisamente consigliato. Chi non lo ha ancora provato, potrebbe essere il momento giusto per iniziare — soprattutto se lavora con architetture microservizi in .NET.

Fonti: Running Multiple Instances of an Aspire AppHost Without Port Conflicts · What’s new in Aspire 13.2