Android: come raccogliere bug report, Debug Logs e Log anti-intrusioni

forenser on 19 Agosto 2026

Android: come raccogliere bug report, Debug Logs e log anti-intrusione
La raccolta tempestiva di bug report, Debug Logs e log anti-intrusione permette di conservare informazioni utili per ricostruire anomalie e possibili eventi di sicurezza su Android

Durante un’analisi, un incidente o una semplice attività di assistenza tecnica può essere necessario raccogliere informazioni diagnostiche da uno smartphone Android.

A differenza di iPhone e iPad, Android non dispone di un singolo archivio perfettamente equivalente al sysdiagnose, il pacchetto diagnostico unico dei dispositivi Apple. Le fonti principali sono tre:

  • il bug report, che raccoglie in un archivio lo stato diagnostico del dispositivo;
  • i Debug Logs, ottenuti tramite logcat, utili per osservare ciò che accade durante un problema;
  • il Log anti-intrusioni, introdotto con Android 16 per conservare nel tempo eventi rilevanti per la sicurezza.

Sono strumenti complementari e non intercambiabili.

Generare un bug report dal dispositivo

Il bug report è un archivio .zip che raccoglie log di sistema, crash, informazioni sui processi e altri dati tecnici prodotti dai componenti interni del sistema. Le dimensioni possono variare da alcune decine a diverse centinaia di MB, in base al dispositivo e ai dati disponibili.

Può essere utile per analizzare crash, blocchi, errori ANR (le app che si bloccano senza rispondere), consumi energetici anomali, problemi di rete e altri comportamenti inattesi.

Per generarlo direttamente dal dispositivo è necessario attivare le Opzioni sviluppatore, un menu nascosto di funzioni avanzate.

Nella maggior parte dei dispositivi:

  1. aprite Impostazioni > Informazioni sul telefono;
  2. individuate la voce Numero build;
  3. toccatela sette volte;
  4. inserite il PIN, se richiesto.

Successivamente:

  1. aprite Impostazioni > Sistema > Opzioni sviluppatore;
  2. selezionate Crea report bug, Segnalazione bug o una voce equivalente;
  3. se vengono proposte due varianti, il Report interattivo è adatto alla maggior parte dei casi e permette di aggiungere dettagli e screenshot; il Report completo include tutte le sezioni diagnostiche, ma non permette queste integrazioni: sceglietelo quando chi riceverà il file lo richiede espressamente;
  4. avviate la raccolta.

La raccolta richiede qualche minuto: al termine comparirà una notifica attraverso la quale sarà possibile salvare o condividere l’archivio.

Su Pixel e su alcuni altri dispositivi, sempre nelle Opzioni sviluppatore, è disponibile anche la Scorciatoia segnalazione bug: aggiunge la voce al menu di accensione e consente di avviare la raccolta nel momento esatto in cui il problema si manifesta, senza dover navigare nei menu. Sui Pixel recenti il menu si apre premendo insieme Accensione e Volume Su, come indicato nella guida Pixel.

Il nome del file sarà generalmente simile a:

bugreport-BUILD_ID-DATE.zip

dove al posto di BUILD_ID e DATE troverete la versione del software e la data di creazione.

Il percorso e il nome delle opzioni possono variare in base al produttore. La procedura generale è documentata da Android Developers.

Generare il bug report da computer con ADB

Il bug report può essere generato anche da computer, su macOS, Linux o Windows, tramite ADB (Android Debug Bridge): è lo strumento a riga di comando con cui il computer dialoga con un dispositivo Android, ed è incluso negli SDK Platform Tools ufficiali di Google. Non serve installare nulla: scaricate l’archivio, estraetelo e aprite il Terminale nella cartella appena estratta. Su Windows il modo più rapido è digitare cmd nella barra degli indirizzi di quella cartella e premere Invio; su Mac si fa clic destro sulla cartella e si sceglie “Nuovo terminale nella cartella”.

Negli esempi successivi viene utilizzato adb. Su macOS e Linux, se state eseguendo il programma direttamente dalla cartella estratta, sostituitelo con ./adb, per esempio ./adb devices.

Sul dispositivo:

  1. abilitate Debug USB nelle Opzioni sviluppatore: è l’interruttore che consente al computer di comunicare con lo smartphone;
  2. collegate lo smartphone al computer via USB;
  3. sbloccatelo;
  4. confermate la richiesta di autorizzazione che compare sullo schermo: l’impronta RSA mostrata identifica il computer che state autorizzando, quindi accettatela solo se siete voi ad aver appena collegato il dispositivo al vostro computer.

Dal computer verificate che il dispositivo sia visibile:

adb devices

Se tutto è a posto comparirà il numero di serie dello smartphone seguito dalla parola device. Se invece compare unauthorized, sbloccate lo smartphone e confermate l’autorizzazione.

A questo punto avviate la generazione:

adb bugreport

Non serve altro: ADB chiede al dispositivo di generare il bug report, attende che sia pronto e salva l’archivio .zip nella cartella in cui vi trovate. L’operazione può richiedere alcuni minuti.

Se sono collegati più dispositivi, indicate quale usare con il numero di serie mostrato da adb devices:

adb -s NUMERO_SERIALE bugreport

Conservate il file .zip originale senza estrarlo, modificarlo o ricomprimerlo.

Raccogliere i Debug Logs con logcat

I Debug Logs sono i messaggi prodotti in tempo reale dal sistema operativo e dalle applicazioni. Android li conserva in aree di memoria di dimensione limitata, i buffer: quando si riempiono, i dati più vecchi vengono sovrascritti dai nuovi.

Per questo motivo devono essere raccolti il prima possibile.

Si presentano due situazioni tipiche.

Il problema è riproducibile: avviate la registrazione con:

adb logcat -b all -v threadtime > debug-logs.txt

Lasciate il comando in esecuzione, riproducete il problema e interrompete la raccolta premendo Ctrl+C.

Il problema è appena avvenuto e non potete (o non volete) riprodurlo: salvate ciò che il dispositivo ha ancora in memoria; in questo caso il comando termina da solo:

adb logcat -b all -v threadtime -d > debug-logs.txt

In entrambi i casi il file debug-logs.txt viene creato nella cartella in cui vi trovate. I due comandi sono identici a parte l’ultima opzione: chiedono di leggere tutti i buffer disponibili (-b all) con data, ora, priorità, PID e TID (-v threadtime), e la -d del secondo dice a logcat di salvare quanto già presente e fermarsi, invece di restare in ascolto.

Su Windows eseguite questi comandi dal Prompt dei comandi (cmd.exe): Windows PowerShell 5.1 salva il file in una codifica (UTF-16LE) che alcuni strumenti di analisi non leggono correttamente, mentre PowerShell 7 usa UTF-8 e non ha questo problema.

I Debug Logs servono a osservare un errore mentre avviene; il bug report fotografa invece lo stato complessivo del dispositivo. La sintassi completa di logcat è descritta nella documentazione ufficiale Android.

Il nuovo Log anti-intrusioni di Android 16

Con Android 16 Google ha introdotto Intrusion Logging, chiamato nell’interfaccia italiana Log anti-intrusioni.

La funzione fa parte della modalità Protezione avanzata ed è stata sviluppata anche con il contributo dell’Amnesty International Security Lab.

A differenza del bug report e dei Debug Logs, conserva nel tempo eventi selezionati appositamente per le analisi di sicurezza, tra cui:

  • avvio dei processi delle applicazioni;
  • installazioni, aggiornamenti e disinstallazioni;
  • interrogazioni DNS (la traduzione dei nomi dei siti in indirizzi) e connessioni verso indirizzi IP;
  • attività e comandi ADB;
  • trasferimenti di file tramite USB;
  • modifiche ai certificati;
  • blocchi e sblocchi del dispositivo.

I log vengono crittografati sul dispositivo e archiviati nell’Account Google scelto dall’utente. Google dichiara di non poterli leggere. Vengono conservati per 12 mesi e non possono essere eliminati manualmente prima della scadenza.

La funzione deve essere attivata prima dell’evento da analizzare: non permette di recuperare retroattivamente informazioni relative al periodo in cui era disabilitata.

Attivare ed esportare il Log anti-intrusioni

L’attivazione viene proposta durante la configurazione della modalità Protezione avanzata; è comunque possibile intervenire in un secondo momento:

  1. aprite Impostazioni > Sicurezza e privacy;
  2. selezionate Protezione avanzata;
  3. attivate Protezione del dispositivo;
  4. abilitate Log anti-intrusioni durante la configurazione oppure aprite successivamente la relativa voce;
  5. scegliete l’Account Google nel quale conservare i log crittografati;
  6. riavviate il dispositivo, se richiesto.

I nomi e l’ordine delle voci possono variare in base al produttore e alla versione di Android.

Quando è necessario esportare i dati:

  1. aprite Impostazioni > Sicurezza e privacy > Protezione avanzata > Log anti-intrusioni;
  2. selezionate Log accessi;
  3. individuate il dispositivo interessato;
  4. toccate Scarica e decripta;
  5. confermate con PIN o autenticazione biometrica.

I file saranno disponibili nel gestore file, normalmente nella cartella:

Download/Intrusion Logging/

La disponibilità della funzione dipende dal dispositivo e dagli aggiornamenti installati. Le procedure ufficiali e le implicazioni per la privacy sono riportate nella guida di Google e nell’approfondimento di Amnesty International.

Alcuni limiti da conoscere

La recente analisi pubblicata da iVerify conferma il valore del Log anti-intrusioni, ma evidenzia anche alcuni limiti:

  • non registra ogni attività del dispositivo;
  • il caricamento non è in tempo reale: le ultime 12-24 ore potrebbero mancare;
  • la cronologia delle reti Wi-Fi non viene registrata;
  • le installazioni non indicano la provenienza dell’app (Play Store, installazione manuale da file APK o ADB);
  • delle sessioni ADB interattive registra l’apertura, non i comandi digitati;
  • gli spegnimenti non lasciano traccia: l’orario va dedotto dai vuoti di attività.

Come condividere i file

Tutte e tre le raccolte possono contenere dati personali: app installate, identificatori del dispositivo, attività di sistema e connessioni di rete. Condividetele solo con il destinatario previsto, tramite un canale cifrato oppure un link o un archivio protetti da password, comunicata separatamente.

Accompagnate i file con data e ora esatta dell’anomalia (con fuso orario), modello del dispositivo, versione di Android, una breve descrizione dell’accaduto e l’orario della raccolta.

Come accortezza generale, bug report e Debug Logs vanno raccolti il prima possibile dopo il problema; il Log anti-intrusioni, invece, va abilitato preventivamente.

Sysdiagnose su iPhone e iPad: come generarlo, recuperarlo e condividerlo in modo sicuro

forenser on 18 Agosto 2026

Sysdiagnose su iPhone e iPad: schema per generare, recuperare e condividere in modo sicuro i log diagnostici
Il pacchetto sysdiagnose raccoglie i log diagnostici di iPhone e iPad per attività di assistenza tecnica, incident response e analisi forense

Durante un’analisi, la gestione di un incidente o una semplice attività di assistenza tecnica, capita sempre più spesso di chiedere a qualcuno di generare un “sysdiagnose” del proprio iPhone o iPad. E la risposta è quasi sempre la stessa: “Un che cosa?”.

Il sysdiagnose è un archivio diagnostico prodotto su richiesta da iOS e iPadOS. Il file, in formato .tar.gz, contiene una fotografia molto dettagliata dello stato del dispositivo, incluse informazioni provenienti da diverse parti del sistema operativo, log di sistema e crash report recenti.

Può essere utile per analizzare blocchi, crash, consumi energetici anomali, problemi di rete e altri comportamenti inattesi.

I due modi per generarlo dall’iPhone o dall’iPad

Metodo A – la combinazione di tasti

È il metodo standard documentato da Apple:

Premete contemporaneamente Volume Su, Volume Giù e il tasto laterale o superiore, quindi rilasciateli immediatamente.

Il sysdiagnose viene avviato al rilascio dei pulsanti: non teneteli premuti in attesa di una conferma.

Su iPhone, una breve vibrazione conferma generalmente l’avvio della raccolta; su iPad la vibrazione non è prevista.

Gli errori più comuni sono tre:

  • prolungare la pressione: il dispositivo potrebbe bloccarsi oppure mostrare la schermata di spegnimento o di SOS emergenze. La pressione deve essere breve e simultanea.
  • premere i tasti in sequenza: tutti e tre devono essere premuti contemporaneamente.
  • cercare immediatamente il file: la raccolta richiede diversi minuti e Apple indica che può impiegarne fino a dieci.

Metodo B – AssistiveTouch

È il metodo meno noto, ma spesso più comodo se i tasti fisici sono danneggiati oppure se si vogliono evitare catture di schermata o altri errori generici sopra riportati:

  1. Impostazioni > Accessibilità > Tocco > AssistiveTouch, e si attiva AssistiveTouch;
  2. si tocca “Personalizza menu principale” e si aggiunge la voce Analisi;
  3. compare il pulsante flottante: si riproduce il problema, si tocca il pulsante e si sceglie Analisi.

Comparirà un’indicazione che segnala la raccolta dei dati analitici in corso.

Dove trovare il file

Dopo qualche minuto, il sysdiagnose sarà disponibile in:

Impostazioni > Privacy e sicurezza > Analisi e miglioramenti > Dati di analisi

L’elenco può essere molto lungo. Utilizzate la funzione di ricerca, oppure scorrete fino a individuare il file più recente il cui nome inizia con:

sysdiagnose_

Il nome sarà simile a questo:

sysdiagnose_2026.08.17_14-32-11+0200_iPhone-OS_iPhone_23A123.tar.gz

Se il file non compare immediatamente, attendete fino a dieci minuti e controllate nuovamente. Se continua a non essere presente, è possibile che la combinazione di tasti non sia stata rilevata e che la raccolta non sia mai iniziata.

Il file può occupare centinaia di megabyte: è normale e non indica un errore.

Recuperare il sysdiagnose da Mac con libimobiledevice

Il Mac non genera il sysdiagnose dell’iPhone o dell’iPad, ma può recuperarne una copia dopo che l’archivio è stato creato sul dispositivo.

Prima di proseguire, generate quindi il sysdiagnose con uno dei due metodi descritti sopra e attendete il completamento della raccolta.

Per trasferirlo è possibile utilizzare libimobiledevice, una suite open source che consente di comunicare con i dispositivi Apple.

Se utilizzate Homebrew e la suite non è ancora installata, da Terminale eseguite:

brew install libimobiledevice

Collegate l’iPhone o l’iPad al Mac tramite USB e sbloccate il dispositivo. Se compare la richiesta “Vuoi autorizzare questo computer?”, selezionate Autorizza.

Da Terminale eseguite:

idevicepair pair

Il comando effettua il pairing e consente al dispositivo di comunicare con il Mac.

Dalla directory nella quale volete conservare i file, create una cartella dedicata al dispositivo – nel caso in esempio un iPhone 11 – e una seconda cartella chiamata sysdiagnose:

mkdir -p "iPhone 11/sysdiagnose"

Posizionatevi quindi al suo interno:

cd "iPhone 11/sysdiagnose"

Le virgolette sono necessarie perché il nome iPhone 11 contiene uno spazio.

In seguito recuperate i file diagnostici, eseguendo esattamente questo comando:

idevicecrashreport -e -k .

Il punto finale indica la cartella corrente come destinazione. L’opzione -e estrae i crash report disponibili, mentre -k mantiene una copia dei report anche sul dispositivo.

Attendete che il caricamento di tutti i file sia terminato.

Al termine, tornate alla cartella precedente con il comando:

cd ..

Quindi create l’archivio compresso:

tar -czvf sysdiagnose.tar.gz sysdiagnose

Le opzioni utilizzate significano:

  • c: crea un nuovo archivio;
  • z: applica la compressione gzip;
  • v: mostra a schermo i file elaborati;
  • f: indica il nome del file da creare, in questo caso sysdiagnose.tar.gz.

Al termine troverete il file sysdiagnose.tar.gz all’interno della cartella iPhone 11. L’archivio conterrà l’intera cartella esportata e potrà quindi includere, oltre al sysdiagnose, anche altri report diagnostici recuperati dal dispositivo: è questo bundle completo che potrete inviare al destinatario.

Come condividerlo

Dal dispositivo aprite il file individuato in Dati di analisi, toccate l’icona di condivisione in alto a destra e scegliete una delle opzioni disponibili:

  • AirDrop, generalmente la soluzione più rapida.
  • Salva su File, per conservarlo localmente o caricarlo successivamente su un servizio di trasferimento.
  • Un portale di assistenza o un collegamento protetto concordato con il destinatario.

Attenzione alla riservatezza

Il sysdiagnose può contenere informazioni personali e dati sensibili relativi al dispositivo, alle applicazioni e alle attività di sistema.

Condividetelo esclusivamente con il destinatario previsto e attraverso un canale sicuro. Se utilizzate un collegamento cloud, è consigliabile impostare una scadenza e una password, comunicando quest’ultima attraverso un canale separato.

Come accortezza generale, è consigliabile generare il sysdiagnose il prima possibile dopo l’anomalia e accompagnarlo con l’orario esatto e una breve descrizione dell’accaduto. Queste informazioni possono aiutare a interpretare i dati raccolti.

Account WhatsApp compromessi su iPhone con iOS 16: l’attacco 0-click che bypassa i dispositivi collegati

forenser on 22 Maggio 2026

WhatsApp

Un weekend tranquillo, di fine maggio: il tempo passa senza problemi fino a quando non iniziano ad arrivare messaggi ambigui sull’applicazione di WhatsApp installata sul tuo iPhone. I contatti iniziano a chiederti: “perché devo darti dei soldi?” oppure “a cosa ti serve il bonifico?”. Questi contatti stanno solo rispondendo ad un messaggio che è stato inviato dal tuo account WhatsApp; il problema è che tu non hai inviato nulla.

Questo è ciò che è accaduto negli ultimi giorni a diverse persone che si sono rivolte al nostro studio. Siamo stati contattati in più occasioni, nell’arco della stessa giornata, da utenti che avevano riscontrato la medesima anomalia. Il fatto curioso è che nessun dispositivo estraneo risultava associato all’account WhatsApp personale: la sezione “Dispositivi collegati” (“Linked Devices”) era pulita, eppure qualcuno stava inviando messaggi a nostra insaputa, dal nostro numero. Cosa sta succedendo?

A questo punto sono iniziate le nostre indagini per cercare di capire come sia possibile incorrere in una “problematica” di questo tipo. Quanto raccolto ha permesso di rivelare dei pattern comuni, utili per contestualizzare il tipo di minaccia e la superficie di attacco.

Confronto tra i casi

Mettendo a confronto i diversi casi raccolti, abbiamo individuato una serie di elementi ricorrenti che delineano lo scenario di compromissione:

• tutti i casi rilevati riguardano iPhone (dal modello 8 al 14, incluse le varianti X, XR, XS, 11, SE, 12 e 13) su cui è installata un versione di iOS 16 nelle sue diverse release;

• gli attaccanti scrivono in chat ai contatti della vittima, dal numero WhatsApp della vittima stessa, chiedendo di disporre bonifici;

• gli attaccanti sembrano avere accesso alle sole chat recenti, ovvero a quelle con cui la vittima ha interagito da poco;

• nessun dispositivo collegato è visibile nella sezione “Dispositivi collegati” delle impostazioni di WhatsApp;

• le vittime non riportano di aver compiuto alcuna azione di pairing particolare: non hanno fornito codici, non hanno inquadrato QR code, non hanno autorizzato accessi.

Per queste ragioni è stato sin da subito evidente che non si trattasse di un classico episodio di ghost pairing (nel quale l’attaccante induce la vittima a scansionare un QR code o a condividere un codice di verifica): l’assenza di qualsiasi interazione richiesta all’utente fa propendere per una compromissione di tipo 0-click, cioè per un’infezione che non richiede alcun intervento da parte della vittima e che colpisce direttamente lo smartphone o l’app WhatsApp.

Account Fantasma

Il primo aspetto senza dubbio interessante è la mancanza di un dispositivo associato. Analizzando i log di una delle copie forensi e il relativo sysdiagnose (componente del sistema operativo iOS contenente i log di diagnostica del telefono), è stato possibile notare un’anomalia nei log generati da WhatsApp: una continua sequenza di eventi di “resync”, come se l’applicazione stesse continuamente rinegoziando la sessione con i server di WhatsApp. Si tratta di eventi non molto comuni presenti in quantità insolita, a meno che qualcun altro non stia tentando in parallelo di mantenere attiva una propria sessione sullo stesso account.

Questa sequenza continua di sincronizzazione, di fatto, è il sintomo di una “competizione” tra due endpoint che cercano di mantenere attiva la stessa sessione, dinamica che approfondiremo successivamente, dopo aver discusso del probabile vettore di compromissione.

Versione di iOS

Un secondo aspetto molto interessante è che tutte le persone che ci hanno contattato possiedono un iPhone, con una specifica versione: iOS 16. Che sia questo il comune denominatore?

Partendo da tale presupposto abbiamo approfondito, ricercando tra i vari articoli presenti in rete e tra i log a disposizione, presenti tra i dati dei dispositivi compromessi. Ricercando problematiche di sicurezza correlate ad iOS 16 abbiamo notato una vulnerabilità descritta nel CVE-2025-43300, possibilmente in combinazione con il CVE 2025-55177 (vulnerabilità di WhatsApp iOS/macOS che poteva consentire il parsing di contenuti da URL arbitrari tramite messaggi di sincronizzazione dei dispositivi collegati non correttamente autorizzati):

ios

La vulnerabilità identificata pare sia correlata al processo delle immagini da parte di una libreria del sistema operativo, libreria utilizzata da diverse applicazioni come, appunto, WhatsApp. In aggiunta, nelle ultime settimane, la letteratura online in relazione a questa vulnerabilità sembra sia stata ampiamente documentata, rendendo di conseguenza più facile lo sfruttamento. Stando a quanto riportato dalla descrizione della vulnerabilità, le versioni di iOS minori della 16.7.12 sembrano essere vulnerabili, versioni compatibili con quelle da noi rilevate nei dispositivi delle vittime.

A supporto di questa tesi, all’interno degli unified logs estratti dal dispositivo sono state rinvenute molteplici occorrenze di errori generati proprio dalla libreria che si occupa del parsing delle immagini, in orari compatibili con quelli relativi alla compromissione degli account WhatsApp.

Riproduzione dello scenario in laboratorio

Per chiudere il cerchio attorno alla sequenza anomala di “resync” osservata nei log, i nostri tecnici hanno provato a riprodurre in laboratorio una parte dello scenario di compromissione, impiegando un device di “test” con installata una versione di iOS vulnerabile. L’attività ha permesso di confermare che esiste effettivamente una catena di azioni in cui un dispositivo estraneo si presenta al server di WhatsApp, apparendo come il dispositivo “vittima”. In tale condizione non vi è alcun tipo di avviso su quest’ultimo da parte di WhatsApp o di iOS.

In altre parole, partendo dal dispositivo compromesso è possibile esfiltrare il materiale crittografico utile per l’handshake di avvio sessione, necessario per istanziare un nuovo client WhatsApp altrove, agganciato però all’account della vittima. È proprio in questa fase che si genera la sequenza continua di “resync” nei log (riscontrati parimenti nei test del nostro laboratorio): il telefono legittimo e il client dell’attaccante si contendono la sessione, riautenticandosi ciclicamente sui server di WhatsApp. Questo modello operativo è pienamente coerente con quanto raccolto sul campo, ovvero con un account che invia messaggi a contatti recenti pur in totale assenza di dispositivi collegati visibili dalle impostazioni dell’app.

Indicazioni operative per utenti e vittime

Sulla base di quanto osservato sui casi reali e di quanto verificato durante la riproduzione dello scenario, possiamo proporre alcune indicazioni pratiche, fermo restando che l’analisi è tuttora in corso e che gli aggiornamenti potranno modificare il quadro qui descritto.

In ottica di prevenzione, trattandosi presumibilmente di un attacco 0-click, è utile ridurre la superficie d’attacco limitando gli automatismi e attivando la Lockdown Mode tramite le Impostazioni Restrittive dell’Account (Strict Account Settings). Non abbiamo ancora verificato se l’abilitazione della verifica in due passaggi su WhatsApp riduca concretamente il rischio di compromissione, ma resta una buona pratica generale. La raccomandazione principale rimane comunque l’aggiornamento del sistema operativo all’ultima patch di sicurezza disponibile: nei casi raccolti, tutti i dispositivi vulnerabili eseguivano una release di iOS 16, mentre la vulnerabilità CVE-2025-43300 risulta corretta nelle versioni successive (quantomeno per gli iPhone).

Se l’account risulta già compromesso, dalle osservazioni condotte emergono alcuni elementi utili: utilizzando il blocco delle chat (la funzione che le rende nascoste tramite codice o biometria) gli attaccanti sembrano non riuscire più a leggerle né a scrivere ai relativi contatti; per “estromettere” l’attaccante pare efficace aggiornare l’app WhatsApp o installarla su un nuovo dispositivo procedendo a una nuova autenticazione; infine, dato che tutti i casi raccolti riguardano dispositivi con iOS 16, l’aggiornamento del sistema operativo dovrebbe far venire meno le condizioni di sfruttamento dell’infezione.

Una raccomandazione importante per chi riceve messaggi sospetti: se un contatto chiede l’esecuzione di un bonifico via WhatsApp, è preferibile verificare la richiesta con una telefonata diretta. Scrivere alla vittima sulla stessa chat WhatsApp potrebbe non essere efficace, perché i messaggi potrebbero essere visualizzati dall’attaccante senza arrivare al legittimo titolare dell’account.

Chiaramente, dal punto di vista delle indagini e della preservazione delle prove, il consiglio di massima è rivolgersi ad un team esperto che possa fornire consigli più approfonditi, idonei per ogni caso specifico, auspicando al contempo la possibilità di non perdere prove utili per futuri approfondimenti.

Il nostro team sta proseguendo le attività di analisi, raccogliendo ulteriori copie forensi e verificando in dettaglio il modello di attacco. Nel frattempo, la raccomandazione operativa più rilevante resta quella di aggiornare la propria versione di iOS con l’ultima patch di sicurezza disponibile, così da ridurre notevolmente le probabilità di infezione.

DRIFT Linux: prime osservazioni sul nuovo tool forense

forenser on 24 Aprile 2026

drift
drift menù

Estratti dell’interfaccia desktop di DRIFT

È stata recentemente rilasciata DRIFT Linux, una nuova distribuzione italiana per la Digital Forensics, ideata da Massimiliano Dal Cero e basata su Ubuntu 24.04 LTS (Noble). Il progetto si propone come ambiente operativo pensato per le attività forensi sul campo.

Allo stato attuale, DRIFT è concepita principalmente come sistema live avviabile da chiavetta USB, mentre eventuali soluzioni installabili sono previste per versioni successive. Dalla pagina di download emerge inoltre una struttura già piuttosto chiara del progetto: sono disponibili le varianti DRIFT Fast 2026.01 e DRIFT Fast XS 2026.01, mentre Fast Micro e una versione installabile denominata Paddock risultano annunciate come prossime. Questo lascia intendere una distribuzione pensata non come immagine unica, ma come famiglia di strumenti destinata a differenziarsi in base ai diversi scenari operativi.

Secondo quanto riportato sul sito ufficiale, DRIFT Linux si presenta come un ambiente operativo orientato all’uso sul campo, con particolare attenzione alla preservazione delle evidenze digitali, alla gestione controllata dei dispositivi collegati e alla disponibilità immediata di strumenti utili nelle fasi di acquisizione e prima analisi. Abbiamo avuto modo di testarla nei primi giorni successivi al rilascio: in questo articolo ne riportiamo alcune caratteristiche tecniche, soffermandoci sulle principali fasi operative dei moduli esaminati.

Cos’è una distribuzione Linux forense e perché si usa

Una distribuzione Linux forense è un sistema operativo progettato per svolgere attività di acquisizione e analisi cercando di preservare, per quanto possibile, l’integrità dei dati originali. Spesso viene eseguita in modalità live, ad esempio da chiavetta USB, così da ridurre l’interazione con il sistema oggetto di esame e operare in un ambiente controllato.

A differenza di un sistema operativo generico, una distro forense integra di norma strumenti e accorgimenti pensati per limitare le alterazioni indesiderate: accesso ai supporti in sola lettura, gestione controllata delle connessioni, produzione di log e raccolta tracciabile delle evidenze. Questo approccio riduce il rischio di contaminazione accidentale dei dati e contribuisce a rafforzare l’integrità, la tracciabilità e la verificabilità tecnica delle evidenze digitali.

Le caratteristiche di DRIFT Linux che abbiamo testato

Secure Boot Ready

Un aspetto emerso sin da subito nel corso dei test riguarda la compatibilità con il sistema di protezione Microsoft Secure Boot. DRIFT Linux si presenta infatti come una distribuzione avviabile anche su sistemi con Secure Boot abilitato, senza richiedere la disattivazione dell’opzione nel BIOS/UEFI. Si tratta di una semplificazione operativa concreta, soprattutto quando si interviene su hardware moderno o in contesti aziendali nei quali modificare le impostazioni di sicurezza potrebbe non essere possibile, consentito o comunque opportuno.

Kernel Write Blocker nativo

Uno degli aspetti più interessanti di DRIFT Linux è il kernel write blocker nativo visibile all’interno dell’applicativo DRIFT Mount Manager. La protezione dell’integrità dei dati è infatti gestita a livello kernel: i dispositivi collegati vengono mantenuti in sola lettura per impostazione predefinita fin dalle prime fasi del boot, riducendo al minimo il rischio di alterazioni accidentali dei supporti originali. Qualora sia necessario abilitarne la scrittura, l’operazione richiede comunque un’azione esplicita da parte dell’operatore, accompagnata da un avviso ben visibile come da immagine sottostante:

DRIFT Mount Manager — Kernel Write Blocker ATTIVO con dialog di sblocco

Connection Panel

Il Connection Panel è un’interfaccia grafica dedicata che consente di visualizzare e gestire in modo diretto lo stato dei servizi di rete. Si tratta di una scelta coerente con quanto indicato dal progetto, che presenta la connettività come una componente da attivare consapevolmente, così da ridurre il rischio di interferenze o alterazioni del contesto tecnico durante le attività di acquisizione e analisi iniziale. Dal punto di vista operativo, questa impostazione appare particolarmente utile perché sposta il controllo verso l’operatore: la rete non viene trattata come una funzione sempre attiva in background, ma come un elemento da governare in modo esplicito in base alle esigenze del caso concreto.

Estratto del Connection Panel

Drift Forensics Web Acquire

Tra i moduli più interessanti della distribuzione figura Web Acquire. Automatizza l’intera catena di acquisizione forense di una pagina web: snapshot della configurazione di rete (IP, routing, DNS), traceroute verso host multipli, cattura PCAP del traffico, esportazione SSL Key Log dal browser per la decifratura HTTPS, registrazione schermo sincronizzata in formato MP4, generazione del valore di hash SHA-256 di tutti i file prodotti e marcatura temporale blockchain tramite OpenTimestamps.

Le schermate dei test mostrano un’interfaccia dedicata, denominata Drift Forensics Web Acquire, nella quale compaiono campi strutturati per nome del caso, numero del caso, analista, pagina iniziale e destinazione. L’impressione è quella di un workflow pensato non soltanto per “salvare” una pagina web, ma per documentare in modo più ampio il contesto tecnico dell’attività svolta.

Estratto del pannello Drift Forensics Web Acquire

Al termine dell’attività viene generato automaticamente un report HTML completo, di cui vengono mostrati due estratti immagine:

Estratti del report HTML prodotto a fine acquisizione web

Guymager

Tra gli strumenti inclusi in DRIFT Linux figura Guymager 0.8.13, impiegato per l’acquisizione forense di supporti fisici.

Per procedere, è necessario aprire il software “DRIFT Mount Manager”, individuare il disco di destinazione e disattivarne il blocco in scrittura tramite l’icona del lucchetto posta accanto al nome del supporto. Successivamente, il dispositivo dovrà essere impostato in modalità “RW”, così da renderlo idoneo a ricevere i file prodotti durante l’acquisizione forense.

Di seguito si riportano alcune schermate relative al test effettuato:

Dopo aver selezionato “Procedi”, a schermo vengono indicati il percorso del dispositivo sbloccato in RW (/dev/sdc1) e la destinazione (/media/drift/RIPRISTINO):

Premendo nuovamente su “Procedi”, viene mostrato il percorso di mount del disco, ovvero in “/media/drift/RIPRISTINO”:

Estratti di DRIFT Mount Manager

Prima di avviare l’acquisizione, Guymager consente di compilare i metadati del caso — numero del caso, numero dell’evidenza, nome dell’esaminatore e note — che verranno associati all’immagine forense generata. Il software supporta i formati EWF/Exx e dd, con calcolo dell’hash in MD5, SHA-1 e SHA-256 e verifica finale dell’acquisizione, utile a confermare la corrispondenza bit-per-bit tra il supporto sorgente e la copia prodotta.

Nel campo Image directory, visibile nell’immagine sottostante, è stato indicato il percorso del supporto esterno precedentemente montato in modalità RW tramite DRIFT Mount Manager — in questo caso “/media/drift/RIPRISTINO” — con l’aggiunta della cartella di destinazione “Copia_F2026_TEST” prevista per il salvataggio dell’immagine forense.

Estratto dell’interfaccia di Guymager che mostra il completamento della copia (Finished)

Nel complesso, DRIFT Linux appare come un progetto che prova a coniugare funzioni dedicate e strumenti già noti nelle prassi di acquisizione forense, con un’impostazione orientata al controllo dell’ambiente operativo e alla preservazione delle evidenze. Pur trattandosi di una prima release, le funzionalità osservate nei test consentono già di coglierne alcuni aspetti di interesse.

Per ulteriori informazioni sul progetto, sulle funzionalità disponibili e sulla documentazione tecnica, è possibile consultare il sito ufficiale di DRIFT Linux: driftlinux.org

DRIFT Linux: la nuova distribuzione italiana per la Digital Forensics

forenser on 17 Aprile 2026

DRIFT Linux

Estratto dell’interfaccia desktop di DRIFT Linux

