Iran nel cyberspazio: operazioni ibride tra Medio Oriente, infrastrutture OT e Cloud Microsoft 365

L’escalation cyber iraniana del primo trimestre 2026 rivela una strategia a doppio vettore: la compromissione degli ambienti cloud delle organizzazioni israeliane e il sabotaggio di sistemi industriali critici negli Stati Uniti. Un modello operativo che ridefinisce il confine tra guerra cinetica e conflitto digitale.

Quello che emerge dai report pubblicati tra la fine di marzo e i primi giorni di aprile 2026 non è un episodio isolato, ma un pattern operativo strutturato. Check Point Research ha tracciato una campagna di password spraying contro ambienti Microsoft 365 in Medio Oriente, condotta da un threat actor riconducibile all’Iran in tre ondate distinte il 3, il 13 e il 23 marzo 2026, colpendo oltre 300 organizzazioni in Israele e più di 25 negli Emirati Arabi Uniti.

Parallelamente, il joint advisory AA26-097A del 7 aprile 2026, firmato da CISA, FBI, NSA, EPA, Dipartimento dell’Energia e US Cyber Command, ha confermato che attori APT affiliati all’Iran stanno attivamente compromettendo PLC Rockwell Automation/Allen-Bradley esposti su internet nei settori Energy, Water and Wastewater Systems e Government Services negli Stati Uniti, con casi documentati di disruption operativa e perdite finanziarie.

Letti separatamente, i due filoni potrebbero sembrare incidenti scollegati. Analizzati insieme, configurano una strategia ibrida di rara coerenza tattica, coerente con quanto già documentato nei 30 giorni di cyber warfare iraniano seguito al 28 febbraio 2026.

Il vettore cloud: 300 organizzazioni israeliane nel mirino

Secondo l’analisi di Check Point Research, la campagna ha colpito oltre 300 organizzazioni israeliane e più di 25 negli EAU, con attività simile osservata contro target in USA, Europa, Regno Unito e Arabia Saudita. Tra i gruppi iraniani noti per questa tecnica figurano Peach Sandstorm e Gray Sandstorm, entrambi con un’ampia storia documentata di password spraying contro ambienti Microsoft 365.

Sul piano dell’attribuzione è importante mantenere la precisione: Microsoft ha valutato che Peach Sandstorm (APT33) opera per conto dell’Islamic Revolutionary Guard Corps (IRGC). Gray Sandstorm (già DEV-0343) è invece descritto come un cluster che agisce verosimilmente a supporto degli interessi iraniani, senza che nei documenti primari pubblici sia stata confermata un’affiliazione esplicita a una specifica agenzia governativa, distinzione rilevante per chi svolge threat intelligence operativa.

Il settore più colpito in Israele è quello municipale, seguito dalla tecnologia (63 tentativi), dalla logistica e trasporti (32), dalla sanità (28) e dal manifatturiero (28). Check Point valuta con moderata confidenza che il targeting delle municipalità israeliane sia correlato alle città colpite da attacchi missilistici iraniani nel corso di marzo, suggerendo che la campagna sia stata progettata per supportare la valutazione dei danni da bombardamento e le operazioni cinetiche in corso.

Sul piano tecnico, il modus operandi è caratterizzato da una sofisticazione deliberatamente contenuta. Durante la fase di scansione, l’attore ha usato nodi Tor exit con rotazione frequente, inviando richieste con un user agent costruito per simulare Internet Explorer 10 su Windows 7. Una volta ottenute credenziali valide, gli attaccanti si autenticano tramite range IP VPN commerciali di Windscribe (185.191.204.X) e NordVPN (169.150.227.X) geolocalizzati in Israele, aggirando le restrizioni geografiche e riducendo il rischio di alert legati ad accessi stranieri.

Il vettore OT: PLC industriali e sistemi SCADA

Secondo l’advisory CISA AA26-097A, almeno da marzo 2026 un gruppo APT affiliato all’Iran ha disrupted il funzionamento di PLC distribuiti in più settori critici statunitensi, tra cui Government Services and Facilities, Water and Wastewater Systems ed Energy. Alcune vittime hanno subito interruzioni operative e perdite finanziarie. Gli attori hanno usato indirizzi IP esteri per accedere a PLC Rockwell Automation/Allen-Bradley esposti su internet, sfruttando software di configurazione legittimi come Studio 5000 Logix Designer per creare connessioni accettate ai dispositivi target, tra cui CompactLogix e Micro850.

Il traffico malevolo è stato osservato sulle porte 44818, 2222, 102, 22 e 502, associate a protocolli OT di diversi vendor, con implicazioni che si estendono potenzialmente oltre i dispositivi Rockwell, inclusi i sistemi Siemens S7 diffusi in Europa e Asia.

Il metodo di accesso non richiede vulnerabilità zero-day: la debolezza sfruttata è di natura architetturale. Come analizzato da Picus Security in relazione all’advisory, i PLC erano esposti su internet senza adeguata segmentazione di rete, controlli di autenticazione o hardening. Le tre azioni difensive più efficaci non richiedono budget: rimuovere le interfacce ICS da internet, cambiare le credenziali di default e bloccare le porte dei protocolli industriali al perimetro.

In un precedente analogo, il gruppo CyberAv3ngers, affiliato all’IRGC Cyber Electronic Command, aveva già compromesso PLC Unitronics nei sistemi idrici statunitensi nel novembre 2023. La campagna attuale rappresenta un’evoluzione di quel playbook su scala maggiore, con dispositivi più diffusi nelle infrastrutture critiche nordamericane. Rockwell Automation aveva già pubblicato il proprio security advisory SD1771 il 20 marzo 2026, esortando i clienti a disconnettere i controller da internet: una linea guida che si allinea quasi perfettamente al messaggio del joint advisory CISA, suggerendo che la campagna fosse già nota al settore privato prima della divulgazione pubblica.

Il ransomware come arma ibrida

Un terzo livello di questa strategia riguarda l’integrazione del ransomware nelle operazioni statali iraniane. Nel marzo 2026, Halcyon ha rivelato che l’amministratore del ransomware Sicarii ha esortato gli operatori filo-iraniani a usare il Baqiyat 313 Locker (BQTlock), attivo con motivazioni pro-palestinesi contro EAU, USA e Israele dal luglio 2025. Secondo Check Point, “le campagne ransomware stanno sfumando il confine tra estorsione criminale e sabotaggio sponsorizzato dallo Stato.”

A fine febbraio 2026, un’organizzazione sanitaria statunitense è stata colpita da Pay2Key, gruppo ransomware iraniano con legami governativi riconducibile al cluster Fox Kitten (noto anche come Lemon Sandstorm, PARISITE, Pioneer Kitten e UNC757). La variante impiegata presenta capacità di evasione e anti-forensics migliorate rispetto alle campagne del luglio 2025. In questo caso non è stata rilevata esfiltrazione di dati, una deviazione dal classico schema del double extortion che suggerisce come l’obiettivo prioritario fosse la disruption operativa più che il guadagno economico.

La dimensione geopolitica: il cyberspazio come teatro del conflitto

Questa campagna non può essere letta al di fuori del suo contesto. Secondo Recorded Future Insikt Group, il targeting della campagna cloud è correlato alle città colpite da missili iraniani, con le operazioni cyber progettate per supportare la valutazione dei danni da bombardamento e le attività cinetiche in corso. Come abbiamo già documentato nell’analisi di Operation Epic Fury e Roaring Lion, il dominio cyber è diventato il secondo fronte attivo del conflitto sin dal 28 febbraio 2026.

Il dato europeo non è trascurabile. Sia la campagna cloud sia il profilo di targeting OT dell’advisory CISA indicano una superficie d’attacco che supera i confini del Medio Oriente. Il targeting di porte associate a protocolli Siemens, Rockwell e Modbus indica che la minaccia è potenzialmente estesa a qualsiasi sistema OT esposto su internet, inclusi quelli capillarmente diffusi nelle infrastrutture critiche europee.

Il quadro macro è confermato dal World Economic Forum: secondo il Global Cybersecurity Outlook 2026, il 64% delle organizzazioni globali tiene oggi conto degli attacchi cyber motivati geopoliticamente nelle proprie strategie di mitigazione del rischio, mentre il 91% delle organizzazioni di maggiori dimensioni ha modificato la propria strategia di cybersecurity in risposta alla volatilità geopolitica.

Implicazioni per le organizzazioni europee e italiane

Il primo livello di rischio riguarda le aziende che operano in settori esposti a tensioni geopolitiche regionali: energia, difesa, trasporti, finanza. Il pattern di targeting iraniano segue logiche di intelligence strategica, non solo di opportunismo, e le organizzazioni europee che hanno rapporti commerciali o tecnologici con i paesi nel mirino possono diventare vettori secondari di accesso.

Il secondo livello riguarda le infrastrutture OT. In Italia, come negli altri paesi europei, la superficie di attacco sui sistemi industriali rimane ampia. La resilienza IT/OT nell’ambito NIS2 impone requisiti di sicurezza più stringenti per i settori critici, ma il percorso di implementazione è ancora in corso per molte organizzazioni. Il Decreto Legislativo 138 del settembre 2024 ha recepito la direttiva in Italia: la semplicità del vettore OT documentato nell’advisory CISA, che non richiede zero-day ma solo PLC accessibili da internet, dovrebbe essere un campanello d’allarme immediato per qualsiasi responsabile della sicurezza operativa.

Il terzo livello riguarda l’identità cloud. Un attacco di password spraying non necessita di malware avanzato per causare danni: una sola password debole può garantire a un avversario un accesso duraturo a un workspace cloud che il personale utilizza quotidianamente. Il monitoraggio delle identità è diventato importante quanto il monitoraggio degli endpoint per le organizzazioni che dipendono da Microsoft 365.

Le contromisure prioritarie

Per gli ambienti cloud Microsoft 365, le misure raccomandate da Check Point Research includono: monitorare i log di accesso per identificare pattern di password spraying con molteplici tentativi falliti da un’unica sorgente; applicare conditional access con geo-fencing e blocco dei nodi Tor; abilitare l’MFA per tutti gli utenti con controlli più stringenti per i ruoli privilegiati; conservare i log di audit per le investigazioni post-compromissione. Il blocco dei range IP associati a Windscribe e NordVPN già noti in questa campagna rappresenta una misura di contenimento efficace nel breve termine.

Per gli ambienti OT, CISA raccomanda di rimuovere immediatamente i PLC dall’esposizione diretta su internet collocandoli dietro gateway sicuri e firewall; per i dispositivi Rockwell, impostare lo switch fisico del controller in modalità run; verificare nei log la presenza di traffico sospetto sulle porte OT, in particolare proveniente da hosting provider esteri; abilitare SSH Dropbear come indicatore di compromissione, dal momento che è stato impiegato dagli attaccanti per mantenere l’accesso remoto ai sistemi compromessi.

Conclusioni: la guerra ibrida è già presente

La campagna iraniana del primo trimestre 2026 è un caso di studio per l’intero settore. Il suo valore analitico non sta nella sofisticazione tecnica, ma nella coordinazione tra vettori multipli e simultanei (cloud M365, PLC/SCADA, ransomware), nella sua integrazione con operazioni cinetiche in corso e nella capacità di proiettare pressione geopolitica ben oltre il teatro di conflitto originario.

Per i professionisti della sicurezza, questo significa che il threat modeling non può più prescindere dalla dimensione geopolitica. Comprendere chi attacca, perché e in quale contesto internazionale è diventato parte integrante della valutazione del rischio, tanto quanto l’analisi delle vulnerabilità tecniche. Il confine tra IT security e national security non è mai stato così sottile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/iran-cyberspazio-war/




Supply Chain Attack nordcoreano, Contagious Interview prende di mira gli sviluppatori: 1.700 pacchetti malevoli in cinque ecosistemi open source

Un’operazione di supply chain attack attribuita a gruppi hacker nordcoreani ha raggiunto una scala senza precedenti: oltre 1.700 pacchetti malevoli distribuiti contemporaneamente su cinque dei principali registri open source globali, progettati per colpire sviluppatori software in tutto il mondo attraverso strumenti di uso quotidiano. La campagna, denominata Contagious Interview e monitorata dai ricercatori di Socket Security dal 2024, ha compiuto il 7 aprile 2026 un salto qualitativo significativo: per la prima volta, la stessa infrastruttura di staging e gli stessi pattern di distribuzione sono stati replicati in parallelo su npm, PyPI, Go Modules, crates.io e Packagist.

Supply Chain Attack nordcoreano: una fabbrica di pacchetti malevoli a scala industriale

Socket ha documentato che il cluster individuato in questa tornata comprende dodici pacchetti malevoli confermati e due pacchetti “dormienti”, caricati sotto alias GitHub tra cui golangorg, aokisasakidev e aokisasakidev1, con una rete di supporto operante sotto i profili maxcointech1010 e maxcointech0000.

L’elenco completo dei pacchetti identificati per ecosistema, secondo il report del ricercatore Kirill Boychenko di Socket, è il seguente: su npm i pacchetti dev-log-core, logger-base, logkitx, pino-debugger, debug-fmt e debug-glitz; su PyPI i pacchetti logutilkit, apachelicense, fluxhttp e license-utils-kit; nel registro Go i moduli github.com/golangorg/formstash e github.com/aokisasakidev/mit-license-pkg; nel registro Rust il pacchetto logtrace; nel registro PHP Packagist il pacchetto golangorg/logkit.

La scelta dei nomi non è casuale: i pacchetti erano progettati per impersonare strumenti di sviluppo legittimi come debug, debug-logfmt, pino-debug, baraka, license, http, libprettylogger e openlss/func-log, funzionando silenziosamente come malware loader. Questo schema è perfettamente coerente con quanto già documentato da ICT Security Magazine nell’analisi sulla supply chain software e i 454.000 pacchetti malevoli del 2025: la fiducia implicita nei registri pubblici è diventata l’arma più efficiente a disposizione degli attaccanti statali.

Il meccanismo di infezione: loader a due stadi invisibili al momento dell’installazione

Il malware nascosto è progettato in modo da non eseguirsi durante l’installazione del pacchetto, rendendo più difficile il rilevamento da parte degli strumenti di sicurezza tradizionali.

I loader recuperano un downloadUrl dall’infrastruttura controllata dagli attaccanti (in particolare dall’endpoint apachelicense[.]vercel[.]app), riscrivono i link di condivisione di Google Drive in formato di download diretto, scaricano archivi ZIP come ecw_update.zip e consegnano payload di secondo stadio specifici per piattaforma. Questi payload si rivelano essere malware con capacità di infostealer e remote access trojan (RAT), in grado di sottrarre credenziali, portafogli di criptovalute e garantire accesso persistente ai sistemi compromessi.

Il coordinamento cross-ecosistema è l’elemento più significativo: lo stesso cluster ha pubblicato i pacchetti su cinque registri diversi riutilizzando la stessa logica di staging, la stessa infrastruttura e gli stessi pattern di riuso delle persona. Questo indica che gli attaccanti possono continuare a portare lo stesso design di loader in nuovi registri con sole modifiche minori al codice.

Chi c’è dietro Contagious Interview: UNC1069, BlueNoroff e il link con Axios

L’attacco è attribuito a un threat actor a motivazione finanziaria noto come UNC1069, che si sovrappone ai gruppi BlueNoroff, Sapphire Sleet e Stardust Chollima. La Security Alliance (SEAL) ha dichiarato di aver bloccato 164 domini collegati a UNC1069 che impersonavano servizi come Microsoft Teams e Zoom tra il 6 febbraio e il 7 aprile 2026.

UNC1069 opera campagne di social engineering a bassa pressione e multi-settimana su Telegram, LinkedIn e Slack, impersonando contatti noti o brand credibili, o sfruttando accessi ad account aziendali e personali precedentemente compromessi, prima di consegnare un link fraudolento a una riunione Zoom o Microsoft Teams, utilizzato per veicolare lure di tipo ClickFix con conseguente esecuzione di malware su Windows, macOS e Linux.

La campagna si inserisce in un contesto più ampio di attacchi alla supply chain software da parte nordcoreana: tra le operazioni parallele figura anche l’avvelenamento del popolare pacchetto npm Axios per distribuire un impianto chiamato WAVESHAPER.V2, dopo aver preso il controllo dell’account npm del maintainer del pacchetto tramite una campagna di social engineering su misura.

Microsoft ha analizzato in dettaglio la campagna Contagious Interview, confermando come gli attori nordcoreani a motivazione finanziaria stiano evolvendo attivamente il loro toolset e la loro infrastruttura, usando domini che si spacciano per istituzioni finanziarie statunitensi e applicazioni di videoconferenza per il social engineering, con una chiara continuità nel comportamento e nell’intento.

Il modello “factory”: una minaccia sistematica e scalabile

Socket descrive Contagious Interview come una minaccia supply chain che adotta un modello a fabbrica, ben dotata di risorse, prolifica e sistematica, che tratta npm, PyPI e VS Code come canali di accesso iniziale rinnovabili verso ambienti di sviluppo e, sulla base delle indagini attuali, estende lo stesso playbook a Go Modules, crates.io e Packagist. Il totale di oltre 1.700 pacchetti malevoli tracciati è riferito all’attività complessiva della campagna a partire dal gennaio 2025.

Per comprendere la portata strutturale del problema, è utile fare riferimento all’analisi già pubblicata su ICT Security Magazine sull’avvelenamento di LiteLLM e la supply chain Python per sviluppatori AI, che descrive lo stesso schema operativo replicato da TeamPCP su cinque ecosistemi in meno di un mese. Contagious Interview applica la medesima logica su scala ancora più ampia e con risorse statali.

Le implicazioni per le organizzazioni: NIS2 e la responsabilità sulle dipendenze

La campagna Contagious Interview ha conseguenze dirette sul piano della compliance normativa. Come approfondito nell’articolo di ICT Security Magazine sugli ecosistemi digitali sotto attacco, NIS2 e gli SBOM, la NIS2 impone alle organizzazioni in scope di valutare la postura di sicurezza dei fornitori diretti e dei service provider, inclusi i componenti open source integrati nelle pipeline di sviluppo. Un pacchetto npm installato da un developer in un ambiente CI/CD è, a tutti gli effetti, un componente della supply chain soggetto a questa valutazione.

Il Cyber Resilience Act (CRA) europeo, in via di implementazione, introdurrà obblighi specifici per i produttori di software che incorporano componenti open source, rendendo la tracciabilità delle dipendenze tramite Software Bill of Materials (SBOM) non più una raccomandazione ma un requisito operativo verificabile.

Raccomandazioni operative per i team di sviluppo

Socket, che ha segnalato tutti i pacchetti malevoli identificati ai registri interessati e presentato richieste di rimozione per gli account GitHub associati, ha ottenuto la rimozione di logtrace da crates.io (con advisory tracciato come RUSTSEC-2026-0081), il blocco dei moduli Go identificati da parte del Go Security team, e la rimozione dei pacchetti aokisasakidev da npm.

Le raccomandazioni pratiche sono le seguenti: trattare come ad alto rischio i pacchetti di utilità che contattano infrastrutture remote, recuperano un downloadUrl, riscrivono link di cloud storage, scaricano archivi, decodificano contenuti remoti o avviano interpreti da funzioni helper; bloccare le versioni delle dipendenze dirette e transitive, fissando hash specifici nelle pipeline CI/CD; esaminare con attenzione i pacchetti appena pubblicati o con pochi download prima dell’adozione; eseguire i pacchetti sospetti in ambienti sandbox prima che raggiungano workstation di sviluppatori o sistemi CI; verificare i maintainer account tramite autenticazione a due fattori e monitorare i trasferimenti di ownership sui pacchetti critici.

Al momento della pubblicazione del report di Socket, alcuni pacchetti erano già stati rimossi dai registri, ma altri erano ancora attivi. Questo sottolinea la necessità di non affidarsi esclusivamente alle misure di sicurezza dei registry, ma di implementare controlli propri a livello di pipeline.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/supply-chain-attack-nordcorea/




APT28 e la campagna FrostArmada: come il GRU russo ruba credenziali Microsoft senza installare malware

Il gruppo di spionaggio russo APT28, noto anche come Fancy Bear, Forest Blizzard e Storm-2754 e riconducibile all’85° Centro Principale dei Servizi Speciali (GTsSS), Unità militare 26165 del GRU, ha condotto una campagna di cyber-spionaggio su scala globale compromettendo migliaia di router domestici e per piccoli uffici. L’operazione, denominata FrostArmada dai ricercatori di Black Lotus Labs (Lumen Technologies), ha permesso di sottrarre in modo silenzioso credenziali di accesso e token OAuth di Microsoft 365, senza che le vittime ricevessero alcun segnale di allarme tradizionale.

La campagna è stata resa pubblica il 7 aprile 2026 contestualmente all’advisory del National Cyber Security Centre (NCSC) del Regno Unito, nell’ambito di un’operazione internazionale coordinata tra autorità di law enforcement e aziende private.

Il meccanismo: DNS hijacking senza malware

La campagna su larga scala è stata denominata FrostArmada da Black Lotus Labs, con Microsoft che la descrive come uno sforzo per sfruttare dispositivi SOHO vulnerabili allo scopo di dirottare il traffico DNS e abilitare la raccolta passiva di dati di rete.

Sin dal 2024 e fino al 2026, APT28 ha configurato Virtual Private Server (VPS) per operare come server DNS malevoli. Questi VPS ricevevano volumi elevati di richieste DNS originate da router precedentemente compromessi tramite vulnerabilità note. Le impostazioni DHCP/DNS dei dispositivi venivano sovrascritte in modo da includere indirizzi IP controllati dall’attaccante, propagando le nuove configurazioni ai dispositivi della rete interna.

Quando gli utenti richiedevano i domini target, il traffico veniva reindirizzato verso un nodo adversary-in-the-middle (AitM), dove le credenziali venivano raccolte ed esfiltrate. L’unico segnale visibile per l’utente finale sarebbe stato un avviso per certificato TLS non valido.

I target del gruppo APT28 e la portata dell’operazione FrostArmada

L’attività risulta iniziata in forma limitata già a partire da maggio 2025, con una fase di compromissione su larga scala avviata da agosto. Al picco, nel dicembre 2025, oltre 18.000 indirizzi IP unici provenienti da almeno 120 paesi comunicavano con l’infrastruttura di APT28. I target primari includevano agenzie governative, ministeri degli affari esteri, forze dell’ordine e provider email e cloud di terze parti distribuiti in Africa settentrionale, America centrale, Sud-Est asiatico ed Europa.

Microsoft ha rilevato oltre 200 organizzazioni e 5.000 dispositivi consumer impattati dall’infrastruttura DNS malevola di Forest Blizzard, precisando che la telemetria non ha indicato compromissioni di asset o servizi di proprietà Microsoft.

Le operazioni di DNS hijacking sono state valutate come opportunistiche: APT28 ha preso di mira un ampio bacino di vittime, filtrando progressivamente i risultati per individuare utenti di potenziale interesse sotto il profilo dell’intelligence.

La vulnerabilità sfruttata

Uno dei modelli router sfruttati da APT28 è il TP-Link WR841N, presumibilmente attraverso la CVE-2023-50224, una vulnerabilità che consente a un attaccante non autenticato di ottenere credenziali memorizzate tramite richieste HTTP GET appositamente predisposte. Una volta ottenute le credenziali del router, l’attore inviava una seconda richiesta HTTP GET per modificare le impostazioni DNS DHCP del dispositivo, impostando il server DNS primario su un indirizzo IP malevolo e mantenendo il server secondario originale come fallback.

L’operazione di smantellamento

L’FBI ha condotto un’operazione tecnica autorizzata dall’autorità giudiziaria per mettere in sicurezza i router compromessi, rimuovendo i resolver di APT28 tramite DNS reset e ripristinando la connessione a resolver legittimi forniti dagli ISP. I comandi inviati ai router hanno anche permesso all’FBI di raccogliere prove sull’attività del gruppo. Per garantire che l’operazione non alterasse le funzionalità ordinarie dei dispositivi né raccogliesse dati degli utenti, il governo ha condotto test estensivi su firmware e hardware dei router TP-Link interessati.

Il DoJ ha precisato che gli utenti possono rimuovere eventuali modifiche residue eseguendo un ripristino alle impostazioni di fabbrica.

Il contesto geopolitico

APT28 è lo stesso gruppo responsabile della violazione del Comitato Nazionale Democratico statunitense nel 2016. L’NCSC ha precedentemente attribuito ad APT28 gli attacchi informatici al Bundestag tedesco nel 2015, che hanno incluso furto di dati e la compromissione degli account email di parlamentari e del Vice Cancelliere, nonché il tentato attacco all’Organizzazione per la Proibizione delle Armi Chimiche (OPCW) nell’aprile 2018, finalizzato a ostacolare le analisi indipendenti sulle armi chimiche impiegate dal GRU nel Regno Unito.

Le implicazioni: perché questo attacco è diverso

La campagna FrostArmada introduce un cambio di paradigma importante nella threat intelligence: il compromesso avviene a livello di infrastruttura di rete, non di endpoint. Non esiste un payload da rilevare, nessun processo anomalo da monitorare, nessun comportamento sospetto sul dispositivo dell’utente finale. L’attacco è invisibile agli strumenti EDR tradizionali e ai controlli di sicurezza perimetrali che non analizzano il traffico DNS in uscita.

Microsoft ha osservato che APT28 potrebbe sfruttare la posizione AitM acquisita per obiettivi aggiuntivi, tra cui attacchi denial of service e il deployment di malware.

Raccomandazioni operative

L’advisory NCSC fornisce indicazioni concrete per ridurre la superficie di attacco, riprese anche da Bleeping Computer con dettagli sull’operazione tecnica di smantellamento:

Sostituire i router che non ricevono più aggiornamenti di sicurezza dal produttore; mantenere il firmware sempre aggiornato all’ultima versione disponibile; non esporre le interfacce di gestione dei router su Internet; abilitare l’autenticazione a più fattori (MFA) su tutti gli account potenzialmente esposti a credential theft; monitorare le impostazioni DNS dei dispositivi di rete per rilevare modifiche non autorizzate; formare gli utenti a non ignorare gli avvisi relativi a certificati TLS non validi.

Il caso FrostArmada è un promemoria significativo del fatto che la sicurezza informatica aziendale non può prescindere dalla protezione dell’infrastruttura di rete di base, compresi i dispositivi SOHO sempre più presenti negli ambienti di lavoro ibrido e negli uffici periferici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/apt28-frostarmada-microsoft/




