Sicurezza IoT: 15 tipi di attacchi (2026)

La proliferazione dei dispositivi IoT — che oggi superano i 18,8 miliardi di endpoint connessi a livello globale (IoT Analytics, 2026) — ha trasformato la superficie di attacco da una stretta apertura in una vasta frontiera distribuita. Dalle fabbriche intelligenti che operano su reti IEC 62443 alle griglie di sensori municipali che monitorano le infrastrutture cittadine, ogni dispositivo connesso rappresenta al tempo stesso un asset operativo e un potenziale punto di ingresso.

Questa guida cataloga i 15 tipi di attacco alla sicurezza IoT più critici, ciascuno illustrato con incidenti reali verificati del periodo 2024–2026. Che siate un ingegnere hardware impegnato a progettare la prossima generazione di prodotti connessi, un CISO che valuta i rischi della catena di approvvigionamento o un product owner che si prepara alla conformità al Cyber Resilience Act (CRA) dell’UE, comprendere queste minacce è il primo passo verso una progettazione di sistema resiliente.

Perché Inovasense? Progettiamo dispositivi IoT con la sicurezza integrata nell’hardware — dal silicio al cloud. Ogni tipo di attacco descritto di seguito corrisponde a un livello di difesa che implementiamo nei nostri prodotti. Scoprite il nostro approccio →

---

1. Accesso non autorizzato ai dispositivi

Il vettore di attacco IoT più diffuso. Gli aggressori sfruttano credenziali predefinite di fabbrica, password cablate nel firmware o vulnerabilità di bypass dell’autenticazione per assumere il controllo di telecamere, PLC industriali, router e dispositivi smart home.

Perché è rilevante nel 2026: il Cyber Resilience Act dell’UE (in vigore da agosto 2025) ora vieta legalmente la commercializzazione di dispositivi con password predefinite o universali. I produttori rischiano sanzioni fino a 15 mln € o al 2,5% del fatturato globale in caso di non conformità.

Come funziona:

• Scansione alla ricerca di dispositivi con Telnet/SSH aperti tramite strumenti come Shodan o Censys
• Sfruttamento di credenziali cablate nei binari del firmware
• Sfruttamento di CVE nel middleware di autenticazione (ad es. buffer overflow nei gestori di login)

Difesa hardware: credenziali univoche per ogni dispositivo, fornite durante la produzione e archiviate in un Secure Element hardware (ad es. ATECC608B o Infineon OPTIGA). Nessuna credenziale nei binari del firmware — mai.

---

2. Intercettazione dei dati

Gli aggressori catturano i dati in transito tra i dispositivi IoT e le piattaforme cloud intercettando comunicazioni wireless non cifrate — Wi-Fi, Bluetooth, Zigbee, LoRaWAN o cellulari (NB-IoT/LTE-M).

Perché è rilevante: molti protocolli LPWAN (Sigfox legacy, LoRaWAN con attivazione ABP) trasmettono con una cifratura minima. I sensori industriali inviano spesso telemetria tramite MQTT non cifrato senza TLS, esponendo i dati operativi all’intercettazione passiva.

Come funziona:

• Sniffing RF passivo con hardware SDR (HackRF, RTL-SDR) sulle bande ISM (868/915 MHz)
• Cattura del traffico MQTT, CoAP o HTTP su canali non cifrati
• Decodifica di protocolli proprietari tramite reverse engineering

Difesa hardware: cifratura end-to-end con chiavi archiviate in Secure Element resistenti alla manomissione. Autenticazione reciproca TLS 1.3 per tutte le comunicazioni cloud. Cifratura a livello applicativo per i payload LPWAN, indipendente dalla sicurezza a livello di rete.

---

3. Attacchi Man-in-the-Middle (MitM)

L’aggressore si posiziona tra due parti in comunicazione — tipicamente tra un dispositivo IoT e il suo backend cloud, oppure tra un dispositivo e il suo server di aggiornamento OTA — intercettando ed eventualmente alterando i dati in transito.

Perché è rilevante: gli attacchi MitM sui canali di aggiornamento del firmware sono particolarmente devastanti. Un aggressore in grado di intercettare e sostituire un binario del firmware ottiene il controllo persistente del dispositivo a livello root.

Come funziona:

• ARP spoofing sulle reti locali per reindirizzare il traffico del dispositivo
• DNS spoofing per reindirizzare le richieste di aggiornamento OTA verso server malevoli
• Stazioni base fraudolente che intercettano il traffico IoT cellulare (IMSI catcher per NB-IoT)
• Certificate stripping quando i dispositivi non convalidano le catene di certificati TLS