Nell’ambito delle distribuzioni Linux dedicate alla Digital Forensics e all’Incident Response, è stata recentemente rilasciata DRIFT Linux (Digital Forensics & Incident Response Toolkits), una nuova distribuzione italiana ideata da Massimiliano Dal Cero, basata su Ubuntu 24.04 LTS (Noble).

Dalle prime informazioni disponibili e dai primi test svolti, il progetto sembra orientato a rispondere a esigenze operative concrete sul campo, si avvia velocemente, è una live distro forense completa dei tool indispensabili per la fase di acquisizione e copia forense ed è compatibile con buona parte dei dispositivi.

In Forenser dedichiamo costante attenzione alla ricerca e alla valutazione degli strumenti disponibili per le attività di analisi forense. Abbiamo avuto modo di testare DRIFT Linux nelle prime ore dalla sua uscita e in questo articolo condividiamo una prima panoramica delle caratteristiche tecniche che hanno attirato la nostra attenzione. Un approfondimento tecnico completo sarà disponibile a breve sul nostro sito.

Secure Boot Ready

Uno degli aspetti che ha subito catturato la nostra attenzione riguarda la compatibilità con Microsoft Secure Boot. La distribuzione live si avvia su sistemi con Secure Boot abilitato senza richiedere la disattivazione dell’opzione nel BIOS/UEFI: una semplificazione operativa concreta, soprattutto quando si interviene su hardware moderno o in contesti aziendali in cui modificare le impostazioni di sicurezza potrebbe non essere possibile o opportuno.

Kernel Write Blocker nativo

La protezione dell’integrità dei dati è gestita direttamente a livello kernel. I dispositivi collegati vengono mantenuti in sola lettura per impostazione predefinita fin dalle prime fasi del boot, riducendo il rischio di alterazioni accidentali sui supporti originali. L’eventuale sblocco in scrittura richiede un’azione esplicita da parte dell’operatore, con avviso ben visibile nell’interfaccia.

DRIFT Mount Manager e Connection Panel

Il sistema include interfacce grafiche dedicate al controllo dell’ambiente di analisi. Il Mount Manager consente di gestire lo stato dei mount in modalità RO/RW, mentre il Connection Panel permette di governare in modo consapevole la connettività di rete — profilo particolarmente delicato in ambito forense, dove l’attivazione della rete deve avvenire solo quando necessario e in modo controllato.

DRIFT Forensics Web Acquire

Tra i moduli di maggiore interesse vi è quello dedicato alla web forensic acquisition, che nei nostri primi test ha mostrato un workflow strutturato di raccolta e documentazione tecnica. Il modulo include la raccolta delle informazioni di rete, la cattura del traffico in formato PCAP, le chiavi TLS/SSL, la registrazione dello schermo e la generazione di un report finale. Un approccio integrato che semplifica la documentazione delle attività di acquisizione web.

Acquisizione forense classica con Guymager

Tra gli strumenti integrati in DRIFTLinux figura Guymager, soluzione ampiamente collaudata per l’acquisizione forense di supporti fisici, che consente la creazione di immagini nei formati “.E01/.Exx” e “.dd”, il calcolo dei valori di hash MD5, SHA-1 e SHA-256, e la successiva verifica finale dell’acquisizione, al fine di confermare la corrispondenza tra la sorgente e la copia forense generata.

OpenTimestamps e tracciabilità delle evidenze

Un ulteriore aspetto di interesse presente in DRIFT Linux è la possibilità di associare alle evidenze una marcatura temporale verificabile tramite OpenTimestamps, aggiungendo un livello aggiuntivo di tracciabilità al workflow di acquisizione. Si tratta di un elemento che contribuisce a rafforzare la verificabilità tecnica delle evidenze digitali prodotte.

Conclusioni preliminari

Le prime analisi svolte nelle ore successive al rilascio di DRIFTLinux restituiscono l’immagine di un progetto tecnicamente interessante e chiaramente orientato alle esigenze operative della Digital Forensics, operativo e concreto.

Nei prossimi giorni pubblicheremo un articolo dedicato con un’analisi più approfondita delle principali funzionalità, nel frattempo, vi invitiamo a scoprire il progetto sul sito ufficiale: driftlinux.org

IISFA Forum 2025 a Roma – Cybercrime, AI e Digital Forensics

forenser on 8 Dicembre 2025

cybercrime-artificialintelligence-digitalforensics-iisfa
locandina-cybercrime-artificialintelligence-digitalforensics-iisfa-1

Venerdì 12 dicembre 2025 si terrà, a Roma, presso il Centro Congressi Frentani Srl (in Via dei Frentani, 4, a pochi passi dalla Stazione Termini di Roma) il seminario “IISFA FORUM 2025 – Cybercrime, Artificial Intelligence & Digital Forensics” durante il quale i partecipanti avranno l’occasione di seguire interventi su Cybercrime, Artificial Intelligence & Digital Forensics.

La conferenza “IISFA Forum 2025 – Cybercrime, Artificial Intelligence e Digital Forensics”, organizzata dall’associazione IISFA, riunisce le principali istituzioni e professionisti italianiimpegnati nella sicurezza informatica, digital forensics e intelligenza artificiale per analizzare l’evoluzione delle minacce informatiche e il ruolo crescente dell’AI nelle attività investigative.

IISFA Forum 2025 a Roma - Programma dell'evento gratuito aperto a tutti

La mattinata è dedicata ad approfondire i trend nazionali sui cyber attacchi, le nuove forme di cybercrime e l’impatto delle tecnologie emergenti sulle indagini, grazie agli interventi di rappresentanti dell’Agenzia per la Cybersicurezza Nazionale, della Polizia Postale, dei Carabinieri, della Guardia di Finanza e di esperti del settore legale e forense. Due tavole rotonde approfondiscono i temi etici legati all’IA e la relazione tra criminalità informatica, social media e comunicazione giornalistica.

Nel pomeriggio, la conferenza si concentrerà su specifici argomenti d’informatica forense, con interventi dedicati allo spyhunting su dispositivi mobili, alle investigazioni digitali in ambito aziendale, ai nuovi reati informatici legati alla cybersecurity e all’IA, fino alle sfide della post-quantum security e all’evoluzione dei ransomware.

La giornata si conclude con un coinvolgente cyber forensics game, una simulazione pratica su un caso reale di analisi forense, che permette al pubblico di confrontarsi direttamente con metodologie e tecniche operative utilizzate nei moderni scenari investigativi.

I temi al centro dell’evento IISFA

locandina-cybercrime-artificialintelligence-digitalforensics-iisfa-2

Nel corso della giornata si alterneranno interventi dedicati a:

  • Cybercrime e nuove forme di criminalità informatica;
  • Intelligenza artificiale e impatti sulle attività investigative e difensive;
  • Ransomware e gestione degli incidenti;
  • Post-quantum security;
  • OSINT (Open Source Intelligence);
  • Digital Forensics in ambito giudiziario, aziendale e istituzionale.

L’intervento del nostro CEO Paolo Dal Checco

La società Forenser sarà presente all’IISFA Forum 2025 a Roma attraverso il CEO Paolo Dal Checco, che durante l’evento “Cybercrime, Artificial Intelligence e Digital Forensics” organizzato da IISFA – International Information Systems Forensics Association – parlerà di “Spyhunting su sistemi cellulari” raccontandone lo stato dell’arte.

locandina-cybercrime-artificialintelligence-digitalforensics-iisfa-3

Alle 14:30, infatti, il CEO di Forenser Paolo Dal Checco interverrà con una relazione dedicata a “Spyhunting sui sistemi cellulari: lo stato dell’arte“, durante la quale verranno affrontati:

  • le principali tecniche di individuazione di software spia e attività malevole sui sistemi cellulari;
  • gli strumenti di analisi forense utilizzati oggi per l’attività di spyhunting su smartphone;
  • le tipologie di copia forense di smartphone (logical, ADB backup, iTunes Backup, advanced logical, Full File System / FFS, physical) e il loro utilizzo nel rilevamento di malware
  • l’utilizzo dei log e dei dump (sysdiagnose, unified logs, shutdown.log, event log, crash log, bug report, logcat, tombstone, ANR, etc…) per rinvenire tracce delle infezioni da malware sui disposivi;
  • gli strumenti di estrazione dati, analisi e malware detection come Mobile Verification Toolkit (MVT), Android Quick Forensics, Sysdiagnose Parser;
  • le potenzialità della intelligenza artificiale nel rilevamento di malware e spy software;
  • l’analisi del traffico di rete come strumento di rilevamento di attività malevola di spy software su smartphone;
  • casi d’uso e scenari investigativi in cui l’analisi forense mobile è centrale per la ricostruzione dei fatti;
  • spunti operativi per professionisti che operano in ambito cybercrime, incident response e consulenza tecnica.

