Due vulnerabilità del 2021, un attacco a dizionario e una funzione di comodità pensata per l'installatore: sono bastate queste tre cose per prendere il controllo di oltre 14.530 dispositivi Dahua in 35 giorni. La campagna, battezzata Operation CameraSwarm dai ricercatori di Hunt.io, è stata ricostruita non grazie a un'intrusione difensiva ma per un errore dell'attaccante: una directory di lavoro da 407 MB lasciata esposta su un server HTTP, con 2.616 file distribuiti in 234 sottocartelle tra strumenti, log, cronologia di shell e registri della campagna.

Cosa è successo

L'attività si colloca tra il 17 giugno e il 22 luglio 2026 e ha usato tre percorsi paralleli:

  • Attacchi alle credenziali — la via più battuta: 12.324 indirizzi IP unici su 13.229 record di campagna. Password deboli, di default o riutilizzate.
  • Bypass dell'autenticazione — 1.923 telecamere raggiunte sfruttando CVE-2021-33044 e CVE-2021-33045, due falle di aggiramento dell'autenticazione note da cinque anni. Dahua le valuta CVSS 8.1 nel proprio advisory, mentre l'NVD statunitense assegna a entrambe 9.8. La prima si attiva presentandosi come client di tipo NetKeyboard durante l'autenticazione, la seconda usa una richiesta di login in loopback verso 127.0.0.1. Su queste telecamere è stato configurato anche un account persistente.
  • Relay P2P — 283 dispositivi individuati per numero di serie, inclusi apparati dietro NAT. È il punto più interessante e il meno compreso.

Il totale complessivo, i 1.923 account persistenti, i 283 dispositivi via P2P e la percentuale dell'89,4% di numeri di serie "vivi" che restituirebbero un canale aperto restano dati attribuiti a Hunt.io e non riprodotti in modo indipendente. Le fonti primarie pubbliche confermano invece i due bypass, la configurazione del tool p2pwn (repository ancora accessibile su GitHub, che accetta numeri di serie Dahua in input) e il meccanismo P2P di fondo. Le compromissioni confermate risultano concentrate in Ucraina e Russia; l'operatore è descritto come russofono sulla base di artefatti linguistici, ma non è attribuito ad alcun gruppo noto né a un'entità statale.

Il problema del numero di serie

Il percorso P2P merita una spiegazione, perché è concettualmente diverso da una vulnerabilità software. ITRES Labs aveva già documentato nell'ottobre 2025, durante un incident response, che sui firmware precedenti alla metà del 2024 un numero di serie Dahua valido era sufficiente a stabilire un percorso di relay attraverso l'infrastruttura cloud Easy4IP del produttore, prima che il dispositivo eseguisse il proprio controllo delle credenziali. In pratica: la rete del produttore costruiva il tunnel e lasciava al web server della telecamera il compito di verificare chi stesse bussando.

Il risultato è che un dispositivo dietro NAT, che l'amministratore considerava irraggiungibile da Internet perché "non ha porte aperte", diventava raggiungibile conoscendo un dato che non è un segreto: il numero di serie, spesso stampato sull'etichetta dell'apparato e presente in fatture, DDT e documentazione d'impianto. ITRES Labs classifica la questione come problema non associato a un CVE e riferisce che il percorso P2P è stato irrobustito nei firmware successivi alla metà del 2024.

Vale la pena chiarire due sigle che circolano associate a questa campagna ma che descrivono altro: CVE-2024-39943 è una command injection in Rejetto HFS, CVE-2025-31702 è una escalation di privilegi Dahua che richiede credenziali di utente normale già ottenute. Nessuna delle due descrive il comportamento del relay.

Cosa significa per le aziende italiane

La reazione istintiva — "riguarda Ucraina e Russia, e comunque noi non abbiamo telecamere Dahua" — è sbagliata su entrambi i fronti.

Primo: molto probabilmente avete apparati Dahua senza saperlo. Dahua è uno dei maggiori produttori OEM al mondo di telecamere IP e NVR: gli stessi apparati vengono rivenduti sotto decine di marchi diversi, alcuni molto comuni negli impianti italiani. Cercare la stringa "Dahua" nell'inventario non basta: serve verificare firmware, interfaccia web e presenza del servizio P2P/Easy4IP sugli apparati installati, qualunque logo abbiano sul frontalino.

