(in)sicurezza digitale

2026-08-06 19:38:30

Snowflake, l’hacker Connor Moucka si dichiara colpevole: il conto finale di 165 aziende violate e miliardi di record rubati

Connor Riley Moucka, 26 anni, di Kitchener (Ontario), si è dichiarato colpevole mercoledì 5 agosto 2026 davanti a un tribunale federale dello stato di Washington per frode informatica, frode telematica, furto di identità aggravato e cospirazione. È l’epilogo giudiziario di quella che resta una delle campagne di furto dati ed estorsione più estese mai orchestrate contro un singolo fornitore cloud: l’attacco del 2024 alla piattaforma Snowflake, che ha colpito almeno 165 aziende clienti e portato al furto di miliardi di record. Moucka rischia fino a 32 anni di carcere e sarà sentenziato il 27 ottobre.

Non una violazione di Snowflake, ma delle credenziali dei suoi clienti

Il dettaglio tecnico che ha reso il caso Snowflake un caso di scuola è che la piattaforma stessa non è mai stata compromessa. Mandiant, incaricata da Snowflake di condurre l’indagine forense, ha attribuito la campagna a un cluster tracciato come UNC5537 e ha confermato che gli attaccanti hanno sfruttato credenziali valide ma esposte da tempo — in alcuni casi risalenti al 2020 — raccolte tramite infostealer su macchine di dipendenti o partner delle aziende clienti. La mancanza sistemica di autenticazione a più fattori sugli account Snowflake ha fatto il resto, trasformando credenziali rubate anni prima in un accesso diretto ai data warehouse di centinaia di organizzazioni.

Secondo Mandiant, il gruppo dietro la campagna era basato in Nord America e collaborava con almeno un membro operante dalla Turchia — identificato in seguito in John Erin Binns, già legato all’hack di T-Mobile del 2021 e arrestato in Turchia nel 2024.

Le vittime: dalle telco alla sanità, passando per la vendita di biglietti

L’elenco delle aziende colpite tra febbraio e ottobre 2024 legge come una rassegna delle violazioni più discusse dell’anno: AT&T, con i log di chiamate e SMS di oltre 100 milioni di clienti; Ticketmaster/Live Nation, con dati relativi a circa 560 milioni di utenti; Advance Auto Parts; uno dei distretti scolastici più grandi degli Stati Uniti; Neiman Marcus; Santander; LendingTree. I dati sottratti includevano estratti bancari, informazioni finanziarie, numeri di registrazione DEA, patenti di guida, passaporti e numeri di previdenza sociale.

Estorsione, ri-estorsione e mercati underground

Dopo l’esfiltrazione, gli attaccanti hanno tentato di estorcere le aziende vittime minacciando la pubblicazione dei dati online, incassando circa 2,5 milioni di dollari in pagamenti di riscatto. Moucka ha inoltre guadagnato altri 495.000 dollari pubblicizzando parte dei dati rubati su forum criminali come BreachForums e XSS.is. Un dettaglio particolarmente inquietante emerso dagli atti processuali riguarda una vittima estorta due volte: nella seconda occasione, Moucka avrebbe utilizzato dati personali relativi a un funzionario governativo ex ed ai suoi familiari per aumentare la pressione. Le perdite complessive stimate per le vittime ammontano a circa 9,5 milioni di dollari.

Prima dell’arresto, avvenuto nel novembre 2024 e seguito dall’estradizione negli Stati Uniti nel luglio 2025, Moucka aveva parlato con la testata 404 Media dicendosi consapevole dell’imminente cattura e ammettendo di aver distrutto prove in vista dell’arresto.

Due righe per i difensori

Il caso Snowflake ha ridefinito il modello di minaccia per i servizi SaaS e data warehouse: non serve violare il fornitore cloud se le identità dei suoi clienti restano esposte. Per i team di sicurezza le lezioni pratiche restano attuali due anni dopo i fatti:

• Imporre l’autenticazione a più fattori su tutti gli account con accesso a piattaforme cloud e data warehouse, senza eccezioni per account di servizio o legacy.
• Ruotare periodicamente le credenziali e trattare come compromesse quelle esposte in precedenti data breach, anche se risalenti a diversi anni prima.
• Monitorare i mercati underground e i forum come BreachForums per individuare precocemente la messa in vendita di dati aziendali.
• Validare i log di accesso alle piattaforme SaaS per individuare pattern anomali provenienti da IP o infrastrutture non riconducibili agli utenti abituali.

La condanna definitiva di Moucka, attesa il 27 ottobre, non chiude del tutto il caso: restano aperte le posizioni di altri complici legati alla campagna, a conferma che dietro un singolo nome pubblico si nasconde quasi sempre un’infrastruttura criminale collaborativa e distribuita.

Timeline e dati chiave

Campagna attiva: febbraio - ottobre 2024
Cluster di minaccia (Mandiant): UNC5537
Aziende clienti Snowflake colpite: almeno 165
Vettore d'accesso: credenziali valide esposte (alcune dal 2020), assenza di MFA
Vittime principali: AT&T (100M+ utenti, log chiamate/SMS), Ticketmaster/Live Nation (560M utenti),
                     Advance Auto Parts, Neiman Marcus, Santander, LendingTree, distretto scolastico USA