L’obiettivo del talk è fornire una panoramica aggiornata sullo stato dell’arte, con un taglio pratico e orientato alle esigenze di chi si occupa quotidianamente di investigazioni digitali su smartphone, in particolare in ambito di rilevamento malware e infezioni da trojan, captatori o spy software.

Locandina dell’evento IISFA Forum 2025 a Roma

L’evento rappresenta un’occasione di confronto tra professionisti del settore, condivisione di buone pratiche e aggiornamento sulle evoluzioni tecnologiche e normative.

Per tutti i dettagli sul programma, gli orari e i relatori, è disponibile la locandina ufficiale in formato PDF:

Locandina IISFA Forum 2025 a RomaDownload

Programma dell’evento IISFA Forum 2025 a Roma

L’evento IISFA Forum 2025 che si terrà a Roma venerdì 12 dicembre 2025 vede la partecipazione di numerosi professionisti del diritto, esperti d’informatica forense, personalità istituzionali e consulenti informatici forensi.

Ore 9:30 – Saluti di indirizzo

  • Gerardo Costabile – Presidente IISFA
  • Nunzia Ciardi – Vicedirettore Agenzia per la Cybersicurezza Nazionale
  • Amm. Gianluca Galasso – Direttore del Servizio Operazioni e gestione delle crisi cyber/CSIRT Italia – Agenzia per la Cybersicurezza Nazionale
    Trend nazionale dei cyber attacchi: lo stato dell’arte in Italia
  • Ivano Gabrielli – Direttore del Servizio Polizia Postale e per la Sicurezza Cibernetica
    Cybercrime e nuovi trend
  • Gen. Vincenzo Molinese – Comandante ROS Carabinieri
    Intelligenza Artificiale e attività investigative
  • Gen. Antonio Mancazzo – Comandante del Nucleo Speciale Tutela Privacy e Frodi Tecnologiche della Guardia di Finanza
    Cybercrime e follow the money: evoluzione e nuovi scenari
  • Stefano Mele – Partner, Head of Cybersecurity & Space Law Department, Gianni & Origoni
    Anatomia di un attacco ransomware: ricatti, psicologia e cryptoasset in attesa di una strategia italiana

Tavola rotonda
Intelligenza artificiale, etica e informatica forense

Partecipano:

  • Eugenio Albamonte (Direzione Nazionale Antimafia)
  • Giuseppe Corasaniti (Professore ordinario UniMercatorum)
  • Paolo Galdieri (Avvocato)
  • Mattia Epifani (Presidente ONIF)
  • Marco Calonzi (Direttivo IISFA)
  • Gianluca Boccacci (Presidente Cyber Actors)

Tavola rotonda
Cybercrime, social media e comunicazione giornalistica tra forma e sostanza

Partecipano:

  • Domenico Colotta (Assocomunicatori)
  • Arturo di Corinto (Giornalista professionista, Agenzia Cybersicurezza Nazionale)
  • Luigi Garofalo (Direttore responsabile Cybersecurity Italia)
  • Roland Kapidani (Red Hot Cyber)

Ore 13:30 – Pausa pranzo

Ore 14:30 – Sessione pomeridiana

  • Paolo Dal Checco – Consulente Informatico forense
    Spyhunting sui sistemi cellulari: lo stato dell’arte
  • Michela Carloni Gammon, Direttore Everbridge – Veronica Vacchi, Dinova
    Tutela aziendale, media investigation e open source intelligence
  • Stefano Aterno (Studio E-lex)
    I nuovi reati informatici nella cybersecurity e nell’intelligenza artificiale
  • Prof. Aniello Castiglione – Università di Salerno
    Post quantum security, evoluzione dei ransomware e complessità investigative
  • Cosimo de Pinto (Direttivo IISFA) & Salvatore Filograno (Direttivo IISFA)
    Cyber forensics game: simulazione con l’intervento del pubblico su un caso reale di analisi forense

Come partecipare alla conferenza IISFA Forum 2025 a Roma

L’evento è gratuito e aperto a tutti, non soltanto ai soci IISFA, sono quindi benvenuti professionisti della cybersecurity, esperti e consulenti di informatica forense, aavvocati, CTU informatici e CTP informatici che operano in procedimenti con evidenze digitali, responsabili IT, DPO, CISO e figure coinvolte nella gestione degli incidenti digitali.

Si ricorda che l’evento si terrà a Roma il 12 dicembre 2025, al Centro Congressi Frentani, in Via dei Frentani 4, a pochi passi dalla Stazione Termini di Roma: per partecipare è sufficiente registrarsi online su Eventbrite e presentarsi venerdì 12 dicembre 2025 presso la sede del congresso alle ore 9:30 per l’inizio dei lavori.

I posti sono limitati ma vi sono ancora alcune disponibilità, raccomandiamo di affrettarvi con la registrazione e di cancellare l’adesione in caso d’impossibilità di partecipare all’evento IISFA a Roma.

Informatica Forense e NIS2, un connubio indissolubile

forenser on 22 Ottobre 2025

Martedì 21 ottobre il CEO Fornser Paolo Dal Checco ha partecipato come docente al Seminario in FAD sincrona dal titolo “Informatica Forense e NIS2, un connubio indissolubile ma sottovalutato” durante il quale ha presentato i punti di contatto tra la direttiva NIS2 e la digital forensics, mostrando come il testo di legge possa essere letto alla luce di uno scenario nel quale l’informatica forense possa essere di supporto sia per la fase di prevenzione sia per quella di gestione dell’incidente informatico.

La giornata di corso sulla normativa NIS2, organizzata dal FOIM – Fondazione Ordine Ingegneri della Provincia di Milano – con Responsabile Scientifico l’Ing. Luca Reggiani, ha visto tra i docenti stimati professionisti che hanno illustrato ai discenti questioni legate alla cybersecurity, informatica forense, strumenti pratici, analisi dei rischi, compliance e standard.

NIS2 e Informatica Forense per Ordine Ingegneri Provincia di Milano

Programma del corso sulla NIS2 organizzato dal FOIM

Il programma del corso sulla NIS2, organizzato dalla Fondazione Ordine degli Ingegneri della Provincia di Milano è stato il seguente:

  • 14.28 | Collegamento alla piattaforma
  • 14.30 | Presentazione del seminario
  • 14.35 | NIS 2: ermeneutica della complessità, un approccio organizzativo integrato alla cybersicurezza – Giuseppe SERAFINI – Avv.
  • 15.10 | Informatica Forense e NIS2, un connubio indissolubile ma sottovalutato – Paolo DAL CHECCO – Consulente Informatico Forense
  • 15.45 | Question time
  • 16.00 | Strumenti pratici per l’implementazione dei prerequisiti NIS-2, ISO27001, GDPR – Alberto BENZONI – Fast-Group
  • 16.35 | Kill Risk: analisi dei rischi rispetto ai controlli (da ISO 27001 a NIST CSF passando per la NIS2) – Gianluigi ANGOTTI – Cons.
  • 17.10 | Recepimento NIS2 e armonizzazione cybersecurity: compliance, standard internazionali e impatti organizzativi – Roberto RE – Cons.
  • 17.45 | Question time
  • 18.00 | Conclusioni e chiusura seminario

Docenti del corso sulla normativa NIS2

I docenti del corso sulla Normativa NIS2 tenuto per la Fondazione Ordine degli Ingegneri della Provincia di Milano sono stati i seguenti:

  • Dott. Paolo Dal Checco, Consulente Informatico Forense
  • Ing. Gianluigi Angotti, CISO (Chief Information Security Officer)
  • Ing. Roberto Re, Consigliere dell’Ordine degli Ingegneri della Provincia di Milano
  • Avv. Giuseppe Serafini, Avvocato presso Studio Legale
  • Dott. Alberto Benzoni, Amministratore Delegato Eureka Srl

Cos’è la direttiva NIS2? 

La Direttiva NIS2 (Network & Information Systems Directive) è stata formalizzata nel 2022 e recepita in Italia con il D.lgs. 138/2024 in sostituzione della precedente direttiva NIS del 2018), ampliandone l’ambito e rafforzando i requisiti di sicurezza per le infrastrutture digitali.

La normativa, entrata in vigore il 16 ottobre 2024, mira ad armonizzare le misure di sicurezza informatica tra i Paesi dell’UE, potenziando la capacità di risposta delle aziende e prevenendo i rischi informatici.

La direttiva introduce una serie di obblighi per migliorare la sicurezza digitale, tra cui uniformare il livello di protezione informatica in tutti gli Stati membri, aumentare la robustezza attraverso requisiti più stringenti e sanzioni severe e preparare le aziende a fronteggiare attacchi informatici mediante piani di resilienza e continuità operativa. 

A chi è destinata la normativa NIS2? 

