SSH ramdisk su iPhone XS con iOS 18.7.9: la chain completa fino al file system

forenser on 31 Luglio 2026

In un precedente articolo pubblicato pochi giorni fa avevamo raccontato il primo stadio della catena: la ricostruzione dell’exploit BootROM usbliter su un iPhone XS di test, con il dispositivo che transitava in modalità PWND DFU, lo stato di accesso più profondo ottenibile prima che qualsiasi componente del sistema operativo Apple venga caricato. Era la prima porta della catena. Oggi documentiamo il completamento dello stadio successivo: il boot di un ramdisk SSH sull’iPhone XS con iOS 18.7.9 installato, l’accesso al filesystem del dispositivo via sessione root, e la conferma che la catena costruita è riproducibile end-to-end.

Il risultato non è un jailbreak – il dispositivo torna alla condizione di partenza al primo reboot, senza modifiche persistenti alla memoria flash – ma è la conferma che la metodologia documentata dalla ricerca pubblica sui SoC A12 è oggi praticabile anche su iOS 18.7.9, la release stabile più recente disponibile al momento della verifica.

Sessione SSH sull’iPhone XS con ramdisk attivo. Il banner mostrato è quello del nostro ambiente di ricerca; la shell root è sul dispositivo, l’accesso avviene via port forwarding USB. ECID e nomi identificativi sono stati oscurati per motivi di privacy

Dove eravamo: lo stadio uno

Nell’articolo precedente avevamo descritto la fase iniziale della catena: il caricamento sull’iPhone XS di un handler personalizzato all’interno della BootROM, tramite il payload dell’exploit usbliter distribuito attraverso un Raspberry Pi Pico configurato come ponte USB. Il risultato di quella fase era la modalità PWND DFU: il device visibile al sistema operativo host come dispositivo Apple in DFU, ma con un handler custom installato nella BootROM che esponeva due opcode aggiuntivi (CUSTOM_DEMOTE e CUSTOM_BOOT). Il dispositivo restava però in una condizione di attesa: il payload era iniettato, ma nulla girava ancora in esecuzione vera e propria oltre alla BootROM stessa.

Lo stadio uno è la porta d’ingresso, ma non è utile in sé. Serve un secondo stadio che faccia partire un ambiente controllato dall’operatore – un iBoot patchato che accetti immagini non firmate, un kernel patchato per disattivare i controlli di integrità, un ramdisk custom che contenga gli strumenti di acquisizione e analisi. È questo che abbiamo costruito nei giorni successivi.

L’ecosistema di riferimento: il progetto ICH

La ricerca pubblica su A12/A13 si è consolidata negli ultimi mesi attorno a un ecosistema di repository su GitHub che coprono i diversi livelli della catena: il firmware per il microcontrollore che esegue l’exploit iniziale, il toolkit di post-exploitation con le primitive di lettura/scrittura sulla BootROM, i patchfinder che identificano gli offset corretti nel kernel e nell’iBoot per la versione di iOS in uso, gli script di orchestrazione che assemblano l’insieme in una procedura eseguibile.

Per la costruzione del bootchain patchato – in particolare per la patch dell’iBoot che consente il caricamento delle immagini firmware non firmate da Apple, per la patch del kernel che disabilita AMFI (Apple Mobile File Integrity) e i controlli di debug, e per l’assemblaggio del ramdisk custom che permette l’esecuzione del kernel patchato – ci siamo basati sul progetto open source ICH_A12_plus_Ramdisk, sviluppato dal ricercatore Pa7r0n e disponibile pubblicamente su GitHub all’indirizzo github.com/Pa7r0n/ICH_A12_plus_Ramdisk. Il progetto automatizza l’intera fase di build del bootchain per SoC A12 e A13 e per iOS dalla versione 17 alla 27, integra i patchfinder di riferimento, gestisce l’estrazione parziale dei firmware dall’IPSW ufficiale Apple e produce un bootchain firmato con il certificato IM4M generico per l’A12.

Il progetto richiede un ambiente macOS Apple per la fase di build, perché alcuni strumenti di manipolazione dei formati di firmware Apple (IMG4, IM4M, wrapping dei coprocessori) esistono solo come binari Mach-O nativi. La fase di flash del microcontrollore e la sessione di boot successiva possono avvenire da qualsiasi macchina con libimobiledevice funzionante.

L’iPhone XS di test durante la fase di boot del ramdisk. Sullo schermo compare lo sfondo nero (bgcolor) e il logo pre-registrato del progetto: sono i segnali visibili dell’iBoot Recovery che risponde ai comandi. Poco dopo il kernel patched viene lanciato e dropbear inizia ad accettare connessioni SSH

La catena tecnica in sintesi

La sequenza documentata e verificata sul nostro iPhone XS è composta da tre fasi principali. Ogni fase richiede il completamento della precedente e non è persistente al reboot del device: questa è una caratteristica desiderabile per un’attività di ricerca forense, perché garantisce che l’intervento sull’oggetto in analisi sia limitato alla sessione corrente.

Fase 1 – Applicazione dell’exploit BootROM (PWND DFU)

Il dispositivo, portato manualmente in modalità DFU, viene connesso a un Raspberry Pi Pico 2 (microcontrollore RP2350) preventivamente programmato con il firmware usbliter. Il Pi Pico innesca la vulnerabilità nel controller USB della BootROM A12 e inietta lo shellcode custom. In circa 700 millisecondi il dispositivo è in stato PWND DFU: il descrittore USB espone la stringa aggiuntiva PWND:[usbliter8] che conferma il buon esito dell’iniezione. Il dispositivo viene ora scollegato dal Pi Pico e riconnesso direttamente al computer di lavoro tramite un cavo Lightning con connettore USB-A.

Fase 2 – Boot di un iBoot patchato in modalità Recovery

Dal computer di lavoro il tool usbliter8ctl (script Python distribuito con l’ecosistema di riferimento) invia al dispositivo un iBoot personalizzato – costruito nella fase di build dal progetto ICH – tramite l’opcode CUSTOM_BOOT esposto dall’handler installato nella BootROM. L’iBoot personalizzato contiene una patch chirurgica al validatore image4 (due istruzioni ARM64 sostituite in un punto identificato dinamicamente dal patchfinder) che permette il caricamento di immagini firmware successive non firmate da Apple. Il device passa dalla modalità DFU alla modalità Recovery, riconoscibile perché libimobiledevice ora vede il dispositivo con la stringa MODE: Recovery invece di MODE: DFU.

