Duty to know and understand; Need to know

Hi, minions:

On December 9, 2018, Brett Shavers published an article on the DFIR Training site entitled "Something I see with forensic software preferences". If you haven't read it yet, I strongly recommend that you do so, (only if you like to be made to think a little). Since the first reading I did of it, (I've read it several times), I've been wanting to write something related to the content of that article. Today is that day.

As you may have seen, the title of this article is "Duty to know and understand; Need to know". What the hell does that mean?

Each one of us will always have some kind of preference, predisposition, when using a type of system, a type of tools. Likewise, each one of us will always be more reluctant to use another type of system, another type of tool. All this can be done even unconsciously. Personally, I try to be equidistant in this sense. It is indifferent to me to use a Windows System than a Linux System. I don't care whether I use a tool with a graphical interface or a system console. Because you should know that everything has its advantages and disadvantages.
There's no such thing as the perfect tool.
For that very reason, because there is no perfect tool, it is an inexcusable duty of the analyst to know what tools he has at his disposal, what alternatives he can use to achieve his goal: to carry out his work satisfactorily. In DFIR there are multiple ways to reach the same result.

The analyst must also understand how the tool he or she is using works. It can happen that you use a tool with all your default settings and you don't find what you are looking for because of that: because you use the default settings. Do you then need to switch to another tool? Or, is it possible that by changing some value of your configuration you find what you are looking for?

The tools have been developed to serve a specific purpose. From the 'smallest' utility, (in size), to the most advanced and expensive forensic suite in this industry, they have been written to fulfill a purpose and each one will present a series of advantages and disadvantages, which can be substituted for each other. If there is a tool that does not meet your expectations and you do not know other tools because you cling to the first one, how do you intend to carry out your work?

You should know that a tool that runs on one System on one target may not work in the same way if it runs on another System on the same target.

On the other hand, the analyst must know what he needs to look for. It seems obvious, doesn't it? You can't carry out an analysis if you don't know what you're going to look for, if you don't mark a purpose. I have always believed that no question is too much when it comes to obtaining information on a case, however absurd it may seem. Any detail can help the analyst in his work.

Just as important as everything I have told you so far, is that you must know that you have to seek a balance. The analyst must take into consideration the resources used, the effort expended, the time invested, the purpose of the case, ... And that, in my opinion, is not achieved by insisting on the use of a single tool

If we know the tools and understand how they work, we will be able to meet our objective in a much more effective way than it might seem in principle.

Let me explain this in a much more dynamic way.

A very simple example

On January 8 of this year 2019, at 13.09, my phone rang. On the other side was a relative who needed my help, my knowledge. This relative was doing a job with a file '.psd' hosted on a USB device and told me that I had 'lost' it and needed to recover it. only that file. To top it all, instead of not touching it, instead of moving away from that device and not even looking at it, he reconnected it to his computer to try to recover it, without knowing very well what he executed.

When I went to pick up the USB device I proceeded to ask him some questions:

* When did you 'lose' the file?
* How did you 'lose' the file?
* When did you create the file?
* When was it last used?
* What was the file called?
* What format was the file?
* What was inside the file?
* How big was the file?
* Where was the file hosted?
* What version of Photoshop was it working with?
* How many coffees was it going to invite me to? 😉

And a few more questions. As I told you before, no question is more than enough to do an effective job.

Before plugging the USB device into the workstation, I proceed to block, and verify, the writing of USB devices:


I am not going to work directly on the device, despite having it connected in read-only mode in the System. I will create a forensic image. For this case I have chosen to use Magnet Acquire. I like how it works because it presents a very detailed log of the device and the acquisition process.

Now, with the image created, I return the USB device to its owner and it's time to comply with the request.

You may be thinking that the most viable option for this case would be to carve the forensic image. That's right. It is an option. Let's look at it with a couple of examples.

I'm going to show you the process with two tools that are very widely used, and very powerful: Foremost' and 'Photorec'.


We can run the tool and tell it to only look for files with the extension '.psd'.

But it looks like we have a problem. We tried to run it without indication of file extension.

The tool has worked, but we have not obtained any file '.psd'. What happens? That the configuration file 'foremost.conf' does not contain the information related to the 'magic numbers' of the files '.psd'.

So, if we do not have examples of such files on our workstation, we can consult sites such as https://www.garykessler.net/library/file_sigs.html or https://www.filesignatures.net/, where we can look for that data relating to the header and footer of a file type.