LinkedIn come arma: dal phishing allo spionaggio di Stato

LinkedIn è oggi molto più di una piattaforma professionale. Per criminali comuni, gruppi APT e agenzie di intelligence straniere è diventata uno degli strumenti offensivi più versatili e difficili da contrastare nel panorama della cybersecurity. La ragione è strutturale: la piattaforma aggrega oltre un miliardo di profili autenticati, dati professionali pubblici, relazioni fiduciarie consolidate e accesso diretto a figure ad alto valore. Tutto questo avviene in un ambiente che la maggior parte delle organizzazioni non monitora con la stessa attenzione riservata alla posta elettronica.

Quello che segue è un censimento ragionato delle tecniche malevole documentate da ricercatori di sicurezza nell’ultimo anno, organizzato per livello di sofisticazione e natura dell’attore.

  1. Phishing via notifiche false: l’esca del recruiter

L’attacco più diffuso e recente è anche quello strutturalmente più insidioso nella sua semplicità. Il 31 marzo 2026, il team Cofense Phishing Defense Center ha pubblicato l’analisi di una campagna attiva in cui gli attaccanti inviano email che replicano con precisione le notifiche ufficiali di LinkedIn. Font, logo, formattazione e oggetto del messaggio sono identici agli originali. Il pretesto è una fantomatica opportunità di lavoro: un messaggio da un presunto recruiter di un’azienda reputabile, con invito urgente a rispondere.

Cliccando, l’utente non raggiunge LinkedIn, ma una pagina di login contraffatta. Il dominio impiegato nella campagna osservata era inedin[.]digital, scelto perché a una lettura rapida si confonde con il dominio legittimo. L’indirizzo email del mittente, khanieteam[.]com, è anch’esso fraudolento, attivo da pochi giorni al momento dell’analisi. I campioni osservati da Cofense erano scritti in lingua cinese e tradotti dai ricercatori.

Enrico Silverio, threat researcher al Cofense Phishing Defense Center, definisce questa campagna come «un promemoria che gli attori delle minacce continuano a evolversi in sofisticazione tecnica e persistenza, elaborando schemi altamente convincenti per sfruttare la fiducia e la curiosità umana».

L’urgenza, in questo contesto, non è un dettaglio: è la leva psicologica centrale. Silverio ricorda inoltre che gli attaccanti «pulled individuals’ home addresses, generated Google Maps screenshots, and inserted them into extortion emails to increase credibility», a conferma di quanto le campagne siano diventate personalizzate e difficili da riconoscere. Il tema dell’abuso di LinkedIn per la distribuzione di malware è approfondito nell’analisi pubblicata su ICT Security Magazine dedicata al malware veicolato tramite LinkedIn, che illustra le tecniche utilizzate dai gruppi APT per compromettere i reclutatori stessi.

  1. Phishing via commenti pubblici: la moderazione come pretesto

Una variante documentata a gennaio 2026 da Cybernews e Security Magazine sfrutta i commenti pubblici della piattaforma invece delle email. Account bot si spacciano per LinkedIn stessa, pubblicando commenti sotto i post degli utenti in cui si afferma che il profilo è stato temporaneamente ristretto per violazioni delle policy. Il messaggio invita a cliccare un link per presentare ricorso, spesso utilizzando il legittimo shortener lnkd.in di LinkedIn per mascherare la destinazione.

Chance Caldwell, Senior Director del Phishing Defense Center di Cofense, descrive questa tecnica come una «troubling evolution in social engineering tactics», in cui gli attaccanti si integrano direttamente in spazi digitali considerati affidabili e sfruttano la fiducia degli utenti mimando comunicazioni legittime. Max Gannon, Cyber Intelligence Team Manager di Cofense, sottolinea che la corretta applicazione dell’AI ha reso possibile creare a scala account che impersonano LinkedIn stesso, una soglia operativa un tempo impraticabile.

Il fattore AI è determinante: l’automazione consente di inondare le sezioni commenti a una velocità che supera ampiamente la capacità di moderazione manuale della piattaforma. LinkedIn ha confermato di essere a conoscenza della campagna, precisando che non comunica mai violazioni di policy attraverso commenti pubblici.

  1. Messaggi diretti con RAT: quando il DM diventa un vettore di intrusione

La terza tecnica è significativamente più sofisticata ed è stata documentata da ReliaQuest a gennaio 2026 in una campagna mirata a executive aziendali e amministratori IT. Il vettore non è l’email, ma il messaggio diretto su LinkedIn, a riprova che il phishing si è ormai emancipato dall’inbox.

L’attacco inizia con un DM che indirizza la vittima al download di un archivio auto-estraente WinRAR (SFX). Una volta aperto, l’archivio decomprime quattro componenti: un PDF reader legittimo open source, una DLL malevola mascherata con lo stesso nome di un file benigno usato dal PDF reader, un interprete Python portable e un file RAR utilizzato come esca per far apparire la cartella legittima. I nomi dei file sono personalizzati in base al ruolo o settore della vittima, con titoli come Upcoming_Products.pdf o Project_Execution_Plan.exe, per aumentare le probabilità che vengano aperti.

La tecnica impiegata è il DLL sideloading: il PDF reader carica automaticamente la DLL malevola al momento dell’esecuzione, eludendo l’endpoint security. Il malware installa poi una chiave Run nel registro di sistema per garantirsi persistenza a ogni avvio, esegue uno strumento di hacking open-source offuscato in Base64 direttamente in memoria (senza scrivere file su disco) e tenta ripetutamente di connettersi a un server di comando e controllo (C2). Il comportamento è compatibile con il deploy di un Remote Access Trojan per accesso persistente e furto di dati.

Come rileva The Hacker News nell’analisi della campagna, ReliaQuest sottolinea un problema strutturale: quando un account viene segnalato su LinkedIn, non è possibile vedere quali altri utenti dell’organizzazione siano stati colpiti dallo stesso messaggio. A differenza dell’email, non esiste modo di richiamare o mettere in quarantena il messaggio già inviato. Non ci sono regole modificabili né mittenti bloccabili. Si può segnalare l’account, ma probabilmente l’attaccante ha già ottenuto ciò che cercava.

  1. AiTM con redirect chain su servizi legittimi: eludere ogni filtro

La campagna più tecnicamente avanzata tra quelle di matrice criminalizzata è stata intercettata e analizzata da Push Security tra ottobre e novembre 2025. La vittima riceveva un link via DM LinkedIn relativo a una falsa opportunità di investimento: un invito a entrare nel consiglio di amministrazione di un fondo chiamato “Common Wealth”, presentato come un’iniziativa in Sud America in partnership con una fantomatica entità denominata AMCO.

Dopo aver cliccato, l’utente veniva reindirizzato tre volte (attraverso un open redirect di Google, poi a un dominio intermedio) prima di raggiungere una landing page personalizzata che imitava un portale di condivisione documenti, ospitata su firebasestorage.googleapis.com di Google. Come annunciato dalla press release ufficiale di Push Security del 30 ottobre 2025, la catena di redirect sfruttava servizi cloud legittimi (Google, Firebase, Microsoft Dynamics) per mascherare la destinazione dei link malevoli.

Gli attaccanti hanno impiegato Cloudflare Turnstile come protezione anti-bot per impedire l’analisi automatizzata delle pagine di phishing, e tecniche di offuscamento del codice per eludere i filtri basati su reputazione dei domini. La pagina finale era un sito Microsoft contraffatto di tipo AiTM (Adversary-in-the-Middle), progettato per intercettare le sessioni e bypassare l’autenticazione multifattore. Nessun gateway email, nessun URL scanner, nessuna threat intelligence feed avrebbe potuto rilevarlo: l’attacco viveva interamente nel browser dell’utente. Come riportato da BleepingComputer nella copertura originale della campagna, tra i domini malevoli impiegati figuravano boardproposalmeet[.]com e sqexclusiveboarddirect[.]icu.

  1. Lazarus Group: LinkedIn come piattaforma per finanziare il regime nordcoreano

Il livello più preoccupante di abuso di LinkedIn è quello state-sponsored. Il gruppo Lazarus, la principale unità cyber della Corea del Nord, utilizza la piattaforma come vettore primario di attacchi con obiettivi duplici: spionaggio industriale e furto di criptovalute per finanziare il programma nucleare di Pyongyang.

La campagna denominata “graphalgo”, attiva dall’inizio di maggio 2025 e analizzata da ReversingLabs nel febbraio 2026, vedeva sviluppatori avvicinati su LinkedIn, Facebook e Reddit con offerte di lavoro false nel settore blockchain e crypto, da parte di una società fittizia denominata Veltrix Capital (dominio veltrixcap[.]org, registrato ad aprile 2025). Come riportato da The Hacker News, ai candidati veniva chiesto di dimostrare le proprie competenze eseguendo un progetto che conteneva, tra le dipendenze, pacchetti malevoli pubblicati su npm e PyPI. Il pacchetto bigmathutils aveva superato le 10.000 installazioni nella versione pulita prima che venisse rilasciata la versione contenente il payload malevolo: una pazienza tattica che permette di accumulare fiducia prima di colpire.

Il malware deployato era un RAT cross-platform (in JavaScript, Python e VBScript) capace di enumerare processi, esfiltrare file, eseguire comandi arbitrari e controllare la presenza dell’estensione MetaMask nel browser per individuare wallet di criptovaluta. Parallelamente, la campagna Contagious Interview vedeva Lazarus impersonare reclutatori di aziende reali (inclusa Fireblocks stessa) per condurre finti colloqui tecnici durante i quali i candidati venivano istruiti a clonare repository GitHub e installare pacchetti npm che innescavano l’infezione.

Il CEO di Fireblocks, Michael Shaulov, che ha lavorato con LinkedIn e le forze dell’ordine per rimuovere quasi una dozzina di profili fake legati alla campagna, ha descritto l’evoluzione degli attaccanti nordcoreani a CNBC: «Nel 2017 e 2018 era relativamente facile identificarli per gli errori grammaticali. Ora sembrerebbe che si siano laureati a Oxford». L’accelerazione è attribuita direttamente all’AI: «It’s clear that the attackers have become way more sophisticated and way harder to detect because of AI».

  1. Spionaggio di Stato: la Cina e i falsi recruiter contro NATO e UE

Il 28 marzo 2026, una fonte di sicurezza europea ha confermato ad AFP quello che i servizi di intelligence occidentali sospettavano da anni: la Cina ha utilizzato profili falsi su LinkedIn per raccogliere informazioni sensibili da dipendenti di istituzioni NATO e dell’Unione Europea. L’operazione, attribuita al Ministero per la Sicurezza dello Stato cinese (MSS), ha preso di mira decine di funzionari attraverso account fittizi che si presentavano come recruiter.

Uno dei profili più attivi utilizzava il nome “Kevin Zhang”, presentandosi come responsabile di una fittizia società di Hong Kong chiamata “Oriental Consulting”. I recruiter iniziavano richiedendo report a pagamento su temi geopolitici, per poi sollecitare informazioni non pubbliche o classificate. I funzionari di Francia, Belgio e Regno Unito reclutati ricevevano compensi da poche centinaia a diverse migliaia di dollari. Gli argomenti di maggiore interesse includevano le sanzioni UE contro la Cina e la strategia NATO in Asia, in particolare riguardo a Taiwan.

La ministra belga della Giustizia Annelies Verlinden ha dichiarato ad AFP che attraverso questa operazione «a great deal of important information and intelligence may have reached China», aggiungendo che internet è diventato un terreno fertile per le grandi potenze che cercano di reclutare agenti.

Non si tratta di un caso isolato. L’utilizzo di LinkedIn da parte del MSS cinese è documentato almeno dal 2014: nel 2023, l’ex capo dell’intelligence estera francese ha rivelato che Beijing avrebbe già avviato in quell’anno un’operazione massiva di spionaggio tramite social media. Nel dicembre 2017, il BfV tedesco aveva individuato oltre 10.000 cittadini tedeschi contattati da profili falsi che prendevano di mira politici e dirigenti aziendali. A novembre 2025, MI5 ha identificato due profili LinkedIn: Amanda Qiu (BR-YR Executive Search) e Shirly Shen (Internship Union), entrambe operative del MSS impegnate a costruire relazioni con parlamentari britannici.

L’agenzia ha avvertito che i profili falsi cinesi ricorrono frequentemente all’archetipo di una giovane donna con nome anglicizzato. Le implicazioni di questa campagna per le istituzioni europee sono discusse anche nell’analisi sullo spionaggio digitale nell’era dell’intelligenza artificiale pubblicata su ICT Security Magazine, che contestualizza le operazioni del MSS nel quadro più ampio della competizione geopolitica per il controllo dell’informazione.

Il problema strutturale: un blind spot nelle difese aziendali

Distribuendo payload malevoli attraverso LinkedIn e altre piattaforme social, gli attaccanti sfruttano sistematicamente i punti ciechi nelle protezioni di cybersecurity delle organizzazioni, che spesso non coprono questi canali con la stessa attenzione riservata alla posta elettronica. Secondo Push Security, il 34% degli attacchi di phishing intercettati nell’ultimo periodo è arrivato attraverso canali non-email, tra cui social media, app di messaggistica, inserzioni pubblicitarie malevole e comunicazioni in-app. Come rilevato nel report di Push Security sul phishing 2025, LinkedIn DM e Google Search rappresentano i due canali non-email più sfruttati dagli attaccanti.

Il paradosso è che LinkedIn, proprio perché è una piattaforma percepita come affidabile e professionale, abbassa strutturalmente la soglia di guardia degli utenti. Nessuno si aspetta di essere attaccato su una piattaforma dove si gestiscono relazioni lavorative verificate. Ed è esattamente questa aspettativa che gli attaccanti, dai gruppi criminali agli APT statali, hanno imparato a monetizzare.

Raccomandazioni operative

Per i team di sicurezza aziendali, le evidenze raccolte suggeriscono di integrare nelle policy di sicurezza e nei programmi di security awareness training moduli specifici dedicati alle minacce su piattaforme social. È necessario trattare qualsiasi link o archivio ricevuto via LinkedIn DM con la stessa cautela riservata agli allegati email sospetti, non aprire mai archivi SFX o eseguibili condivisi durante processi di selezione senza verifica indipendente dell’identità del mittente, e verificare sempre l’URL del mittente nelle notifiche LinkedIn prima di cliccare. Va ricordato, infine, che LinkedIn non comunica mai restrizioni di account attraverso commenti pubblici o link in email non sollecitate.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/linkedin-cybercrime/




Cyber-guerra Iran-USA-Israele: operazione Epic Fury e Roaring Lion, il più grande attacco informatico della storia

La cyber-guerra Iran-USA-Israele che si è aperta il 28 febbraio 2026 non è un’escalation come le altre. È il primo conflitto su larga scala in cui le operazioni cibernetiche hanno preceduto, accompagnato e amplificato quelle cinetiche in modo strutturale e documentato. L’Operazione Epic Fury (denominazione statunitense) e l’Operazione Roaring Lion (denominazione israeliana) hanno colpito oltre 1.250 obiettivi militari iraniani nelle prime 48 ore. Ma prima che un singolo missile lasciasse il tubo di lancio, lo U.S. Cyber Command era già il first mover: le operazioni cyber hanno aperto la strada a tutto il resto.

Il risultato è stato la dimostrazione più eclatante nella storia della cybersecurity di cosa significhi cyber dominance, e di quanto sia fragile il confine tra pace e guerra nel dominio digitale.

Un’operazione cyber senza precedenti

Le quattro ore che hanno cambiato la dottrina militare

Secondo l’analisi pubblicata da Lawfare, il nucleo dell’offensiva cyber si è consumato in circa quattro ore, prima che il regime iraniano imponesse il blackout totale di internet. In quella finestra temporale, la coalizione ha ottenuto risultati straordinari.

Il generale Dan Caine, presidente dei Joint Chiefs of Staff, ha dichiarato in conferenza stampa che le operazioni spaziali e cyber coordinate hanno effettivamente interrotto le comunicazioni e le reti sensoriali iraniane, privando l’avversario della capacità di osservare, coordinare e rispondere. L’obiettivo dichiarato era disorientare e confondere il nemico.

Ciò che emerge dal reporting di fonti multiple – Financial Times, Unit 42, CSIS – è un’operazione a strati multipli che ha colpito simultaneamente diversi livelli dell’infrastruttura iraniana.

Livello 1 – Infrastruttura di rete. La connettività internet iraniana è crollata tra l’1 e il 4% dei livelli normali la mattina del 28 febbraio 2026, secondo le rilevazioni di Unit 42. L’attacco ha interessato routing BGP, infrastruttura DNS e sistemi SCADA/ICS, come documentato da AttackIQ. Non si è trattato di un semplice DDoS: è stata un’operazione multi-vettore progettata per isolare il Paese dal resto del mondo digitale.

Livello 2 – Intelligence e sorveglianza. Il Financial Times ha rivelato che l’intelligence israeliana monitorava da anni la rete di telecamere stradali di Teheran, utilizzandola per tracciare i movimenti delle guardie del corpo di Khamenei e di altri alti funzionari. Un’operazione cyber parallela ha interrotto il sistema di telefonia mobile nell’area del compound di Khamenei, impedendo al suo staff di sicurezza di ricevere avvertimenti sull’attacco imminente. Questa capacità, come ha sottolineato l’analisi di Lawfare, è il risultato di anni di costruzione di un’architettura di intelligence comprensiva focalizzata su Teheran, basata su SIGINT, cyber espionage e HUMINT.

Livello 3 – Operazioni informative. L’app religiosa iraniana BadeSaba, con oltre 5 milioni di download, è stata compromessa per inviare messaggi di propaganda direttamente ai cittadini e al personale militare. Il primo messaggio recitava: “L’aiuto è arrivato.” Un secondo era indirizzato specificamente al personale delle forze armate, invitandolo a deporre le armi o unirsi alle forze di liberazione. Come ha osservato su X lo specialista iraniano Hamid Kashfi, l’app è estremamente popolare e richiede l’accesso alla geolocalizzazione dell’utente per fornire orari di preghiera accurati. La compromissione aveva quindi un doppio valore: intelligence sulla posizione di milioni di utenti e operazione psicologica in tempo reale.

Livello 4 – Disruption dei media e del C2. L’agenzia di stampa statale iraniana IRNA e diversi siti governativi sono stati compromessi tramite hijacking. Le comunicazioni di comando e controllo dell’IRGC sono state interrotte durante le ore critiche di apertura dell’operazione, secondo il reporting di AttackIQ.

Il paradosso della finestra temporale

L’analisi di Lawfare evidenzia un paradosso fondamentale: più l’operazione cyber è efficace, più breve è la sua finestra di utilità. Circa quattro ore dopo l’inizio degli attacchi, il regime iraniano ha imposto un blackout internet a livello nazionale – una risposta che l’Iran adotta abitualmente anche durante il dissenso interno. Il blackout ha eliminato simultaneamente sia le capacità offensive della coalizione nel cyberspazio sia quelle degli stessi apparati statali iraniani.

Questo produce una lezione dottrinale di enorme importanza per i pianificatori militari e i professionisti della cybersecurity: la cyber dominance è un asset a tempo determinato. Una volta impiegata, il suo effetto si consuma rapidamente – ma nei conflitti moderni, quelle prime ore possono determinare l’esito dell’intera campagna.

Il confronto con il precedente ucraino

Il parallelo più immediato è con l’invasione russa dell’Ucraina nel febbraio 2022, quando l’attacco al sistema satellitare Viasat e i wiper malware (HermeticWiper, IsaacWiper, CaddyWiper) accompagnarono le prime ore dell’offensiva cinetica. Tuttavia, la scala dell’operazione contro l’Iran segna un salto qualitativo significativo.

In Ucraina, le operazioni cyber russe ebbero un impatto limitato sulla connettività complessiva del Paese e non impedirono alla leadership ucraina di comunicare e coordinare la difesa.

In Iran, la connettività nazionale è stata ridotta all’1-4% in poche ore – un livello di disruption che non ha precedenti in conflitti tra Stati. Inoltre, la compromissione di app consumer (BadeSaba), reti di telecamere urbane e sistemi di telefonia mobile in un’unica operazione integrata dimostra un livello di preparazione e di penetrazione dell’infrastruttura avversaria che va ben oltre quanto osservato nel teatro ucraino.

La risposta: 60 gruppi hacktivisti, il fronte cyber si allarga

L’Electronic Operations Room e la coalizione delle sigle

La reazione nel dominio cyber non si è fatta attendere. Secondo Unit 42, al 2 marzo 2026 erano attivi circa 60 gruppi hacktivisti, inclusi collettivi pro-russi che si sono uniti al fronte. Il 28 febbraio stesso è stata costituita una struttura di coordinamento denominata Electronic Operations Room.

Un’analisi di Rescana ha documentato, tra il 28 febbraio e il 2 marzo 2026, ben 149 attacchi DDoS hacktivisti che hanno colpito 110 organizzazioni in 16 Paesi. La maggioranza degli attacchi si è concentrata in Kuwait (28%), Israele (27,1%) e Giordania (21,5%), con il settore governativo che ha rappresentato quasi il 48% degli obiettivi.

Tra i gruppi più attivi identificati da Unit 42, SOCRadar e CloudSEK:

  • Handala Hack – collegato al Ministero dell’Intelligence iraniano (MOIS), è la persona più prominente nel panorama hacktivista iraniano. Ha rivendicato compromissioni di aziende energetiche israeliane, dei sistemi di distribuzione carburante giordani, e ha minacciato funzionari israeliani con doxxing e minacce di morte, segnalando uno sconfinamento verso l’intimidazione psicologica e fisica.
  • FAD Team (Fatimiyoun Cyber Team) – ha rivendicato l’accesso non autorizzato a sistemi SCADA/PLC in Israele e in altri Paesi, inclusi sistemi di controllo di oltre 24 dispositivi appartenenti a una società di servizi di sicurezza israeliana. Il gruppo si concentra su wiper malware e distruzione permanente dei dati.
  • Dark Storm Team – collettivo pro-palestiniano e pro-iraniano specializzato in DDoS su larga scala, che ha colpito istituzioni finanziarie e siti web israeliani.
  • Keymous+ e DieNet – responsabili di quasi il 70% dell’intera attività di attacco DDoS documentata nei primi giorni del conflitto, secondo i dati di Radware.
  • Gruppi pro-russi come NoName057(16) e Z-Pentest – quest’ultimo ha rivendicato, tra il 28 febbraio e il 2 marzo, la compromissione di diverse entità statunitensi, inclusi sistemi ICS/SCADA e reti CCTV.

Una nota di cautela è doverosa: molte di queste rivendicazioni vanno valutate con scetticismo critico. L’analisi di Symantec ha riscontrato che alcune rivendicazioni di alto profilo – come il presunto attacco di Handala a Saudi Aramco – si basavano su documenti già in circolazione, suggerendo operazioni informative o psicologiche più che compromissioni reali. Anche Sophos ha sottolineato che i gruppi iraniani hanno talvolta sovrastimato le proprie capacità, pur rimanendo attori capaci. La distinzione tra DDoS temporaneo, defacement, esfiltrazione reale di dati e compromissione profonda di infrastrutture è fondamentale per calibrare correttamente la risposta difensiva.

Oltre il DDoS: wiper, ransomware e targeting ICS/OT

La cyber-guerra Iran-USA-Israele non si limita ai DDoS. Flashpoint ha identificato una massiccia campagna #OpIsrael che coinvolge attori pro-russi e pro-iraniani nella quale i sistemi di controllo industriale israeliani sono stati presi di mira direttamente. Il Fatimiyoun Electronic Team, secondo il Washington Institute, starebbe conducendo attacchi contro aziende energetiche e finanziarie occidentali con l’obiettivo di dispiegare wiper malware.

Una campagna di phishing particolarmente insidiosa ha distribuito l’APK malevolo RedAlert, mascherato da applicazione ufficiale di allerta emergenza, progettato per la sorveglianza e l’esfiltrazione di dati dai dispositivi mobili.

La pre-posizione: MuddyWater era già dentro

Seedworm nelle reti statunitensi

Uno degli sviluppi più significativi per comprendere la dimensione strategica di questa cyber-guerra è la scoperta, pubblicata il 5 marzo 2026 dal team Symantec e Carbon Black Threat Hunter di Broadcom, che il gruppo APT iraniano MuddyWater (noto anche come Seedworm) era attivo nelle reti di diverse organizzazioni statunitensi sin dall’inizio di febbraio 2026 – settimane prima dell’inizio delle operazioni cinetiche.

Le vittime includono una banca statunitense, un aeroporto, organizzazioni non governative negli USA e in Canada, e le operazioni israeliane di una società software fornitrice dell’industria della difesa e aerospaziale. I ricercatori hanno identificato un backdoor fino ad allora sconosciuto, denominato Dindoor, basato sul runtime Deno per l’esecuzione di codice JavaScript e TypeScript, firmato digitalmente con un certificato intestato a “Amy Cherne”. Un secondo backdoor Python, Fakeset, è stato trovato sulle reti dell’aeroporto e dell’ONG, firmato con certificati legati a Seedworm.

Come ha commentato Denis Calderone, CTO di Suzu Labs, all’outlet SC Media: la guerra cyber non è iniziata quando le bombe hanno cominciato a cadere. Era già in corso a febbraio. Il fatto che MuddyWater disponesse di tooling nuovo e operativo prima dell’inizio del conflitto cinetico rivela il livello di preparazione del gruppo.

Ulteriore conferma è arrivata dal collettivo di threat intelligence indipendente Ctrl-Alt-Intel, che ha ottenuto accesso a un’infrastruttura di MuddyWater ospitata nei Paesi Bassi, scoprendo un vasto arsenale di framework C2 personalizzati, script, log e dati delle vittime, con l’exploitation di oltre una dozzina di CVE, incluse vulnerabilità SQL injection precedentemente sconosciute, come riportato da Help Net Security.

Pyroxene, Bauxite, Parisite: la pipeline verso l’OT