Difesa hardware: firmware firmato con catena di avvio verificata via hardware. Il bootloader convalida le firme del firmware rispetto a chiavi pubbliche fuse nella memoria OTP — nessun software può sovrascrivere questa verifica. Il tutto combinato con il certificate pinning per tutte le connessioni TLS.

---

4. Attacchi DDoS (Distributed Denial of Service)

Gli aggressori compromettono migliaia di dispositivi IoT per costruire botnet che sommergono i bersagli di traffico, saturando server, reti o servizi. I dispositivi IoT sono reclute ideali per le botnet: sempre online, raramente monitorati e spesso in esecuzione con firmware obsoleto.

Perché è rilevante nel 2026: la botnet Mirai (2016) è stata solo l’inizio. I successori moderni come RapperBot, HinataBot e Pandora sono potenziati dall’IA, polimorfici e mirano specificamente ai dispositivi IoT con architetture ARM/MIPS.

Come funziona:

• Scansione automatizzata alla ricerca di dispositivi vulnerabili tramite elenchi di credenziali e catene di exploit
• Infezione dei dispositivi con malware di botnet tramite exploit Telnet, SSH o HTTP
• Coordinamento command-and-control (C2) per attacchi flood sincronizzati (TCP SYN, UDP, HTTP/2)
• Sempre più spesso: ransom DDoS — minaccia di attacchi a meno che non venga pagata una somma in criptovaluta

Difesa hardware: il Secure Boot impedisce l’esecuzione di codice non autorizzato. L’isolamento di rete garantisce che i dispositivi consumer compromessi non possano spostarsi lateralmente verso le reti OT. Il monitoraggio delle risorse rileva schemi di traffico in uscita anomali.

---

5. Manomissione fisica

Gli aggressori con accesso fisico a un dispositivo estraggono dati sensibili sondando le interfacce di debug (JTAG, SWD, UART), leggendo direttamente la memoria flash o modificando componenti hardware per aggirare i controlli di sicurezza.

Perché è rilevante: i dispositivi IoT installati in spazi pubblici — contatori intelligenti, sensori di traffico, cassette postali, monitor ambientali — sono intrinsecamente vulnerabili all’accesso fisico. A differenza dei data center, i dispositivi installati sul campo non dispongono di addetti alla sicurezza.

Come funziona:

• Connessione a porte di debug JTAG/SWD esposte per estrarre firmware e chiavi di cifratura
• Dissaldatura dei chip flash per l’analisi offline (chip-off forensics)
• Glitching dell’alimentazione o dei segnali di clock per aggirare la verifica del Secure Boot
• Bus probing con analizzatori logici per catturare le comunicazioni tra chip

Difesa hardware: interfacce di debug disabilitate/fuse in produzione. Memoria flash esterna cifrata con chiavi nei Secure Element. Circuiti di rilevamento della manomissione che azzerano il materiale crittografico in caso di intrusione fisica. Progettazione PCB con via interrate e incapsulamento in resina epossidica (potting) per le applicazioni ad alta sicurezza.

---

6. Attacchi side-channel

Invece di attaccare l’algoritmo crittografico in sé, gli attacchi side-channel estraggono i segreti osservando le caratteristiche fisiche del dispositivo durante il funzionamento — consumo di potenza, emissioni elettromagnetiche, variazioni di temporizzazione o persino firme acustiche.

Perché è rilevante: gli attacchi side-channel aggirano tutte le misure di sicurezza software. Per quanto robusto sia l’algoritmo di cifratura, se l’hardware lascia trapelare informazioni attraverso i rail di alimentazione o le emanazioni EM, le chiavi possono essere recuperate.

Come funziona:

• Simple Power Analysis (SPA): osservazione delle tracce di potenza durante le operazioni crittografiche per identificare schemi dipendenti dalla chiave
• Differential Power Analysis (DPA): analisi statistica di migliaia di tracce di potenza per estrarre i singoli bit della chiave
• Electromagnetic Analysis (EMA): sonde EM in campo vicino che catturano i segnali da specifiche regioni del chip
• Timing Attacks: misurazione delle differenze nei tempi di esecuzione che si correlano con i valori dei dati segreti

Difesa hardware: implementazioni crittografiche a tempo costante. Acceleratori crittografici hardware con contromisure DPA integrate (esecuzione randomizzata, iniezione di rumore nell’alimentazione). Secure Element dedicati (certificati CC EAL5+) progettati per resistere agli attacchi side-channel.