Fase 3 – Caricamento della catena di boot completa e avvio del kernel

All’iBoot in modalità Recovery vengono ora inviati, nell’ordine documentato dal progetto ICH: il DeviceTree, il trustcache, il ramdisk contenente dropbear e gli strumenti di analisi, il kernel patchato (con le due patch AMFI e debugger applicate dal patchfinder Leeksov), e i firmware dei coprocessori (AOP, ANE, AVE, ISP, GFX, SIO) necessari alla corretta inizializzazione del bus USB nel kernel. Al termine il comando bootx innesca l’esecuzione del kernel patchato, che monta il ramdisk come rootfs, lancia il minimo indispensabile di userspace e avvia dropbear in ascolto sulla porta 22.

Log di esecuzione della catena di boot completa sul terminale del computer di lavoro. Si vedono, in ordine, l’invio dell’iBoot al dispositivo tramite CUSTOM_BOOT, la comparsa della modalità Recovery, il caricamento sequenziale dei firmware dei coprocessori, il DeviceTree, il trustcache, il ramdisk, il kernel e l’invocazione

Il momento della verità: la sessione SSH

Terminata la fase di boot, il dispositivo continua a essere visibile al computer di lavoro come dispositivo USB, ma questa volta il suo endpoint di rete è servito dal kernel appena caricato – non più dalla BootROM o dall’iBoot. Un port forwarding USB tramite iproxy (strumento standard di libimobiledevice) espone la porta 22 del dispositivo su una porta locale del computer, e da lì una comune sessione ssh apre la shell root sul telefono. La password è quella standard del ramdisk di ricerca – alpine – che rispetta la convenzione storica dei jailbreak Apple da oltre quindici anni.

Il primo comando eseguito sulla shell è mount_ich, uno strumento distribuito con il ramdisk che monta in un colpo solo tutti i filesystem del dispositivo: il volume di sistema (sealed system snapshot, sola lettura per design a partire da iOS 15), il volume Dati utente (contrassegnato APFS con flag protect, ovvero con Data Protection attiva at rest), il volume Preboot, il volume xART. A questo punto abbiamo una vista completa della struttura del filesystem del dispositivo, e – a livello di sistema operativo – l’accesso più profondo ottenibile senza modificare permanentemente il dispositivo.

Cosa vediamo e cosa non vediamo

Il fatto che i filesystem siano montati non implica che tutti i loro contenuti siano leggibili in chiaro. iOS applica la sua protezione dati a livello di singolo file, distinguendo quattro classi di protezione: dalla classe A (“Complete”, decifrabile solo quando il dispositivo è sbloccato dall’utente) alla classe D (“NoProtection”, decifrabile senza input utente perché la chiave è derivata solo dall’UID hardware). Nella condizione di ramdisk boot post-DFU il Secure Enclave non è stato coinvolto nel processo di autenticazione utente e non ha derivato le chiavi di classe A, B e C: i file appartenenti a queste classi restano cifrati a livello di storage, e la loro apertura dal ramdisk restituisce Operation not permitted.

Ciò che possiamo ottenere adesso: acquisizione BFU

Nello stato attuale della catena la nostra postazione è in grado di eseguire un’acquisizione di tipo BFU (Before First Unlock) del dispositivo: i file di classe D – che comprendono la struttura del sistema operativo, i log di sistema, i database diagnostici, un numero non trascurabile di database applicativi non protetti da Data Protection e le cache condivise – sono immediatamente leggibili e possono essere copiati bit-a-bit dal dispositivo attraverso la sessione SSH. È lo stesso livello di accesso che gli strumenti commerciali di acquisizione full file system offrono in modalità BFU e rappresenta il risultato utile per una parte rilevante dei casi di analisi che entrano nel nostro laboratorio – in particolare quando la richiesta operativa riguarda dati di sistema, log applicativi, artefatti di rete o ricostruzione di sequenze temporali.

Ciò che non escludiamo: dialogo con il Secure Enclave (AFU-equivalent)

L’accesso ai file di classe A, B e C – che comprendono la maggior parte dei database delle app di terze parti, gli attachment delle chat, il keychain e altri artefatti tipicamente rilevanti in ambito investigativo – richiede la comunicazione con il Secure Enclave dal kernel patchato attraverso l’interfaccia IOKit AppleSEPKeyStore. Quando la password del dispositivo è nota all’operatore (perché comunicata dal titolare, come avviene di frequente nelle attività di consulenza tecnica di parte, o autorizzata dal collegio giudicante), il processo consiste nel fornirla al Secure Enclave via chiamata IOKit, ricevere in risposta le chiavi di classe derivate e passare queste ultime al driver APFS del kernel per la decifratura on-the-fly dei file. Non è una capacità che possediamo oggi sul nostro laboratorio, ma non è nemmeno un obiettivo di ricerca esplorativa: è un lavoro di ingegneria mirata sopra una base già consolidata, con un margine di tuning ragionevole per portarlo a compimento.

A conferma della praticabilità dell’approccio, il progetto pubblico usbliter8-fun (github.com/34306/usbliter8-fun) documenta una catena end-to-end funzionante su iPhone 11 Pro con iOS 27 beta che va ben oltre il ramdisk SSH: include patch al kernel per bypassare le protezioni AMFI e i controlli di trust, il dialogo con il Secure Enclave per il boot del sistema operativo completo, e il ripristino di una condizione di device operativo con SpringBoard funzionante e SSH persistente. Il progetto non è direttamente riutilizzabile sul nostro iPhone XS – l’A13 e l’A12 hanno offset kernel diversi, iOS 27 introduce strutture di sicurezza (SPTM, TXM) assenti in iOS 18, e alcune scelte progettuali di quel progetto sono incompatibili con l’uso forense che ci interessa – ma dimostra che la metodologia è consolidata e che l’estensione al nostro contesto è una questione di porting mirato e non di ricerca da zero.

Prossimi passi