L’analisi di HSToday mette in evidenza tre gruppi iraniani che operano lungo una kill chain strutturata verso gli ambienti di Operational Technology (OT):

  • Pyroxene (allineato all’IRGC, sovrapposizione con UNC1549 secondo Mandiant) – sta conducendo operazioni di mapping nella kill chain ICS di Stage 2 all’interno delle reti di fornitori e contractor nei settori difesa, aviazione ed energia, utilizzando tenant Microsoft Azure vittima-specifici come infrastruttura C2.
  • Bauxite (operante sotto la persona CyberAv3ngers) – ha già superato la fase dell’accesso per raggiungere gli effetti: avrebbe compromesso oltre 400 dispositivi OT tramite il malware IOControl, secondo fonti di settore, manipolando PLC Unitronics presso impianti idrici statunitensi. Il CISA aveva già emesso un advisory dedicato alle attività di CyberAv3ngers contro dispositivi Unitronics nel dicembre 2023, confermando il pattern di targeting ICS da parte di questo gruppo.
  • Parisite (noto come Pioneer Kitten/Fox Kitten) – funziona come Initial Access Broker per questo ecosistema, sfruttando VPN esposte e dispositivi edge per compromettere ambienti IT di operatori di infrastrutture critiche, per poi vendere o trasferire l’accesso ad attori statali e affiliati ransomware. Dragos ha osservato direttamente Parisite fornire accessi successivamente utilizzati in operazioni dirette verso ambienti OT.

Il punto cruciale: il seam IT-to-OT non è una vulnerabilità teorica. È un percorso di exploitation attivo e documentato.

Le TTP iraniane nel framework MITRE ATT&CK

Per i SOC analyst e i threat hunter, è utile mappare le tecniche osservate nel conflitto corrente sul framework MITRE ATT&CK. Le TTP dominanti degli APT iraniani attivi in questa fase includono:

  • T1566 – Phishing e T1566.001 – Spearphishing Attachment: vettore iniziale privilegiato da MuddyWater (campagna Dindoor) e APT42, con documenti Office armati e campagne RedAlert APK.
  • T1078 – Valid Accounts: sfruttamento di credenziali legittime rubate, tecnica cardine per Parisite/Fox Kitten nell’accesso iniziale a reti di infrastrutture critiche.
  • T1190 – Exploit Public-Facing Application: exploitation di VPN, dispositivi edge e applicazioni esposte, documentata sia per Parisite che per MuddyWater.
  • T1059.007 – Command and Scripting Interpreter: JavaScript: il backdoor Dindoor utilizza il runtime Deno per eseguire comandi, una scelta tecnica insolita che indica evoluzione del tooling.
  • T1071.001 – Application Layer Protocol: Web Protocols: utilizzo di servizi cloud legittimi (Azure, Wasabi, Backblaze) come infrastruttura C2, rendendo il traffico malevolo indistinguibile da quello aziendale.
  • T1567 – Exfiltration Over Web Service: tentativo di esfiltrazione verso bucket Wasabi Technologies tramite Rclone, osservato nella campagna contro la società software.
  • T0831 – Manipulation of Control (ICS): la manipolazione dei PLC Unitronics da parte di Bauxite/CyberAv3ngers rappresenta un’operazione ICS di Stage 2 nella kill chain Dragos/SANS.

Questo mapping non è esaustivo, ma fornisce ai team difensivi un riferimento immediato per verificare la copertura delle proprie detection rule rispetto alle tecniche più attive in questo specifico contesto di minaccia.

Le lezioni operative per i CISO

Sei azioni immediate

La combinazione delle raccomandazioni di Unit 42, HSToday, eSentire e delle analisi di settore converge su sei azioni prioritarie.

  1. Isolare i dispositivi OT esposti a internet. In particolare PLC Unitronics e qualsiasi dispositivo ICS accessibile dall’esterno. La campagna di Bauxite/CyberAv3ngers ha dimostrato che gli attaccanti iraniani hanno già la capacità e la volontà di manipolare sistemi di controllo industriale.
  2. Auditare e terminare le sessioni VPN di contractor inutilizzate. Parisite/Fox Kitten opera esattamente come un Initial Access Broker, sfruttando VPN e dispositivi edge di fornitori nei settori difesa, aviazione ed energia. Ogni sessione VPN non terminata di un contractor è una porta aperta.
  3. Abilitare alerting sulle anomalie nelle API cloud. Pyroxene utilizza tenant Azure vittima-specifici come C2. Il monitoraggio delle chiamate API verso servizi cloud come Azure, AWS e GCP, in particolare quelle che attraversano il confine IT-OT, è fondamentale.
  4. Conservare almeno una copia dei dati critici in modalità air-gapped. Il wiper malware è lo strumento privilegiato delle operazioni distruttive iraniane – dalla campagna contro l’Albania nel 2022 alle attuali minacce del FAD Team.
  5. Implementare il blocco geografico degli IP dove possibile. Questo non è sufficiente di per sé – gli attaccanti utilizzano proxy e VPN – ma riduce la superficie d’attacco per gli strumenti automatizzati a bassa sofisticazione che rappresentano la maggioranza del volume.
  6. Preparare un piano di comunicazione per la gestione delle rivendicazioni. Come sottolinea Unit 42, i gruppi hacktivisti spesso esagerano la portata dei loro attacchi. Avere una procedura per validare e rispondere alle rivendicazioni – distinguendo tra accesso effettivo e compromissione di sistema – è fondamentale per evitare il panico e il danno reputazionale.

La domanda scomoda sull’OT

La lezione più profonda di questa cyber-guerra Iran-USA-Israele riguarda la sicurezza OT. Dragos ha documentato che il percorso dall’accesso IT alla compromissione OT è un pathway attivo e verificato, non un rischio ipotetico. Per i CISO europei e italiani – in particolare nei settori energia, trasporti e manifatturiero – questo significa porsi tre domande urgenti, come suggerisce l’analisi di HSToday:

  • Chi ha l’autorità di disconnettere da internet i nostri asset OT più critici con brevissimo preavviso?
  • Quanto velocemente possiamo terminare tutti gli accessi di terze parti nel nostro ambiente?
  • Abbiamo visibilità sui servizi cloud che i nostri fornitori utilizzano per gestire i nostri sistemi?

Se la risposta a una di queste domande è “non lo so”, il livello di esposizione è significativo.

Il quadro strategico: cyber come strumento asimmetrico

La dottrina iraniana dopo il blackout

L’analisi di Halcyon evidenzia un aspetto strutturale della cyber capability iraniana che questo conflitto rende ancora più rilevante: la convergenza tra operazioni statali e attività criminale. Il modello iraniano prevede che operatori statali monetizzino gli accessi ottenuti attraverso campagne governative tramite estorsione, mantenendo una plausible deniability.

Questo è particolarmente rilevante perché, come valutato dal CSIS, con le capacità convenzionali gravemente degradate dalle operazioni cinetiche, il cyber rappresenta ora lo strumento asimmetrico più accessibile per la ritorsione iraniana. La degradazione della connettività internet ha temporaneamente ostacolato la capacità di coordinamento degli APT operanti dall’interno dell’Iran, ma Unit 42 avverte che la degradazione dei comandi potrebbe anche portare ad autonomia tattica per le cellule operative al di fuori dei confini iraniani, con potenziali deviazioni dai pattern precedentemente stabiliti.

CISA sotto stress

Un fattore aggravante, documentato da CNBC, è che la principale agenzia cyber statunitense – CISA – si trova in condizioni operative ridotte. Al momento della pubblicazione, il sito web dell’agenzia riportava un ultimo aggiornamento al 17 febbraio a causa di un lapse in federal funding, con la cancellazione di valutazioni di sicurezza, formazione e altri impegni. Secondo CNBC, l’agenzia avrebbe perso circa un terzo dei suoi dipendenti dal cambio di amministrazione, e il suo direttore temporaneo sarebbe stato riassegnato ad altra divisione del DHS. Se confermato, questo scenario crea un vuoto di coordinamento proprio nel momento in cui la minaccia è più elevata.

Lo spettro della ritorsione a lungo termine

Il precedente storico è chiaro. Dopo l’uccisione del generale Soleimani nel 2020, i gruppi iraniani hanno lanciato ondate di wiper attack, campagne di credential harvesting e operazioni di spionaggio contro infrastrutture critiche occidentali. Come sottolinea AttackIQ, lo stesso playbook si sta dispiegando ora, ma con strumenti significativamente più capaci. Gruppi come MuddyWater, APT35/Charming Kitten, OilRig/APT34 e Agrius hanno trascorso anni a perfezionare il loro tradecraft.

La scoperta da parte di ESET nel dicembre 2025 del nuovo backdoor MuddyViper di MuddyWater, indirizzato verso infrastrutture critiche israeliane ed egiziane, e la campagna Operazione Olalampo di febbraio 2026 che ha dispiegato backdoor AI-assisted contro i settori energia e marittimo nell’area MENA, confermano che questi gruppi rimangono operativamente attivi e in evoluzione.

Prospettive: la nuova normalità della guerra ibrida

Questa cyber-guerra Iran-USA-Israele ha reso concreta una serie di scenari che la comunità di cybersecurity discuteva in termini teorici. Non è più una questione di se le operazioni cyber accompagneranno i conflitti cinetici, ma di come difendersi in un contesto dove la guerra nel cyberspazio precede, accompagna e sopravvive a quella sul campo.

Per l’Europa – e per l’Italia in particolare, con la sua esposizione sia come hub energetico mediterraneo sia come Paese con basi NATO e rappresentanze diplomatiche dei Paesi coinvolti – il messaggio è chiaro: la sicurezza delle infrastrutture critiche non è più un esercizio di compliance, ma una questione di resilienza nazionale.

Come ha osservato Scott McKinnon, CSO di Palo Alto Networks per UK e Irlanda, al Mobile World Congress di Barcellona: ogni volta che c’è un conflitto, c’è sempre una risposta. Non vengono usati solo i sistemi di difesa e di attacco fisici, ma anche armamenti collaterali nel cyberspazio.

La cyber-guerra Iran-USA-Israele è il primo banco di prova della guerra ibrida su scala globale. Non sarà l’ultimo.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/cyber-guerra-iran-usa-israele/




Il trattamento dei dati sanitari

Questo articolo fa parte della serie legata al tema della cybercriminalità nel settore sanitario, un percorso di analisi che intreccia sanità digitale, protezione dei dati e sicurezza informatica. L’attenzione si concentra sul concetto di dati sanitari, considerati il nucleo più sensibile della privacy. Essi, infatti, non solo riflettono la condizione clinica di un individuo, ma ne svelano la dimensione più intima, richiedendo tutele rafforzate sia sul piano normativo che tecnologico.

Così la Dr.ssa Salvadori Angelica, consigliere dell’Ordine dei Medici Chirurghi e Odontoiatri della Provincia di Torino:

La prima cosa che faccio quando arrivo in studio è accendere il computer. E con questo gesto apro, in qualche modo inconsapevole, una finestra, anzi una porta attraverso la quale, nel corso della giornata, i dati dei miei pazienti potranno essere disseminati in molte direzioni. […] Ad esempio, mi metto in collegamento con il SAR (Sistema di Accoglienza Regionale) della Regione Piemonte e il SAC (Sistema di Accoglienza Centrale) quando compilo in modalità informatica una ricetta dematerializzata contenente prescrizioni farmaceutiche e specialistiche, mi collego con AURA (Archivio Unico Regionale degli Assistiti della Regione Piemonte) se emerge l’esigenza di un aggiornamento dell’anagrafe degli assistiti, mi connetto con l’INPS (Istituto Nazionale della Previdenza Sociale) quando rilascio un certificato di malattia, oppure con l’INAIL (Istituto Nazionale per l’Assicurazione contro gli Infortuni sul Lavoro) se devo certificare un infortunio lavorativo, con il CSI Piemonte (Consorzio per il Sistema Informativo) se devo vedere l’esito di un tampone per Covid 19, se devo richiederne uno, se devo verificare l’inizio o la fine di una quarantena o di un isolamento, se devo vedere se un paziente è vaccinato. E questo vale non solo per me, medico di medicina generale, ma per tutti i medici convenzionati con il SSN, per i medici specialisti ospedalieri e, per alcuni aspetti, anche per i medici liberi professionisti.Se i medici, forse, non sempre sono consapevoli di tutto quello che mettono in moto, viene da chiedersi: e i cittadini? Hanno una percezione corretta di tutte le strade che possono prendere i loro dati sanitari?”.[1]

Nel discorrere del primo capitolo si è potuto constatare come, grazie alle potenzialità offerte dall’innovazione tecnologica, i dati sanitari stiano acquisendo sempre maggior impiego nel mondo contemporaneo: dalla ricerca medica e farmaceutica alla gestione dei servizi sanitari pubblici e privati.[2]

La materia inerente alla protezione dei dati sanitari è stata definita “diritto inquieto”[3], vi è difatti una tensione che caratterizza i dati sanitari stessi: meritevoli da un lato di massima protezione e riservatezza, e dall’altro di una calibrata circolazione per esigenze di sanità pubblica (si pensi alla destinazione ai fini di ricerca). A tale poi già complesso bilanciamento si aggiunge il problema della sicurezza rispetto a possibili attacchi informatici che possono mettere a rischio tanto la privacy degli individui quanto la tutela della salute pubblica.

Occorrerà comunque dapprima inquadrare ontologicamente le categoria dei dati idonei a rivelare lo stato di salute.

Alquanto nota è difatti la formula che consente di qualificare i dati sanitari come “nocciolo (o nucleo) duro” della privacy, locuzione utilizzata da chi rileva come essi si collochino “nel cerchio concentrico più interno” o, se si vuole, all’estremo più elevato della “scala delle durezze”[4] della protezione dei dati personali, risultando invero capaci di far intravedere, quando non di svelare del tutto, la sfera più riservata della persona.[5]

Ed è proprio dalla loro alta sensibilità che si ricava la necessità di una maggior tutela nel trattamento rispetto a quello indirizzato ad altre tipologie di dati, in quanto, se non correttamente svolto, potrebbe ingenerare rischi significativi per il rispetto dei diritti e delle libertà fondamentali dell’individuo, esponendo quest’ultimo a potenziali discriminazioni, stigmatizzazioni e classificazioni.

Il quadro normativo di riferimento è sicuramente esteso, ad ogni modo come fonti principali si possono indicare il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio per come relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati, anche meglio noto come GDPR (General Data Protection Regulation), che abroga la direttiva 95/46/CE;[6] a cui si aggiunga il decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali, conosciuto anche come Codice della privacy), aggiornato ed integrato con le modifiche introdotte dal decreto legislativo del 10 agosto 2018, n. 101, quale recante disposizioni per l’adeguamento della normativa nazionale al regolamento (UE) anzidetto. [7]

Prima di affrontare la spinosa questione della protezione dei dati personali si vogliono fissare alcune preliminari definizioni, guardando innanzitutto alle disposizioni del Regolamento 2016/679/UE.

L’art. 4, par. 1, n. 1 del testo normativo sopradetto infatti chiarisce come per dato personale si debba intendere: “qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento ad un identificativo come il nome, un numero di identificazione, dati relativi all’ubicazione, un identificativo online o ad uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale”.

Entro l’ampia categoria dei dati personali si rinviene poi il sottoinsieme dei cosiddetti “dati particolari” (ex dati sensibili, nel vecchio codice privacy), definiti dall’art. 9 del GDPR come: “dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché dati genetici, dati biometrici intesi a identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona”.

Si noti come i dati relativi alla salute figurino proprio fra i dati particolari, cioè quei dati la cui conoscenza da parte di altri può recare un grave pregiudizio per l’interessato.

Addentrandosi ancora più nel dettaglio della normativa il Considerando 35 del GDPR puntualizza come fra i dati inerenti alla salute dovrebbero rientrare :

tutti i dati riguardanti lo stato di salute dell’interessato che rivelino informazioni connesse allo stato di salute fisica o mentale passata, presente o futura dello stesso. […] Le informazioni risultanti da esami e controlli effettuati su una parte del corpo o una sostanza organica, compresi i dati genetici e i campioni biologici; e qualsiasi informazione riguardante, ad esempio, una malattia, una disabilità, il rischio di malattie, l’anamnesi medica, i trattamenti clinici o lo stato fisiologico o biomedico dell’interessato, indipendentemente dalla fonte, quale, ad esempio, un medico o altro operatore sanitario, un ospedale, un dispositivo medico o un test diagnostico in vitro”.

Si comprende allora il motivo per cui i dati sanitari, ipersensibili, espressivi della più autentica essenza della privatezza, siano proprio quella tipologia di dati ad andare a beneficiare di una maggior tutela accordata dall’ordinamento, per come espressa in: misure di garanzia rafforzate, presupposti di liceità del trattamento particolarmente stringenti, stretta indispensabilità a fini informativi, divieto di divulgazione, e si intuirà altresì la ragione per cui siano necessitanti di una protezione rafforzata rispetto a tutti quei rischi di intrusione ed accesso indebito, alterazione e manipolazione connessi a possibili attacchi cibernetici indirizzabili ai sistemi informativi sanitari.[8]

Principi cardine sulla protezione dei dati sanitari

Appurato come in ambito medico, ossia in qualsiasi struttura ospedaliera, RSA, ambulatorio del medico di base o del libero professionista, ad esser trattati sistematicamente siano soprattutto dati “particolari”, si volgerà ivi lo sguardo alle disposizioni che vanno a disciplinarne le specifiche modalità di trattamento.

Preliminarmente tuttavia si passeranno in rassegna i sei principi generali, in tema di trattamento dei dati personali, elencati all’art. 5 del GDPR, quali presupposti fondamentali attorno a cui orbitano tutti i meccanismi di protezione dei dati.

In primis si annoveri il principio definito di liceità, correttezza e trasparenza (lawfulness, fairness and transparency), in nome del quale si richiede che i dati “vengano trattati in modo lecito, corretto e trasparente nei confronti degli interessati”, ciò implica dunque che qualsiasi informazione ad essi inerente sia accessibile e di facile comprensione, grazie all’utilizzo di un linguaggio chiaro e semplice, nonché che gli interessati abbiano contezza dell’identità dei titolari del trattamento (ossia dei soggetti che per l’appunto trattano i dati personali) e delle finalità del trattamento stesso.

Calando tale principio nel panorama sanitario si può richiamare quanto previsto dall’Accordo Stato-Regioni sulla telemedicina del 17 dicembre 2020, il quale prevede specifici oneri informativi nei confronti dei pazienti soggetti a servizi di telemedicina fra cui: una completa descrizione della gestione dei dati, dei diritti dell’assistito, delle modalità di contatto, nonché un elenco aggiornato dei responsabili del trattamento.[9]

Il secondo principio invece è relativo alla limitazione delle finalità (purpose limitation) dei dati, si rilevi come questi siano “raccolti per finalità determinate, esplicite e legittime”, per cui non sarà consentito trattarli successivamente in modo non compatibile con le finalità previamente delineate. Si tenga comunque presente che eventuali ulteriori trattamenti per finalità di pubblico interesse, di ricerca scientifica, storica o a fini statistici non sono considerati incompatibili con le finalità iniziali e risultano pertanto consentiti.

Il terzo principio è la c.d. minimizzazione dei dati (data minimisation), in ragione del quale questi ultimi dovranno essere “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati”.

L’accuratezza poi (accuracy) è il quarto principio ed implica la necessità di garantire che i dati personali siano adeguatamente accurati ed aggiornati, ove necessario, adottando tutte le misure ragionevoli necessarie per cancellarli o rettificarli tempestivamente qualora inesatti rispetto alle finalità per cui vengono trattati.

Il quinto principio suole indicare la c.d. limitazione della conservazione (storage limitation), per cui i dati saranno “conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati”. Una eventuale conservazione per periodi di tempo più lunghi sarà consentita unicamente per finalità di interesse pubblico, di ricerca scientifica, storica o a fini statistici. Le politiche di data retention, previste specificatamente dal nostro ordinamento, disciplinano infatti numerosi e differenziati tempi di conservazione per quanto concerne la documentazione sanitaria: sarà pertanto compito dell’operatore sanitario (pubblico o privato) dover identificare la natura della documentazione e conseguentemente la normativa di riferimento applicabile.

Per esemplificare, l’iconografia radiologica conta ad oggi un periodo di archiviazione di dieci anni, viceversa le cartelle cliniche, gli esami di laboratorio, i referti vedono un obbligo di conservazione illimitato nel tempo, in quanto rappresentanti atto ufficiale, indispensabile a garantire la certezza del diritto, nonché quale preziosa fonte documentaria per le ricerche di carattere storico sanitario.[10]

Il sesto ed ultimo principio riguarda infine l’integrità e la riservatezza dei dati (integrity and confidentiality), ciò implicherà che vengano adottate tutte le misure tecniche ed organizzative adeguate per garantire un livello di sicurezza proporzionato al rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, inclusa la protezione contro “trattamenti non autorizzati o illeciti, la perdita, la distruzione o il danno accidentale”.

A titolo esemplificativo, si richiami l’elencazione all’art 32 par.1 del GDPR relativamente alle misure che possono essere adottate ed implementate al fine di garantire la sicurezza dei digital data, fra cui:

  1. La pseudonimizzazione dei dati personali, ovvero una metodologia che si pone l’obiettivo di “allontanare” il dato dalla persona, rendendone così complessa la stessa riferibilità (senza tuttavia romperne il legame, a cui mirano invece le tecniche di anonimizzazione);[11]
  2. La cifratura dei dati, volta a rendere i dati personali incomprensibili a chiunque non sia autorizzato ad accedervi tramite una apposita chiave di lettura idonea a decriptarne l’informazione;
  3. La capacità di assicurare, su base permanente, la riservatezza, l’integrità, la disponibilità ed altresì la resilienza dei sistemi e dei servizi di trattamento;
  4. La capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
  5. L’auditing, espressione volta ad indicare una procedura atta a testare, verificare, e valutare regolarmente l’efficacia delle misure tecniche e organizzative concretamente adottate.[12]

Si badi bene, il legislatore non entra nel dettaglio, anzi quello fornito risulta pressoché un elenco generale, poiché è fondamentale che la security stessa venga garantita da soluzioni ritagliate nel modo più personale possibile rispetto alle specificità del soggetto da proteggere. Non pare essere dunque “codardia legislativa”, ma diretta conseguenza dell’assunto secondo cui se il titolare del trattamento deve essere accountable allora dovrà parimenti essere libero di ritagliarsi il “vestito” di sicurezza che ritiene necessario per la propria struttura.

Il principio di accountability

Il medesimo art. 5 del GDPR, al secondo paragrafo, enuncia il principio di responsabilizzazione (o accountability), in assenza del quale i sei principi cardine previamente elencati non potrebbero esser attuati: sarà infatti precipua responsabilità del titolare del trattamento[13] predisporre e mettere in atto specifiche soluzioni tecniche e organizzative che rendano il trattamento lecito, corretto, trasparente, adeguato, limitato nel tempo, pertinente ed effettuato per finalità legittime; così come sarà sua stessa responsabilità risponderne e “render conto” dell’efficacia delle misure concretamente impiegate e dei risultati così ottenuti.

Pertanto la figura apicale di una data struttura (si pensi ad un Direttore sanitario), tenuto conto della natura del dato, del suo ambito di applicazione (nell’erogazione di servizi di cura, in un progetto di ricerca etc.), del contesto (limitatamente alla propria struttura, od in condivisione con altre), delle finalità del trattamento, dei rischi per i diritti e le libertà delle persone fisiche, dovrà adottare misure tecniche ed organizzative adeguate, ossia parametrate al livello di rischio rilevato. Le anzidette misure poi, ex art. 24 GDPR, dovranno essere “riesaminate ed aggiornate qualora necessario”, introducendo così il principio fondamentale della ciclicità della sicurezza, quale perimetro altamente dinamico da dover revisionare periodicamente nel tempo, al fine di ottenerne un sempre maggiore perfezionamento. [14]

Non vi è dubbio sul fatto che venga in tal modo a delinearsi un sistema di adeguamento al GDPR fortemente accentrato sulla figura del titolare del trattamento: data la riconosciuta difficoltà di esercizio dei diritti dell’interessato[15], essendo egli spesso propenso a rilasciare i propri dati con leggerezza o con carenza di consapevolezza, viene spostato il baricentro della responsabilità sul titolare del trattamento e sulla necessità che le operazioni di trattamento stesse siano “GDPR compliant”.[16]

Ed è proprio così che il concetto di accountability si collega con quelli di prevenzione e proattività, inglobando il saper agire d’anticipo, pianificando, mediante policy e tecnologie efficaci, quanto necessario per evitare i rischi di compromissione dei dati. Fare ciò significa, ex art. 25 GDPR, operare una valutazione del rischio e del suo contenimento attraverso tecniche di protezione “fin dall’avvio del trattamento” (c.d. privacy by default) e “per impostazione predefinita” (c.d. privacy by design): tali espressioni puntualizzano come la privacy degli interessati dovrà essere tutelata fin dall’inizio, cioè dalle fasi di ideazione e progettazione del servizio, e che non potranno esser trattati dati personali ulteriori rispetto a quelli minimi indispensabili per la specifica finalità del trattamento.[17]

Tali ragionamenti, per ciò che ivi più interessa, possono certo essere calati in ambito sanitario: i software, i dispositivi e le procedure utilizzati nella sanità digitale dovranno essere rispettosi della normativa in tema di protezione dei dati. Pertanto una corrispondenza di telemedicina fra medico e paziente con l’uso di sistemi non sicuri, come i social o la posta elettronica, costituisce di per sé una procedura a rischio, violante le regole sulla protezione dei dati, ed in quanto tale sanzionabile dall’Autorità Garante per la protezione dei dati.

Allora i sanitari, e le strutture che offrono servizi di telemedicina, hanno il precipuo dovere di gestire i rischi derivanti dal trattamento dei dati personali dei pazienti, optando per quelle soluzioni operative che offrano le migliori garanzie di proporzionalità, efficacia, sicurezza, e rispetto dei diritti della persona.[18]

Si voglia, già in questa sede, anticipare l’assoluto rilievo dell’innestare una cultura della (cyber)sicurezza mediante una adeguata formazione del personale medico, ed è così invero che recita l’articolo 32 comma 4 del GDPR: “Il titolare del trattamento ed il responsabile del trattamento fanno sì che chiunque agisca sotto la loro autorità e abbia accesso a dati personali non tratti tali dati se non è istruito in tal senso dal titolare medesimo.”

Si pensi ad una struttura sanitaria complessa (da un poliambulatorio ad un grande ospedale), in questa stessa gli operatori a trattare dati sanitari sono indubbiamente molteplici, ad ogni modo comunque tutti dovranno essere a conoscenza circa le procedure da seguire ed i conseguenti probabili rischi insiti nel trattamento di dati sensibili, in particolar modo alla luce delle sempre più frequenti compromissioni degli archivi e sistemi digitali sanitari.