---

7. Spoofing dei dispositivi

Gli aggressori creano dispositivi fraudolenti che impersonano endpoint IoT legittimi sulla rete. Il dispositivo contraffatto può iniettare dati falsi, intercettare comandi o ottenere l’accesso non autorizzato ai sistemi di backend presentando identità di dispositivo clonate o falsificate.

Perché è rilevante: nell’IoT industriale e nelle infrastrutture critiche, i sensori contraffatti possono indurre decisioni catastrofiche — letture errate della temperatura in un impianto chimico, dati di occupazione fabbricati nella gestione degli edifici o misurazioni fraudolente nelle reti dei servizi pubblici.

Come funziona:

• Clonazione di certificati di dispositivo o indirizzi MAC dal traffico catturato
• Estrazione di chiavi di identità del dispositivo da hardware compromesso (vedi Attacco n. 5)
• Registrazione di dispositivi fraudolenti su reti con autenticazione dei dispositivi debole o assente

Difesa hardware: identità di dispositivo univoca e non estraibile, fornita nei Secure Element hardware durante la produzione. Autenticazione TLS reciproca — sia il dispositivo sia il server dimostrano la propria identità. Attestazione del dispositivo basata su certificati con archiviazione delle chiavi supportata dall’hardware.

---

8. Attacchi Sybil

In un attacco Sybil, un singolo avversario crea molteplici identità false all’interno di una rete IoT peer-to-peer o mesh, sopraffacendo i meccanismi decisionali o di routing della rete con nodi fraudolenti.

Perché è rilevante: i protocolli di rete mesh (Thread, Zigbee, LoRa mesh) si basano sul consenso tra peer per le decisioni di routing. Un aggressore Sybil che controlla oltre il 50% dei nodi percepiti può manipolare il routing dei dati, i risultati della Sensor Fusion o la governance della rete.

Come funziona:

• Generazione di numerose identità di nodi virtuali senza dispositivi fisici corrispondenti
• Sfruttamento di reti in cui la verifica dell’identità si basa esclusivamente su credenziali software
• Compromissione dei meccanismi di consenso nelle architetture IoT decentralizzate

Difesa hardware: attestazione dell’identità supportata dall’hardware — ogni nodo deve dimostrare il possesso di una chiave privata univoca archiviata in un Secure Element. Controllo di ammissione alla rete che convalida i certificati radicati nell’hardware prima di consentire la partecipazione di un nodo.

---

9. Attacchi replay

Gli aggressori catturano pacchetti di comunicazione legittimi e li ritrasmettono successivamente per attivare azioni non autorizzate — come sbloccare una porta, autorizzare un pagamento o reinviare un comando a un sensore.

Perché è rilevante: molti protocolli IoT mancano di nonce, timestamp o numeri di sequenza nei loro messaggi di autenticazione. Un comando di “sblocco” catturato per una serratura intelligente può essere riprodotto all’infinito se il protocollo non impone la freschezza del messaggio.

Come funziona:

• Cattura di trasmissioni RF con hardware SDR (ad es. i segnali dei telecomandi delle chiavi intelligenti)
• Registrazione e riproduzione di token di autenticazione o cookie di sessione
• Reinvio di comandi OTA privi di convalida tramite timestamp o contatore

Difesa hardware: nonce generati via hardware e contatori monotoni nei Secure Element. Autenticazione challenge-response in cui il dispositivo dimostra di essere attivo — non solo il possesso di una credenziale. RTC hardware (orologio in tempo reale) per la convalida dei timestamp negli scenari offline.

---

10. Manipolazione del firmware

Gli aggressori estraggono il firmware del dispositivo, lo sottopongono a reverse engineering per individuare le vulnerabilità, iniettano codice malevolo e riprogrammano il dispositivo con un’immagine firmware trojanizzata. Ciò garantisce un accesso persistente a livello root che sopravvive ai ripristini di fabbrica.

Perché è rilevante: a differenza del malware software, che può essere rimosso reinstallando il sistema operativo, le compromissioni a livello di firmware persistono nella memoria non volatile e vengono eseguite prima di qualsiasi misura di sicurezza a livello di sistema operativo. Sono eccezionalmente difficili da rilevare e correggere.

Come funziona:

• Estrazione del firmware tramite interfacce di debug, analisi degli aggiornamenti OTA o download dal sito web del fornitore
• Reverse engineering con Ghidra/IDA Pro per identificare bypass dell’autenticazione e punti di iniezione
• Riconfezionamento del firmware modificato e programmazione tramite accesso fisico o canali di aggiornamento compromessi
• Impianto di rootkit che si nascondono nel codice del bootloader, invisibili agli strumenti di sicurezza in fase di esecuzione

