Threat hunting sul traffico TLS: cosa dimostrano i metadati

La cifratura non elimina ogni possibilità di analisi di rete. Cambia le evidenze disponibili. Una detection sostenibile dichiara quali proprietà misura e non presenta un fingerprint o una connessione periodica come prova del contenuto trasmesso.

Separare contenuto e osservazione

TLS 1.3, RFC 8446, protegge integrità e confidenzialità del canale; la lunghezza dei dati non è completamente nascosta e può essere influenzata dal padding. Dopo ServerHello i messaggi dell’handshake sono cifrati: un sensore passivo non può assumere di leggere sempre il certificato del server.

Prima della caccia, scrivere una matrice di visibilità: traffico sul sensore, log del proxy, risoluzioni DNS e telemetria endpoint. Una mancata osservazione può dipendere dalla posizione del sensore, da perdita di pacchetti o da una modalità di trasporto diversa. Non tradurla automaticamente in evasione.

Costruire una timeline con Zeek

conn.log descrive connessioni con timestamp, durata, endpoint, byte e stato. orig_bytes e resp_bytes rappresentano byte di payload, distinti dai conteggi a livello IP. Non sono direttamente la dimensione di un documento applicativo.

ssl.log aggiunge metadati TLS, tra cui versione e server_name quando disponibili. Il campo si chiama ssl.log anche per TLS. Correlare con uid nel contesto del sensore ed evitare join globali su identificatori estratti da raccolte differenti senza verificarne l’unicità.

jq -r '[.ts, .uid, .["id.orig_h"], .["id.resp_h"], (.duration // 0), (.orig_bytes // 0), (.resp_bytes // 0)] | @tsv' conn.log

Dal beacon candidato all’indagine

Proposta operativa: raggruppare per asset e destinazione, poi misurare distanza tra connessioni e dispersione degli intervalli. Confrontare giorni lavorativi e periodi di inattività. Un processo che comunica regolarmente durante la notte è interessante solo se quel comportamento non è coerente con la funzione dell’asset.

Documentare come siano trattate connessioni persistenti, retry e record incompleti. Un’applicazione può multiplexare molte richieste in una sola connessione; contare solo aperture di socket può perdere il comportamento rilevante. Eseguire il confronto su gruppi omogenei, conservando la distribuzione e non soltanto una media.

Limiti: fingerprint e nomi non sono identità

Un fingerprint del client descrive caratteristiche dell’implementazione osservata, non l’intenzione del programma. Applicazioni legittime possono condividerlo e un attaccante può usare librerie comuni. Analogamente, una destinazione condivisa da molte applicazioni non attribuisce il traffico a un singolo servizio.

Trattare un server_name mancante come dato assente. Non assumere SNI sempre leggibile: Encrypted Client Hello (RFC 9849) protegge il ClientHello interno, che può contenere il nome della destinazione reale. Per verificare un candidato, cercare il processo che possiede la connessione, il suo percorso, la firma e l’utente; chiedere al proprietario del servizio una spiegazione confrontabile con i tempi osservati.

Mitigazione e criterio di chiusura

In uno scenario sintetico, una cadenza regolare può corrispondere a un agent di monitoraggio. Chiudere il candidato solo dopo aver correlato configurazione e processo, non perché il dominio è noto. Per un’escalation conservare campioni, qualità della cattura e alternative escluse. Se mancano endpoint e payload, il risultato resta un sospetto di comunicazione: non una prova di esfiltrazione o di esecuzione di comandi.

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.

• RFC Editor — TLS 1.3
• Zeek — conn.log
• Zeek — ssl.log