Il Data Protection Officer

Anche la designazione di un Responsabile della protezione dati (da qui in avanti indicato come DPO, acronimo inglese per Data Protection Officer) rientra nell’approccio responsabilizzante delineato dal GDPR, in linea col principio di accountability.

Tale figura professionale, designata dal titolare o dal responsabile[19] del trattamento, si presenta quale un consulente esperto, dotato di un’approfondita conoscenza della normativa e delle prassi in tema di gestione dei dati personali, nonché dello specifico settore di riferimento in cui si trova ad operare.

La nomina del DPO si presenta come obbligatoria, ex art. 37 del GDPR, ogniqualvolta il trattamento sia effettuato da una autorità pubblica o da un organismo pubblico, nonché quando le attività principali del titolare o del responsabile del trattamento consistano nel trattare, su larga scala, categorie particolari di dati personali (quali per l’appunto sono i dati inerenti alla salute).

Questo non significa che ogni medico sia obbligato a designare un DPO: il singolo professionista o il medico di base non trattano dati “su vasta scala”, diversamente il problema si pone per gli studi in cui operano più medici e così anche per una Azienda sanitaria, un ospedale privato, una residenza sanitaria assistenziale, tutti si doteranno di tale figura dotata di competenze giuridiche, informatiche, nonché di risk management, la cui responsabilità sarà quella di osservare, valutare ed organizzare la gestione del trattamento dei dati personali (e dunque la loro protezione), affinché questi ultimi siano trattati nel rispetto delle normative privacy europee e nazionali.

L’art. 39 del GDPR opera poi una dettagliata elencazione delle principali funzioni del DPO, fra cui:

  1. Informare e fornire una consulenza al titolare o al responsabile del trattamento in merito agli obblighi derivanti del Regolamento europeo;
  2. Sorvegliare l’attuazione del Regolamento europeo, come anche vigilare sull’applicazione delle politiche del titolare del trattamento in materia di protezione dei dati personali, comprese l’attribuzione delle responsabilità, la sensibilizzazione e la formazione del personale che partecipa ai trattamenti;
  3. Fornire, se richiesto, un parere in merito alla valutazione d’impatto sulla protezione dei dati e sorvegliarne il concreto svolgimento. Essendo la valutazione d’impatto un processo volto a valutare la necessità e proporzionalità di un determinato trattamento e a gestirne gli eventuali rischi, il titolare del trattamento si consulterà preventivamente col DPO su tematiche quali: condurre o meno la valutazione stessa, quale specifica metodologia sia da adottare, quali salvaguardie e misure di sicurezza siano da applicare al fine di attenuare i rischi per i diritti delle persone interessate;
  4. Fungere da punto di contatto per il Garante per la protezione dei dati personali e controllare che sia dato seguito alle richieste del Garante stesso.

Ancora, al secondo paragrafo l’art. 39 del GDPR con una formula prettamente di chiusura: “Nell’eseguire i propri compiti il responsabile della protezione dei dati considera debitamente i rischi inerenti al trattamento, tenuto conto della natura, dell’ambito di applicazione, del contesto e delle finalità del medesimo”, in sostanza con tale disposizione di portata generale si chiede al DPO di delineare un ordine di priorità nell’attività svolta e di concentrarsi sulle questioni che presentino maggiori rischi in termini di protezione dei dati.[20]

Il registro delle attività di trattamento

Rientrante a sua volta nel concetto di accountability risulta essere anche il cosiddetto Registro delle attività di trattamento, novità introdotta dall’art. 30 del GDPR.

Quest’ultimo altro non è che lo strumento attraverso il quale il titolare e il responsabile del trattamento documentano in forma scritta, anche elettronica, le principali informazioni relative alle attività di trattamento e alle misure di garanzia adottate, in base alle finalità perseguite ed ai profili di rischio rilevati, al fine di poter poi dimostrare all’Autorità di controllo (il Garante per la protezione dei dati) di aver adempiuto correttamente alla propria funzione di protezione dei dati personali.

Per quanto concerne propriamente l’ambito sanitario la regolare tenuta del Registro delle attività di trattamento risulta quale obbligo per tutti gli operatori sanitari (singoli professionisti sanitari, medici di medicina generale, ospedali privati, case di cura, farmacie, parafarmacie, Aziende Sanitarie appartenenti al S.S.N. etc.).

Per analizzarne nel dettaglio il contenuto minimo si guardi alla elencazione fornita all’art. 30 del Regolamento, in base al quale il Registro conterrà:

  1. Il nome e i dati di contatto del titolare del trattamento;
  2. Le finalità del trattamento (come “trattamento dei dati del paziente per l’erogazione della specifica prestazione sanitaria”);
  3. Una descrizione delle categorie di interessati (ad esempio “pazienti”) e circa le categorie di dati personali (quali dati anagrafici, dati biometrici etc.);
  4. Le categorie di destinatari a cui i dati personali sono stati o saranno comunicati (si pensi ad un laboratorio analisi);
  5. Ove possibile, i termini ultimi previsti per la cancellazione delle diverse categorie di dati;
  6. Ove possibile, una descrizione generale circa le misure di sicurezza tecniche ed organizzative adottate (quali security policy, sistemi di intrusion detection etc.).

Potrà ad ogni modo esser riportata nel registro qualsiasi informazione che il titolare od il responsabile ritengano utile dover indicare (come le valutazioni di impatto effettuate o le modalità di raccolta del consenso seguite).

Standard internazionali per la sicurezza dei dati: ISO 27001

Come si è potuto osservare poc’anzi la normativa europea pone in capo ai titolari e responsabili del trattamento dei dati numerosi adempimenti, fra i quali assume notevole rilievo l’adozione di “misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”.

Così infatti dispone l’art. 32 del GDPR cercando di guidare la scelta di tale misure in base al principio di adeguatezza, nonché “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti ed anche le libertà delle persone fisiche”.

Essendo tali ultime formule pressoché generali, l’esigenza attuale risulta quella di fornire ai titolari e ai responsabili del trattamento degli strumenti concreti per individuare e scegliere idonee misure di sicurezza ed essere in grado di dimostrane la pratica adozione.[21]

Nel classificare invero le misure di sicurezza adottabili il GDPR opera un riferimento a due categorie di misure: quelle tecniche e quelle organizzative, diversamente dalla letteratura del settore[22] che invece distingue in: misure volte a garantire la sicurezza organizzativa (quali procedure di gestione di data breaches), quelle relative alla sicurezza logica e tecnologica (quali sistemi di autenticazione, antimalware, firewall, monitoraggi, scansioni delle vulnerabilità), e quelle relative alla sicurezza fisica (si pensi alla sicurezza degli edifici e degli archivi, al controllo degli accessi ed alla sicurezza ambientale). L’obiettivo di tutte le anzidette misure sarà comunque quello di assicurare la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi informativi.

Con l’obiettivo di agevolare la specifica scelta delle misure di sicurezza concretamente adottabili da parte del titolare e del responsabile del trattamento soccorrono sul piano internazionale le c.d. normative ISO, ossia norme tecniche sviluppate dalla International Organization for Standardization riportanti linee guida che un determinato soggetto dovrà andare a rispettare per l’ottenimento di una certificazione valida sul piano internazionale, attestante la conformità del soggetto stesso (persona fisica, ente pubblico o privato) a specifici parametri di valutazione.

Fra la molteplici norme ISO, si può qui porre in evidenza la ISO 27001 quale standard internazionale per la sicurezza delle informazioni, creata al fine di definire i requisiti atti a stabilire, implementare, mantenere e migliorare un sistema di gestione della sicurezza delle informazioni. [23]

Nei suoi contenuti presenta infatti un insieme di best practices, utili per sviluppare ed accrescere la capacità delle organizzazioni di gestire i rischi legati alla protezione dei dati, la ISO 27001 è invero molto specifica nel raccogliere, nel suo cosiddetto annex A, un vero e proprio catalogo di misure da adottare per contrastare nonché mitigare i rischi di perdita, modifica, divulgazione non autorizzata od accesso ai dati personali trattati.

Non sarebbe del tutto errato pensare quindi alla normativa GDPR e alla ISO 27001 alla stregua di un sistema integrato in ambito di sicurezza dei dati, d’altronde è lo stesso Considerando 100 del GDPR ad incoraggiare “l’istituzione di meccanismi di certificazione” che possano consentire di valutare il livello di protezione dei dati prodotti e dei servizi.

Ed ancora, è l’art. 24, comma 3 del GDPR a specificare come l’adesione ai codici di condotta ed alle certificazioni approvate, proprio come la ISO 27001, possa essere considerata come un elemento dimostrativo circa la conformità ed il rispetto degli obblighi del titolare del trattamento, in ossequio allo stesso principio di accountability.

Purtuttavia pare ovvio sottolineare come la garanzia di una certificazione non reciderà mai del tutto il rischio di verificazione di eventi dannosi relativi alla sicurezza dei dati, come peraltro si constaterà a seguire in ambito sanitario, ma al massimo andrà ad attenuarne le possibilità ed eventualità di accadimento e, conseguentemente, le relative responsabilità per tutti coloro che trattano i dati e le informazioni.

Condizioni di liceità del trattamento in ambito sanitario

Rimane tuttora da chiarire cosa si debba intendere con la precisa locuzione “trattamento dei dati”, di qui la definizione fornita dall’art. 4 del GDPR: “Qualsiasi operazione o insieme di operazioni, compiute con o senza l’ausilio di processi automatizzati ed applicate a dati personali o insiemi di dati personali, come la raccolta, la registrazione, l’organizzazione, la strutturazione, la conservazione, l’adattamento o la modifica, l’estrazione, la consultazione, l’uso, la comunicazione mediante trasmissione, diffusione o qualsiasi altra forma di messa a disposizione, il raffronto o l’interconnessione, la limitazione, ed altresì la cancellazione o la distruzione”.

Si può evidenziare peraltro come una operazione di trattamento si articoli in differenti fasi: una preliminare (raccolta e registrazione), una di elaborazione (selezione, impiego), una di circolazione (o diffusione), ed infine una residuale (conservazione, cancellazione).

Si vuole sottolineare come l’art. 9 del GDPR ponga un divieto generale al trattamento di intere categorie particolari di dati, fra cui figurano proprio i dati relativi alla salute: “È vietato trattare dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché trattare dati genetici, dati biometrici intesi ad identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona”.

Tuttavia tale divieto non è certo assoluto, in quanto in presenza di tutta una serie di condizioni di liceità, espressamente elencate dallo stesso testo normativo, tale preclusione non opera.

Per ciò che ivi interessa, il trattamento dei dati sanitari sarà considerato lecito laddove avvenga: per finalità di medicina preventiva, diagnosi, assistenza o terapia sanitaria o sociale (cosiddetta “finalità di cura”); per motivi di interesse pubblico nel settore della sanità pubblica (si pensi alla gestione di emergenze sanitarie nazionali, od alla protezione da gravi minacce per la salute a carattere transfrontaliero); ed ancora a fini di archiviazione nel pubblico interesse, di ricerca scientifica, storica o a fini statistici.

Vale la pena soffermarsi su come di fatto il GDPR superi così la precedente cornice normativa “consensocentrica” (propria del d.lgs. 196/2003, Codice privacy): diversamente dal passato infatti, non dovrà più esser richiesto il consenso del paziente per il trattamento di dati in ambito sanitario, purché si tratti di dati specificatamente necessari alle “finalità di cura” previste dal Regolamento Ue (prevenzione, diagnosi etc.) e che le relative attività siano effettuate da un professionista sanitario soggetto al segreto professionale.

Così, per esemplificare, persegue una finalità di cura l’infermiere che effettua una valutazione dei parametri vitali di un paziente al momento dell’accesso in pronto soccorso, come anche il cardiologo che raccoglie l’anamnesi necessaria alla corretta refertazione di un elettrocardiogramma; lo specialista che annota i dati biometrici del paziente in vista di un intervento chirurgico, come pure, in senso ampio, un direttore sanitario di una struttura pubblica che procede alla archiviazione di dati per studi statistici finalizzati tutela della salute collettiva.[24]

Ovvio è, ma vale la pena specificarlo, che non si deve qui confondere il consenso prestato al trattamento dei dati sanitari, col consenso ai trattamenti sanitari stessi: è quest’ultimo infatti a costituire il presupposto di legittimità dell’operato medico, andando ad “assorbire” il primo consenso, che non risulta più pertanto necessario.

D’altronde un professionista sanitario dovrà necessariamente venire a conoscenza di tutta una serie di dati identificativi e clinici (anamnesi, farmaci assunti etc.) per l’esecuzione di un trattamento sanitario, ed egli stesso, d’altra parte, nel trattare il paziente andrà a generare tutta un’altra serie di dati (referti, lastre etc.), dal momento poi che la semplice raccolta e consultazione di dati ne costituisce per definizione un trattamento, per un medico risulterà inevitabile, nello svolgimento delle sue funzioni, trattare costantemente i dati personali dei pazienti.

Si segnali ancora come ai trattamenti “per finalità di cura” siano comunque equiparati anche i trattamenti operati tramite applicazioni mediche, quando la finalità perseguita è quella di fornire cura al paziente, tramite un servizio di telemedicina, telesorveglianza o telemonitoraggio.

È evidente inoltre come tale dispensa dall’ottenimento del consenso non opererà laddove i trattamenti dei dati dei pazienti avvengano per finalità diverse da quelle strettamente di cura (si pensi a fini promozionali, commerciali o di fidelizzazione della clientela).

Residuano ad ogni modo alcuni casi in cui i dati sanitari possono essere trattati esclusivamente con il consenso della persona interessata quali: come si diceva nel primo capitolo, la possibilità di accesso al FSE (fascicolo sanitario elettronico), l’adesione a servizi di refertazione online, oppure l’utilizzo di apps mediche, quando il trattare i dati del paziente afferisce, solo in senso lato, alla cura di quest’ultimo, ma non è ad essa strettamente necessario (si pensi ad una applicazione che fornisce indicazioni su come migliorare la qualità del sonno), in tal caso il titolare del trattamento dovrà trattare i dati previa acquisizione del consenso dell’utente interessato.

Si può concludere evidenziando come l’approvazione del GDPR abbia indubbiamente contribuito a richiamare l’attenzione degli operatori sanitari sui temi della privacy e della protezione dei dati, in quanto strettamente connessi ai profili della sicurezza delle cure e di dignità del paziente. Come evidenziato infatti dal Garante, nella sua relazione annuale al Parlamento dell’anno 2018,[25] eventuali carenze in ambito di sicurezza dei dati personali possono avere effetti oltremodo deleteri negli stessi processi di erogazione dei trattamenti medici, rappresentando causa di disfunzioni, rallentamenti ed errori sanitari, fonti di potenziale responsabilità della struttura sanitaria, obbligata così a risarcirne i danni conseguenti.

L’obbiettivo di questi due preliminari capitoli voleva essere il presentare la digitalizzazione della sanità quale occasione senza precedenti di sviluppo ed innovazione, da dover senza dubbio promuovere per una sempre maggiore efficienza ed universalità delle cure, e per una migliore programmazione della spesa sanitaria. Tuttavia suddetta digital health dovrà realizzarsi all’interno di un progetto di politiche pubbliche organico e lungimirante di governance sanitaria, che promuova una condivisione selettiva dei dati sanitari, con le dovute cautele, al fine di minimizzarne i rischi cibernetici e le conseguenti possibili lesioni alla sfera personale della riservatezza e della dignità dei pazienti.[26]

La sanità digitale, pur rappresentando un’occasione di sviluppo e innovazione, espone inevitabilmente a rischi di compromissione dei sistemi informativi e alla minaccia crescente della cybercriminalità. Proprio a questo tema sarà dedicato il prossimo articolo della serie, che introdurrà la rivoluzione digitale e l’innovazione criminale, approfondendo le nuove forme di criminalità tecnologica.

Per approfondire, invitiamo a leggere il white paper gratuito di Maria Vittoria Zucca dal titolo La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] A. Salvadori, “Deontologia e tutela dei dati sanitari”, in Torino Medica. La rivista dell’ordine dei medici chirurghi e odontoiatri della provincia di Torino, anno XXXIII, numero 3-4, 2021, pp. 9-10.

[2] ANITEC-ASSINFORM (Associazione italiana per l’Information and Communication Technology), Una data strategy per la Sanità italiana, a cura del gruppo di lavoro Digital Transformation in Sanità di Anitec-Assinform, Maggio 2022, p. 20.

[3] Intervento di A. Soro, ex-presidente dell’Autorità Garante per la protezione dei dati personali, “Tracciamento contagi coronavirus, ecco i criteri da seguire”, in Agenda Digitale, 29 Marzo 2020.

[4] L’immagine della scala delle durezze, diffusamente ripresa nella dottrina che si è occupata di privacy, si deve a Stefano Rodotà. Cfr. S. Rodotà, “Persona, riservatezza, identità. Prime note sistematiche sulla protezione dei dati personali”, in Rivista critica del diritto privato, anno XV, 1997, pp. 583-609.

[5] F. Di Ciommo, “Il trattamento dei dati sanitari tra interessi individuali e collettivi”, in R. Pardolesi (a cura di), La privacy sanitaria, vol. II, Giuffrè editore, Milano, 2003, vol. II, p. 239.

[6] Regolamento (Ue) 2016/679 del Parlamento e del Consiglio, relativo alla “protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati”, del 27 Aprile 2016, che abroga la Direttiva 95/46/CE (Regolamento generale sulla protezione dei dati), per il testo normativo nella sua completezza si rimanda al sito internet: eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:32016R0679.

[7] Decreto legislativo 30 Giugno 2003, n. 196, recante il “Codice in materia di protezione dei dati personali”, integrato con le modifiche introdotte dal decreto legislativo 10 Agosto 2018, n. 101, recante “Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (Ue ) 2017/679 del Parlamento e del Consiglio, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali.

[8] Intervento di P. Stanzione, Presidente dell’Autorità garante per la protezione dei dati personali, “Sicurezza del dato sanitario e condivisione”, in Panorama, 18 Febbraio 2022.

[9] Il documento Indicazioni nazionali per l’erogazione di prestazioni di telemedicina è stato approvato dalla Cabina di regia del NSIS nella seduta del 28 ottobre 2020 ed è stato adottato con Accordo in Conferenza Stato Regioni del 17 dicembre 2020 (Repertorio atti n.215/CSR).

[10] NETPATROL, op. cit. supra a nota 17, p. 8.

[11] G. D’Acquisto, M. Naldi, Big Data e Privacy by Design. Anonimizzazione, Pseudonimizzazione e Sicurezza, Giappichelli Editore, Torino, 2017.

[12] A. Antonilli, op. cit. supra a nota 3, p. 92.

[13] Per “titolare del trattamento” si rimandi all’art 4 del GDPR: “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che, singolarmente o insieme ad altri, determina le finalità e i mezzi del trattamento di dati personali […]”.

[14] P. Perri (intervento), durante il Webinar “Conoscere e prevenire gli attacchi cyber in sanità”, tenutosi in data 30 giugno 2021.

[15] Per “interessato” si intenda la persona fisica alla quale si riferisce il dato personale.

[16] D. Poletti, “Comprendere il Reg. UE 2016/679: Un’introduzione”, in A. Mantelero, D. Poletti (a cura di), Regolare la tecnologia: il Reg. UE 2016/679 e la protezione dei dati personali. Un dialogo fra Italia e Spagna, Pisa University Press, 2018, pp. 9-19.

[17] A. Cortesi, “L’art. 25 del GDPR: dalla privacy by default al principio di minimizzazione o necessità nel trattamento dei dati personali”, in Interlex: rivista di diritto, tecnologia, informazione, 2017.

[18] NETPATROL, op. cit. supra a nota 17, p. 9.

[19] Per “responsabile del trattamento” si rimanda all’art. 4 del GDPR: “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che tratta dati personali per conto del titolare del trattamento.”

[20] “Linee guida sui responsabili della protezione dei dati”, WP243 rev. 01, adottate dal Gruppo di lavoro articolo 29 in materia di protezione dei dati personali, versione emendata ed adottata il 5 aprile 2017.

[21] R. Riccio, “Le misure di sicurezza tra GDPR e ISO 27001: due normative a confronto e i possibili scenari prospettabili”, in Cyberlaws: free legal database and blog, 9 Gennaio 2019.

[22] G. Butti, A. Piamonte, GDPR: nuova privacy. La conformità su misura, Iter editore, Milano, 2017.

[23] ISO/IESC 27001: 2013, “Information technology – Security techniques – Information Security – Managements systems – Requirements”.

[24] G. Chiarini, “Privacy: come cambia il dato normativo”, in E-Health: innovazione e tecnologia in ospedale, vol. 72, 2019, pp. 66-69.

[25] La Relazione del Garante per la protezione dei dati sanitari al Parlamento del 2018 è reperibile qui.

[26] P. Stanzione, intervento cit. supra, a nota 32.

Profilo Autore

Maria Vittoria Zucca, laureata con lode in Giurisprudenza presso l’università degli Studi di Trento, è attualmente dottoranda nel Programma di Dottorato di Interesse Nazionale in Cybersecurity, con istituzione capofila la Scuola IMT Alti Studi di Lucca, ed è affiliata alla Scuola Superiore Sant’Anna, presso l’Istituto Dirpolis (Diritto, Politica e Sviluppo).
La sua attività di ricerca si concentra sulla prevenzione, l’indagine ed il contrasto della criminalità informatica, includendo le discipline del diritto penale dell’informatica e della criminologia digitale. Su questi temi è autrice di diverse pubblicazioni scientifiche e partecipa regolarmente a conferenze nazionali e internazionali.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/dati-sanitari/




ClickFix: la tecnica di social engineering che ha fatto +517% e trasforma la vittima nel vettore d’attacco

ClickFix attacco social engineering, questa è la combinazione di parole che ogni professionista della sicurezza informatica dovrebbe avere in cima alla lista delle priorità operative nel 2026. Non perché sia l’ennesima tecnica di phishing con un nome accattivante, ma perché rappresenta un ribaltamento concettuale nella dinamica attaccante-vittima: per la prima volta su scala industriale e con questo livello di esplicitezza, è la vittima stessa a eseguire il codice malevolo, con le proprie mani, credendo di risolvere un problema.

Certo, le macro nei documenti Office richiedevano un’azione utente, il clic su “Abilita contenuto”. Ma ClickFix porta questo principio a un livello qualitativamente diverso: la vittima non si limita ad autorizzare un’esecuzione nascosta, copia e incolla attivamente un comando che non comprende in un terminale di sistema. La differenza non è di grado. È di paradigma.

I numeri parlano senza ambiguità. Secondo il report H1 2025 di ESET, le detection legate a ClickFix sono cresciute del 517% in sei mesi, attestandosi come la seconda tecnica di attacco più intercettata dopo il phishing classico, con quasi l’8% di tutti gli attacchi bloccati attribuibili a varianti HTML/FakeCaptcha.

Microsoft Threat Intelligence ha confermato che ClickFix è diventato il metodo di accesso iniziale in più rapida crescita, con campagne che colpiscono migliaia di dispositivi enterprise e consumer ogni giorno a livello globale. Il Center for Internet Security (CIS) ha rilevato che la tecnica ha costituito oltre un terzo di tutti gli alert non-malware sulla rete Albert Network nel primo semestre 2025. Quanto alla distribuzione geografica, i dati ESET Research collocano le maggiori concentrazioni in Giappone (23%), Perù (6%), Polonia, Spagna e Slovacchia (ciascuna oltre il 5%), con il sud Europa tra le aree a crescita più rapida.

Quando un attacco cresce a questa velocità, non è un trend, è un cambiamento strutturale nel panorama delle minacce. Eppure, nel panorama informativo italiano, l’analisi approfondita di ClickFix è pressoché assente. Questo articolo colma quella lacuna.

ClickFix: come funziona l’attacco che sfrutta la fiducia dell’utente

Per comprendere perché ClickFix è così devastante, bisogna partire dalla sua meccanica operativa. L’attacco si articola in tre passaggi che, nella loro semplicità, rappresentano un capolavoro di ingegneria psicologica.

Primo passo: il pretesto. La vittima raggiunge una pagina web – tramite phishing, malvertising, sito compromesso o risultato di ricerca manipolato che presenta un elemento familiare: un CAPTCHA di Cloudflare, un messaggio di errore del browser, una richiesta di verifica dell’identità. Secondo Sekoia TDR, i cluster ClickFix più diffusi impersonano pagine Google Meet con falsi problemi audio, aggiornamenti di sicurezza Microsoft e verifiche reCAPTCHA.

Secondo passo: la manipolazione della clipboard. Quando la vittima interagisce con il falso prompt, tipicamente cliccando un pulsante “Verifica” o “Fix it” – un JavaScript nascosto copia silenziosamente un comando malevolo nella clipboard del sistema, sfruttando API come navigator.clipboard.writeText()
o document.execCommand('copy')
. La vittima non sa che i propri appunti sono stati sovrascritti con codice PowerShell, un comando mshta.exe o un one-liner cmd offuscato. In alcune varianti meno sofisticate, il comando è visualizzato direttamente sulla pagina e l’utente lo copia manualmente seguendo le istruzioni: il risultato è identico.

Terzo passo: l’auto-infezione. La pagina istruisce la vittima ad aprire la finestra Run di Windows (Win+R), incollare il contenuto (Ctrl+V) e premere Invio. Poiché il processo eseguito nasce come figlio di Explorer.exe, esattamente come qualsiasi comando lanciato dall’utente, i controlli preventivi di accesso iniziale vengono completamente aggirati: filtri email, web gateway, sandbox non vedono nulla di sospetto, perché il payload non transita per quei canali.

Per quanto riguarda gli EDR, la situazione è più sfumata: un’azione user-initiated è intrinsecamente più difficile da classificare come malevola, ma gli EDR moderni con behavioral analysis possono rilevare le catene di processo successive (PowerShell che scarica un payload, connessioni C2 anomale). Come ha documentato Microsoft, Defender for Endpoint è in grado di rilevare e mitigare le attività post-esecuzione. Il problema è che la prevenzione dell’accesso iniziale – la prima linea di difesa – è cieca.

Questa è la genialità distruttiva di ClickFix: non sfrutta una vulnerabilità software, ma una vulnerabilità cognitiva. Come ha osservato Kaspersky nel febbraio 2026, l’essenza di ClickFix si riduce a “convincere la vittima, sotto vari pretesti, a eseguire un comando malevolo sul proprio computer”.

