Windows y su lado antiforense, (Plug and Play Cleanup y setupapi[.]dev)

Hola, secuaces:

El artículo que hoy les presento a ustedes es un trabajo que tenía pendiente de publicar desde hace casi un año... Hoy, por fin, puedo tacharlo de mi lista 'To Do'. Esto son las cosas que tiene ser meramente un curioso en la materia. Que uno sólo puede hacer lo que puede hacer, con los medios que tiene y con el tiempo que del que dispone. Pero no me gusta quedarme con ningún trabajo a medias. Así que he terminado lo que empecé y espero que lo disfruten igual que yo.

Permítanme situarles un poco en los antecedentes de este proyecto, con una breve introducción sobre el cómo surgió el presente trabajo...


Después de la presentación que expuse en el Congreso de Ciberseguridad CONPilar, (el día 28 de abril de 2018), bajo el título "Piénsatelo dos veces antes de meterla", y tras la correspondiente publicación de un muy breve artículo en 'Follow the White Rabbit', (el día 1 de mayo de 2018), Alexis Brignoni tuvo a bien hacerme una observación ese mismo día, mediante un tweet, que me dejó perplejo. En dicho tweet, Alexis menciona que parece ser que a Windows le gusta eliminar entradas de dispositivos USB si no son conectados en 30 días. Acompaña a ese tweet un enlace a un artículo de David Cowen, (publicado el día 19 de abril de 2018), bajo el título "Windows, Now with built in anti forensics!". En dicho artículo, David dice que: "Windows, por sí solo y sin la petición del usuario, está eliminando algunas entradas de dispositivos no utilizados, del Registro, de forma sistemática, impulsado por el programador de tareas". David también hace referencia a la fuente de la noticia pero, desafortunadamente, ya no se encuentra disponible, (http://textlab.io/doc/431305/pdf-version---dpmforensics).

Así pues, me puse manos a la obra y así lo anuncié mediante otro tweet, (el día 4 de mayo de 2018). Levanté algunas máquinas virtuales, instalé varias versiones de Windows e hice las pruebas pertinentes. Terminadas dichas pruebas, se lo hice saber a David mediante otro mensaje, (el día 7 de junio de 2018), porque esa 'nueva' característica de Windows me tenía completamente desconcertado.

Poco tiempo después, (el día 29 de julio de 2018), David publicó un nuevo reto en su Blog, con un interrogante bien claro: "Windows 10 sigue cambiando y con ello su comportamiento. En Windows 8.1 y las primeras versiones de Windows 10 existía la tarea de eliminar los dispositivos plug and play que no se habían conectado durante 30 días. En las versiones más recientes de Windows 10 esto parece estar desactivado. Para este desafío, documente qué versiones de Windows 10 tienen la tarea habilitada y si sobrevive a la actualización."

Yo ya tenía medio trabajo hecho... pero la falta de previsión me llevó por mal camino. No tuve en consideración el espacio de disco duro que es necesario para las actualizaciones y me quedé corto asignando un tamaño de disco adecuado. (Vuelta a empezar con las pruebas).

Pero... no hay mal que por bien no venga, porque Adam Harrison hizo un excelente trabajo publicando una resolución al reto, en su Blog, (el día 30 de julio de 2018), con el artículo "Windows Plug and Play Cleanup".

He creído oportuno exponerles esta breve cronología para que vean ustedes que, a veces, hay grandes trabajos, proyectos e ideas, que surgen de una mera observación, de un pequeño comentario.

Dicho esto,

Según parece, nos encontramos ante una tarea programada que eliminará todos los dispositivos que no hayan estado conectados durante 30 días. ¿Cómo? ¿Una nueva característica anti forense en Windows? Esto, atenta contra mi curiosidad


Plug and Play Cleanup


'Plug and Play Cleanup' es una tarea programada que viene integrada con algunas versiones de Windows 10. Es creada por el propio Sistema y es ejecutada con el usuario System. Esta tarea dice en su descripción, textualmente: "Windows conserva copias de todos los paquetes de controladores de dispositivos instalados antes desde Windows Update y otras fuentes, incluso después de instalar versiones más recientes de los controladores. Esta tarea quitará las versiones anteriores de los controladores que ya no se necesiten. Se conservará la versión más reciente de cada paquete de controladores. También quitará el estado usado por los dispositivos que lleven mucho tiempo sin detectarse en el Sistema."

Para entender cómo funciona la tarea programada, hay que estudiarla. Windows crea para cada tarea programada un fichero que es alojado en la ruta '%systemroot%\system32\Tasks\'. En este caso, el fichero de la tarea se encuentra en:
%systemroot%\System32\Tasks\Microsoft\Windows\Plug and Play\Plug and Play Cleanup

Si es abierto con un visor adecuado puede ser estudiado cómodamente y se pueden ver claramente diversos apartados y campos con distintos valores. 

Lo primero que se puede apreciar es que hace referencia a un fichero que lleva por nombre 'pnpclean.dll', (del que les hablaré un poquito más adelante), que se encuentra en:
%SystemRoot%\system32\pnpclean.dll
Según el sitio de Microsoft, existen dos versiones de tareas: 1.0 y 2.0. La versión de esta tarea se corresponde a la 1.0.

El campo que lleva por nombre 'RunLevel', presenta un valor de 'HighestAvailable' e indica que, conforme al sitio de Microsoft, la tarea va a ser ejecutada con los permisos de usuario más altos disponibles, (usuario System).

El campo que lleva por nombre 'ExecutionTimeLimit', presenta un valor de 'PT1H' e indica que, conforme al sitio de Microsoft, la tarea se ejecutará durante un tiempo máximo de una hora.

El campo que lleva por nombre 'UseUnifiedSchedulingEngine', presenta un valor de 'true' e indica que, conforme al sitio de Microsoft, se utilizará el motor de programación unificada para realizar la tarea.

Dentro del apartado 'MaintenanceSettings' se pueden ver dos campos. El campo 'Period', que presenta un valor de 'P1M', indica que, conforme al sitio de Microsoft, la tarea se ejecutará una vez al mes durante el mantenimiento automático. El campo 'Deadline', que presenta un valor de 'P2M', indica que, conforme al sitio de Microsoft, la tarea se ejecutará una vez cada dos meses durante el mantenimiento automático de emergencia, si no se ha podido completar durante el mantenimiento automático regular.

Si lo desean, pueden ver la documentación oficial de Microsoft existente sobre los ajustes de mantenimiento.

El fichero 'pnpclean.dll', al que hace referencia la tarea, es el responsable de llevar a cabo la eliminación de los dispositivos y controladores 'antiguos' que no son usados, (según el Sistema).


Este fichero se localiza en la ruta:
%SystemRoot%\system32\pnpclean.dll
Este fichero se encarga de buscar dispositivos y controladores que no han sido conectados y usados recientemente y que pueden ser eliminados del Sistema.


Les recuerdo a ustedes que un atacante con privilegios podría ejecutar este fichero para tratar de eliminar algunas evidencias, haciendo uso de:
rundll32.exe pnpclean.dll,RunDLL_PnpClean /DEVICES /DRIVERS /MAXCLEAN


Les puedo garantizar a ustedes que muchos de esos dispositivos que han sido eliminados los uso con frecuencia.

El entorno de pruebas

Para arrojar un poco más de luz sobre este comportamiento, un poco oscuro, de Windows he optado por realizar instalaciones limpias de las siguientes versiones de Windows 10, virtualizadas bajo VirtualBox:
  • Versión 1507, OS build 10240.16384
  • Versión 1607, OS build 14393.0
  • Versión 1709, OS build 16299.15
  • Versión 1803, OS build 17127.1
  • Versión 1803, OS build 17134.1
  • Versión 1803, OS build 17134.112
Después de completar la instalación, he decidido llevar a cabo una serie de pasos comunes a todas las versiones probadas:
  • Comprobar la existencia de la tarea 'Plug and Play Cleanup'
  • Instalar un único dispositivo USB en todas las máquinas, (número de serie 070B59BB1CB2234)
  • Extraer los siguientes ficheros con FTK Imager Lite:
    • Plug and Play Cleanup
    • pnpclean.dll
    • setupapi.dev.log
    • System
  • Actualizar todos los sistemas a la última versión disponible
  • 'Viajar al futuro', cambiando la fecha del Sistema
  • Volver a extraer los mismos ficheros que antes de la actualización
He tenido en cuenta la fecha de creación de los ficheros 'Plug and Play Cleanup' y 'pnpclean.dll', así como la versión de los ficheros '.dll' y he comparado su contenido calculando el valor hash en MD5, usando la herramienta HasMyFiles.

Todos los sistemas han sido actualizados a la OS build 17134.619, a excepción de la OS build 10240, que ha sido actualizada a la 17763.316, (por razones que desconozco).

Pueden consultar ustedes la versión, la fecha de lanzamiento y otra información relativa a las distintas versiones en el sitio oficial de Microsoft.

Las pruebas

OS build 10240.16384

Esta versión presenta la tarea programada.

El fichero 'Plug and Play Cleanup' presenta un valor hash de a637c76f51d93371487db5b64e1333a6.

El fichero 'pnpclean.dll' presenta una fecha de creación de 10/07/2015 8:23:38, una versión de 10.0.10240.16384 y un valor hash de 3b24ac437d7ea0df8bde0d7cfbc5d6ad.

Tras efectuar la actualización,

El fichero 'Plug and Play Cleanup' original ha sido movido a "Windows\System32\Tasks_Migrated\Microsoft\Windows\Plug and Play\" y ocupa su lugar otro fichero con el mismo valor hash de a637c76f51d93371487db5b64e1333a6.

El fichero 'pnpclean.dll' original ya no se encuentra en el Sistema. Ocupa su lugar otro fichero, con una fecha de creación de 15/09/2018 5:07:07, con una versión de 10.0.17763.1 y con un valor hash de 5bc372bd55b3c1506f9ffabda9f11639. También se encuentra otro fichero 'pnpclean.dll' en la ruta "Windows.old\System32\", que presenta una fecha de creación de 30/09/2016 3:13:53, con una versión de 10.0.10240.17146 y un valor hash de c8703a9e0c5ca37439a37a0af3a535e7.


En esta versión, la tarea programada sigue estando habilitada después de la actualización.

OS build 14393.0

Esta versión presenta la tarea programada.

El fichero 'Plug and Play Cleanup' presenta un valor hash de a637c76f51d93371487db5b64e1333a6.

El fichero 'pnpclean.dll' presenta una fecha de creación de 16/07/2016 11:42:16, una versión de 10.0.14393.0 y un valor hash de e8ac0747384c96c23ca5e84ee79492bd.

Tras efectuar la actualización,

El fichero 'Plug and Play Cleanup' original ha sido movido a "Windows\System32\Tasks_Migrated\Microsoft\Plug and Play\" y ocupa su lugar otro fichero con el mismo valor hash de a637c76f51d93371487db5b64e1333a6.

El fichero 'pnpclean.dll' original ya no se encuentra en el Sistema. Ocupa su lugar otro fichero, con una fecha de creación de 11/04/2018 23:34:32, con una versión de 10.0.17134.1 y con un valor hash de 4fa8d3cb0ef46be97cd4314617db94dc. También se encuentra otro fichero 'pnpclean.dll' en la ruta "Windows.old\System32\", que presenta una fecha de creación de 16/07/2016 11:42:16, con una versión de 10.0.14393.0 y un valor hash de e8ac0747384c96c23ca5e84ee79492bd.


En esta versión, la tarea programada sigue estando habilitada después de la actualización.

OS build 16299.15

Esta versión no presenta la tarea programada.

El fichero 'pnpclean.dll' presenta una fecha de creación de 29/09/2018 13:41:56, una versión de 10.0.16299.15 y un valor hash de c2374548a0b171794628a136cf4507da.

Tras efectuar la actualización,

El fichero 'pnpclean.dll' original ya no se encuentra en el Sistema. Ocupa su lugar otro fichero, con una fecha de creación de 11/04/2018 23:34:32, con una versión de 10.0.17134.1 y con un valor hash de 4fa8d3cb0ef46be97cd4314617db94dc. También se encuentra otro fichero 'pnpclean.dll' en la ruta "Windows.old\System32\", que presenta una fecha de creación de 29/09/2017 13:41:56, con una versión de 10.0.16299.15 y un valor hash de c2374548a0b171794628a136cf4507da.


OS build 17127.1

Esta versión no presenta la tarea programada.

El fichero 'pnpclean.dll' presenta una fecha de creación de 18/03/2018 17:29:24, una versión de 10.0.17127.1 y un valor hash de 8eb85239c3e8e7bb8dd070b722e60da.

Tras efectuar la actualización,

El fichero 'pnpclean.dll' original ya no se encuentra en el Sistema. Ocupa su lugar otro fichero, con una fecha de creación de 11/04/2018 23:34:32, con una versión de 10.0.17134.1 y con un valor hash de 4fa8d3cb0ef46be97cd4314617db94dc. También se encuentra otro fichero 'pnpclean.dll' en la ruta "Windows.old\System32\", que presenta una fecha de creación de 18/03/2018 17:29:24, una versión de 10.0.17127.1 y un valor hash de 8eb85239c3e8e7bb8dd070b722e60da.


OS build 17134.1

Esta versión no presenta la tarea programada.

El fichero 'pnpclean.dll' presenta una fecha de creación de 11/04/2018 23:34:32, una versión de 10.0.17137.1 y un valor hash de 4fa8d3cb0ef46be97cd4314617db94dc.

Tras efectuar la actualización,

El fichero 'pnpclean.dll' presenta exactamente las mismas características que antes de la actualización.


OS build 17134.112

Esta versión no presenta la tarea programada.

El fichero 'pnpclean.dll' presenta una fecha de creación de 11/04/2018 23:34:32, una versión de 10.0.17134.1 y un valor hash de 4fa8d3cb0ef46be97cd4314617db94dc.

Tras efectuar la actualización,

El fichero 'pnpclean.dll' presenta exactamente las mismas características que antes de la actualización.



Resultados

A continuación les expongo los resultados que he obtenido en una tabla, dividida en dos partes por cuestiones de tamaño, (y por ende para una mayor comprensión). La primera parte se corresponde la información de antes de la actualización de los sistemas y la segunda parte se corresponde con la información relativa a los sistemas una vez actualizados.



Tal y como pueden apreciar ustedes, en mis pruebas, las versiones que cuentan con la tarea programada son las 1507, (10240), y 1607, (14393). A partir de la versión 1709, inclusive, no se presenta la tarea programada.

Las tareas programadas existentes son idénticas en todos los sistemas que la tienen activada y, además, persisten después de la actualización, puesto que siguen estando presentes.

En una instalación limpia, cada versión del Sistema Operativo cuenta con su propia versión del fichero 'pnpclean.dll', que es modificado cuando se actualiza la versión.

Todos los sistemas, una vez actualizados, (a excepción de la versión 1507 que presenta alguna peculiaridad), presentan la misma versión del fichero 'pnpclean.dll', creado el 11 de abril de 2018.

A partir de la versión 1803, (17134.1), lanzada el 11 de abril de 2018, se presenta la misma versión del fichero 'pnpclean.dll' en todos los sistemas, que no sufren cambios en su actualización.

Un par de pecualiaridades

Durante la ejecución de mis pruebas he podido observar un par de peculiaridades.

He podido leer en algunos artículos que los dispositivos son eliminados cuando no han sido conectados en 30 días, cuando se ejecuta la tarea. Según he podido ver en mis pruebas, esto no es así.

Para entender este funcionamiento debemos entender cuándo entra en funcionamiento. Tal y como he expuesto anteriormente, la tarea 'Plug and Play Cleanup' es ejecutada una vez al mes, durante el mantenimiento automático o una vez cada dos meses, durante el mantenimiento de emergencia, si falla el mantenimiento automático. Por lo tanto, hay que tener en cuenta cómo se produce el mantenimiento automático, que pueden consultar en el sitio oficial de Microsoft. Deben saber ustedes que es el Sistema quien elige cuándo se ejecuta el mantenimiento automático, cuando se encuentra encendido o en reposo y, por defecto, se lleva a cabo de forma diaria, (a las 3 AM), con una duración máxima de una hora.

Cuando la tarea se ejecuta, ésta, siempre llama al fichero 'pnpclean.dll'. El Sistema considera exitosa la ejecución de la tarea aunque se muestre un error en ella. Y si la tarea presenta después de su ejecución el código 0x0 significa, según el sitio de Microsoft, que la tarea ha sido ejecutada satisfactoriamente.

Todas las tareas que programa el propio Sistema Windows presentan una fecha de última ejecución de 30 de noviembre de 1999.

Para realizar las pruebas de ejecución de la tarea he optado por realizar varios 'viajes al futuro', cambiando la fecha del Sistema.

Adelanto la fecha del Sistema, (que se encuentra aislado de la red), hasta el día 28 de marzo para dejarlo inactivo. La tarea se ha ejecutado tras 10 minutos de inactividad, el día 28 de marzo, a las 07.52.11 horas.


Nuevamente, adelanto la fecha del Sistema hasta el día 15 de abril para dejarlo nuevamente inactivo. La tarea es ejecutada ese día, a las 08.05.58 horas.


Realizo un último 'viaje al futuro', adelantando la fecha del Sistema al día 10 de mayo para dejarlo inactivo por última vez, hasta la ejecución de la tarea, que se produce a las 09.06.48 horas.


Todas estas acciones que lleva a cabo esta tarea programada se pueden apreciar en el log 'setupapi.dev.log', que es el encargado de registrar las instalaciones y desinstalaciones de controladores.


(En este caso no se elimina nada porque no hay nada que eliminar).

Con esto se puede deducir que no hace falta que transcurran 30 días desde el último uso de un controlador o de un dispositivo, aunque no puedo, a día de hoy, determinar la frecuencia exacta de su ejecución.

Otra peculiaridad con la que me he encontrado está relacionada con la versión 10240 de Windows que, además de tener la tarea programada 'Plug and Play Cleanup' habilitada y con persistencia después de su actualización, no registra los controladores de dispositivos conectados en su log 'setupapi.dev.log'.

Conecto el dispositivo 070B59BB1CB22334 al Sistema actualizado, de la versión 10240 a la la versión 17763, el día 25 de febrero de 2019, a las 09.52.55.


Y procedo a examinar el log 'setupapi.dev.log', donde no encuentro dicho dispositivo conectado.


Esta versión actualizada de la 10240 no graba los dispositivos USB en ese fichero, aunque sí he encontrado esos valores en el log 'setupapi.upgrade.log', en el apartado correspondiente al de configuración de la migración PnP.


Visto este detalle, opto por hacer una serie de pruebas con la versión 10240 limpia y aislada de la red. Conecto ese mismo dispositivo y vuelvo a estudiar el log 'setupapi.dev.log', con resultado negativo.


Así pues, al menos esta versión de Windows, no graba los dispositivos USB en el log correspondiente.

Conclusiones

Son varias las conclusiones que se me ocurren...

La primera de ellas es que, si ustedes tienen pensado publicar un trabajo pero otra persona se les ha adelantado y ya se encuentra publicado, publíquenlo igualmente porque eso servirá para dos cosas:
  • Reconocer el trabajo de otras personas. (Eso es bueno)
  • Validar pruebas de otras personas. (Eso es bueno)
La colaboración, de forma directa o indirecta, es muy buena para buscar resultados.

Otra conclusión que saco es que, cada vez más, se hace necesario conocer la versión original del sistema instalado porque es posible que nos encontremos con casos en los que no se graban los dispositivos USB que se conectan, (como ocurre con la versión 10240), o con casos en los que estos son eliminados junto a sus controladores, por acción del propio sistema o por acción del usuario.

Si nos encontramos con una carpeta 'Windows.old', se debe estudiar porque es posible que lo que estamos buscando se encuentre ahí, si los controladores y dispositivos han sido conectados antes de una actualización. No hay que olvidar que existen algunas herramientas forenses que basan su funcionamiento la búsqueda de datos de los ficheros afectados por la tarea 'Plug and Play Cleanup'.

Puedo confirmar las pruebas que hizo Adam en su artículo y decir que la última versión que incluía la tarea 'Plug and Play Cleanup' ha sido la 1607, dejando de estar presente en las siguientes versiones. También puedo decir que el fichero encargado de efectuar esa 'limpieza', el fichero 'pnpclean.dll', presenta una estabilidad desde la versión 17134.1, puesto que no varía con las siguientes versiones. 

No podemos descartar que, conforme avanzan y cambian las versiones de Windows, es posible que volvamos a encontrar la tarea 'Plug and Play Cleanup'.

Si les ha gustado este pequeño trabajo, háganmelo saber. (Eso es bueno).

Eso es todo.

spacer

Windows and its anti-forensic side, (Plug and Play Cleanup and setupapi[.]dev)

Hi, minions:

The article that I present to you today is a work that I had pending to publish for almost a year... Today, at last, I can cross it off my 'To Do' list. These are the things that have to be merely a curious in the matter. That you can only do what you can do, with the means you have and with the time you have. But I don't like to be with a half-hearted job. So I've finished what I started and I hope you enjoy it as much as I do.

Let me put you a little in the background of this project, with a brief introduction on how this work came about...


After my presentation at the CONPilar Cybersecurity Congress, (April 28, 2018), under the title "Think twice before you insert it", and after the corresponding publication of a very brief article in 'Follow the White Rabbit', (May 1, 2018), Alexis Brignoni was kind enough to make an observation that same day, by means of a tweet, which perplexed me. In that tweet, Alexis mentions that it seems that Windows likes to remove entries from USB devices if they are not connected in 30 days. Accompanying this tweet is a link to an article by David Cowen, (published on April 19, 2018), under the title "Windows, Now with built in anti forensics!". In that article, David says that: "Windows, by itself and without the user's request, is systematically removing some unused device entries from the Registry, driven by the task scheduler". David also refers to the source of the news but, unfortunately, is no longer available, (http://textlab.io/doc/431305/pdf-version---dpmforensics).

So I set to work and announced it in another tweet, (May 4, 2018). I lifted some virtual machines, installed several versions of Windows and made the relevant tests. Once these tests were finished, I let David know by means of another message, (on June 7, 2018), because this 'new' feature of Windows had me completely confused.

Shortly after, (July 29, 2018), David posted a new challenge in his Blog, with a very clear question: "Windows 10 keeps changing and with it its behavior. In Windows 8.1 and the first versions of Windows 10 there was the task of removing plug and play devices that had not been connected for 30 days. In the most recent versions of Windows 10 this seems to be disabled. For this challenge, document which versions of Windows 10 have the task enabled and whether it survives the upgrade."

I already had half a job done... but the lack of foresight led me astray. I didn't consider the hard disk space needed for upgrades and fell short of assigning an appropriate disk size. (Back to start with testing).

But... there is no evil that for good does not come, because Adam Harrison did an excellent job publishing a resolution to the challenge, in his Blog, (on July 30, 2018), with the article "Windows Plug and Play Cleanup".

I thought it appropriate to give you this brief chronology so that you can see that, at times, there are great works, projects and ideas, which arise from a mere observation, from a small comment.

That said,

Apparently, this is a scheduled task that will remove all devices that haven't been connected for 30 days. How? A new anti-forensics feature in Windows? That's against my curiosity.


Plug and Play Cleanup


'Plug and Play Cleanup' is a scheduled task that comes integrated with some versions of Windows 10. It is created by the System itself and is executed with the System user. This task says in its description, verbatim: "Windows keeps copies of all device driver packages installed before from Windows Update and other sources, even after installing newer versions of the drivers. This task will remove older versions of drivers that are no longer needed. The most recent version of each driver package will be preserved. It will also remove the status used by devices that have not been detected in the System for a long time".

To understand how the scheduled task works, you need to study it. Windows creates for each scheduled task a file that is hosted in the path "%systemroot%\system32\Tasks\". In this case, the task file is in:
%systemroot%\System32\Tasks\Microsoft\Windows\Plug and Play\Plug and Play Cleanup

If it is opened with a suitable viewfinder it can be studied comfortably and different sections and fields with different values can be clearly seen. 

The first thing you can see is that it refers to a file called 'pnpclean.dll', (which I will tell you a little later), which is in:
%SystemRoot%\system32\pnpclean.dll
According to the Microsoft site, there are two versions of tasks: 1.0 and 2.0. The version of this task corresponds to 1.0.

The field named 'RunLevel', has a value of 'HighestAvailable' and indicates that, according to the Microsoft site, the task will be executed with the highest user permissions available, (System user).

The field named 'ExecutionTimeLimit' has a value of 'PT1H' and indicates that, according to the Microsoft site, the task will be executed for a maximum time of one hour.

The field named 'UseUnifiedSchedulingEngine' has a value of 'true' and indicates that, according to Microsoft's site, the unified programming engine will be used to perform the task.

In the 'MaintenanceSettings' section you can see two fields. The 'Period' field, which has a value of 'P1M', indicates that, according to Microsoft's site, the task will be executed once a month during automatic maintenance. The 'Deadline' field, which has a value of 'P2M', indicates that, according to the Microsoft site, the task will be executed once every two months during the emergency automatic maintenance, if it could not be completed during the regular automatic maintenance.

If you wish, you can view the existing official Microsoft documentation on maintenance settings.

The file 'pnpclean.dll', to which the task refers, is responsible for carrying out the removal of unused 'old' devices and drivers (depending on the System).


This file is located in the path:
%SystemRoot%\system32\pnpclean.dll
This file searches for devices and drivers that have not been connected and used recently and can be removed from the System.


I remind you that an attacker with privileges could run this file to try to remove some evidence, making use of:
rundll32.exe pnpclean.dll,RunDLL_PnpClean /DEVICES /DRIVERS /MAXCLEAN

I can assure you that many of those devices that have been eliminated use them frequently.


The test environment

To shed a little more light on this behavior, a little dark, of Windows I have chosen to perform clean installations of the following versions of Windows 10, virtualized under VirtualBox
  • Version 1507, OS build 10240.16384
  • Version 1607, OS build 14393.0
  • Version 1709, OS build 16299.15
  • Version 1803, OS build 17127.1
  • Version 1803, OS build 17134.1
  • Version 1803, OS build 17134.112
After completing the installation, I have decided to carry out a series of steps common to all tested versions:
  • Check the existence of the 'Plug and Play Cleanup' task
  • Install a single USB device on all machines, (serial number 070B59BB1CB2234)
  • Extract the following files with FTK Imager Lite:
    • Plug and Play Cleanup
    • pnpclean.dll
    • setupapi.dev.log
    • System
  • Upgrade all systems to the latest version available
  • 'Travelling to the future', changing the date of the System
  • Re-extract the same files as before the update
I have taken into account the creation date of the 'Plug and Play Cleanup' and 'pnpclean.dll' files, as well as the version of the '.dll' files and compared their contents by calculating the hash value in MD5, using the HasMyFiles tool.

All systems have been updated to OS build 17134.619, except for OS build 10240, which has been updated to 17763.316, (for reasons I don't know).

You can check the version, release date and other information about the different versions on Microsoft's official site.

The tests

OS build 10240.16384

This version presents the scheduled task.

The 'Plug and Play Cleanup' file has a hash value of a637c76f51d93371487db5b64e1333a6.

The file 'pnpclean.dll' has a creation date of 10/07/2015 8:23:38, a version of 10.0.10240.16384 and a hash value of 3b24ac437d7ea0df8bde0d7cfbc5d6ad.

After the update,

The original 'Plug and Play Cleanup' file has been moved to "Windows\System32\Tasks_Migrated\Microsoft\Windows\Plug and Play\" and another file with the same hash value of a637c76f51d93371487db5b64e1333a6 takes its place.

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 15/09/2018 5:07:07, with a version of 10.0.17763.1 and a hash value of 5bc372bd55b3c1506f9ffabda9f11639. There is also another file 'pnpclean.dll' in the path "Windows.old\System32\", which presents a creation date of 30/09/2016 3:13:53, with a version of 10.0.10240.17146 and a hash value of c8703a9e9c5ca37439a37a0af3a535e7.


In this version, the scheduled task is still enabled after the update.

OS build 14393.0

This version presents the scheduled task.

The 'Plug and Play Cleanup' file has a hash value of a637c76f51d93371487db5b64e1333a6.

The file 'pnpclean.dll' has a creation date of 16/07/2016 11:42:16, a version of 10.0.14393.0 and a hash value of e8ac0747384c96c23ca5e84ee79492bd.

After the update,

The original 'Plug and Play Cleanup' file has been moved to "Windows\System32\Tasks_Migrated\Microsoft\Plug and Play\" and another file with the same hash value of a637c76f51d93371487db5b64e1333a6 takes its place.

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. There is also another file 'pnpclean.dll' in the path "Windows.old\System32\", which presents a creation date of 16/07/2016 11:42:16, with a version of 10.0.14393.0 and a hash value of e8ac0747384c96c96c23ca5e84ee79492bd.


In this version, the scheduled task is still enabled after the update.

OS build 16299.15

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 29/09/2018 13:41:56, a version of 10.0.16299.15 and a hash value of c2374548a0b171794628a136cf4507da.

After the update,

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. Another file 'pnpclean.dll' is also found in the path "Windows.old\System32\", which presents a creation date of 29/09/2017 13:41:56, with a version of 10.0.16299.15 and a hash value of c2374548a0b171794628a136cf4507da.



OS build 17127.1

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 18/03/2018 17:29:24, a version of 10.0.17127.1 and a hash value of 8eb85239c3e8e7bb8dd070b722e60da.

After the update,

The original 'pnpclean.dll' file is no longer in the System. Another file takes its place, with a creation date of 11/04/2018 23:34:32, with a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc. Another file 'pnpclean.dll' is also found in the path "Windows.old\System32\", which presents a creation date of 18/03/2018 17:29:24, a version of 10.0.17127.1 and a hash value of 8eb85239c3e8e7bb8dd070b722e60da.


OS build 17134.1

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 11/04/2018 23:34:32, a version of 10.0.17137.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc.

After the update,

The file 'pnpclean.dll' has exactly the same features as before the update.


OS build 17134.112

This version does not have the scheduled task.

The file 'pnpclean.dll' has a creation date of 11/04/2018 23:34:32, a version of 10.0.17134.1 and a hash value of 4fa8d3cb0ef46be97cd4314617db94dc.

After the update,

The file 'pnpclean.dll' has exactly the same features as before the update.



Results

Here are the results I have obtained in a table, divided into two parts by size, (and therefore for greater understanding). The first part corresponds to the information before the update of the systems and the second part corresponds to the information related to the systems once they have been updated.



As you can see, in my tests, the versions with the scheduled task are 1507, (10240), and 1607, (14393). As of version 1709, inclusive, the scheduled task is not presented.

The existing scheduled tasks are identical in all systems that have it activated and, in addition, they persist after the update, since they are still present.

In a clean installation, each version of the Operating System has its own version of the file 'pnpclean.dll', which is modified when the version is updated.

All systems, once updated, (with the exception of version 1507, which has some peculiarities), present the same version of the file 'pnpclean.dll', created on 11 April 2018.

From version 1803, (17134.1), launched on 11 April 2018, the same version of the file 'pnpclean.dll' is presented in all systems, which do not undergo changes in their update.

A couple of pecualities

During the execution of my tests I was able to observe a couple of peculiarities.

I could read in some articles that the devices are removed when they have not been connected in 30 days, when the task is executed. As I have seen in my tests, this is not the case.

To understand this operation we must understand when it comes into operation. As I have explained before, the 'Plug and Play Cleanup' task is performed once a month, during automatic maintenance or once every two months, during emergency maintenance, if automatic maintenance fails. Therefore, you have to take into account how the automatic maintenance occurs, which can be consulted on the official Microsoft site. You should know that it is the System that chooses when the automatic maintenance is executed, when it is on or at rest and, by default, it is carried out daily, (at 3 AM), with a maximum duration of one hour.

When the task runs, it always calls the file 'pnpclean.dll'. The System considers the execution of the task successful even if an error is shown in it. And if the task presents after its execution the code 0x0 means, according to the Microsoft site, that the task has been executed successfully.

All the tasks programmed by the Windows System itself have a last execution date of 30 November 1999.

In order to carry out the tests of execution of the task I have chosen to carry out several 'trips to the future', changing the date of the System.

I advance the date of the System, (which is isolated from the network), until March 28 to leave it inactive. The task was executed after 10 minutes of inactivity, on March 28, at 07.52.11 hours.



Again, I bring forward the date of the System until April 15 to leave it again inactive. The task is executed that day, at 08.05.58 hours.


I make a last 'trip to the future', bringing forward the date of the System to May 10 to leave it inactive for the last time, until the execution of the task, which occurs at 09.06.48 hours.


All these actions carried out by this scheduled task can be seen in the log 'setupapi.dev.log', which is in charge of registering driver installations and uninstallations.


(In this case nothing is eliminated because there is nothing to eliminate).

This means that there is no need to be 30 days after the last use of a driver or a device, although I cannot, as of today, determine the exact frequency of its execution.

Another peculiarity that I have come across is related to version 10240 of Windows which, besides having the programmed task 'Plug and Play Cleanup' enabled and with persistence after its update, does not register the drivers of connected devices in its log 'setupapi.dev.log'.

I connect device 070B59BB1CB22334 to the updated System, from version 10240 to version 17763, on February 25, 2019, at 09.52.55.


And I proceed to examine the log 'setupapi.dev.log', where I can't find the device connected.


This updated version of the 10240 does not save the USB devices in that file, although I have found those values in the log 'setupapi.upgrade.log', in the section corresponding to the PnP migration configuration.


Given this detail, I choose to do a series of tests with the 10240 version clean and isolated from the network. I connect that same device and study again the log 'setupapi.dev.log', with negative result.


Thus, at least this version of Windows does not save the USB devices in the corresponding log.

Conclusions

There are several conclusions I can think of...

The first of them is that, if you are planning to publish a work but another person has anticipated it and it is already published, publish it as well because that will serve for two things:
  • Recognize other people's work. (That's good)
  • Validate other people's tests. (That's good)
Collaboration, directly or indirectly, is very good for seeking results.

Another conclusion I draw is that, more and more, it is necessary to know the original version of the installed system because it is possible that we find cases in which the USB devices that are connected are not recorded, (as happens with version 10240), or cases in which these are eliminated together with their controllers, by the action of the system itself or by the action of the user.

If you find a 'Windows.old' folder, you should study it because it is possible that what you are looking for is there, if the drivers and devices have been connected before an update. Don't forget that there are some forensic tools that base their operation on finding data from the files affected by the 'Plug and Play Cleanup' task.

I can confirm the tests that Adam did in his article and say that the last version that included the task 'Plug and Play Cleanup' has been the 1607, ceasing to be present in the following versions. I can also say that the file in charge of this 'cleaning', the file 'pnpclean.dll', has a stability since version 17134.1, since it does not vary with the following versions. 

We can't rule out that, as Windows versions progress and change, we may find the 'Plug and Play Cleanup' task again.

If you liked this little job, let me know. (That's good).

That's all.

spacer

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 memoryit 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
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.

spacer