NotPetya: il cyberattacco più costoso di sempre

25 febbraio 2026 • 11 min read

Alla fine di giugno 2017, in Ucraina inizia qualcosa che, a prima vista, sembra “il solito ransomware”: computer che si riavviano, file improvvisamente non disponibili e una richiesta di riscatto sullo schermo.

Poche ore dopo è chiaro: non è un incidente locale. È un incendio.

Il nome rimasto impresso è NotPetya. Ancora oggi è l’esempio perfetto di come una presunta “semplice ondata di malware” possa trasformarsi in un evento capace di mettere in ginocchio aziende in tutto il mondo e causare danni nell’ordine dei miliardi.

In questo articolo voglio collegare due cose:

La storia dietro NotPetya: cosa è successo e perché è costato così tanto?
La prospettiva pratica: cosa significa per aziende “normali” oggi, non solo per colossi Fortune 500?

La parte scomoda di NotPetya non è che fosse “troppo complesso”. La parte scomoda è: è spaventosamente realistico.

Perché lo scrivo nel 2026? Perché oggi parliamo di phishing con deepfake guidati dall’IA, ma in caso di emergenza falliamo ancora sulle stesse cose banali del 2017: segmentazione mancante e backup attaccati allo stesso “tubo” della produzione.

NotPetya in 5 minuti: cosa è successo?

Per inquadrare il tutto, bisogna ordinare gli eventi.

Il 27 giugno 2017, NotPetya compare prima in Ucraina e poi si diffonde globalmente a velocità elevatissima. Un elemento chiave è stato un aggiornamento compromesso di un software di contabilità molto diffuso in Ucraina (M.E.Doc). Il malware non è entrato per “un click stupido”, ma tramite un meccanismo che le aziende usano ogni giorno: gli aggiornamenti.

Ed è un punto che molti sottovalutano col senno di poi: alla base era un supply-chain attack. M.E.Doc non è stato un caso: era la leva perfetta, perché gli update sono fidati per design.

La lezione per oggi è scomoda ma cruciale: puoi avere tutto “sotto controllo” internamente; se il software del tuo commercialista, di un fornitore, un connettore ERP o uno strumento di terze parti viene compromesso, sei comunque dentro il raggio d’impatto. Il rischio supply chain non è “un problema cloud”: è, molto concretamente, un problema di update.

Una volta dentro la rete, non si parla più di singoli endpoint, ma di Lateral Movement (movimento laterale):

Via SMB e vulnerabilità note (tra cui EternalBlue / MS17-010, un exploit trapelato dal toolkit della NSA), NotPetya poteva propagarsi su altri sistemi Windows senza interazione dell’utente.
In parallelo, usava credential dumping (Mimikatz/LSASS) per estrarre password/hash dalla RAM e muoversi con credenziali reali di admin.
Per l’esecuzione remota, sfruttava strumenti “normali” di amministrazione (ad es. PsExec/WMI). Questa combinazione è pericolosa perché, nei log, può sembrare “operatività normale” all’inizio.

Questa era la “ricetta segreta”: exploit per saltare velocemente su nuove macchine, credenziali dalla memoria per privilegi reali e, poi, scalare con strumenti nativi.

Punto importante: patchare da solo non sarebbe bastato. Anche con sistemi patchati contro EternalBlue, si poteva comunque cadere appena il malware riusciva a raccogliere credenziali/hash admin validi altrove nella rete.

NotPetya giocava anche con il tempo: aveva una delay e non forzava subito il “big bang” (reboot/wipe), ma solo dopo un po’. Questo rende la detection più difficile e, di fatto, è un classico contro il sandboxing: il malware non “detona” immediatamente mentre in background sta già scalando.

Il risultato è esattamente quello che si vede sempre:

Prima, alcuni sistemi diventano “strani”.
Poi, improvvisamente, un’intera sede crolla.
E se non reagisci velocemente (tagliare la rete, bloccare account, chiudere i confini di segmentazione), l’incidente può diventare multi-sede.