La psicologia dell’obbedienza automatica: perché ClickFix funziona così bene

Il successo di ClickFix non si spiega con la sofisticazione tecnica – il codice è spesso banale, un one-liner PowerShell offuscato. Si spiega con la psicologia, e in particolare con tre principi ben documentati nella letteratura sulla persuasione e sul comportamento decisionale.

Il primo è il principio di autorità teorizzato da Robert Cialdini in “Influence: The Psychology of Persuasion” (1984):

le persone tendono a obbedire a richieste provenienti da fonti percepite come autorevoli.

Un CAPTCHA Cloudflare, un messaggio di errore con il logo Chrome, una notifica di sicurezza Microsoft non sono solo pretesti, sono segnali di autorità che il cervello della vittima processa in modo automatico. Nessun utente si ferma a chiedersi se quel CAPTCHA sia reale, perché ne ha superati migliaia di identici.

Il secondo principio è il task completion bias, o compulsione al completamento: una volta iniziata un’azione (visitare un sito, verificare la propria identità), il cervello resiste all’interruzione. L’utente che ha già cliccato “Verifica” percepisce il passaggio aggiuntivo – aprire Run, incollare, eseguire – come la naturale prosecuzione di un processo già avviato, non come un’azione radicalmente diversa.

Il terzo è il condizionamento operante costruito da decenni di interazione con i sistemi Microsoft. Pulsanti “Fix it”, wizard di troubleshooting, prompt di aggiornamento che richiedono azioni manuali: ogni clic su “Ripara”, “Aggiorna”, “Verifica” ha rinforzato un pattern comportamentale automatico. ClickFix sfrutta esattamente questo condizionamento, trasformando la diligenza dell’utente nella sua vulnerabilità.

Il report di Proofpoint ha evidenziato un ulteriore elemento: ClickFix esternalizza la responsabilità percepita. L’utente non sta “scaricando un file sospetto”, sta “risolvendo un problema tecnico”. Questa riformulazione cognitiva disattiva le difese critiche, comprese quelle dei professionisti IT. E qui sta il paradosso più sottile: la tecnica è più efficace contro utenti motivati e diligenti che contro quelli distratti.

L’evoluzione in un ecosistema di varianti: da ClickFix a CrashFix, FileFix e oltre

Ciò che rende ClickFix particolarmente insidioso è la sua capacità di mutare. Dalla tecnica osservata per la prima volta nell’ottobre 2023 e documentata sistematicamente da Proofpoint nel marzo 2024 tramite l’initial access broker TA571, si è sviluppata un’intera famiglia di varianti, ciascuna adattata a un contesto specifico.

FileFix (giugno 2025, ricercatore mr.d0x, analisi SOCRadar): sposta la superficie d’attacco dalla finestra Run alla barra degli indirizzi di Esplora File di Windows. Una pagina web malevola apre silenziosamente una finestra legittima di File Explorer tramite un elemento HTML nascosto, mentre JavaScript copia un comando PowerShell mascherato nella clipboard. La vittima incolla quello che crede essere un percorso file nella barra di Explorer e il codice viene eseguito. L’intuizione è brillante: gli utenti incollano percorsi file quotidianamente, rendendo l’azione del tutto naturale.

CrashFix (febbraio 2026, Microsoft via SOCRadar): combina il crash deliberato del browser con il social engineering. Gli attaccanti distribuiscono un’estensione Chrome malevola mascherata da ad blocker legittimo che, a un certo punto, provoca il crash del browser e visualizza una falsa notifica di sicurezza che richiede l’esecuzione di un “scan” correttivo.

Variante DNS via nslookup (febbraio 2026, Microsoft Security/The Hacker News): la più recente e sofisticata. Dopo che la vittima esegue il comando iniziale, questo lancia una query nslookup verso un server DNS controllato dall’attaccante. La risposta DNS contiene, all’interno dei record, una stringa con uno script malevolo che scarica il payload finale (nell’attacco documentato, ModeloRAT). Il traffico malevolo appare come una normale risoluzione DNS, complicando enormemente la detection a livello di rete.

Variante Finger protocol (febbraio 2026, Kaspersky): l’utente viene persuaso ad aprire la riga di comando ed eseguire un comando che stabilisce una connessione via protocollo Finger (porta TCP 79) con il server dell’attaccante. Il protocollo trasferisce solo testo, ma questo è sufficiente per scaricare un ulteriore script che installa il malware. L’uso di un protocollo legacy e poco monitorato è un indicatore dell’evoluzione tattica degli attaccanti.

Variante crypto-scam via Pastebin (febbraio 2026, Kaspersky): nei commenti su Pastebin, gli attaccanti diffondono un messaggio su un presunto difetto nell’exchange Swapzone.io. La vittima viene istruita a digitare manualmente “javascript:” nella barra degli indirizzi di Chrome e incollare uno script che, anziché manipolare tassi di cambio, sostituisce gli indirizzi dei wallet Bitcoin con quelli dell’attaccante.

Altre varianti documentate includono TerminalFix, ConsentFix, GlitchFix e JackFix, ciascuna con differenze nell’approccio al social engineering ma con lo stesso principio fondante: convincere l’utente a eseguire un comando che non comprende.

Piattaforma, non solo Windows: ClickFix è cross-platform

Un errore comune è pensare a ClickFix come una minaccia esclusivamente Windows. Non lo è.

Su macOS, le campagne ClickFix dirigono le vittime verso il Terminale, dove vengono istruite a eseguire comandi che scaricano ed eseguono malware in formato .dmg. Sekoia TDR ha documentato campagne che distribuiscono Atomic macOS Stealer (AMOS) tramite ClickFix sin da maggio 2025, sfruttando landing page che impersonano Google Meet o servizi di videoconferenza. Una campagna più recente, riportata da The Hacker News, ha distribuito Odyssey Stealer – un fork evoluto di AMOS capace di esfiltare credenziali da 203 estensioni wallet browser e 18 applicazioni wallet desktop. Odyssey opera come un RAT completo, con persistenza via LaunchDaemon, polling C2 ogni 60 secondi e supporto per proxy SOCKS5.

Su Linux, le varianti ClickFix sfruttano il terminale nativo con comandi bash. Il report CIS conferma l’efficacia cross-platform come uno dei fattori chiave della diffusione della tecnica. Il dato è significativo: un singolo kit ClickFix può colpire tutti e tre i sistemi operativi con adattamenti minimi.

Quando gli APT statali copiano il cybercrime: l’adozione da parte di Russia, Iran e Corea del Nord

Il segnale più eloquente della maturità di una tecnica cybercriminale è la sua adozione da parte dei gruppi APT sponsorizzati da stati nazionali. ClickFix ha raggiunto questo traguardo in tempi record.

Proofpoint ha documentato in modo dettagliato come, in una finestra di appena tre mesi tra la fine del 2024 e l’inizio del 2025, almeno quattro gruppi APT statali abbiano integrato ClickFix nelle proprie operazioni. È importante notare che, secondo la stessa Proofpoint, ciascun attore è stato osservato con una sola campagna o ondata ClickFix, a suggerire una fase di sperimentazione piuttosto che un’adozione sistematica. Ciononostante, l’adozione parallela da parte di nazioni diverse e indipendenti è un indicatore forte dell’efficacia percepita della tecnica.

TA427/Kimsuky (Corea del Nord), noto anche come Emerald Sleet, ha utilizzato ClickFix tra gennaio e febbraio 2025 per colpire organizzazioni nel settore dei think tank che si occupano di affari nordcoreani. L’attacco iniziava con email di spear-phishing che impersonavano diplomatici giapponesi. Dopo un’interazione iniziale per costruire fiducia, una tattica caratteristica di Kimsuky, i target venivano indirizzati a un sito controllato dall’attaccante dove erano istruiti a eseguire un comando PowerShell. La catena d’infezione multi-stadio portava all’installazione di QuasarRAT, un malware commodity diffuso anche nell’ecosistema cybercriminale.

TA450/MuddyWater (Iran), alias Mango Sandstorm, ha sfruttato ClickFix in una finestra di due giorni, il 13 e 14 novembre 2024, inviando email di phishing a 39 organizzazioni prevalentemente in Medio Oriente (con la maggiore concentrazione in Emirati Arabi e Arabia Saudita). Le email impersonavano Microsoft con oggetto “Urgent Security Update Required – Immediate Action Needed” e richiedevano l’esecuzione di un comando PowerShell con privilegi di amministratore. Il comando installava silenziosamente Level, un tool RMM legittimo utilizzato per mantenere accesso persistente ai sistemi.

TA422/APT28 (Russia), il noto gruppo affiliato al GRU (attribuzione a media confidenza da CERT-UA), ha impiegato ClickFix il 17 ottobre 2024. Le email di phishing imitavano un foglio Google Spreadsheet e conducevano a un prompt reCAPTCHA che, al click, copiava un comando PowerShell e istruiva la vittima ad eseguirlo. Il comando creava un tunnel SSH e lanciava moduli Metasploit, fornendo accesso backdoor completo al sistema.

UNK_RemoteRogue (Russia), un gruppo meno noto, ha utilizzato email inviate da server Zimbra probabilmente compromessi con link a documenti Microsoft Office fasulli. La pagina conteneva istruzioni per copiare codice nel terminale, accompagnate da un tutorial YouTube su come eseguire PowerShell. Il codice JavaScript eseguiva PowerShell collegato al framework di C2 Empire. La campagna ha colpito individui in due organizzazioni collegate a un importante produttore di armamenti nel settore difesa.

Come ha sintetizzato Proofpoint, “l’incorporazione di ClickFix non sta rivoluzionando le campagne di questi attori, ma sta sostituendo le fasi di installazione ed esecuzione nelle catene d’infezione esistenti”. In altre parole, ClickFix è diventato un componente modulare, un upgrade del vettore di accesso iniziale compatibile con qualsiasi toolset offensivo.

ClickFix come vettore ransomware: il caso Interlock e la timeline di un’intrusione

ClickFix non è solo un veicolo per infostealer e RAT. È diventato un vettore di accesso per operazioni ransomware complete.

Il caso più documentato è quello del gruppo Interlock, oggetto di un advisory congiunto FBI-CISA-HHS-MS-ISAC nel luglio 2025 (AA25-203A). Interlock ha integrato ClickFix nella propria catena d’attacco, utilizzando pagine che imitano il sito di Advanced IP Scanner – uno strumento usato quotidianamente dai professionisti IT – con un falso CAPTCHA Cloudflare. La scelta del target è chirurgica: colpire chi lavora in ambito IT, chi ha privilegi elevati sulle reti aziendali.

La CISA ha confermato che l’FBI ha osservato gli attori Interlock utilizzare ClickFix come tecnica di accesso iniziale, in cui “le vittime vengono indotte a eseguire un payload malevolo cliccando un falso CAPTCHA che contiene istruzioni per aprire la finestra Run, incollare il contenuto della clipboard ed eseguire un processo PowerShell codificato in Base64”. Tra le vittime documentate, DaVita Inc. – attacco dell’aprile 2025, 1,5 terabyte di dati rubati e impatto su oltre 200.000 pazienti – e la città di St. Paul, Minnesota (luglio 2025).

Anatomia temporale di un’intrusione ClickFix

Per dare concretezza operativa, la campagna ClickFix che distribuisce Matanbuchus 3.0 documentata da Huntress nel febbraio 2026 offre una ricostruzione temporale esemplare:

  • T+0 min – La vittima riceve un’email o raggiunge una landing page con falso errore browser;
  • T+1 min – ClickFix: la vittima esegue il comando nella finestra Run. Viene lanciato msiexec.exe
    per scaricare silenziosamente un installer MSI da un dominio malevolo;
  • T+3 min – L’MSI estrae file in percorsi che imitano software di sicurezza legittimo (
    %APPDATA%\Cybernetics Ltd\Threat Fabric
    ) e utilizza binari Zillya Antivirus per eseguire il loader Matanbuchus 3.0;
  • T+10 min – Matanbuchus deploya AstarionRAT, stabilisce comunicazioni C2 mascherate come telemetria legittima;
  • T+15 min – Gli attaccanti preparano strumenti in C:\ProgramData\USOShared
    (mimando Windows Update), creano account “DefaultService” e impostano esclusioni in Defender;
  • T+40 min – Movimento laterale verso server e domain controller tramite PsExec.

Dall’esecuzione del comando ClickFix alla compromissione dei domain controller: meno di 40 minuti. Questo dato definisce la finestra operativa entro cui un SOC deve rilevare e contenere. Il dwell time di Interlock, per confronto, è in media di 15-24 giorni tra accesso iniziale e deployment del ransomware, secondo Forescout.

L’ecosistema dei payload: cosa viene distribuito e cosa è cambiato dopo il takedown Lumma

La versatilità di ClickFix come vettore di accesso iniziale si riflette nell’ampiezza del malware distribuito. Ma il panorama dei payload ha subito un cambiamento significativo nel maggio 2025.

Il caso Lumma Stealer. Lumma è stato per mesi il payload dominante nelle campagne ClickFix: distribuito tramite false pagine reCAPTCHA, malvertising e siti compromessi, con un modello Malware-as-a-Service a partire da 250 dollari al mese. Il 21 maggio 2025, un’operazione congiunta tra Microsoft Digital Crimes Unit, FBI, DOJ, Europol e Japan Cybercrime Control Center ha smantellato circa 2.300 domini dell’infrastruttura Lumma.

Microsoft aveva identificato oltre 394.000 PC Windows infetti nei soli due mesi precedenti; l’FBI stima circa 10 milioni di infezioni totali. L’effetto è stato reale ma temporaneo: secondo i dati Lumu, i nuovi indicatori di compromissione sono crollati a 57 il giorno del takedown (21 maggio), per poi risalire a 287 il giorno successivo e raggiungere picchi di 457 entro una settimana. L’ecosistema ClickFix non ha perso un colpo: i competitor (SnakeStealer, Vidar, Odyssey Stealer) hanno rapidamente colmato il vuoto e RedLine ha offerto sconti speciali agli ex affiliati Lumma.

Infostealer attualmente distribuiti: Lumma Stealer (tornato operativo con infrastruttura ricostruita), Atomic macOS Stealer (AMOS), Odyssey Stealer, Vidar, SnakeStealer e Berserk Stealer. Rubano credenziali browser, cookie di sessione, dati wallet crypto e contenuti clipboard.

RAT: AsyncRAT, NetSupport RAT, QuasarRAT, DarkGate, ModeloRAT e AstarionRAT. NetSupport RAT è particolarmente insidioso perché è un tool RMM legittimo trojanizzato, rendendo più difficile la sua classificazione come malevolo.

Ransomware: Interlock e Epsilon Red hanno utilizzato ClickFix come vettore di accesso iniziale. Epsilon Red, in una campagna globale scoperta da CloudSEK nel luglio 2025, ha impiegato pagine ClickFix che impersonavano Discord Captcha Bot e piattaforme di streaming come Twitch, Kick e OnlyFans.

Framework di C2: Metasploit (usato da APT28), Empire (usato da UNK_RemoteRogue), Cobalt Strike e Havoc C2 (documentato da FortiGuard Labs, con comunicazioni mascherate tramite Microsoft Graph API).

Il marketplace ClickFix: la commercializzazione della tecnica

La commercializzazione è il segnale definitivo che una tecnica è diventata infrastruttura criminale permanente. ClickFix ha raggiunto anche questo stadio.

Come riportato da SOCRadar e confermato da ESET, i builder ClickFix sono in vendita su marketplace e canali Telegram del dark web. Questi kit forniscono landing page weaponizzate, personalizzabili per brand e contesto, con cui anche un attaccante a bassa competenza può lanciare campagne sofisticate. Kit phishing preconfezionati, log di credenziali, builder ClickFix: la barriera d’ingresso si è abbattuta.

Jiří Kropáč, Director of Threat Prevention Labs di ESET, ha dichiarato che “la lista di minacce a cui gli attacchi ClickFix conducono cresce di giorno in giorno, includendo infostealer, ransomware, RAT, cryptominer, tool di post-exploitation e persino malware custom di attori allineati a stati nazionali”.

Mappatura MITRE ATT&CK: ClickFix nel framework offensivo

Per i professionisti che operano con MITRE ATT&CK come linguaggio comune, ClickFix attraversa diverse tattiche e tecniche del framework:

  • Initial Access: T1189 (Drive-by Compromise) per la landing page iniziale; T1566.002 (Phishing: Spearphishing Link) per le email che conducono alla pagina ClickFix;
  • Execution: T1204.001 (User Execution: Malicious Link) e T1204.004 (User Execution: Malicious Copy-Paste) – quest’ultimo citato specificamente nell’advisory CISA AA25-203A per descrivere la meccanica ClickFix; T1059.001 (Command and Scripting Interpreter: PowerShell) per la fase di esecuzione dei comandi;
  • Defense Evasion: T1027.006 (Obfuscated Files: HTML Smuggling) per l’offuscamento JavaScript nelle landing page. La manipolazione della clipboard è un componente della catena di social engineering che abilita T1204 ma non ha un mapping ATT&CK diretto autonomo;
  • Command and Control: T1071.004 (Application Layer Protocol: DNS) per la variante nslookup; T1219 (Remote Access Software) per i payload RAT/RMM.

Questa mappatura è operativamente critica: consente ai team SOC di costruire detection rule allineate alle tecniche specifiche e di verificare la copertura delle proprie capability difensive contro ogni fase della catena ClickFix.

ClickFix attacco social engineering: come rilevarlo, guida operativa per SOC analyst

La detection di ClickFix presenta sfide peculiari: non c’è un file malevolo scaricato in fase iniziale (nessun hash da bloccare al perimetro), non c’è un exploit (nessuna firma IDS), l’azione parte dall’utente (nessuna anomalia di processo iniziale evidente). Tuttavia, la catena d’attacco lascia tracce forensi specifiche e rilevabili.

Monitoraggio del registro RunMRU

Ogni comando eseguito tramite la finestra Run viene registrato nella chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
. Il repository Sigma ufficiale include una regola specifica (ID: f5fe36cf-f1ec-4c23-903d-09a3110f6bbb
) che monitora le modifiche a questa chiave cercando la presenza di URL HTTP/HTTPS – un indicatore forte di ClickFix, poiché un utilizzo legittimo della finestra Run raramente include URL completi.

Detection delle catene di processo

La catena di processo tipica di ClickFix è: explorer.exe → cmd.exe/powershell.exe → [payload]
. Questo pattern è specifico perché il comando lanciato dalla finestra Run ha Explorer come processo padre. Le regole Sigma della community (regola correlata, ID: d487ed4a-fd24-436d-a0b2-f4e95f7b2635
) rilevano specificamente le catene dove Explorer.exe genera processi con righe di comando contenenti URL o comandi PowerShell offuscati.

Indicatori chiave da monitorare nelle righe di comando:

  • Stringhe come “I am not a robot”, “reCAPTCHA”, “I am Human” nella RunMRU;
  • Esecuzioni di mshta.exe
    con parametri URL;
  • Comandi powershell -nop -w hidden -c
    originati da Explorer.exe;
  • Esecuzioni di nslookup
    verso server DNS non standard (variante DNS);
  • Invocazioni di curl
    o Invoke-WebRequest
    con URL a bassa reputazione;
  • Utilizzo del protocollo Finger (porta TCP 79).
Regole YARA per la detection in memoria

Per le varianti ClickFix che operano prevalentemente in memoria, le regole YARA possono intercettare pattern caratteristici:

ClickFix: la tecnica di social engineering, cyber attack cybercrime
Nota operativa: questa regola è un punto di partenza illustrativo che va affinato per l’ambiente specifico. La condition 2 of them
(anziché any of them
) riduce i falsi positivi, ma in contesti enterprise con uso intensivo di PowerShell per l’amministrazione Active Directory, i threshold vanno ulteriormente calibrati per evitare alert fatigue. L’integrazione con context-aware detection (es. correlazione con attività browser recente e RunMRU) migliora significativamente la precision.

Microsoft Defender: ASR, SmartScreen e AMSI

Le regole ASR (Attack Surface Reduction) di Microsoft Defender rappresentano una delle difese più efficaci. Tra le regole rilevanti per ClickFix: quella che blocca l’esecuzione di script potenzialmente offuscati, quella che impedisce l’esecuzione di contenuti scaricati da Internet, e la restrizione dei child process di mshta.exe. Si raccomanda di consultare la documentazione Microsoft aggiornata per i GUID specifici e le modalità di enforcement/audit, poiché la configurazione varia per versione e ambiente.

Microsoft Defender SmartScreen è in grado di segnalare le landing page ClickFix in Microsoft Edge, aggiungendo un livello di protezione a monte dell’esecuzione. AMSI (Antimalware Scan Interface) analizza i contenuti degli script PowerShell al momento dell’esecuzione, intercettando pattern malevoli anche quando offuscati.

Monitoraggio di rete

Per la variante DNS, il monitoraggio delle query DNS verso server non autorizzati è critico. Traffico nslookup verso IP esterni non presenti nei resolver aziendali configurati dovrebbe generare alert. Come suggerito da Sekoia, monitorare connessioni di rete iniziate da PowerShell verso domini a bassa prevalenza o con TLD sospetti è un indicatore efficace. Per la variante Finger, monitorare il traffico sulla porta TCP 79 – un protocollo sostanzialmente in disuso negli ambienti moderni.

Risposta all’incidente: cosa fare quando ClickFix è già stato eseguito

Se l’analisi degli indicatori conferma un’esecuzione ClickFix, la risposta deve essere immediata e strutturata.

Contenimento (primi 15 minuti). Isolare l’endpoint dalla rete (network isolation tramite EDR o stacco fisico). Non spegnere la macchina: le evidenze in memoria sono preziose. Verificare se l’utente ha privilegi elevati (domain admin, admin locale) per stimare il blast radius potenziale.

Analisi forense iniziale (primi 60 minuti). Esaminare la chiave RunMRU (
HKCU\...\Explorer\RunMRU
) per identificare il comando eseguito. Analizzare i log di processo (EventID 4688 con audit delle command line abilitato) per ricostruire la catena explorer.exe → shell → payload. Verificare connessioni di rete attive e recenti verso IP/domini sospetti. Estrarre artefatti dai percorsi di staging noti (%APPDATA%, %TEMP%, %ProgramData%).

Contenimento esteso. Verificare se ci sono stati movimenti laterali: controllare autenticazioni anomale nei log del domain controller, verificare nuovi account creati, esclusioni Defender impostate, sessioni RDP/PsExec. Se il payload è un infostealer, considerare compromesse tutte le credenziali salvate nei browser e i cookie di sessione: forzare il reset delle password e la revoca delle sessioni attive per l’utente colpito.

Eradication e recovery. Reimaging dell’endpoint compromesso. Rotazione delle credenziali enterprise a cui l’utente aveva accesso. Verifica e revoca dei token di sessione (particolarmente critico se vengono utilizzati servizi cloud come Microsoft 365 o Salesforce). Aggiornamento delle regole di detection con gli IoC specifici della campagna.

Strategie di mitigazione: dal contenimento tecnico alla policy organizzativa

La difesa contro ClickFix richiede un approccio multilivello che combina controlli tecnici, policy organizzative e formazione mirata.

Controlli tecnici prioritari

Disabilitare o restringere la finestra Run. Tramite Group Policy (
User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu from Start Menu
) o, in ambienti gestiti tramite Intune/Endpoint Manager, la policy equivalente nei Configuration Profiles. Questo elimina il vettore primario di ClickFix senza impattare le operazioni IT, che utilizzano terminali dedicati.

Restringere l’esecuzione di PowerShell. Implementare policy di PowerShell Constrained Language Mode e Windows Defender Application Control (WDAC) per limitare l’esecuzione di script PowerShell non firmati. La combinazione con AMSI garantisce l’analisi dei contenuti anche quando gli script sono offuscati.

Blocco dei LOLBin abusati. Tramite AppLocker o WDAC, bloccare o limitare l’esecuzione di mshta.exe
, wscript.exe
e cscript.exe
per gli utenti standard. Questi Living-off-the-Land Binaries sono i vettori di esecuzione più comuni nelle catene ClickFix.

Application allowlisting. Come raccomandato dal CIS (CIS Control 2), implementare allowlist applicative che permettano l’installazione e l’esecuzione solo di software autorizzato.

DNS filtering. Utilizzare servizi di DNS filtering per bloccare i domini malevoli noti. Il servizio Malicious Domain Blocking and Reporting (MDBR) del CIS aggiorna continuamente gli indicatori di compromissione legati a ClickFix.

Policy organizzative

Stabilire e comunicare in modo inequivocabile che nessun CAPTCHA legittimo, nessun aggiornamento software e nessuna procedura di verifica richiederà mai all’utente di aprire un terminale, una finestra Run o di incollare comandi. Questa regola, nella sua semplicità, è la contromisura più efficace contro ClickFix.

Implementare procedure di segnalazione rapida per i sospetti ClickFix, con canali dedicati e tempi di risposta definiti. Come evidenziato dalla timeline Matanbuchus, il tempo tra l’esecuzione del comando e il lateral movement verso i domain controller può essere inferiore a 40 minuti: la velocità di segnalazione è critica.

Formazione mirata: oltre l’awareness tradizionale

La formazione anti-phishing tradizionale, “non cliccare link sospetti, non aprire allegati”, non copre ClickFix. Come osservato da Todyl, ClickFix richiede un aggiornamento specifico dei programmi di security awareness che includa simulazioni di falsi CAPTCHA con richieste di esecuzione di comandi. I dipendenti devono essere addestrati a riconoscere che un prompt proveniente da una pagina web o da un’email che chiede di aprire la finestra Run (Win+R) e incollare un comando è sempre un indicatore di attacco. L’unica eccezione legittima, l’assistenza tecnica IT interna verificata tramite canale out-of-band, va esplicitamente definita nella policy aziendale.

Implicazioni normative: ClickFix e gli obblighi NIS2, DORA e GDPR

Un’infezione ClickFix che porta a esfiltrazione di dati personali configura un data breach notificabile ai sensi del GDPR (Art. 33 e 34), con obbligo di comunicazione all’Autorità Garante entro 72 ore e, nei casi di rischio elevato, anche agli interessati.

La Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 (in vigore dal 16 ottobre 2024), impone alle entità essenziali e importanti l’adozione di misure tecniche e organizzative proporzionate, che includono esplicitamente la formazione e la sensibilizzazione del personale in materia di sicurezza informatica (Art. 24 del decreto, corrispondente all’Art. 21, comma 2, lettera g della Direttiva). Una formazione awareness che non copra tecniche come ClickFix potrebbe essere considerata inadeguata rispetto allo stato dell’arte delle minacce.

