Archive for the ‘Sans’ Category

Digital Forensics: Troppo porno, troppo poco tempo

settembre 25th, 2010, posted in Browser forensics, Sans, Traduzioni inglese>italiano

Il post seguente è stato tradotto per gentile concessione di SANS Computer Forensics

Recentemente ho trattato un caso in cui una delle richieste era determinare se il pc fosse stato utilizzato per visualizzare e/o scaricare immagini pornografiche da Internet. In primo luogo vorrei dire che l’unica parte che, in ultima analisi, possa determinare se l’immagine sia pornografica, è il tribunale. Detto questo abbiamo convenuto, all’inizio delle indagini, che qualsiasi immagine avesse mostrato chiaramente gli organi sessuali sarebbe stata, secondo la definizione del cliente, pornografica.

Analizzando il caso con FTK 3.12 e prelevando le immagini sia dallo spazio allocato che, tramite carving, nel non allocato, sono state recuperate oltre 60.000 immagini.

Il cliente esigeva una risposta rapida, quindi controllare e classificare il gran numero di immagini manualmente non era pensabile.
Visualizzare rapidamente ogni immagine per soli 5 secondi, avrebbe significato bruciare circa 2 settimane di lavoro.
Il processo doveva essere automatizzato e nel più breve tempo possibile.

Sapevo che AccessData possiede un modulo opzionale denominato “Explicit Image Detector” (EID) e ho deciso di fare un tentativo. Ho contattato il settore vendite e acquistato una licenza annuale per circa $ 800, il file di licenza è stato aggiornato e si trattava quindi solamente di aggiornare il mio dongle FTK.

Per aggiungere l’elaborazione EID all’immagine già elaborata è stata semplicemente una questione di:

Fare clic su Evidence > Add/Remove Evidence…

In detailed options > Evidence processing, attivare File Signature Analysis

Selezionare Explicit Image Detection > ho selezionato l’opzione X-DFT (default) così come le opzioni X-ZFN (più precise):

Figura 1 Opzioni EID

Figura 1 Opzioni EID

Ero alla fine della giornata e ho deciso di lasciare semplicemente il processo in esecuzione durante la notte. La mattina seguente aveva terminato e guardando i log del caso relativi ai tempi di elaborazione, ho visto che hanno richiesto circa sei ore. E con le immagini caricate sul caso e le rispettive label di classificazione EID. Una rapida occhiata ha mostrato che un’immagine con un valore di X-ZFN superiore a 90 eliminava la maggior parte dei falsi positivi. Un filtro (vedi Figura 2) è stato costruito in modo da selezionare solo le immagini appartenenti a X-ZFN con un valore superiore a 90.

Figura 2 Filtro EID

Figura 2 Filtro EID

Questo ha portato il numero totale di immagini sospette da 60.000 a 6000, esattamente 1/10 del numero totale e un compito decisamente più gestibile. È importante ricordare che EID lavora usando i toni carne, quindi qualsiasi immagine con un elevato livello di toni simili, sia essa un normale ritratto o un’immagine pornografica, ottiene un riscontro in EID; quindi si è resa necessaria una revisione manuale. Utilizzare il filtro con valore superiore a 90, visualizzare le immagini con FTK thumbnail viewer, selezionare select all e poi deselezionare tutte le immagini che non avessero soddisfatto la definizione di immagine pornografica come definito dal cliente, ha richiesto circa 6 ore e portato il numero di immagini a 4.886.

Le immagini sono state raggruppate in un segnalibro, sempre considerando gli elementi di prova relativi alla richiesta del cliente, è stato generato un report e masterizzato su DVD per esser presentato al cliente. L’uso di EID non solo ha impedito che impattasse su altri casi, considerando il mio attuale carico di lavoro; ma ha anche fatto risparmiare al cliente circa 60 e più ore di tempo fatturabile, che sarebbero state facilmente necessarie se le immagini avessero dovuto essere analizzate manualmente.

Fonte: Digital Forensics: Too Much Porn, Too Little Time

Attacchi alle applicazioni web lato client

marzo 24th, 2010, posted in Sans

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Nel corso degli ultimi anni, gli attacchi contro le applicazioni web sono diventati più frequenti e sofisticati.

Ci sono diversi metodi per attaccare le applicazioni web, SQL injection, è uno dei più noti. In questo articolo parleremo di una classe diversa di attacchi e forniremo alcuni esempi di come un incident responder, o un investigatore di computer forensics possa individuarli.

Tutti i form web contengono campi che vengono utilizzati per catturare input da un utente e inviati al server per l’elaborazione.
I campi del form vengono comunemente usati per raccogliere informazioni, dai dettagli dell’operazione sui siti di ecommerce, fino alle credenziali di autenticazione per contenuti riservati. Mentre i campi del form vengono utilizzati per raccogliere dati legittimamente inseriti da parte degli utenti, possono essere utilizzati anche per arrecare danno.

Un esempio comune di attacco lato client è il form field injection. In questo tipo di attacco il malware, interagendo con un browser web, aggiunge ulteriori campi ad un form su una pagina web (cercate BHO html injection).

Lo scopo dei campi injected è ingannare gli utenti a rivelare dati personali sensibili, come password, codici PIN dei bancomat e numeri di carte di credito. Queste informazioni vengono acquisite e trasmesse a siti remoti dove possono essere usati per perpetrare furti di identità o frodi. Diverse classi di malware sono in grado di eseguire questo tipo di attacco, compreso l’ampiamente utilizzato ZeuS

Gli attacchi HTML injection compiono con il form field injection, un ulteriore passo in avanti. Invece di inserire un campo di un form in una pagina web, l’injection di codice HTML sostituisce l’HTML legittimo proveniente dal server, in maniera simile ad una operazione “taglia ed incolla”. L’HTML sostituito viene sovrascritto dall’ HTML dell’attacker ed il contenuto originale non verrà mai più inserito dal browser web. Questo tipo di attacco può essere utilizzato per modificare il flusso logico di un’applicazione web. Ad esempio i dati legittimi in una pagina web, come il riepilogo di un account, potrebbero essere sostituiti da un form per chiedere nome utente e password. Dopo che i dati saranno stati inseriti nel form, i dati legittimi saranno mostrati correttamente. Ciò potrebbe apparire come un ulteriore livello di autenticazione, inducendo l’utente a inserire le credenziali che verranno memorizzate come l’attacco form field injection di cui sopra.

Perché queste informazioni sono importanti per i professionisti dell’ incident response e della digital forensic ? Entrambi questi attacchi sono lato client. Quando si investiga su applicazioni web compromesse, gli investigatori potrebbero non avere accesso al computer lato client. Tuttavia, poiché i campi injected sono parte di un form web, possono essere trasmessi al server nella richiesta POST, insieme ai campi legittimi della pagina. Questi artifact possono essere visualizzati come dati anomali nei log dei server. Ad esempio, un campo nome utente che appaia in un POST che non sia in una pagina di login legittima, dovrebbe essere investigato.

In sintesi: conoscere gli attacchi in corso, saper come vengono compiuti e saper quali artifact, o firme, possano lasciarsi alle spalle, può essere un grande vantaggio per un investigatore. Tramite la conoscenza e la ricerca di questi segni, gli investigatori sono in grado di riconoscere e reagire agli incidenti più velocemente, con conseguente minore impatto per l’organizzazione/agenzia. Si torna al vecchio adagio di conoscere il vostro sistema, dati, flussi, ecc. Concentrate l’attenzione su qualsiasi deviazione anomala rispetto a questi pattern, in quanto può essere un avvertimento che si sia verificato un incidente.

Chris Silveira gestisce il CSIRT e Paul Yacovetta è un forensic engineer presso un istituto finanziario.

Fonte: Client-side Web Application Attacks

Flash Cookie Forensics

settembre 25th, 2009, posted in Flash cookie forensics, Sans, Traduzioni inglese>italiano

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Recentemente, i cookie di flash sono stati un argomento di notevole interesse, grazie al rilascio di un ottimo paper dal titolo Cookie di flash e privacy. I cookie di flash, o local shared objects nel linguaggio Macromedia, sono un ottimo esempio di forensic artifact che esiste da molto tempo; in pratica ignorato fino a quando non si è deciso di renderlo noto. Quando vedo una nuova ricerca che riguarda problematici controlli della privacy, immediatamente estraggo il mio palmare, perché so che troverò artifact di grande valore che potranno aiutarmi nel corso delle mie indagini relative alla forensics.

Prima di tutto alcuni principi fondamentali:

  • Macromedia Flash è diventato onnipresente sul web, grazie a funzionalità come lo streaming video ed altre peculiarità per il “cliente ricco”. Molti dei siti più popolari sul web sono dipendenti da Flash e quindi un’alta percentuale di utenti Internet ha installato il plug-in per Flash.
  • Lo standard Flash incorpora i local shared objects (LSO), che consentono ai dati (come le preferenze) di essere conservati nell’istanza locale di Flash, sulla macchina dell’utente.
  • Gli LSO vengono memorizzati come singoli file con estensione .SOL.  Per impostazione predefinita sono meno di 100 KB e non hanno scadenza (a differenza dei tradizionali cookie HTTP).
  • Ho trovato i file .SOL in due posizioni, nel sistema locale: %user profile%\Application Data\Macromedia\Flash Player e %user profile%\Application Data\Macromedia\Flash Player\# SharedObjects\profile \ in un sistema XP).Per l’analisi di Vista, sarà necessario cercare nella cartella roaming all’interno di %user profile%\
  • Gli LSO non sono browser based, quindi attualmente, non esiste un modo semplice per l’utente medio di rimuoverli (cancellando semplicemente i file si raggiunge lo scopo, ma l’utente deve sapere dove si trovano). Questo rende gli LSO molto difficili da eliminare sul sistema locale.

Analisi

Per i nostri scopi, il termine cookie di flash è adatto per definire gli LSO, perché fornisce informazioni molto simili a quelle che troviamo nei tradizionali cookie HTTP. Chi ha frequentato il corso SANS SEC 408 Computer Forensic Essentials ricorda che i cookie HTTP possono fornire le seguenti informazioni:

I siti web visitati

Macromedia Flash richiede che gli LSO siano conservati gerarchicamente, per dominio. In questo modo è possibile far rispettare la regola che ogni dominio può memorizzare fino a 100K sul sistema locale. Dal nostro punto di vista, questo ci fornisce uno strumento molto utile per esaminare velocemente i siti visitati.

Figure 1: Listato directory che mostra i domini LSO

Figura 1: Listato directory che mostra i domini LSO

Anche gli annunci pubblicitari basati su Flash hanno la possibilità di salvare gli LSO. Questo è importante, perché, in alcuni casi, si può necessariamente concludere che l’intento dell’utente fosse quello di accedere al dominio. L’origine degli LSO è spesso evidente (vedi figura 2). Ma ulteriori test o artifact addizionali possono essere necessari per giungere a conclusioni definitive.

Figura 2: Local Shared Object memorizzato da una pubblicità flash

Figura 2: Local Shared Object memorizzato da una pubblicità flash

Account utente locale che ha visitato il sito

I file .SOL si trovano all’interno della cartella %user profile% , che indica l’account autenticato nel momento in cui l’LSO è stato salvato.

La prima e l’ultima visita al sito

Dal momento che i file .SOL vengono salvati singolarmente, abbiamo un bel set di timestamp del file system da utilizzare. Su Windows XP (che ha l’Access time stamping abilitato per default), si può utilizzare l’Access Time per sapere quando l’LSO è stato letto l’ultima volta. Questo può dirci, potenzialmente, quando il sito è stato visitato per l’ultima volta; ma si deve prestare attenzione, visto che non sono a conoscenza di alcuna norma che richieda un sito di distribuzione per leggere gli LSO. È certamente nel loro interesse e i miei test sembrano confermarlo, ma se il sito non legge l’LSO per qualche ragione, l’access time non sarà aggiornato.

Il creation time del file .SOL, potenzialmente, può comunicare quando il sito è stato visitato per la prima volta. Ancora una volta, però, non è possibile stabilire con certezza che l’LSO sia stato creato durante la prima visita al sito; quindi è difficile essere definitivi. Per analizzare meglio tutto questo, si dovrebbe considerare “la prima visita nota al sito”. Altri artifact del sistema, possono essere in grado di confermare questa data, o indicare una visita precedente.

Così, osservando di nuovo la figura 1, è possibile vedere che la prima visita nota a mg3.mail.yahoo.com è stata l’ 11/27/2008 all’ 1:38 e l’ultima visita nota l’ 8/17/2009 alle 5:27 (local machine time).

Dati memorizzati dal sito

Flash tenta semplicemente di offuscare i dati all’interno di ogni LSO, controllando il formato e forzando una serializzazione binaria dei dati memorizzati. Detto questo, se trovate un file rilevante, non trascurate questa area di dati. Ho trovato informazioni interessanti, come text-based location information memorizzate da un sito web meteo.

Strumenti

Sebbene non sia raccomandato come forensics tool (in primo luogo, perché richiede l’installazione/esecuzione su un sistema live), l’estensione per Firefox, Better Privacy, è un ottimo strumento per identificare (e rimuovere) gli LSO sul sistema locale. Uno dei modi migliori per conoscere i forensics artifact è l’analisi su un sistema con un comportamento noto (cioè il vostro sistema). Il plug-in Better Privacy vi permette di esaminare (e gestire) gli LSO su un sistema live.

 Figura 3: Better Privacy Firefox plug-in Screenshot

Figura 3: Better Privacy Firefox plug-in Screenshot

Questo è solo un primo rapido esame relativo ai Cookie di Flash, esorto i nostri lettori ad inviare eventuali link o informazioni supplementari nei commenti del blog.

Ciad Tilbury, GCFA, ha trascorso oltre dieci anni nell’ambito investigativo relativamente al crimine informatico: dal computer hacking allo spionaggio, fino a casi di frode per svariati milioni di dollari. Attualmente insegna al SEC408 Computer Forensic Essentials e SEC508 Computer Forensics, Investigations, and Response per il SANS Institute.

Fonte: Flash Cookie Forensics

Memory forensics: un esempio pratico

agosto 22nd, 2009, posted in Memory forensics, Sans, Traduzioni inglese>italiano

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Durante un incidente informatico in un’azienda protetta da antimalware, Host IPS e Windows GPO; atti ad impedire l’esecuzione di materiale pericoloso, abbiamo notato qualcosa di sospetto nella rete e sembrava venisse utilizzato per far trapelare informazioni. Cosa dobbiamo fare per avere indizi su ciò che sta accadendo?
La memory forensics ci può aiutare. Effettuiamo una prima immagine della memoria utilizzando il software MDD di Mantech (http://www.mantech.com/msma/mdd.asp):

Dopo aver effettuato l’immagine, useremo uno strumento che possa essere in grado di sondare in maniera più approfondita ciò che contiene, in modo da ottenere le prove utili per il caso. Si userà Volatility framework (https://www.volatilesystems.com/default/volatilità). Un software open source in Python che è in grado di analizzare le immagini della memoria di Windows XP e raccogliere informazioni: come i socket creati, la lista dei processi, la lista delle DLL caricate, le connessioni attive, l’indirizzo di memoria, i file aperti e le chiavi di registro per ogni processo. Ecco come si usa: digitiamo python volatility :

src=”http://manuel.santander.name/sans/volatility_usage.jpg” alt=”" />

Otteremo la lista dei processi, ora cerchiamo di trovare qualcosa di strano. Digitiamo python volatility pslist memory.dmp-f :

Abbiamo trovato qualcosa. PID 2316 sembra essere un netcat. Vediamo se c’è qualche trasferimento in corso, grazie ad un controllo delle connessioni attive sull’ host, digitiamo python volatility connections -f memory.dmp :

Nessun trasferimento in corso. Netcat potrebbe essere in ascolto? Verifichiamo ogni socket creato digitando python volatility sockscan memory.dmp-f :

Abbiamo trovato qualcosa! Netcat sembra essere in ascolto sulla porta TCP 1234 (Protocollo 6).

È possibile verificare i numeri di protocollo qui .

Dove sta scrivendo? Proviamo ad aprire i file digitando python volatility file memory.dmp-f :

Sembra essere in attesa di un file di Excel. Proporrò altri casi nei prossimi post.

Manuel Humberto Peláez Santander è Chief Information Security Officer dell’ Empresas públicas Medellín ESP .

Possiede GCFA, GCIA, GNET, GCFW, GCIH e GSEC.

Fonte : Memory forensics: A practical example

Metadati Office 2007

agosto 21st, 2009, posted in Computer forensics, Sans, Traduzioni inglese>italiano

Il post seguente è stato tradotto, previa autorizzazione, dal blog SANS Computer Forensics

Le informazioni ricavate dai metadati dei documenti possono essere una valida fonte di informazioni per gli investigatori ed il loro valore è indiscusso. I documenti creati utilizzando Microsoft Office compaiono spesso nel corso delle indagini. Parecchi script e software permettono di leggere il formato proprietario dei documenti creati utilizzando Office 2003 e versioni precedenti, di conseguenza non c’è altro da aggiungere per quanto riguarda questi strumenti. Ma non ci sono molti software che possano leggere i metadati nel nuovo formato che utilizza Office 2007 , OpenXML. Così ho deciso di esaminarlo un po’ più accuratamente.

Microsoft ha già pubblicato un documento che descrive abbastanza bene la struttura di OpenXML [ 1 ]. In sostanza un documento creato in OpenXML, è un file compresso con il noto formato ZIP, in modo che possa essere facilmente aperto con qualsiasi software che faccia uso di tale formato (ad esempio, modificando il nome del documento da document.docx a document.zip e utilizzando un software che legga il formato ZIP).

All’interno del file ZIP sono presenti alcune strutture predefinite di file, generalmente file XML che descrivono il documento ed il suo contenuto, facilmente leggibili tramite librerie standard disponibili nei linguaggi di scripting come Perl.

Secondo quanto detto da Microsoft, all’interno dell’archivio ZIP viene creata una cartella chiamata “_rels”. Questa cartella contiene un file chiamato “. Rels” che definisce le relazioni all’interno dell’archivio. Questo dovrebbe essere il primo luogo utile per effettuare il parse del documento. All’interno del file .rels si trovano i tag che definiscono le relazioni del documento:

<Relationship Id="someID" Type="relationshipType" Target="targetPart"/>

I metadati sono memorizzati in file che contengono un tipo di “proprietà * “, generalmente nota come “proprietà core” e “proprietà estesa”. Questi file sono in genere memorizzati secondo il percorso seguente:

  • DocProps / core.xml
  • DocProps / app.xml

    Questi file contengono, quindi, le informazioni effettive dei metadati: chi ha creato il documento, ultimo file salvato, ecc. Per essere in grado di visualizzare i metadati di tali informazioni è necessario estrarre ed effettuare il parse dei documenti.

    A questo proposito ho creato uno script read_open_xml.pl , che effettua il parse dei contenuti del file .rels per individuare i metadati e successivamente estrarli e stamparli sullo schermo. Ecco un esempio di come possa essere utilizzato:

    ./read_open_xml.pl test.docx
    ==========================================================================
     cmd line: ./read_open_xml.pl test.docx
    ==========================================================================
    
    Document name: test.docx
    Date: Tue Jun  9 16:51:23 GMT 2009
    
    --------------------------------------------------------------------------
    File Metadata
    --------------------------------------------------------------------------
     title = my company template
     subject = Document template
     creator = Kristinn Gudjonsson
     keywords = template, word
     description =
     lastModifiedBy = Kristinn Gudjonsson
     revision = 3
     lastPrinted = 2008-08-15T10:14:00Z
     created = 2008-08-15T10:14:00Z
     modified = 2008-08-15T10:14:00Z
     category = template
    --------------------------------------------------------------------------
    Application Metadata
    --------------------------------------------------------------------------
     Template = my_template.dot
     TotalTime = 0
     Pages = 2
     Words = 159
     Characters = 908
     Application = Microsoft Word 12.1.2
     DocSecurity = 0
     Lines = 7
     Paragraphs = 1
     ScaleCrop = false
     Manager = Some dude
     Company = My Company
     LinksUpToDate = false
     CharactersWithSpaces = 1115
     SharedDoc = false
     HyperlinksChanged = false
     AppVersion = 12.0258
    
    copyright, Kristinn Gudjonsson, 2009

    Lo script legge anche la codifica dei caratteri dei documenti XML e ne codifica l’output.

    Lo script è stato creato per essere usato con Linux, grazie ad alcune modifiche che ho apportato, dovrebbe funzionare anche con sistemi operativi Windows (è stato testato su Win XP SP3 con ActivePerl 5,10).

    È possibile scaricare la versione per Windows qui .

    La versione per Windows e per Linux non sono state ancora testate, quindi potrebbero essere ancora instabili ( alcune informazioni per l’installazione sono contenute all’interno dello script stesso)

    Fonte : Office 2007 Metadata

I 7 metodi maggiormente utilizzati dagli investigatori per catturare i criminali tramite la forensics dei dispositivi mobili

agosto 7th, 2009, posted in Mobile forensics, Sans

Questo post è stato tradotto, previa autorizzazione, di SANS Computer forensics

I dispositivi mobili odierni sono un’arma a doppio taglio: creano nuovi rischi per la sicurezza ma allo stesso tempo forniscono preziose fonti di prova agli investigatori della digital forensics. Le capacità sempre crescenti di tali dispositivi, li rendono sempre più simili ai personal computer, che ci accompagnano durante la nostra esplorazione del mondo. Gli investigatori possono utilizzare le informazioni memorizzate per ricostruire i nostri movimenti, le comunicazioni e altri dettagli personali.

Se si ha la necessità di estrarre informazioni da telefoni cellulari, smartphone e altri dispositivi mobili, o se si è preoccupati per la sicurezza dei propri dati; in questo post sono presenti alcune informazioni importanti.

Bypassare i codici di sicurezza : gli investigatori della digital forensics sono in grado di estrarre il codice di sicurezza di alcuni dispositivi mobili protetti, utilizzando strumenti specializzati.
La schermata seguente mostra il codice di sicurezza “12345″ recuperato da un Nokia 6230 utilizzando .XRY (l’identificativo dell’abbonato è stato rimosso).

Essere in grado di aggirare i meccanismi di sicurezza, consente agli investigatori di acquisire i dati tramite il software forense.

Codice di sicurezza Nokia 6230 recuperato tramite .XRY

Safe SIM Card: Inserire una carta SIM in maniera errata in un telefono cellulare, distrugge alcuni dati utili in memoria.
Per evitare simili problemi, gli investigatori sono in grado di creare Safe SIM Card, progettate per l’analisi forense.

Acquisizione Live : La rimozione della batteria prima di eseguire un’acquisizione forense, può distruggere prove preziose.
In alcuni casi, per garantire che tutte le prove disponibili siano preservate, l’investigatore lascerà il dispositivo portatile acceso fino a quando l’acquisizione forense non potrà essere effettuata; prendendo le precauzioni necessarie, atte ad impedire che i dati possano essere modificati.

Trusted Time Source: anche se il clock sul dispositivo non è impostato correttamente, alcuni time stamp possono essere corretti; visto che sono generati dal sistema sul core network. Ad esempio, il timestamp di un messaggio SMS ricevuto, è stabilito dallo Short Message Service Center, non dal telefono cellulare.

Localizzazione degli spostamenti : Alcuni dispositivi memorizzano le informazioni basate sulla posizione geografica, associate ad alcuni mezzi di comunicazione ed azioni, sul dispositivo stesso.
Gli investigatori possono recuperare tali informazioni per rilevarne la posizione in un determinato momento. Ad esempio, la seguente schermata mostra i metadati exif estratti utilizzando JPEGsnoop da una fotografia digitale scattata utilizzando un dispositivo mobile G1. Questi metadati includono la data e l’ora della foto e le coordinate GPS della località (i dettagli relativi allla località sono stati eliminati ).

JPEGsnoop utilizzato per estrarre dati Exif tramite tag GPS da una fotografia digitale

Recupero dei dati eliminati : Quando l’utente cancella il log delle chiamate, può essere recuperabile con relativa facilità. Quindi anche se i log delle chiamate non vengono visualizzati, gli investigatori potrebbero essere in grado di visualizzare i dettagli delle chiamate effettuate, ricevute e perse, utilizzando strumenti facilmente reperibili.

Getting Physical : Gli investigatori possono recuperare grandi quantità di dati cancellati da diversi dispositivi mobili, tramite l’acquisizione e l’analisi dell’intero contenuto della memoria. Questa schermata mostra l’acquisizione della memoria fisica di un Nokia 6610, tramite l’applicazione di Sarasoft, Twister flasher box.

Dump della memoria fisica di un Nokia 6610, utilizzando Twister flasher box di Sarasoft

I dati eliminati, come fotografie, log delle chiamate e le tracce delle attività dell’utente (ad esempio, la navigazione Web e la visualizzazione di file) recuperate da un dispositivo mobile possono fornire agli investigatori alcune tra le più utili ed incriminanti prove di un caso.

Per imparare queste ed altre tecniche relative alla forensics dei dispositivi mobili, iscrivetevi al SEC563 Mobile Device forensics di Baltimora, 27-31 luglio ( Iscrivetevi qui ).

Si tratta di un corso tecnico intensivo, con numerosi esercizi pratici per familiarizzare con il funzionamento interno dei vari dispositivi mobili e mostrare vantaggi e limiti dei vari approcci e strumenti. Non solo dimostreremo lo stato dell’arte per quanto riguarda gli strumenti e le tecniche della mobile forensics; ma sveleremo lentamente i vari livelli delle prove digitali per mostrare ciò che accade dietro le quinte. In questo modo, otterremo una conoscenza più approfondita delle informazioni necessarie alle indagini.

SEC563 - Mobile Device Forensics

Eoghan Casey è founding partner di cmdLabs (http://www.cmdlabs.com/), autore del libro “Digital Evidence and Computer Crime” e coautore di “Malware Forensics”.
Ha partecipato ad una vasta gamma di indagini digitali, inclusi casi di intrusioni di rete, frode, crimini violenti, furto d’identità ed attività criminali on-line. Ha testimoniato in materia civile e penale, ha presentato relazioni tecniche e documenti prodotti in giudizio, relativamente alla computer forensics ed in casi di criminalità informatica.

Fonte: Top 7 ways investigators catch criminals using Mobile Device Forensics