15 Abr Wintriage: Publicada la versión 30032024 / Released version 30032024
ACTUALIZACIÓN!/ UPDATE!
Nueva versión con una actualización importante: 28042024
¡Llega una nueva versión de WinTriage 30032024!
The latest release of Wintriage 30032024 is here! (English version here).
La prueba de que Wintriage es un proyecto vivo es que seguimos y seguimos publicando nuevas versiones que corrigen errores que detectamos (o detectáis y nos lo comunicáis), así como nuevas funcionalidades, todo con la intención de que tengamos una herramienta lo más robusta, versátil y completa posible.
La solución de bugs y mejoras de rendimiento que hemos introducido en esta ocasión han sido los siguientes:
- En la versión 30072023 ya eliminamos que se hiciera por defecto la detección de ADS (Alternate Data Streams) en los sistemas de ficheros, debido a la cantidad de tiempo que esto consumía, respecto a poderlo mirar en un análisis de la $MFT, algo que, sin duda, es algo que nos toca hacer en un amplio porcentaje de incidentes. Por este mismo motivo hemos eliminado la ejecución de los comandos que generaban un listado completo del sistema de ficheros. Es decir, dado que nos va a tocar analizar la $MFT y es un artefacto forense que vamos a tener nuestra disposición, preferimos acelerar el proceso de extracción minimizando la cantidad de comandos que consumen un alto volumen de tiempo. Así, hemos logrado reducir la extracción de evidencias en un servidor de ficheros en unos 3-5 minutos de media.
- En la versión anterior de Wintriage, implementamos la utilización de Dumpit en vez de Ramcapture para generar un volcado de la memoria RAM de la máquina, dado que la ejecución de Ramcapture desde una unidad mapeada (ya sea por SMB o por TSClient) no funcionaba correctamente. Esto hacía que no tuviéramos que descargar las dependencias de RamCapture en el directorio «Tools». Pues nos hemos dado cuenta de que la última versión de Dumpit existente para descarga no funciona correctamente en sistemas Windows 2003/XP/7/2008. Probando con versiones anteriores de Dumpit, estas no estaban pensadas para ejecución no-interactiva, mediante parámetros como /Q y /O, por lo que no podemos utilizar una versión compatible con versiones antiguas de Windows tampoco. Así, hemos vuelto a incluir como requerimiento auxiliar los cuatro ficheros de RamCapture (los dos ejecutables y los dos drivers con extensión .sys) y adicionalmente hemos dejado los ficheros de Dumpit. En caso de que hagas una extracción de un sistema Windows 2003/XP/7/2008, te recomendamos que lo hagas en local, puesto que se utilizará Ramcapture. Sin embargo, en el caso que la hagas en un sistema más moderno que los indicados se utilizará Dumpit, siendo esto ya funcional se ejecute en local o desde unidad de red mapeada.
- Hemos solucionado un bug que mostraba un pop-up de error bastante feo en caso de extracción offline (partiendo de una imagen forense de un disco) de artefactos de usuario, al llegar al «Default User».
Como nuevos artefactos forenses ahora Wintriage extrae los siguientes:
- Como artefactos de usuario, en el NTUSER.DAT suele haber una sección correspondiente a los últimos servidores a los que se ha conectado el usuario a través de la aplicación de Escritorio Remoto nativa a Windows. Sin embargo, si el usuario ha utilizado la aplicación Remote Desktop, este listado de servidores no queda en el NTUSER.DAT, sino en otra localización.
Esto, lo explican estupendamente en este enlace de ZEROFOX, en el que se ve la imagen anterior.
Hemos implementado que, si un usuario ha utilizado esta herramienta, los artefactos forenses que guardan la información relevante a la misma, se deje en el directorio del usuario, extraído por Wintriage.
Tras leer otro interesante artículo de Zerofox, relacionado en este caso con la tecnología de paquetes MSIX de Microsoft, se observa que aquellas aplicaciones que hacen uso de dicho formato de paquetes, generan información forense bajo un subdirectorio llamado «SystemAppData\Helium» en el que se puede rescatar ciertos ficheros que, tras su tratamiento, permiten identificar ficheros abiertos con esa aplicación, y directorios navegados con la misma (shellbags), algo que no tendríamos de otra manera. Así, que implementamos que Wintriage, cuando le dices que extraiga información forense de usuarios, busca en todos los directorios de AppData\Local\Packages de cada usuario, si hay alguno de los ficheros que cumplen con esto. En caso de que así sea, genera dentro del directorio del usuario extraído por Wintriage, un directorio por cada aplicación en la que haya información forense MSIX.
Como siempre, puedes descargar gratuitamente Wintriage desde https://cursos.securizame.com/extra/wintriage.7z
El hash SHA-256 de esta versión es f0f2b34b79782ec05887bebd4f8e1f9be30551ce9bd4e5e826c06cca508d5c41
- Wintriage: la herramienta de triage para el dfirer en Windows
- Wintriage 20092020 (20/09/2020)
- Wintriage 24022021 (24/02/2021)
- Wintriage 30102021 (30/10/2021)
- Wintriage 02012022 (02/01/2022)
- Wintriage 18092022 (18/09/2022)
- Wintriage 09042023 (09/04/2023)
- Wintriage 30032024 (30/03/2024)
The proof that Wintriage is a living project is that we continue publishing new versions that correct errors that we detect (or you detect and communicate them to us), as well as new functionalities, all with the intention of having a tool that is as robust, complete and versatile as possible.
The bug fixes and performance improvements that we have introduced on this occasion are the following:
- In version 30072023 we already eliminated the detection of ADS (Alternate Data Streams) in the file systems by default, due to the amount of time this consumed, compared to being able to see it in an analysis of the $MFT, something that without a doubt, is something that we have to do in a large percentage of incidents. For the same reason we have eliminated the execution of the commands that generated a complete list of the file system. Because if we are going to analyze the $MFT and it is a forensic artifact that we are going to have at our disposal, we prefer to accelerate the extraction process by minimizing the number of commands that consume a high volume of time. So we have managed to reduce the extraction of evidence on a file server by about 3-5 minutes on average.
- In the previous version of Wintriage, we implemented the use of Dumpit instead of Ramcapture to generate a dump of the machine’s RAM, since running Ramcapture from a mapped drive (either by SMB or TSClient) it did not work correctly . This meant that we didn’t have to download the RamCapture dependencies in the «Tools» directory. We have realized that the latest version of Dumpit available for download doesn’t work correctly on Windows 2003/XP/7/2008 systems. Testing with previous versions of Dumpit, these were not intended for non-interactive execution, using parameters like /Q and /O, so we cannot use a version compatible with older versions of Windows either. So we have once again included as an auxiliary requirement the four RamCapture files (the two executables and the two drivers with the .sys extension) and we have additionally left the Dumpit files. If you are extracting a Windows 2003/XP/7/2008 system, we recommend that you do it locally, since Ramcapture will be used. However, if you do it on a more modern system than those indicated, Dumpit will be used, this being already functional whether it is executed locally or from a mapped network drive.
- We have fixed a bug that showed a rather ugly error pop-up in case of offline extraction (based on a forensic image of a disk) of user artifacts, when reaching the «Default User».
As new forensic artifacts Wintriage now extracts the following:
- As user artifacts, in the NTUSER.DAT there is usually a section corresponding to the last servers where the user has connected through the native Windows Remote Desktop application. However, if the user has used the Remote Desktop application, this list of servers is not in NTUSER.DAT, but in another location.
This is explained beautifully in this ZEROFOX link, where you can see the previous image.
We have implemented that, if a user has used this tool, the forensic artifacts that store the information relevant to it are left in the user’s directory, extracted by Wintriage.
After reading another interesting article by Zerofox, related in this case to Microsoft’s MSIX package technology, it is observed that those applications that make use of that package format generate forensic information under a subdirectory called «SystemAppData\Helium» where you can rescue certain files that, after processing, allow you to identify files opened with that application, and directories navigated with it (shellbags), something that we wouldn’t have otherwise. So, we implemented that Wintriage, when you tell it to extract forensic information from users, searches in all the AppData\Local\Packages directories of each user, if there are any files that comply with this. If so, it generates within the user directory extracted by Wintriage, a directory for each application in which there is MSIX forensic information.
As always, you can download Wintriage from https://cursos.securizame.com/extra/wintriage.7z.
SHA-256 hash for this version tarball is f0f2b34b79782ec05887bebd4f8e1f9be30551ce9bd4e5e826c06cca508d5c41