Il Regolamento DORA (Digital Operational Resilience Act), applicabile dal 17 gennaio 2025, richiede alle entità finanziarie la gestione dei rischi ICT (Art. 13) con misure che includano la protezione contro il social engineering avanzato e il testing periodico della resilienza operativa. ClickFix, con la sua capacità di colpire specificamente professionisti IT con privilegi elevati (come nel caso Interlock/Advanced IP Scanner), rappresenta esattamente il tipo di minaccia che DORA intende contrastare.

Il futuro di ClickFix

La traiettoria evolutiva di ClickFix è chiara: specializzazione crescente, adattamento ai contesti e sfruttamento delle nuove interfacce.

Todyl prevede che le prossime evoluzioni sfrutteranno WebAssembly per eseguire operazioni malevole che attraversano il confine tra sandbox browser e sistema operativo, Progressive Web App (PWA) per ottenere accesso persistente e permessi espansi, e manipolazione delle estensioni browser tramite social engineering in stile ClickFix.

La variante DNS del febbraio 2026 indica una direzione precisa: mascherare il traffico malevolo all’interno di protocolli legittimi, rendendo la detection progressivamente più complessa. Quando il payload arriva tramite una risposta DNS anziché un download HTTP, i tradizionali indicatori di compromissione basati su URL e hash perdono efficacia.

È importante riconoscere anche i limiti strutturali di ClickFix. La tecnica richiede un’interazione manuale significativa – più passaggi rispetto a un exploit drive-by tradizionale, e questo ne riduce intrinsecamente il tasso di conversione. Non tutti gli utenti che vedono un falso CAPTCHA eseguiranno il comando: i dati precisi sui tassi di successo non sono pubblicamente disponibili, ma la necessità di più passaggi manuali implica un funnel con perdite significative a ogni stadio. Ciononostante, l’enorme volume di distribuzione (builder commerciali, campagne automatizzate) compensa ampiamente questa limitazione: anche un tasso di conversione basso genera un numero assoluto elevato di compromissioni.

Il fattore più preoccupante resta la commercializzazione. Con builder ClickFix disponibili sul dark web a prezzi accessibili e kit che si aggiornano con nuove varianti, la barriera d’ingresso è crollata. Non serve più essere APT28 per condurre una campagna ClickFix efficace: servono un kit da qualche centinaio di dollari e una lista di email.

ClickFix attacco social engineering: il paradigma che i difensori non possono ignorare

ClickFix rappresenta qualcosa di più profondo di una singola tecnica d’attacco. Segna il passaggio da un paradigma in cui l’attaccante deve superare le difese tecniche a uno in cui l’attaccante recluta la vittima come complice involontaria della propria compromissione.

Questa inversione ha implicazioni operative concrete. I controlli preventivi perimetrali – filtri email, sandbox, web gateway – non vedono nulla di anomalo, perché il payload non transita per quei canali. Gli EDR rilevano le attività post-esecuzione ma partono in svantaggio: l’azione iniziale è user-initiated e quindi intrinsecamente ambigua. Le soluzioni di network security vedono traffico DNS apparentemente normale nella variante più recente. Il cerchio si chiude con una constatazione scomoda: quando l’attaccante trasforma l’utente nel vettore, l’intero modello difensivo basato sulla sola prevenzione automatizzata mostra i suoi limiti strutturali.

La risposta non è abbandonare quel modello, ma integrarlo con ciò che ClickFix ha reso non più opzionale: detection comportamentale granulare (monitoraggio RunMRU, catene di processo Explorer → PowerShell, query DNS anomale), hardening degli endpoint (restrizione Run dialog, PowerShell Constrained Language Mode, blocco LOLBin), incident response con tempi compatibili con la velocità dell’attacco (40 minuti al lateral movement), e soprattutto una formazione utente che abbandoni le formule generiche per affrontare lo scenario specifico. La frase “un CAPTCHA non ti chiederà mai di aprire il terminale” vale più di cento slide sull’importanza di verificare il mittente delle email.

ClickFix attacco social engineering: tre parole che definiscono il 2025-2026 della sicurezza informatica. Non perché sia la minaccia più sofisticata, non lo è. Ma perché è la più efficace nel colpire il punto cieco più grande di qualsiasi architettura di sicurezza: l’essere umano che crede di fare la cosa giusta.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/clickfix-attacco-social-engineering/




e-Health: verso una sanità digitale

E-Health e sanità digitale rappresentano oggi il cuore pulsante dell’innovazione in ambito sanitario, ma anche il terreno più esposto alle nuove minacce informatiche. Questo contributo inaugura la serie “La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”, con l’obiettivo di analizzare come la trasformazione digitale stia rivoluzionando il sistema salute e, al tempo stesso, aprendo vulnerabilità cruciali.

Sanità digitale ed e-Health: l’impatto della trasformazione tecnologica in ambito sanitario

Nel pieno dell’attuale Darwinismo digitale l’innovazione tecnologica non è più sentita quale requisito distintivo di aziende migliori o particolarmente capaci, ma anzi quale prerequisito imprescindibile, pena il diventare anelli deboli di una catena evolutiva in cui soltanto coloro che sono dotati di capacità d’adattamento possono sopravvivere. Fra gli svariati settori assoggettati a tale digitalizzazione rientra a piena regola quello sanitario, dove i sistemi informativi ne costituiscono ad oggi indispensabile ossatura.

È innegabile invero come la sanità sia stata sottoposta negli ultimi anni ad un inarrestabile processo di innovazione, ne sono un chiaro esempio l’evolversi della telemedicina, le cartelle cliniche elettroniche, la nanorobotica chirurgica, i dispositivi wearables, od altresì l’utilizzo delle intelligenze artificiali in ambito diagnostico.

Sebbene i benefici sottesi a tale digitalizzazione siano d’immediata percezione in termini di maggiore celerità, organizzazione ed efficienza delle cure, parimenti evidenti risultano essere i rischi, le vulnerabilità e le minacce, derivanti sia da una ingente mole di dati ed informazioni in circolo, difficilmente controllabili, sia dall’utilizzo di sistemi, apparecchiature e devices spesso non congegnati seguendo elevati standard di sicurezza by design.

In particolar modo si sta attualmente assistendo all’emergere di innovative cyber-minacce, sempre più sofisticate, che privilegiano lo strumento cibernetico al fine di acquisire dati sanitari sensibili o per compromettere l’erogazione di un servizio essenziale dello Stato, pertanto la nuova “patologia” informatica che la sanità tutta si ritrova a dover fronteggiare risulta essere una rinnovata forma di criminalità informatica, contraddistinta dalle tipiche caratteristiche di impresa.

Si è ritenuto di condurre la qui presente trattazione servendosi del lessico medico, in particolar modo mutuandone l’iter operativo, per come costituito dalle fasi di anamnesi, diagnosi, passando per la terapia in atto, per giungere poi ad una prognosi del fenomeno oggetto di analisi.

Il quadro sintomatologico vede le infrastrutture critiche sanitarie del Paese, quali soggetti estremamente vulnerabili, contraddistinte sovente da arretratezza tecnologica e strutturale, dalla mancanza di risorse (sia umane che fisiche) e da una cybercultura inadeguata, nonostante siano al contempo bacini di un ingente patrimonio informativo ultrasensibile, e parimenti garanti di funzioni cruciali della società, quali salute, sicurezza e benessere comuni. Sono le statistiche a parlar chiaro: la sanità risulta essere attualmente nel mirino di svariati attacchi hacker, le aggressioni digitali indirizzate a colpire tale settore sono in costante aumento, divenendo col tempo sempre più frequenti, gravi e pervasive.

Volendo diagnosticare le principali tipologie delle anzidette minacce cyber si è ritenuto opportuno tripartirle, in base al target di riferimento, nei sottogruppi: data breach, ransomware ed intrusioni nei dispositivi medicali.

La frase celebre di Lavoisier, recitante: “nulla si crea, nulla si distrugge e tutto si trasforma” sembra trovare smentita al sopraggiungere dell’informatica, una informazione può infatti ad oggi esser distrutta, alterata od altresì duplicata infinite volte, seguendo metodi tanto leciti quanto fraudolenti. Ed è così la sanità in primis dovrebbe risultare in grado di proteggere e vigilare su valori quali la riservatezza, l’integrità e la disponibilità circa la mole di dati ultrasensibili di cui è custode, quei medesimi dati che, in forma singola quanto aggregata, si figurano attualmente come ricco bacino di approvvigionamento per il cybercrimine, data la loro ampia versatilità ed il conseguente valore economico.

La minaccia principe comunque, per larga diffusione ed impatto, rimane il ransomware, quale malware rivolto a colpire le stesse infrastrutture, cifrandone i dati, danneggiando e causando la temporanea indisponibilità dei sistemi.

I settori critici, quale quello sanitario, rappresentano terreno fertile per tale tipologia di attacco, data la loro alta propensione a pagare ingenti riscatti al fine di difendere la propria business continuity, evitando le conseguenze economico sociali devastanti che potrebbero derivare da eventuali disservizi e rallentamenti operativi. Ancora, dato il pieno approdo nell’era dell’Internet of Medical Things, non sono da escludere tutta una serie di cyberminacce impattanti su dispositivi, strumenti ed apparecchiature medicali, ossia tanto sulla disponibilità del servizio che un dato device supporta, quanto sulla riservatezza dei dati da esso raccolti, nonché altresì sulla sicurezza del paziente stesso che ne stia facendo uso.

D’altronde se ad oggi i dispositivi medicali condividono gran parte della propria architettura con quella dei normali personal computer, ossia la presenza di un sistema operativo, di una componentistica elettronica e di una interfaccia di comunicazione per connettersi con l’esterno, avranno parimenti in comune le stesse tipologie di minacce ed i conseguenti approcci di security.

Pertanto l’attuale terapia in atto, nonché conditio sine qua non della stessa innovazione tecnologica, risulta essere la cybersicurezza, intesa quale attività preventiva finalizzata a rafforzare la resilienza delle infrastrutture e la continuità dei servizi essenziali erogati.

Di conseguenza l’attuale normativa tenderà ad incentivare l’adozione di una strategia olistica di “difesa in profondità”, attuata mediante una metodologia di gestione del ciclo di vita della cybersecurity, che parta dall’analisi e dalla valutazione dei livelli di rischio, all’adozione di misure ed architetture di sistema atte alla mitigazione, gestione e recovery dai possibili incidenti, per giungere poi al continuo monitoraggio in tempo reale di sistemi e servizi sanitari, il tutto attraverso soluzioni sì intrinsecamente sicure e resilienti che, pur offrendo un alto livello di security e di continuity, non ostacolino mai la piena efficienza operativa dei sistemi medesimi.

In sede propriamente di prognosi non potrà che andarsi a delineare una sfida comune, rivolta a tutti quei soggetti appartenenti all’ecosistema sanitario, affinché siano informati, coinvolti, attivi e proattivi sul tema, riconoscendone la pressante urgenza e negando la marginalità che sovente in passato ha dovuto rivestire. Temi quali l’empowerment delle figure professionali in ambito cyber, la autonomia strategica, l’awareness e la responsabilizzazione saranno pertanto i traguardi a cui gli stakeholders della cybersecurity nazionale (istituzioni centrali o locali, nonché società civile) mireranno, attuando tutte quelle misure atte a far sì che il livello di resilienza possa incrementare e che i settori critici strategici necessari alla sussistenza dello Stato possano rivelarsi adeguatamente tutelati e protetti.

Dalla Scuola Ippocratica alla Digital Health

Si vuol dare avvio alla presente trattazione con un rapido excursus storico, senza alcuna pretesa di esaustività, sulle origini e sull’evoluzione della scienza medica, così da comprenderne il valore e l’intrinseca capacità di procedere di pari passo col progresso umano.

Una prima radicale svolta si registra nel V secolo a.C. con l’arrivo della medicina greca, la quale permise di abbandonare le precedenti pratiche rituali e divinatorie, tramutando la figura del medico da sciamano o sacerdote che fosse, a quella di un razionale pensatore, padrone di un sapere scientifico dedito all’osservazione, all’interpretazione dei fenomeni e alla ricerca delle loro cause.

Da qui Ippocrate, ritenuto il padre della medicina moderna, egli assegnava un compito puntuale alla medicina: “Descrivere il passato, comprendere il presente e prevedere il futuro”, in pratica, agile viene il richiamo: l’anamnesi, la diagnosi, la prognosi della odierna medicina.[1] Una volta divenuto controllabile, disponibile alla discussione, nonché confutazione, il sapere medico, seguito dai primordiali studi anatomici e fisiologici, divenne oggetto di studio nelle prime scuole e, a seguire, nelle università.

Seguì poi per tutto il decorso storico un costante progredire della scienza medica parallelamente da una parte alle esigenze collettive: si sviluppò la pratica chirurgica a supporto delle campagne di guerra, si approfondirono gli studi sull’origine delle malattie epidemiche a seguito dell’arrivo in Europa della cosiddetta peste nera, e d’altra parte in parallelo all’evoluzione tecnologica: la diffusione del microscopio portò allo sviluppo dell’istologia, si svilupparono le prime tecniche radiologiche, vennero implementati gli esami fisico-chimici e biologici fino ad arrivare alle moderne sperimentazioni di laboratorio.[2]

Si approda così al fenomeno che si erge a nucleo duro di questo lavoro tutto: l’avvento della rivoluzione digitale.

Non esiste settore della vita quotidiana (si pensi al settore bancario, finanziario, dei trasporti etc.) che non sia stato profondamente influenzato, modificato ed orientato dalle nuove tecnologie[3], e l’ambito sanitario non si è mostrato di certo immune da tale digitalizzazione.

Si è assistito infatti ad un mutamento del paradigma della medicina tradizionale[4]: da una sanità basata su un sistema di comunicazione burocratico-cartaceo novecentesco, in cui le informazioni viaggiavano alla velocità di gambe e mani di assistenti ed impiegati, ad un sanità digitale, caratterizzata da istantaneità, celerità, nonché contraddistinta dalla de-materializzazione e dalle connessioni sociali.

Chiaro è come alle innovazioni tecnologiche si siano simultaneamente affiancati notevoli mutamenti sociali: l’invecchiamento della popolazione, la crescita delle aspettative di cura, la prevalenza delle patologie cronico-degenerative; tutti fattori che hanno contribuito a dare alla luce nuove domande indirizzate al sistema sanitario, in merito soprattutto alle modalità di erogazione delle prestazioni sanitarie stesse.[5]

Così ad oggi la piattaforma Image-guided therapy, lanciata da Philips, permette ad un medico di osservare a distanza un paziente valutando se una operazione sia necessaria o meno; oppure il progetto di intelligenza artificiale “Watson” della IBM è capace di processare in contemporanea una immensa mole di immagini (quali radiografie, risonanze, tomografie) e informazioni (dati medici, cartelle cliniche, sperimentazioni etc.) al fine di individuare velocemente specifici percorsi diagnostico-terapeutici; ed ancora il sevizio telematico di monitoraggio da remoto Doctorplus, destinato a pazienti affetti da diabete e scompenso cardiaco, permette di inviare via bluetooth le misurazioni fatte autonomamente dai pazienti ad una centralina, che a sua volta le inoltrerà ad una piattaforma cloud a cui avranno accesso il medico, lo specialista, ed altresì la centrale infermieristica.[6]

L’elenco sarebbe assai vasto: stampanti tridimensionali, dossier e fascicoli sanitari elettronici, dispositivi wireless, servizi di telesoccorso, terapie digitali, nanotecnologia e robotica chirurgica, tutto si trova ad essere inglobato nel capiente “termine ombrello” che prende il nome di e-Health (o sanità digitale).

Definizione e aree tecnologiche di e-Health

Il termine e-Health è divenuto popolare a partire dalla fine degli anni Novanta, coniato per essere in linea con le altre “parole elettroniche” quali e-commerce, e-business nel tentativo di trasmettere quello stesso entusiasmo che già ruotava attorno al commercio elettronico e per render conto delle nuove possibilità che Internet stava gradualmente aprendo al settore sanitario.[7]

Per cogliere il carattere multidisciplinare che si cela dietro a tale terminologia si voglia di seguito riportare la definizione offerta dal ricercatore tedesco-canadese Gunter Eysebanch: “L’e-Health è un campo emergente dall’intersezione tra l’informatica medica, il sistema sanitario pubblico ed il mercato, che si riferisce ai servizi ed alle informazioni sanitarie forniti attraverso Internet e le tecnologie correlate. In senso più ampio, il termine caratterizza non solo uno sviluppo tecnico, ma anche una forma mentis, un’attitudine ed un impegno a pensare in senso globale, al fine di migliorare la sanità a livello locale, regionale e mondiale attraverso l’utilizzo di tecnologie dell’informazione e della comunicazione”.[8]

Ancora, per maggiore chiarezza, può esser utile richiamare la definizione per come fornita dalla Commissione Europea, che così recita: “L’e-Health risulta un insieme di strumenti e servizi digitali al servizio della salute e delle cure mediche, implicanti l’uso di tecnologie informatiche e di telecomunicazione (ICTs) per migliorare attività come la prevenzione, la diagnosi e il trattamento delle patologie, nonché il monitoraggio e la gestione delle abitudini e stili di vita che incidono sulla salute”.

È stato dunque il notevole sviluppo delle ICTs come pure il passaggio dal web 1.0 alla fase 2.0 ad aver ampliato il ventaglio dei servizi fruibili dai cittadini in ambito di salute, e benché l’e-Health sia un settore estremamente dinamico ed in costante evoluzione, si può qui tentare di elencarne le principali aree tecnologiche: la telemedicina (nelle sue forme di tele-diagnostica, tele-consulto, tele-assistenza, tele-chirurgia), le cartelle cliniche elettroniche, il telesoccorso, i dispositivi mobili indossabili e portabili, la robotica ed ancora la diagnostica avanzata assistita da algoritmi di intelligenza artificiale.[9]

L’esser catapultati nell’era dell’Internet of Things[10]ha permesso poi di coniare un sottoinsieme dell’e-Health : la m-Health (o mobile health) che vuole riferirsi a tutti i sensori, mobile devices, apps, e wearable technologies tramite cui l’utente interviene nella gestione della propria salute, potendo monitorare una vasta serie di parametri vitali (quali battito cardiaco, temperatura corporea, attività cerebrale, funzionamento metabolico etc.) dando così vita al fenomeno sociale del c.d. self-tracking consistente nel misurare, registrare e condividere quella grande mole di dati autoprodotti relativi al funzionamento del proprio organismo.[11]

Si vogliono concludere queste preliminari riflessioni evidenziando come i vantaggi offerti da una sanità digitale siano facilmente ed immediatamente percepibili: maggiore efficienza e qualità delle cure (si pensi all’accuratezza delle diagnosi o alla precisione delle procedure mediche etc.), riduzione dei costi economici, maggiore partecipazione informata del paziente, prevenzione delle condizioni mediche gravi, riduzione del costo umano delle patologie ed anche un generale miglioramento del benessere personale.

Se i benefici sono senza dubbio evidenti tuttavia occorre volgere l’occhio anche agli elementi più di criticità: produrre e consumare contenuti elettronici implica la circolazione di una grande mole di dati ed informazioni, difficilmente controllabili e per questo potenzialmente esposti ad elevati livelli di rischio.[12]

È stato proprio l’irrompere dell’evoluzione tecnologica a far sorgere nuove problematiche di sicurezza, rectius cyber-sicurezza, e nello scenario sanitario tali preoccupazioni si sono materializzate col verificarsi di, sempre più frequenti, attacchi informatici (miranti ad esempio alla sottrazione di dati sensibili), tali da minare tanto la privacy quanto la dignità dei pazienti.

Si avrà comunque modo di analizzare compiutamente le questioni inerenti la cyber-sicurezza nonché il cyber-crimine in ambito sanitario più avanti nella trattazione, a cui si rimanda.

La Telemedicina

Risulta preliminare, per comprendere a pieno gli argomenti che in seguito verranno esaminati, chiarire cosa si debba intendere col termine di medicina a distanza (o telemedicina), anzitutto tramite qualche cenno storico.

È agli inizi del ‘900 che si fanno risalire i primi tentativi di quella che si può definire una telemedicina ante litteram: nel 1906 Willem Einthoven, uno dei padri dell’elettrocardiografia, fu il primo a studiare un elettrocardiogramma attraverso la linea telefonica, nel 1920, negli Stati Uniti, alcuni medici vennero ingaggiati per l’assistenza sanitaria via radio alle navi che avevano emergenze mediche, nel 1955 l’Istituto Psichiatrico del Nebraska, tramite un collegamento che utilizzava la televisione a circuito chiuso, realizzò consulti fra specialisti per finalità didattiche nonché per effettuare terapie di gruppo, e ancora nel 1971 fu utilizzata, per la prima volta, la trasmissione satellitare.[13]

Indubbiamente però fu l’avvento di Internet a determinare una svolta rivoluzionaria: grazie alla rete infatti si è reso possibile registrare ed inviare enormi quantità di immagini, dati e audio consentendone l’accesso ad un numero praticamente illimitato di persone contemporaneamente, ed è così che la telemedicina ha potuto superare la prorpia fase di sperimentazione per radicarsi sempre di più nella quotidianità, modificando e migliorando il sistema socio-sanitario tutto.

Pertanto la telemedicina altro non è che un nuovo modo di concepire l’attività del medico, il quale grazie all’ausilio delle nuove tecnologie, riesce a controllare e monitorare i pazienti senza che questi ultimi siano fisicamente presenti: non è più il paziente a spostarsi, ma le informazioni che lo riguardano.

Seppur risulti difficile darne un’univoca definizione, essendo una disciplina in costante e dinamica evoluzione, si possono richiamare le parole di sintesi utilizzate nel 1997 dall’Organizzazione Mondiale della Sanità: “La telemedicina è l’erogazione dell’assistenza sanitaria, quando la distanza è un fattore critico, da parte degli operatori sanitari; ed a tal fine sono utilizzate le tecnologie informatiche e le telecomunicazioni per lo scambio di informazioni per la diagnosi, la terapia, la prevenzione di patologie, per l’istruzione permanente degli operatori sanitari e per la ricerca e lo studio in tutti i settori di interesse per il miglioramento dello stato di salute dell’individuo e della comunità”.

Si ricava dunque che la prestazione in telemedicina non sostituisce la prestazione sanitaria tradizionale, ma la integra per potenzialmente migliorarne efficacia, efficienza ed appropriatezza, pur conservando le implicazioni di un qualsiasi atto medico dal punto di vista professionale, etico, nonché legale.

Per provvedere ivi ad una rapida classificazione, i servizi di telemedicina possono essere suddivisi in tre differenti macro-categorie: la telemedicina specialistica, la telesalute e la teleassistenza.[14]

Per quanto concerne la prima macro-categoria, a seconda del tipo di attori coinvolti (che siano medico-paziente od anche medico-altri operatori sanitari) la telemedicina specialistica segue tre distinte modalità:

  1. La televisita: che consente al medico di vedere ed interagire a distanza col paziente, in tempo reale o differito, e ciò che scaturirà da tale rapporto sarà proprio un atto diagnostico contenente prescrizioni di farmaci o di terapie;
  2. Il teleconsulto: un’attività di consulenza a distanza fra medici finalizzata ad ottenere pareri e consigli, in ragione di una specifica competenza medica, nella scelta di una terapia legata alla presa in carico di un paziente;
  3. La telecooperazione sanitaria: ossia l’assistenza concreta fornita da un medico (od altro operatore sanitario) ad un altro medico impegnato in un determinato atto sanitario, ed è il termine utilizzato soprattutto per la consulenza fornita a quanti prestano un soccorso d’urgenza.

La seconda macro-categoria, quella della telesalute, comprende i sistemi che collegano i pazienti, in particolar modo coloro affetti da malattie croniche, con gli stessi medici affinché questi ultimi possano prestare loro assistenza a livello diagnostico, di monitoraggio, di gestione e di responsabilizzazione. Si rende necessario allora tanto un ruolo attivo del medico quanto del paziente che monitorerà e trasmetterà i propri dati (solitamente i parametri vitali di base) provvedendo alla propria autocura, autonomamente o con l’ausilio di un operatore sanitario.

Infine la terza macro-categoria è quella della teleassistenza, un sistema socio-assistenziale per la presa in carico di una persona anziana o fragile, che vedrà la gestione di allarmi, l’attivazione di servizi di emergenza o chiamate di supporto, chiaro è come quest’ultima abbia contenuto prevalentemente sociale, con confini prettamente sfumati sul versante sanitario, con cui si dovrà in ogni caso connettere al fine di garantire una vera e propria continuità assistenziale.

Ancora una volta appaiono chiari e manifesti i benefici sottesi allo sviluppo e all’adozione di tecniche e strumenti di telemedicina, quali: l’equità di accesso all’assistenza sanitaria (si pensi alle aree rurali poco collegate alla città di riferimento, alle aree di montagna, alle piccole isole; od anche al miglioramento dell’assistenza sanitaria in carcere), una migliore qualità dell’assistenza atta a garantire continuità delle cure (si pensi al telemonitoraggio come strumento per migliorare la vita dei pazienti cronici attraverso soluzioni di auto-gestione), una migliore efficacia, efficienza ed appropriatezza delle cure prestate (si pensi al confronto multidisciplinare fra medici, all’ausilio per i servizi di emergenza-urgenza), la riduzione dei tempi di attesa e del ricorso alla ospedalizzazione, nonché la possibilità di ottimizzare l’uso delle risorse disponibili.

Altrettanto ovvia però appare l’esigenza di evitare un uso improprio della telemedicina: è indispensabile che i professionisti sanitari ed i pazienti siano adeguatamente formati e preparati a riguardo, così da garantire in primo luogo la sicurezza dei dati e di conseguenza la privacy degli individui.

Si può già anticipare in questa sede che il semplice utilizzo di ICTs per il trattamento di informazioni sanitarie o la condivisione online di tali dati non costituiscono di per sé strumenti di telemedicina, per esser più chiari: non rientrano nella telemedicina social network, forum, newsgroup, posta elettronica od altri canali non autorizzati.