Guadagni stimati: ~2,5M USD (riscatti) + 495.000 USD (vendita dati underground)
Perdite vittime stimate: ~9,5M USD
Mercati underground utilizzati: BreachForums, XSS.is
Complice: John Erin Binns (Turchia, già legato all'hack T-Mobile 2021)
Arresto Moucka: novembre 2024 (Canada) - Estradizione: luglio 2025
Dichiarazione di colpevolezza: 5 agosto 2026
Sentenza attesa: 27 ottobre 2026 (fino a 32 anni di carcere)

(in)sicurezza digitale

2026-08-06 19:37:02

OctLurk e SilkLurk: la backdoor sinofona che si decifra solo sulla macchina della vittima

Si parla di:
Toggle

Un malware che si rifiuta di funzionare su qualsiasi macchina tranne quella del bersaglio designato: è questa l’arma di precisione che un attore sinofono ha usato per almeno diciotto mesi contro ministeri, ospedali e centri di ricerca dell’Asia Centrale. Kaspersky GReAT ha battezzato l’operazione con i nomi dei due impianti che ne costituiscono il cuore, OctLurk e SilkLurk, e i dettagli tecnici pubblicati da Securelist disegnano il profilo di una campagna di cyberspionaggio pensata apposta per resistere all’analisi forense.

Un bersaglio, una chiave

Da gennaio 2025 il gruppo, non ancora attribuito a un cluster APT noto, ha colpito enti governativi e organizzazioni critiche in Afghanistan, Kirghizistan, Tagikistan, Uzbekistan, Kazakistan e, fuori dall’area, in Siria. La vittimologia comprende ministeri degli Esteri, forze dell’ordine, sanità, ricerca, logistica, pianificazione urbana e persino istituti scolastici pubblici — un ventaglio tipico delle operazioni di raccolta informativa a lungo termine piuttosto che del cybercrimine opportunistico.

Il tratto distintivo della campagna è la codifica “victim-specific”: entrambi i backdoor lasciano sul disco solo un minuscolo loader, mentre il payload vero e proprio resta cifrato finché non viene eseguito sulla macchina giusta. OctLurk usa il numero seriale del disco fisso come chiave di decifratura, SilkLurk il nome del computer. Se un analista prova a eseguire il campione in sandbox o su un sistema diverso da quello infettato, il payload semplicemente non si apre. È una tecnica che complica enormemente sia il rilevamento automatico sia il reverse engineering, perché toglie ai difensori la possibilità di “detonare” il malware in un ambiente controllato per osservarne il comportamento.

OctLurk: ricognizione e movimento laterale in memoria

OctLurk viene iniettato interamente in memoria tramite un loader dedicato. Prima di eseguire il payload principale, gli attaccanti verificano la connettività verso il dominio dns.ssentialserv[.]xyz, poi lanciano uno script batch che avvia LurkProxy, l’utility di proxying che stabilisce il contatto con il server di comando e controllo (C2) all’indirizzo 154.196.162[.]76.

Una volta operativo, OctLurk raccoglie le informazioni di sistema, le cifra e le invia via socket a un secondo C2 hard-coded, dns.multitoconference[.]com. Da quel momento il backdoor può caricare in memoria plugin aggiuntivi per l’esecuzione di comandi, operazioni sul filesystem, raccolta e manipolazione degli appunti, cattura di screenshot ed emulazione di mouse e tastiera. Gli operatori hanno sfruttato in particolare il plugin “command shell” per una sequenza di azioni molto concreta:

• fingerprinting completo dell’host e raccolta di informazioni estese sul sistema compromesso;
• esportazione e query degli eventi di logon interattivo remoto per individuare utenti specifici;
• dump degli hash delle password dai domain controller tramite secretsdump.py di Impacket;
• installazione di un keylogger travestito da AnyDesk per evitare il rilevamento;
• decifratura ed estrazione delle password salvate in Google Chrome e Mozilla Firefox;
• accesso remoto persistente tramite l’agente Pandora RC;
• scansione di reti interne e pubbliche con Fscan, alla ricerca di servizi SSH (porta 22) e MySQL (porta 3306), con tentativi di accesso usando credenziali da un file chiamato pp.txt;
• connessione a server di posta per raccogliere o manipolare messaggi email.

LurkProxy, il terzo strumento del set, può operare come proxy SOCKS5 o come proxy trasparente — una modalità alla volta — per instradare il traffico verso un indirizzo target, un accorgimento che aiuta gli attaccanti a mascherare l’origine delle connessioni C2 dentro il traffico di rete della vittima.

SilkLurk e il salto verso l’esfiltrazione

SilkLurk viene avviato tramite una DLL caricata con una sequenza di DLL side-loading, tecnica ormai marchio di fabbrica di diversi gruppi sinofoni. Dopo aver creato un socket TCP verso il proprio C2, invia le informazioni sulla vittima e attende istruzioni: sincronizzazione dell’orologio di sistema, impostazione dell’intervallo di polling, aggiornamento della configurazione o iniezione di ulteriori plugin in memoria.

L’attività post-compromissione osservata è quella di un’operazione di furto documentale mirato: tramite cmd.exe e PowerShell gli operatori si connettono a risorse di rete condivise usando credenziali amministrative, cercano e mettono da parte documenti riservati, si disconnettono dalle condivisioni e infine comprimono i dati rubati con WinRAR o 7-Zip. In alcuni casi la stessa catena di side-loading viene riutilizzata per distribuire PlugX, backdoor storicamente associata a gruppi di hacking cinesi.

Le tracce di un ecosistema più ampio

Kaspersky ha individuato sovrapposizioni infrastrutturali tra questa campagna e un impianto C++ precedentemente documentato, SilentRaid (noto anche come MystRodX o TrustFall), collegato a sua volta a un cluster di attività denominato UAT-7290 attivo contro operatori telco. I ricercatori restano cauti sull’attribuzione — non è chiaro se le due campagne siano state condotte in parallelo dallo stesso gruppo o se semplicemente condividano fornitori di infrastruttura — ma il quadro complessivo conferma quanto gli ecosistemi di cyberspionaggio sinofono continuino a riciclare toolkit, loader e provider tra operazioni distinte, rendendo la clusterizzazione un esercizio sempre più complesso per i difensori.

Cosa devono fare i difensori

Il vettore di accesso iniziale resta sconosciuto, il che rende la telemetria di rete l’unica difesa realmente efficace contro un impianto che vive quasi esclusivamente in memoria. Per le organizzazioni governative e critiche nell’area centroasiatica e per chiunque abbia rapporti con enti di quella regione, ha senso monitorare le connessioni verso i domini e l’IP indicati più sotto, verificare la presenza di keylogger mascherati da eseguibili legittimi come AnyDesk, controllare i log di logon interattivo remoto per pattern anomali di query mirate e, soprattutto, dare priorità a EDR capaci di ispezionare l’esecuzione in memoria piuttosto che il solo file scanning su disco, dato che il loader lasciato sul filesystem è deliberatamente minimale e poco significativo per il rilevamento signature-based.

Indicatori di compromissione

Domini C2:
dns.ssentialserv[.]xyz
dns.multitoconference[.]com

Indirizzo IP C2:
154.196.162[.]76

Strumenti abusati:
Impacket secretsdump.py
Fscan (github.com/shadow1ng/fscan)
Pandora RC agent
Keylogger camuffato da AnyDesk
WinRAR / 7-Zip per l'archiviazione dei dati esfiltrati
File di credenziali: pp.txt

Malware correlato:
PlugX (via DLL side-loading)
SilentRaid / MystRodX / TrustFall (overlap infrastrutturale)

Spcnet.it

2026-08-06 19:32:28

Autenticazione SSH a chiave pubblica: la guida completa con ssh-keygen

Perché le password su SSH sono ormai un rischio da eliminare

Se gestisci anche un solo server Linux esposto su Internet, i log di /var/log/auth.log te lo confermano ogni giorno: bot e botnet tentano continuamente il login SSH via password, in modalità brute-force o credential stuffing. Una password, per quanto complessa, resta un segreto condiviso che può essere intercettato, indovinato o riutilizzato da un attaccante che l’ha ottenuta altrove. L’autenticazione a chiave pubblica elimina questo vettore alla radice: il server non conosce mai un segreto trasmissibile, ma verifica solo che il client possieda la chiave privata corrispondente a una chiave pubblica già autorizzata.

Questa guida copre il flusso completo: generazione della coppia di chiavi con ssh-keygen, distribuzione della chiave pubblica, gestione di host multipli con ~/.ssh/config, uso di ssh-agent e, infine, disattivazione sicura del login via password lato server.

Generare la coppia di chiavi con ssh-keygen

Il primo passo è la scelta dell’algoritmo. Nel 2026 la raccomandazione per la quasi totalità degli scenari è Ed25519: chiavi più corte di RSA, generazione e verifica più veloci, sicurezza equivalente (o superiore) a RSA 3072/4096 bit. OpenSSH genera Ed25519 come default da ssh-keygen 9.5 (fine 2023), ma vale la pena specificarlo esplicitamente per chiarezza e portabilità degli script:

ssh-keygen -t ed25519 -C "nome@host-o-scopo-della-chiave"

Il comando chiede dove salvare la chiave (default ~/.ssh/id_ed25519) e una passphrase. Imposta sempre una passphrase: senza, chiunque copi il file della chiave privata (backup non cifrato, laptop rubato, snapshot di VM) ottiene accesso diretto ai sistemi target. Se devi supportare dispositivi legacy che non gestiscono Ed25519 (raro, ma capita con apparati di rete datati), usa RSA a 4096 bit come alternativa:

ssh-keygen -t rsa -b 4096 -C "nome@host-o-scopo-della-chiave"

Un’opzione spesso sottovalutata è l’uso di chiavi FIDO2/hardware, dove il materiale crittografico non lascia mai una security key fisica (es. YubiKey):

ssh-keygen -t ed25519-sk -C "chiave-hardware"

Per ambienti con requisiti di compliance elevati o accessi amministrativi privilegiati, vale la pena valutarla: anche in caso di compromissione totale della workstation, la chiave privata resta inaccessibile senza il dispositivo fisico.

Distribuire la chiave pubblica

Il modo più rapido è ssh-copy-id, che si occupa di creare (se assente) la directory ~/.ssh sul server remoto, con permessi corretti, e di appendere la chiave pubblica a authorized_keys:

ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@server

Se ssh-copy-id non è disponibile (ad esempio da un client Windows senza WSL), il metodo manuale equivalente è:

cat ~/.ssh/id_ed25519.pub | ssh utente@server \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

I permessi contano davvero: OpenSSH lato server rifiuta silenziosamente authorized_keys se la directory .ssh è scrivibile da altri utenti o se il file ha permessi troppo aperti. Se il login a chiave “non funziona” senza errori evidenti, controlla sempre chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys prima di cercare altrove.

Gestire host multipli con ~/.ssh/config

Chi amministra decine di server trae grande beneficio da un file di configurazione client centralizzato. Invece di ricordare chiave, utente e porta per ogni host, definisci alias in ~/.ssh/config:

Host prod-web01
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host *.interno.lan
    User admin
    IdentityFile ~/.ssh/id_ed25519_lan
    ForwardAgent no

Da quel momento ssh prod-web01 basta e avanza. L’opzione IdentitiesOnly yes è importante quando gestisci più chiavi: senza di essa, il client SSH può offrire al server tutte le identità disponibili nell’agent, esaurendo il numero massimo di tentativi consentiti (MaxAuthTries) prima di arrivare a quella corretta.

ssh-agent: passphrase una sola volta per sessione

Con una passphrase impostata (come dovrebbe essere sempre), digitarla a ogni connessione è scomodo. ssh-agent mantiene la chiave decifrata in memoria per la durata della sessione:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sulla maggior parte delle distribuzioni desktop l’agent è già integrato con il session manager. Evita ForwardAgent yes indiscriminato: l’agent forwarding espone la tua chiave in memoria a qualunque processo con privilegi root sul server intermedio, un rischio concreto se quel server non è pienamente fidato. Se ti serve saltare attraverso un bastion host, preferisci ProxyJump:

Host bastion
    HostName bastion.example.com
    User jump

Host target-interno
    HostName 10.0.5.20
    User admin
    ProxyJump bastion

Disabilitare l’autenticazione a password lato server

Solo dopo aver verificato che il login a chiave funziona correttamente (testalo in una sessione separata prima di chiudere quella attuale), disattiva la password lato server. Sulle distribuzioni moderne (Debian/Ubuntu recenti), il modo più pulito è un drop-in dedicato, che viene caricato prima del file principale e quindi vince sui default:

sudo mkdir -p /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/00-disable-password-auth.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t && sudo systemctl reload sshd

sshd -t valida la sintassi prima del reload: un errore di battitura in questo file può tagliarti fuori dal server se non hai un accesso alternativo (console cloud, iDRAC/iLO, ecc.). PermitRootLogin prohibit-password è la scelta consigliata rispetto a no secco: mantiene comunque disponibile il root via chiave per operazioni di emergenza, ma blocca il tentativo via password.

Checklist finale per un hardening solido

• Una chiave dedicata per servizio/scopo (deploy, amministrazione, CI/CD), non un’unica chiave riutilizzata ovunque.
• Passphrase sempre presente sulle chiavi memorizzate su disco non cifrato.
• Audit periodico di authorized_keys su ogni server: rimuovi le chiavi di chi ha lasciato il team o non necessita più di accesso.
• AuthorizedKeysCommand con backend centralizzato (Vault, LDAP) se gestisci decine di server e vuoi evitare la distribuzione manuale delle chiavi.
• Fail2ban o equivalente comunque attivo, come difesa in profondità anche a password disabilitate.

Conclusione

Il passaggio da password a chiavi SSH richiede pochi minuti per server, ma elimina una delle superfici di attacco più sfruttate contro sistemi Linux esposti. La combinazione di Ed25519, ~/.ssh/config ben strutturato e password disabilitate lato server è oggi lo standard minimo per qualunque infrastruttura, piccola o grande che sia.

Fonte: LinuxBlog.io.

Linux ssh-keygen: Set Up SSH Key Authentication the Right Way | LinuxBlog.io

Password-based SSH login is a liability. This guide walks through generating SSH key pairs with ssh-keygen, deploying public keys, disabling password authentication, and managing multiple keys cleanly with ~/.ssh/config.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-08-06 19:33:18

Unity abbandona Mono per CoreCLR: cosa cambia con .NET 10 e C# 14

Da Mono a CoreCLR: la fine di un’era per Unity

Se sviluppate in C# ma non toccate Unity, la notizia potrebbe sembrarvi di nicchia. Non lo è. Con la release di Unity 6.8, prevista entro la fine del 2026, il motore di gioco più diffuso al mondo abbandona definitivamente il proprio fork custom di Mono in favore di CoreCLR, il runtime “vero” del .NET moderno, con supporto a .NET 10 e C# 14. Per anni Unity è rimasto ostaggio di un’architettura di scripting congelata a metà del decennio scorso, mentre il resto dell’ecosistema .NET correva avanti tra top-level statements, pattern matching avanzato, source generator e miglioramenti di performance del JIT. Il cambio di runtime non è solo un aggiornamento di versione: è un caso di studio interessante per chiunque lavori con .NET, anche fuori dal game dev, perché racconta come si affronta la migrazione di un’applicazione legacy da AppDomain a un modello di isolamento moderno.

Domain Reload: il problema che ogni sviluppatore Unity conosce a memoria

Chi lavora su progetti Unity di dimensioni consistenti conosce fin troppo bene il Domain Reload: si salva uno script, si torna nell’editor, e parte una barra di progresso che su progetti grandi può durare decine di secondi. Il motivo è architetturale: ogni ricompilazione degli script comporta lo scaricamento completo dell’AppDomain e il suo ricaricamento da zero in memoria, un’operazione “a tappeto” pensata per un modello di isolamento vecchio di vent’anni.

Con CoreCLR, Unity abbandona il concetto di AppDomain in favore degli AssemblyLoadContext (ALC), il meccanismo di isolamento e caricamento assembly introdotto nel .NET moderno fin dai tempi di .NET Core. Invece di ricaricare tutto lo stato applicativo, il runtime può scaricare e ricaricare selettivamente solo gli assembly effettivamente modificati.

AssemblyLoadContext: un concetto utile ben oltre Unity

Per chi non l’avesse mai usato fuori da un contesto plugin-system, un AssemblyLoadContext è essenzialmente un contenitore isolato in cui caricare assembly .NET, che può essere scaricato indipendentemente dal resto dell’applicazione. È lo stesso meccanismo che sta dietro a scenari come plugin dinamici, hot reload di parti di un’applicazione server, o sandboxing di codice di terze parti. Un esempio minimale, applicabile a qualunque applicazione .NET moderna:

using System.Reflection;
using System.Runtime.Loader;

var alc = new AssemblyLoadContext("PluginContext", isCollectible: true);

Assembly plugin = alc.LoadFromAssemblyPath(@"C:\plugins\MyPlugin.dll");
// ... usa il plugin tramite reflection o interfacce condivise ...

alc.Unload(); // richiede la garbage collection per liberare davvero la memoria
GC.Collect();
GC.WaitForPendingFinalizers();

Il dettaglio da tenere presente, sia in Unity sia in un’applicazione .NET qualsiasi, è che uno scaricamento “leaked” è possibile: se un riferimento a un tipo caricato nell’ALC sopravvive fuori dal suo scope (una closure, un evento sottoscritto, un campo statico), l’assembly non può essere effettivamente liberato dal garbage collector. Non a caso, nel forum ufficiale Unity gli sviluppatori hanno confermato che il motore segnalerà esplicitamente all’utente quando un AssemblyLoadContext non riesce a essere scaricato correttamente, un problema di leak molto simile a quello che chi scrive plugin system in .NET conosce già.

Cosa cambia in pratica, oltre al Domain Reload

La migrazione a CoreCLR porta con sé una serie di conseguenze pratiche per chi sviluppa con Unity:

• ECS più integrato: gli Instance ID passano da 32 a 64 bit, permettendo a GameObject “classici” ed entità ECS (Data-Oriented Technology Stack) di condividere lo stesso spazio di identificatori. Un nuovo metodo GetEntityId() collega direttamente gli oggetti di scena al mondo ECS, riducendo la frizione tra i due paradigmi.
• Serializzazione nativa dei dizionari: Dictionary<TKey, TValue> sarà finalmente serializzabile nativamente dall’Inspector, eliminando i workaround basati su liste parallele di chiavi e valori o su ISerializationCallbackReceiver. In parallelo, Unity rimuove il datato e insicuro BinaryFormatter.
• IL2CPP resta, ma diventa opzionale: per le piattaforme non coperte da NativeAOT (che CoreCLR usa per la compilazione ahead-of-time), IL2CPP continuerà a essere il backend di scripting necessario. Su piattaforme compatibili, però, sarà possibile scegliere CoreCLR come backend alternativo già a partire da una preview tecnica prevista intorno a Unity 6.7.
• MiMalloc come allocatore di memoria: l’integrazione dell’allocatore ad alte prestazioni di Microsoft riduce i problemi di lock contention nei carichi multithread, con benefici diretti per chi usa il C# Job System in scenari data-oriented.

Perché la cosa interessa anche chi non fa game dev

Il percorso di Unity da Mono a CoreCLR è, in piccolo, lo stesso tipo di migrazione che molte software house con applicazioni .NET Framework legacy dovranno affrontare prima o poi: passare da un modello di isolamento basato su AppDomain (o peggio, da un fork custom del runtime) a un’architettura moderna basata su ALC, con tutti i vantaggi in termini di performance, ma anche le insidie legate alla gestione del ciclo di vita degli assembly caricati dinamicamente. Se lavorate su plugin system, hosting di codice di terze parti o architetture a moduli scaricabili a runtime, vale la pena studiare da vicino come Unity gestisce concretamente i leak di ALC: è un problema che, presto o tardi, si incontra in qualunque applicazione .NET che provi a fare hot-reload o isolamento dinamico.

Conclusione

Con Unity 6.8, il motore smette di essere un’isola separata dall’ecosistema .NET e si allinea finalmente al runtime moderno, portando in dote C# 14, prestazioni migliori e un developer loop molto più rapido. Per chi sviluppa giochi è una notizia enorme; per chi sviluppa in .NET in generale è un promemoria utile su come affrontare, con gli strumenti giusti, la migrazione da architetture di isolamento legacy a AssemblyLoadContext.

Fonte: DZone, con dettagli tecnici dal thread ufficiale Path to CoreCLR, 2026: Upgrade Guide su Unity Discussions.

1714279

^{discussions.unity.com}

Marco Cappato

2026-07-29 00:29:41

Chi controlla l'informazione in Italia? Spionaggio e potere con Francesco Cancellato

Ho incontrato Francesco Cancellato, direttore di Fanpage.it, e insieme abbiamo parlato della trasformazione del sistema dei media, del suo impatto sulla libertà di informazione e sulla tenuta delle istituzioni democratiche.

Siamo partiti dal caso Paragon, lo spionaggio che Cancellato ha subito tramite lo spyware Graphite, una vicenda che – pur avendo una gravità accertata diversa – mi ha ricordato quella che ho vissuto io, quando mi è arrivata notizia di essere spiato dai servizi segreti italiani (youtu.be/KpPrKNUExeE).

Da lì abbiamo parlato della vulnerabilità dei cittadini e dei giornalisti di fronte all'uso incontrollato di strumenti di sorveglianza militare, toccando poi altri argomenti: il ruolo degli editori indipendenti all'interno di un mercato dominato dalle piattaforme Big Tech, i rischi legati alla disinformazione generata dall'intelligenza artificiale e le trasformazioni della partecipazione politica di fronte alle grandi crisi globali, prima fra tutte la lotta al cambiamento climatico.

✍️ Iscriviti alla mia newsletter: marcocappato.substack.com/subs…
È il canale in cui cercherò di stare dietro alle notizie e commentare quello che succede.

Se vuoi inviarmi domande o riflessioni, scrivimi a marcocappato@substack.com

marcocappato.it
CAPPATO TUBE, i miei video sul Fediverso: video.marcocappato.it
MASTODON: mastodon.uno/@marcocappato
INSTAGRAM: instagram.com/marcocappato/
LINKEDIN: linkedin.com/in/marco-cappato/
X: https://x.com/marcocappato
🔬Associazione Luca Coscioni: associazionelucacoscioni.it/
🇪🇺 Eumans: eumans.eu/

Con il supporto dell'Associazione Luca Coscioni
🐐 Powered by Biquette: instagram.com/biquette.it/

00:00 - Intro
01:15 - Il caso dello spyware Paragon
07:17 - Sorveglianza digitale e tutela della privacy
13:37 - Indipendenza editoriale, grandi piattaforme e qualità dell'informazione
18:58 - L'impatto dell'Intelligenza Artificiale sui media e sulla democrazia
23:47 - Il ruolo della regolamentazione e il valore dei dati pubblici
30:28 - La crisi della democrazia rappresentativa
39:01 - Crisi globali e politica nazionale
46:51 - Economia, beni comuni e costo sociale delle emissioni
53:58 - È la fine del populismo?
1:02:24 - Domanda trappola

Spcnet.it

2026-08-05 12:39:09

Troubleshooting Windows: perché partire dall’evidenza e non dal comando di riparazione

Il problema non è la mancanza di strumenti, è l’ordine in cui si usano

Windows include più utility diagnostiche di quante un amministratore ne userà mai tutte. Eppure la causa più comune di sessioni di troubleshooting infruttuose non è l’ignoranza dei tool, ma la sequenza sbagliata: si parte da un comando di riparazione (sfc /scannow, un reset di Windows Update, un DISM al buio) prima ancora di aver capito quale sottosistema sta effettivamente fallendo. Il risultato è tempo perso, evidenze diagnostiche distrutte dal riavvio, e spesso la causa radice che resta lì, pronta a ripresentarsi la settimana successiva.

Vale la pena fermarsi a formalizzare un metodo, perché è quello che separa un troubleshooting efficace da un’accozzaglia di tentativi casuali. Di seguito un processo in cinque passi, seguito da una rassegna degli strumenti chiave e da una tabella sintesi sintomo → strumento che può diventare un riferimento rapido da tenere a portata di mano durante un incidente.

Un processo ripetibile prima di toccare qualsiasi comando

La maggior parte delle sessioni di troubleshooting falliscono prima ancora che venga lanciato il primo comando. Un amministratore vede un errore, prova un comando di riparazione che conosce, riavvia, e scopre che il problema originale è ancora lì. Un approccio più solido richiede di rallentare abbastanza da stabilire una baseline:

1. Confermare o riprodurre il problema: è cronico o è stato un episodio isolato?
2. Registrare il sintomo esatto: messaggio di errore, orario, utente coinvolto, dispositivo, modifiche recenti.
3. Raccogliere le evidenze dal sistema più probabilmente coinvolto.
4. Applicare una modifica alla volta, partendo dall’opzione meno invasiva.
5. Verificare il risultato e documentare cosa è effettivamente cambiato.

Un esempio concreto: se Windows Update fallisce con un errore generico, la tentazione è resettare tutti i componenti di aggiornamento in blocco. Il primo passo corretto è invece capire in quale fase è avvenuto il fallimento — scan, download, staging, installazione o riavvio — perché questa distinzione determina se bisogna guardare i log di Windows Update, i log di servicing, lo stato del disco, la configurazione delle policy o la connettività di rete.

Event Viewer: il primo posto dove cercare quando c’è un timestamp

Event Viewer è il punto di partenza quando il sintomo ha un orario preciso: un crash applicativo, un riavvio inatteso, un servizio che si ferma, un problema di driver, un’installazione fallita. Si parte dai Windows Logs, filtrando Application, System e Setup per eventi Critical, Error e Warning nell’intorno temporale del problema, per poi individuare l’event source, l’event ID, il modulo che genera il fault, il nome del servizio o del driver coinvolto.

Il criterio per separare il segnale dal rumore è la ripetibilità: un warning isolato di ieri è quasi sempre rumore; un errore che compare sistematicamente ogni volta che si apre una determinata applicazione è un segnale affidabile. Le evidenze diagnostiche più utili sono quelle correlate nel tempo e riproducibili, non gli eventi isolati.

SFC prima, DISM solo se SFC non basta

System File Checker (SFC) è uno strumento di riparazione mirato per i file di sistema protetti. Si usa quando una feature nativa di Windows si comporta in modo anomalo, un componente integrato non parte, oppure Event Viewer punta a file del sistema operativo mancanti o corrotti:

sfc /scannow

SFC è utile perché verifica e sostituisce i file protetti senza richiedere una reinstallazione, ma dipende dal component store locale come sorgente di riparazione. Se quello store è danneggiato, SFC può segnalare corruzione trovata ma non riparabile del tutto. A quel punto il passo successivo è DISM, non ripetere SFC all’infinito sperando in un risultato diverso.

Deployment Image Servicing and Management (DISM) opera a livello di image e component store, uno strato sotto SFC. Va usato quando SFC non riesce a completare le riparazioni, quando l’installazione di Windows Update o di una feature fallisce ripetutamente, o quando il problema è a livello di servicing. Il comando di riparazione online più comune:

DISM /Online /Cleanup-Image /RestoreHealth

In ambienti enterprise, DISM può aver bisogno di una sorgente di riparazione affidabile — supporto di installazione, un’immagine montata, o una posizione di contenuto gestita — soprattutto quando gli endpoint non possono scaricare i contenuti di riparazione da Windows Update. Dopo che DISM completa con successo, conviene rilanciare SFC, così i file protetti possono essere riparati da un component store ormai sano.

Windows Update: capire in quale fase fallisce prima di resettare tutto

Il troubleshooting di Windows Update deve partire dall’identificazione della fase fallita. Un fallimento nello scan suggerisce problemi di policy, rete, proxy o sorgente di aggiornamento. Un fallimento nel download indica problemi di connettività, disponibilità dei contenuti o cache. Un fallimento nell’installazione punta spesso allo servicing stack, al component store, allo spazio su disco, a un riavvio pendente o a un driver in conflitto.

Sulle versioni moderne di Windows, Windows Update si basa su dati Event Tracing for Windows (ETW) piuttosto che scrivere un semplice log testuale in continuo. Per generare un log leggibile quando serve un dettaglio più approfondito lato client, si usa PowerShell:

Get-WindowsUpdateLog

Vale anche controllare Event Viewer nei log operativi del client di Windows Update e il Setup log per gli eventi di installazione. Se lo stesso pacchetto KB fallisce ripetutamente, conviene verificare se l’aggiornamento è applicabile, se esiste un aggiornamento che lo sostituisce, e da quale sorgente il dispositivo riceve gli update — Windows Update diretto, Microsoft Update, WSUS, oppure una piattaforma di gestione come Intune o Configuration Manager.

Un reset completo di Windows Update dovrebbe essere un passo tardivo, non il primo. Resettare i servizi e svuotare le cache può sbloccare client incastrati, ma distrugge anche evidenze utili. Meglio catturare prima il codice di errore, i log e la cronologia degli aggiornamenti.

“La rete non funziona” è quasi sempre DNS o configurazione

I sintomi di rete richiedono un punto di partenza diverso, perché gli utenti spesso descrivono come “la rete è giù” un problema che in realtà è DNS, routing, autenticazione, policy del firewall o un singolo endpoint applicativo che non risponde. È corretto partire dalla configurazione TCP/IP locale prima di testare i servizi remoti.

Un errore comune tra amministratori meno esperti è dare per scontato che “il ping non risponde” equivalga a “la rete è giù”. In ambienti enterprise questa assunzione è spesso sbagliata: molti sistemi sono configurati per ignorare le richieste ICMP pur continuando a erogare regolarmente il servizio previsto. Un firewall può bloccare ICMP, una policy di sicurezza può disabilitare le risposte, un servizio cloud può non rispondere mai al ping. La domanda giusta non è se un dispositivo risponde al ping, ma se il servizio richiesto è effettivamente raggiungibile: bisogna sempre testare ciò che l’utente sta effettivamente cercando di usare, con strumenti come ipconfig, nslookup e tracert mirati sul servizio specifico.

Tabella di riferimento rapido: sintomo → strumento

Sintomo	Partire da	Perché
App che va in crash o si chiude inaspettatamente	Event Viewer, poi Reliability Monitor	Identifica moduli in fault, errori applicativi e pattern di modifiche recenti
Windows Update fallisce ripetutamente	Log di Windows Update, Setup log, DISM	Separa i fallimenti di scan, download, installazione e servicing
Feature di Windows mancanti o instabili	SFC, poi DISM se SFC non ripara	Ripara i file di sistema protetti e il component store sottostante
Utenti non raggiungono risorse di rete	ipconfig, ping, nslookup, tracert	Valida configurazione locale, raggiungibilità, DNS e routing in ordine
Le performance degradano improvvisamente	Task Manager, Resource Monitor, Event Viewer	Correla la pressione sulle risorse con servizi, driver ed errori

Reliability Monitor merita una menzione a parte perché offre una vista a timeline di crash applicativi, fallimenti di Windows, installazioni di driver ed eventi di aggiornamento. È meno dettagliato di Event Viewer, ma resta eccellente per individuare rapidamente cosa è cambiato immediatamente prima che iniziasse un problema ricorrente.

Costruire il proprio toolkit di troubleshooting

Per un professionista IT, l’abilità di troubleshooting più preziosa non è memorizzare comandi, ma sapere quale fonte di evidenza fidarsi per una determinata classe di problema. Event Viewer dice cosa Windows ha registrato; Reliability Monitor mostra quando i problemi sono iniziati. Una checklist pratica da seguire durante un incidente:

• Registrare sintomi esatti, orario, dispositivo, utente e modifiche recenti.
• Controllare i log più rilevanti prima di applicare riparazioni ad ampio raggio.
• Eseguire i comandi di riparazione da un terminale elevato e catturarne l’output.
• Cambiare una variabile alla volta, per sapere con certezza cosa ha risolto il problema.
• Verificare dal punto di vista dell’utente, non solo dalla console amministrativa.

Questa disciplina previene due errori tipici: eseguire riparazioni distruttive troppo presto, e dichiarare vittoria prima di aver verificato il flusso di lavoro reale. Se un utente non riesce ad aprire una condivisione di rete, un ping riuscito non è il traguardo: il traguardo è l’utente che apre la condivisione, accede ai file attesi e conferma che il problema non si ripresenta.

Conclusione

La differenza tra una sessione di troubleshooting produttiva e una frustrante raramente sta nella conoscenza di comandi avanzati. Sta nel partire dal sintomo invece che dal comando, chiedersi quale evidenza confermerebbe o smentirebbe la causa più probabile, e solo a quel punto scegliere lo strumento che fornisce quell’evidenza nel modo più veloce. È questa disciplina che trasforma una collezione di utility in un vero toolkit diagnostico.

Fonte: Critical Windows Troubleshooting Tools: Stop Wasting Time on the Wrong Fixes, Petri IT Knowledgebase

Critical Windows Troubleshooting Tools for Faster Fixes

Learn to use Windows troubleshooting tools like Event Viewer, System File Checker, and DISM.

^{Michael Reinders (Petri IT Knowledgebase)}

Spcnet.it

2026-08-05 12:35:04

Diagnosticare lo swap su Linux con smem: USS, PSS, RSS e il ruolo di vm.swappiness nei cgroup v2

Un server con RAM libera che continua a usare swap è uno degli scenari più fraintesi nella diagnostica Linux. La reazione istintiva è quasi sempre la stessa: aumentare la RAM o disattivare lo swap. Nessuna delle due è la risposta giusta se prima non sai quale processo sta finendo su disco e perché. Lo strumento più adatto a rispondere a questa domanda è smem, un tool di reporting che calcola l’uso di memoria proporzionale per processo, swap incluso — una cosa che top e ps da soli non fanno.

Perché il kernel usa lo swap anche con RAM libera

Linux è progettato per usare tutta la RAM disponibile, spesso per la cache dei file. Quando il kernel decide che alcune pagine di memoria non vengono accedute da un po’, può spostarle su swap anche se c’è ancora RAM libera: è un comportamento intenzionale, non un guasto. Il parametro che governa questa aggressività è vm.swappiness, un valore da 0 a 200 che esprime quanto il kernel preferisce recuperare pagine di cache file rispetto a spostare pagine anonime su swap.

Un dettaglio poco noto e rilevante da kernel 5.8 in poi: con i cgroup v2, vm.swappiness=0 non significa più “non spostare mai nulla su swap”. Continua a indicare una forte preferenza per liberare cache file, ma il kernel spingerà comunque pagine anonime su swap se è vicino all’OOM. Prima di intervenire su questo parametro, però, il primo passo resta capire chi sta effettivamente consumando swap.

Installare smem

Non è quasi mai preinstallato, ma è nei repository delle principali distribuzioni:

# RHEL / CentOS / AlmaLinux / Fedora
dnf install smem

# Debian / Ubuntu
apt install smem

USS, PSS e RSS: la differenza che conta davvero

La ragione per cui smem è più utile di un ps aux --sort=-rss al volo sta nelle metriche che espone. ps e top mostrano principalmente RSS, che sovrastima sistematicamente l’uso di memoria perché conta anche le pagine condivise tra processi (librerie, memoria mappata) come se appartenessero interamente a ciascun processo.

• RSS (Resident Set Size): memoria fisica occupata dal processo, incluse le pagine condivise con altri processi — per questo tende a sovrastimare.
• USS (Unique Set Size): memoria usata esclusivamente da quel processo, senza nulla di condiviso. È quanta memoria verrebbe effettivamente liberata se il processo terminasse.
• PSS (Proportional Set Size): somma la USS più una quota proporzionale della memoria condivisa, distribuita tra tutti i processi che la usano. È la metrica più realistica per capire “quanta memoria sta davvero consumando il sistema per questo processo”, perché sommando i PSS di tutti i processi non conti la stessa pagina condivisa più volte.

Su un web server con decine di processi PHP-FPM o worker Nginx che condividono le stesse librerie, la differenza tra RSS e PSS può essere enorme: sommare tutti gli RSS ti dà un numero fantasioso, sommare i PSS ti avvicina al reale consumo di RAM del sistema.

Uso di base: chi sta consumando swap

Il comando principale per la diagnosi dello swap ordina i processi per swap decrescente:

smem -rs swap

Output tipico (troncato):

  PID User     Command                         Swap      USS      PSS      RSS
28986 mysql    /usr/sbin/mysqld --daemoniz   476372  10963864 10963932 10965112
29152 root     /usr/sbin/rsyslogd -n         371424     3956    17475    43352
31423 root     /opt/fluent-bit/bin/fluent-     22508    26612    26739    29100

In questo esempio è immediato vedere che mysqld e rsyslogd sono i responsabili principali dello swap, non un generico “sistema pieno”. Questo è già un’informazione azionabile: invece di aggiungere RAM alla cieca, sai su quale servizio intervenire.

Per una vista più visuale, smem genera anche grafici a torta per utente o processo, utile per presentare rapidamente la distribuzione dei consumi:

smem --pie name -s rss

(richiede matplotlib installato per generare l’immagine).

Cosa fare dopo aver identificato il colpevole

Una volta isolato il processo, la strada tipica è duplice: da un lato tuning applicativo del servizio (per MySQL, rivedere innodb_buffer_pool_size e le connessioni aperte; per rsyslog, verificare codeon accumulo di code su disco lento), dall’altro una revisione più conservativa di vm.swappiness:

sysctl vm.swappiness=1
echo 'vm.swappiness=1' >> /etc/sysctl.conf

Un valore basso (1-10) dice al kernel di preferire fortemente la RAM e ricorrere allo swap solo come ultima risorsa, comportamento adatto alla maggior parte dei carichi di hosting: il default di 60 è pensato per un uso desktop generico ed è piuttosto aggressivo per un server.

Se il servizio gira in un cgroup (container, systemd slice)

Su sistemi che orchestrano i workload con cgroup v2 — container Docker/Podman, unit systemd con MemoryMax=, pod Kubernetes — la vecchia intuizione su swap e RAM va integrata con un secondo livello di controllo: memory.swap.max. Questo parametro è un limite massimo di swap utilizzabile dal cgroup: se il cgroup raggiunge quel tetto, la memoria anonima al suo interno smette di essere spostata su swap, indipendentemente da cosa dice vm.swappiness a livello di kernel. Non è pensato per gestire quanto swap viene usato durante il funzionamento normale, ma come argine per evitare che un singolo cgroup saturi lo swap dell’intero host.

Una pratica ragionevole quando si dimensionano i limiti di un cgroup è impostare memory.high attorno al 10-20% sotto memory.max, per dare al kernel margine di reclaim prima di colpire il limite duro, e aggiungere un 20-30% al di sopra del picco di utilizzo reale dell’applicazione quando si calcola memory.max, per tenere conto della page cache che nei cgroup v2 conta comunque contro il totale di memoria assegnato.

Conclusione

smem è uno strumento leggero ma preciso per rispondere a una domanda che free, top o vmstat lasciano aperta: non solo “quanto swap sto usando”, ma “chi lo sta usando e quanto pesa davvero, al netto della memoria condivisa”. Su un server che sembra inspiegabilmente lento nonostante RAM apparentemente disponibile, è spesso il primo strumento da tirare fuori prima di toccare vm.swappiness, aggiungere RAM o — peggio — disattivare lo swap del tutto, cosa che su Linux tende a peggiorare le cose sotto pressione di memoria invece di risolverle.

Fonte originale: Diagnosing Swap Usage with smem on Linux, LinuxBlog.io

Diagnosing Swap Usage with smem on Linux | LinuxBlog.io

If you've ever looked at your server and wondered why it's using swap even though plenty of RAM is available, you're not alone. This is a common scenario

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-08-05 12:45:25

Acqua sotto attacco: come hacker legati all’Iran hanno tentato di contaminare le reti idriche di sette stati USA

Si parla di:
Toggle

Non un semplice blackout digitale, ma un tentativo — riuscito solo in parte — di trasformare un attacco informatico in un’emergenza sanitaria pubblica. FBI ed EPA hanno confermato che, dal 27 luglio 2026, impianti idrici e fognari di almeno sette stati americani sono stati colpiti da intrusioni coordinate contro controllori industriali esposti su internet. Un memo delle forze dell’ordine del Minnesota, il primo stato a rendere pubblico l’incidente, è ancora più esplicito sul movente: l’obiettivo dichiarato degli attaccanti non era interrompere il servizio, ma contaminare l’acqua potabile.

Cosa è successo nel weekend del 26-27 luglio

Il Minnesota ha rilevato attività ostile su oltre 30 sistemi idrici e fognari comunitari nella notte tra domenica 26 e lunedì 27 luglio. L’impianto idrico di Braham, una comunità di circa 1.700 abitanti, è stato messo completamente fuori uso e ripristinato in circa due ore passando alla gestione manuale. A Plymouth sono state disconnesse apparecchiature con connettività cellulare su due torri idriche e diverse stazioni di sollevamento fognario. South St. Paul e Maple Plain hanno mantenuto il servizio nonostante l’impatto sui controlli automatizzati, ma Maple Plain ha dichiarato lo stato di emergenza locale.

L’incidente non si è fermato al Minnesota: il Wisconsin ha rilevato attività ostile sui propri impianti idrici nello stesso arco temporale, tanto da spingere il Dipartimento delle Risorse Naturali a ordinare “azioni immediate” agli operatori. Nell’avviso congiunto pubblicato giovedì, FBI ed EPA hanno confermato che utility idriche di almeno sette stati — non nominati pubblicamente — hanno segnalato incidenti dal 27 luglio in poi, in alcuni casi con degrado operativo reale.

Il bersaglio tecnico: PLC Rockwell esposti su internet

L’avviso FBI/EPA identifica con precisione l’equipaggiamento colpito: controllori logici programmabili (PLC) Allen-Bradley delle serie MicroLogix 1100 e 1400, prodotti da Rockwell Automation, raggiungibili direttamente da internet. Gli attaccanti hanno effettuato accesso remoto a questi dispositivi, modificandone indirizzo IP e password — di fatto scacciando gli operatori legittimi dalla possibilità di monitorare e controllare l’impianto. In almeno un caso, dopo aver notato discrepanze tra siti diversi, l’organizzazione vittima ha scoperto che gli attaccanti erano andati oltre, alterando direttamente i file di progetto del PLC: la logica ladder che governa il comportamento fisico di pompe e valvole.

La fisica dietro l’obiettivo dichiarato dagli attaccanti si chiama backsiphonage. Le reti di distribuzione idrica lavorano in pressione positiva, tipicamente tra 40 e 80 psi, per spingere l’acqua verso gli utenti e tenere fuori dalle tubature eventuali contaminanti esterni. L’EPA fissa a 20 psi la soglia sotto la quale un evento di perdita di pressione viene classificato come pericoloso: scendere sotto quel valore in prossimità di un cross-connection — un punto in cui le tubature di distribuzione corrono vicino a fonti non potabili, come acque di falda, pozzi privati o linee fognarie — può risucchiare quei contaminanti all’interno del sistema attraverso giunti o crepe nelle tubature, lo stesso principio fisico di una cannuccia. La pericolosità dell’attacco sta nella combinazione di due capacità simultanee: manipolare i PLC per abbassare la pressione, e allo stesso tempo sopprimere gli allarmi che dovrebbero avvisare gli operatori del calo, lasciandoli con dashboard apparentemente normali mentre il sistema fisico è già in stato non sicuro.

Nessuna contaminazione è stata confermata: il Dipartimento della Salute del Minnesota ha dichiarato che la qualità dell’acqua non è stata compromessa in nessuno degli impianti colpiti e non sono state emesse ordinanze di bollitura a livello statale.

Chi c’è dietro: Iran, CyberAv3ngers e l’ipotesi false flag

Gli investigatori federali ritengono probabile il coinvolgimento di attori legati all’Iran, sebbene l’attribuzione non sia confermata. Il tempismo è indicativo: gli attacchi in Minnesota sono iniziati quattro giorni dopo che la CISA aveva aggiornato un avviso su larga scala riguardante l’espansione delle operazioni iraniane contro acqua, energia e infrastrutture governative statunitensi. Tre giorni prima degli attacchi, il gruppo Handala — attribuito al Ministero dell’Intelligence iraniano — aveva pubblicamente minacciato di colpire reti idriche, elettriche e di trasporto americane, proprio nello stesso giorno dell’aggiornamento CISA.

Secondo i ricercatori di Tenable, il pattern operativo osservato in Minnesota è coerente con l’ecosistema CyberAv3ngers, gruppo collegato al Corpo delle Guardie Rivoluzionarie Islamiche che dal 2023 prende sistematicamente di mira le infrastrutture idriche statunitensi e sanzionato dal Tesoro USA nel febbraio 2024. Il contesto geopolitico è quello di un conflitto armato aperto tra Stati Uniti e Iran, iniziato il 28 febbraio 2026 e proseguito con un cessate il fuoco entrato in vigore ad aprile: le operazioni cyber iraniane contro le infrastrutture critiche americane sono continuate e si sono intensificate da allora.

Gli inquirenti stanno però valutando anche un’ipotesi più inquietante: che chi ha condotto l’attacco abbia deliberatamente riutilizzato tattiche, strumenti e infrastruttura associati agli attori iraniani per costruire un’operazione false flag, capace di alimentare tensioni tra Washington e Teheran in un momento in cui i due paesi sono già in conflitto aperto. Nessuna attribuzione formale è stata effettuata; nessuna accusa è stata mossa.

Uno scontro politico, un problema strutturale

La vicenda ha acceso anche uno scontro politico interno: il presidente Trump ha respinto pubblicamente l’attribuzione all’Iran, attribuendo la responsabilità alla “grossolana incompetenza” del Minnesota e del governatore democratico Tim Walz. Walz ha risposto puntando il dito contro i tagli imposti dall’amministrazione Trump alla CISA, che secondo TechCrunch ha perso circa un terzo del proprio organico, incluso lo smantellamento della sua iniziativa anti-ransomware. Al di là della disputa politica, il problema strutturale resta: un’indagine EPA del 2024 ha rilevato che il 70% dei sistemi idrici ispezionati dal 2023 non rispettava gli obblighi di valutazione del rischio previsti dall’America’s Water Infrastructure Act, e un successivo rapporto dell’Inspector General ha individuato vulnerabilità critiche o gravi in 97 dei oltre 1.000 sistemi idrici controllati, per una popolazione servita di circa 26,6 milioni di persone.

Cosa devono fare subito gli operatori

Le raccomandazioni congiunte di FBI, EPA e CISA per il settore idrico sono immediate e concrete: scollegare i PLC dall’accesso diretto a internet, sostituendo la connettività cellulare non protetta con VPN dedicate e autenticazione a più fattori dove l’accesso remoto resta necessario; cambiare tutte le password predefinite o deboli, dato che una quota significativa dei dispositivi compromessi utilizzava credenziali banali; confrontare i file di progetto dei PLC in produzione con backup offline noti per individuare eventuali discrepanze nella logica ladder, che possono persistere anche dopo un reset delle password; impostare fisicamente i selettori a chiave dei controllori in modalità “Run”, che blocca la modifica remota della logica anche in caso di compromissione di rete; e pianificare la sostituzione dei dispositivi a fine vita come le serie MicroLogix 1100/1400, che potrebbero non ricevere più aggiornamenti di sicurezza da Rockwell Automation.

Un dettaglio da non sottovalutare riguarda i fornitori di servizi gestiti: l’avviso FBI segnala che configurazioni di rete replicate da uno stesso managed service provider su più clienti possono moltiplicare il successo di un singolo attacco su decine di impianti diversi — un rischio di supply chain che le utility idriche, spesso piccole e con personale IT limitato o assente, raramente hanno la capacità di verificare da sole.

Indicatori tecnici e riferimenti

Dispositivi presi di mira:
Rockwell Automation Allen-Bradley MicroLogix 1100 (PLC)
Rockwell Automation Allen-Bradley MicroLogix 1400 (PLC)

Tecnica osservata:
Accesso remoto diretto a PLC esposti su internet
Modifica di IP e password del dispositivo
Alterazione dei file di progetto / logica ladder ("ladder logic discrepancies")
Soppressione di allarmi e monitoraggio

Attore sospettato:
CyberAv3ngers / cluster IRGC-CEC (attribuzione non confermata da FBI)
Possibile operazione false flag in corso di verifica

Riferimenti ufficiali:
FBI/EPA PSA - Malicious Cyber Actors Targeting Water and Wastewater Sector PLCs
CISA Advisory AA26-097A (campagna ICS legata all'Iran)

(in)sicurezza digitale

2026-08-05 12:43:44

OVERCAST PANDA: la Cina compromette fisicamente i laptop di giornalisti e scienziati in hotel

Si parla di:
Toggle

Non serve sempre un exploit da milioni di dollari per compromettere un bersaglio di alto valore: a volte basta un cacciavite, una chiavetta USB e una cena fuori dalla stanza d’albergo. È questo lo scenario descritto dal CrowdStrike 2026 Threat Hunting Report, pubblicato il 3 agosto, che rivela come tra marzo e maggio 2026 il team OverWatch abbia individuato e neutralizzato una serie di operazioni “close access” condotte in Cina dall’adversary OVERCAST PANDA contro i laptop di giornalisti, ricercatori e altri professionisti stranieri in viaggio nel Paese.

Chi è OVERCAST PANDA

OVERCAST PANDA è un adversary china-nexus attivo almeno dal 2019, in precedenza tracciato con il nome di cluster ClearVariable. Il suo tradecraft è storicamente caratterizzato dall’uso di due impianti proprietari, FlowCloud e LookBack, distribuiti attraverso vettori diversi a seconda dell’operazione. Ciò che distingue questa campagna dalle tipiche intrusioni china-nexus — solitamente basate su spear phishing, sfruttamento di vulnerabilità edge o compromissioni della supply chain software — è la scelta di un approccio interamente fisico, capace di bypassare di netto qualunque difesa di rete o endpoint basata su telemetria da remoto.

La tecnica: accesso fisico opportunistico e boot da USB

Secondo la ricostruzione di CrowdStrike, gli operatori di OVERCAST PANDA hanno sfruttato momenti di assenza dei bersagli — tipicamente durante cene o eventi collaterali di conferenze — per accedere fisicamente a laptop lasciati incustoditi nelle stanze d’albergo. Il dispositivo veniva avviato da un supporto USB rimovibile, bypassando così il sistema operativo in esecuzione e le relative protezioni, incluso qualunque agente EDR installato: l’impianto FlowCloud veniva scritto direttamente sul disco, fuori dal contesto del sistema operativo attivo.

Al successivo riavvio del laptop — un’operazione del tutto ordinaria che non insospettisce la vittima — il backdoor si avviava automaticamente e restava operativo in modo persistente e silenzioso. Su almeno uno dei casi disinnescati da OverWatch, il laptop non aveva mai mostrato alcun segno di intrusione a livello di rete, a conferma che l’intero attacco si era consumato offline, senza lasciare tracce nei log di traffico che i team di sicurezza normalmente monitorano.

Le capacità di FlowCloud

Una volta attivo, FlowCloud fornisce agli operatori un accesso pressoché completo alla macchina compromessa: keylogging, cattura di screenshot, raccolta ed esfiltrazione di file, furto di credenziali salvate. Per un giornalista che sta lavorando su fonti sensibili o per un ricercatore che porta con sé dati proprietari o pre-pubblicazione, l’impianto rappresenta un rischio equivalente a una sorveglianza fisica prolungata, ma condotta interamente a livello digitale e senza necessità di ulteriore contatto con il bersaglio dopo l’installazione iniziale.

Il contesto: il Threat Hunting Report 2026 di CrowdStrike

Il caso OVERCAST PANDA si inserisce in un quadro più ampio disegnato dal report, che descrive un ecosistema china-nexus sempre più aggressivo e rapido. Gli adversary VAULT PANDA e GENESIS PANDA, ad esempio, hanno sfruttato vulnerabilità critiche entro 24 ore dalla pubblicazione di proof-of-concept pubblici — un ritmo nettamente superiore alla media generale osservata da CrowdStrike, secondo cui l’88% degli sfruttamenti di vulnerabilità con PoC disponibile avviene comunque entro 48 ore dalla release. Il report segnala inoltre una crescita del 30% negli annunci di initial access broker relativi a società tecnologiche (277 aziende offerte in vendita), a testimonianza di una domanda crescente per accessi già pronti all’uso.

In questo contesto, le operazioni close access di OVERCAST PANDA rappresentano un promemoria che la sofisticazione offensiva cinese non si esaurisce nel dominio puramente informatico: la disponibilità di personale sul territorio nazionale permette di condurre operazioni ibride, fisiche e digitali, contro bersagli che altrimenti sarebbero difficili da raggiungere da remoto.

Implicazioni pratiche per viaggiatori e organizzazioni

Per chi viaggia in Cina — o in qualunque contesto ad alto rischio — con dispositivi aziendali, alcune contromisure restano fondamentali:

• non lasciare mai laptop o dispositivi incustoditi in stanze d’albergo, anche per periodi brevi; usare cassaforte in camera solo come deterrente minimo, non come garanzia
• abilitare la crittografia full-disk con autenticazione pre-boot e disabilitare il boot da dispositivi USB o esterni via firmware/BIOS, con password dedicata
• utilizzare dispositivi “da viaggio” dedicati, privi di dati sensibili e reimmagati al rientro, per le trasferte in giurisdizioni ad alto rischio
• attivare soluzioni di tamper-detection e monitorare eventuali riavvii anomali o modifiche allo stato del disco al rientro
• istruire il personale — giornalisti, ricercatori, dirigenti — sui rischi specifici degli attacchi close access, distinti da quelli più noti di phishing e compromissione di rete

Il caso dimostra che, contro adversary con risorse statali e accesso fisico al territorio, anche l’igiene di sicurezza informatica più rigorosa deve essere affiancata da protocolli di sicurezza operativa (OPSEC) pensati per il mondo fisico.

Indicatori e TTP

Adversary: OVERCAST PANDA (ex cluster ClearVariable), china-nexus, attivo dal 2019
Malware: FlowCloud (impianto principale), LookBack (impianto storico)

TTP osservate:
- T1200 – Hardware Additions (uso di supporto USB rimovibile per boot esterno)
- Bypass del sistema operativo e degli agenti EDR tramite avvio da media esterno
- Scrittura dell'impianto direttamente su disco, fuori dal contesto OS
- Persistenza tramite avvio automatico al riavvio successivo del sistema
- Capacità: keylogging, screenshot capture, file collection, credential theft
- Nessuna attività di rete rilevabile durante la fase di compromissione iniziale

Finestra operativa nota: marzo-maggio 2026
Bersagli: giornalisti, ricercatori/scienziati e altri professionisti stranieri in viaggio in Cina
Contesto di compromissione: laptop incustoditi in stanze d'albergo durante eventi/conferenze
Fonte: CrowdStrike 2026 Threat Hunting Report (pubblicato 3 agosto 2026)