Log Analysis per Incident Response — SIEM, Correlazione e Pivot per Rispondere agli Attacchi

Hai appena ricevuto un alert dal SIEM: un host interno sta contattando un IP su una porta non standard. In quel momento hai due strade: ignorare l'alert e sperare sia un falso positivo, oppure iniziare a scavare nei log. Noi, di Meteora Web, abbiamo affrontato scenari simili decine di volte. Un alert senza una metodologia di log analysis è solo rumore. La differenza tra un incidente gestito in poche ore e un disastro che manda offline un'azienda sta nella capacità di correlare eventi e fare pivot tra i log. In questa guida ti mostriamo come si fa, con comandi reali e un approccio operativo.

Cosa rende diversa la log analysis in Incident Response rispetto al monitoring ordinario?

Il monitoring ordinario guarda soglie e soglie: troppo traffico, troppi errori, un servizio down. Genera alert, ma non dice cosa è successo. La log analysis in Incident Response (IR) è un lavoro da detective: devi ricostruire una timeline, trovare l'origine, capire il movimento laterale e l'esfiltrazione. Non ti interessa la media degli errori, ti interessa il singolo evento anomalo e le sue connessioni.

Facciamo un esempio concreto. Un nostro cliente aveva un e-commerce WordPress compromesso. Il SIEM segnalava un login amministrativo da un IP cinese mai visto. Da lì abbiamo fatto pivot: abbiamo cercato quell'IP nei log di accesso del server web, trovato una richiesta POST anomala, poi nei log di audit abbiamo visto la modifica di un file di plugin. Dai log di sistema abbiamo visto una connessione outbound verso un dominio sospetto. Tutto questo in 15 minuti, perché avevamo un metodo per correlare e pivotare.

La differenza è questa: il monitoring ti dice “c'è un problema”, la log analysis in IR ti dice “ecco esattamente cosa è successo, quando e come”.

Cosa fare subito: Quando ricevi un alert, non limitarti a leggerlo. Chiediti: “Questo evento ha un prima e un dopo nei log?”. Annota il timestamp esatto e inizia a raccogliere i log di quel minuto.

Come correlare eventi tra diversi log source per identificare un attacco?

La correlazione è il cuore della log analysis in IR. Un singolo log non basta: devi incrociare auth log, web server log, firewall log, DNS log e log di sistema. L’obiettivo è trovare un filo rosso che lega eventi apparentemente separati.

Correlazione temporale

Se il SIEM ti dice che alle 14:32:15 c'è stato un login riuscito da un IP sconosciuto, e alle 14:32:45 una modifica di file, e alle 14:33:10 una connessione outbound, hai già una sequenza sospetta. Il tempo è il primo fattore di correlazione.

Correlazione per entità

Stesso IP, stesso nome utente, stesso processo, stesso host. Ecco un esempio di correlazione manuale via riga di comando. Partiamo dal log degli accessi SSH:

# Trova tutti i tentativi di login falliti
sudo grep "Failed password" /var/log/auth.log | awk '{print $1,$2,$3,$11}' | sort | uniq -c | sort -nr

Questo comando ti dà gli indirizzi IP con più tentativi falliti. Ora selezionane uno e verifica se c'è stato un login riuscito:

# Cerca login riusciti dallo stesso IP
sudo grep "Accepted password" /var/log/auth.log | grep "IP_SOSPETTO"

Se trovi un successo, prendi il timestamp e cerca nei log del web server (es. nginx) se quello stesso IP ha fatto richieste anomale:

# Cerca richieste da quell'IP nei log di accesso
sudo grep "IP_SOSPETTO" /var/log/nginx/access.log | awk '{print $4,$7}'

Poi confronta con i log di sistema per vedere se nello stesso momento sono stati eseguiti comandi come wget, curl o modifiche a file sensibili.

Strumento potente: usa journalctl con l'unità specifica e filtra per IP:

sudo journalctl -u sshd -g "IP_SOSPETTO" --since "2026-04-10 14:30" --until "2026-04-10 14:35"

Questa correlazione manuale è veloce e funziona anche senza SIEM. Noi la usiamo spesso quando dobbiamo fare un’analisi rapida su server Linux.