Il traguardo del ramdisk SSH funzionante rappresenta un punto di consolidamento significativo della catena, ma non è il traguardo finale della ricerca. Restano da affrontare almeno tre aspetti di rilievo per l’applicabilità operativa in ambito forense:

  • L’implementazione del dialogo con il Secure Enclave per lo sblocco delle chiavi di classe A, B e C, condizione necessaria per accedere ai file protetti da Data Protection quando la password del dispositivo è nota all’operatore o comunicata al collegio giudicante.
  • L’automazione della procedura di acquisizione bit-a-bit dei volumi APFS del dispositivo, con generazione degli hash di integrità della catena di custodia e produzione di un’immagine in formato standard per l’analisi successiva con strumenti di parsing forense.
  • L’estensione della metodologia al SoC A13 (iPhone 11, 11 Pro, iPhone SE 2020) e alle versioni più recenti di iOS su A12/A13, sulla base della ricerca pubblica in corso da parte della comunità internazionale.

Continueremo a documentare l’attività man mano che i risultati saranno consolidati. Le condizioni per una loro applicabilità in un contesto operativo – con tutte le garanzie di documentazione, riproducibilità e attendibilità che la prova digitale richiede – sono ora considerevolmente più vicine di quanto lo fossero pochi mesi fa.

Exploit BootROM su iPhone XS: la prima catena e il progetto usbliter

forenser on 26 Luglio 2026

Nel mondo dell’informatica forense, esiste un livello di accesso che i vendor delle principali piattaforme di acquisizione full file system utilizzano per estrarre dati che nessuna procedura di backup logico può raggiungere: le chat cancellate, i keychain, i database SQLite delle app di terze parti, i file di configurazione, gli attributi di sistema.

Per gli iPhone dotati di SoC dalla famiglia A11 in giù, la porta d’ingresso a questo livello passa da una vulnerabilità hardware immutabile presente nella BootROM Apple. Per l’A12 – il chip degli iPhone XS, XR e delle prime generazioni di iPad Pro 2018 – la vulnerabilità esiste, ma la sua catena di sfruttamento è considerevolmente più complessa.

Il team Forenser ha recentemente ricostruito la prima parte di questa catena su un iPhone XS di test. In questo articolo raccontiamo cosa siamo riusciti a fare, quale metodologia abbiamo seguito, quale contesto internazionale si sta muovendo intorno a questo genere di ricerca e – soprattutto – cosa questo apre in termini di prospettive per l’acquisizione forense di dispositivi mobili di generazione recente.

Il punto di partenza: BootROM e checkm8

Ogni iPhone, all’accensione, esegue un piccolo pezzo di codice fisicamente scritto sul silicio del processore: la BootROM. È il primo software che gira sul dispositivo, letteralmente immutabile perché scolpito nel chip durante la fabbricazione. Non può essere aggiornato con un aggiornamento di iOS; non può essere modificato nemmeno da Apple. Se contiene un difetto, quel difetto resta lì per tutta la vita del dispositivo.

Nel 2019 il ricercatore axi0mX ha pubblicato checkm8, un exploit che sfrutta proprio una vulnerabilità nella BootROM di tutti gli SoC Apple dall’A5 all’A11. Da allora, checkm8 è diventato la base di tutti i principali strumenti di jailbreak permanente (checkra1n, palera1n) e delle metodologie forensi impiegate dai vendor commerciali per l’acquisizione full file system. Nulla di ciò che Apple ha rilasciato successivamente – nemmeno le patch di iOS 18 – può neutralizzarlo su quei dispositivi.

Nota importante: la vulnerabilità nella BootROM non è risolvibile a livello di hardware perché il codice è fisicamente immutabile. Apple può tuttavia introdurre, nelle release successive di iOS, mitigazioni a livello di kernel, iBoot, Secure Enclave e stack di boot che rendono lo sfruttamento pratico della vulnerabilità progressivamente più complesso – richiedendo catene di exploit più articolate per raggiungere gli stage successivi. La porta d’ingresso della BootROM resta quindi aperta in perpetuo, ma l’accesso effettivo ai dati sulle release iOS più recenti non è né automatico né immediato.

Gli iPhone XS/XR/iPad Pro 2018 utilizzano il SoC A12 (T8020). Sono affetti dalla stessa famiglia di vulnerabilità, ma con condizioni di sfruttamento diverse e considerevolmente più delicate. Per anni non è esistito uno strumento pubblico stabile che funzionasse su A12 con la stessa semplicità di checkm8 sui chip precedenti.

Il progetto usbliter

Alcuni mesi fa, il gruppo di ricerca Paradigm Shift ha pubblicato un progetto denominato usbliter (dal nome del suo componente principale, usbliter8): una catena di exploit simile a checkm8 specificamente adattata all’A12/A13, distribuita insieme al codice sorgente su GitHub e accompagnata da un articolo tecnico sul loro sito. Il progetto includeva:

  • Un firmware da caricare su un microcontrollore Raspberry Pi Pico, che si comportava come ponte USB tra PC e iPhone
  • Il codice dell’exploit vero e proprio, che sfrutta un difetto nel controller USB DWC2 della BootROM A12
  • Uno shellcode che, una volta iniettato, trasforma la modalità DFU standard dell’iPhone in una modalità pwned (PWND DFU), stato che espone capacità estese non altrimenti disponibili
  • Un ramdisk SSH precompilato per il boot successivo su versioni iOS meno recenti
Il progetto usbliter sul profilo github di Paradigm Shift prima della rimozione
Il progetto usbliter come appariva sul repository GitHub di Paradigm Shift prima della sua rimozione.

Nella giornata di ieri, 25 luglio 2026, l’intero materiale è stato rimosso: sia l’articolo pubblicato sul sito del gruppo, sia il repository GitHub. Le motivazioni non sono state comunicate pubblicamente ma è chiaro che le copie del codice sono rimaste disponibili presso chi le aveva già scaricate prima della rimozione.

Paradigm Shift - Introducing usbliter8
L’articolo di Paradigm Shift che descriveva il progetto, così come appariva prima della rimozione avvenuta il 25 luglio 2026.

Oggi la pagina risulta rimossa e il contenuto non è più accessibile, come si può notare accedendo alla URL pubblica precedentemente linkata in numerosi articoli.

Paradigm Shift - Introducing usbliter8 - Removed page
La medesima pagina sul sito Paradigm Shift, non più raggiungibile.

L’exploit riuscito sul nostro iPhone XS

Per verificare quanto riportato nell’articolo, il team Forenser ha condotto l’attività di ricerca su un iPhone XS utilizzato ai fini di studio (identificativo hardware iPhone11,2 D321AP) con installato iOS 18.7.9, la versione piu recente disponibile al momento della verifica. La documentazione del progetto usbliter raccomandava esplicitamente l’uso di un Raspberry Pi Pico 2 – la seconda generazione del microcontrollore – motivando la scelta con maggiore stabilità dell’exploit e possibilità di supportare timing più aggressivi.

Nell’articolo sul sito web – ora rimosso – erano segnalati come compatibili anche altri microcontrollori di fascia analoga (RP2040 su schede alternative, alcune varianti STM32).

Raspberry pi pico utilizzato per testare l'exploit usbliter8
Raspberry pi pico utilizzato per testare l’exploit usbliter8

Nel nostro caso, nell’attesa della consegna di un microcontrollore tra i segnalati, avevamo a disposizione soltanto un Pi Pico di prima generazione (Pico 1 W, basato su RP2040). I primi tentativi di exploitation non davano esito: il dispositivo non transitava in stato PWND DFU e il descrittore USB restituito da libirecovery non mostrava la stringa PWND:[usbliter8] che avrebbe confermato la riuscita dell’exploit. Dopo alcuni cicli di verifica sul timing dei segnali e sui parametri del firmware caricato sul Pico, l’exploit ha iniziato a funzionare in modo affidabile anche sull’hardware di prima generazione.

Expolit checkm8 usbliter8 PWND success
Il descrittore USB dell’iPhone XS con l’exploit checkm8/usbliter8 attivo. La presenza della stringa PWND:[usbliter8] a fianco del tag SRTG:[iBoot-3865…] (identificativo della BootROM A12) conferma il buon esito dell’iniezione. Il codice ECID è stato oscurato per motivi di privacy.

Il risultato è stato positivo su prima generazione, ma segnaliamo che il Pico 2 resta la scelta preferibile per chi voglia partire da zero: la maggiore affidabilità dei timing riduce il numero di tentativi necessari.

Cosa significa “PWND DFU”: lo stage uno di un exploit BootROM

Un exploit BootROM completo si compone di più stage eseguiti sequenzialmente: ciascuno prepara le condizioni per il successivo, e ciascuno rappresenta un livello di accesso incrementalmente più profondo. Lo stage inizialmente ottenuto – quello che abbiamo raggiunto sul nostro iPhone XS con usbliter – è lo stage uno, ed è il più importante dell’intera catena.

In termini astratti, uno stage uno di exploit BootROM è il punto in cui l’attaccante – o il ricercatore, o l’operatore che utilizza uno strumento di acquisizione forense – ha già iniettato il proprio codice di controllo nella BootROM del dispositivo, prima ancora che qualsiasi componente del sistema operativo venga caricato. Da questa posizione:

  • La catena di firma Apple è aggirabile dallo stage successivo: si può caricare un iBoot personalizzato, un kernel modificato, un ramdisk arbitrario, purché si conoscano i passaggi tecnici corretti
  • Le protezioni introdotte da iOS sono ininfluenti, perché nessun componente di iOS è ancora stato eseguito: né AMFI, né Secure Enclave in modalità produzione, né i controlli TXM (Trusted Execution Monitor) introdotti nelle versioni più recenti
  • Il device è in uno stato “tethered”: ogni operazione richiede il PC e la catena di boot personalizzata, senza modifiche persistenti alla memoria flash del dispositivo se non esplicitamente volute – condizione fondamentale per la preservazione della prova digitale in ambito forense
  • Non è un caso che questo genere di accesso sia impiegato dalle piattaforme di acquisizione full file system utilizzano internamente per estrarre i dati dagli iPhone di generazione compatibile. La differenza tra un vendor commerciale (che vende la soluzione a decine di migliaia di euro per licenza annua) e un ricercatore che documenta lo stesso stage è solo l’ingegneria – non l’informazione tecnica di base, che è ampiamente disponibile nella letteratura di sicurezza pubblica sin dal 2019 (CVE-2019-8900 – Apple Security Advisories).

Il valore dello stage uno non risiede tanto in quello che permette di fare da solo – il device connesso in PWND DFU non fornisce ancora accesso ai dati utente – quanto nel fatto che rende possibile ogni stage successivo. Da questa posizione, con il tempo e la competenza necessari, si può in linea di principio arrivare a:

  • Il caricamento di un iBEC (iBoot Extended Console) personalizzato, in grado di accettare firmware non firmato da Apple
  • Il boot di un kernel iOS modificato per disattivare i controlli di integrità
  • Il montaggio di un ramdisk contenente strumenti di estrazione dati (SSH, tar, sqlite, keychain dumper)
  • L’accesso completo al file system del dispositivo, sia partizione di sistema che dati utente, incluse le sezioni normalmente cifrate dopo il primo unlock
  • L’estrazione delle chiavi crittografiche del keychain

È lo stesso schema che, con implementazioni diverse, viene utilizzato da anni per gli iPhone con SoC A7-A11. Portarlo alla generazione A12 è la sfida attualmente aperta.

Il panorama internazionale

La ricerca in questo ambito è in fermento. Nella medesima giornata in cui Paradigm Shift rimuoveva il proprio progetto, è comparso su GitHub un nuovo repository — usbliter8-fun a cura dell’utente 34306 — che documenta una catena analoga per iPhone 11 Pro (SoC A13 T8030) su iOS 27 beta. Il progetto include patch per iBSS, iBEC, kernel e TXM, oltre a un TSS proxy per la personalizzazione dei firmware tramite blob salvato.

Repository 34306 usbliter8-fun su GitHub
Il repository 34306/usbliter8-fun su GitHub, che documenta una catena di exploit funzionante su iPhone 11 Pro con iOS 27 beta. Un progetto strutturalmente affine al nostro caso, con adattamenti specifici per l’A13 e il firmware corrente della beta pubblica.