Perché “ransomware” era solo una copertura

NotPetya è stato percepito come ransomware perché mostrava una richiesta di riscatto. Ma tecnicamente e operativamente era altro.

Il punto chiave: NotPetya era, nella realtà, un wiper. Malware il cui scopo non è “fare soldi”, ma distruggere sistemi e interrompere l’operatività.

Può sembrare pignoleria, ma in un incidente cambia tutto:

Con ransomware classico, a volte c’è una possibilità di recupero tramite chiavi o negoziazione.
Con un wiper, l’obiettivo è “rotto”. Pagare in Bitcoin non ti salva.

Nel caso di NotPetya c’è un dettaglio tecnico che sottolinea ancora di più il carattere da wiper: sovrascriveva l’MBR (Master Boot Record) e cifrava la MFT (Master File Table). E persino la parte “ransomware” era implementata male: l’ID di installazione visualizzato era generato casualmente e non era correttamente legato a una chiave di decifratura utilizzabile. Tradotto: non c’era praticamente una via di ritorno.

Ecco perché NotPetya era così perfido: ha spinto molte aziende verso il playbook sbagliato all’inizio. Pensi “playbook ransomware”, ma ti serve un “playbook di disaster recovery”.

Il fatto che l’attacco fosse più distruzione che profitto è coerente anche con l’attribuzione successiva: diversi governi hanno attribuito pubblicamente NotPetya ad attori statali russi.

10 miliardi di dollari: perché è costato così tanto?

Se guardi solo l’etichetta “ransomware”, il danno sembra difficile da spiegare. “Si ripristina dal backup e basta, no?”

In pratica, NotPetya è stato così costoso soprattutto perché ha colpito dove spesso si investe poco: disponibilità.

Il principale costo non è stato il malware, ma lo stop.

Linee di produzione ferme.
Logistica di nuovo su carta.
Identità e domini da ricostruire.
Applicazioni, integrazioni e dipendenze che cadono a catena.
E non succede in un solo sistema, ma in tanti contemporaneamente.

Per questo NotPetya viene spesso definito “il cyberattacco più costoso di sempre”. Alcune stime parlano di circa 10 miliardi di dollari di danni complessivi.

Lo si vede anche nei numeri delle singole aziende: Merck, FedEx (incl. TNT Express) e Mondelez hanno descritto nei loro report che non era “un tema IT”, ma un tema di business con effetti reali su ricavi, costi e capacità di consegna.

NotPetya ha avuto anche un enorme strascico legale: aziende contro assicurazioni. Alcuni assicuratori hanno provato a non pagare classificandolo come “Act of War” (quindi un attacco guidato da uno Stato). Un caso noto è quello di Mondelez contro il proprio assicuratore. La lezione, ancora oggi, è dura: la mia cyber-assicurazione copre attacchi statali, o scatta una war exclusion proprio quando serve?

Update per lettori pro: il caso Mondelez è stato risolto nel 2023. Da allora (e, più in generale, dopo NotPetya), il mercato ha stretto le clausole in molti contratti: in molte polizze, gli attacchi “state-motivated” sono definiti in modo più restrittivo o esplicitamente esclusi. Questo rende la cyber-assicurazione un rischio finanziario concreto se non capisci davvero il wording.

E non va sottovalutato: anche se “ripristini solo l’IT”, in realtà stai combattendo contro dipendenze.

Un esempio citato spesso è Maersk: non si è trattato di qualche file cifrato, ma di ricostruire sistemi core, identità e IT operativa per far ripartire porti e logistica.

La storia è leggendaria perché mostra quanto identità e backup possano essere fragili: Maersk ha perso praticamente tutto il suo Active Directory, tranne un unico Domain Controller in Ghana che, a causa di un blackout, era offline al momento dell’attacco. Quel “Lucky Punch” è diventato un backup offline involontario: con quel singolo server fisico sono riusciti a ricostruire l’AD globale e accelerare il recovery.

