Un attacco informatico non è una domanda da fare a un consulente a posteriori. È un'emergenza che si gestisce in minuti, non in giorni. Se non hai un piano di Incident Response testato, stai scommettendo che non ti capiterà mai. Noi, di Meteora Web, lo vediamo ogni giorno: aziende che scoprono un ransomware alle 8 di mattina e alle 10 stanno ancora cercando il numero del tecnico. Non puoi permettertelo.
Questa guida è il tuo manuale operativo su Incident Response (IR) e Digital Forensics (DFIR). Non teoria accademica: processi, comandi, decisioni che abbiamo messo in pratica su server Linux, e-commerce WordPress e infrastrutture cloud di clienti reali. Partiamo dal problema concreto: sei stato colpito. Cosa fai subito? E come ti prepari per non farti più sorprendere?
1. Incident Response Framework: le fasi che salvano il fatturato
Un framework IR non è burocrazia. È una checklist che ti tiene lucido quando tutto va a fuoco. Noi seguiamo lo standard NIST SP 800-61, adattato alla realtà delle PMI: Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity.
Preparation: il 90% del successo
La preparazione significa avere strumenti e runbook già pronti. Non ti serve un SOC da milioni di euro. Ti serve:
- Un server di log centralizzato (ELK, Graylog o anche solo Rsyslog).
- Backup immutabili offline (testati ogni mese).
- Credenziali di accesso a cloud provider, DNS, hosting in un vault sicuro.
- Un contatto diretto con un fornitore di DFIR (noi facciamo anche quello, ma meglio averti già in rubrica).
Esempio concreto: Un cliente e-commerce aveva tutti i backup sullo stesso account AWS del server di produzione. Ransomware cripta tutto, compresi i backup. Recovery impossibile. Noi li abbiamo migrati su backup offline su S3 Glacier con policy di retention immutabile. Costa poco, salva l'azienda.
Detection & Analysis: non ignorare i segnali
Un attacco non arriva con un cartello luminoso. Si vede da cose piccole: un login da un IP sospetto, un picco di traffico, un processo che consuma CPU senza motivo. Il 90% dei nostri interventi su IR arriva da un alert che qualcuno ha ignorato per giorni.
Sponsored Protocol
Strumenti base: Google Search Console per siti WordPress (ci dicono che il sito è stato compromesso), SIEM come Wazuh (open source, lo installiamo noi sui server), analisi dei log di accesso HTTP (errore 500 sparso? Leggi il file di log).
Calcolo del danno: Veniamo dalla contabilità. Quando un attacco ferma l'e-commerce per 6 ore, non parliamo di reputazione: parliamo di fatturato perso. Un sito che genera 5.000€ al giorno perde 1.250€ in 6 ore. Aggiungi il costo del recovery, della forensics, della comunicazione ai clienti. Un piano IR costa molto meno.
2. Forensics Digitale: acquisizione dell'evidenza e catena di custodia
Se l'incidente finisce in tribunale (e sempre più spesso succede), ogni file che tocchi senza metodo diventa inutilizzabile come prova. La catena di custodia è la registrazione di chi, quando, come e perché ha interagito con l'evidenza.
Acquisizione forense di un server Linux
Non fare mai shutdown -h now su un server attaccato. Perdi la memoria volatile. Procedura base:
# 1. Acquisire la RAM con LiME o fmem
sudo insmod lime.ko "path=/mnt/forensics/ramdump.mem format=lime"
# 2. Acquisire disco con dd (o ddrescue per blocchi danneggiati)
sudo dd if=/dev/sda of=/mnt/forensics/diskimage.raw bs=4M conv=noerror
# 3. Hash SHA256 di ogni file acquisito
sha256sum /mnt/forensics/*.raw >> /mnt/forensics/hashes.txt
# 4. Registrare tutto in un documento timestampato (catena di custodia)Regola d'oro: Mai montare il filesystem originale in scrittura. Usa write-blocker hardware o software (ad esempio, mount -o ro,loop).
Acquisizione da e-commerce (WordPress/MySQL)
Qui il tempo è critico perché il sito deve tornare online. Noi procediamo in parallelo: clone del filesystem via rsync su un server forense, dump del database con mysqldump con flag --single-transaction e --hex-blob, acquisizione dei log del web server e di error_log. Poi ripristiniamo da backup pulito mentre analizziamo la copia.
3. Analisi Malware: sandbox, detonazione e behavioral analysis
Non eseguire mai un malware sospetto sul tuo computer di lavoro. Usa una sandbox isolata. Strumenti gratuiti e potenti:
Sponsored Protocol
- Cuckoo Sandbox (open source, da configurare su VM dedicata)
- Any.Run (online, interattivo, buono per analisi rapide)
- Joe Sandbox (versione cloud con report dettagliati)
Caso reale: Un cliente aveva ricevuto una email con un allegato .doc che chiamava un payload da un server remoto. Noi abbiamo caricato il documento su Any.Run, osservato le connessioni verso un IP noto come C2, e bloccato quel dominio a livello DNS. Senza analisi, avremmo potuto pulire il PC ma lasciare la backdoor.
Behavioral analysis: cosa guardare
Il malware moderno non scrive sempre file sul disco. Lascia tracce nel registro di sistema (Windows), nei cron job (Linux), o modifica il boot. Usa Process Monitor (Procmon) su Windows o lsof/strace su Linux per vedere in tempo reale quali risorse vengono toccate.
4. Memory Forensics: Volatility e analisi della RAM
La RAM contiene tutto: processi in esecuzione, connessioni di rete, password in chiaro, e persino il codice del malware che cerca di nascondersi. Volatility è lo strumento di riferimento. Esempio di analisi su un dump di RAM Linux:
# Identificare il profilo del sistema
volatility -f ramdump.mem imageinfo
# Elencare i processi attivi
volatility -f ramdump.mem --profile=LinuxUbuntu1804x64 linux_pslist
# Cercare processi nascosti (rootkit)
volatility -f ramdump.mem linux_pstree
# Estrarre la command line di ogni processo
volatility -f ramdump.mem linux_cmdline
# Catturare connessioni di rete al momento del dump
volatility -f ramdump.mem linux_netstatAttenzione: La memoria va acquisita a server acceso, prima di qualsiasi operazione. Se il server è già stato riavviato, hai perso la prova più importante.
5. Log Analysis per IR: SIEM, correlazione e pivot
I log sono la timeline di un attacco. Senza log centralizzati, sei cieco. Noi usiamo Wazuh (open source, basato su OSSEC + Elastic) per aggregare log da server, firewall, applicazioni. Un esempio di regola di correlazione (decoded) per rilevare tentativi di brute force su WordPress:
wordpress
authentication
^.*POST /wp-login.php.*
^.*error: Incorrect password.*
Pivotare da un indicatore all'altro: Se un IP compare nei log di accesso e anche nei log del firewall come connessione a una porta non standard, quello è un pivot. Lo stesso IP che appare in un alert di malware su un PC potrebbe essere il C2 di un attacco in corso.
Sponsored Protocol
6. Ransomware IR: contenimento, decrittazione e recovery
Il ransomware è l'incidente più devastante per una PMI. Non esiste backdoor: se cripta i dati, o hai backup puliti o paghi (e spesso non riottieni i dati). Il nostro flusso:
- Isolamento istantaneo: Spegnere la rete del server colpito, staccare il cavo di rete, non spegnere il server (potresti perdere la RAM con le chiavi di decrittazione).
- Identificare la variante: Usa ID Ransomware (id-ransomware.malwarehunterteam.com) caricando la nota di riscatto o l'estensione dei file. Spesso esistono decrittatori gratuiti.
- Recovery da backup: Se hai backup immutabili, ripristina su hardware pulito. Non fidarti del server originale finché non è stato formattato e la causa dell'infezione eliminata.
- Forensics post-incidente: Acquisisci copia forense del server colpito per capire il vettore d'ingresso (spesso RDP esposto, phishing, vulnerabilità plugin).
Posizione netta: Noi non consigliamo mai di pagare. Se paghi, finanzierai il prossimo attacco. Ma capiamo la pressione: se non hai backup, il business può collassare in 48 ore. Ecco perché preparazione significa backup testato regolarmente.
7. Network Forensics: Wireshark e analisi del traffico malevolo
Il traffico di rete non mente. Anche se il malware cancella i log locali, il firewall e il router hanno registrato connessioni. Wireshark è il coltellino svizzero.
Catturare il traffico durante un incidente
# Cattura su interfaccia specifica, senza bufferizzare in memoria
sudo tcpdump -i eth0 -s 0 -w /mnt/forensics/traffic.pcap -C 100 -W 10Analisi di una connessione C2
Filtra per IP sospetto e poi per tcp.flags.syn==1 per vedere le connessioni in uscita. I malware spesso usano DNS query verso domini generati algoritmicamente (DGA): filtra dns.qry.name e cerca pattern come random hex strings.
Sponsored Protocol
Esempio: Analizzando un pcap di un cliente, abbiamo notato una connessione HTTPS verso un IP in Russia su porta 443 con un certificato self-signed. Il dominio DNS era stato registrato 24 ore prima. Quella era la C2. Abbiamo bloccato l'IP a livello di firewall e il malware ha smesso di comunicare.
8. Timeline Analysis: ricostruire un attacco cronologicamente
Ricomporre gli eventi in ordine temporale è la parte più delicata. Ogni evidenza (log, file system, RAM, traffico) ha un timestamp. Noi usiamo Plaso (log2timeline) per estrarre timeline super dettagliate.
Step pratici:
- Raccogliere tutti i log: sistema (auth.log, syslog, Windows Event Log), applicativi (Apache, NGINX), firewall.
- Convertire in formato comune (CSV o JSON).
- Caricare in un foglio di calcolo o in Timesketch (GUI open source) e ordinare per timestamp.
- Identificare il primo evento: il primo login non autorizzato, il primo file malevolo scaricato, la prima connessione C2.
Caso concreto: Un sito WordPress fu defacciato. La timeline ha mostrato che l'accesso FTP era stato usato 3 giorni prima da un IP diverso dal solito. Il cliente aveva usato la stessa password per FTP e email, e un attacco di phishing aveva rubato le credenziali email. Il defacement era solo la ciliegina sulla torta: avevano già perso l'account di posta.
9. Threat Hunting: caccia proattiva alle minacce
Non aspettare l'alert. Cerca attivamente indicatori di compromissione (IoC) prima che causino danni. Noi dedichiamo una finestra settimanale per ogni cliente: analisi dei log di rete, ricerca di hash noti (VT), verifica di processi anomali.
Tecnica semplice: Usa YARA per scansionare il filesystem alla ricerca di pattern di malware. Esempio di regola YARA per rilevare un webshell PHP:
rule webshell_php_base64 {
strings:
$a = "base64_decode" nocase
$b = "eval(" nocase
$c = "system(" nocase
condition:
all of them
}Lancia YARA sulle directory web ogni notte. I falsi positivi si riducono con il tempo.
10. Post-Incident Review: lessons learned e miglioramento continuo
L'incidente non finisce quando il sito torna online. Finisce quando hai scritto un report e aggiornato i tuoi processi. Il post-mortem deve rispondere a tre domande:
Sponsored Protocol
- Come è entrato l'attaccante? (Root cause)
- Perché non l'abbiamo rilevato prima? (Gap nei controlli)
- Cosa faremo per evitare che si ripeta? (Azioni concrete, con scadenze e responsabilità)
Esempio dal nostro lavoro: Dopo un ransomware su un server di un cliente, abbiamo scoperto che il vettore era un plugin WooCommerce non aggiornato. Azione: attivazione degli aggiornamenti automatici per i plugin critici, implementazione di un WAF (Wordfence), e backup giornaliero offsite. Sei mesi dopo, un altro tentativo di exploit è stato bloccato perché il plugin era già aggiornato.
In sintesi — cosa fare adesso
Non aspettare che un incidente ti faccia alzare dal letto alle 3 di notte. Ecco le azioni immediate:
- Scrivi un piano di Incident Response anche su due pagine. Definisci ruoli (chi chiama, chi isola, chi analizza), strumenti (log server, backup, sandbox) e procedure di contenimento.
- Testa i backup oggi stesso. Ripristina un file vecchio da backup immutabile. Se non funziona, il backup non esiste.
- Centralizza i log su un SIEM open source (Wazuh o Grafana Loki). Almeno gli errori del web server e i log di login.
- Installa un agente YARA sulle macchine critiche (server web, database) e scansiona periodicamente.
- Fai un esercizio di table-top: simula un ransomware con il tuo team. Scoprirai falle che non immaginavi.
Noi, di Meteora Web, accompagniamo le aziende in tutto il percorso DFIR: dalla preparazione alla gestione dell'emergenza fino alla forensics post-incidente. Se hai dubbi o se un attacco è già in corso, contattaci subito. Prenota una consulenza d'emergenza.
Link utili:
- NIST SP 800-61 Rev. 2 - Incident Response
- SANS DFIR - Digital Forensics Incident Response
- Volatility Foundation - Memory Forensics
Leggi anche:
