Sysmon: correlare processi, DNS e connessioni con ProcessGuid

Tre eventi isolati possono suggerire una storia sbagliata. Per investigare un processo Windows occorre sapere quali eventi sono abilitati, quali campi sono preservati dall’ingestione e quale finestra temporale permette una correlazione affidabile.

Verificare la raccolta prima della regola

La documentazione Sysmon di Microsoft distingue Process Create, evento 1, Network Connect, evento 3, e DNS Query, evento 22. L’evento 3 è disabilitato per impostazione predefinita. Non basta installare Sysmon per ottenere una timeline completa di rete.

Preparare una scheda del sensore: versione, configurazione applicata, esclusioni, eventi effettivamente ricevuti e latenza di inoltro. Le configurazioni del SIEM possono rinominare campi o scartare dati. Annotare anche intervalli di arresto del servizio e cambiamenti del filtro: un’assenza può essere un problema di copertura.

Usare l’identificatore giusto

Secondo Microsoft, gli eventi Sysmon includono identificatori utili alla correlazione; l’evento 1 riporta ProcessGuid e dati del processo padre. I timestamp degli eventi sono in UTC. L’evento 22 descrive query DNS anche quando non riescono.

Il PID può essere riutilizzato. Come proposta di normalizzazione, conservare identificatore dell’host, ProcessGuid e timestamp sorgente insieme al tempo di ingestione. Quando si ricostruisce la parentela, usare il ParentProcessGuid dell’evento di creazione e verificare che il riferimento esista nella finestra raccolta.

Una timeline minima di lavoro

Lo schema seguente è pseudocodice, non una query pronta per uno specifico SIEM:

processi = eventi con EventID = 1
per ogni (host, ProcessGuid):
    aggiungi eventi 22 e 3 con stessa chiave
    ordina per timestamp sorgente
    conserva eventi originali e filtri applicati

Limiti: evitare correlazioni troppo facili

Una query seguita da una connessione non dimostra che la connessione abbia usato quella risposta: cache, risoluzioni parallele e IP condivisi possono confondere il join. Confrontare intervallo, risultato della query e contesto applicativo. Non associare ogni evento DNS a tutte le connessioni del processo senza documentare il criterio.

In uno scenario sintetico, un browser avvia un updater che risolve un dominio raro. Per valutare il caso, confrontare una seconda macchina con la stessa versione e recuperare il pacchetto installato. Un nome raro o una catena padre-figlio insolita resta un candidato, non un’etichetta di malware.

Mitigazione: validare senza eseguire malware

1. In laboratorio creare un processo benigno riconoscibile e annotare l’ora UTC.
2. Generare una risoluzione e una connessione verso un servizio controllato.
3. Verificare quali processi eseguono realmente le operazioni e quali eventi arrivano.
4. Controllare che il parser conservi i GUID e distinguere eventi mancanti da eventi esclusi.
5. Ripetere dopo una modifica del filtro e confrontare i volumi.

Il risultato della caccia deve includere evidenza sorgente, criterio di correlazione, lacune e motivazione della decisione. Le command line possono contenere informazioni sensibili: limitarne accesso e conservazione al necessario per l’indagine.

Fonti essenziali

Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.

• Microsoft Sysinternals — Sysmon
• Microsoft — eventi Sysmon