Nell’analisi degli incidenti l’endpoint è spesso il punto in cui l’attività malevola lascia le tracce più ricche. Saper leggere i log host e attribuire loro il giusto valore probatorio è competenza centrale del dominio Host-Based Analysis del CBROPS.

Le fonti host: cosa registra cosa

Tre famiglie di log coprono la quasi totalità delle evidenze endpoint.

Fonte Piattaforma Cosa cattura Esempio di valore
Windows Event Logs Windows Autenticazioni, avvio processi, servizi, policy 4624 logon riuscito, 4625 fallito, 4688 process creation, 4104 script block PowerShell
Sysmon (System Monitor) Windows (agente aggiuntivo) Telemetria granulare guidata da config XML 1 process create (con hash), 3 network connect, 11 file create, 22 DNS query
syslog Linux/Unix, appliance, apparati di rete Messaggi con facility + severity, centralizzabili auth.log, accessi SSH, eventi kernel

I Windows Event Logs sono suddivisi in canali (Security, System, Application) e usano gli Event ID come chiave di ricerca. Sono nativi ma poco granulari: 4688 dice quale processo è nato, non necessariamente la command line completa o gli hash, se non abilitato via audit policy.

Sysmon colma questo gap. Non è attivo di default: va installato e alimentato con un file di configurazione che definisce cosa loggare (una config permissiva genera rumore enorme). Il suo punto di forza è che l’Event ID 1 registra automaticamente gli hash (MD5, SHA-256, IMPHASH) dell’immagine eseguita, la command line e il processo padre — materiale d’oro per la caccia agli IOC. Ricorda i tre più chiesti all’esame: 1 (process creation), 3 (network connection), 11 (file creation).

syslog è il modello del mondo *nix e degli apparati: messaggi testuali con facility (auth, cron, daemon…) e severity (0 emergency → 7 debug), inoltrabili a un collector centrale (spesso un SIEM). Non ha hash nativi, ma è la spina dorsale della raccolta host su sistemi non-Windows.

Dai log agli IOC

Un Indicator of Compromise è un artefatto osservabile che segnala compromissione. Dai log host si estraggono tipicamente:

  • Hash di file/processi (da Sysmon EID 1) — l’IOC più affidabile perché lega l’indicatore a un contenuto binario esatto.
  • IP e domini di C2 (Sysmon EID 3 e 22).
  • Nomi file, path, chiavi di registro, named pipe.
  • Command line e sequenze padre-figlio anomale (es. un processo Office che lancia una shell).

Gli IOC atomici (un hash, un IP) sono facili da correlare ma volatili; gli attaccanti li cambiano. Per questo si preferiscono indicatori comportamentali, ma ai fini del CBROPS l’estrazione di IOC atomici dai log resta il primo passo del triage.

Classificazione delle evidenze

Non tutte le evidenze pesano uguale. Il framework da conoscere:

  • Best evidence: l’artefatto originale e diretto, quello di massimo valore probatorio. Un’immagine forense del disco, il log system originale, il binario del malware. In tribunale è la prova primaria.
  • Corroborating evidence: prova di supporto che rafforza la best evidence senza sostituirla. Un log di firewall che conferma la connessione C2 già vista nel log host corrobora, non prova da solo.
  • Indirect (circumstantial) evidence: prova indiziaria; suggerisce una conclusione per inferenza, non la dimostra direttamente.

Un’evidenza può essere altered/tampered (alterata/manomessa): se l’integrità non è garantita, perde valore probatorio.

Hashing e catena di custodia

L’integrità è ciò che distingue una prova utilizzabile da una contestabile. Si calcola un hash (SHA-256 è lo standard; MD5 è legacy e collision-prone) dell’evidenza al momento dell’acquisizione e lo si ricalcola a ogni passaggio della chain of custody. Se l’hash coincide, il dato non è stato modificato; se differisce, l’evidenza è compromessa.

Il punto concettuale critico: l’hash prova l’integrità del dato, cioè che non è cambiato — NON prova chi lo ha creato né chi lo ha manipolato. Autenticazione dell’autore e non ripudio richiedono altri meccanismi (firme digitali, log di accesso, testimonianza). L’hash è un sigillo di integrità, non una firma di paternità.

Trappole tipiche d’esame

  • Scenario: la traccia chiede l’evidenza “di maggior valore probatorio” → best evidence (l’artefatto originale), NON la corroborating.
  • Scenario: un log secondario che conferma un fatto già stabilito da un’altra fonte → è corroborating evidence, non best.
  • Scenario: gli hash di acquisizione e verifica coincidono → dimostrano solo integrità/non-alterazione, non l’identità dell’autore.
  • Scenario: serve la command line e l’hash del processo su Windows → risposta Sysmon (Event ID 1), non il solo 4688 nativo.
  • Scenario: raccogliere log di accesso da host Linux e apparati di rete verso un collector → syslog, con severity/facility, non Windows Event Log.