A tal proposito si riportino a seguire le parole di Peter Zeggel, CEO di arztkonsultation.de, il principale fornitore di telemedicina in Germania: “L’utilizzo di app che non sono progettate specificatamente per il settore sanitario comporta dei rischi. Le applicazioni di telemedicina sono progettate e certificate specificatamente per salvaguardare i dati personali sensibili. Bypassare questo alto livello di protezione significa rischiare di incorrere in una perdita di fiducia, nonché in misure disciplinari e sanzioni pesanti”.

Da ultimo si sottolinei come ad oggi questo tipo di problematiche appaiano del tutto attuali: un report del 2021 commissionato da Kaspersky ad Arlington Research, condotto a livello globale e composto da 389 interviste fra coloro che operano nel campo della telemedicina ha dato alla luce tali risultati: il 54% dei fornitori di servizi di telemedicina concordano sul fatto che alcuni dei propri medici conducano abitualmente sessioni di medicina a distanza utilizzando app non specificamente progettate a tal fine quali FaceTime, Facebook Messenger, WhatsApp e Zoom.

Inoltre sentimento diffuso fra gli operatori sanitari risulta essere proprio il timore di non riuscire a garantire la sicurezza e riservatezza dei dati sensibili: solo tre intervistati su dieci (30%) si dichiara infatti fiducioso che la propria azienda sanitaria sia in grado di intervenire efficacemente e bloccare eventuali intrusioni e violazioni informatiche.

Ciò inevitabilmente si riverbera anche sul versante dei pazienti: il 52% degli operatori sanitari ha sperimentato infatti casi di pazienti che si sono rifiutati di tenere videochiamate proprio per la diffidenza verso le tecnologie ed il timore in ambito di sicurezza e protezione dei dati.[15]

Il Fascicolo sanitario elettronico

Un referto scaturito da una sopraccitata prestazione di telemedicina e firmato digitalmente dal medico, dovrà poter essere condiviso, su richiesta del paziente, con altri sanitari in formato digitale, usando le più aggiornate soluzioni tecnologiche, fra cui il Fascicolo sanitario elettronico (d’ora in avanti indicato in breve come FSE). Decisive appaiono in materia nozioni quali la comunicabilità e l’interconnessione: le prestazioni sanitarie a distanza e il FSE possono e devono comunicare l’un l’altro in modo tale da innescare un flusso continuo di informazioni tali da consentire ai sanitari di poter sempre disporre di un quadro clinico corretto e il più esaustivo possibile rispetto i dati clinici di un paziente.

Il FSE è stato istituito con il decreto legge 179/2012, coordinato con la legge di conversione 221/2012, che si vuol qui richiamare a livello definitorio: “Il fascicolo sanitario elettronico è l’insieme dei dati e documenti digitali di tipo sanitario e sociosanitario generati da eventi clinici presenti e trascorsi, riguardanti l’assistito, riferiti anche alle prestazioni erogate al di fuori del Servizio sanitario nazionale”. [16]

La normativa de quo prosegue poi delineandone in dettaglio le finalità : “Il Fascicolo sanitario elettronico è istituito dalle regioni e province autonome […] nel rispetto della normativa vigente in materia di protezione dei dati personali, a fini di: prevenzione, diagnosi, cura e riabilitazione; studio e ricerca scientifica in campo medico, biomedico ed epidemiologico; programmazione sanitaria, verifica delle qualità delle cure e valutazione dell’assistenza sanitaria”. Si noti come delle tre finalità, soltanto la prima sia rivolta propriamente alla cura del cittadino, le rimanenti due riguardano invece la gestione della sanità pubblica, sia nella accezione di ricerca e sviluppo, sia per quanto riguarda la governance nazionale del sistema sanitario.[17]

Nel FSE confluiranno pertanto sia dati sanitari che amministrativi riferibili all’assistito, quali: dati identificativi del paziente; documenti sanitari e socio-sanitari (referti di laboratori, prescrizioni di medicinali, terapie, anamnesi, verbali di pronto soccorso etc.); il Patient Summary (anche “profilo sanitario sintetico”) documento atto a riassumere la storia clinica del paziente e la sua situazione corrente, curato ed aggiornato dal medico di medicina generale; ed ancora vi sarà una autonoma sezione dedicata specificatamente al cittadino in cui inserire dati ed informazioni personali (dati sul nucleo famigliare, attività sportiva etc.).[18]

Il sopraindicato decreto legge 179/2012 all’art 12, comma 3-bis prevedeva che il FSE potesse essere alimentato esclusivamente sulla base del consenso libero e informato da parte dell’assistito, il quale avrebbe avuto quindi la facoltà di permettere o meno la costituzione del proprio FSE, come anche di decidere se e quali dati relativi alla propria salute inserire nel fascicolo medesimo.

Tale comma è stato tuttavia abrogato dal decreto legge 34/2020 recante “Misure urgenti in materia di salute e di sostegno al lavoro e all’economia” (c.d. decreto “Rilancio”), con simile abrogazione si è voluta facilitare l’alimentazione del FSE, in precedenza “limitata” dalla necessità del consenso, permettendo che in esso vadano a confluire direttamente i documenti sanitari appartenenti all’interessato (anche se generati da strutture sanitarie private o situate al di fuori della propria regione di appartenenza).[19]

Con tale mutamento allora si è voluta garantire una maggior completezza del FSE, ma di certo ciò non andrà ad incidere in alcun modo sul versante della privacy poiché l’accesso al FSE potrà comunque avvenire solamente previo consenso del soggetto interessato: sarà il cittadino invero a dover fornire l’autorizzazione affinché gli esercenti professioni sanitarie, sia pubblici che privati, possano accedere ai contenuti del FSE che lo riguardano, senza il suo consenso pertanto il FSE rimarrebbe comunque inaccessibile. A ciò fanno ovvia eccezione le Regioni ed il Ministero della Salute, che potranno trattare tali dati sanitari per finalità di governo e di ricerca, purchè in forma anonima e nel rispetto dei principi di indispensabilità, necessità, pertinenza e non eccedenza.

Ad ogni modo si specifichi ancora come la normativa privacy non sarà mai di intralcio alla tutela della salute: sia il decreto legge 179/2012, sia il GDPR prevedono infatti la possibilità di accedere al FSE nel caso in cui il paziente non sia nelle condizioni di prestare il suo consenso, ma l’accesso risulti comunque necessario per salvaguardare la propria vita o quella di terzi.

I brevi cenni che si sono fin qui voluti fornire miravano essenzialmente a presentare il FSE quale il vero e proprio fulcro della connected care italiana, un nodo di aggregazione e condivisione di dati, documenti, analisi e statistiche.

Ciò tornerà senz’altro utile al prosieguo della trattazione dal momento che, come si vedrà, i dati sanitari protetti, quali informazioni altamente sensibili, non sono immuni da possibili interessi di mercato e possono pertanto rivelarsi ricco bacino di approvvigionamento per il cybercrimine.[20]

Nuovi scenari nell’e-Health: la Telechirurgia

Dal nome dall’aviatore americano, Charles Lindbergh, che effettuò il primo volo senza scalo attraverso l’Oceano Atlantico, è passata alla storia come “Operazione Lindbergh”, uno dei primi interventi chirurgici a distanza eseguito nel Settembre 2001 da un team di chirurghi con sede a New York su di un paziente ospedalizzato a Strasburgo.[21]

È dalla dimostrazione della fattibilità di tale procedura transatlantica che si sono poste le basi per la globalizzazione delle procedure chirurgiche: l’impiego della chirurgia robotica è ad oggi una realtà clinica invero pienamente inserita nella telemedicina, che va guadagnandosi sempre maggiori consensi.

Per telechirurgia in particolare si intende in una tecnica operatoria che consente al medico di eseguire un intervento chirurgico a distanza, ossia su di un paziente che non si trova fisicamente nello stesso luogo. L’operatore umano infatti si servirà di una apposita console, fornita di un monitor atto a consentire l’osservazione continua della regione operatoria, andando ad eseguire così tutte le varie manovre necessarie dell’intervento che, teletrasmesse, verranno con estrema precisione ripetute sul paziente da un robot chirurgico.[22]

La chirurgia a distanza allora, avvalendosi di reti wireless e tecnologie robotiche, potrebbe consentire la realizzazione di interventi chirurgici di alta qualità in luoghi con scarsa assistenza medica (si pensi ad aree rurali, o zone di guerra) eliminando la necessità di viaggi a lunga distanza; o permettere la collaborazione in tempo reale fra chirurghi situati in diversi centri medici; od ancora permettere di migliorare l’accuratezza chirurgica (ad esempio il tremore fisiologico dell’operatore può essere annullato).[23]

Si è pensato di inserire anche tale argomento in trattazione dal momento che il cyber-crimine in ambito sanitario non va ad esaurirsi nella mera violazione e sottrazione di dati ed informazioni sanitarie ultrasensibili, ma anzi la stessa telesurgery non si presenta immune da diversi aspetti critici legati proprio alla sua cyber-sicurezza.

A tal proposito, già in questa sede, si può riportare una sperimentazione portata avanti nel 2015 dalla ricercatrice Tamara Bonaci e dal suo team dell’Università di Washington, mirante ad analizzare le possibili minacce legate al settore della telechirurgia, in particolar modo guardando ai possibili attacchi informatici che possono andare ad interferire direttamente sul comportamento di un Telerobot.[24]

Bonaci e i suoi collaboratori hanno in tale sede testato il robot per la telechirurgia denominato Raven II, analizzandone la capacità operativa sotto attacco informatico.

Il sopradetto sistema Raven II risulta composto da due bracci chirurgici, controllati a distanza dall’operatore umano, progettato con l’obiettivo di lavorare con la massima efficienza in condizioni estreme, ed è proprio tale connotato a far sorgere una prima complicazione: i sistemi di telesurgery, dovendo operare in aree a rischio dispongono infatti di connessioni condivise, nonché di bassa qualità, con ovvie ripercussioni per quanto concerne privacy e sicurezza.

Nel condurre la sperimentazione il team di ricerca de quo è riuscito ad intromettersi nei comandi del robot, verificando la possibilità di prenderne il controllo, come anche di modificarne comandi ed operazioni effettuate nel corso dell’intervento chirurgico simulato.

Così spiega Bonaci: “A causa della natura aperta e incontrollabile delle reti di comunicazione diventa facile per malintenzionati od hacker interrompere o interferire con la comunicazione tra un robot e un chirurgo”.

Simulando un possibile attacco hacker pertanto i ricercatori sono stati quindi in grado di cancellare, riordinare e ritardare i comandi inviati tramite la console, di portare il telerobot ad uno stato di blocco ed altresì di prenderne il completo controllo.

Non può che essere allora una attuale preoccupazione quella di garantire requisiti minimi di sicurezza anche e soprattutto nell’ambito della telechirurgia, perché gravi ed irreversibili sarebbero le conseguenze di un reale cyber attack laddove vi sia concretamente la vita di un paziente sul tavolo operatorio.

L’analisi ha evidenziato come l’e-Health sia ormai un pilastro imprescindibile della sanità moderna, capace di migliorare cure, accessibilità ed efficienza, ma al tempo stesso vulnerabile alle minacce del cybercrime sanitario. Le nuove sfide riguardano la protezione dei dati ultrasensibili, la continuità dei servizi e la fiducia dei pazienti. Nel prossimo approfondimento della serie ci concentreremo proprio sul tema cruciale del trattamento dei dati sanitari, per comprendere come la gestione, la sicurezza e la governance delle informazioni cliniche possano garantire il futuro della sanità digitale.

Per un inquadramento più completo, invitiamo a consultare il white paper gratuito di Maria Vittoria Zucca dal titolo “La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] R. Brischetto, F. Cosmi, Imparare il metodo scientifico. Da Ippocrate a Garattini, Edizioni LSWR, Milano, 2022.

[2] Jean-Charles Sournia, Storia della Medicina, Edizioni Dedalo S.r.l., Bari, 1994.

[3] A. Antonilli, “Sicurezza informatica e trattamento dei dati in ambito sanitario”, in Salute e società, XVI, suppl. 3/2017, pp. 84-100.

[4] M. Moruzzi, “La nuova cultura della sanità dematerializzata”, in Recenti Progressi in Medicina, vol. 105, n.11, 2014, pp. 407-409.

[5] C. Cipolla, A. Ardissone, “Un paradigma cittadino-centrico nella m-Health”, in Salute e società, XVI, n.2, 2017, pp. 12-28.

[6] Ivi, p.15.

[7] G. Eysebench, “What is e-Health”, in Journal of Medical Internet Research, 3(2), 2001.

[8] Ibidem.

[9] Con l’espressione “web 1.0” si suole indicare un primordiale flusso comunicativo di tipo unidirezionale in cui viene fortemente limitata la possibilità di interazione tra una azienda ed i propri clienti, invece col passaggio allo stadio del “web 2.0” si approda ad una comunicazione di tipo partecipativo, contraddistinta dai tre pilastri di: interazione, condivisione e partecipazione.

[10] “Internet delle cose” è una espressione coniata nel 2011 da Dave Evans, il quale ne parlava in questi termini “L’internet delle cose indica semplicemente il momento in cui a Internet hanno incominciato ad esser più cose (o oggetti) che persone”.

[11] C. Cipolla, A. Ardissone, op. cit. supra a nota 5, p.21.

[12] A. Antonilli, op. cit. supra a nota 3, p. 88.

[13] E. Manzi, S. Selvaggi, V. Sica, “Tecnologie informatiche e delle comunicazioni in medicina: la telemedicina”, in V. Sica, S. Selvaggi (a cura di), La telemedicina. Approccio multidisciplinare alla gestione dei dati sanitari, Springer-Verlag, Milano, 2010, pp. 1-9.

[14] Linee di indirizzo nazionali sulla Telemedicina approvate nella seduta del 10 Luglio 2012, dall’Assemblea generale del Consiglio Superiore di Sanità.

[15] Kaspersky, Telehealth take-up: the risks and opportunities, healthcare report 2021.

[16] Legge 17 Dicembre 2012 n. 221, “Conversione in legge con modificazioni del decreto-legge 18 Ottobre 2012 n. 179, recante ulteriori misure urgenti per la crescita del Paese”, entrata in vigore il 19 Dicembre 2012.

[17] NETPATROL, “Sanità digitale e telemedicina: privacy, cybersicurezza e intelligenza artificiale nella sanità digitale”, in GDPR insight series, n° 6, 2020, pp. 2-16.

[18] G. Ducci, “Pianificare la comunicazione dei servizi di e-health: attori, sistemi, relazioni. Il caso del fascicolo sanitario elettronico”, in Sociologia della comunicazione, fascicolo 48, 2014, pp. 26-37.

[19] Decreto legge 19 Maggio 2020, n. 34, “Misure urgenti in materia di salute, sostegno al lavoro ed all’economia, nonché di politiche sociali connesse all’emergenza epidemiologica da COVID-19”, convertito con modificazioni dalla legge 17 Luglio 2020, n.77.

[20] Peraltro non si confonda il Fascicolo sanitario elettronico con il diverso strumento del Dossier sanitario elettronico (o DSE), la cui gestione viene affidata di norma ad un unico titolare del trattamento, con la finalità di rendere più efficienti i processi di diagnosi e di cura del paziente all’interno di un’unica struttura sanitaria, consentendo ai diversi professionisti che vi operano di accedere a tutte le informazioni cliniche relative a precedenti interventi (ricoveri, visite ambulatoriali etc.) purché siano effettuati dall’assistito presso quella medesima struttura.

[21] J. Marescaux, J. Leroy et al., “Transatlantic robot-assisted telesurgery”, in Nature, vol. CDXIII, n. 6854, September 2001, pp. 379-380.

[22] E. Santoro, V. Pansadoro, La chirurgia robotica in Italia : indagine nazionale, 2011.

[23] Ovvio è che il chirurgo a sua volta riceverà informazioni dal campo operatorio, come immagini stereoscopiche tridimensionali e stimoli pressocettivi, che gli permetteranno di operare avendo l’illusione di essere in sala operatoria.

[24] T. Bonaci, To make a robot secure: An experimental analysis of cyber security threats against teleoperated surgical robotics, Department of Engineering, University of Washington, 2015.

Profilo Autore

Maria Vittoria Zucca, laureata con lode in Giurisprudenza presso l’università degli Studi di Trento, è attualmente dottoranda nel Programma di Dottorato di Interesse Nazionale in Cybersecurity, con istituzione capofila la Scuola IMT Alti Studi di Lucca, ed è affiliata alla Scuola Superiore Sant’Anna, presso l’Istituto Dirpolis (Diritto, Politica e Sviluppo).
La sua attività di ricerca si concentra sulla prevenzione, l’indagine ed il contrasto della criminalità informatica, includendo le discipline del diritto penale dell’informatica e della criminologia digitale. Su questi temi è autrice di diverse pubblicazioni scientifiche e partecipa regolarmente a conferenze nazionali e internazionali.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/e-health/




EDR killer BYOVD: il ransomware che spegne le difese endpoint

EDR killer BYOVD non è un concetto nuovo. Ma nel febbraio 2026 è diventato qualcosa di diverso: non più una tecnica di nicchia riservata ai gruppi APT più sofisticati, bensì lo strumento standard – quasi banale – con cui il ransomware acceca le difese endpoint prima ancora di cifrare il primo file.

Nelle prime due settimane di febbraio 2026 sono accaduti due eventi che, presi insieme, segnano un punto di non ritorno. Il primo: Huntress ha documentato un’intrusione in cui gli attaccanti hanno utilizzato un driver del tool forense EnCase – con certificato scaduto nel 2010 e successivamente revocato – per terminare 59 prodotti di sicurezza endpoint dalla modalità kernel. Il secondo: il Symantec and Carbon Black Threat Hunter Team ha rivelato che un ransomware emergente battezzato Reynolds ha integrato un driver vulnerabile direttamente nel proprio payload, fondendo evasione difensiva e cifratura in un unico binario.

La convergenza di questi due episodi racconta una storia che va ben oltre il singolo incidente. Racconta il fallimento strutturale di un modello di sicurezza endpoint su cui le organizzazioni hanno investito miliardi, e che gli attaccanti stanno imparando a spegnere con un driver firmato di vent’anni fa.

Che cos’è il BYOVD e perché funziona ancora nel 2026

La tecnica Bring Your Own Vulnerable Driver – BYOVD – è concettualmente disarmante nella sua semplicità. L’attaccante non scrive un driver malevolo, non cerca di aggirare la firma digitale, non sfrutta uno zero-day nel kernel. Porta con sé un driver perfettamente legittimo, firmato da un vendor riconosciuto, che contiene una vulnerabilità nota. Poiché il driver è firmato, Windows lo carica senza protestare. Una volta in esecuzione nello spazio kernel, l’attaccante sfrutta la falla del driver per terminare i processi di sicurezza con privilegi di sistema.

Il meccanismo tecnico si articola in passaggi precisi. Il malware deposita il driver vulnerabile su disco, tipicamente mascherandolo come componente OEM legittimo. Registra il driver come servizio kernel di Windows, garantendosi persistenza al riavvio. Una volta caricato, il driver espone un’interfaccia IOCTL (Input/Output Control) che consente ai processi in user-mode di inviare comandi con privilegi kernel. A quel punto, il malware compila un elenco dei processi di sicurezza da terminare – nell’incidente documentato da Huntress, l’elenco comprendeva 59 prodotti tra EDR e antivirus – e li uccide uno per uno, in un ciclo continuo con intervallo di un secondo che impedisce qualsiasi riavvio automatico del processo protettivo.

Il risultato è che l’attaccante opera “al buio”: nessun alert, nessuna telemetria, nessun rilevamento comportamentale. L’EDR non è stato aggirato; è stato spento.

Ciò che rende questa tecnica devastante nel 2026 non è la sua novità – il BYOVD è documentato da anni nel framework MITRE ATT&CK sotto T1068 e T1562.001 – ma la sua industrializzazione. Come ha osservato Broadcom/Symantec nel report sul ransomware Reynolds, il BYOVD è oggi di gran lunga la tecnica di evasione difensiva più utilizzata dagli operatori ransomware.

Il caso Huntress: un driver forense del 2006 che spegne 59 EDR nel 2026

All’inizio di febbraio 2026, i ricercatori di Huntress hanno risposto a un incidente che illustra perfettamente il paradosso del BYOVD. Gli attaccanti hanno ottenuto l’accesso iniziale tramite credenziali compromesse di una VPN SonicWall SSL priva di autenticazione multifattore. Fin qui, nulla di sorprendente: credenziali rubate e assenza di MFA sono il biglietto d’ingresso standard per il ransomware nel 2026.

La fase successiva è quella che merita attenzione. Gli attaccanti hanno distribuito un EDR killer personalizzato che conteneva, codificato al suo interno, il driver kernel EnPortv.sys – un componente dell’EnCase forensic suite sviluppato da Guidance Software. Questo driver era stato firmato con un certificato emesso il 15 dicembre 2006, scaduto il 31 gennaio 2010 e successivamente revocato.

Eppure Windows lo ha caricato. Come è possibile?

La risposta sta in una scelta architetturale che Microsoft ha fatto nel 2015 per garantire la retrocompatibilità. A partire da Windows 10 versione 1607, tutti i nuovi driver kernel devono essere firmati tramite il Hardware Dev Center di Microsoft. Tuttavia, per non rompere il software legacy, è stata introdotta un’eccezione: i driver firmati con certificati emessi prima del 29 luglio 2015, che si concatenano a un’autorità di certificazione cross-signed supportata, possono ancora essere caricati. Il driver EnCase rientra pienamente in questa eccezione.

C’è un secondo meccanismo che sigilla il problema. Come hanno spiegato i ricercatori di Huntress: quando il codice è firmato con un timestamp, Windows valida la firma rispetto al momento in cui è stata creata, non rispetto alla data corrente. Poiché il driver è stato timestampato quando il certificato era ancora valido, la firma rimane valida a tempo indeterminato. Il kernel, inoltre, non verifica le Certificate Revocation List al boot, per ragioni di performance.

Il risultato netto è che un driver con certificato scaduto da 16 anni e revocato continua a caricarsi ed eseguirsi nello spazio kernel di qualsiasi sistema Windows moderno.

Una volta caricato, il driver esponeva l’interfaccia IOCTL 0x223078 (KillProc). Il componente in user-mode apriva un handle verso il dispositivo del driver (\.\OemHwUpd) e inviava i PID dei processi target tramite DeviceIoControl. Il driver, operando in kernel-mode, invocava ZwOpenProcess con accesso PROCESS_TERMINATE seguito da ZwTerminateProcess. Quando il codice kernel-mode chiama le funzioni Zw*, il wrapper imposta PreviousMode a KernelMode, segnalando che i parametri provengono da una sorgente fidata: Windows salta interamente la validazione di sicurezza che applicherebbe ai chiamanti in user-mode.

L’EDR killer compilava un elenco interno di 59 processi di sicurezza associati ai principali vendor – tra cui Avast, CrowdStrike Falcon, Cortex XDR, Sophos, HitmanPro.Alert e Symantec – utilizzando hash dei nomi dei processi per l’identificazione. Il kill loop, eseguito con un intervallo di un secondo, terminava immediatamente qualsiasi processo di sicurezza che tentasse di riavviarsi.

Un dettaglio tecnico particolarmente ingegnoso: l’EDR killer non conservava il driver come byte grezzi. Utilizzava uno schema di codifica basato su un dizionario di 256 parole inglesi incorporate nel binario, dove ogni parola corrispondeva a un valore di byte specifico. Il payload codificato appariva come testo inglese innocuo, eludendo efficacemente gli strumenti di analisi statica. Una volta decodificato, il malware scriveva il driver su disco sotto un percorso che imitava un componente OEM legittimo, nascondeva il file e copiava i timestamp da un file di sistema reale per integrarsi con l’ambiente.

L’attacco è stato interrotto prima del deployment del ransomware, ma il messaggio è inequivocabile: con un driver di vent’anni fa, un attaccante può accecare l’intero stack di sicurezza endpoint.

Reynolds: quando il ransomware porta l’EDR killer nel proprio DNA

Se l’incidente documentato da Huntress rappresenta il modello classico – EDR killer come tool separato, dispiegato prima del ransomware – il caso Reynolds, analizzato dal Symantec and Carbon Black Threat Hunter Team e reso pubblico il 10 febbraio 2026, segna un’evoluzione tattica significativa.

Reynolds è una famiglia ransomware emergente che ha integrato il componente BYOVD direttamente all’interno del payload di cifratura. Il driver vulnerabile utilizzato è NSecKrnl di NsecSoft, affetto dalla vulnerabilità CVE-2025-68947, che consente la terminazione arbitraria dei processi senza verifica dei permessi adeguati. Lo stesso driver era stato precedentemente usato dal gruppo Silver Fox per distribuire il RAT ValleyRAT.

Al momento dell’esecuzione, Reynolds deposita il driver NSecKrnl.sys in una directory di sistema, lo carica nello spazio kernel e lo utilizza per terminare i processi di sicurezza di Avast, CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Sophos e Symantec Endpoint Protection. Solo dopo aver reso cieche le difese, il ransomware avvia la routine di cifratura, aggiungendo l’estensione “.locked” ai file compromessi.

L’integrazione presenta vantaggi tattici evidenti. Come ha osservato Dick O’Brien, principal intelligence analyst di Symantec, rilasciare un unico file anziché due è più silenzioso e riduce le probabilità di rilevamento. Inoltre, eliminando l’intervallo temporale tra il dispiegamento dell’EDR killer e l’esecuzione del ransomware, si chiude la finestra in cui i difensori potrebbero intervenire.

Tuttavia, questa integrazione comporta anche un rischio per l’attaccante: consolidare evasione difensiva e cifratura in un’unica catena di esecuzione aumenta la densità comportamentale del binario, incrementando la probabilità di rilevamento da parte di soluzioni con monitoraggio comportamentale avanzato. Non a caso, nell’incidente analizzato da Symantec, il prodotto endpoint dell’azienda ha continuato a funzionare nonostante il tentativo di terminazione. Sophos, da parte sua, ha dichiarato a The Hacker News di disporre di protezioni di blocco contro questo specifico driver dal novembre 2025 e di safeguard proattivi contro il payload da diversi anni – un’indicazione che i vendor più maturi stanno evolvendo le difese, ma anche che la corsa tra attaccanti e difensori è continua.

Dopo l’iniziale attribuzione a Black Basta – basata sulla somiglianza delle TTP – un’analisi più approfondita ha portato Symantec a classificare Reynolds come famiglia ransomware distinta. Non è chiaro se rappresenti un rebrand o uno spin-off di Black Basta, ma l’evoluzione tattica che porta con sé è indipendente dall’attribuzione: il BYOVD integrato nel payload è una tendenza, non un caso isolato.

