{"id":3081,"date":"2025-09-19T16:55:37","date_gmt":"2025-09-19T14:55:37","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=3081"},"modified":"2025-09-19T16:55:37","modified_gmt":"2025-09-19T14:55:37","slug":"digital-forensics-nella-risposta-agli-incidenti-informatici","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/09\/19\/digital-forensics-nella-risposta-agli-incidenti-informatici\/","title":{"rendered":"Digital forensics nella risposta agli incidenti informatici"},"content":{"rendered":"\n

Introduzione<\/strong><\/p>\n\n\n\n

La digital forensics <\/strong>\u00e8 la disciplina che si occupa di individuare, preservare ed esaminare le evidenze digitali al fine di ricostruire eventi e azioni compiute su sistemi informatici. In particolare, nel contesto della risposta agli incidenti informatici<\/strong>, le tecniche forensi permettono di capire cosa \u00e8 accaduto durante un attacco, quali sistemi sono stati compromessi e in che modo, fornendo informazioni critiche per prevenire futuri incidenti. A livello internazionale esistono standard e linee guida che definiscono le migliori pratiche in questo campo: ad esempio lo standard ISO\/IEC 27042:2015 <\/em>fornisce \u201clinee guida per l\u2019analisi e l\u2019interpretazione delle evidenze digitali\u201d <\/em>mentre ISO\/IEC 27043:2015<\/em> definisce \u201cprincipi e processi di indagine sugli incidenti\u201d<\/em>. Analogamente, la guida NIST SP 800-86 <\/strong>del National Institute of Standards and Technology \u2013 intitolata \u201cGuide to Integrating Forensic Techniques into Incident Response\u201d <\/em>\u2013 descrive processi efficaci per svolgere analisi forensi su vari tipi di dati (file, sistemi operativi, traffico di rete, applicazioni) e integrare queste attivit\u00e0 nell\u2019ambito di un\u2019indagine di sicurezza . Questi riferimenti enfatizzano un approccio metodico e strutturato all\u2019analisi forense, essenziale affinch\u00e9 le evidenze raccolte abbiano validit\u00e0 e siano utili sia in ottica tecnica sia, se necessario, in sede legale.<\/p>\n\n\n\n

Analisi di file system<\/strong><\/p>\n\n\n\n

L\u2019analisi forense di un file system <\/strong>consiste nell\u2019esaminare la struttura e il contenuto di supporti di memoria (dischi fissi, SSD, pen drive, ecc.) al fine di scoprire tracce digitali significative. Ogni file e directory su un sistema operativo \u00e8 organizzato secondo un file system (come NTFS per Windows, EXT4 per Linux, APFS per macOS, ecc.), il quale mantiene metadati cruciali: nomi dei file, dimensioni, permessi e timestamp <\/em>(date di creazione, modifica, accesso, ecc.). L\u2019analista forense ispeziona queste informazioni per ricostruire le attivit\u00e0 svolte sul sistema e individuare anomalie. Ad esempio, nei file system NTFS <\/strong>di Windows il Master File Table <\/em>(MFT) registra record per ogni file, includendo fino a quattro timestamp principali per ciascuno (creazione, ultima modifica, ultimo accesso, ultima modifica del record MFT). Questi dati temporali consentono di costruire una timeline degli eventi sul disco. In un\u2019analisi tipica, si cercano file sospetti (ad esempio programmi malevoli camuffati), si esaminano gli attributi e i contenuti dei file e si analizzano gli artefatti del file system (come i journal di NTFS, la $Recycle.Bin, i punti di ripristino, ecc.) alla ricerca di evidenze. Inoltre, si verifica la presenza di file nascosti o di istanze di steganografia <\/strong>(informazioni occultate dentro file leciti) e si controlla l\u2019integrit\u00e0 dei file confrontandone gli hash <\/em>crittografici con valori noti.<\/p>\n\n\n\n

Un aspetto fondamentale del file system forensics \u00e8 il recupero di file cancellati. Molti utenti pensano che quando un file viene eliminato dal sistema scompaia definitivamente, ma in realt\u00e0 non \u00e8 cos\u00ec: l\u2019eliminazione rimuove il riferimento al file dalla tabella di allocazione (ad esempio la File Allocation Table su FAT o la MFT su NTFS) ma i dati binari del file restano sui settori del disco finch\u00e9 non vengono sovrascritti. I file (o frammenti di essi) permangono nelle aree non allocate del disco e, con gli strumenti appropriati, \u00e8 difficile ma non impossibile <\/em>ricostruirli. Ci\u00f2 significa che \u00e8 spesso possibile recuperare documenti o altri artefatti anche dopo la cancellazione, soprattutto su supporti di grande capacit\u00e0 dove pu\u00f2 trascorrere molto tempo prima che i blocchi vengano riutilizzati per nuovi dati.<\/p>\n\n\n\n

L\u2019analista forense utilizza tecniche di data carving <\/strong>(descritte pi\u00f9 avanti) per scandagliare queste porzioni libere alla ricerca di header <\/em>e footer <\/em>noti di file (come le intestazioni JPEG, PDF, ecc.) e ricostruire file eliminati o corrotti. Un altro approccio consiste nel calcolare gli hash <\/em>(MD5, SHA-1, SHA-256) di tutti i file presenti e confrontarli con database di indicatori di compromissione <\/em>(IOC) noti o con liste di hash di software benigni, cos\u00ec da individuare rapidamente malware noti o file anomali. In contesto italiano, ad esempio, il CERT-AgID <\/strong>(Computer Emergency Response Team dell\u2019Agenzia per l\u2019Italia Digitale) fornisce alle Pubbliche Amministrazioni un servizio di feed IoC <\/em>contenente hash di file malevoli osservati nelle campagne di attacco pi\u00f9 recenti. Questo feed, combinato con appositi tool, consente di identificare file compromessi nei sistemi oggetto di analisi. Hashr <\/strong>\u00e8 uno di questi strumenti sviluppati dal CERT-AgID: permette di cercare, all\u2019interno di un filesystem, file noti come malevoli confrontando i loro hash con una lista di impronte note. L\u2019uso di hashr <\/em>\u00e8 risultato particolarmente utile sia nelle indagini di sicurezza informatica sia nell\u2019analisi forense, ad esempio per verificare l\u2019integrit\u00e0 di grandi volumi di dati e scovare rapidamente malware presenti su disco.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figura 1: Schermata di output dello strumento hashr (open source di CERT-AGID) in azione. In questo esempio, l\u2019utility ha analizzato la directory <\/em>Downloads confrontando ogni file con una lista di hash indicanti malware noti, restituendo per ciascun file corrispondenze di hash MD5, SHA1 e SHA256. Tale strumento pu\u00f2 velocizzare<\/em> l\u2019identificazione di file infetti all\u2019interno di file system di grandi dimensioni, ed \u00e8 utilizzabile anche a fini di verifica dell\u2019integrit\u00e0 dei file.<\/em><\/p>\n\n\n\n

Dal punto di vista operativo, l\u2019analisi forense dei file system inizia con una corretta acquisizione <\/strong>della memoria di massa da esaminare. Si procede creando una copia forense bit-a-bit del supporto originale (disk image<\/em>), operazione effettuata tipicamente a sistema spento (analisi dead<\/em>) utilizzando tool come dd <\/em>(in ambienti Unix) o strumenti dedicati (ad es. FTK Imager<\/strong>, Guymager<\/strong>), spesso impiegando un write-blocker <\/strong>hardware o software per evitare qualsiasi modifica accidentale al disco originale. L\u2019immagine ottenuta viene poi sottoposta a hash (es. SHA-256) <\/strong>per calcolarne l\u2019impronta univoca, che servir\u00e0 a garantirne l\u2019integrit\u00e0: confrontando il valore hash della copia con quello calcolato sul disco originale, si verifica che la copia sia esatta e che nessuna alterazione sia avvenuta durante l\u2019acquisizione. Solo a questo punto gli investigatori lavorano sull\u2019immagine duplicata, lasciando intatto l\u2019originale (principio fondamentale per assicurare la validit\u00e0 probatoria delle evidenze). Una volta montata o caricata l\u2019immagine in appositi software, l\u2019analisi pu\u00f2 procedere: si passa in rassegna la struttura di directory, si cercano file sospetti (anche in base a nome, tipo o hash), si analizzano i contenuti con visualizzatori esadecimali o strumenti di parsing (per esempio analizzando il registro di configurazione di Windows, i file di Prefetch, i log di sistema, ecc.), e si ricostruiscono le attivit\u00e0 avvenute sul file system. Il risultato finale \u00e8 spesso una ricostruzione dettagliata (timeline<\/em>) delle azioni svolte su quel supporto (creazione, modifica, cancellazione di file, installazione di programmi, collegamenti di dispositivi USB, ecc.), utile per comprendere la dinamica di un incidente e attribuire eventuali responsabilit\u00e0.<\/p>\n\n\n\n

Analisi di dump di memoria (memory forensics)<\/strong><\/p>\n\n\n\n

L\u2019analisi forense della memoria RAM <\/strong>\u00e8 una componente sempre pi\u00f9 centrale nelle investigazioni digitali. La memory forensics <\/em>si occupa di studiare il contenuto della memoria volatile di un sistema (dump <\/em>RAM catturato da un computer o dispositivo) allo scopo di estrarre informazioni sulle attivit\u00e0 in corso o recenti, spesso impossibili da reperire altrove. Infatti qualsiasi operazione compiuta da un sistema informatico \u2013 processi eseguiti, connessioni di rete, utilizzo di credenziali, ecc. \u2013 transita attraverso la RAM e pu\u00f2 persistere in memoria per un certo tempo anche dopo la conclusione dell\u2019evento. La RAM di un computer pu\u00f2 contenere quindi una quantit\u00e0 enorme di dati utili: l\u2019elenco dei processi e thread <\/strong>in esecuzione (con i relativi programmi e moduli caricati), le connessioni di rete <\/strong>attive o recentemente chiuse (comprese informazioni su indirizzi IP e porte remote), le chiavi crittografiche <\/strong>in uso, password <\/strong>in chiaro temporaneamente presenti, il contenuto della clipboard (appunti) e persino tracce di malware in esecuzione <\/strong>\u2013 inclusi rootkit o altri codici malevoli che potrebbero occultarsi al file system. In altri termini, la memoria \u00e8 spesso il luogo migliore dove cercare le attivit\u00e0 di un software malevolo: anche se un malware tenta di nascondersi eliminando file dal disco o operando solo in memoria (fileless malware<\/em>), deve comunque essere caricato e mantenuto nella RAM per poter agire. Attraverso la memory forensics \u00e8 possibile mettere in luce evidenze altrimenti invisibili, come malware residenti unicamente in memoria, sessioni di navigazione web in modalit\u00e0 incognita (che non lasciano cronologia su disco) o conversazioni in chat volatile, e persino modifiche apportate a chiavi di registro di Windows che risiedono solo in memoria e non ancora scritte su disco.<\/p>\n\n\n\n

Le fasi di un\u2019analisi della memoria includono innanzitutto l\u2019acquisizione <\/strong>del dump: se il sistema \u00e8 live, si utilizzano tool appositi (ad es. Magnet RAM Capture<\/strong>, FTK Imager <\/strong>in modalit\u00e0 live, Belkasoft RAM Capturer <\/strong>o comandi di sistema) per estrarre un\u2019immagine completa della RAM e dei file di swap\/paging, evitando per quanto possibile di alterare lo stato della macchina. Una volta ottenuto il file di dump grezzo, si passa alla fase di estrazione delle evidenze<\/strong>: qui entrano in gioco framework specializzati come Volatility <\/strong>o Rekall<\/strong>. Volatility<\/em>, in particolare, \u00e8 un framework open source scritto in Python, dotato di una collezione di plug-in che permettono di estrarre artefatti dal dump di memoria volatile. Tramite Volatility, l\u2019analista pu\u00f2 elencare tutti i processi attivi al momento dell\u2019acquisizione (e quelli terminati di recente ma ancora residenti in memoria), ispezionare l\u2019area di memoria di ciascun processo alla ricerca di stringhe o moduli caricati, ricostruire la lista delle connessioni di rete aperte (socket TCP\/ UDP con relativi IP\/porta), recuperare informazioni sui driver e i kernel module caricati, estrarre il contenuto della clipboard, delle cache DNS e molto altro. Si possono anche cercare firme note di malware in memoria o rilevare tecniche di offuscamento, come process injection, hooking di funzioni di sistema, presenza di eseguibili packed<\/em>, ecc. Un esempio concreto: grazie all\u2019analisi RAM \u00e8 possibile recuperare credenziali o token di autenticazione temporanei che risiedono in memoria (ad esempio password di utenti o chiavi di sessione), elemento che talvolta consente di comprendere l\u2019entit\u00e0 di una compromissione o di effettuare escalation controllate in laboratorio per studiare un attacco. L\u2019analisi della memoria viene condotta preferibilmente off-line <\/em>sull\u2019immagine catturata, utilizzando i profili adeguati (profiling) per interpretare le strutture dati in base al sistema operativo target. Ad esempio, Volatility richiede di specificare il profilo (p.es. Windows 10 x64 build 19041) per poter tradurre correttamente indirizzi di memoria e simboli: un passaggio fondamentale, poich\u00e9 l\u2019uso di un profilo errato pu\u00f2 portare a output incompleti o incoerenti.<\/p>\n\n\n\n

Un aspetto importante \u00e8 la correlazione delle evidenze di memoria con altre fonti<\/strong>. Spesso, i risultati dell\u2019analisi RAM vanno messi in relazione con quanto emerge dall\u2019analisi del disco e dei log di rete, al fine di costruire un quadro unificato dell\u2019incidente. Ad esempio, processi sospetti individuati in RAM (come un powershell.exe <\/em>lanciato con comandi anomali, oppure un processo senza file su disco indicativo di un malware fileless) dovrebbero poi essere cercati nelle evidenze del file system (esiste un file corrispondente su disco? Ci sono riferimenti nel Prefetch o nel registro di sistema?) e nei log (ci sono eventi che mostrano l\u2019esecuzione di quel processo da parte di un certo utente?). Solo tramite questa visione d\u2019insieme si pu\u00f2 capire appieno l\u2019accaduto. Nel contesto italiano, l\u2019uso della memory forensics \u00e8 ormai prassi sia nelle operazioni di incident response: ad esempio, per malware analysis <\/em>su campioni attivi intercettati in sistemi compromessi o per identificare in tempo reale minacce come il malware Agent.Tesla <\/strong>o Ursnif <\/strong>che negli ultimi anni hanno preso di mira enti pubblici e privati. <\/p>\n\n\n\n

Analisi di log di sicurezza e di rete<\/strong><\/p>\n\n\n\n

I log <\/strong>\u2013 registri degli eventi prodotti da sistemi operativi, applicazioni e dispositivi di rete \u2013 costituiscono una fonte informativa primaria nella gestione e analisi degli incidenti informatici. Ogni componente IT (e anche molti dispositivi non-IT) genera infatti una notevole quantit\u00e0 di informazioni sotto forma di log, che vengono tipicamente classificati per categorie e livelli di severit\u00e0. Ad esempio, un server web produce log delle richieste HTTP con indicazione di timestamp, URL richiesto, indirizzo IP del client e codice di risposta; un firewall registra gli accessi consentiti o negati per ogni connessione (con dati su IP, porte, protocolli); un sistema operativo mantiene log di sicurezza (tentativi di login riusciti o falliti, cambi di privilegi, eventi del kernel) e cos\u00ec via. Analizzare questi log di sicurezza <\/strong>significa estrarre dai dati grezzi le informazioni rilevanti per un determinato incidente, identificare correlazioni tra eventi e riconoscere pattern anomali che possano indicare attivit\u00e0 malevole o malfunzionamenti.<\/p>\n\n\n\n

Un esempio concreto: in caso di sospetta intrusione su un server, l\u2019analisi incrociata dei log potrebbe rivelare che un certo utente ha effettuato un login fuori orario (voce nel security log<\/em>), subito seguito dall\u2019esecuzione di comandi insoliti registrati nella shell history <\/em>e da connessioni verso un IP esterno annotati nel log del firewall. Ciascun singolo evento, preso a s\u00e9, potrebbe passare inosservato; la correlazione temporale <\/strong>e funzionale tra i vari log permette invece di ricostruire la sequenza<\/strong> dell\u2019attacco <\/strong>(es. accesso iniziale \u2013 movimenti laterali \u2013 esfiltrazione di dati) e di identificarne la sorgente. Per un responsabile CSIRT\/SOC, saper orchestrare questa attivit\u00e0 di analisi log \u00e8 fondamentale: significa dover gestire potenzialmente decine di migliaia di eventi al secondo, filtrare i falsi positivi <\/em>e isolare gli indicatori critici. A tal fine, ci si avvale comunemente di sistemi SIEM (Security Information and Event Management)<\/strong>. Un SIEM \u00e8 una piattaforma software che colleziona i log <\/strong>da sorgenti disparate, li normalizza <\/strong>(cio\u00e8 li traduce in un formato comune), li correla <\/strong>in base a regole predefinite e spesso applica motori di analisi comportamentale per individuare minacce in tempo reale. In pratica, il SIEM funge da concentratore: al suo interno confluiscono log da firewall, IDS\/IPS, sistemi endpoint, database, applicazioni, ecc., e l\u2019analista pu\u00f2 consultare da un\u2019unica console l\u2019andamento degli eventi. Ad esempio, il SIEM pu\u00f2 generare un alert qualora rilevi, entro uno stesso intervallo temporale, pi\u00f9 tentativi di accesso falliti su diversi sistemi seguiti da un accesso riuscito con un account amministrativo: segnale tipico di un possibile brute forcing <\/strong>andato a segno. Oppure pu\u00f2 correlare l\u2019apparizione di un file sospetto in un host (rilevato dall\u2019antivirus) con una connessione uscente su porta non standard (dal log del proxy): anche qui producendo un avviso di possibile data exfiltration<\/em>. I moderni SIEM integrano inoltre feed di threat intelligence <\/em>(indicatori di minaccia esterni forniti da CERT e vendor) e funzionalit\u00e0 di orchestrazione automatica (SOAR), cos\u00ec da arricchire gli eventi grezzi con informazioni contestuali e, in alcuni casi, reagire automaticamente (per esempio isolando un host infetto).<\/p>\n\n\n\n

Nell\u2019analisi forense vera e propria, i log rivestono anche un ruolo chiave come evidenze<\/strong>: costituiscono spesso prova documentale di un\u2019azione (si pensi ai log di autenticazione nel caso di accessi non autorizzati, o ai log di transazione di un database in caso di frodi). \u00c8 importante perci\u00f2 assicurarne la corretta conservazione e autenticit\u00e0: un responsabile deve garantire che i log siano archiviati in forma write-once <\/em>(immutabile) e con riferimenti temporali affidabili (sincronizzazione oraria via NTP, uso di timestamp in UTC, ecc.), in modo che possano essere esibiti come prova qualora necessario. Un aspetto non banale \u00e8 la gestione dei tempi e della sincronizzazione<\/strong>: se i sistemi coinvolti in un incidente non hanno orologi allineati, la ricostruzione temporale pu\u00f2 risultare complicata. Idealmente tutti i server e dispositivi devono sincronizzare l\u2019ora con un time server <\/em>preciso (via protocollo NTP); in pratica pu\u00f2 capitare di trovare orologi sfasati. In fase di analisi forense occorre pertanto tener conto di eventuali offset temporali tra log diversi, effettuando opportune conversioni per costruire una timeline coerente degli eventi\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 . Questo evidenzia ulteriormente l\u2019importanza di un approccio sistematico e metodico nell\u2019analisi dei log.<\/p>\n\n\n\n

In Italia, il CERT-AgID e l\u2019ACN\/CSIRT Italia <\/strong>incoraggiano fortemente l\u2019adozione di sistemi di logging centralizzato e di SIEM negli enti pubblici, fornendo anche indicazioni su come configurare al meglio il monitoraggio. Ad esempio, ACN ha pubblicato nel 2022 la Guida alla notifica degli incidenti al CSIRT Italia<\/em>, che tra le varie cose elenca i tipi di log ed evidenze che gli enti devono raccogliere e conservare per facilitare le investigazioni post-incidente\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 . Vi sono stati anche casi concreti in cui l\u2019analisi dei log ha permesso di scoprire attacchi sofisticati: ad esempio, l\u2019indagine su una serie di attacchi alle caselle PEC (Posta Elettronica Certificata) nel 2023 \u2013 coordinata da CERT-AgID in collaborazione con la Polizia Postale \u2013 ha visto come elemento chiave l\u2019esame dei log di accesso ai server di posta e delle tracce lasciate dai malware nei log antivirus, consentendo di individuare i punti di ingresso dei criminali e di rafforzare le difese delle infrastrutture coinvolte.<\/p>\n\n\n\n

Analisi del traffico di rete<\/strong><\/p>\n\n\n\n

L\u2019analisi forense della rete <\/strong>(Network Forensics) riguarda la cattura, l\u2019ispezione e l\u2019interpretazione del traffico di rete con l\u2019obiettivo di ottenere prove digitali relative a eventuali attacchi o attivit\u00e0 malevole che si sono svolte attraverso i sistemi di comunicazione. In sostanza, mentre l\u2019analisi dei log spesso si basa su dati gi\u00e0 registrati dai sistemi, l\u2019analisi del traffico va direttamente alla fonte: i pacchetti di rete <\/strong>scambiati tra sorgenti e destinazioni. Questa disciplina permette di determinare, ad esempio, l\u2019origine di un attacco, le modalit\u00e0 di comunicazione di un malware con i server di comando e controllo (C2), o l\u2019eventuale esfiltrazione di dati sensibili tramite canali nascosti. L\u2019investigatore di rete inizia tipicamente con l\u2019acquisizione <\/strong>del traffico: pu\u00f2 trattarsi di file di cattura (.pcap<\/em>) ottenuti mettendo in ascolto una scheda di rete in modalit\u00e0 promiscua (con strumenti di packet capture <\/em>come tcpdump <\/strong>o Wireshark<\/strong>), oppure di flussi di log generati da sonde IDS\/IPS, NetFlow, ecc. Spesso, durante un incidente, il team forense configura dei packet sniffer <\/strong>nei punti chiave (ad esempio sulla porta di uno switch core, o attivando port mirroring) per raccogliere tutto il traffico in transito da e verso i sistemi compromessi. I dati cos\u00ec acquisiti \u2013 idealmente corredati di timestamp precisi e sincronizzati \u2013 vengono poi analizzati nel dettaglio.<\/p>\n\n\n\n

Nell\u2019analisi del traffico di rete, alcuni elementi chiave da esaminare includono: i protocolli <\/strong>utilizzati in comunicazione (HTTP, HTTPS, DNS, SMTP, etc.), gli indirizzi IP <\/strong>sorgente e destinazione, i numeri di porta <\/strong>coinvolti, i timestamp <\/strong>delle connessioni, nonch\u00e9 il contenuto dei pacchetti stessi (payload) se in chiaro. Ad esempio, in un file PCAP catturato durante un attacco potremmo filtrare tutto il traffico HTTP non cifrato e ritrovare richieste sospette verso URL esterni, oppure osservare in un dump DNS delle richieste a domini anomali (indizi di malware che cerca il suo dominio di controllo). Strumenti come Wireshark <\/strong>forniscono potenti capacit\u00e0 di filtraggio e decodifica per ispezionare i pacchetti: l\u2019analista pu\u00f2 ricomporre flussi TCP, estrarre file trasferiti (ad esempio file scaricati via HTTP o FTP) e seguire la sequenza delle chiamate di rete. Esistono anche strumenti specializzati detti Network Forensic Analysis Tool (NFAT) <\/strong>\u2013 un esempio open source \u00e8 Xplico <\/strong>\u2013 il cui scopo principale \u00e8 estrarre e ricostruire automaticamente tutti i dati applicativi significativi da un\u2019acquisizione di rete. Xplico, ad esempio, \u00e8 in grado di ricavare da un file pcap tutto il contenuto delle email transitanti (protocolli SMTP\/ POP\/IMAP), le pagine web e i file scambiati via HTTP, le conversazioni VOIP (protocollo SIP\/RTP) convertendole in registrazioni audio, e cos\u00ec via 23 24 . Ci\u00f2 risulta estremamente utile per presentare le evidenze in forma comprensibile: piuttosto che sfogliare migliaia di pacchetti, l\u2019analista pu\u00f2 ottenere direttamente i messaggi e-mail inviati dall\u2019attaccante o i file trafugati.<\/p>\n\n\n\n

Un aspetto critico nell\u2019analisi di rete \u00e8 la presenza della crittografia<\/strong>. Oggi molto traffico (in primis HTTP tramite TLS, ma anche email con SMTPS\/IMAPS, VPN cifrate, ecc.) \u00e8 cifrato end-to-end, il che impedisce di leggere il contenuto dei pacchetti a meno di poter disporre delle chiavi private per decriptarlo. Questo ovviamente complica l\u2019analisi forense: se l\u2019attaccante ha usato solo canali cifrati, si dovr\u00e0 fare affidamento su metadati (IP, porte, quantit\u00e0 di dati) e su eventuali side-channel <\/em>(come l\u2019individuazione del tipo di protocollo o l\u2019osservazione di certificate exchange noti) per dedurre cosa sia successo. In ambienti aziendali, per mitigare il problema, talvolta si utilizzano sistemi di SSL\/TLS inspection <\/em>(proxy che terminano e re-instaurano le connessioni cifrate, consentendo l\u2019ispezione del contenuto da parte del SOC) \u2013 ma ci\u00f2 deve essere bilanciato con esigenze di privacy e normative. Nonostante la crittografia, alcuni indicatori di compromissione di rete possono comunque emergere: ad esempio, pattern di traffico anomalo (un host interno che fa centinaia di connessioni verso l\u2019esterno di notte), oppure l\u2019uso di protocolli o porte inusuali per la rete aziendale.<\/p>\n\n\n\n

Un compito importante del forense di rete \u00e8 anche quello di tracciare la sorgente di un attacco<\/strong>. I malintenzionati spesso utilizzano machine zombi <\/em>o server proxy per celare la propria identit\u00e0, rendendo arduo risalire all\u2019IP originario dell\u2019attaccante. Attraverso l\u2019analisi incrociata dei log di diversi dispositivi (router, firewall di frontiera, server di autenticazione RADIUS\/TACACS), si pu\u00f2 tuttavia riuscire a seguire il percorso di un attacco e identificare l\u2019ingresso iniziale. Ad esempio, se un attaccante ha sfruttato una VPN compromessa, i log VPN daranno l\u2019IP pubblico utilizzato; correlando questo con log di altri provider o con segnalazioni di CERT internazionali, si pu\u00f2 scoprire se quell\u2019IP corrisponde a una nota botnet<\/em>. Questo tipo di investigazione sfrutta sia le competenze tecniche che le cooperazioni inter-agenzia: CERT e forze di polizia spesso collaborano scambiandosi informazioni sugli indirizzi IP e le infrastrutture di attacco note.<\/p>\n\n\n\n

A tal proposito, \u00e8 utile menzionare alcuni casi concreti italiani<\/strong>. Le forze dell\u2019ordine, in particolare la Polizia Postale, hanno sviluppato notevoli capacit\u00e0 di network forensics. Un esempio \u00e8 l\u2019uso proprio di Xplico citato in contesti operativi: in una presentazione del progetto DEFT Linux <\/strong>(una distribuzione forense live creata in Italia), Stefano Fratepietro mostr\u00f2 come la Polizia, dopo aver catturato il traffico di rete relativo a un\u2019attivit\u00e0 illecita, utilizzi Xplico per analizzarlo e ricavare le prove applicative. Questo ha permesso in vari casi di \u201cleggere\u201d comunicazioni tra criminali che avvenivano su canali non cifrati e di raccogliere elementi probatori (e-mail, credenziali, conversazioni VoIP) direttamente dal traffico di rete salvato. Un altro caso noto \u00e8 l\u2019investigazione sulle botnet Mirai <\/strong>e varianti IoT in Italia: grazie al monitoraggio del traffico anomalo in uscita da dispositivi compromessi (camere IP, router), il CERT-AgID in coordinamento con l\u2019ACN \u00e8 riuscito a mappare le connessioni verso i server di comando esteri e a condividere con gli ISP le informazioni per la mitigazione, mostrando l\u2019efficacia dell\u2019analisi di rete su larga scala per la difesa nazionale. In sintesi, la network forensics fornisce al responsabile CSIRT uno sguardo \u201csul filo\u201d delle comunicazioni, rivelando come <\/em>e cosa <\/em>\u00e8 stato trasferito durante un attacco \u2013 informazioni imprescindibili per capire l\u2019impatto dell\u2019incidente (ad es. quali dati sono stati rubati) e per bloccare canali di attacco ancora attivi.<\/p>\n\n\n\n

Analisi di memorie di massa<\/strong><\/p>\n\n\n\n

Con memorie di massa <\/strong>si intendono tutti i dispositivi di archiviazione persistente dei dati, come hard disk, SSD, chiavette USB, schede di memoria, e in senso lato anche i dischi virtuali di macchine virtuali o istanze cloud. L\u2019analisi forense di queste memorie \u2013 strettamente collegata a quella dei file system \u2013 si focalizza sull\u2019esame dell\u2019intero supporto fisico <\/strong>o logico e non solo della struttura di files e cartelle. Ci\u00f2 include aspetti come: l\u2019identificazione di tutte le partizioni presenti (anche quelle nascoste o non standard), l\u2019esame dei settori di boot (MBR o GPT) per individuare bootkit o alterazioni, la ricerca di volume shadow copies <\/em>o backup nascosti, e in generale l\u2019analisi di ogni area del disco, compresi lo spazio non allocato e lo slack space <\/em>(lo spazio inutilizzato alla fine dei cluster allocati).<\/p>\n\n\n\n

Operativamente, anche qui si parte dall\u2019acquisizione forense <\/strong>del supporto di memoria, creando un\u2019immagine bitstream come discusso in precedenza. Nel caso di dischi di grandi dimensioni, questa operazione pu\u00f2 richiedere molto tempo e devono essere adottate opportune precauzioni (condizioni ambientali adeguate, UPS per evitare interruzioni di corrente, etc.). Una volta ottenuta l\u2019immagine, l\u2019investigatore pu\u00f2 utilizzare software di analisi come EnCase<\/strong>, FTK <\/strong>o tool open source (ad es. The Sleuth Kit <\/em>con interfaccia Autopsy<\/em>) per caricarla. Questi strumenti permettono di navigare tra le partizioni individuate, montarle in sola lettura e analizzarne il contenuto. Un controllo importante \u00e8 quello della consistenza tra il livello logico e fisico<\/strong>: per esempio, se la tabella delle partizioni indica che un certo spazio del disco non \u00e8 allocato a nessuna partizione, potrebbe essere normale (spazio vuoto inutilizzato) oppure potrebbe celare una partizione nascosta contenente dati (talvolta i criminali usano partizioni con identificatori anomali o volutamente corrotte per nascondere informazioni). L\u2019analista utilizza quindi tecniche di carving <\/em>e scanning anche sull\u2019intera immagine fisica per vedere se firme di file noti compaiono in zone altrimenti \u201cmute\u201d del disco.<\/p>\n\n\n\n

Un altro scenario da affrontare \u00e8 quello dei RAID o volumi cifrati<\/strong>. Nelle grandi infrastrutture, spesso i dischi sono in configurazione RAID: il forense dovr\u00e0 poter ricostruire il volume logico aggregando le immagini dei singoli dischi (rispettando ordine e parametri RAID) per accedere ai dati. Se il volume \u00e8 cifrato (es. tramite BitLocker, LUKS, VeraCrypt), serviranno le chiavi di decrittazione o tecniche specifiche (es. estrarre la master key <\/em>dalla RAM acquisita, in caso di sistema acceso) per poter proseguire. Anche dispositivi come smartphone e tablet rientrano nelle \u201cmemorie di massa\u201d in senso lato: qui le metodologie divergono (uso di strumenti come Cellebrite UFED <\/strong>o Magnet AXIOM <\/strong>per estrarre una immagine logica o fisica del telefono, sblocco tramite exploit, ecc.), ma per brevit\u00e0 ci focalizziamo sui sistemi tradizionali.<\/p>\n\n\n\n

Durante l\u2019analisi delle memorie di massa \u00e8 importante mantenere la documentazione <\/strong>di ogni passo: ad esempio annotare i codici identificativi del supporto, i calcoli hash effettuati, l\u2019orario di inizio e fine delle copie, le persone intervenute. Questo perch\u00e9, trattandosi spesso di evidence da presentare eventualmente in tribunale, la catena di custodia <\/strong>deve essere chiara e ininterrotta: ogni spostamento o copia dell\u2019evidenza dev\u2019essere tracciato, e l\u2019integrit\u00e0 deve essere costantemente verificata con hash. Gli standard internazionali (come ISO\/IEC 27041 <\/em>e la stessa 27042<\/em>) sottolineano l\u2019importanza di garantire l\u2019idoneit\u00e0 e l\u2019adeguatezza del metodo investigativo e la validit\u00e0 delle prove raccolte. In Italia, anche le linee guida del Consiglio d\u2019Europa e del Framework Nazionale di Cybersecurity <\/em>richiamano questi principi, e le forze dell\u2019ordine (come i reparti di informatica forense dei Carabinieri e della Polizia) hanno protocolli rigorosi per l\u2019acquisizione e la conservazione delle memorie digitali sequestrate.<\/p>\n\n\n\n

In sintesi, l\u2019analisi delle memorie di massa copre un ventaglio molto ampio di attivit\u00e0: dalla copia forense alla ricerca di dati nascosti, dall\u2019individuazione di partizioni occulte al recupero di file cancellati, fino all\u2019estrazione di informazioni residuali (ad es. nel pagefile <\/em>o hibernation file di Windows potrebbero trovarsi frammenti di documenti o credenziali che vale la pena esaminare). Tutto questo richiede competenze tecniche approfondite sul funzionamento dei dispositivi di storage e dei file system, nonch\u00e9 padronanza degli strumenti software dedicati.<\/p>\n\n\n\n

Data carving e recupero dei dati<\/strong><\/p>\n\n\n\n

Il data carving <\/strong>(o file carving) \u00e8 una tecnica forense avanzata utilizzata per recuperare file o frammenti di dati direttamente dal contenuto grezzo di un supporto, senza fare affidamento sulle strutture logiche del file system. Si ricorre al carving soprattutto quando i metadati del file system \u2013 che normalmente indicano posizione e dimensione dei file \u2013 non sono pi\u00f9 disponibili o affidabili: ad esempio, per file cancellati (le cui entry sono state rimosse dalla MFT\/FAT) o in casi di file system corrotti\/formattati dove la struttura directory \u00e8 andata persa. Il principio base del carving \u00e8 che molti tipi di file hanno una firma riconoscibile: delle sequenze specifiche di byte all\u2019inizio (header) \u00a0e talvolta alla fine \u00a0(footer) del file. Ad esempio, i file JPEG iniziano tipicamente con i byte FF D8 FF E0<\/code> (o FF D8 FF E1<\/code> ), i file PDF iniziano con %PDF<\/code>– , i file ZIP con PK\\x03\\x04<\/code> e cos\u00ec via. Un programma di carving scansiona l\u2019immagine binaria del disco o della memoria alla ricerca di queste firme; quando ne trova una, cerca di estrapolare tutti i byte consecutivi fino al termine plausibile del file (spesso identificato da un footer noto, oppure da un cambio di contesto). Il risultato \u00e8 l\u2019estrazione <\/strong>di segmenti di dati che verosimilmente rappresentano file completi o parziali. <\/p>\n\n\n\n

Ad esempio, se in uno spazio non allocato di un disco troviamo la firma di inizio di un documento Word (byte D0 CF 11 E0<\/code> per i vecchi .doc in formato OLE, o l\u2019indicazione PK<\/code> per i .docx che sono ZIP), il software tenter\u00e0 di ricostruire il file Word recuperando tutti i settori successivi fino a quando i dati non hanno pi\u00f9 senso compiuto o incontrano un\u2019altra firma. Il carving pu\u00f2 recuperare file interi se i cluster non sono stati ancora riutilizzati, ma pu\u00f2 anche produrre file parziali <\/strong>o corrotti se parti di essi sono state sovrascritte. Tuttavia, anche frammenti di file possono contenere informazioni utili (ad esempio, un pezzo di testo in un documento, o i frame di un video). Questa tecnica \u00e8 quindi fondamentale quando si analizzano supporti dove l\u2019attaccante ha cercato di ripulire le tracce <\/em>cancellando file o formattando volumi: spesso, i dati restanti sul disco raccontano ancora la storia. Va notato che il carving non garantisce che i file recuperati siano esattamente nella loro originaria integrit\u00e0; \u00e8 necessario validare poi tali file (ad esempio aprendo i documenti recuperati o verificandone gli hash se disponibili).<\/p>\n\n\n\n

Esistono diversi strumenti per il data carving: tra gli open source noti vi sono Foremost <\/strong>e Scalpel<\/strong>, nonch\u00e9 PhotoRec <\/strong>(specializzato nel recupero di foto e multimedia). Suite forensi complete come Autopsy\/TSK integrano anch\u2019esse funzioni di carving. In ambito NIST, sono stati definiti anche test specifici per valutare l\u2019efficacia dei carving tool (il progetto CFReDS<\/strong>). Il responsabile forense deve conoscere i limiti di questa tecnica: ad esempio, file frammentati (non contigui sul disco) sono difficili da ricostruire completamente via carving, perch\u00e9 tra un frammento e l\u2019altro potrebbero esserci altri dati \u2013 alcuni strumenti avanzati tentano di riconoscere frammenti appartenenti allo stesso file sulla base di pattern, ma non \u00e8 semplice. Inoltre il carving produce spesso falsi positivi <\/strong>(bytes casuali che assomigliano a una firma) \u2013 l\u2019analista dovr\u00e0 quindi verificare manualmente i risultati, soprattutto se l\u2019evidenza estratta \u00e8 critica.<\/p>\n\n\n\n

In definitiva, il data carving aggiunge un tassello importante all\u2019analisi forense, consentendo di scavare <\/em>a livello di byte nel supporto alla ricerca di qualunque traccia residua. \u00c8 un processo che pu\u00f2 essere lungo e intensivo computazionalmente, ma che in indagini complesse ha portato a ritrovare, ad esempio, frammenti di email scambiate, immagini di reati, documenti eliminati poco prima di un sequestro, etc., rivelandosi spesso la chiave per incastrare i responsabili.<\/p>\n\n\n\n

Timeline forense e analisi temporale<\/strong><\/p>\n\n\n\n

Il concetto di timeline <\/strong>in ambito forense si riferisce alla costruzione di una sequenza cronologica di eventi digitali che consenta di ricostruire in modo chiaro chi ha fatto cosa e quando <\/em>su un sistema. La timeline forense \u00e8 una delle tecniche pi\u00f9 potenti a disposizione degli analisti, perch\u00e9 permette di collegare tra loro le diverse evidenze secondo l\u2019asse temporale, fornendo una visione d\u2019insieme dell\u2019incidente. Come afferma un principio ben noto: \u201cla timeline analysis consente di ricostruire gli eventi, individuare con precisione gli incidenti di sicurezza e comprendere il comportamento di un attaccante\u201d <\/em>. In pratica, creare una timeline significa prendere tutti i timestamp rilevanti \u2013 orari di modifica dei file, registrazioni di log, orari di esecuzione dei processi, etc. \u2013 e ordinarli, correlando poi ciascun evento con gli altri.<\/p>\n\n\n\n

Per esempio, una timeline relativa a un attacco informatico complesso potrebbe mettere in fila: l\u2019ora in cui un malware \u00e8 stato eseguito (desunta dall\u2019orario di creazione di un processo in memoria), subito seguita dall\u2019ora in cui un nuovo file sospetto \u00e8 comparso sul disco (timestamp di creazione del file), poi alcuni minuti dopo la connessione a un server esterno (da un log di rete), poi ancora la modifica di varie chiavi di registro (con orari registrati nel registro eventi), e infine magari l\u2019esecuzione di un comando di cancellazione dati poco prima di un riavvio (log di shell). Vista in timeline, questa serie di azioni delinea chiaramente il modus operandi e l\u2019impatto temporale dell\u2019incidente, cosa che sarebbe difficile da cogliere esaminando isolatamente le singole fonti.<\/p>\n\n\n\n

La costruzione di timeline forensi pu\u00f2 essere fatta manualmente, esportando i dati temporali da varie fonti e inserendoli in un foglio cronologico, ma data l\u2019enorme mole di informazioni spesso conviene usare strumenti specializzati. Uno dei pi\u00f9 noti \u00e8 Plaso (log2timeline)<\/strong>, un framework open source che automaticamente estrae timestamp da un\u2019ampia variet\u00e0 di file di log e artefatti (file system, registro di Windows, cronologie browser, eventi di sistema) e crea una super timeline <\/em>aggregata. Con Plaso, si pu\u00f2 ad esempio prendere un intero disco e far generare tutti gli eventi temporali possibili in formato testuale o CSV, per poi analizzarli magari con un\u2019interfaccia come Timesketch <\/strong>(piattaforma web per visualizzare e filtrare timeline). Ci\u00f2 consente di effettuare ricerche veloci (es. \u201cmostra eventi tra le 14:00 e le 15:00 del 12\/05\/2025\u201d o \u201ctrova qualsiasi modifica di file .exe nella settimana precedente l\u2019incidente\u201d) e di applicare filtri per tipologia di evento.<\/p>\n\n\n\n

Un concetto importante nella timeline analysis \u00e8 quello dei pivot point<\/strong>: in un dataset cronologico enorme, si parte di solito da un evento chiave (ad esempio l\u2019ora in cui \u00e8 stato rilevato l\u2019incidente, o l\u2019orario di un alert antivirus) e si analizzano tutti gli eventi immediatamente precedenti e successivi a quello, allargando via via la finestra temporale. Questo aiuta a focalizzarsi sul periodo critico. Inoltre si distingue tra timeline completa <\/em>(super timeline) e timeline mirata<\/em>: la prima include tutto il possibile ed \u00e8 utile per non perdere dettagli, ma pu\u00f2 essere ridondante; la seconda invece si concentra su eventi di un certo tipo o su certe fonti (ad esempio solo la timeline dei file di un particolare directory, o solo gli eventi di login) rendendo pi\u00f9 agevole l\u2019analisi. In pratica l\u2019analista forense spesso crea prima timeline parziali (ad esempio timeline del file system, timeline dei log di sicurezza) e poi le fonde assieme per l\u2019analisi finale.<\/p>\n\n\n\n

La timeline forense <\/em>non \u00e8 solo uno strumento tecnico, ma diventa spesso una parte integrante del report <\/strong>conclusivo di un\u2019investigazione. Molti incident report contengono una sezione chiamata \u201cTimeline of Events\u201d in cui vengono elencati in ordine cronologico tutti gli eventi salienti scoperti, con data\/ora, descrizione e fonte. Ci\u00f2 fornisce ai decisori (manager, o eventualmente giudici in tribunale) una narrazione chiara di cosa \u00e8 avvenuto. Per esempio: \u201c08:42:15 <\/strong>\u2013 L\u2019utente admin <\/em>effettua login da remoto sull\u2019host SERVER1<\/em>; 08:45:10 <\/strong>\u2013 Viene creato il file malware.exe <\/em>nella cartella C:\\Windows\\Temp<\/em>; 08:45:15 <\/strong>\u2013 Il servizio antivirus genera un allarme (file infetto rilevato); 08:45:30 <\/strong>\u2013 Connessione di rete dall\u2019host SERVER1 <\/em>verso l\u2019IP esterno 123.123.123.123 sulla porta 443 (presumibilmente HTTPS); 08:47:00 <\/strong>\u2013 Cancellazione di massa di file nella cartella DatiCondivisi<\/em>…\u201d, e cos\u00ec via. Una presentazione del genere consente di capire immediatamente la successione e l\u2019impatto degli eventi.<\/p>\n\n\n\n

Bisogna considerare, come accennato, eventuali problemi di sincronizzazione oraria<\/strong>: la timeline finale potrebbe includere eventi registrati da macchine con orologi non allineati, quindi l\u2019analista deve normalizzare i tempi (ad esempio convertire tutti in UTC o applicare offset noti). Inoltre, la precisione dei timestamp pu\u00f2 variare: alcuni log registrano l\u2019ora al millisecondo, altri solo al secondo o al minuto. Quando si comparano eventi, queste differenze vanno tenute presenti (un evento con timestamp 10:00:00 e uno 10:00:30 potrebbero in realt\u00e0 essere simultanei se il primo log \u00e8 approssimato al minuto). Gli strumenti automatici spesso aiutano evidenziando potenziali correlazioni nonostante tali discrepanze.<\/p>\n\n\n\n

In conclusione, il concetto di timeline rappresenta la spina dorsale dell\u2019analisi forense<\/strong>: mette ordine nel caos di dati prodotti da un incidente e racconta la storia in modo lineare. Un responsabile CSIRT\/ SOC deve saper sia costruire manualmente timeline (in contesti magari con pochi dati o in tempo reale) sia utilizzare tool avanzati per timeline complesse, cos\u00ec da poter spiegare efficacemente l\u2019accaduto ai vari stakeholder e prendere decisioni informate sulle misure di contrasto e prevenzione da adottare.<\/p>\n\n\n\n

Fondamenti di analisi dei malware<\/strong><\/p>\n\n\n\n

La malware analysis <\/strong>\u00e8 il processo di esaminare un codice malevolo (malware) per capirne il funzionamento, l\u2019origine, gli obiettivi e gli indicatori di compromissione, in modo da poter mitigare l\u2019attacco e prevenire future infezioni. Nell\u2019ambito della risposta agli incidenti, saper analizzare un malware trovato in un sistema compromesso \u00e8 fondamentale: consente di determinare quali azioni ha compiuto (es. furto di dati, installazione di backdoor, cifratura ransomware), quali componenti ha installato e come rilevarlo\/neutralizzarlo efficacemente. Si distinguono due approcci principali: analisi statica <\/strong>e analisi dinamica<\/strong>.<\/p>\n\n\n\n

    \n
  • Analisi statica: <\/strong>consiste nell\u2019esaminare il malware senza eseguirlo<\/strong>, studiandone il file binario e il codice. Include tecniche come: il calcolo di hash e confronto con database di minacce noti (per vedere se il malware \u00e8 gi\u00e0 catalogato), l\u2019estrazione di stringhe <\/em>testuali presenti nel file (che spesso rivelano indizi su funzionalit\u00e0, URL o messaggi interni), l\u2019uso di antivirus e strumenti di scanning per rilevare firme o packer usati, l\u2019analisi del PE header nel caso di eseguibili Windows (per capire compilatore, librerie importate, ecc.), e soprattutto il reverse engineering <\/strong>tramite disassembler e decompiler (come IDA Pro<\/strong>, Ghidra <\/strong>o radare2<\/strong>). Con il debugging statico si pu\u00f2 leggere il codice assembly del malware per individuare, ad esempio, routine di rete (API chiamate per fare connessioni), routine di cifratura, oppure condizioni di attivazione (date\/time bomb). L\u2019analisi statica \u00e8 svolta in isolamento, dunque \u00e8 sicura <\/em>(il codice non viene attivato sul serio), ma pu\u00f2 essere molto complessa se il malware \u00e8 offuscato o protetto da anti-disassembling. Ad ogni modo, utilizzando debugger e altri strumenti, l\u2019analista pu\u00f2 ottenere molte informazioni sulle operazioni svolte dal programma dannoso e identificare eventuali punti deboli del malware stesso (ad esempio errori di implementazione che permettono di creare un decryptor per ransomware).<\/li>\n\n\n\n
  • Analisi dinamica: <\/strong>complementare alla precedente, consiste nell\u2019osservare il malware in esecuzione <\/strong>all\u2019interno di un ambiente controllato e isolato (solitamente una sandbox o macchina virtuale di test). Si lancia il malware e si monitora il suo comportamento: quali processi crea, che file legge o scrive, quali chiavi di registro modifica, che traffico di rete genera, ecc… Per far ci\u00f2 ci si avvale di strumenti come sandbox automatizzate (es. Cuckoo Sandbox<\/strong>, VMRay<\/strong>, Joe Sandbox<\/strong>) o monitor manuali (come Process Monitor<\/em>, Regshot<\/em>, sniffer di rete e simili) in una VM. L\u2019analisi dinamica permette di vedere concretamente <\/em>l\u2019effetto del malware, ad esempio scoprendo l\u2019URL di callback verso cui prova a connettersi, o vedendo che crea una copia di s\u00e9 in una certa directory e stabilisce persistenza impostando una chiave di registro di run<\/em>. Questo metodo pu\u00f2 in alcuni casi essere pi\u00f9 rapido nel fornire indicazioni (rispetto a dover leggere migliaia di righe di assembly), ma ha alcuni limiti: malware sofisticati possono rilevare l\u2019ambiente virtuale\/sandbox e cambiare comportamento (o non attivarsi proprio) in presenza di indicatori di analisi. Inoltre, se il malware \u00e8 configurato per attivarsi solo in determinate condizioni (es. in un particolare giorno, o solo se rileva una certa configurazione di sistema), l\u2019analista deve capire e soddisfare tali condizioni, altrimenti l\u2019osservazione potrebbe non rivelare nulla di utile.<\/li>\n<\/ul>\n\n\n\n

    In una strategia completa di malware analysis, statica e dinamica <\/strong>si combinano: ad esempio, l\u2019analisi statica preliminare pu\u00f2 fornire IOC (hash, nomi di dominio, stringhe sospette) e indicazioni su come attivare il malware, mentre l\u2019analisi dinamica conferma il comportamento e produce tracce di esecuzione <\/em>(log delle azioni compiute). Oltre a questi approcci, esistono anche l\u2019analisi automatizzata <\/strong>(utilizzo di motori AV e piattaforme cloud che gi\u00e0 identificano la famiglia di malware e danno un report preconfezionato) e l\u2019analisi della memoria <\/strong>specifica del malware (analizzare un dump di memoria del sistema infetto per estrarre parti di malware in esecuzione, utile per malware fileless o moduli iniettati).<\/p>\n\n\n\n

    Il fine ultimo dell\u2019analisi malware \u00e8 duplice: difensivo e conoscitivo<\/strong>. Dal lato difensivo, capire il funzionamento del malware consente di sviluppare contromisure mirate: ad esempio, scrivere firme per IDS\/antivirus (basate su byte sequence uniche del malware), creare regole Yara per individuare varianti simili, implementare filtri su firewall\/proxy per bloccare i domini di C&C emersi, o rafforzare le configurazioni di sistema contro le tecniche specifiche usate dal malware (es: se il malware sfrutta WMI<\/em> per persistere, inserire controlli su WMI). Un\u2019analisi approfondita \u201cfornisce una comprensione del<\/em> funzionamento delle minacce, consentendo alle organizzazioni di creare rilevamenti mirati invece di affidarsi<\/em> a firme generiche\u201d<\/em>; in pratica, conoscere bene il malware permette di scoprirlo anche quando muta (perch\u00e9 si sa cosa tende a fare) e di reagire pi\u00f9 velocemente. Inoltre gli analisti, esaminando gli Indicatori di Compromissione (IOC) <\/strong>del malware (indirizzi IP, hash di file, chiavi di registro modificate, ecc.), possono aggiornare i sistemi di monitoraggio: per esempio, inserendo nel SIEM gli hash in watchlist <\/em>o caricando gli IP malevoli nei feed di blocco. Ci\u00f2 aiuta anche a rilevare eventuali nuove infezioni da varianti analoghe (se altri host iniziano a contattare lo stesso C&C, potrebbe voler dire che il malware ha colpito anche l\u00ec). Dal lato conoscitivo<\/strong>, la malware analysis contribuisce a rintracciare le tattiche, tecniche e procedure (TTP) <\/strong>degli attaccanti e spesso a collegare un malware a una certa famiglia o gruppo (threat actor). Ad esempio, analizzando un ransomware si pu\u00f2 scoprire che utilizza lo stesso algoritmo di cifratura e schema di riscatto di un gruppo noto, attribuendo cos\u00ec l\u2019attacco e potenzialmente condividendo intel con le autorit\u00e0. In alcuni casi, l\u2019analisi porta anche a individuare eventuali zero-day exploit <\/em>sfruttati dal malware: \u201caiutando i ricercatori di sicurezza a individuare exploit<\/em> sconosciuti prima che si diffondano\u201d<\/em>. Ci\u00f2 consente di avvisare i vendor software e far patchare le vulnerabilit\u00e0, innalzando la sicurezza generale.<\/p>\n\n\n\n

    Per un analista CSIRT\/SOC, non \u00e8 richiesto essere un reverse engineer <\/em>di livello avanzato, ma sicuramente avere i fondamenti di analisi malware<\/strong>: sapere come funziona un eseguibile, quali sono i metodi base per analizzarlo, quali strumenti usare e come interpretare un report tecnico di malware. Ad esempio, bisogna conoscere strumenti come VirusTotal <\/strong>(per un primo scan e reputazione di un file), Hybrid Analysis <\/strong>o ANY.RUN <\/strong>(sandbox online che mostrano un comportamento dinamico), debugger come OllyDbg\/x64dbg <\/strong>(per tracciare manualmente l\u2019esecuzione di malware a runtime), decompiler come Ghidra (per uno sguardo ad alto livello sul codice), e strumenti di dump e unpacking (poich\u00e9 molti malware sono compressi o criptati). Durante un incidente grave, il responsabile potrebbe dover guidare il team nella scelta: \u201cAbbiamo trovato questo eseguibile sospetto su un server, lo isoliamo e lo mandiamo in sandbox? oppure ne calcoliamo subito l\u2019hash e vediamo se \u00e8 noto? Quali IOC estraiamo?\u201d. Il responsabile deve anche tradurre i risultati dell\u2019analisi malware in azioni: ad esempio, se dall\u2019analisi emerge che il malware si propaga via rete usando SMB exploit, andr\u00e0 immediatamente disposto un controllo di tutti gli host per vedere se presentano quella vulnerabilit\u00e0 e applicare le patch. Oppure, se scopre che il malware ruba certi tipi di file, andranno monitorati accessi anomali a quei file su altri sistemi. Insomma, l\u2019analisi malware fornisce la \u201cintelligence tecnica\u201d <\/em>durante una crisi cyber, e il responsabile deve saperla sfruttare per il contenimento e la remediation dell\u2019incidente.<\/p>\n\n\n\n

    Un esempio italiano di applicazione di queste competenze \u00e8 il lavoro svolto dal CERT-AgID sulle campagne di malspam <\/strong>(email malevole) in Italia: i loro analisti analizzano quotidianamente malware come bancari (es. Ursnif, Dridex), ransomware (es. Cryptolocker, LockBit) e spyware diffusi via email di phishing, producendo report <\/em>e IOC condivisi con tutte le amministrazioni. Nel Report \u201cLe campagne<\/em> malevole del 2024\u201d <\/em>pubblicato da CERT-AgID, ad esempio, si illustrano le tecniche di offuscamento osservate nei malware giunti via PEC, mostrando come la combinazione di analisi statica (per deoffuscare macro Office e script PowerShell allegati) e analisi dinamica (per osservare i contatti verso i server di destinazione e i file drop) abbia permesso di contrastare efficacemente tali minacce. Questo tipo di conoscenza, opportunamente integrata nei processi di un SOC, consente di innalzare significativamente il livello di protezione degli enti italiani contro attacchi mirati.<\/p>\n\n\n\n

    Principali strumenti software per l\u2019analisi forense<\/strong><\/p>\n\n\n\n

    In campo forense digitale esiste un\u2019ampia gamma di strumenti software specializzati. Un responsabile CSIRT\/SOC deve conoscerne i principali \u2013 sia commerciali sia open source \u2013 per scegliere di volta in volta quelli pi\u00f9 adatti e per comprendere i risultati prodotti dal team tecnico. Di seguito elenchiamo alcuni dei tool pi\u00f9 diffusi e riconosciuti, suddivisi per categoria.<\/p>\n\n\n\n

      \n
    • Suite di analisi su disco e file system: <\/strong>strumenti completi che permettono di esaminare immagini forensi di dischi, navigare tra file, estrarre artefatti e generare report. I pi\u00f9 noti sono EnCase Forensic <\/em>(Guidance Software\/OpenText) e FTK \u2013 Forensic Toolkit <\/em>(AccessData\/Exterro), ampiamente usati dalle forze dell\u2019ordine e dalle societ\u00e0 di cybersecurity. In ambito open source, spicca Autopsy <\/strong>(con il motore The Sleuth Kit<\/em>): interfaccia grafica che consente analisi dettagliate di file system (NTFS, FAT, EXT, HFS, ecc.), ricerca di keyword, carving, timeline e molto altro. Autopsy supporta plugin per l\u2019analisi di specifici artifact (ad es. la cronologia di browser, i registri di sistema Windows, ecc.) e rappresenta una valida alternativa free ai prodotti commerciali. Un altro nome da citare \u00e8 X-Ways Forensics <\/strong>(di X-Ways Software): un toolkit potentissimo e leggero molto apprezzato per la velocit\u00e0 e l\u2019efficienza nell\u2019analisi di dischi (popolare in contesti professionali europei). Queste suite includono funzioni di hashing di massa, confronto con liste di known files <\/em>(hash set noti, come la NSRL), ricostruzione di RAID, esportazione di report completi per tribunale, e sono indispensabili per gestire casi complessi. Da menzionare anche software come Magnet AXIOM <\/strong>(della Magnet Forensics), che integra funzioni di analisi filesystem, mobile e cloud in un unico ambiente.<\/li>\n\n\n\n
    • Strumenti per memory forensics: <\/strong>il gi\u00e0 discusso Volatility Framework <\/strong>\u00e8 il riferimento open source per l\u2019analisi dei dump RAM. Include decine di plugin per estrarre praticamente qualsiasi informazione dalla memoria di Windows, Linux, macOS e profili Android. La sua conoscenza \u00e8 fondamentale per chi fa incident response. Un altro progetto simile (nato come fork) \u00e8 Rekall<\/strong>. In ambito commerciale, Magnet AXIOM <\/em>e Belkasoft Evidence Center <\/em>offrono moduli di memory analysis integrati, ma spesso si finisce per utilizzare Volatility anche in tali contesti. Per facilitare l\u2019uso di Volatility, esistono interfacce grafiche e tool correlati \u2013 ad esempio Volatility Workbench <\/strong>o Autopsy Memory Modules <\/strong>\u2013 ma anche linee di comando avanzate come KAPE <\/strong>che integrano flussi di lavoro di triage memoria + timeline. Infine, nel mondo enterprise, prodotti EDR (Endpoint Detection & Response) come CrowdStrike, FireEye HX, Microsoft Defender for Endpoint, spesso dispongono di capacit\u00e0 di acquisizione memoria e analisi automatizzata integrata, sebbene non flessibili come un\u2019analisi manuale con Volatility.<\/li>\n\n\n\n
    • Strumenti per analisi di log e network forensics: <\/strong>per i log, oltre ai SIEM gi\u00e0 citati (Splunk, Elastic Stack\/ELK, IBM QRadar, ArcSight, etc.), in un laboratorio forense pu\u00f2 essere utile log2timeline\/Plaso <\/em>per estrarre timeline come detto, oppure tool come Chainsaw <\/strong>(per analisi offline di Windows event logs usando regole Sigma), EVTX Explorer <\/strong>(visualizzazione avanzata di log Windows) e SysmonView <\/strong>(per tracciare eventi Sysmon). Per la parte network, l\u2019insostituibile Wireshark <\/strong>permette di analizzare qualunque traccia di rete a basso livello. In aggiunta, strumenti come Zeek <\/strong>(ex Bro) servono a elaborare grandi moli di traffico producendo log sintetici su connessioni, file trasferiti, dns query, ecc. Utili anche NetworkMiner <\/strong>(che estrae in automatico elementi dal traffico, simile a Xplico ma con interfaccia diversa) e Moloch\/Arkime <\/strong>(piattaforma di capture indexing su larga scala). Nel contesto italiano, come gi\u00e0 accennato, la distribuzione DEFT Linux <\/strong>includeva Xplico e altre utility di rete, costituendo un riferimento per molti anni (ora il progetto \u00e8 meno attivo, ma Xplico prosegue separatamente).<\/li>\n\n\n\n
    • Strumenti per analisi malware: <\/strong>qui troviamo disassembler e debugger come IDA Pro<\/strong>, Ghidra <\/strong>(open source della NSA), OllyDbg\/x64dbg<\/strong>, essenziali per il reversing. Sandbox come Cuckoo <\/strong>(open) e varie soluzioni commerciali (VMRay, JoeSandbox, Any.Run) sono utilizzate per l\u2019automated dynamic analysis. Inoltre, tool come Radare2 <\/strong>o Binary Ninja <\/strong>possono fornire analisi alternative. L\u2019analista malware utilizza anche unpacker <\/em>(es. UPX <\/strong>per eseguibili compressi) e strumenti di monitoraggio come Process Monitor<\/strong>, RegShot<\/strong>, ApateDNS <\/strong>(per ingannare le richieste DNS dei malware). Su un piano diverso, servizi online tipo VirusTotal <\/strong>e database come MalwareBazaar <\/strong>aiutano a contestualizzare il campione (vedere se hash \u00e8 noto, se esistono Yara rules, ecc.). Conoscere questi strumenti e le relative tecniche di utilizzo rientra nel bagaglio di competenze che un responsabile deve quantomeno saper indirizzare: ad esempio, decidere quando inviare un campione sospetto a un servizio cloud per un\u2019analisi veloce e quando invece \u00e8 necessario allestire un ambiente isolato e approfondire manualmente.<\/li>\n\n\n\n
    • Piattaforme integrate e distribuzioni forensi: <\/strong>esistono delle vere e proprie distro <\/em>o suite integrate che raccolgono decine di tool. Ad esempio CAINE <\/strong>(Computer Aided INvestigative Environment) \u00e8 una distribuzione GNU\/Linux live creata in Italia, specificamente per la digital forensics. CAINE contiene un ambiente grafico con script e interfacce che guidano attraverso le fasi classiche dell\u2019investigazione (acquisizione, esame, report) e integra moduli <\/em>software per analisi di database, memoria, rete, immagini file system NTFS\/FAT\/EXT, etc. 43 44 . Il tutto assicurando che le operazioni siano forensically sound (ad esempio montando le evidenze in sola lettura). Altre distro note sono SANS SIFT Workstation <\/strong>(Ubuntu-based, mantenuta da SANS Institute) e Kali Linux <\/strong>per la parte pi\u00f9 \u201coffensiva\u201d e di test penetrativo ma comunque utile per alcuni strumenti forensi. Anche Tsurugi Linux <\/strong>\u00e8 una distro recente orientata a DFIR. L\u2019adozione di queste piattaforme consente ai team di avere un ambiente standard con tutti gli strumenti necessari pronti all\u2019uso. Nel contesto lavorativo, spesso si usano macchine virtuali con tali distro per operare sulle evidenze in laboratorio.<\/li>\n<\/ul>\n\n\n\n

      In ambito CSIRT\/SOC, \u00e8 attesa \u201cla conoscenza dei principali strumenti software<\/em> di analisi forense quali Autopsy, Volatility, Magnet Forensics, EnCase Forensic\u201d<\/em>, come esplicitato anche in annunci di lavoro del settore. Questo significa avere familiarit\u00e0 almeno di base con l\u2019interfaccia e le funzionalit\u00e0 di ciascuno di essi: ad esempio sapere come aprire un case in Autopsy e avviare l\u2019ingest dei moduli, oppure come lanciare i plugin di Volatility da riga di comando per estrarre i processi o le connessioni di rete da un dump RAM, o ancora conoscere l\u2019esistenza di Magnet AXIOM (suite commerciale all-in-one usata anche da forze dell\u2019ordine per analizzare PC e dispositivi mobili). Naturalmente nessuno strumento \u00e8 \u201cuniversale\u201d o adatto a tutti gli scopi: il bravo analista sceglie di volta in volta l\u2019utensile pi\u00f9 idoneo. Ad esempio, per una rapida triage su 100 endpoint potrebbe usare script e tool da riga di comando (es. KAPE <\/em>per raccogliere artefatti chiave e Velociraptor <\/em>per query live), mentre per un\u2019analisi in depth di un singolo server compromesso potrebbe preferire montare l\u2019immagine in Autopsy e lavorare di fino. L\u2019importante \u00e8 conoscere le potenzialit\u00e0 e i limiti di ogni strumento: saper leggere tra le righe di un output, capire se ad esempio un dato mancante \u00e8 dovuto a un limite del tool o alla reale assenza di quell\u2019artefatto, ecc.<\/p>\n\n\n\n

      Da ultimo, vale la pena citare che gli strumenti software sono in continua evoluzione: ogni anno emergono nuovi tool o nuove versioni con funzionalit\u00e0 potenziate (si pensi solo all\u2019evoluzione di Volatility per supportare Windows 11, o ai tool di cloud forensics per AWS\/Azure). Un responsabile forense deve mantenersi aggiornato, partecipando magari a community specializzate (come Forensic Focus<\/strong>, DFIR Training<\/strong>, o community locali IISFA) e testando in laboratorio i nuovi strumenti per valutarne l\u2019efficacia.<\/p>\n\n\n\n

      Conclusioni<\/strong><\/p>\n\n\n\n

      L\u2019articolo ha passato in rassegna i principali ambiti dell\u2019analisi forense digitale rilevanti per un responsabile di cybersecurity. Dall\u2019analisi dei file system e delle memorie di massa (con le tecniche di recupero dati e carving) all\u2019ispezione forense della memoria volatile, dall\u2019interpretazione dei log di sicurezza alla dissezione del traffico di rete, fino allo studio dei malware e all\u2019uso dei tool specializzati \u2013 ogni sezione evidenzia competenze e conoscenze che risultano oggi imprescindibili per gestire efficacemente incidenti informatici complessi. Queste attivit\u00e0 non vivono isolate, ma confluiscono in un processo unificato di digital forensics & incident response (DFIR)<\/strong>: ad esempio, i risultati dell\u2019analisi malware influiscono sulle azioni di containment, la timeline forense orienta le indagini ulteriori, l\u2019analisi dei log pu\u00f2 suggerire dove cercare evidenze aggiuntive su disco o in memoria, e cos\u00ec via. Il responsabile deve quindi avere una visione olistica, sapendo integrare i vari filoni di analisi in una strategia coerente.<\/p>\n\n\n\n

      Gli standard internazionali citati (ISO\/IEC 27042, 27043, NIST SP 800-86) forniscono un quadro metodologico solido: aderiscono a principi di rigor metodologico, validit\u00e0, ripetibilit\u00e0 e legalit\u00e0 <\/em>delle operazioni forensi. Anche nelle procedure italiane (dalle circolari di ACN\/CERT-AgID ai manuali operativi delle forze dell\u2019ordine) si ritrova l\u2019enfasi sulla corretta gestione delle evidenze e sulla necessit\u00e0 di agire tempestivamente ma senza comprometterne l\u2019integrit\u00e0. Questo equilibrio \u2013 rapidit\u00e0 vs. accuratezza \u2013 \u00e8 spesso la sfida principale in uno scenario di incidente reale: il responsabile deve decidere quando \u00e8 il caso di scollegare un sistema per preservarne lo stato, oppure quando conviene lasciarlo online per raccogliere pi\u00f9 dati; deve prioritizzare le analisi (ad esempio, prima la memoria per cogliere dati volatili, poi il disco) e allocare le risorse giuste (personale e strumenti) ai vari task.<\/p>\n\n\n\n

      In termini di contesto nazionale, abbiamo visto come l\u2019Italia si stia allineando alle migliori pratiche: la creazione dell\u2019ACN e il potenziamento di CSIRT Italia, le attivit\u00e0 di CERT-AgID focalizzate su prevenzione e condivisione di informazioni, nonch\u00e9 la crescita di competenze nelle unit\u00e0 di Polizia Postale e altri organi investigativi in materia di cyber forensics, testimoniano una maggiore attenzione strategica verso la resilienza cibernetica. Casi concreti gestiti con successo \u2013 dalla mitigazione di campagne malware mirate alle PA, all\u2019attribuzione di attacchi tramite analisi delle TTP, fino alla persecuzione penale di cybercriminali grazie a prove digitali forensi \u2013 dimostrano il valore di queste capacit\u00e0.<\/p>\n\n\n\n

      Per chi aspira a coordinare la prevenzione e gestione degli incidenti informatici, \u00e8 quindi cruciale non solo conoscere la teoria, ma anche aver maturato una certa esperienza pratica con le tecniche e gli strumenti descritti. La formazione continua, i laboratori su scenari simulati (ad esempio competizioni di Digital Forensics CTF <\/strong>o esercitazioni nazionali di cyber crisis) e l\u2019aggiornamento sulle minacce emergenti (tramite report come quelli CERT-AgID o dell\u2019ENISA) completeranno il bagaglio necessario. In un campo cos\u00ec dinamico, la curiosit\u00e0 investigativa <\/strong>e la mentalit\u00e0 analitica <\/strong>sono qualit\u00e0 preziose quanto la conoscenza tecnica. Un buon responsabile forense sa fare le domande giuste e seguire gli indizi digitali con rigore scientifico, consapevole che dietro ogni byte potrebbe celarsi la chiave per sventare un attacco o attribuirne la responsabilit\u00e0.<\/p>\n\n\n\n

      In conclusione, l\u2019analisi forense applicata al cyber-incident response \u00e8 sia un\u2019arte che una scienza: richiede metodo, strumenti e standard \u2013 ma anche intuito, esperienza e capacit\u00e0 di adattamento. L\u2019obiettivo finale \u00e8 sempre quello di far luce sull\u2019accaduto (shed light on the incident<\/em>), fornendo risposte chiare al chi, cosa, quando, come <\/em>e aiutando cos\u00ec l\u2019organizzazione a riprendersi <\/strong>dall\u2019incidente e a imparare <\/strong>da esso per migliorare la propria postura di sicurezza.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Introduzione La digital forensics \u00e8 la disciplina che si occupa di individuare, preservare ed esaminare le evidenze digitali al fine di ricostruire eventi e azioni compiute su sistemi informatici. In particolare, nel contesto della risposta agli incidenti informatici, le tecniche forensi permettono di capire cosa \u00e8 accaduto durante un attacco, quali sistemi sono stati compromessi … Leggi tutto “Digital forensics nella risposta agli incidenti informatici”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[12,14],"tags":[51,84,77,83,82,79,87,85,86,53],"class_list":["post-3081","post","type-post","status-publish","format-standard","hentry","category-cyber-security","category-digital-forensics","tag-acquisizione-forense","tag-data-carving","tag-dump","tag-file-system","tag-incident-response","tag-log","tag-malware","tag-network","tag-timeline","tag-volatility"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3081","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=3081"}],"version-history":[{"count":30,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3081\/revisions"}],"predecessor-version":[{"id":3113,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/3081\/revisions\/3113"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=3081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=3081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=3081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}