Il progetto 34306 non è direttamente riutilizzabile sul nostro iPhone XS: l’A13 e l’A12 hanno offset diversi, e iOS 27 introduce nuove strutture crittografiche assenti in iOS 18, ma conferma che l’approccio è valido e che la comunità di ricerca sta attivamente lavorando su queste piattaforme.

Il repository resta pubblicamente accessibile al momento della pubblicazione di questo articolo. Il codice è distribuito con avvertimenti espliciti sui rischi di corruzione del Secure Enclave, del passcode, delle credenziali WiFi e del baseband: motivo per cui – come per ogni operazione di questo tipo – la ricerca deve essere condotta esclusivamente su dispositivi dedicati e mai su device operativi.

Prospettive per l’acquisizione forense

Se e quando la catena sarà completa sul nostro laboratorio, le possibilità applicative in ambito forense sono considerevoli. Un iPhone XS con ultima versione di iOS installata, rappresenta ancora una porzione significativa dei dispositivi che entrano regolarmente nei nostri casi come oggetto di analisi. Le capacità che uno stage completo abiliterebbe includono:

  • Acquisizione full file system senza dipendere da tool commerciali di terze parti, con la possibilità di documentare integralmente ogni passaggio della procedura
  • Estrazione del keychain e delle credenziali applicative, oggi non ottenibili con backup logico via libimobiledevice
  • Recupero di chat cancellate e altri artefatti disponibili solo dai database SQLite completi, non nella loro versione backup
  • Analisi live del dispositivo in modalità tethered per ricerca di malware persistente, con visibilità sul filesystem, sui processi e sui log a livelli non altrimenti raggiungibili
  • Preservazione della prova con controllo totale sui passaggi eseguiti e ripetibilità dell’operazione documentabile

Non è un obiettivo alla portata di ogni operatore, e non lo è ancora nemmeno per noi in questo momento: siamo alla prima porta della catena, con davanti diversi stage da consolidare. Ma la strada è tracciata, e la letteratura disponibile – sia quella pubblica sia quella oggi rimossa ma già distribuita – è sufficiente per proseguire.

Considerazioni finali

Il team Forenser sta proseguendo – ovviamente per fini accademici e scientifici – l’attività di ricerca sui stage successivi per verificare quali sono le vulnerabilità dei sistemi e le potenzialità in ambito informatico forense.

Ogni progresso viene documentato internamente con criteri di riproducibilità che riteniamo essenziali quando si opera in ambito forense: nessun passaggio deve essere frutto di tentativi non tracciabili, nessuna patch deve essere applicata senza comprenderne il razionale, nessun test deve avvenire su dispositivi che non siano stati preventivamente designati come sacrificabili per la ricerca.

Il valore di questa attività non risiede in un jailbreak per finalità di modifica del dispositivo – ambito su cui non operiamo – ma nella comprensione tecnica di uno strato del sistema iOS che è pubblicamente documentato ma poco praticato al di fuori dei vendor commerciali.

Comprendere direttamente come funziona lo stage BootROM di un iPhone A12 significa poter valutare, in casi reali, la qualità delle acquisizioni prodotte da terzi, individuare eventuali artefatti introdotti dagli strumenti utilizzati e – nei casi in cui sia strettamente necessario – condurre l’acquisizione in modo indipendente, con piena documentazione tecnica della catena di custodia digitale.

Aggiorneremo il nostro sito con i risultati man mano che i vari stage saranno consolidati.

La Prova Digitale al Corso Biennale dell’Avvocato Penalista

forenser on 24 Maggio 2026

Nel corso della lezione del 23 maggio 2026 del I Corso Biennale di Specializzazione dell’Avvocato Penalista, organizzato dalla Scuola UCPI di Roma, il Prof. Avv. Marco Pittiruti e il consulente informatico forense e CEO Forenser Dr. Paolo Dal Checco hanno affrontato uno dei temi oggi più delicati del processo penale: la gestione della prova digitale, con particolare riferimento alle perquisizioni e ai sequestri probatori informatici.

L’incontro ha messo in evidenza come l’evoluzione tecnologica abbia profondamente modificato il modo di svolgere le indagini penali. Smartphone, computer, cloud, account online e sistemi di messaggistica rappresentano ormai archivi completi della vita personale e professionale di ogni individuo. Di conseguenza, ogni attività di acquisizione forense comporta inevitabilmente un impatto molto significativo sui diritti fondamentali della persona sottoposta a indagine.

La prova digitale non è una “prova perfetta”

Nel suo intervento introduttivo, il Prof. Marco Pittiruti ha evidenziato come una parte della giurisprudenza abbia per lungo tempo considerato la prova digitale quasi come una prova “autoevidente”, affidabile per definizione e quindi assimilabile a un semplice documento ai sensi dell’art. 234 c.p.p.

Secondo Pittiruti, questa impostazione è ormai superata. Il dato informatico presenta infatti caratteristiche peculiari: è immateriale, facilmente alterabile, duplicabile e spesso estremamente promiscuo, poiché all’interno dello stesso dispositivo convivono informazioni personali, professionali e dati potenzialmente rilevanti per l’indagine.

Da qui nasce il problema centrale affrontato durante la lezione: come conciliare le esigenze investigative con il rispetto del diritto di difesa e del principio di proporzionalità?

Il problema dei sequestri “omnibus”

Uno dei passaggi più significativi dell’intervento ha riguardato il fenomeno dei sequestri “omnibus”, ossia quei provvedimenti con cui vengono acquisiti integralmente computer, smartphone, server o interi archivi digitali senza una preventiva delimitazione dei dati realmente pertinenti all’indagine.

Pittiruti ha osservato come l’attività di sequestro informatico rischi di trasformarsi in vere e proprie “pesche a strascico investigative”, nelle quali il pubblico ministero ottiene accesso indiscriminato a enormi quantità di informazioni, spesso estranee al procedimento penale. Questo problema è particolarmente rilevante perché i moderni dispositivi elettronici contengono ormai l’intera vita digitale dell’individuo: comunicazioni private, dati sanitari, fotografie, attività lavorative, credenziali di accesso, relazioni professionali e informazioni riservate.

Secondo il relatore, il principio di proporzionalità rappresenta oggi il principale strumento difensivo per contrastare queste prassi investigative. La Corte di Cassazione, soprattutto nelle pronunce più recenti, ha progressivamente imposto al pubblico ministero un obbligo di motivazione rafforzata, richiedendo che il decreto di perquisizione e sequestro specifichi in modo concreto:

  • quali dati si intendono cercare;
  • perché sia necessario acquisire determinati dispositivi;
  • quali criteri di selezione verranno utilizzati;
  • quale sia il periodo temporale rilevante per l’indagine.

L’importanza delle parole chiave e dei criteri di selezione

Particolare attenzione è stata dedicata ai criteri di selezione dei dati, spesso realizzati mediante parole chiave utilizzate durante le attività di analisi forense. Pittiruti ha sottolineato come la giurisprudenza più recente richieda che tali criteri siano “effettivi” e non meramente apparenti.

Un esempio concreto citato durante la lezione riguarda l’utilizzo del nome di un’azienda o del dominio di posta elettronica come keyword di ricerca: una scelta apparentemente neutra che, in pratica, può comportare il sequestro indiscriminato di migliaia di email e documenti.

Il tema assume ulteriore rilevanza quando nei dispositivi sequestrati sono presenti comunicazioni coperte da segreto professionale, come quelle tra avvocato e assistito. Pittiruti ha evidenziato come, nella prassi, non sempre vengano adottate adeguate cautele per evitare l’acquisizione di tali contenuti, con il rischio di compromettere il diritto di difesa.

Copia di mezzo e copia di fine

Entrambi I relatori hanno ampiamente parlato della questione legata alla nuova normativa che prevede la creazione di una copia forense che viene identificata inizialmente come “copia di mezzo” o “copia mezzo” e poi, successivamente alla creazione e consolidamento, filtrata tramite selezione basata su keyword (parole chiave), criteri temporali, criteri di contesto o valori hash producendo quella che si definisce “copia di mezzo” o “copia mezzo”.

Nel contesto delle indagini digitali e del diritto processuale penale, la copia-mezzo è infatti la copia integrale e non selettiva di tutti i dati presenti su un dispositivo sequestrato, una copia completa e comprensiva di tutti i dati appresi, inclusi in buona parte dati fuori dal perimetro dell’indagine.

Da questa, gli inquirenti, Polizia Giudiziaria o i consulenti tecnici forensi appositamente nominati dal Pubblico Ministero selezionano solo le informazioni rilevanti al reato, creando così la copia-fine, che entra ufficialmente a far parte del fascicolo probatorio.

La distinzione è fondamentale per tutelare la privacy e il diritto di difesa del cittadino ed è regolamentata in modo preciso: Copia-mezzo (Copia Integrale o Servente) è il duplicato esatto (bit-a-bit) dell’intero dispositivo (es. smartphone, PC) e la sua funzione è tecnica è quella di cristallizzare tutto il contenuto per consentire la restituzione del dispositivo fisico all’avente diritto nel minor tempo possibile. La Copia-fine (Copia Selettiva) è invece l’insieme di dati estratto dalla copia-mezzo che contiene esclusivamente le informazioni pertinenti alle indagini, tanto che solo questi file specifici costituiranno la prova utilizzabile in giudizio.

I concetti di copia-mezzo e copia-fine non derivano da una specifica legge o articolo del codice, ma dalla giurisprudenza della Corte di Cassazione: i Giudici hanno provveduto a colmare un vuoto normativo per adattare le vecchie regole sul sequestro fisico all’era degli smartphone e dei computer. Poiché il codice di procedura penale non menziona esplicitamente i termini “copia di mezzo” e “copia di fine”, la Sentenza della Corte di Cassazione n. 34265 del 22 settembre 2020 (depositata il 2 dicembre 2020) ne ha formalizzato la distinzione e le regole d’uso:

La durata del sequestro e la “vita digitale” dell’indagato

Un altro aspetto affrontato riguarda la durata del sequestro dei dispositivi informatici. Nella pratica investigativa capita frequentemente che smartphone e computer vengano trattenuti per mesi, talvolta anni, con pesanti ripercussioni sulla vita personale e professionale dell’indagato.

La Corte di Cassazione ha progressivamente affermato che il trattenimento dei dati e delle copie forensi deve limitarsi al tempo strettamente necessario alle operazioni di selezione e analisi. Tuttavia, come osservato durante la lezione, nella pratica questo principio si scontra con criteri molto elastici e con l’ampia discrezionalità riconosciuta agli organi investigativi.

La gestione tecnica del reperto informatico

Nella seconda parte dell’incontro, il CEO Forenser Paolo Dal Checco ha affrontato – dal punto di vista del perito informatico forense – gli aspetti tecnici dell’informatica forense, illustrando le metodologie utilizzate per acquisire e analizzare correttamente i dati digitali tramite tecniche di digital forensics.

L’intervento ha evidenziato come l’acquisizione forense non possa essere improvvisata: anche una semplice operazione di collegamento di un dispositivo a un computer può alterare automaticamente i dati presenti sul supporto. Dal Checco ha spiegato che i sistemi operativi moderni eseguono frequentemente operazioni automatiche – come la creazione di file di sistema, la modifica di timestamp o l’indicizzazione dei contenuti – che possono compromettere l’integrità del reperto digitale.

Per questo motivo, nella digital forensics vengono utilizzati strumenti specifici, come i write blocker hardware e software, che impediscono al sistema operativo di scrivere accidentalmente sui supporti sequestrati.

Dal Checco ha inoltre illustrato le differenze operative tra Windows, macOS e Linux nella gestione dei dispositivi acquisiti, evidenziando come alcuni sistemi offrano maggiori garanzie rispetto ad altri nella prevenzione delle alterazioni involontarie dei dati.

Corso Biennale UCPI Specializzazione Avvocato Penalista a Roma

Le best practices e la genuinità della prova

Uno dei punti centrali dell’intervento tecnico ha riguardato il rispetto delle best practices internazionali di digital forensics. La corretta acquisizione del dato richiede infatti:

  • documentazione completa delle operazioni;
  • utilizzo di strumenti verificati;
  • generazione di hash crittografici;
  • tracciabilità delle attività svolte;
  • conservazione sicura delle copie forensi;
  • possibilità di ripetere e verificare le operazioni eseguite.