Attenzione: il vero pivot non è lineare. L'IP del login potrebbe essere diverso dall'IP della connessione outbound (ad esempio se l'attaccante ha usato un proxy). Allora devi cercare un nome utente comune o un file comune.

Correlazione tramite SIEM

I SIEM hanno regole di correlazione native. Ad esempio in Wazuh puoi creare una regola che genera un alert quando un login riuscito è seguito da un comando sospetto:

<rule id="100001" level="12">
  <if_sid>5715</if_sid>  <!-- Regola per login riuscito SSH -->
  <match>wget|curl|nc -e|bash -i</match>
  <description>SSH login seguito da comando sospetto</description>
  <group>incident_response,</group>
</rule>

Questa regola non guarda solo il singolo evento, ma la sequenza temporale tra due log diversi. È così che trasformi i log in intelligence.

Cosa fare ora: Scegli un alert recente ricevuto dal tuo SIEM. Estrai il timestamp e l’IP. Esegui manualmente una correlazione tra almeno tre sorgenti di log (ad es. auth + web + firewall). Scrivi su un foglio la sequenza temporale che emerge.

Quali tecniche di pivot sui log ti permettono di seguire l'attaccante?

Il pivot è l’arte di passare da un indicatore a un altro per ricostruire il percorso dell’attaccante. Inizi da un IP, arrivi a un utente, poi a un file, poi a un processo, poi a una nuova connessione. Ecco le tecniche principali.

Pivot da IP a sessioni

Un IP compare nei log del firewall. Esegui una query su tutti i log che contengono quell'IP per trovare tutte le sessioni attive:

sudo grep "IP_SOSPETTO" /var/log/firewall.log | awk '{print $1,$2,$5,$7}'

Se il firewall logga i flussi, puoi vedere porte di destinazione e protocolli. Un IP che contatta su porte 22 e 80 è più sospetto di uno che contatta solo 443.

Pivot da sessione a utente

Dai log di sistema, cerca il login associato a quell'IP e ottieni il nome utente:

sudo last | grep "IP_SOSPETTO"

O su sistemi con auditd:

sudo ausearch -ui username -ts recent

Ora hai un utente. Con l'utente, cerca nei log di modifica dei file (inotify, auditd, File Integrity Monitoring) per vedere quali file ha modificato.

Pivot da file a processo

Supponiamo che il file modificato sia /var/www/html/wp-content/uploads/malware.php. Cerca nei log di sistema se un processo ha scritto o eseguito quel file:

sudo ausearch -f /var/www/html/wp-content/uploads/malware.php -i

Su Windows, userei Get-WinEvent con l'Event ID 4663 (accesso a file). Il risultato ti dà il processo (es. /usr/bin/php) e l'ora esatta.

Pivot da processo a connessione

Se il processo è php, controlla se ha avviato connessioni di rete in quello stesso minuto. Usa auditd per le connessioni (syscall connect) o i log di sistema:

sudo ausearch -sc connect -i -ts 04/10/2026 14:30:00 -te 04/10/2026 14:35:00

In questo modo passi da un file a una connessione outbound. È così che chiudi il cerchio.

Strumento avanzato: lnav (Logfile Navigator) è un tool interattivo che permette di navigare tra più file di log, applicare filtri e fare pivot su campo di interesse. Noi lo usiamo spesso per analisi rapide su server senza SIEM.

Cosa fare subito: Prendi un log di un incidente passato (anche simulato). Applica la catena di pivot: IP -> sessione -> utente -> file -> processo -> connessione. Documenta ogni passo. Vedrai che il percorso si svela.

Come costruire una timeline dell'incidente usando i log?

Una timeline è la spina dorsale della comunicazione in IR: ti permette di raccontare la storia dell'attacco a chi deve decidere (CISO, cliente, forze dell'ordine). La costruisci estraendo timestamp da tutte le sorgenti e ordinandoli.

Raccogliere i log e normalizzare i timestamp

Non tutti i log hanno lo stesso fuso orario. Il primo passo è convertire tutto in UTC. Su Linux, usa date per convertire se conosci il fuso:

# Converti un timestamp locale in UTC
date -d "2026-04-10 15:30:00 CEST" -u +"%Y-%m-%dT%H:%M:%SZ"

Poi estrai tutti gli eventi di interesse da ogni log source e mettili in un file unico. Esempio di estrazione rapida:

# Estrai da auth.log e syslog l'evento specifico
sudo grep "2026-04-10" /var/log/auth.log | grep -E "Accepted|Failed|session" >> timeline.txt
sudo grep "2026-04-10" /var/log/syslog | grep -E "malware|wget|curl" >> timeline.txt
sudo grep "2026-04-10" /var/log/nginx/access.log >> timeline.txt

Poi ordina per timestamp. Se i log hanno formati diversi, usa sort -k1,2 oppure importa in un foglio di calcolo. Per analisi più pulite, usiamo awk per normalizzare il campo timestamp come primo campo.

Timeline con SIEM

Se usi ELK o Splunk, puoi creare un report temporale con una query. In Splunk:

index=* (sourcetype=linux_secure OR sourcetype=apache_access) earliest="2026-04-10T14:30:00" latest="2026-04-10T15:00:00"
| table _time, src_ip, user, command, file_path
| sort _time

Questa query ti dà una timeline perfetta. Ogni riga è un evento con il timestamp esatto.

Cosa fare adesso: Per il prossimo incidente, abituati a estrarre subito una timeline di 30 minuti intorno all'alert. Usa il comando grep su più file di log e ordina con sort. Conservala come primo documento dell'IR.

Strumenti pratici per la log analysis in IR: SIEM, ELK, e riga di comando

Non sempre hai un SIEM enterprise. Noi lavoriamo spesso su server di clienti che hanno solo i log di sistema base. Ecco gli strumenti che usiamo, dal più semplice al più complesso.

Riga di comando (sempre disponibile)

• grep/awk/sed: per estrarre e filtrare.
• lnav: per navigare interattivamente tra più log con highlight e filtri.
• journalctl: per sistemi con systemd, filtra per unità, priorità, timestamp.
• ausearch: per auditd, query strutturate su utente, file, syscall.
• tshark: per analizzare file pcap o catturare in tempo reale.

Wazuh (SIEM open source)

Lo usiamo spesso per clienti che vogliono un SIEM senza licenze costose. Wazuh ha un'interfaccia web con dashboard di correlazione, regole personalizzate, e plugin per pivotare su eventi. Esempio di regola di correlazione che genera un alert quando un IP appare in più di 3 tipi di log diversi entro 5 minuti:

<rule id="100002" level="10">
  <if_sid>502,5715,80660</if_sid>  <!-- regole di login, modifica file, connessione -->
  <match>srcip=IP_SOSPETTO</match>
  <description>Stesso IP in auth, file e conn log entro 5 min</description>
  <options>no_full_log</options>
</rule>

ELK Stack (Elasticsearch, Logstash, Kibana)

Per chi ha volumi enormi. Kibana permette di creare dashboard di correlazione, usare il linguaggio di query KQL per cercare eventi con campi specifici. Ad esempio per trovare tutti gli eventi di un utente in un range temporale:

user.name: "admin" AND @timestamp >= "2026-04-10T14:30" AND @timestamp <= "2026-04-10T15:00"

Poi puoi cliccare su un campo per fare pivot immediato su quell'entità.

Cosa fare ora: Se non hai ancora un SIEM, inizia con lnav e un set di comandi grep. Se hai Wazuh o ELK, crea una dashboard specifica per IR che mostri: timeline, IP sospetti, tentativi di login, modifiche file e connessioni outbound.

Cosa fare adesso

1. Definisci una procedura di raccolta log per IR: Prima che scoppi un incidente, prepara un elenco delle fonti di log del tuo sistema (auth.log, syslog, web access, firewall, DNS) e i comandi per estrarle rapidamente.
2. Esercitati con un incidente simulato: Crea uno scenario di attacco (ad es. un PHP shell scaricato via web) e ripeti i passi di correlazione e pivot descritti qui. Usa solo riga di comando.
3. Configura una regola di correlazione nel tuo SIEM: Se usi Wazuh, implementa la regola che lega login + modifica file + outbound conn. Mettila in produzione.
4. Documenta la timeline: Per ogni incidente reale o simulato, produci un file di timeline ordinato con timestamp UTC e fonti.
5. Approfondisci: Leggi la guida completa su Incident Response e Forensics Digitale per il quadro generale.

Noi, di Meteora Web, vediamo ogni giorno aziende che subiscono attacchi e non sanno da dove partire con i log. Con questi strumenti e questa metodologia, puoi passare dal panico alla risposta mirata in pochi minuti. Il resto è pratica.