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)