Ricostruire la sequenza con la device timeline
Quando un alert punta a un endpoint, la domanda del SOC non è “cosa ha rilevato il sensore” ma “cosa è successo prima e dopo”. La device timeline in Microsoft Defender XDR è il flusso cronologico dei segnali raccolti dal sensore di Defender for Endpoint su quella macchina: creazione di processi, connessioni di rete, scritture di file, modifiche al registry, logon. Serve a ricostruire la catena — quale parent process ha lanciato cosa, quale binario ha scaricato quale payload, quale account era attivo — e quindi a identificare il punto d’ingresso.
La timeline è uno strumento a profondità su un device. Per verificare se lo stesso indicatore è presente su altre macchine passi ad advanced hunting, che espone gli stessi segnali in forma interrogabile nelle tabelle DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents. Criterio: timeline per la profondità su una macchina, advanced hunting per l’ampiezza sulla flotta. Le finestre di retention delle due viste non coincidono: se il quesito parla di eventi “vecchi”, verifica il dato corrente nella documentazione ufficiale invece di assumere.
Evidence ed entità: leggere l’incident, non solo l’alert
Nella pagina dell’incident la scheda evidence elenca le entità coinvolte — file, processi, IP, URL, account, device, mailbox — con il verdetto associato (malicious, suspicious, clean) e lo stato di remediation prodotto dall’automated investigation. È la vista che risponde a “cosa ha già fatto il sistema e cosa resta a me”.
Da lì si scende sulle entity page: la pagina di un file mostra prevalenza, dispositivi in cui è comparso, firma digitale e permette la deep analysis (detonazione in sandbox) quando il verdetto non è chiaro; la pagina di un account collega i logon rilevati sugli endpoint alle identità; la pagina del device raccoglie alert, timeline e response action. Il ragionamento: incident per l’ampiezza, entità per il verdetto, timeline per la sequenza.
Live response: cosa risolve, prerequisiti e ruolo
La live response apre una shell remota verso un device onboardato, per ispezionarlo e agire in tempo reale senza trasferte né tool di terze parti: elencare processi e connessioni attive, esaminare il file system, prelevare un artefatto, eseguire uno script pubblicato nella library, rimuovere un elemento persistente. È la scelta giusta quando l’indagine richiede un’interazione mirata e iterativa che nessun pacchetto statico può dare.
Prerequisiti che l’esame verifica quasi sempre: il device deve essere onboardato e raggiungibile, con una versione di sistema operativo supportata; la funzionalità live response va abilitata nelle advanced feature del tenant; per i sistemi server esiste un’impostazione dedicata separata (live response for servers) da attivare a parte; per lanciare script non firmati serve l’ulteriore toggle sugli unsigned script. Sul piano delle autorizzazioni non basta un ruolo di sola lettura: servono i permessi di active remediation actions, distinti fra comandi di base e comandi avanzati (download di file dal device, esecuzione di script, remediation).
Investigation package e le altre response action
Il collect investigation package (o forensics package) è l’alternativa non interattiva: con una sola azione il servizio raccoglie dal device un set standard di artefatti — autorun, programmi installati, processi, servizi, scheduled task, connessioni di rete, event log di sicurezza, informazioni di sistema — e li rende disponibili come archivio scaricabile, con l’operazione tracciata nell’action center. Si sceglie quando serve un pacchetto forense riproducibile da consegnare a chi farà l’analisi offline.
Le altre response action convivono con l’indagine: sul device isolation (full o selective), restrict app execution, antivirus scan, avvio di un’automated investigation; sui file stop and quarantine, aggiunta di un indicator, deep analysis.
Trappole tipiche d’esame
- Raccogliere artefatti forensi standard senza sessione interattiva → collect investigation package: pacchetto predefinito e scaricabile; la live response qui è sovradimensionata e meno riproducibile.
- Eseguire uno script su un server compromesso → live response con l’impostazione per i server abilitata: attivare la sola live response non basta, i server hanno un toggle dedicato (e gli script non firmati un ulteriore toggle).
- L’analista isola i device ma non apre la sessione → mancano i permessi di active remediation actions: non è un problema di licenza né di onboarding; controlla anche basic vs advanced commands.
- Il device è già isolato e ora va indagato → la live response continua a funzionare: l’isolation blocca il traffico esterno ma preserva la connessione al servizio Defender for Endpoint.
- Cercare su tutta la flotta l’IOC trovato in timeline → advanced hunting, non la device timeline: la timeline è per singola macchina; e una hunting query non genera alert, per farlo serve una custom detection rule.
- Stabilire se un eseguibile sconosciuto è malevolo → deep analysis dalla entity page del file: collegarsi in live response per “guardare il file” non produce un verdetto.