NIS2 non è destinata a tutti è applicabile ad alcuni settori critici come l’energia, i trasporti, la finanza, la sanità e le infrastrutture digitali, utilizzando un criterio che definisce l’applicabilità in base alla dimensione delle imprese. 

Le imprese soggette alla NIS2 devono adeguarsi a requisiti più dettagliati in tema di gestione del rischio, sicurezza della catena di fornitura e risposta agli incidenti. Inoltre, la normativa introduce una forte responsabilità dei manager, che impone ai dirigenti di adottare misure di sicurezza adeguate e di promuovere la formazione del personale.  

L’intervento di Paolo Dal Checco su NIS2 e Informatica Forense

L’intervento del CEO Forenser Paolo Dal Checco, nel corso sulla NIS2, è stato intitolato “Informatica Forense e NIS2: Un Connubio Indispensabile per la Sicurezza Sistemica” ed è stato dedicato all’importanza critica del legame tra Informatica Forense e la Direttiva NIS2, un binomio che, sebbene indissolubile, è ancora troppo sottovalutato.

In qualità di Consulente Informatico Forense e fondatore di Forenser Srl, forte di un’esperienza decennale sul campo e oltre 2.000 casi gestiti in ruoli tecnici e legali – esperienza maturata a partire Dottorato di Ricerca in Informatica focalizzato sulla crittografia e la sicurezza delle comunicazioni – il Dr. Dal Checco ha voluto sottolineare come la NIS2 imponga un radicale cambio di paradigma.

Non è più sufficiente limitarsi ad acquistare soluzioni tecnologiche; la normativa richiede infatti di dimostrare l’efficacia misurabile delle misure di sicurezza implementate, adottando un approccio multi-rischio che deve essere proporzionale al livello di rischio precedentemente valutato.

NIS2 e Compliance - digital forensics e informatica forense in aiuto

L’informatica forense o digital forensics si rivela essenziale non solo nella risposta agli attacchi, ma in ogni misura minima prevista dall’Articolo 24. Per esempio, è fondamentale per condurre una corretta Analisi dei Rischi, poiché solo l’analisi retrospettiva degli incidenti passati – inclusi quelli tentati o “mancati” – può fornire i dati necessari per questa valutazione. Essa rappresenta il campo di gioco principale nella Gestione degli Incidenti e nella verifica dell’integrità dei sistemi di Continuità Operativa, dove solo un’analisi approfondita può confermare che i backup non siano stati compromessi. Inoltre, l’analisi post-incidente è l’unica vera metrica per la Valutazione dell’Efficacia degli strumenti di logging, EDR o SIEM utilizzati, e risulta imprescindibile per rispondere alla domanda fondamentale in termini di sicurezza del personale: “Chi ha fatto cosa, quando e come?”.

NIS2 e questione temporale per i CISO - Informatica Forense per la gestione dell'incidente informatico

La sfida più grande si concentra tuttavia sulla gestione delle tempistiche stringenti dettate dall’Articolo 25. Dalla pre-notifica da inviare al CSIRT Italia entro 24 ore fino alla Relazione Finale Completa richiesta entro un mese, la pressione sui CISO è altissima. Questa relazione finale deve obbligatoriamente includere la Root Cause Analysis, ovvero l’identificazione precisa della causa originale che ha innescato l’evento dannoso. Ed è qui che emerge il punto cruciale della lezione: è impossibile identificare con certezza la root cause – come pare effettivamente richiesto dalla normativa NIS2 – senza condurre un’indagine approfondita di Informatica Forense o Digital Forensics.

In conclusione, la Direttiva NIS2 ci spinge verso un approccio olistico alla sicurezza che integra misure Tecniche, Organizzative e Operative; in questo scenario, i log di sistema e le procedure operative diventano la fonte primaria di prova. L’informatica forense, dunque, non è un’opzione, ma una necessità tecnica e legale imprescindibile per soddisfare gli obblighi normativi e garantire una protezione efficace dell’organizzazione in un contesto normativo che si focalizza sull’interruzione dei servizi essenziali e sull’impatto sistemico.

Sulle tracce dell’hacker dell’autoscuola con Le Iene e Forenser

forenser on 15 Ottobre 2025

Domenica 12 ottobre 2025 è andato in onda su Italia 1 la prima parte del servizio televisivo de Le Iene intitolato “Chi è l’hacker dell’autoscuola?”, condotto da Veronica Ruggeri.
Nel corso della puntata, il Dott. Paolo Dal Checco, CEO di Forenser Srl e consulente informatico forense per Le Iene, ha partecipato all’indagine come perito informatico, collaborando con la redazione per far luce su un complesso caso di cyberstalking, intrusione informatica e monitoraggio illecito delle comunicazioni digitali.

Un caso di hacking e stalking digitale

Il primo episodio del servizio de Le Iene racconta la vicenda di due dipendenti di una scuola guida – Andrea e Chiara – perseguitati da oltre un anno da un ignoto hacker che – attraverso tecniche di intrusione e sorveglianza digitale – ha compromesso sistemi informatici, intercettato conversazioni, inviato messaggi minatori e diffuso informazioni personali e contenuti privati.

Tra le modalità di attacco riscontrate nelle azioni portate avanti contro Chiara, Andrea e i loro genitori oltre che alcuni amici figurano:

  • l’accesso abusivo a dispositivi mobili e computer aziendali,
  • l’utilizzo di servizi di posta elettronica criptata come ProtonMail,
  • il controllo remoto di elementi fisici come la serranda automatizzata dell’autoscuola,
  • e il monitoraggio costante delle attività online e offline delle vittime tramite canali social, SMS, email e applicazioni di messaggistica.

L’intervento del team Forenser Srl

Nel corso del servizio de Le Iene sull’hacker dell’autoscuola parte I, il Dott. Dal Checco – affiancato da una parte del team tecnico di Forenser Srl, ha operato in qualità di consulente informatico forense per Le Iene, conducendo attività di:

  • ricognizione tecnica e valutazione delle superfici d’attacco,
  • copia forense di smartphone e PC con strumenti certificati (Oxygen Forensics Detective),
  • acquisizione forense di account cloud e social network,
  • analisi dei log di rete e dei metadati digitali nell’ambito di attività di network forensics e mobile forensics,
  • verifica di accessi anomali e potenziali compromissioni tramite tecniche di email forensics e digital profiling.

L’intervento ha consentito di cristallizzare le evidenze digitali e preservare la catena di custodia dei dati, garantendo la validità probatoria delle informazioni acquisite.

Metodologia di analisi forense

Per affrontare un caso così complesso, il team Forenser ha adottato un approccio multidisciplinare che combina diverse branche della digital forensics:

  • Mobile Forensics: estrazione e analisi forense di dispositivi mobili per individuare app di controllo remoto, spyware o tracce di sincronizzazioni cloud sospette;
  • Email Forensics: analisi degli header dei messaggi provenienti da domini cifrati, ricostruzione dei percorsi SMTP e correlazione temporale tra messaggi e attività sui dispositivi;
  • Social network forensics: ispezione dei log di accesso ai profili social network (in particolare Instagram) utilizzati dall’hacker per comunicare con le vittime;
  • OSINT e Digital Profiling: raccolta di informazioni pubbliche e tecniche per la ricostruzione dell’identità digitale dell’attaccante.

Una perizia informatica per fare chiarezza

Il caso dell’“hacker dell’autoscuola” resta aperto e tuttora oggetto di approfondimento tecnico. Le copie forensi acquisite saranno analizzate dal laboratorio Forenser Srl per la redazione di una perizia informatica forense completa, finalizzata a individuare la dinamica degli attacchi, la provenienza delle intrusioni e i potenziali responsabili.

Il Dott. Paolo Dal Checco ha sottolineato l’importanza, in situazioni simili, di affidarsi a professionisti qualificati in informatica forense in grado di intervenire tempestivamente, cristallizzare le prove digitali e fornire un supporto tecnico e giuridico utile alle autorità competenti.

Il video del servizio de Le Iene sull’hacker dell’autoscuola

La puntata “Chi è l’hacker dell’autoscuola?” – prima parte – è disponibile gratuitamente in streaming sul sito ufficiale de Le Iene (Mediaset) al seguente link con il servizio sull’hacker dell’autoscuola.

Quella che è andata in onda il 12 ottobre 2025 è la prima puntata di una serie che approfondirà la questione dell’hacker della autoscuola con il team Forenser e il Dott. Paolo Dal Checco che, come Perito Informatico per Le Iene, analizzeranno le evidenze digitali acquisite per tentare di arrivare a una soluzione all’evidente minaccia che stanno subendo i due dipendenti della scuola guida oltre che le loro famiglie.

Durante la seconda puntata della serie “Chi è l’hacker dell’autoscuola?” verranno mostrati ulteriori eventi e indizi utili per fornire ulteriori elemnenti di valutazione per comprendere chi possa celarsi dietro l’hacker che tormenta Chiara e Andrea da oltre un anno e mezzo, anche se come si vedrà l’identificazione dell’hacker della scuola guida è ancora lontana.