Once we have found the data we are interested in we must introduce them into a file 'foremost.conf'.

Again, we proceed to run 'Foremost' with indication of the type of file we want to recover. But the tool doesn't work this way either.

If we use 'Foremost' with a custom configuration file we should look for all the file types found in it. This way, we run the tool again without specifying the file type. This time he has managed to extract 9 files '.psd'.

Agreed. Now what? What do we do? 

Can you say that we can deliver these results to the 'client', to which I will say: Without checking them?

Can you say that we can check the results, to which I will say: Are you going to open all the extracted files, one by one? In this case there have only been 9 files. If it were a few tens or hundreds?

As we know the content of the file, and we know that it has a part of text inside, we can look for that content in the recovered files, making use of 'egrep'.

And we can try to open it if we get a positive result, but depending on the type of file, it is very possible that we may encounter errors when opening the file. And this type of error is very common in files that do not have a 'footer', a 'magic number' at the end of the file, as is the case of files '.psd'.

At this point, value the time invested, the effort spent, and the results obtained: In this example, it has not been possible to recover the file of the request.

If you want to see a more detailed article on 'Foremost' you can read the article "My name is #Foremost: I’ve seen things you people wouldn’t believe".


We can run 'Photorec' directly on the forensic image.

In this case, 'Photorec' does allow us to directly select the file type '.psd' without having to enter its configuration.

We leave the rest of the configuration by default and process the whole disk.

In this case, the application has managed to extract 3 files '.psd'. We can now look for which file from which it has managed to recover contains the information we are interested in. In principle, the file with the name 'f1110816.psd', with a size of 156.864 KB, is the one we are interested in.

Indeed, we open it and the result is positive. However, we proceed to run 'Photorec' again, but this time varying its configuration.

With this new run the application extracts 2 files. After searching for the content of interest within them, it tells us that the file we are interested in is the one named 'f1110784.psd', with a size of 74.800 KB.

Indeed, we open it and it is the file that we have to recover. You should know that depending on the configuration that we carry out in the application, we will be shown some results or others.

At this point, where we have two candidate files to be recovered, which of them do you choose? Because the two have different names, with different size and, therefore, different content, although the image of the file is the same. 

Again, value the time invested, the effort spent, and the results obtained: In this example, it has been possible to recover two files that, apparently, correspond to that of the request.

The easy way

Never, ever, should you underestimate the information you provide to meet an objective because the solution to the case, with the information at your disposal, may be in plain sight. Likewise, you should never, ever underestimate any tool, because the solution may be there.

In order to do an effective job in this case I have not chosen to use any carving tool. I have chosen to use 'The Sleuth Kit'.

The first thing I do is to see what partitions the USB device has, using the utility 'mmls'.

After that, I generate a timeline, only with the content of '.psd' files, using the utilities 'fls' and 'mactime', filtering the results with 'egrep'.

After studying the timeline, by means of the dates provided and the name of the file, I proceed to see the information of a file located in inode 83, under the name '_ote.psd', which is presented as deleted, by means of the utility 'istat'.

This is the file I'm looking for. So I extract it using the 'icat' utility.

And I proceed to its opening to check it out.

If you want to see more about 'The Sleuth Kit' you can read the article "About the timelines: The limit, your imagination".


As you may have noticed, with 'Foremost', in this case, it was not possible to extract the file of interest. The opposite has happened with 'Photorec', which has recovered two files, with different names and sizes. 

If we compare the files extracted using carving tools with the file extracted with 'The Sleuth Kit' you can see the difference.

This is just a small example. But,

The solution to one case does not have to be the same as for another case. The solution may be something more complex, such as manual file recovery using 'xxd', or something very simple, such as forensic image processing in an advanced forensic suite. 

Sometimes the solution will be somewhat convoluted and other times it will be found with the naked eye. Sometimes no data will be available and other times the data will provide a gateway to solving the problem.

What you have to take into account is that, for each case, you have to find a balance weighing time, resources, effort... And all this cannot be carried out if you do not know the tools, if you do not understand how they work and, of course, if you do not know what you are looking for.

Therefore, do not hold on to a tool as if it were the only one, as if it were the best. Think of the wide range you can have, of the use each of these tools can have.

That's all.

Deber de conocer y entender; Necesidad de saber

Hola, secuaces:

El día 9 de diciembre del año 2018, Brett Shavers publicó un artículo en el sitio DFIR Training bajo el título "Something I see with forensic software preferences, (Algo que veo con las preferencias del software forense)". Si aún no lo han leído ustedes, les recomiendo encarecidamente que lo hagan, (sólo si les gusta que les hagan pensar un poco). Desde la primera lectura que hice de él, (lo he leído en varias ocasiones), llevo queriendo escribir algo relacionado con el contenido de ese artículo. Hoy es ese día.

Como habrán podido ver ustedes, el título del presente artículo es "Deber de conocer y entender; Necesidad de saber". ¿Qué diantres significa eso?

Cada uno de nosotros siempre va a tener algún tipo de preferencia, predisposición, a la hora de utilizar un tipo de Sistema, un tipo de herramientas. Igualmente, cada uno de nosotros siempre será más reacio al uso de otro tipo de Sistema, de otro tipo de herramientas. Todo ello puede hacerse incluso inconscientemente. Personalmente, procuro ser equidistante en este sentido. Me es indiferente utilizar un Sistema Windows que un Sistema Linux. Me da lo mismo usar una herramienta con interfaz gráfica que una consola del sistema. Porque deben saber ustedes que todo tiene sus ventajas y sus inconvenientes.
No existe la herramienta perfecta.
Por ese mismo hecho, porque no existe la herramienta perfecta, es un deber inexcusable del analista conocer qué herramientas tiene a su disposición, qué alternativas puede usar para lograr su objetivo: realizar de forma satisfactoria su trabajo. En DFIR existen múltiples caminos para llegar a un mismo resultado.

Igualmente, el analista debe entender cómo funciona la herramienta que está usando. Puede darse el caso de que ustedes usen una herramienta con todas sus configuraciones por defecto y no encuentren lo que están buscando por eso mismo: porque usan ustedes la configuración por defecto. ¿Necesitan pasar entonces a otra herramienta? O, ¿Es posible que cambiando algún valor de su configuración encuentren lo que están buscando?

Las herramientas han sido desarrolladas para cumplir un propósito específico. Desde la utilidad más 'pequeña', (en tamaño), hasta la suite forense más avanzada y cara de esta industria, han sido escritas para cumplir con una finalidad y cada una presentará una serie de ventajas y de inconvenientes, que pueden suplirse entre ellas. Si hay una herramienta que no cumple con sus expectativas y no conocen ustedes otras herramientas porque se aferran a la primera, ¿Cómo pretenden llevar a cabo su trabajo?

Deben saber ustedes que una herramienta que se ejecuta en un Sistema sobre un objetivo puede no trabajar de igual modo si se ejecuta en otro Sistema sobre el mismo objetivo.

Por otro lado, el analista debe saber qué necesita buscar. Parece obvio, ¿No? No se puede llevar a cabo un análisis si no se sabe lo que se va a buscar, si no se marca una finalidad. Siempre he tenido la creencia de que ninguna pregunta sobra a la hora de obtener información de un caso, por absurda que pueda parecer. Cualquier detalle puede ayudar al analista en su trabajo.

Igual de importante que todo lo que les he expuesto hasta ahora, es que deben saber que tienen que buscar un equilibrio. El analista debe tener en consideración los recursos utilizados, el esfuerzo empleado, el tiempo invertido, la finalidad del caso, … Y eso, en mi opinión, no se consigue empeñándose en el uso de una única herramienta.

Si conocemos herramientas y entendemos cómo funcionan podremos ser capaces de cumplir con nuestro objetivo de una manera mucho más eficaz de lo que pudiera parecer a priori.

Permítanme que les explique esto de una forma mucho más dinámica:

Un ejemplo muy sencillo

El día 8 de enero de este año 2019, a las 13.09 horas, sonó mi teléfono. Al otro lado estaba un familiar que precisaba de mi ayuda, de mis conocimientos. Este familiar estaba realizando un trabajo con un fichero '.psd' alojado en un dispositivo USB y me dijo que lo había 'perdido' y necesitaba recuperarlo. únicamente ese fichero. Para colmo, en lugar de no tocarlo, en lugar de alejarse de ese dispositivo para ni siquiera mirarlo, lo volvió a conectar a su equipo para intentar recuperarlo, sin saber muy bien qué ejecutó.

Cuando fui a recoger el dispositivo USB procedí a hacerle algunas preguntas:

* ¿Cuándo se le 'perdió' el fichero?
* ¿Cómo se le ha 'perdido' el fichero?
* ¿Cuándo creó el fichero?
* ¿Cuándo lo usó por última vez?
* ¿Cómo se llamaba el fichero?
* ¿Qué formato tenía el fichero?
* ¿Qué contenido había dentro del fichero?
* ¿Cuánto ocupaba el fichero?
* ¿Dónde estaba alojado el fichero?
* ¿Con qué versión de Photoshop estaba trabajando?
* ¿A cuantos cafés me iba a invitar? 😉

Y algunas otras preguntas más. Como les he dicho anteriormente, ninguna pregunta sobra para hacer un trabajo eficaz.

Antes de conectar el dispositivo USB en la estación de trabajo, procedo a bloquear, y a verificar, la escritura de dispositivos USB:


No voy a trabajar directamente sobre el dispositivo, a pesar de tenerlo conectado en modo de sólo lectura en el Sistema. Voy a crear una imagen forense. Para este caso he optado por utilizar Magnet Acquire. Me gusta cómo funciona porque presenta un log muy detallado del dispositivo y del proceso de adquisición.

Ahora, con la imagen creada, devuelvo el dispositivo USB a su propietario y es hora de cumplir con la petición.

Es posible que ustedes estén pensando que la opción más viable para este caso sería efectuar un 'carving' sobre la imagen forense. Es cierto. Es una opción. Vamos a verlo con un par de ejemplos.

Voy a mostrarles el proceso con dos herramientas de uso muy extendido, y muy potentes: 'Foremost' y 'Photorec'.


Podemos ejecutar la herramienta e indicarle que únicamente busque ficheros con extensión '.psd'.

Pero parece ser que tenemos algún problema. Probamos a ejecutarlo sin indicación de extensión de ficheros.

La herramienta ha trabajado, pero no hemos obtenido ningún fichero '.psd'. ¿Qué ocurre? Que el fichero de configuración 'foremost.conf' no contiene la información relativa a los 'números mágicos' de los ficheros '.psd'.

Así que, si no disponemos de ejemplos de ese tipo de ficheros en nuestra estación de trabajo, podemos consultar sitios como https://www.garykessler.net/library/file_sigs.html o https://www.filesignatures.net/, donde podemos buscar esos datos relativos a la cabecera y pie de un tipo de fichero.

Una vez que hemos encontrado los datos que nos interesan debemos introducirlos dentro de un fichero 'foremost.conf'

Nuevamente, procedemos a ejecutar 'Foremost' con indicación del tipo de fichero que deseamos recuperar. Pero tampoco funciona de este modo la herramienta.

Si utilizamos 'Foremost' con un fichero de configuración personalizado debemos buscar todos los tipos de fichero que se encuentren en él. De este modo, ejecutamos de nuevo la herramienta sin especificar el tipo de fichero. En esta ocasión ha conseguido extraer 9 ficheros '.psd'.

Conforme. ¿Y ahora? ¿Qué hacemos? 

Podrán decir ustedes que podemos entregar estos resultados al 'cliente', a lo que yo les diré: ¿Sin comprobarlos?

Podrán decir ustedes que podemos comprobar los resultados obtenidos, a lo que yo les diré: ¿Van a abrir todos los ficheros extraídos, uno a uno? En este caso sólo han sido 9 ficheros. ¿Si se tratara de algunas decenas o cientos?

Como conocemos el contenido del fichero, y sabemos que tiene una parte de texto en su interior, podemos buscar ese contenido en los ficheros recuperados, haciendo uso de 'egrep'.

Y podemos intentar abrirlo si obtenemos un resultado positivo, pero dependiendo del tipo de fichero de que se trate, es muy posible que nos podamos encontrar con errores a la hora de abrir el fichero. Y este tipo de errores es muy habitual en ficheros que no disponen de un 'footer', de un 'número mágico' al final del archivo, como es el caso de los ficheros '.psd'.

Llegados a este punto, valoren ustedes el tiempo invertido, el esfuerzo empleado, y los resultados obtenidos: En este ejemplo, no ha sido posible recuperar el fichero de la petición.

Si desean ustedes ver un artículo más detallado sobre 'Foremost' pueden leer el artículo "Mi nombre es #Foremost: Yo… he visto cosas que vosotros no creeríais"


Podemos ejecutar 'Photorec' directamente sobre la imagen forense.