Sul piano giuridico, Pittiruti ha evidenziato come la violazione di queste procedure non venga ancora considerata dalla giurisprudenza italiana come causa automatica di inutilizzabilità della prova. Tuttavia, alcune recenti pronunce sembrano aprire scenari nuovi, attribuendo crescente importanza alla correttezza metodologica delle operazioni tecniche e alla verifica dell’attendibilità intrinseca della prova digitale.

Il ruolo sempre più centrale del consulente informatico forense

Uno dei messaggi più forti emersi durante la lezione è stato il ruolo ormai imprescindibile del consulente informatico forense nella strategia difensiva.

Secondo entrambi i relatori, oggi non è più sufficiente una difesa esclusivamente giuridica: la comprensione delle metodologie tecniche di acquisizione, conservazione e analisi del dato è diventata essenziale per verificare la legittimità dell’attività investigativa e individuare eventuali anomalie o violazioni.

Il processo penale digitale richiede quindi una collaborazione sempre più stretta tra avvocato e consulente tecnico, affinché il contraddittorio possa svilupparsi non solo sul piano giuridico, ma anche su quello scientifico e metodologico.

Una sfida centrale per il processo penale contemporaneo

La lezione ha mostrato con grande chiarezza come il tema della prova digitale rappresenti oggi una delle principali sfide del processo penale contemporaneo. L’enorme capacità invasiva degli strumenti informatici impone infatti un delicato equilibrio tra esigenze investigative e tutela dei diritti fondamentali.

Da un lato vi è la necessità di acquisire prove spesso decisive; dall’altro emerge sempre più chiaramente il rischio che attività investigative sproporzionate compromettano la riservatezza, il diritto di difesa e la genuinità stessa della prova.

In questo scenario, la digital forensics non rappresenta soltanto una disciplina tecnica, ma diventa uno strumento essenziale di garanzia processuale.

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

Paolo Dal Checco e Andrea Galeazzi sul furto del canale Youtube

forenser on 24 Gennaio 2026

Il CEO Forenser Paolo Dal Checco analizza l’hackeraggio del canale YouTube di Andrea Galeazzi

Recentemente, il noto youtuber Andrea Galeazzi ha subito il furto del proprio account Google e, di conseguenza, del suo canale YouTube da quasi 1,5 milioni di follower. Il nostro CEO, Paolo Dal Checco, lo ha raggiunto nella sua famosa “Cantinetta” per analizzare gli aspetti tecnici dell’accaduto e offrire consigli pratici su come proteggersi da questi attacchi e come rimediare qualora il danno sia già avvenuto.

L’incidente ha avuto origine da un attacco di Spear Phishing estremamente sofisticato e personalizzato. A differenza delle campagne generiche, gli attaccanti hanno sfruttato una fase di reconnaissance precisa, basandosi sulle reali lamentele degli utenti riguardo alla qualità audio dei video recenti per proporre una falsa collaborazione con un brand di microfoni. L’attuale disponibilità di strumenti basati sull’Intelligenza Artificiale consente ormai di automatizzare la creazione di scenari così contestualizzati, analizzando profili pubblici per ingannare la vittima con una precisione che un tempo avrebbe richiesto un operatore umano dedicato,.

Sotto il profilo tecnico, il vettore d’attacco non ha mirato alla sottrazione diretta della password, ma allo sfruttamento di una finta autenticazione OAuth. Andrea Galeazzi, rassicurato dalla coerenza del contesto, ha autorizzato l’accesso tramite una maschera che pareva legittima, permettendo ai criminali di procedere al hijacking del canale. Ciò che colpisce maggiormente dal punto di vista dell’Incident Response è la velocità della “Kill Chain”: in meno di venti secondi dall’autorizzazione, gli attaccanti hanno modificato le credenziali, revocato le sessioni attive e impostato un token fisico (chiave hardware FIDO/U2F) come unico metodo di autenticazione, rendendo inefficaci i metodi di recupero tradizionali.

Andrea Galeazzi parla del suo account Youtube e Google hackerato con Paolo Dal Checco

Nel corso del video, il nostro CEO Paolo Dal Checco ha evidenziato la debolezza intrinseca dell’autenticazione a due fattori (2FA) via SMS, vulnerabile a malware e SIM Swapping, consigliando suo posto l’adozione di metodi più robusti come le Passkey o, meglio ancora, le chiavi di sicurezza hardware come le YubiKey.

Per i profili ad alto rischio, emerge l’importanza del Google Advanced Protection Program, un’impostazione di sicurezza che limita drasticamente l’accesso alle API di terze parti e impone finestre temporali di verifica estese per operazioni critiche,.

Dal punto di vista della Digital Forensics, nel video Andrea Galeazzi spiega l’importanza di reperire artefatti specifici che provino la titolarità storica dell’account, come l’ID univoco del canale (non il semplice handle pubblico), i log storici dei dispositivi e i dettagli dei metodi di pagamento pregressi.

Paolo Dal Checco e Andrea Galeazzi hanno inoltre discusso il concetto di “isolamento dei dati”, suggerendo di abbandonare l’idea di un account unico per tutti i servizi e di separare nettamente le identità digitali lavorative, personali e finanziarie per ridurre il raggio d’azione di un’eventuale compromissione.

Lo stesso vale per le password, che devono essere diverse per ogni account e servizio presso i quali si possiede un account.

Il peggio è passato, ma questo episodio dimostra che chiunque può cadere vittima di hacking se colto nel momento o con la chiave giusta. Il video completo dell’incontro tra Andrea Galeazzi e il nostro CEO è visionabile su YouTube nel canale di Andrea Galeazzi.

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.

Web Forensics e Indagini Digitali Forensi per MSAB a Roma

forenser on 5 Novembre 2025

Come si acquisisce in maniera forense una pagina web? Come si cristallizza un post Instagram o un commento ricevuto su Facebook per fini giudiziari? Se stampo una mail in PDF ha valore legale come prova digitale in Tribunale?

Queste e altre domande troveranno risposta nel talk sulla Web Forensics che il CEO Forenser Paolo Dal Checco insieme al collega Andrea Lazzarotto giovedì 6 novembre 2025 a Roma nell’ambito del workshop organizzato da MSAB intotolato “Nuovi Orizzonti per le Indagini Digitali Forensi: Sfide e Soluzioni”.