Alla fine, non colpisce solo “l’IT”, ma il business direttamente:

Nel food: produzione, pianificazione e supply chain si fermano.
Nel marittimo: i container restano fermi.
Nel pharma: manufacturing, processi di qualità e capacità di consegna vanno sotto pressione.

Ecco perché il numero è così alto: la schermata di riscatto è solo un sintomo. Il danno vero è lo stop.

Caso pratico: l’attacco che mi aspetterei in un’azienda “normale”

Voglio descrivere intenzionalmente un caso che non sa di Hollywood. Non “state actor vs big tech”, ma uno scenario plausibile per una media azienda.

Immagina un’azienda di medie dimensioni:

Una sede principale e una seconda più piccola.
Un setup Windows classico: AD, file server, qualche VM, un ERP.
Più una manciata di sistemi che non tocchi quasi mai: controller di macchine, software legacy, un “Windows Server 2008 qualcosa” perché il vendor non ha mai aggiornato.
Backup presenti: giornaliero su un NAS, settimanale anche su un secondo sistema.

Ed ecco il punto che molti sottovalutano:

Questa azienda non ha “poca security” perché tutti sono incompetenti. È perché operatività e tempo vincono sempre.

Le patch vengono rimandate perché la produzione è stretta. La segmentazione resta “per dopo” perché i VLAN sono lavoro. Le password di admin locale sono cresciute storicamente. E il NAS è ovviamente online, perché altrimenti il restore sarebbe troppo scomodo.

La timeline (realistica, non drammatica)

Un martedì mattina arriva un aggiornamento. Può essere un fornitore, uno strumento di un prestatore, un connettore… qualcosa che aggiorna automaticamente. Oppure è un sistema compromesso da un partner con accesso via VPN.

08:10: i primi client diventano instabili. Un reboot qui, un errore strano là.
08:25: il primo file server rallenta. I ticket helpdesk aumentano.
08:40: improvvisamente “il dominio è strano”. Il login è lento, le GPO impazziscono.
09:00: un admin fa login “per dare un’occhiata veloce”. Spesso è lì che il movimento laterale accelera.
09:20: un’intera sede è, di fatto, offline.

E ora viene la parte che capisci davvero solo dopo:

Se in quel momento non tagli duro, il danno non scala in modo lineare: scala in modo esponenziale.

E ovviamente arriva la domanda che arriva sempre:

“Dobbiamo pagare?”

Con NotPetya, la risposta amara era: anche se volessi, probabilmente non sarebbe stata una soluzione. Psicologicamente cambia l’incidente, perché devi metterti subito in modalità “ricostruzione”, non “decifratura”.

Più aspetti, più sistemi devi rifare. Più sistemi devi rifare, più tempo resti in modalità emergenza. E più resti in emergenza, più costa.

Quello che fa davvero male

Dopo poche ore è chiaro: non è “ripristiniamo qualche file”. È “ricostruiamo Active Directory e sistemi core”.

E poi scopri:

I backup erano online e sono stati colpiti.
La documentazione non è aggiornata.
Hai poche “golden images” per reimaging rapido.
Le credenziali admin erano ovunque.
Nessuno ha mai provato come segmentare una sede in modo pulito in 30 minuti.

È il momento in cui un incidente IT diventa una crisi aziendale.

Cosa fa diversamente un SOC oggi (e cosa c’entra l’IA)

In un grande Security Operations Center (SOC) arrivano ogni giorno miliardi di eventi da tantissime fonti. Non è più “un admin che guarda i log del firewall”, ma un processo industrializzato di telemetria, correlazione, automazione e analisi umana.

Interessante è la divisione dei ruoli:

IA/automazione come prima linea: ordina, correla, trova pattern e filtra l’ovvio.
Persone come seconda/terza linea: quando il caso è critico o ambiguo, analisti intervengono, decidono e coordinano la risposta.