En este caso, 'Photorec' sí nos permite seleccionar directamente el tipo de fichero '.psd' sin necesidad de entrar en su configuración.

Dejamos el resto de la configuración por defecto y procesamos todo el disco entero.

En este caso, la aplicación ha conseguido extraer 3 ficheros '.psd'. Podemos, ahora, buscar qué fichero de los que ha conseguido recuperar contiene la información que nos interesa. A priori, el fichero con el nombre 'f1110816.psd', con un tamaño de 156.864 KB, es el que nos interesa.

Efectivamente, lo abrimos y el resultado es positivo. No obstante, procedemos a ejecutar de nuevo 'Photorec', pero esta vez variando su configuración.

Con esta nueva ejecución la aplicación extrae 2 ficheros. Tras buscar el contenido de interés dentro de ellos, nos indica que el fichero que nos interesa es el que lleva por nombre 'f1110784.psd', con un tamaño de 74.800 KB. 

Efectivamente, lo abrimos y se trata del fichero que tenemos que recuperar. Deben saber ustedes que depende de la configuración que llevemos a cabo en la aplicación, se nos mostrarán unos resultados u otros.

Llegados a este punto, donde tenemos dos ficheros candidatos a ser los que debemos recuperar, ¿Cuál de ellos eligen ustedes? Porque los dos presentan distintos nombres, con distinto tamaño y, por ende, distinto contenido, aunque la imagen del fichero sea la misma.

De nuevo, valoren ustedes el tiempo invertido, el esfuerzo empleado, y los resultados obtenidos: En este ejemplo, ha sido posible la recuperación de dos ficheros que, aparentemente, se corresponden con el de la petición.

El camino fácil

Nunca, jamás, deben ustedes subestimar la información que les proporcionen para cumplir con un objetivo porque la solución al caso, con la información de la que disponen, puede estar a simple vista. Igualmente, nunca, jamás, deben subestimar ninguna herramienta, porque la solución puede estar ahí.

Para realizar un trabajo eficaz en este caso no he optado por usar alguna herramienta de 'carving'. He optado por utilizar 'The Sleuth Kit'.

Lo primero que hago es ver qué particiones tiene el dispositivo USB, mediante la utilidad 'mmls'

Después de ello, genero una línea de tiempo, únicamente con el contenido de ficheros '.psd', mediante las utilidades 'fls' y 'mactime', filtrando los resultados con 'egrep'.

Tras el estudio de la línea de tiempo, mediante las fechas proporcionadas y el nombre del fichero, procedo a ver la información de un fichero ubicado en el inodo 83, bajo el nombre '_ote.psd', que se presenta como borrado, mediante la utilidad 'istat'.

Este sí es el fichero que estoy buscando. Así que lo extraigo mediante la utilidad 'icat'.

Y procedo a su apertura para comprobarlo.

Si desean ver ustedes algo más sobre 'The Sleuth Kit' pueden leer el artículo "Sobre las líneas de tiempo: El límite, tu imaginación".


Como se habrán percatado ustedes, con 'Foremost', en este caso, no ha sido posible extraer el fichero de interés. Lo contrario ha ocurrido con 'Photorec', que nos ha recuperado dos ficheros, con distintos nombres y tamaños. 

Si comparamos los ficheros extraídos empleando herramientas de 'carving' con el fichero extraído con 'The Sleuth Kit' podrán ustedes ver la diferencia.

Esto se trata únicamente de un pequeño ejemplo. Pero,

La solución a un caso no tiene porque ser la misma que para otro caso. La solución puede estar en algo más complejo, como la recuperación manual de ficheros, empleando 'xxd', o en algo muy sencillo, como el procesado de la imagen forense en una avanzada suite forense. 

A veces, la solución será algo enrevesada y otras veces se encontrará a simple vista. A veces no se dispondrán de datos y otras veces los datos proporcionarán una puerta a la resolución del problema.

Lo que tienen que tener en cuenta ustedes es que, para cada caso, deben buscar un equilibrio sopesando el tiempo, los recursos, el esfuerzo... Y todo eso no se puede llevar a cabo si ustedes no conocen herramientas, si no entienden cómo funcionan y, por supuesto, si no saben lo que buscan.

Por ello, no se aferren a una herramienta como si fuera la única, como si fuera la mejor. Piensen en el amplio abanico del que pueden disponer, en el uso que puede tener cada una de esas herramientas.

Esto es todo.