Minions

Minions

domingo, 10 de febrero de 2019

#DFIR: Choose your weapon well. Calculate the impact.

Hi minions:

Allow me to begin by making reference to an element that I believe it is essential to know perfectly:

Request for Comments: 3227 - Guidelines for Evidence Collection and Archiving.

Whenever I have the opportunity, I mention this document because it sets out some basic guidelines for acting in the event of a security incident, in any of its forms. Among many other interesting aspects, (such as the first person who can intervene in a System), are the guiding principles during the collection of evidence, which says that one should proceed to collect evidence from the most volatile to the least volatile and which specifies in point 2.1 on the order of volatility.

(I'm not going to talk to you about kernel, or debugging, or pages of memory...) This would result in an article with a much larger and much more extensive technical depth).

In my opinion, when someone proceeds to intervene in a live System for further analysis, the first technical action to be carried out is the performance of a memory dump. Due to the greater volatility of memory, the acquisition of memory is a fundamental phase in the collection of evidence.
Memory can and should be analyzed because, sometimes, studying non-volatile data will not be enough.
When studying a forensic image of a memory it is played with some advantage in the analysis. In the memory there may be data corresponding to other data stored on the hard disk or you may encounter anonymous data that is not stored on the hard disk. It is therefore necessary to act quickly, altering as little as possible the memory itself that you want to capture.

The more time that elapses, as well as the more activity there is in the System, the fewer options there are to collect useful information from the memory because the memory is constantly changing. Therefore, using tools to capture the memory alters the memory and, therefore, also alters the memory image that is being acquired because the memory is not 'frozen'. So how do you preserve the volatile data contained in RAM? There is no acquisition method that comes close to 100% to maintain memory integrity. Memory will always be modified.

Data can survive in memory for a certain amount of time. For example, you may be able to retrieve an image that has been opened on a System from an external device, where the thumbnail view itself is housed, so it is not possible to see the content of the image elsewhere. If the image still remains in the memory, it can be extracted, even if it is fragmented.

It is possible to carry out a 'carving' on the forensic image of the memory; it is possible to carry out a timeline of it; it is possible to obtain hashes or credentials that are in use of, for example, encrypted content in the System; to export keys of the Registry of Windows, Logs of Events, etc.; it is possible to see processes in execution, historical processes, hidden processes, network connections, ... 

The same options that you can carry out on an image of a hard disk, can carry out on the memory. (on this I have pending to publish a 'work' for more than a year. 😕😕)

Very interesting data can be extracted from the memory. Key data can be obtained for the successful resolution of the case. I almost dare to say that you can solve a case only with the proper study of memory, (I'm opening the umbrella 🙄🙄).


There is no doubt that each scenario has to be evaluated because each of them will have its own characteristics. For example, it is not the same case, nor does it require the same study, the analysis of an e-mail header as a case in which child pornography content is found.

But before we start analyzing the memory, it must be captured. For that reason it is vital to choose the right tool to use, to capture as much raw memory as possible.

It has been spoken in many articles, on many occasions, of the existing tools that can be available to carry out such an action, explaining its basic operation. But nothing has been said about the impact that the execution of these tools have on the memory itself.

The test environment


If you're trying to collect as much raw memory as possible and you're trying to maintain as much of that memory as possible, why not do a study of the impact of the tools you use, beforehand? In the study that I present below I have taken into account both the resource consumption of the memory itself and the duration of the acquisition. Both aspects, in my opinion, are extremely important.

The tests have been carried out on my own System: A Windows 10 System, in its compilation '17763.292', which has 15306 MB of memory size; as well as a Windows 10 System, in its compilation '17763.253', (which you can download from Microsoft's official site), virtualized under VirtualBox, with an assigned memory of 4096 MB.


For the monitoring of the processes in execution of the different memory acquisition tools I have chosen to use the 'Process Explorer' tool, in its version 16.22, (which you can download from Microsoft's official site).

The values I have taken into account as a reference are those related to the private workspace, which consists of the memory dedicated to that monitored process and which is not shared with other processes, as well as the workspace that is shared with other processes. This size is measured in Kilobytes.

The reference values I have taken into account for the execution times are those related to the time stamps corresponding to the creation and modification of the forensic image of the memory, because the file is generated at the same time that the dump begins and is modified for the last time when the last data is recorded.

In order not to lose any detail during the acquisition of the dumps I have chosen to record the entire process in video using the 'Record That' function of the 'Game Bar', which incorporates the Windows 10 System itself.

As far as the tested tools are concerned, I have chosen to use some of them with free access and more widespread use:

* DumpIT, in its version 3.0.20190124.1
* Magnet RAM Capture, in its version 1.1.2
Belkasoft Live RAM Capturer
* Memorize, in its version 3.0
* Winpmem, in its version 3.2
* FTK Imager Lite, in its version 3.1.1

Belkasoft Live RAM Capturer



During memory acquisition with this tool, two processes have been raised: The 'RamCapture64.exe' process, as the parent process, and a child process 'conhost.exe'. The 'conhost.exe' process is responsible for opening instances for each Windows console. In other words, for each Windows console that is opened, a 'conhost.exe' process will appear.

The 'RamCapture64.exe' process has presented a range of consumption values, in its private space, of 1872-1988, as minimum and maximum values. In its shared memory it has oscillated between 11476-11672.

The 'conhost.exe' process has presented a range of consumption values, in its private space, of 7260-7344, as minimum and maximum values. In its shared memory it has oscillated between 16768-16816.


The time taken for this tool to acquire the complete memory of the System was 3,150000003 minutes, as can be seen in the time stamps relating to the creation and modification of the memory image.


DumpIT



This tool allows its execution in two different ways: directly from the executable itself, or from a cmd console, where the configuration of some parameters is allowed. Depending on how the tool is executed, you will be able to find some values or others. 

If you choose to run this tool from the executable itself, you will find two processes: 'DumpIT.exe', as the parent process, and a child process 'conhost.exe'.

The 'DumpIT.exe' process has presented a range of consumption values, in its private space, of 1644-1988, as minimum and maximum values. In its shared memory it has oscillated between 8980-9028.

The 'conhost.exe' process has presented a range of consumption values, in its private space, of 7104-7296, as minimum and maximum values. In its shared memory it has oscillated between 17132-17200.


The time it has taken this tool to acquire the complete memory of the System, with this type of execution, has been 7.716666658 minutes, as seen in the time stamps relating to the creation and modification of the memory image.


However, if you choose to run this tool from the cmd console, where some parameters are allowed to be configured, you can find the parent process 'cmd.exe', your child process 'conhost.exe', and the parent process 'DumpIT.exe', your child process 'conhost.exe'.

The 'cmd.exe' process has presented a range of consumption values, in its private space, of 6108-11484, as minimum and maximum values. In its shared memory it has oscillated between 14460-16776.

The 'conhost.exe' process, dependent on the 'cmd.exe' process, has presented a range of consumption values, in its private space, of 8520-8524, as minimum and maximum values. In its shared memory it has oscillated between 22180-22284.

The 'DumpIT.exe' process has presented a range of consumption values, in its private space, of 1688-1776, as minimum and maximum values. In its shared memory it has oscillated between 8900-8988.

The 'conhost.exe' process has presented a range of consumption values, in its private space, of 7192-7280, as minimum and maximum values. In its shared memory it has oscillated between 16540-17012.


The time it has taken this tool to acquire the complete memory of the System, with this type of execution, has been 4.866666662 minutes, as seen in the time stamps relating to the creation and modification of the memory image.


*** QUICK NOTE ***

This tool will provide, at the end, a very interesting report with information related to the KDBG, which will help them to identify correctly the profile of the memory, as well as information related to the file generated, with a hash SHA256, information about the machine where it has been executed, information about the Operating System and information about the version of the tool itself. Very important information that must be attached to the final report.


********************

FTK Imager Lite



During memory acquisition with this tool, a single process named 'FTK Imager.exe' has been set up.

This process has presented a range of consumption values, in its private space, of 21588-22024, as minimum and maximum values. In its shared memory it has oscillated between 50764-51744.


The time taken for this tool to acquire the complete memory of the System was 3.583333333 minutes, as can be seen in the time stamps relating to the creation and modification of the memory image.



Magnet RAM Capture



During memory acquisition with this tool, a single process named 'MagnetRAMCapture.exe' has been set up.

This process has presented a range of consumption values, in its private space, of 9656-10484, as minimum and maximum values. In its shared memory it has oscillated between 32812-34296.


The time taken for this tool to acquire the complete memory of the System was 4,066666664 minutes, as can be seen in the time stamps related to the creation and modification of the memory image.



Memorize



This tool is executed through the cmd console, so they are presented during the acquisition: a parent process 'cmd.exe' with a child 'conhost.exe' process, and a parent process 'Memorize.exe' with a child process 'conhost.exe'. In addition to these processes a 'netsh.exe' process is presented at the end of the acquisition, which is a command line utility, dependent on the 'Memorize.exe' process.

The 'cmd.exe' process has presented a range of consumption values, in its private space, of 5708-11020, as minimum and maximum values. In its shared memory it has oscillated between 14512-16320.

The process 'conhost.exe', dependent on the process 'cmd.exe', has presented a range of consumption values, in its private space, of 7604-7688, as minimum and maximum values. In its shared memory it has oscillated between 19904-20032.

The 'Memorize.exe' process has presented a range of consumption values, in its private space, of 3616-3644, as minimum and maximum values. In its shared memory it has oscillated between 11860-11960.

The 'conhost.exe' process has presented a range of consumption values, in its private space, of 7276-8180, as minimum and maximum values. In its shared memory it has oscillated between 16804-17924.

The 'netsh.exe' process has presented a memory consumption, in its private space, of 980. In its shared memory it has presented a value of 120.


The time it has taken this tool to acquire the complete memory of the System, with this type of execution, has been 6.583333332 minutes, as can be seen in the time stamps relating to the creation and modification of the memory image.



Winpmem



This tool, which runs through the cmd command line, will present a parent process 'cmd.exe', with two processes dependent on it: 'conhost.exe' and 'winpmem_3.2.exe'.

The 'cmd.exe' process has presented a range of consumption values, in its private space, of 2828-5920, as minimum and maximum values. In its shared memory it has oscillated between 4944-4992.

The process 'conhost.exe', dependent on the process 'cmd.exe', has presented a range of consumption values, in its private space, of 7552-7640, as minimum and maximum values. In its shared memory it has oscillated between 20016-20064.

The process 'winpmem_3.2.exe' has presented a range of consumption values, in its private space, of 1840-3824, as minimum and maximum values. In its shared memory it has oscillated between 6720-8948.


The time it has taken this tool to acquire the complete memory of the System has been 5.116666668 minutes, as can be seen in the time stamps relating to the creation and modification of the memory image.


This tool allows the capture of the memory using the network, which can be carried out using the Netcat utility, but this would result in raising another extraordinary process under the name 'nc.exe' that would have a memory consumption, in its private workspace, of about 624 K.

*** QUICK NOTE ***

The execution of this procedure would be through the lines:

winpmem_3.2.exe -m --format raw --output - | nc.exe IP_Destination Port
nc.exe -l -p Port > C:\Test\Memory_Winpmem_remote.raw

********************

The acquisition


Any memory acquisition tool will always dump the entire memory of the System. All generated files will be the same size, unless they are compressed or divided.


In the case of the acquisition with the Winpmem tool, the resulting file will be larger than the memory of the System because, in addition to the same, it extracts and acquires other types of data. Therefore, the resulting file will be a '.zip' file, which is a container that cannot be analyzed directly and that must be decompressed, being found inside the image of the physical memory under the name of 'PhysicalMemory'.


I have come across some articles, with some comments and with some rumors, in which it is said that some tools give problems with sizes greater than 8 GB. This is not true. The main problem I think exists is that the profile is not identified correctly. The profile of the image must be correctly identified before proceeding with the image analysis. All memory images that are created with the tools shown in this article can be analyzed with the appropriate tools, such as Volatility.


Objective data


I am now going to show you the objective data from the tests I have carried out. And the first data that I am going to present to you is going to be relative to time: The time, established in seconds, that a tool takes to acquire the memory of the System.


As you can see, in my tests, the fastest tool has been Belkasoft Live RAM Capturer, while the slowest has been DumpIT, by running on the command prompt, where I have specified a format type and an output path. However, the DumpIT tool, if executed directly, without making use of the System Symbol, is not the slowest, leaving that place to Memorize. The difference between the fastest and the slowest is 274 seconds.

I have already told you at the beginning of this article that memory is constantly changing, that it presents highly volatile information. That's why the 274-second difference between the fastest and slowest tool is a very long time. In that time, the possibilities of recovering elements of interest, such as the images that I have given as an example above and that could be found in the memory, decrease.

The next value I want to show you is the memory consumption, in your private workspace, of each of the tools tested.


Because memory is constantly changing, processes will never present a single value. And they won't even present the same range of values in another similar execution.

In my tests, the tool that has used the least resources, private, has been DumpIT, with a minimum value of 1644 Kilobytes, compared to 21588 Kilobytes used by FTK Imager Lite. Even at maximum values, the DumpIT tool consumes less resources, with a maximum value of 1988 Kilobytes, (the same as the Belkasoft RAM Capturer tool), compared to the 22024 Kilobytes maximum value of FTK Imager Lite. You can see that the difference between both minimum values is 19944 Kilobytes. Think about the great amount of information that can be found in that space, and think about the vital information that can be lost by not thinking about that size.

You can think and believe that it is enough with those values, with that comparison, to determine whether to choose one tool or another. But you must also think about the rest of the processes that are raised by the System with each one of the tools and in the space shared with other processes. Therefore, in the following image (I hope it is well schematized), you will find the information corresponding to those data, where I expose the values obtained with the total sum of the consumption of each of the tools.


As you can see, the tool with less total consumption, in my tests, has been DumpIT, with direct execution, if the use of the console cmd, with a value of 24860 Kilobytes. On the contrary, the tool that presents the highest consumption is Memorize, with a total value of 88264 Kilobytes. You are seeing a difference in total consumption of 53404 Kilobytes. Do you know the enormous amount of data that can be found with that size, in that space? Think about what information you can store in that size..

Conclusions


In this article I present just a few small tests that I have carried out with some of the memory acquisition tools that have free access and that I consider to be more widely used. You can try comparing others. Some small utilities, like MDD, or some forensic suite, like OSForensics.

Because memory is constantly changing, no tool will have a single value, neither in resource consumption, nor in time. It will even present the same range of values in two different executions. It is not possible to extract two identical memories. It all depends on the case. Everything depends on the System, on what is being executed at that moment.

I think this is a very good way to compare the way the different tools work, without making subjective assessments, full of interests or opinions, since it is about presenting objective data, with a real environment.

You can continue to use the tool of your choice or you can keep in mind that, since the memory presents very volatile, constantly changing information, you must choose carefully what you are going to execute and how. You can value only some factor of the use of the tools or you can take into account everything that needs to be valued: The memory consumption of each of the tools, both in your private work space and in the shared one, the time that each tool invests in carrying out its function, or the fact that there are tools that facilitate a final report, with information on the profile on which it has been worked.

I only let you know that you have to choose the right weapon to use and calculate the impact that its use has on the memory of the System. A memory that is being acquired in order to carry out a study on it. A study that contains key information for the resolution of a case. Information that will be lost if you do not act quickly and with the right tool.


The analysis of the memory can be a really tedious task but, without a doubt, if it is done in a correct way the results will be highly positive and satisfactory.

That's all.

#DFIR: Elija bien su arma. Calcule el impacto.

Hola secuaces:

Permítanme ustedes que empiece haciendo una referencia a un elemento que considero que es básico conocer a la perfección:

Request for Comments: 3227 - Guidelines for Evidence Collection and Archiving.

Siempre que tengo oportunidad, menciono este documento puesto que marca unas directrices elementales para actuar ante un incidente de seguridad, en cualquiera de sus tipos. Entre otros muchos aspectos interesantes, (como la primera persona que puede intervenir en un Sistema), se encuentran los principios rectores durante la recolección de evidencias, que dice que se debe proceder a recolectar las evidencias desde la más volátil a la menos volátil y que especifica en el punto 2.1 sobre el orden de volatilidad.

(No les voy a hablar a ustedes de kernel, ni de debugging, ni de páginas de memoria... Ello daría lugar a un artículo con un calado técnico mucho mayor y mucho más extenso).

En mi opinión, cuando alguien procede a intervenir en un Sistema vivo para su posterior análisis, la primera acción técnica que debe llevar a cabo es la realización de un volcado de la memoria. Debido a la mayor volatilidad de la memoria, la adquisición de la misma es una fase fundamental en la recolección de evidencias.
La memoria puede y debe ser analizada porque, algunas veces, estudiar los datos no volátiles no será suficiente.
Al estudiar una imagen forense de una memoria se juega con cierta ventaja en el análisis. En la memoria pueden existir datos que corresponden a otros datos almacenados en el disco duro o pueden encontrarse ustedes con datos anónimos que no son alojados en el disco duro. Por ello hay que actuar rápidamente, alterando lo menos posible la propia memoria que se desea capturar.

A mayor tiempo que transcurra, así como a mayor actividad que haya en el Sistema, menos opciones existen de recopilar información útil de la memoria porque, la memoria, está en constante cambio. Por ello, al usar herramientas para capturar la memoria se altera la misma y, por lo tanto, también se altera la propia imagen de memoria que se está adquiriendo porque la memoria no se 'congela'. Entonces, ¿Cómo se preservan los datos tan volátiles que contiene la memoria RAM? No existe ningún método de adquisición que se acerque al 100% para mantener la integridad de la memoria. La memoria siempre va a ser modificada.

Los datos pueden sobrevivir en la memoria durante un determinado tiempo. Por ejemplo, es posible que puedan ustedes recuperar una imagen que ha sido abierta en un Sistema desde un dispositivo externo, en donde se aloja la propia vista en miniatura, por lo que no es posible ver el contenido de la imagen en otro sitio. Si dicha imagen aún permanece en la memoria, puede ser extraída, aunque se encuentre fragmentada.

Se puede llevar a cabo un 'carving' sobre la imagen forense de la memoria; se puede realizar un timeline de ella; se pueden obtener hashes o credenciales que se encuentren en uso de, por ejemplo, contenido cifrado en el Sistema; exportar claves del Registro de Windows, Logs de Eventos, etc.; Se pueden ver procesos en ejecución, procesos históricos, procesos ocultos, conexiones de red, … 

Las mismas opciones que pueden ustedes llevar a cabo sobre una imagen de un disco duro, pueden llevar a cabo sobre la memoria. (sobre esto tengo pendiente publicar un 'trabajo' desde hace más de un año 😕😕)

Se pueden extraer datos muy interesantes de la memoria. Se pueden obtener datos clave para la resolución satisfactoria del caso. Casi me atrevo a decir que se puede resolver un caso sólo con el debido estudio de la memoria, (voy abriendo el paraguas 🙄🙄).


Sin lugar a dudas, hay que valorar cada escenario porque cada uno de ellos presentará sus características. Por ejemplo, no es el mismo caso, ni requiere el mismo estudio, el análisis de una cabecera de un correo electrónico que un caso en donde se encuentre contenido de pornografía infantil.

Pero antes de empezar a analizar la memoria, ésta, debe ser capturada. Por ese motivo es vital elegir bien la herramienta a usar, para capturar la mayor cantidad de memoria bruta que se pueda.

Se ha hablado en muchísimos artículos, en muchísimas ocasiones, de las herramientas existentes de las que se puede disponer para llevar a cabo tal acción, explicando su funcionamiento básico. Pero nada se ha comentado sobre el impacto que tienen, en la propia memoria que se quiere adquirir, la propia ejecución de esas herramientas.

El entorno de pruebas


Si se trata de recopilar la mayor cantidad de memoria en bruto posible y se trata de mantener la mayor integridad posible de esa memoria, ¿Por qué no hacer un estudio sobre el impacto de las herramientas que se usan, con anterioridad? En el estudio que les presento a continuación he tenido en cuenta tanto el consumo de recursos de la propia memoria como el tiempo de duración de la adquisición. Ambos aspectos, en mi opinión, de suma importancia.

Las pruebas han sido efectuadas sobre mi propio Sistema: Un Sistema Windows 10, en su compilación '17763.292', que dispone de 15306 MB de tamaño de memoria; así como un Sistema Windows 10, en su compilación '17763.253', (que pueden descargar ustedes desde el sitio oficial de Microsoft), virtualizado bajo VirtualBox, con una memoria asignada de 4096 MB.


Para la monitorización de los procesos en ejecución de las distintas herramientas de adquisición de la memoria he optado por usar la herramienta 'Process Explorer', en su versión 16.22, (que pueden ustedes descargar desde el sitio oficial de Microsoft).

Los valores que he tenido en cuenta como referencia son los relativos al espacio de trabajo privado, que consiste en la memoria dedicada a ese proceso monitorizado y que no es compartida con otros procesos, así como el espacio de trabajo que es compartido con otros procesos. Este tamaño es medido en Kilobytes.

Los valores de referencia que he tenido en cuenta para los tiempos de ejecución son los relativos a las marcas de tiempo correspondientes a la creación y modificación de la imagen forense de la memoria, porque el fichero es generado en mismo momento en el que comienza el volcado y es modificado por última vez cuando se graba el último dato.

Para no perder ningún detalle durante la adquisición de los volcados he optado por grabar todo el proceso en video usando la función 'Grabar eso', de la 'Barra de juego', que incorpora el propio Sistema Windows 10.

En lo referente a las herramientas testadas, he optado por utilizar algunas de acceso gratuito y de uso más extendido:

* DumpIT, en su versión 3.0.20190124.1
* Magnet RAM Capture, en su versión 1.1.2
Belkasoft Live RAM Capturer
* Memorize, en su versión 3.0
* Winpmem, en su versión 3.2
* FTK Imager Lite, en su versión 3.1.1

Belkasoft Live RAM Capturer



Durante la adquisición de la memoria con esta herramienta, se han levantado dos procesos: El proceso 'RamCapture64.exe', como proceso padre, y un proceso hijo 'conhost.exe'. El proceso 'conhost.exe' es el responsable de abrir instancias para cada consola de Windows. Es decir, por cada consola de Windows que se abra aparecerá un proceso 'conhost.exe'.

El proceso 'RamCapture64.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 1872-1988, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 11476-11672.

El proceso 'conhost.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 7260-7344, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 16768-16816.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema ha sido de 3,150000003 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.


DumpIT



Esta herramienta permite su ejecución de dos modos distintos: directamente desde el propio ejecutable, o desde una consola cmd, donde se permite la configuración de algunos parámetros. Dependiendo de cómo se ejecute la herramienta se podrán encontrar ustedes con unos valores u otros. 

Si optan ustedes por una ejecución de esta herramienta desde el propio ejecutable se podrán encontrar con dos procesos: 'DumpIT.exe', como proceso padre, y un proceso hijo 'conhost.exe'. 

El proceso 'DumpIT.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 1644-1988, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 8980-9028.

El proceso 'conhost.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 7104-7296, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 17132-17200.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema, con este tipo de ejecución, ha sido de 7,716666658 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.


Sin embargo, si optan ustedes por ejecutar esta herramienta desde la consola cmd, donde se permite la configuración de algunos parámetros, se podrán encontrar con el proceso padre 'cmd.exe', con su proceso hijo 'conhost.exe', y con el proceso padre 'DumpIT.exe', con su proceso hijo 'conhost.exe'.

El proceso 'cmd.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 6108-11484, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 14460-16776.

El proceso 'conhost.exe', dependiente del proceso 'cmd.exe', ha presentado un rango de valores de consumo, en su espacio privado, de 8520-8524, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 22180-22284.

El proceso 'DumpIT.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 1688-1776, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 8900-8988.

El proceso 'conhost.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 7192-7280, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 16540-17012.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema, con este tipo de ejecución, ha sido de 4,866666662 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.


*** NOTA RÁPIDA ***

Esta herramienta les proporcionará, al finalizar, un reporte muy interesante con información relativa al KDBG, que les ayudará a identificar de forma correcta el perfil de la memoria, además de información relativa al fichero generado, con un hash SHA256, información de la máquina donde ha sido ejecutada, información del Sistema Operativo e información sobre la versión de la propia herramienta. Información muy importante que debe ser adjuntada al informe final.


********************

FTK Imager Lite



Durante la adquisición de la memoria con esta herramienta, se ha levantado un único proceso con nombre 'FTK Imager.exe'.

Dicho proceso ha presentado un rango de valores de consumo, en su espacio privado, de 21588-22024, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 50764-51744.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema ha sido de 3,583333333 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.



Magnet RAM Capture



Durante la adquisición de la memoria con esta herramienta, se ha levantado un único proceso con nombre 'MagnetRAMCapture.exe'.

Dicho proceso ha presentado un rango de valores de consumo, en su espacio privado, de 9656-10484, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 32812-34296.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema ha sido de 4,066666664 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.



Memorize



Esta herramienta es ejecutada mediante la consola cmd, por lo que se presentan durante la adquisición: un proceso padre 'cmd.exe' con un proceso 'conhost.exe' hijo, y un proceso padre 'Memorize.exe' con un proceso hijo 'conhost.exe'. Además de estos procesos se presenta, al final de la adquisición, un proceso 'netsh.exe', que es una utilidad de línea de comandos, dependiente del proceso 'Memorize.exe'.

El proceso 'cmd.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 5708-11020, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 14512-16320.

El proceso 'conhost.exe', dependiente del proceso 'cmd.exe', ha presentado un rango de valores de consumo, en su espacio privado, de 7604-7688, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 19904-20032.

El proceso 'Memorize.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 3616-3644, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 11860-11960.

El proceso 'conhost.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 7276-8180, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 16804-17924.

El proceso 'netsh.exe', ha presentado un consumo de memoria, en su espacio privado, de 980. En su memoria compartida ha presentado un valor de 120.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema, con este tipo de ejecución, ha sido de 6,583333332 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.



Winpmem



Esta herramienta, que se ejecuta mediante la línea de comandos cmd, presentará un proceso padre 'cmd.exe', con dos procesos dependientes de él: 'conhost.exe' y 'winpmem_3.2.exe'

El proceso 'cmd.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 2828-5920, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 4944-4992.

El proceso 'conhost.exe', dependiente del proceso 'cmd.exe', ha presentado un rango de valores de consumo, en su espacio privado, de 7552-7640, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 20016-20064.

El proceso 'winpmem_3.2.exe' ha presentado un rango de valores de consumo, en su espacio privado, de 1840-3824, como valores mínimo y máximo. En su memoria compartida ha oscilado entre 6720-8948.


El tiempo que ha tardado esta herramienta en adquirir la memoria completa del Sistema ha sido de 5,116666668 minutos, conforme se aprecia en las marcas de tiempo relativas a la creación y modificación de la imagen de memoria.


Esta herramienta permite la captura de la memoria haciendo uso de la red, que se puede llevar a cabo mediante la utilidad Netcat, pero ello se traduciría en levantar otro proceso extraordinario bajo el nombre 'nc.exe' que tendría un consumo de memoria, en su espacio de trabajo privado, de unos 624 K.

*** NOTA RÁPIDA ***

La ejecución de este procedimiento sería mediante las líneas:

winpmem_3.2.exe -m --format raw --output - | nc.exe IP_Destino Puerto
nc.exe -l -p Puerto > C:\Test\Memory_Winpmem_remote.raw

********************

La adquisición


Cualquier herramienta de adquisición de memoria volcará, siempre, la memoria íntegra del Sistema. Todos los ficheros generados presentarán el mismo tamaño, a menos que sean comprimidos o divididos.


En el caso de la adquisición con la herramienta Winpmem, el fichero resultante será de un mayor tamaño al de la memoria del Sistema porque, además de la misma, extrae y adquiere otro tipo de datos. Por ello, el fichero resultante será un fichero '.zip', que es un contenedor que no puede ser analizado directamente y que debe ser descomprimido encontrándose, en su interior, la imagen de la memoria física bajo el nombre de 'PhysicalMemory'.


Me he encontrado con algunos artículos, con algunos comentarios y con algunos rumores, en los que se dice que algunas herramientas dan problemas con tamaños superiores a los 8 GB. Este hecho no es cierto. El principal problema que creo que existe es que no se identifica el perfil de forma correcta. Se debe identificar correctamente el perfil de la imagen antes de proceder con el análisis de la misma. Todas las imágenes de memoria que se crean con las herramientas mostradas en el presente artículo pueden ser analizadas con las herramientas oportunas, como Volatility.


Datos objetivos


Voy a mostrarles ahora los datos objetivos de las pruebas que he llevado a cabo. Y el primer dato que les voy a presentar va a ser el relativo al tiempo: El tiempo, establecido en segundos, que una herramienta tarda en adquirir la memoria del Sistema.


Como podrán observar ustedes, en mis pruebas, la herramienta más rápida ha sido Belkasoft Live RAM Capturer, mientras que la más lenta ha sido DumpIT, mediante la ejecución en el símbolo del sistema, en donde he especificado un tipo de formato y una ruta de salida. No obstante, la herramienta DumpIT, si es ejecutada directamente, sin hacer uso del Símbolo del Sistema, no es la más lenta, dejando ese puesto a Memorize. La diferencia entre la más rápida y la más lenta es de 274 segundos.

Ya les he comentado al principio de este artículo que la memoria está en constante cambio, que presenta información sumamente volátil. Por ello, esa diferencia de 274 segundos existente entre la herramienta más rápida y la más lenta es muchísimo tiempo. En ese tiempo disminuyen las posibilidades de recuperar elementos de interés, como las imágenes que les he puesto como ejemplo anteriormente y que se pudieran encontrar en la memoria.

El siguiente valor que les quiero mostrar a ustedes es el relativo al consumo de memoria, en su espacio de trabajo privado, de cada una de las herramientas probadas.


Dado que la memoria está en constante cambio, los procesos nunca presentarán un valor único. Y ni siquiera presentarán el mismo rango de valores en otra ejecución similar.

En mis pruebas, la herramienta que menos recursos, privados, ha utilizado, ha sido DumpIT, con un valor mínimo de 1644 Kilobytes, frente a los 21588 Kilobytes que ha utilizado FTK Imager Lite. Incluso en los valores máximos, la herramienta DumpIT consume menos recursos, con un valor máximo de 1988 Kilobytes, (igual que la herramienta Belkasoft RAM Capturer), frente a los 22024 Kilobytes de valor máximo de FTK Imager Lite. Pueden ver ustedes que la diferencia entre ambos valores mínimos es de 19944 Kilobytes. Piensen ustedes en la gran cantidad de información que se puede encontrar en ese espacio, y piensen ustedes que la información vital que se puede perder por no pensar en ese tamaño.

Ustedes pueden pensar y creer que basta con esos valores, con esa comparativa, para determinar si elegir una herramienta u otra. Pero también deben pensar en el resto de procesos que son levantados por el Sistema con cada una de las herramientas y en el espacio compartido con otros procesos. Por ello, en la siguiente imagen, (espero que esté bien esquematizada), podrán encontrar ustedes la información correspondiente a esos datos, en donde expongo los valores obtenidos con la suma total del consumo de cada una de las herramientas.


Tal y como pueden apreciar, la herramienta con menos consumo total, en mis pruebas, ha sido DumpIT, con la ejecución directa, si el uso de la consola cmd, con un valor de 24860 Kilobytes. Por el contrario, la herramienta que presenta el mayor consumo es Memorize, con un valor total de 88264 Kilobytes. Están ustedes viendo una diferencia de consumo total de 53404 Kilobytes. ¿Saben ustedes la ingente cantidad de datos que se pueden encontrar con ese tamaño, en ese espacio? Piensen ustedes en qué información pueden guardar en ese tamaño.

Conclusiones


En este artículo les presento sólo unas pequeñas pruebas que he llevado a cabo con algunas de las herramientas de adquisición de memoria que tienen un acceso gratuito y que considero de uso más extendido. Pueden probar ustedes a comparar otras. Algunas pequeñas utilidades, como MDD, o alguna suite forense, como OSForensics.

Dado que la memoria está en constante cambio, ninguna herramienta presentará un único valor, ni en consumo de recursos, ni en tiempo. Tan siquiera presentará el mismo rango de valores en dos ejecuciones distintas. No es posible extraer dos memorias idénticas. Todo depende del caso. Todo depende del Sistema, de lo que se esté ejecutando en ese momento.

Creo que esta es una muy buena manera de comparar la forma en la que trabajan las distintas herramientas, sin realizar valoraciones subjetivas, llenas de intereses u opiniones, puesto que se trata de presentar datos objetivos, con un entorno real.

Pueden seguir ustedes usando la herramienta que les apetezca o pueden ustedes tener presente que, puesto que la memoria presenta información muy volátil, en constante cambio, deben elegir con cuidado qué van a ejecutar y cómo. Pueden valorar únicamente algún factor del uso de las herramientas o pueden tener en cuenta todo lo que hay que valorar: El consumo de memoria que tiene cada una de las herramientas, tanto en su espacio de trabajo privado como en el compartido, el tiempo que invierte cada herramienta en realizar su función, o el hecho de que existan herramientas que facilitan un reporte final, con información del perfil sobre el que se ha trabajado.

Sólo les hago saber que tienen ustedes que elegir bien el arma a usar y calcular el impacto que tiene su uso sobre la memoria del Sistema. Una memoria que se está adquiriendo para realizar sobre ella un estudio. Un estudio que contiene información clave para la resolución de un caso. Información que se va a perder si no se actúa rápidamente y con la herramienta adecuada.

El análisis de la memoria puede ser realmente una labor tediosa pero, sin duda, si se efectúa de una manera correcta los resultados serán altamente positivos y satisfactorios.

Esto es todo.