Sbagliare tabella è il modo più comune di non trovare nulla

In advanced hunting una query sintatticamente perfetta su una tabella sbagliata restituisce zero righe, e zero righe non è un errore: è una risposta. È la trappola più insidiosa del threat hunting, perché il vuoto viene letto come “l’evento non è successo” invece che come “l’ho cercato nel posto sbagliato”. Prima di scrivere KQL, l’analyst deve rispondere a una domanda sola: da quale prodotto proviene il segnale che sto cercando? Ogni tabella è il raccoglitore di un workload preciso, e i confini fra workload sono più netti di quanto suggerisca il portale unificato.

Le tabelle di Microsoft Defender XDR

Il modello mentale è per dominio di segnale, non per tipo di minaccia.

Endpoint (Defender for Endpoint) — il prefisso Device raggruppa la telemetria raccolta dal sensore sulla macchina: DeviceProcessEvents per le esecuzioni e le command line, DeviceNetworkEvents per connessioni in uscita e destinazioni remote, DeviceFileEvents per creazione, modifica e copia di file, DeviceLogonEvents per gli accessi al dispositivo, DeviceRegistryEvents per chiavi e valori di registry (persistenza, tampering).

Email e collaboration (Defender for Office 365) — EmailEvents contiene un record per messaggio con mittente, destinatario, verdetto e azione di delivery; EmailAttachmentInfo e EmailUrlInfo esplodono rispettivamente gli allegati e le URL contenute nei messaggi; UrlClickEvents registra i click sui link protetti da Safe Links, cioè il momento in cui l’utente ha davvero interagito.

Identità (Defender for Identity) — IdentityLogonEvents raccoglie gli eventi di autenticazione osservati sull’Active Directory on-premises, IdentityDirectoryEvents le modifiche e gli eventi sui domain controller, IdentityInfo l’anagrafica degli account (attributi, ruoli, gruppi) usata per arricchire il resto.

Alert — AlertInfo ha una riga per alert (titolo, severity, categoria MITRE, prodotto di origine), AlertEvidence ha una riga per entità collegata all’alert (device, account, file, IP). Correlare le due è il pattern standard per passare dall’alert alle entità coinvolte.

App SaaS (Defender for Cloud Apps) — CloudAppEvents traccia le attività degli utenti nelle applicazioni cloud monitorate.

Le tabelle di Microsoft Sentinel

Nel workspace di Log Analytics le tabelle non sono organizzate per workload Defender ma per connettore di origine. SecurityEvent contiene gli eventi di sicurezza Windows raccolti tramite Azure Monitor Agent con le relative data collection rule; Syslog la stessa cosa per i sistemi Linux; CommonSecurityLog normalizza i log in formato CEF di firewall, proxy e appliance di terze parti. Sul fronte identità cloud, SigninLogs contiene i sign-in di Microsoft Entra ID e AuditLogs le modifiche alla directory, mentre AzureActivity copre le operazioni sul control plane di Azure (chi ha creato, modificato o cancellato una risorsa). ThreatIntelligenceIndicator ospita gli indicatori di threat intelligence importati, da usare in join per il matching. Infine il piano di gestione del SOC: SecurityAlert raccoglie gli alert provenienti dalle soluzioni connesse, SecurityIncident gli incident di Sentinel con il loro ciclo di vita, Heartbeat la salute e la connettività degli agent — la tabella da guardare quando il sospetto è che i dati non arrivino affatto.

Il criterio di scelta

La domanda operativa è sempre la stessa. Segnale nato sul dispositivo? Tabelle Device*. Nato in una mailbox? Tabelle Email* o UrlClickEvents. Nato su AD on-premises? Tabelle Identity*. Nato su Entra ID? Non è in advanced hunting: è SigninLogs/AuditLogs in Sentinel. Nato da infrastruttura di rete o sistemi non Microsoft? CommonSecurityLog o Syslog. Il portale unificato permette di interrogare anche le tabelle del workspace Sentinel quando l’ambiente è onboarded, ma questo non fonde gli schemi: le colonne restano quelle del prodotto di origine, e una query scritta per DeviceLogonEvents non gira su SecurityEvent.

Trappole tipiche d’esame

  • Cercare i sign-in cloud di un utente compromesso → SigninLogs, non DeviceLogonEvents: DeviceLogonEvents registra gli accessi al dispositivo; l’autenticazione a Microsoft Entra ID vive in SigninLogs. Confonderle è l’errore più frequente.
  • Sapere se l’utente ha davvero cliccato il link del phishing → UrlClickEvents, non EmailUrlInfo: EmailUrlInfo dice che l’URL era nel messaggio, UrlClickEvents dice che qualcuno l’ha aperto.
  • Elencare i device coinvolti in un alert → AlertEvidence, non AlertInfo: AlertInfo è una riga per alert senza le entità; le entità stanno in AlertEvidence, da correlare su AlertId.
  • Attività sospette su un domain controller on-premises → Identity*, non SigninLogs: Defender for Identity copre l’AD on-premises; Entra ID Protection e SigninLogs coprono l’identità cloud. Lo scenario dice sempre quale dei due.
  • Chi ha cancellato la risorsa in Azure → AzureActivity, non AuditLogs: AuditLogs è la directory di Entra ID, il control plane delle risorse Azure è AzureActivity.
  • La query non restituisce nulla e sospetti un problema di ingestion → Heartbeat: prima di riscrivere il KQL, verifica che i dati arrivino; l’assenza di righe può dipendere da una data collection rule mancante, non dalla logica.