Sembra “roba da grandi”, ma la lezione vale anche per le aziende piccole:

Non devi costruire un SOC. Ma ti serve la stessa mentalità:

Raccogli segnali (EDR, firewall, auth log).
Definisci cosa è “normale”.
E hai un processo che reagisce in minuti, non in giorni.

NotPetya nel 2017 era già così veloce che nessun umano avrebbe potuto “reagire abbastanza in fretta” una volta partita la propagazione. Il punto dell’IA non è tanto “ancora più veloce”, ma: aiutarti a trovare prima l’anomalia nel rumore (ad esempio, alle 03:00 di notte, all’improvviso 500 macchine che provano a parlare SMB tra loro). Sono quei minuti che decidono: vedere prima, contenere prima, isolare prima.

E poi c’è questo mindset che vedo sempre più spesso come default:

Assume breach.

Pianifica come se l’attaccante fosse già dentro. Non per paranoia, ma per pragmatismo.

Cosa considero il minimo oggi (senza budget enterprise)

Se vuoi portarti via qualcosa da NotPetya, è questo:

NotPetya non è stata “una vulnerabilità”. È stata una catena di debolezze che si amplificavano a vicenda.

La buona notizia: proprio per questo, alcune basi riducono tantissimo il rischio.

1) Patch ed exposure management (sul serio)

Gli update Windows critici (soprattutto attorno a SMB) non possono essere “prima o poi”.
Tutto ciò che è esposto verso l’esterno ha priorità.
E se serve legacy: almeno segmentato, con regole chiare.

2) Rendere il lateral movement scomodo

Separare account admin (quotidiano vs admin).
Password admin locali uniche per device (LAPS).
Non lasciare WMI/PsExec aperti ovunque.
Limitare SMB dove non serve davvero.

3) Segmentazione, ma pragmatica

Non devi fare Zero Trust “perfetto” domani. Ma:

Client, server, backup e OT/produzione non devono stare in una rete piatta.
I Domain Controller sono tier 0 e vanno protetti come tali.
Il traffico est-ovest merita la stessa attenzione del traffico Internet.

4) Backup: offline, immutabili, testati

Lo dico come lo vedo in tanti progetti:

Un backup sempre online e sempre scrivibile spesso non è un backup quando serve.

3-2-1 è un buon inizio.
Storage immutabile (o supporti offline) cambia le regole del gioco.
Test di restore obbligatori. Non “abbiamo backup”, ma “abbiamo provato i restore”.

5) Runbook e un “kill switch” per le sedi

Non ti serve un manuale da 80 pagine. Ma ti serve chiarezza:

Chi decide che una sede va isolata?
Come blocchi account rapidamente?
Quali sistemi devono tornare su per primi (AD, DNS, DHCP, VPN, ERP)?

E sì: va provato, altrimenti in crisi non serve.

Reality check: con NotPetya, in molti casi la misura più efficace non è stata “un altro tool”, ma separazione fisica. Su Maersk ci sono racconti di persone che correvano negli uffici e staccavano cavi (rete/energia) dagli switch per fermare la propagazione. Sembra banale, ma a volte è la migliore high-tech security quando contano i secondi.

Conclusione

Per me, NotPetya resta uno dei migliori esempi del perché la sicurezza non si risolve con “abbiamo l’antivirus”.

Non è stato devastante perché fosse magico. È stato devastante perché ha colpito punti deboli molto normali:

fiducia negli aggiornamenti
troppo movimento laterale
poca segmentazione
backup troppo vicini alla rete di produzione

Ed è proprio per questo che è così rilevante per aziende “normali”.

Se investi oggi, non investire solo in tool: investi in resilienza (visibilità, risposta rapida e capacità di ripristinare in modo pulito). È la differenza tra “una giornata pessima” e “un trimestre che non recuperi”.

Fonti e approfondimenti

Alla prossima, Joe