Secondo: le due CVE del 2021 sono ancora nel catalogo KEV della CISA. Al 19 agosto 2026 risultano tuttora elencate tra le vulnerabilità note come sfruttate. Una falla di cinque anni fa che continua a produrre vittime non è un problema di ricerca: è un problema di manutenzione. La videosorveglianza è tipicamente installata da un fornitore esterno, collaudata una volta e poi dimenticata, senza che nessuno in azienda ne assuma la titolarità operativa. Il contratto di manutenzione, quando esiste, copre la sostituzione dell'hardware, non l'aggiornamento del firmware.

Terzo, ed è il punto che pesa di più in Italia: un DVR compromesso è un data breach. Le immagini di persone identificabili sono dati personali. Un accesso non autorizzato al sistema di videosorveglianza costituisce una violazione ai sensi dell'art. 33 GDPR, con l'obbligo di documentarla nel registro delle violazioni e, se ricorre un rischio per i diritti e le libertà degli interessati, di notificarla al Garante entro 72 ore; se il rischio è elevato — e riprese di lavoratori, clienti o pazienti diffuse a terzi lo sono — scatta anche la comunicazione agli interessati ex art. 34. A questo si somma il quadro giuslavoristico: l'impianto di videosorveglianza sul luogo di lavoro richiede accordo sindacale o autorizzazione dell'Ispettorato ai sensi dell'art. 4 dello Statuto dei lavoratori, informativa adeguata e tempi di conservazione contenuti. Un impianto già irregolare sul piano formale che viene anche compromesso espone a un doppio profilo di responsabilità.

Quarto: la telecamera è un punto d'appoggio, non solo un obiettivo. Un apparato IoT compromesso in una rete piatta è una testa di ponte verso i sistemi gestionali. Per i soggetti che rientrano nel d.lgs. 138/2024 (NIS2), il perimetro delle misure di gestione del rischio comprende gli apparati connessi alla rete aziendale, indipendentemente dalla loro funzione, e include esplicitamente la sicurezza della catena di approvvigionamento: il fornitore che ha installato l'impianto rientra in quella catena.

Cosa fare subito

  • Fate l'inventario reale degli apparati di videosorveglianza: marca, modello, produttore OEM effettivo, versione firmware, data dell'ultimo aggiornamento. Se non sapete rispondere, questo è già il risultato dell'analisi.
  • Aggiornate il firmware scaricandolo esclusivamente dal sito del produttore e verificando la corrispondenza con l'advisory ufficiale. I firmware precedenti alla metà del 2024 sono i più esposti sul percorso P2P.
  • Disattivate P2P/Easy4IP se non è indispensabile. Nella grande maggioranza degli impianti aziendali serve solo alla app mobile dell'installatore: sostituitela con un accesso VPN.
  • Eliminate ogni port forwarding verso le porte tipiche degli apparati (37777, 80, 443, 554) e verificate su motori di ricerca per dispositivi esposti se i vostri IP pubblici rispondono su quelle porte.
  • Segmentate la VLAN della videosorveglianza dalla rete produttiva, con regole in uscita che consentano solo il traffico strettamente necessario. Un DVR non ha alcuna ragione di parlare con il file server.
  • Sostituite le credenziali con password uniche e robuste su ogni apparato, e verificate l'elenco degli account locali: la campagna ha creato account persistenti. Dopo un eventuale ripristino di fabbrica, ricontrollate l'elenco anziché darlo per pulito.
  • Attivate e centralizzate i log degli apparati e degli NVR: senza log non potrete stabilire, in caso di verifica del Garante, se le immagini siano state effettivamente esfiltrate.
  • Mettete per iscritto chi aggiorna cosa nel contratto con l'installatore, con una cadenza definita e un obbligo di segnalazione degli advisory del produttore.

In sintesi

CameraSwarm non introduce tecniche nuove: mette in fila password deboli, due bypass vecchi di cinque anni e una funzione cloud del produttore progettata per la comodità dell'installazione. È esattamente il profilo di rischio della maggior parte degli impianti di videosorveglianza italiani, dove il dispositivo è trattato come un elettrodomestico e non come un sistema informatico connesso che tratta dati personali. La differenza tra le due letture, in caso di incidente, la fa il Garante.