Chi è Forenser Srl

Forenser Srl è una società specializzata in informatica forense, consulenza tecnica, perizie informatiche e analisi di evidenze digitali per tribunali, avvocati, aziende e privati.
Il laboratorio opera su casi di cybercrime, data breach, frodi informatiche, analisi di e-mail, mobile forensics e investigazioni digitali, con metodologie conformi agli standard internazionali (SWGDE, NIST, ISO/IEC 27037) oltre che Italiani, come la Legge 48/2008 che prevede vincoli restrittivi su catena di custodia e modalità di acquisizione forense delle prove digitali.

Per approfondimenti o richieste di consulenza in ambito informatico forense, CTP informatiche, CTU informatiche, partecipazione ad attività di descrizione giudiziaria in fascicoli civili, sequestri o accertamenti tecnici irripetibili in fascicoli penali è possibile contattare Forenser Srl attraverso il modulo di contatto ufficiale oppure scrivendoci o telefonandoci al numero presente nella pagina dei contatti dello Studio d’Informatica Forense.

Verifica autenticità email e posta elettronica per Le Iene

forenser on 6 Ottobre 2025

Domenica 21 settembre 2025 è andato in onda il servizio dove il CEO Forenser Paolo Dal Checco ha contribuito, come Consulente Informatico Forense per Le Iene, a verificare l’integrità e l’autenticità di messaggi di posta elettronica prodotti dalla protagonista del servizio TV in un contesto nel quale la controparte ne disconosceva l’originalità dichiarandoli falsi e prodotti con Photoshop.

Verifica autenticità, integrità e originalità messaggi email di posta elettronica

Contattato come consulente informatico da Filippo Roma de Le Iene, Paolo Dal Checco ha eseguito la verifica di originalità e integrità di alcuni messaggi di posta elettronica, dimostrato come le mail fossero autentiche, originali, integre e provenienti dall’indirizzo di posta indicato nel campo del mittente.

Tali messaggi erano invece stati disconosciuti e dichiarati falsi e manipolati dalla controparte, senza però che ne fosse dimostrata la falsità e l’alterazione o manipolazione.

Avendo a disposizione le email in formato EML/MSG/TXT – o nel caso migliore potendo accedere direttamente alla mailbox sulle quali sono contenute – è invece possibile fare diversi tipi di analisi forensi basate su tecniche di “email forensics”, tra le quali:

1) il controllo della firma DKIM o ARC apposta dal server mittente su alcuni campi (es. mittente, destinatario, oggetto, data invio, etc…) e sul testo per verificare ad esempio autenticità del contenuto e del mittente;
2) il riscontro incrociato tra IMAP INTERNALDATE e IMAP UID per verificare eventuali attacchi di tipo Man in The Mail (MITM) con caricamento di “append” sul server email;
3) l’analisi della coerenza del MessageID con eventuali codifiche/timestamp o eventuali ID nel campo “In-Reply-To”;
4) la verifica del rispetto del protocollo DMARC da parte del server mittente;
5) l’accertamento circa la configurazione SPF impostata nella zona DNS del dominio mittente;
6) il riscontro incrociato nei vari messaggi del thread;
7) le verifiche sui timestamp in formato EpochTime apposti in varie parti dello header RFC822, così come nei separatori di campo;
8) ricostruzione del percorso SMTP nella catena dei Received by/from nell’header per la coerenza di IP, reverse DNS, timezone e delay;
9) analisi dei MIME boundaries e struttura interna multipart (testo, HTML, allegati, inline);
10) analisi forense degli allegati (es. PDF, Word, etc…) alla ricerca di dati EXIF che possono contenere autori, date o nomi rilevanti;
11) verifica circa ulteriori destinatari (TO, CC o CCN) della mail oggetto di analisi, dai quali potrebbero essere acquisite ulteriori copie per analisi parallele;
12) il controllo sugli X-Fields apposti dagli MTA.

Nel servizio in cui Paolo Dal Checco ha operato come perito informatico per Le Iene, è stato illustrato con un esempio pratico mostrato alla Iena Fabrizio Roma come per poter produrre una perizia informatica su mailbox e posta elettronica non è sufficiente una stampa cartacea o PDF ma è essenziale poter avere a disposizione anche la parte “nascosta” dei messaggi, ciò che chiamiamo “header” o “intestazione” RFC822 nella sua interezza e – quando possibile – poter acquisire tramite copia forense i messaggi direttamente dalla mailbox online.

Dal Checco - Perito Informatico per Le Iene nel servizio su analisi originalita posta elettronica

Il servizio TV andato in onda domenica ovviamente è molto più ampio e la parte che il Dr. Dal Checco ha svolto in qualità di perito informatico forense per Le Iene è limitata alla verifica tramite tecniche d’informatica forense dei messaggi di posta elettronica.

Per chi fosse interessato, il video è disponibile integralmente e gratuitamente al link con la puntata delle Iene su email forensics sul sito Mediaset.

Seminario ONIF 2025 sull’informatica forense a Bari

forenser on 2 Ottobre 2025

Per chi fosse interessato, segnaliamo il Seminario ONIF 2025 sulla informatica forense, che si terrà a Bari venerdì 17 ottobre 2025, nella splendida cornice di Villa De Grecis.

La 9a edizione dell’evento annuale dell’Osservatorio Nazionale d’Informatica Forense (ONIF) è dedicata a Operatori delle Forze dell’Ordine, Giuristi e consulenti informatici forensi oltre che a personalità istituzionali e professionisti del.

Durante l’evento si parlerà della survey ONIF 2025, d’intelligenza artificiale applicata alla video forensics, di DSPM e DLP, di forensys, il gestionale per l’informaticoforense moderno, di competenze e certificazione di processi e procedure informatiche forensi, di dispositivi IIoT, di threat intelligence e NIS2, di bonifiche elettroniche e webforensics con sponsor e relatori di altissimo livello.

Osservatorio Nazionale Informatica Forense – Bari 2025

Il programma dell’evento ONIF a Bari del 17 ottobre 2025 è il seguente:

08:30 – 09:30
Registrazione partecipanti

09:30 – 10:15
Introduzione e saluti istituzionali
Mattia Epifani (Presidente ONIF)
Moderazione: Nanni Bassetti
Direzione eventi: Pasquale Di Tolla

10:15 – 10:45
Presentazione Survey ONIF 2025
Alessandro Fiorenzi

10:45 – 11:15
Utilizzo dell’intelligenza artificiale per la super risoluzione di video digitali a scopo forense. È una buona idea? Un caso pratico: riconoscimento di volti
Massimo Iuliani

11:15 – 11:45
Pausa caffè

11:45 – 12:15
DSPM e DLP: La sinergia vincente per la sicurezza dei dati
Alessandro Fontana (Netskope)

12:15 – 12:45
Forensys: il gestionale per l’informatico forense moderno
Antonio Roberto Consalvi

12:45 – 13:15
Dallo smartphone allo smartwatch: nuove frontiere nell’analisi forense dei dispositivi mobili
Diego Cassini (Compelson)

13:15 – 14:30
Pausa pranzo

14:30 – 15:00
L’erogazione di servizi di digital forensics di qualità: tra esigenza di risorse, competenze e certificazione di processi e procedure
Michele Ferrazzano

15:00 – 15:15
DeepPlate: un utilizzo intelligente dell’intelligenza artificiale
Marco Fontani (Amped Software)

15:15 – 15:30
Inside the breach: analisi forense, threat intelligence e risposta operativa come architettura di difesa tra obblighi NIS2 e contesto reale
Claudio Tinelli

15:30 – 16:00
Digital Forensics per dispositivi IIoT (Industrial Internet of Things): sfide, prospettive e casi reali
Fabrizio Giuliani

16:00 – 16:15
Pausa

16:15 – 16:30
Magnet One: la nuova era delle indagini digitali
Luigi Portaluri, MBA (Magnet Forensics)

16:30 – 16:45
Le Bonifiche Elettroniche a supporto di controspionaggio industriale. M2 Bridge New, apparato innovativo per rilevare Software Spy su Cellulari e Tablet
Marco Muratori (MG Extreme)

16:45 – 17:00
Ottimizzare gli strumenti investigativi per superare le sfide digitali
Oliver Gheorghe (Solutions Engineer Cellebrite)

17:00 – 17:30
Web Forensics: Presentazione della prima Certificazione CWFE per l’Acquisizione di Contenuti Online
Alessandro Rella

17:30 – 17:45
Domande e termine lavori

Chi desidera la versione PDF può visionare in preview o scaricare la locandina dell’evento ONIF a Bari dal seguente link.