Lo stesso report di Broadcom ha osservato che la pratica di incorporare la componente di evasione difensiva direttamente nel payload ransomware non è del tutto inedita: era stata documentata in un attacco Ryuk nel 2020 e in un incidente legato a un ransomware meno noto chiamato Obscura alla fine di agosto 2025. Tuttavia, ciò che distingue Reynolds è la maturità dell’integrazione e il suo posizionamento in un ecosistema dove il BYOVD embedded potrebbe diventare requisito standard per attrarre affiliati nei programmi RaaS.

EDRKillShifter e la collaborazione cross-gang: il BYOVD come lingua franca del ransomware

Il fenomeno dell’EDR killer BYOVD non si esaurisce nei due episodi di febbraio 2026. Per comprenderne la portata sistemica, è necessario guardare a ciò che ESET ha documentato nel marzo 2025: la scoperta di EDRKillShifter, un tool EDR killer sviluppato e mantenuto da RansomHub come parte integrante del proprio programma Ransomware-as-a-Service.

EDRKillShifter è un software specializzato che utilizza la tecnica BYOVD per disabilitare i prodotti EDR sugli endpoint compromessi. Ciò che lo rende particolarmente significativo è la decisione di RansomHub di offrirlo direttamente ai propri affiliati – una scelta rara nel panorama RaaS, dove tipicamente gli affiliati devono procurarsi autonomamente gli strumenti per l’evasione difensiva.

La scoperta più rilevante di ESET, tuttavia, riguarda la diffusione cross-gang dello strumento. Tracciando l’uso di specifici campioni di EDRKillShifter, i ricercatori hanno identificato un singolo threat actor – denominato QuadSwitcher – che ha condotto attacchi per conto di quattro diverse operazioni ransomware: RansomHub, Play, Medusa e BianLian. Tutti gli attacchi coinvolgevano gli stessi campioni di EDRKillShifter e gli stessi server C2.

Il fatto che Play e BianLian – gang che operano tradizionalmente sotto modelli RaaS chiusi, basati sulla fiducia a lungo termine – utilizzino strumenti di un rivale come RansomHub suggerisce un livello di collaborazione senza precedenti nell’ecosistema ransomware. Come hanno teorizzato i ricercatori ESET, membri fidati di Play e BianLian stanno collaborando con rivali e riutilizzando gli strumenti ricevuti nelle proprie operazioni.

Questa dinamica trasforma l’EDR killer BYOVD da strumento tattico a infrastruttura condivisa dell’ecosistema ransomware. Non è più una capacità proprietaria di un singolo gruppo: è una commodity, un servizio, una lingua franca del cybercrime organizzato.

Perché Windows non può semplicemente “risolvere” il problema

Qualsiasi professionista della sicurezza, a questo punto, si pone la domanda ovvia: perché Microsoft non blocca semplicemente i driver con certificati scaduti o revocati?

La risposta è più complessa di quanto sembri e tocca uno dei trade-off più delicati dell’architettura Windows: la retrocompatibilità.

L’eccezione per i driver firmati prima del 29 luglio 2015 non è un bug – è una policy deliberata. Milioni di dispositivi hardware in produzione dipendono da driver legacy firmati con certificati di quel periodo. Revocare unilateralmente l’eccezione significherebbe potenzialmente causare crash di sistema, schermate blu e malfunzionamenti hardware su una scala difficile da quantificare.

Microsoft ha scelto un approccio alternativo: la Vulnerable Driver Blocklist, una lista di driver noti come vulnerabili o malevoli, implementata come policy Windows Defender Application Control (WDAC). A partire da Windows 11 versione 22H2, questa blocklist è abilitata di default su tutti i dispositivi. Viene aggiornata con ogni release principale di Windows, tipicamente una o due volte l’anno.

Il problema evidente di questo approccio è che è intrinsecamente reattivo: solo i driver già noti come weaponizzati finiscono nella lista. Ogni nuovo driver vulnerabile scoperto dagli attaccanti ha una finestra di esposizione fino al prossimo aggiornamento. In un ecosistema dove esistono centinaia di migliaia di driver firmati accumulati in decenni di sviluppo hardware, la superficie di attacco potenziale è virtualmente illimitata.

C’è poi un secondo problema, documentato nel CVE-2025-59033: la blocklist, implementata come policy WDAC, presenta un comportamento diverso a seconda che HVCI sia attivo o meno. Sui sistemi senza HVCI, alcune voci della blocklist che specificano il TBS hash del certificato insieme a qualificatori FileAttribRef (come nome del file o versione) possono non essere bloccate correttamente. Microsoft ha contestato l’assegnazione del CVE, affermando che la blocklist è progettata per funzionare con HVCI attivo e che i sistemi senza HVCI dovrebbero utilizzare App Control con policy personalizzate.

Ma questo sposta il problema anziché risolverlo: nella realtà operativa, HVCI non è attivo sulla maggioranza degli endpoint enterprise. Molte organizzazioni lo disabilitano per ragioni di compatibilità con driver legacy, impatto sulle performance o, più semplicemente, perché non ne conoscono l’esistenza o la funzione. Il risultato è una protezione che esiste sulla carta ma non nel data center.

L’inventario degli strumenti: gli EDR killer che stanno ridefinendo il playbook ransomware

Il panorama degli EDR killer BYOVD nel 2026 è variegato e in rapida espansione. Comprenderne la tassonomia è essenziale per chi deve costruire strategie difensive.

TrueSightKiller sfrutta il driver truesight.sys ed è uno degli strumenti pubblicamente disponibili più utilizzati nelle intrusioni ransomware recenti.

AuKill, documentato da Sophos, utilizza una versione obsoleta del driver impiegato dall’utility Microsoft Process Explorer per disabilitare i processi EDR prima del deployment del ransomware.

Poortry (noto anche come BurntCigar) è un driver malevolo frequentemente impiegato insieme al loader Stonestop. A differenza dei tool precedenti, Poortry è stato firmato con certificati rubati o ottenuti fraudolentemente, aggiungendo un ulteriore livello di sofisticazione.

GhostDriver e Warp AVKiller completano l’arsenale più frequentemente osservato, con quest’ultimo che sfrutta un driver anti-rootkit di Avira per disabilitare i prodotti di sicurezza.

Un caso particolarmente emblematico della diversificazione in atto riguarda il gruppo Interlock, che ha sviluppato un tool denominato “Hotta Killer” per sfruttare un zero-day in un driver anti-cheat gaming – GameDriverx64.sys, tracciato come CVE-2025-61155 – in attacchi BYOVD contro organizzazioni del settore educativo in UK e USA. L’intrusione, analizzata da FortiGuard, è particolarmente istruttiva perché illustra la convergenza di più tecniche offensive in un’unica campagna: l’accesso iniziale è avvenuto tramite tattiche di social engineering ClickFix per distribuire il payload MintLoader, seguito dal deployment del RAT NodeSnake per il movimento laterale, e infine dall’uso di Hotta Killer per disabilitare le difese prima della cifratura.

Il driver, rinominato UpdateCheckerX64.sys, veniva caricato come servizio kernel e comunicava tramite un link simbolico, esponendo un IOCTL (0x222040) con un magic flag (0xFA123456) per terminare i processi di sicurezza. Il caso Interlock è significativo perché dimostra che gli attaccanti non si limitano più ai driver di sicurezza o forensics: qualsiasi driver firmato con accesso kernel – inclusi quelli dei videogiochi – è un potenziale vettore BYOVD.

La portata del fenomeno ha spinto la Cyber Security Agency di Singapore (CSA) a pubblicare un advisory dedicato agli EDR killer, segnalando che almeno otto gruppi ransomware utilizzano attivamente strumenti di questo tipo. L’advisory ha evidenziato caratteristiche chiave condivise tra i tool: framework collaborativo tra gang, randomizzazione dei nomi dei driver, capacità di auto-scompattamento in memoria e uso di certificati rubati o scaduti.

La lista non è statica. Come ha evidenziato la ricerca di ESET su RansomHub, i ricercatori hanno osservato un aumento marcato nell’uso di EDR killer derivati da proof-of-concept pubblici, mentre il set di driver abusati rimane relativamente fisso. Cisco Talos ha analizzato sistematicamente le classi di vulnerabilità tipicamente sfruttate nei driver Windows, confermando che lo sfruttamento è migrato dal dominio degli attori avanzati a quello delle minacce commodity, in primis il ransomware. Questo significa che la barriera d’ingresso per sviluppare un EDR killer personalizzato è in caduta libera: chiunque abbia competenze di sviluppo Windows di livello intermedio può assemblarne uno partendo da codice disponibile su repository pubblici e proof-of-concept documentati.

Il paradosso dell’EDR e il debito del driver legacy

C’è un’ironia crudele nella situazione attuale. L’Endpoint Detection and Response è il prodotto di sicurezza su cui le organizzazioni investono di più, il pilastro su cui costruiscono la propria postura difensiva. I vendor EDR hanno sviluppato capacità sempre più sofisticate: rilevamento comportamentale, machine learning, analisi della memoria, threat hunting automatizzato.

Ma tutto questo sofisticato apparato tecnologico opera in user-mode. E un singolo driver vulnerabile caricato in kernel-mode ha il potere di spegnerlo completamente, bypassando ogni protezione, incluso Protected Process Light (PPL), il meccanismo che dovrebbe impedire la terminazione dei processi di sicurezza critici.

Il BYOVD come tecnica EDR killer sfrutta un debito architetturale che si è accumulato in decenni di sviluppo dell’ecosistema Windows. Ogni driver firmato legittimamente in vent’anni di storia informatica è un potenziale strumento nelle mani di un attaccante. E poiché questi driver erano progettati per scopi legittimi – forensics, gestione hardware, anti-rootkit, anti-cheat gaming – nessuno ha mai pensato di limitare le loro capacità kernel-mode in modo granulare.

Questo debito del driver legacy è strutturalmente analogo al debito tecnico nel software: una scelta ragionevole al momento della progettazione che diventa un rischio crescente con il passare del tempo. La differenza è che il debito tecnico nel software si paga con costi di manutenzione; il debito del driver legacy si paga con intrusioni ransomware riuscite.

Contromisure operative: cosa funziona davvero e cosa è un’illusione

Definito il problema nella sua dimensione reale, è necessario analizzare le contromisure con lo stesso rigore critico. Non tutte le difese proposte sono ugualmente efficaci, e alcune creano un falso senso di sicurezza.

HVCI (Hypervisor-Protected Code Integrity)

È la difesa più robusta attualmente disponibile. HVCI utilizza la virtualizzazione hardware per proteggere la memoria kernel, impedendo l’esecuzione di codice non firmato o non conforme alle policy. Quando HVCI è attivo, la Vulnerable Driver Blocklist di Microsoft viene effettivamente applicata. Huntress lo raccomanda esplicitamente come prima contromisura: abilitare HVCI / Memory Integrity garantisce che la blocklist dei driver vulnerabili sia effettivamente enforced.

Il problema: HVCI può causare incompatibilità con driver legacy e applicazioni che richiedono accesso diretto al kernel. Alcune organizzazioni lo disabilitano per ragioni operative, esponendosi esattamente all’attacco che dovrebbe prevenire.

WDAC (Windows Defender Application Control)

WDAC consente di definire policy granulari su quali driver e applicazioni possono essere eseguiti. Configurato correttamente in modalità allowlist, WDAC può bloccare proattivamente il caricamento di qualsiasi driver non esplicitamente autorizzato, inclusi quelli non ancora presenti nella blocklist di Microsoft.

È la contromisura più efficace in termini di copertura, ma anche la più complessa da implementare. Richiede un inventario accurato di tutti i driver legittimi necessari nell’ambiente, un processo di test rigoroso e una gestione continua delle eccezioni. In ambienti enterprise complessi, il deployment di WDAC in modalità enforced può richiedere mesi.

ASR Rules (Attack Surface Reduction)

La regola ASR “Block abuse of exploited vulnerable signed drivers” impedisce a un’applicazione di scrivere su disco un driver vulnerabile firmato. Tuttavia, come documentato da Microsoft, questa regola non blocca un driver già presente nel sistema – agisce solo sulla fase di installazione. Inoltre, le ASR rules dipendono da Microsoft Defender e possono essere disattivate da processi in user-mode, il che ne limita l’efficacia contro attaccanti che hanno già ottenuto privilegi elevati.

Monitoraggio comportamentale e telemetria

Se le difese preventive falliscono – e come abbiamo visto, in molti ambienti mancano i prerequisiti per attivarle – il rilevamento diventa l’ultima linea di difesa. I SOC dovrebbero monitorare attivamente: la creazione di servizi kernel con nomi che mimano componenti OEM o hardware; il caricamento di driver non standard, specialmente se firmati con certificati obsoleti; la terminazione anomala dei processi EDR; l’uso di sc.exe per la creazione di nuovi servizi kernel; l’attività IOCTL sospetta verso driver appena caricati.

Huntress ha evidenziato come la telemetria SIEM proveniente dal SonicWall sia stata determinante per ricostruire la timeline dell’intrusione. La lezione operativa è chiara: la visibilità a livello di rete e di autenticazione deve complementare, non sostituire, la protezione endpoint.

Il quadro strategico: dalla rincorsa delle blocklist alla riduzione strutturale del rischio

Il BYOVD come vettore EDR killer mette in discussione un assunto implicito della sicurezza endpoint degli ultimi dieci anni: che l’EDR sia sufficiente come difesa primaria.

Non lo è. Non perché l’EDR non funzioni – funziona eccellentemente nel proprio dominio. Ma perché opera a un livello di privilegio inferiore rispetto allo spazio in cui gli attaccanti possono agire quando sfruttano un driver kernel vulnerabile. È come avere una guardia armata all’ingresso che un intruso può addormentare prima di entrare.

La risposta strategica non è abbandonare l’EDR, ma costruire architetture dove la compromissione dell’EDR non equivalga alla compromissione dell’intero ambiente. Questo significa defense in depth reale, non come slogan ma come architettura: segmentazione di rete che limita il lateral movement indipendentemente dallo stato dell’endpoint; monitoraggio a livello di rete e di identità che non dipende dall’agente endpoint; policy di allowlisting dei driver che prevengono il caricamento di codice non autorizzato a livello kernel; autenticazione multifattore robusta su ogni punto di accesso remoto (l’incidente Huntress è iniziato con credenziali VPN senza MFA).

Il modello mentale deve evolvere dalla domanda “il nostro EDR rileverà l’attacco?” alla domanda “cosa succede se l’attaccante spegne il nostro EDR?”. Se la risposta alla seconda domanda è “non abbiamo visibilità e non possiamo contenere l’intrusione”, l’architettura difensiva ha un problema strutturale che nessun upgrade dell’EDR potrà risolvere.

Implicazioni per NIS2, DORA e la compliance

Il fenomeno EDR killer BYOVD ha implicazioni dirette per i framework normativi europei in fase di implementazione. NIS2 richiede alle organizzazioni essenziali e importanti di adottare misure di gestione del rischio proporzionate, inclusa la sicurezza della supply chain e la gestione delle vulnerabilità. Un ambiente in cui driver legacy vulnerabili possono essere sfruttati per disabilitare le difese endpoint rappresenta un rischio di supply chain tecnologica che deve essere esplicitamente indirizzato nel risk assessment.

Non si tratta di un rischio teorico: CISA ha aggiornato l’advisory congiunto su Akira nel novembre 2025 documentando specificamente l’uso di malware POORTRY per modificare configurazioni BYOVD su driver vulnerabili e disabilitare le protezioni endpoint, confermando che il fenomeno è monitorato dalle autorità di sicurezza a livello internazionale.

DORA, per le entità finanziarie, richiede test di resilienza operativa digitale che includano scenari di threat-led penetration testing. I TLPT dovrebbero necessariamente includere scenari BYOVD per validare la capacità dell’organizzazione di rilevare e contenere un’intrusione in cui l’EDR è stato neutralizzato.

La responsabilità ricade sull’organizzazione, non sul vendor EDR. Se un ransomware riesce a cifrare l’ambiente perché l’EDR è stato spento con un driver vulnerabile che avrebbe potuto essere bloccato da HVCI o WDAC, la domanda delle autorità di supervisione sarà: perché queste contromisure non erano abilitate?

Cosa aspettarsi: il BYOVD embedded come nuovo standard

Il caso Reynolds non è un’anomalia. È un segnale direzionale.

Come ha osservato il Symantec and Carbon Black Threat Hunter Team, l’integrazione di capacità aggiuntive direttamente nel payload ransomware potrebbe funzionare come unique selling point per gli sviluppatori che cercano di attrarre affiliati. In un mercato RaaS competitivo, offrire un payload che gestisce autonomamente l’evasione difensiva riduce la complessità per l’affiliato e rende gli attacchi più facili da eseguire.

È ragionevole prevedere che nel corso del 2026 vedremo altri gruppi ransomware adottare il modello del BYOVD embedded, e che la ricerca di driver vulnerabili ancora non presenti nella blocklist di Microsoft diventerà un’attività sistematica da parte dei threat actor. I numeri supportano questa proiezione: secondo i dati aggregati da Cyble e ReliaQuest, gli attacchi ransomware nel 2025 hanno raggiunto quota 4.737, in aumento rispetto ai 4.701 del 2024, con il riscatto medio balzato a 591.988 dollari nel Q4 2025 (+57% sul trimestre precedente, secondo Coveware).

In un ecosistema dove la competizione tra gang è feroce e le barriere d’ingresso continuano a scendere, offrire un payload con EDR killer BYOVD integrato diventa un vantaggio competitivo concreto nel reclutamento di affiliati. La corsa è già in atto: ogni driver firmato legittimamente in due decenni di storia Windows è un potenziale candidato.

Per i difensori, questo significa che la finestra per implementare contromisure strutturali – HVCI, WDAC, segmentazione, monitoraggio indipendente dall’endpoint – si sta chiudendo. Il BYOVD non è una minaccia futura: è il presente del ransomware. E il costo dell’inazione non è più un rischio teorico da inserire nel risk register. È un incidente in attesa di accadere.

Checklist operativa per SOC analyst e security architect

Per chi deve tradurre questa analisi in azioni concrete, ecco le priorità operative immediate:

  • Verificare lo stato di HVCI/Memory Integrity su tutti gli endpoint Windows. Se disabilitato, pianificare l’attivazione con test di compatibilità. Senza HVCI, la Vulnerable Driver Blocklist di Microsoft potrebbe non essere enforced correttamente.
  • Valutare il deployment di WDAC in modalità audit come primo passo, per identificare i driver caricati nell’ambiente e costruire una policy di allowlisting progressiva.
  • Abilitare la regola ASR “Block abuse of exploited vulnerable signed drivers” su tutti gli endpoint con Microsoft Defender attivo.
  • Implementare il monitoraggio SIEM per la creazione di servizi kernel anomali, il caricamento di driver non standard e la terminazione dei processi EDR. In particolare, monitorare chiamate DeviceIoControl verso device handle sconosciuti e la creazione di link simbolici (\??) verso driver appena installati.
  • Condurre un inventario dei driver kernel attualmente caricati nell’ambiente tramite PowerShell (Get-WindowsDriver o driverquery /si) e confrontarlo con la Vulnerable Driver Blocklist di Microsoft per identificare driver a rischio già presenti.
  • Verificare che l’MFA sia attiva su tutti i servizi di accesso remoto (VPN, RDP, SSH). L’incidente Huntress è iniziato con credenziali VPN senza MFA.
  • Testare lo scenario “EDR down” negli esercizi di incident response e nei TLPT previsti da DORA: cosa succede se l’attaccante spegne l’EDR? Quali controlli compensativi entrano in funzione? Se la risposta è “nessuno”, l’architettura ha un problema strutturale.
  • Aggiornare la Vulnerable Driver Blocklist manualmente se non si è su Windows 11 22H2 o successivo. Le versioni precedenti di Windows potrebbero avere una blocklist obsoleta.
  • Implementare il monitoraggio dei driver con certificati obsoleti. Configurare regole di alerting per il caricamento di driver kernel firmati con certificati emessi prima del 2015, con particolare attenzione a quelli con timestamp di firma antecedenti al 2010.
Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-crime/edr-killer-byovd-endpoint/




ZeroDayRAT: La Nuova Minaccia per Android e iOS


I ricercatori di iVerify, un’azienda specializzata in sicurezza informatica per dispositivi mobili, ha rivelato l’arrivo nel panorama delle minacce di un nuovo, preoccupante strumento: ZeroDayRAT. Questa piattaforma spyware è emersa nel sottobosco del cybercrime su Telegram, presentandosi come una soluzione completa per il controllo remoto di dispositivi Android e iOS. Lungi dall’essere un semplice estrattore di dati, ZeroDayRAT si posiziona come un toolkit di compromissione mobile a tutto tondo in grado di offrire agli aggressori un controllo profondo e persistente sui dispositivi infetti.

Architettura e Compatibilità del Malware

ZeroDayRAT si distingue per la sua ampia compatibilità, estendendosi su un vasto spettro di versioni di sistemi operativi mobili. Gli sviluppatori pubblicizzano il supporto per le versioni Android dalla 5 alla 16, coprendo quindi sia dispositivi legacy che i più recenti aggiornamenti del sistema operativo Google. Sul fronte Apple, la compatibilità arriva fino a iOS 26, includendo le ultime versioni del sistema operativo mobile. Questa trasversalità rende ZeroDayRAT una minaccia preoccupante poiché la sua potenziale superficie di attacco è estremamente ampia. La piattaforma offre agli acquirenti un pannello di controllo completo, con una interfaccia di gestione intuitiva e centralizzata dei dispositivi compromessi, evidenziando una grande maturità nella sua concezione e implementazione.

Capacità di Monitoraggio e Raccolta Dati

Il cuore operativo di ZeroDayRAT risiede nelle sue estese capacità di sorveglianza passiva. La dashboard di gestione del malware fornisce all’operatore una panoramica dettagliata di ogni dispositivo compromesso, visualizzando informazioni cruciali come il modello del terminale, la versione del sistema operativo, lo stato della batteria, i dettagli della SIM (inclusi IMSI e IMEI), la posizione geografica del dispositivo e lo stato del blocco schermo. A un livello più granulare, il malware è in grado di registrare l’utilizzo delle applicazioni, tracciare le cronologie delle attività dell’utente e intercettare tutti gli scambi di messaggi SMS. Ulteriori sezioni del pannello permettono di visualizzare le notifiche ricevute e un elenco degli account registrati sul dispositivo, fornendo identificativi utente ed e-mail che potrebbero essere successivamente sfruttati per attacchi di brute-forcing o credential stuffing su altri servizi. Se sono stati ottenuti i permessi di accesso al GPS, ZeroDayRAT è in grado di tracciare la vittima in tempo reale, visualizzando la posizione attuale su una mappa interattiva, completa di cronologia degli spostamenti.

Dal sito di iVerify

Operazioni Attive e Controllo Remoto

Oltre alla sorveglianza passiva, ZeroDayRAT abilita una serie di operazioni attive che consentono agli aggressori un controllo diretto sul dispositivo. Questo include la possibilità di attivare da remoto le fotocamere (sia quella anteriore che posteriore) e il microfono, fornendo flussi multimediali in tempo reale per la sorveglianza ambientale. Un modulo di registrazione dello schermo permette di catturare l’interazione dell’utente con il dispositivo, rivelando password, PIN, gesti di sblocco e altre informazioni sensibili. L’accesso ai permessi SMS è particolarmente critico: non solo consente l’intercettazione delle password monouso (OTP), facilitando il bypass dell’autenticazione a due fattori (2FA), ma permette anche l’invio di SMS dal dispositivo della vittima, potenzialmente per attività di spam, frode o diffusione del malware stesso. Ulteriormente, un modulo keylogging registra ogni input dell’utente, comprese password, pattern di sblocco e qualsiasi testo digitato, offrendo una miniera d’oro di credenziali.

Furto Finanziario Avanzato

ZeroDayRAT implementa moduli specifici per il furto finanziario, dimostrando una focalizzazione diretta sull’esfiltrazione di asset economici. Un componente dedicato al furto di criptovalute scannerizza le app wallet più comuni come MetaMask, Trust Wallet, Binance e Coinbase. Questo modulo non solo registra gli ID dei wallet e i saldi, ma tenta anche l’iniezione di indirizzi negli appunti, sostituendo gli indirizzi wallet copiati dalla vittima con indirizzi controllati dall’aggressore per deviare le transazioni. Parallelamente, un “bank stealer” prende di mira le app di online banking, le piattaforme UPI (come Google Pay e PhonePe) e servizi di pagamento come Apple Pay e PayPal. La tattica principale qui è l’utilizzo di overlay screen, ovvero schermate false che si sovrappongono all’interfaccia legittima dell’app per ingannare la vittima e indurla a inserire le proprie credenziali direttamente nelle mani dell’aggressore.

Implicazioni per la Sicurezza Aziendale e Individuale

Il toolkit ZeroDayRAT, sebbene non sia stato dettagliato il suo meccanismo di distribuzione iniziale da iVerify, rappresenta una minaccia significativa a più livelli. Per le organizzazioni, la compromissione di un dispositivo di un dipendente tramite ZeroDayRAT potrebbe fungere da punto d’ingresso per violazioni aziendali più ampie, esponendo dati sensibili e infrastrutture critiche. La capacità di intercettare OTP e credenziali, unita al keylogging e al controllo remoto, può bypassare molte delle difese perimetrali tradizionali. A livello individuale, una compromissione ZeroDayRAT porta a una totale perdita di privacy e a potenziali perdite finanziarie devastanti. La raccomandazione primaria per mitigare tali rischi rimane l’adesione rigorosa all’installazione di applicazioni esclusivamente dagli store ufficiali (Google Play e Apple App Store) e da sviluppatori con comprovata reputazione. Per gli utenti ad alto rischio, l’attivazione di funzionalità di sicurezza avanzate come la “Modalità Lockdown” su iOS e la “Protezione Avanzata” su Android è fortemente consigliata, poiché queste opzioni sono progettate per limitare l’esposizione a exploit e malware sofisticati.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/02/10/zerodayrat-la-nuova-minaccia-per-android-e-ios/?utm_source=rss&utm_medium=rss&utm_campaign=zerodayrat-la-nuova-minaccia-per-android-e-ios