Difesa hardware: catena di Secure Boot verificata via hardware — il processore verifica la firma del bootloader rispetto a chiavi fuse nella memoria OTP (one-time programmable) prima di eseguire qualsiasi codice. La protezione dal rollback tramite contatori hardware monotoni impedisce gli attacchi di downgrade. Cifratura del firmware a riposo utilizzando chiavi accessibili solo al Secure Element.

---

11. Intercettazione e sorveglianza

Gli aggressori compromettono dispositivi IoT dotati di sensori — telecamere, microfoni, rilevatori di movimento, sensori ambientali — per condurre attività di sorveglianza non autorizzata di persone, spazi o processi industriali.

Perché è rilevante: la convergenza di sensori sempre attivi e connettività di rete crea capacità di sorveglianza che non esistevano nell’era pre-IoT. I dispositivi compromessi raccolgono dati in modo silenzioso, spesso per mesi prima di essere rilevati.

Come funziona:

• Accesso ai flussi di telecamere/microfoni tramite credenziali predefinite o CVE non corrette
• Compromissione di smart speaker per attivare i microfoni senza indicatori visivi/sonori
• Intercettazione dei dati dei sensori ambientali per dedurre schemi di occupazione e routine quotidiane

Difesa hardware: controlli di accesso applicati a livello hardware sulle periferiche dei sensori. Indicatori di privacy dedicati (LED) collegati direttamente alle linee di alimentazione dei sensori — impossibili da disattivare via software. Minimizzazione dei dati fin dalla progettazione — elaborazione locale dei dati dei sensori e trasmissione delle sole informazioni derivate, non dei flussi grezzi.

---

12. Divulgazione di informazioni

I dati sensibili trapelano dai dispositivi IoT attraverso API non protette, messaggi di errore prolissi, archiviazione non cifrata o metadati incorporati nel traffico di rete — inclusi numeri di serie dei dispositivi, versioni del firmware, topologia di rete, credenziali utente e parametri operativi.

Perché è rilevante: la divulgazione di informazioni è spesso la fase di ricognizione che abilita attacchi più devastanti. Conoscere l’esatta versione del firmware e l’architettura del chip di un dispositivo bersaglio restringe drasticamente lo spazio di ricerca degli exploit.

Come funziona:

• Interrogazione di endpoint di informazioni del dispositivo che non richiedono alcuna autenticazione
• Analisi dei messaggi broadcast mDNS/SSDP/UPnP che rivelano tipi e capacità dei dispositivi
• Estrazione di credenziali in chiaro da pacchetti di aggiornamento del firmware non cifrati
• Raccolta di metadati dei dispositivi da API cloud con controlli di accesso insufficienti

Difesa hardware: esposizione minima delle informazioni fin dalla progettazione. Le query sulla versione del firmware richiedono l’autenticazione. I certificati dei dispositivi rivelano solo le rivendicazioni di identità necessarie. Archiviazione cifrata a riposo per tutti i dati di configurazione e operativi sensibili.

---

13. Sfruttamento di API non sicure

Le API cloud che gestiscono le flotte di dispositivi IoT contengono spesso falle di autorizzazione — broken object-level authorization (BOLA), mass assignment, esposizione eccessiva dei dati — che consentono agli aggressori di accedere o controllare dispositivi appartenenti ad altri utenti.

Perché è rilevante: una singola vulnerabilità di un’API può compromettere un’intera flotta di dispositivi. A differenza degli attacchi hardware, che richiedono l’accesso fisico ai singoli dispositivi, gli attacchi alle API si propagano istantaneamente su milioni di endpoint.

Come funziona:

• Manipolazione dei parametri delle API (ad es. modifica del device_id nelle richieste per accedere ai dispositivi di altri utenti)
• Sfruttamento dell’assenza di rate limiting per l’enumerazione delle credenziali
• Abuso dei meccanismi webhook/callback per esfiltrare dati
• Attacchi di mass assignment che elevano i normali account utente a privilegi di amministratore

Difesa hardware: token di autenticazione del dispositivo supportati dall’hardware, che non possono essere falsificati o trasferiti tra dispositivi. Richieste API firmate con chiavi archiviate nei Secure Element — anche se la logica dell’API presenta falle, i dispositivi non autorizzati non possono falsificare un’autenticazione valida.

---

14. Brute force e credential stuffing

