Foto: cliff1126 · Pixabay · Licenza dei contenuti Pixabay
Notte fonda, un e-commerce in dropshipping fermo, database e backup locali cifrati. Qui racconto come abbiamo fermato l'attacco, verificato che non ci fossero evidenze di furto dei dati dei clienti e riportato il negozio online con il 100% dei dati ripristinati.
Tocca una scheda per vedere da dove arriva il numero.
Dalle 03:14 UTC, quando parte la cifratura, alle 17:44 UTC, quando il traffico riapre: 14 ore e 30 minuti.
Ripristinati dal backup immutabile su AWS S3 con Object Lock, l'unica copia che il ransomware non poteva raggiungere. Gli ordini arrivati tra le 00:00 e le 03:14, successivi al backup, sono stati ricostruiti con un plugin sviluppato da noi che legge le email d'ordine e le riconverte in record del database.
Cinque voci: mancate vendite, penali dropshipping, pubblicità a vuoto, intervento di incident response e customer care. Vedi il grafico.
Il Recovery Point Objective misura quanto indietro si trova il punto di ripristino: l'ultimo backup immutabile è delle 00:00, la cifratura parte alle 03:14. Gli ordini di quella finestra non sono andati persi: li abbiamo ricostruiti dalle email d'ordine.
L'analisi forense ha confermato che l'attacco si è limitato alla cifratura sul posto: la notifica al Garante ha riguardato solo la temporanea indisponibilità dei dati.
AxulStyle vende online in due modi: dal proprio magazzino e in dropshipping, con i fornitori collegati via API. Quella notte il monitoraggio segnala che la piattaforma non è più raggiungibile. Nessun ordine entra, i webhook verso i fornitori si interrompono, le campagne Google e Meta continuano a portare clienti su una pagina di errore.
Poi la scoperta più dura: sul server sono cifrati il database, i file del sito e anche i backup locali. È il momento in cui ti chiedi se hai perso tutto, e se i dati dei tuoi clienti sono finiti nelle mani di qualcun altro.
Alle 03:45 arriva la chiamata d'emergenza. Da lì la risposta segue un ordine preciso: contenere, raccogliere le prove, ricostruire su basi pulite.
Trascina il cursore (o usa le frecce) per rivivere la notte minuto per minuto, in ora UTC.
Il monitoraggio segnala la piattaforma irraggiungibile.
Il team interno conosceva bene il proprio negozio. Una cifratura totale, però, chiede procedure e strumenti che si usano solo in queste ore, e che è normale non avere in casa.
Il VPS era del tutto inaccessibile e non esisteva una procedura di Disaster Recovery testata per uno scenario di cifratura completa.
Il ransomware aveva colpito il database di produzione e la cartella /backup/local/. Bisognava verificare l'integrità dei backup immutabili remoti e orchestrare un ripristino sicuro.
Nomi, indirizzi, cronologia ordini: in caso di furto scatta l'obbligo di notifica al Garante Privacy entro 72 ore. Serviva una risposta basata sulle prove.
Prima di riattivare pagamenti e API dropshipping bisognava garantire che la nuova infrastruttura fosse priva di backdoor, web shell o altre persistenze.
L'analisi forense ha confermato che l'attacco si è limitato alla cifratura sul posto. La notifica al Garante è stata limitata a un evento di temporanea indisponibilità dei dati (perdita di disponibilità), senza violazione della riservatezza.
Ogni attacco riuscito è una catena: basta spezzare un anello per fermarlo. Seleziona una tappa per vedere cosa è successo e perché ha funzionato.
Il servizio SSH, quello che serve agli amministratori per entrare nel server, rispondeva a qualunque indirizzo pubblico. Da un nodo della rete Tor parte un attacco brute-force: password provate una dopo l'altra, prima su utenti inesistenti come admin, poi su deployer.
Fail2ban, lo strumento che blocca gli indirizzi dopo troppi tentativi sbagliati, non era attivo, e nessuno li ha fermati.
tentativi falliti in circa 52 minuti, dalle 02:10:14 alle 03:02:41
La password dell'utente deployer cede. L'autenticazione si basava sulla sola password, senza chiavi SSH obbligatorie e senza MFA: indovinarla bastava per entrare.
MFA, autenticazione a più fattori: oltre alla password serve una seconda prova, per esempio un codice temporaneo (TOTP) o una chiave fisica come YubiKey.
Sfrutta CVE-2023-32629, nota come «Game-Over OverlayFS»: un difetto del kernel Ubuntu che consente a un utente senza privilegi di ottenere i permessi di root, senza conoscere la password di amministratore. La correzione esisteva già, ma gli aggiornamenti di sicurezza erano fermi da oltre 14 mesi.
CVE è il codice pubblico con cui si cataloga una vulnerabilità nota. OverlayFS è il file system del kernel Linux che sovrappone più cartelle in una sola vista, usato tra l'altro dai container.
Con il controllo totale del server, lo script del ransomware arresta MySQL e cifra il database (/var/lib/mysql), i file del sito (/var/www) e i backup locali. Il negozio va offline: undici minuti dopo scatta l'allarme del monitoraggio.
Il VPS viene isolato dalla rete tramite il firewall del provider cloud e con regole locali che lasciano passare solo il SOC. Alle 04:30 la memoria RAM e i log vengono copiati su un supporto forense: lì restano le tracce di ciò che l'attaccante ha fatto, ed è da lì che si capisce se ha portato via dati. Il processo di cifratura viene individuato e terminato.
Perché non spegnere subito il server? La RAM si cancella allo spegnimento: con lei sparirebbero processi, connessioni e chiavi in memoria, cioè le prove.
Il server compromesso viene distrutto, senza tentare di ripulirlo: alle 09:00 parte un nuovo VPS sanificato con kernel aggiornato. Alle 11:30 database e file tornano dal backup immutabile su AWS S3, dopo averne verificato il blocco. Seguono VPN, SSH solo con chiavi, patch del kernel e CrowdSec. Alle 17:44 il traffico riapre.
S3 Object Lock applica il modello WORM (scrivi una volta, leggi molte volte): finché il blocco è attivo, la copia non si può modificare né cancellare. Per questo il ransomware non l'ha raggiunta.
Un estratto reale del registro di autenticazione del server e i comandi della risposta, nell'ordine in cui sono avvenuti.
# auth.log · brute-force da nodo Tor (185.220.101.x)02:10:14 vps-prod-01 sshd[14201]: Failed password for invalid user admin from 185.220.101.x port 49152 ssh202:10:18 vps-prod-01 sshd[14205]: Failed password for deployer from 185.220.101.x port 49156 ssh2... [omessi 4.120 tentativi falliti] ...03:02:41 vps-prod-01 sshd[18942]: Accepted password for deployer from 185.220.101.x port 51200 ssh2# 03:03 escalation a root via CVE-2023-32629 (OverlayFS)03:14:00 vps-prod-01 systemd[1]: Stopping MySQL Community Server...03:14:02 vps-prod-01 kernel: [ 4120.5512] Encryptor process (pid 19102) traversing /var/www/# risposta · isolamento di rete: passa solo il SOC (195.201.x.x)iptables -Fiptables -A INPUT -p tcp -s 195.201.x.x --dport 22 -j ACCEPTiptables -A INPUT -j DROP# acquisizione della RAM con LiME, caricato come modulo del kernelinsmod lime.ko "path=/mnt/usb_forensic/ram_dump.lime format=raw"# individuazione e arresto del processo di cifraturaps aux | grep -E 'encrypt|crypto|payload'kill -9 19102# verifica dello stato Object Lock (WORM) del backup remotoaws s3api get-object-legal-hold \--bucket axulstyle-backups-*** \--key db_backup_****-**-**_00-00.sql.gz
Le righe in corsivo sono commenti. L'indirizzo dell'attaccante (nodo Tor), il nome del bucket e il giorno del backup sono mascherati; l'indirizzo del SOC era già mascherato.
Apri ogni tappa per il dettaglio. Puoi filtrare per fase.
Da un nodo della rete Tor (185.220.101.x) parte una raffica di tentativi di accesso sulla porta 22, aperta a tutto Internet: prima utenti inesistenti come admin, poi l'utente deployer. Fail2ban non è attivo e nessuno blocca l'indirizzo.
Dopo oltre 4.120 tentativi falliti la password debole cede. Senza chiavi SSH obbligatorie né MFA, la password era l'unica barriera.
L'attaccante sfrutta CVE-2023-32629 («Game-Over OverlayFS»), una vulnerabilità nota del kernel Ubuntu: da utente senza privilegi a root, senza la password di amministratore. Gli aggiornamenti di sicurezza erano fermi da oltre 14 mesi.
Lo script arresta MySQL e cifra il database (/var/lib/mysql), i file del sito (/var/www) e i backup locali. Da questo momento il negozio è offline.
I sistemi di monitoraggio segnalano che la piattaforma non è raggiungibile. Intanto le campagne Google e Meta continuano a portare visitatori su un sito che risponde con errore.
AxulStyle ingaggia il team di incident response esterno. La priorità è fermare il danno senza distruggere le prove.
Il VPS viene isolato tramite il firewall del provider cloud; le regole locali lasciano passare solo il SOC. L'attaccante non raggiunge più il server.
Dump della memoria RAM con LiME su supporto forense e copia dei log: servono a ricostruire le azioni dell'attaccante e a verificare se ha portato via dati. Il processo di cifratura viene individuato e terminato.
Il VPS compromesso viene distrutto, non ripulito: si riparte da un server nuovo con kernel aggiornato, così nessuna backdoor o persistenza può sopravvivere.
I dati tornano dal backup immutabile su AWS S3 Object Lock, dopo averne verificato lo stato di blocco (WORM). È la copia che il ransomware non ha potuto toccare.
Accesso solo da VPN aziendale, SSH solo con chiavi, kernel con la patch per CVE-2023-32629, CrowdSec con blocco automatico sul firewall.
Riapertura del traffico e operatività al 100%: pagamenti e integrazioni dropshipping ripartono su un'infrastruttura verificata.
Nel conto di un incidente, oltre al tempo di fermo, entrano la pubblicità che continua a correre e la gestione di fornitori e clienti. Seleziona una voce per evidenziarla nell'anello.
Valori in euro, ordinati come nella valutazione d'impatto.
Quote calcolate sul totale e arrotondate al decimale.
La cifratura del database ha interrotto la sincronizzazione in tempo reale con il magazzino dei fornitori esterni. Nella finestra di errore sono stati venduti articoli non più disponibili a stock: rimborsi gestiti a mano e notifiche ai marketplace per evitare penalizzazioni sul profilo venditore.
Nessuna delle debolezze era esotica: erano impostazioni rimaste come all'inizio. Qui sotto trovi com'era l'infrastruttura e com'è adesso.
Porta 22 aperta a tutto l'indirizzamento IP pubblico.
Porta 22 chiusa sull'IP pubblico: si entra solo dalla VPN aziendale con MFA, da IP statico autorizzato.
Sola password, debole, senza MFA né chiavi SSH obbligatorie.
PasswordAuthentication no: solo chiavi Ed25519, più MFA con TOTP o YubiKey.
Fail2ban non attivo: migliaia di tentativi senza alcun blocco.
CrowdSec / Fail2ban con blocco automatico degli IP malevoli sul firewall di rete.
Aggiornamenti di sicurezza fermi da oltre 14 mesi: kernel vulnerabile a CVE-2023-32629.
Kernel ≥ 6.2.0-31-generic e unattended-upgrades: patch critiche di kernel e sistema entro 24 ore dal rilascio.
Backup locali sullo stesso server, cifrati insieme ai dati di produzione.
Strategia 3-2-1-1-0: 3 copie, 2 supporti, 1 off-site, 1 immutabile su S3 Object Lock, 0 errori nei test di ripristino quotidiani.
Nessuna procedura testata per uno scenario di cifratura totale.
Una procedura di Disaster Recovery, verificata ogni giorno dai test di ripristino automatici.
A tutto questo si aggiungono verifiche periodiche: penetration test annuale e vulnerability assessment trimestrale, perché chi difende un server deve cercare le porte aperte prima che lo faccia qualcun altro.
Se il tuo server è fermo adesso, ogni minuto conta e ogni prova pure. Se invece ti sei riconosciuto in una delle debolezze di questa pagina, possiamo chiuderle prima che diventino una notte come questa.
Attacco in corso? Non spegnere il server e non cancellare nulla: memoria e log sono le prove che servono. Scrivimi.
Raccontami cosa vuoi proteggere, costruire o far crescere. Ti aiuto a capire da dove partire.
Da oltre trent'anni faccio tre cose. Cerco le falle della tua azienda prima che le trovi chi vuole entrare. Imposto il marketing perché i risultati si possano misurare. E aiuto persone e aziende a capire chi sono, prima ancora di decidere cosa vendere.
Certified Ethical HackerSicurezza informatica dal 1993
Google Ads
Meta
WordPress
WooCommerce
Shopify
TikTokCosì non devo chiederti in chat le stesse cose e la mia prima risposta parla già del tuo caso. Ci vuole meno di un minuto.
Passo 1 di 4
Questo sito è un progetto indipendente e non è affiliato, autorizzato o sponsorizzato da Google LLC. I marchi Google Ads, Analytics e BigQuery sono di proprietà esclusiva di Google LLC.
I servizi offerti non sono associati, approvati o sponsorizzati da Meta Platforms, Inc. Facebook e Instagram sono marchi registrati di Meta.
Le certificazioni esposte attestano il superamento degli esami tecnici ufficiali ma non configurano un rapporto di dipendenza con i fornitori delle tecnologie.
Ultimo aggiornamento: febbraio 2026 · Disclaimer completo