Indagini Digitali e Web Forensics per MSAB a Roma 2025

L’evento, organizzato in collaboratione con Nuix, SANS Institute and eTrace Digital Security, si terrà in presenza presso l’UNA HOTELS Hotel Empire dalle 8:30 alle 18:30.

Programma del Workshop MSAB sulle Indagini Digitali

Il workshop che si terrà a Roma prevede talk di altissimo livello su argomenti d’informatica forense e mobile forensics con l’intervento dei seguenti professionisti:

  • Mattia Epifani, CEO di Reality Net, consulente informatico forense, esperto in attività di Digital Mobile Forensics, docente certificato SANS, docente universitario, autore e divulgatore, con l’intervento: “Not So Private Browsing!”
  • Paolo Dal Checco, Consulente informatico forense, esperto in attività di Digital Mobile Forensics, analisi di OSINT, malware e criptovalute, docente universitario, autore e divulgatore, insieme a
  • Andrea Lazzarotto, Consulente informatico forense, esperto in attività di Digital Mobile Forensics, ricercatore, sviluppatore, con l’intervento: “Web Forensics: Le Nuove frontiere delle Prove Digitali”
  • Roberto Murenec, Maresciallo in forza al Comando Provinciale della Guardia di Finanza di Pordenone, autore, divulgatore e esperto di Digital Forensics e relativa regolamentazione legislativa, insieme a
  • Pier-Luca Toselli, Luogotenente Carica Speciale in forza al Comando Provinciale della Guardia di Finanza di Bologna, esperto di Digital Forensics e relativa regolamentazione legislativa, con l’intervento: “Perquisizione e Sequestro del Dispositivo “Mobile” Tra Rispetto delle Regole Processuali e delle Garanzie di Parte”
  • I responsabili di E-Trace, rivenditore esclusivo MSAB per il territorio italiano.
  • Manlio Longinotti, Responsabile Italia SANS, con l’intervento: “SANS DFIR Trainings: La Formazione Oltre l’Aggiornamento”
  • Dario Beniamini, GCFA, GCFE, GOSI, CFIP, CIFI, Esperto in proprietà intellettuale e tutela dei marchi, DFIR, NUIX Senior Consultant, docente certificato SANS, con l’intervento: “Rethinking Digital Investigations: Beyond Keyword Searches”
  • Ghennadii KONEV, con l’intervento: “Non Solo FFS, Estrazioni Fisiche BFU con XRY”
  • Giovanni Maria Castoldi, MSAB North Mediterranean Area Sales Manager.

Web Forensics e Indagini Digitali

Nell’intervento di Paolo Dal Checco e Andrea Lazzarotto si parlerà di un tema sempre più centrale nelle indagini digitali: la Web Forensics, ovvero l’insieme di tecniche e metodologie per acquisire, preservare e analizzare prove provenienti dal web come siti web, pagine web, servizi online, piattaforme cloud, API, social network e applicazioni mobili.

Spesso le indagini digitali si concentrano su dispositivi fisici, ma oggi una parte sempre più significativa delle evidenze si trova “fuori” dal computer, nel cloud o su piattaforme web in continua evoluzione. Da qui nasce la necessità della webforensics, cioè quella di rendere l’acquisizione forense di risorse web affidabile, ripetibile e non disconoscibile, al pari di quella tradizionale.

Web Forensics - Dal Checco e Lazzarotto per MSAB a Roma

Durante il talk sulla Web-Forensics i due relatori mostreranno come costruire una macchina virtuale forense per l’acquisizione di pagine e contenuti web, documentando ogni passaggio (traffico di rete, video, log, certificati, riferimenti temporali, ecc.), come cristallizzare l’ambiente e i risultati con tecniche di hashing, timestamping e marca temporale e come utilizzare strumenti open source specifici per l’acquisizione e la verifica, come FIT (Freezing Internet Tool) e Fuji, sviluppati per garantire integrità, catena di custodia e trasparenza nelle operazioni di copia e analisi.

Si parlerà anche di acquisizioni di contenuti “complessi”, come flussi video o chiamate API, oltre che di come intercettare e documentare correttamente il traffico HTTPS o REST attraverso strumenti utilizzabili in ambito web forensics come mitmproxy.

Infine, a latere – poiché non si tratta di webforensics pura – si discuterà delle nuove sfide legate all’acquisizione forense dei dispositivi Mac con chip Apple Silicon, che richiedono un cambio di paradigma simile a quello già affrontato nel mondo mobile.

L’obiettivo del workshop sulla Web Forensics è mostrare un metodo pratico e ripetibile per affrontare in modo rigoroso e documentato la cristallizzazione di prove digitali web, in linea con i principi della Legge 48/2008, della ISO/IEC 27037 e delle best practice internazionali.

Agenda dell’evento MSAB a Roma

L’evento che si terrà giovedì 6 novembre 2025 a Roma nell’ambito del workshop organizzato da MSAB intotolato “Nuovi Orizzonti per le Indagini Digitali Forensi: Sfide e Soluzioni” seguirà la seguente agenda dei lavori:

  • 8:45 Registrazione Partecipanti
  • 9:30 Introduzione
  • 9:45 Ghennadii Konev & Giovanni Maria Castoldi con l’intervento: “Non Solo FFS, Estrazioni Fisiche BFU con XRY”
  • 10:30 Coffee Break
  • 10:45 Mattia Epifani con l’intervento: “„”Not So Private Browsing!“
  • 11:45 Dario Beniamini con l’intervento: “Rethinking Digital Investigations: Beyond Keyword Searches”
  • 12:30 Paolo Dal Checco & Andrea Lazzarotto con l’intervento: “Web Forensics: Le Nuove frontiere delle Prove Digitali”
  • 13:15 Pranzo
  • 14:30 Manlio Longinotti con l’intervento: “SANS DFIR Trainings: La Formazione Oltre l’Aggiornamento”
  • 15:00 Pier Luca Toselli & Roberto Murenec con l’intervento: “Perquisizione e Sequestro del Dispositivo Mobile“ Tra Rispetto delle Regole Processuali e delle Garanzie di Parte“
  • 15:45 Coffee Break
  • 16:00 Intervento E-Trace
  • 16:45 Q&A, Demo
  • 18:00 Termine

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.