Gli aggressori provano sistematicamente ogni possibile combinazione di password (brute force) o utilizzano credenziali trapelate da altre violazioni di dati (credential stuffing) per ottenere l’accesso alle interfacce di gestione dei dispositivi IoT e alle dashboard cloud.

Perché è rilevante: i dispositivi IoT implementano raramente il blocco dell’account o il rate limiting a causa dei vincoli di risorse. Combinato con i massicci database di credenziali disponibili dalle violazioni storiche (oltre 24 miliardi di credenziali nelle compilation di leak pubbliche), questo attacco rimane estremamente efficace.

Come funziona:

• Strumenti automatizzati (Hydra, Medusa) che scorrono dizionari di credenziali predefinite
• Credential stuffing utilizzando coppie email/password provenienti da database violati
• Attacchi “low-and-slow” che restano al di sotto delle soglie di rilevamento
• Attacchi alle interfacce web di gestione dei dispositivi, alle API e ai servizi SSH/Telnet

Difesa hardware: l’autenticazione basata su certificati elimina del tutto le password. Blocco applicato a livello hardware dopo i tentativi falliti (implementato nel Secure Element, non aggirabile tramite modifica del firmware). Autenticazione a più fattori con token hardware per l’accesso amministrativo alle piattaforme di gestione dei dispositivi.

---

15. Cryptojacking

Gli aggressori dirottano le risorse di calcolo dei dispositivi IoT per estrarre criptovaluta — tipicamente privacy coin come Monero, che utilizzano algoritmi PoW memory-hard ottimizzati per il mining su CPU. Sebbene i singoli dispositivi IoT abbiano una potenza di calcolo minima, le botnet di migliaia di dispositivi generano ricavi di mining significativi.

Perché è rilevante: il cryptojacking è spesso considerato a “basso impatto” perché non sottrae dati né interrompe direttamente le operazioni. Tuttavia, provoca un aumento del consumo energetico (costi dell’elettricità più alti del 15–25%), un degrado accelerato dell’hardware, stress termico e una riduzione della durata di vita del dispositivo — particolarmente critica per i dispositivi da campo alimentati a batteria.

Come funziona:

• Distribuzione di payload di mining attraverso gli stessi vettori del malware di botnet (credenziali predefinite, CVE non corrette)
• Ottimizzazione dei miner per le architetture ARM/MIPS comuni nell’IoT
• Utilizzo di miner browser in stile coinhive sulle interfacce web dei dispositivi IoT
• Occultamento dell’attività di mining limitando l’utilizzo della CPU per evitare il rilevamento

Difesa hardware: il Secure Boot impedisce l’esecuzione di binari non autorizzati. Whitelisting delle applicazioni applicato a livello hardware — solo le applicazioni firmate e autorizzate possono essere eseguite. Monitoraggio dell’integrità in fase di esecuzione con attestazione supportata dall’hardware.

---

Il panorama delle minacce è in evoluzione — il vostro hardware è pronto?

I 15 tipi di attacco sopra descritti non sono teorici — sono attivi, documentati e sempre più automatizzati. Il Cyber Resilience Act dell’UE, in vigore dal 2025, impone ai produttori di affrontare queste minacce fin dalla progettazione, e non come ripensamenti.

In Inovasense progettiamo dispositivi IoT con la sicurezza integrata nell’hardware — dalla selezione del silicio e dall’architettura di Secure Boot fino alle comunicazioni cifrate e agli involucri resistenti alla manomissione. Ogni vettore di attacco di questa guida corrisponde a un livello di difesa che implementiamo come prassi standard.

Il nostro approccio Security-by-Design:

• Hardware Root of Trust — Secure Element (ATECC608B, OPTIGA Trust M) per l’archiviazione delle chiavi e l’identità del dispositivo
• Secure Boot autenticato — Catena di avvio verificata via hardware, dalla ROM all’applicazione
• Comunicazioni cifrate — TLS 1.3 / DTLS con autenticazione reciproca e certificate pinning
• Aggiornamenti OTA firmati — Firmware firmato in fase di build, verificato via hardware prima dell’installazione, con protezione dal rollback
• Protezione fisica dalla manomissione — Interfacce di debug disabilitate, flash cifrata, circuiti di rilevamento della manomissione
• Conformità al CRA — Documentazione completa per la valutazione della conformità al Cyber Resilience Act dell’UE

Fonti e riferimenti ufficiali

• Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Gazzetta ufficiale dell'UE)
• GDPR — Regulation (EU) 2016/679 — EUR-Lex (Gazzetta ufficiale dell'UE)